Receiving raw H.264 UDP streams stopped working for me in VLC 3.0.x (working fine in 2.2.8)
Posted: 15 Apr 2018 15:36
Hi,
I’m using VLC as a client for receiving the camera stream from a Raspberry Pi (it is raw H.264 via local UDP Multicast).
In 2.2.8, this works fine:
Output:
Even though there’s a demux error, the stream is working fine.
In 3.0.1, the same doesn’t work anymore:
Output:
(and so on)
An image is displayed though, but it’s unusable (blurry and mostly green area).
This is the command I’m using on the Raspberry Pi to create the stream:
Is this a bug in VLC, or is it expected behavior that version 3 is stricter when it comes to non-standard(?) streams?
Thanks,
Aaron
PS: For some reason, the forum doesn’t print the line breaks in my code snippets
I’m using VLC as a client for receiving the camera stream from a Raspberry Pi (it is raw H.264 via local UDP Multicast).
In 2.2.8, this works fine:
Code: Select all
$ /Applications/VLC.app/Contents/MacOS/VLC --network-caching 0 --demux h264 udp://@239.255.0.1:5000Code: Select all
VLC media player 2.2.8 Weatherwax (revision 2.2.8-2-gf5224a0)
[00000001038000e8] core libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
[000000010033e5a8] h264 demux error: this doesn't look like a H264 ES stream, continuing anyway
[0000000100248438] core input error: Invalid PCR value in ES_OUT_SET_(GROUP_)PCR !
shader program 1: WARNING: Output of vertex shader 'TexCoord1' not read by fragment shader
WARNING: Output of vertex shader 'TexCoord2' not read by fragment shaderEven though there’s a demux error, the stream is working fine.
In 3.0.1, the same doesn’t work anymore:
Code: Select all
/Applications/VLC.app/Contents/MacOS/VLC --network-caching 0 --demux h264 udp://@239.255.0.1:5000Code: Select all
VLC media player 3.0.1 Vetinari (revision 3.0.1-0-gec0f700fcc)
[00007ff65ac1fd00] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
[00007ff65fc0a1c0] udp stream error: 1316 bytes packet truncated (MTU was 1316)
[00007ff65ac5ff70] h26x demux error: this doesn't look like a h264 ES stream, continuing anyway
[00007ff65fc0a1c0] udp stream error: 1316 bytes packet truncated (MTU was 1316)
[00007ff65fc0a1c0] udp stream error: 1316 bytes packet truncated (MTU was 1316)
[00007ff65fc0a1c0] udp stream error: 1316 bytes packet truncated (MTU was 1316)
[00007ff65fc0a1c0] udp stream error: 1316 bytes packet truncated (MTU was 1316)
[00007ff65fc0a1c0] udp stream error: 1316 bytes packet truncated (MTU was 1316)
[00007ff65fc0a1c0] udp stream error: 1316 bytes packet truncated (MTU was 1316)
[00007ff65fc0a1c0] udp stream error: 1316 bytes packet truncated (MTU was 1316)
[00007ff65fc0a1c0] udp stream error: 1316 bytes packet truncated (MTU was 1316)
[00007ff65f9dc520] main stream error: unknown query 0x30e in demux_vaControlHelper
[00007ff65fc0a1c0] udp stream error: 1316 bytes packet truncated (MTU was 1316)
[00007ff65fc0a1c0] udp stream error: 1316 bytes packet truncated (MTU was 1316)
[00007ff65fc0a1c0] udp stream error: 1316 bytes packet truncated (MTU was 1316)
(and so on)
An image is displayed though, but it’s unusable (blurry and mostly green area).
This is the command I’m using on the Raspberry Pi to create the stream:
Code: Select all
raspivid -ae 40,0xff -a 1036 -t 0 -w 1280 -h 720 -ih -fps 30 -o udp://239.255.0.1:5000Is this a bug in VLC, or is it expected behavior that version 3 is stricter when it comes to non-standard(?) streams?
Thanks,
Aaron
PS: For some reason, the forum doesn’t print the line breaks in my code snippets