mad_ady wrote:Also, after I play something with c2play and I later play something in kodi I sometimes see the framebuffer (systemd status messages) as a frame, but it disappears quickly.
I have found the cause of this. There is now code in aml_libs that changes the video mode (alpha enable/disable) when a codec is opened or closed.
https://github.com/mdrjr/c2_aml_libs/bl ... #L705-L728
https://github.com/mdrjr/c2_aml_libs/bl ... #L877-L896
Each time the mode is changed, the fbdev driver redraws the console. This causes it to appear until something draws over it again. Therein lies the problem I am currently facing. In order to support subtitles, I can no longer blank the fbdev as was previously done. I need the fbdev layer visible to draw on. Now instead of blanking it, I clear it to transparent. However, as soon as I open the codec it changes the video mode and linux redraws the console. This means I need to re-clear the buffer each time the codec is opened or closed. Rather than implement work arounds, I would rather correct the cause of the issue and
remove the mode setting code from aml_libs codec_init/codec_close functions. Applications need control over when and what the video mode is set to otherwise problems arise. For example, if a video application crashes or for some other reason never calls codec_close, the video mode is never restored and X11 displays improperly. There are also scenarios where the codec should be opened, but transparency not enabled as in the case of "zero copy" GLES rendering.
As a compromise, I would suggest moving the mode setting code in aml_libs to its own function to enable/disable transparency. This will allow code to determine when its appropriate to change the mode. The mode is not dependent on the codec being open or closed. The currently mode setting assumes we will always have a broken X11 driver and that future APIs like Wayland will need to implement the same broken behavior to function properly.
Since this change would affect Kodi, I am publicly discussing it here to collect feedback from anyone interested.
[edit]
More details ...
In a graph based frame work like OpenMax, GStreamer, and now the command line player, codec_init can not be called until the graph is started and the first video data has arrived detailing the codec format to use. This happens asynchronously in a graph. This means an application will need to monitor the graph continuously or in a call back to know that the codec has been opened and that screen needs to be cleared again. While an application like Kodi will clear the screen every frame mitigating this, it will also need to ensure the console is cleared so that when the mode switch happens only black is displayed instead of text. Clearing the screen each frame is no longer trivial when we are dealing with 4K displays. This places a lot of unnecessary memory bandwidth pressure on the bus. It is also pointless to clear the display each frame when only video is showing. My intended strategy is to only clear the display when needed and to use "dirty rectangles" to only update the part of the display that needs it. This reqruies work-around if the codec opening and closing causes the display contents to be "trashed".
[edit 2]
I played around with adding new entry points to aml_libs: codec_init_no_modeset and codec_close_no_modeset. This means that other programs will not require any changes and I can simply use the new API calls. However, it creates further disparity between the C2 API set and the C1. In the end, I am considering abandoning aml_libs. It is mainly a convience library that wraps driver IOCTLs. Since I do not require most of its functionality, it will probably be better if I just call the IOCTLs directly.
