also the CPU usage is pretty much the same no matter the hardware acceleration preference is toggled or not, so I can only guess it's always using hardware acceleration given that software decoding wouldn't keep up with 1080p.

I downloaded vlc testing on December 11th as directed by changing the source repositories to testing which also brought updates to ffmpeg and chromium. This was for my 4b 4gb (acquired after the firmware updates that corrected overheating problems and which has been more or (occasionally) less a joy to use and actually exceeded my expectations considering some of the comments I had read on these forums and elsewhere).

After this update I was pleased to note that both vlc and the repository version of mpv would play videos that used the vp9 codec. Prior to these testing updates both vlc and mpv(but not chromium browser or kodi) rendered vp9 videos with artifacts that made them unwatchable. At the same time I updated raspbian firmware so as to enable arm64 using /boot/config.txt (which incidentally I have subsequently disabled since it seemed to make firefox consistently crash when playing youtube in browser.) and observed after the firmware update thus enabled vlc was also able to play vp8 videos which it didn’t previously.

Now for the problem which seems to have crept into my system only in the last day or two- at least I didn’t notice it before. I use the chromium extension Open in VLC media player to play youtube videos via vlc:

In recent days I notice vlc crashing abruptly with no warning when playing youtube videos online via vlc player. These crashes take place often well along in the video with very low cpu and memory use. When replaying the video again in vlc,the crash will occur at a different spot in the video. My pi is not over-clocked. My internet download speed is usually in excess of 90mbps as mesuared by Ookla It crashes with both cma=512M added to /boot/commandline.txt and without this addition. It crashes with vlc preferences set to either video out to mmal splitter or to video out set to x11(xcb). Incidentally I see no to differences in resource usage or capabilities using either of these video outputs but I prefer x11(xcb) because it enables a floating control bar in full screen activated by mouse movement. It crashes with both gpu allocated 160mb and 192mb.

The video I have just been testing it on (altough it occurs in other videos as well) is:

