Black Flash after Video play

[ChayMahajj]

Hello everyone,

I am using vlc to play videos but after each played video there is a black glitch apearing then disapears like black flash. "I noticed that when I played a video that ends with white frame and then I displayed a white image with another image player application based on framebuffer device"

Is ther a work-around solution can be implemented in VLC source code ?

I will be thankfull that someone can provide me with a suitable path to follow in order to find the right solution.

Thank you

Best regards, Chayma.

[jc-kynesim]

Short answer - no easy reliable solution. VLC tends to close its output "window" at the end of a clip and & reopen it at the start of the next. There is some code that sometimes preserves stuff but it can be very tricky if the display is actively using a decode backing buffer to keep an image on screen. But to (maybe) address your problem - what Pi are you using and what output mode (wayland, X, drm or something else)?

[ChayMahajj]

Hello jc-kynesim,

thank you for your quick answer. I am using Compute Module 4 with a customized base board , Display is connected via HDMI and I am using drm as output mode for VLC Note : I am using vlc cmd line so without GUI

[ChayMahajj]

The main problem was switching between vlc and a framebuffer based image player application. When I switch from vlc to framebuffer, an old image is displayed before the current image is displayed. So I thought of displaying the last frame of the video and here comes the black flash appearance.

[jc-kynesim]

Sorry - I don't think you are going to have any joy. You are almost certainly using drm out in vlc and tearing that down to go to another app absolutely requires vlc reclaiming the last display buffer before exit which will produce a black frame. It is just possible that vlc has a framebuffer output mode that might do the trick for you but that is going to have slow output compared to drm typically so may not play video well.

[ChayMahajj]

It is an old trick I am using to fix this issue, I t was working well with omxplayer. Mainly I am using customized image player application to implement transition btween images and for displaying vlc is not working well as well as there is no transition.

I think I have to rethink all the solution now since I am using VLC ? And if I undrestand well there is no solution as work around in VLC source code ?

[jc-kynesim]

There is no workaround that I am aware of that is likely to do what I think you want.

[ChayMahajj]

even to disable that black frame produced when exiting ?

[jc-kynesim]

The chances are it is black due to there being no frame at all. When displaying via DRM the frames are mapped directly from the decoder buffers - those are reclaimed by the system before exit so what you are looking at is a lack of frame rather than a deliberately created black frame.

[ChayMahajj]

Undrestood! Could you please help me to find where in the Source code VLC is checking if there is there no frame or not. Thank you

[jc-kynesim]

There is no such code in VLC - this would be the kernel.

Now it occurs to me that you might not be seeing a black frame per-se but a mode change which often blacks the screen (depending on monitor) as drm attempts to restore the previous context on close. Does adding --drm-no-modeset to your command line help?

[ChayMahajj]

Yes I am already using --drm-no-modeset in order to prevent vlc from switching off/on the display in the start and in the end.

[ChayMahajj]

Hallo, Since drm is producing this kind of black frame. Can I use another vout interface that gives me a good video play result?

[ChayMahajj]

If drm is producing the black frame so I can modify the close function of drm_vout in order to ignore this ? Right? Or it will be useless ?

[jc-kynesim]

My expectation is that it will be useless but feel free to experiment. If you come up with something that does what you need and doesn't break anything else I'd appreciate the patch.

[ChayMahajj]

Great thank you for providing your opinion.

[jc-kynesim]

I don't want to get your hopes up but I've just fixed an issue in drm close that might have caused what you are seeing. The fix will be in the next Pi VLC release which I'm guessing will turn up in public sometime next week. I stress might here - if it doesn't get better with that (or if I've merely changed the behaviour to something else undesirable to you) then I really have no ideas that will help.

[ChayMahajj]

Hello jc-kynesim

Sorry for my late reply. I was in vacation. I hope the update help to fix my problem. Where can I find the fix ? I am using bullseye branch. Is it already released ?

[ChayMahajj]

@jc-kynesim is the new changes already released ? If yes, where can I find it ? Note : I am using bullseye branch to compile VLC

[jc-kynesim]

It should be in the standard pios apt distribution and in the patchset here.

[ChayMahajj]

@jc-kynesim all patches in debian 11 branch are not recently updated. Should I use debian 12 instead of debian 11 ?

[ChayMahajj]

Hi @jc-kynesim Should I consider only this update (refer to the picture) or all the patch hwaccel_41 ? Thanks

[jc-kynesim]

Ummm... It depends what you are applying it to. If you are applying patches to an upstream VLC then you clearly need the entire patchset (the file your highlit line is patching doesn't exist otherwise) - if you are applying to the sources that Pi builds from it should already be there. But as a slightly more helpful answer - take the entire lot - you've got the wrong line(s).

[ChayMahajj]

I am using bullseye branch to build from source VLC. I found teh patch in debian12 branch The picture present a diff btw mmal_35.patch in debian 11 and hwaccel_41.patch in debian 12 version Is Applying the entire lot (the file hwaccel_41.patch) in debian 11 branch wouldn't create an issue right ? Thanks for your response. @jc-kynesim

[jc-kynesim]

The patchset applies to VLC 3.0.20. VLC 3.0.20 with this patchset compiles fine under bullseye. I don't know what versions earlier Debian distributions are using.

[ChayMahajj]

Thank you for this quick answer. The upstream rpi-vlc package v3.0.20 is not available in bullseye So to be more sure I will apply all the patches under bookworm-rpt branch (debian/patches) in bullseye-rpt branch in order to get the same changes in bullseye. Or is it better to get the coude source of v3.0.20 from VLC official site and apply directly the patches under bookworm-rpt branch ? What do you think ?

Thanks again.

[jc-kynesim]

I'd take the patched sources from bookworm and compile them under bullseye

[ChayMahajj]

Hello @jc-kynesim trying to build the bookworm branch and applying the patch series I got this error

[jc-kynesim]

Ah - bother - looks like that isn't in your drm_fourcc.h. I don't have a bullseye PiOS to check against here but try adding

#define fourcc_mod_get_vendor(modifier) \
        (((modifier) >> 56) & 0xff)

#define fourcc_mod_is_vendor(modifier, vendor) \
        (fourcc_mod_get_vendor(modifier) == DRM_FORMAT_MOD_VENDOR_## vendor)

#define fourcc_mod_code(vendor, val) \
        ((((__u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | ((val) & 0x00ffffffffffffffULL))

(copied from my drm_fourcc.h)

[ChayMahajj]

I can't find a file with the name drm_fourcc.h (Is it library directory or in Vlc source code )

[ChayMahajj]

the file is under libdrm folder ( and it is a locked folder that I can't modify it)

[jc-kynesim]

Yes - I was simply going to suggest that you added the missing defns to drmu_vlc_fmts.c

[ChayMahajj]

Thank you for your help @jc-kynesim This patch fixes my issue.