(Which incidentally really is a must see. While I am a classical music aficionado my musical tastes are fairly catholic and this is some really joyful life affirming roots music preserved by a courtly southern lawyer. truly from bygone days.- see also in a somewhat similar vein on the same youtube channel:
:

I update raspbian via synaptic quite regularly. I notice one recent upgrade was

libffms2-4 on December 14th

and
libsasl2-2 and libsasl2-modules-db on december 21st

Anyone have any suggestions as to what may be causing this frustrating error. It does not appear to happen on local videos.
Naturally if you do not wish to add the aforementioned chromium extension you can replicate the problem by pasting the url into vlc

I enabled pulse in vlc audio out . I had previously installed apulse a pulse emulator to get a recent debian firefox non esr working and it seems to work in vlc. I am going to test this a bit and see if it resolves the vlc crashes.

Addenda so far with limited testing of apulse installed and audio out pulse no more crashes with vlc playing youtube videos.
adenda to addendas vlc just crashed
vlc with pulse enabled just crashed. alas!

Hi
with the new version can i play my 3840x1080 videos to fullscreen hdmi outputs?
So 1920x1080 (left part of the video) to hdmi1 and 1920x1080 (right part of the video) to hdmi2?
thanks

I imagine you can do that from desktop in windowed mode (with window occupying almost whole of both screens).
Performance may not be great. I don't believe a single instance of VLC supports two displays in fullscreen mode.

Yes, but framerate is very low, i see tearing, etc. Not usable.
Any plan for this feature in future versions?
I think many of us like to use dual output, if engineers already gived to us

I think you expect too much. In window mode you already get lost frames when you play a 1080p50 video (not in overlay mode!) on a 1080p screen. It will get worse on larger screens or double screens. But I'm not sure what is possible with the new H265 decoder.

Minimal Kiosk Browser (kweb)
Slim, fast webkit browser with support for audio+video+playlists+youtube+pdf+download
Optional fullscreen kiosk mode and command interface for embedded applications
Includes omxplayerGUI, an X front end for omxplayer

I think you expect too much. In window mode you already get lost frames when you play a 1080p50 video (not in overlay mode!) on a 1080p screen. It will get worse on larger screens or double screens. But I'm not sure what is possible with the new H265 decoder.

In an X window, the bottleneck is rendering the pixels, not the codec.
Running fullscreen, we can bypass X and render to a hardware YUV layer which is much better.

4K or 2x1080p is always likely to struggle in an X window, but is more feasible fullscreen.
But I don't believe VLC supports two displays in fullscreen mode.

Running two instances of VLC in fullscreen mode may be possible (currently they can't both decode hevc, but that is being worked on).
The playback won't be synchronised.

It won't be a priority to support this in VLC as it's a pretty niche use case.

Today I downloaded a video from German TV station "ARD". I was surprised to see that they now offer it in 1080p50 (non-interlaced) resolution. I tried to play it in VLC and only got a black screen (but heard the audio track). The message window shows lots of messages like
mmal_codec error: Failed to alloc CMA buf: fmt=Z420, size=3133440

If I open it in omxplayer(GUI) it runs without any problems. Even mplayer can play it but with a lot of lost frames.

CMA is the kernel's contiguous memory allocator, not GPU. If you have vc4-fkms-v3d or vc4-kms-v3d loaded then it would have increased that heap automatically to 256MB. Otherwise add "cma=128M" to /boot/cmdline.txt (do not add any carriage returns).

CMA is the kernel's contiguous memory allocator, not GPU. If you have vc4-fkms-v3d or vc4-kms-v3d loaded then it would have increased that heap automatically to 256MB. Otherwise add "cma=128M" to /boot/cmdline.txt (do not add any carriage returns).

I'm testing this on a RPi 4/4GB. vc4-fkms-v3d is enabled. cmdline.txt has
cma=512M

Minimal Kiosk Browser (kweb)
Slim, fast webkit browser with support for audio+video+playlists+youtube+pdf+download
Optional fullscreen kiosk mode and command interface for embedded applications
Includes omxplayerGUI, an X front end for omxplayer

Hi, I'm testing the patch on Rpi 4 within BalenaOS and 32 bit docker OS image based on debian (balenalib/raspberrypi3:buster-run).
When I play HVEC video, the mmal opens the hvec codec correctly, but fails to find the required devices /dev/rpivid-*.

Could you please point me to the right direction?
What is responsible for creating those devices? Do I need to install additional drivers or enable some overlays?
I found that before those devices were named /dev/argon-*, but neither is available in host devices.

Hi, I'm testing the patch on Rpi 4 within BalenaOS and 32 bit docker OS image based on debian (balenalib/raspberrypi3:buster-run).
When I play HVEC video, the mmal opens the hvec codec correctly, but fails to find the required devices /dev/rpivid-*.

Could you please point me to the right direction?
What is responsible for creating those devices? Do I need to install additional drivers or enable some overlays?
I found that before those devices were named /dev/argon-*, but neither is available in host devices.

Thank you, so would that be something like dtoverlay=brcm,bcm2838? That's all?
I'm not experienced with this.

No. The relevant nodes are part of the base device tree definition for the Pi4. For some reason your kernel build doesn't have those defines in the device tree, or hasn't built the relevant module (does "modinfo rpivid-mem" give you the details of the module?)

Sorry, we support Raspbian and our standard kernel configs / device tree. If BalenaOS does something else then you need to ask them for support (or is it your hosted Debian build at fault?)

No idea off the top of my head.
I know that there are a number of different formatting paths through VLC because of the odd way that it can order plugins, but the expert on VLC is on holiday at present.
I don't know how the geometry effects are implemented, but they'll typically hammer performance anyway.

Today I downloaded a video from German TV station "ARD". I was surprised to see that they now offer it in 1080p50 (non-interlaced) resolution. I tried to play it in VLC and only got a black screen (but heard the audio track). The message window shows lots of messages like
mmal_codec error..............

Just revisited this thread. I am using vlc version 3.0.8-0+deb10u1+rpt7 with a gpu allocation of 160. I didn’t add cma=512. I downloaded your video here in Canada and encountered no geo restriction. The video played smoothly, no dropped frames (other than a few at the very beginning or if fast forwarded) even in windowed mode ,low cpu usage~6%,
PS. Digressing for a momentI back to the avidenux thread

https://www.raspberrypi.org/forums/view ... x#p1591343
I would really recomend you give avidemux a try. I am using version 2.7.4 and as far as I can tell it is frame accurate and does do smart rendering. I have lately been using it a fair bit on the pi for quick correcting of audio sync problems, cutting portions out of videos, and appending videos and it so fast!

Edit:

Edit: I should point out out although I don’think it is relevant to this video that I had done an rpi-update to the Jan 10, 2020 firmware so as to enable vp8 playback in vlc which at least at the time when I did the rpi-update didn’t play in vlc with the stable firmware.
Pi users might be interedted in knowing if they weren’t already aware that the Pi 4 got some vey favourasble mention from an influential source recently ie.: