Hello!
I am trying using libVLC to get the udp stream as it happens for the native caspar client.
I tested the application media player streaming a video from vlc and seems to be working correctly.
Unfortunately I do not manage to output the stream from casparcg.
I use the following command to add the stream to the channel:
"ADD 1 STREAM udp://127.0.0.1:5000 -format mpegts"
Server log returns OK
The I play on 1 1 a video but nothing.
Same if I Play an HTML template on 1 10 or just a picture.
What am I doing wrong?
Thanks
One problem with the generic streaming command is it does not force a nice mapping between transport packet size and the IP transport packet size. One possible modification to your command line is to add the packet size onto the destination address:
ADD 1 STREAM udp://127.0.0.1:5000?pkt_size=1316 -format...
This sets 7 transport packets per ethernet packet.
There is an example streaming command in the link below that several users found worked for them.
1 Like
Hello @andyw and thanks for your precious answer on the other post.
I manage to make it work adding the pkt_size.
Here when adding the stream:
ADD 1 STREAM udp://127.0.0.1:5000?pkt_size=1316 -codec:v libx264 -tune:v zerolatency -preset:v ultrafast -crf:v 25 -vf scale=640:360 -format mpegts
While to load it on libVLC media I used:
New Media(libVLC, "udp://@127.0.0.1:5000?pkt_size=1316 :network-caching=100", FromType.FromLocation)
Now I can notice some latency (quite acceptable but…).
It seems like the args are not getting really accepted by CG.
For instance the network caching or apparently the scaling and crf, are not really making any difference.
CG log
[2024-11-29 11:26:11.344] [info] Received message from 127.0.0.1: ADD 1 STREAM udp://127.0.0.1:5000?pkt_size=1316 -codec:v libx264 -tune:v zerolatency -preset:v ultrafast -crf:v 25 -vf scale=640:360 -format mpegts\r\n
[2024-11-29 11:26:11.344] [info] ffmpeg[udp://127.0.0.1:5000?pkt_size=1316] Initialized.
[2024-11-29 11:26:11.345] [info] Sent message to 127.0.0.1:202 ADD OK\r\n
[2024-11-29 11:26:11.346] [info] [ffmpeg] [libx264 @ 00000145D839C5C0] using SAR=1/1
[2024-11-29 11:26:11.346] [info]
[2024-11-29 11:26:11.348] [info] [ffmpeg] [libx264 @ 00000145D839C5C0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[2024-11-29 11:26:11.348] [info]
[2024-11-29 11:26:11.350] [info] [ffmpeg] [libx264 @ 00000145D839C5C0] profile High 4:2:2, level 3.2, 4:2:2, 8-bit
[2024-11-29 11:26:11.350] [info]
[2024-11-29 11:26:11.351] [warning] ffmpeg[udp://127.0.0.1:5000?pkt_size=1316] Unused option vf=scale=640:360
[2024-11-29 11:26:11.351] [info] Received message from 127.0.0.1: TLS\r\n
[2024-11-29 11:26:11.364] [info] [ffmpeg] [libx264 @ 00000145D0050D40] frame I:720 Avg QP:14.02 size: 3708
[2024-11-29 11:26:11.364] [info]
[2024-11-29 11:26:11.365] [info] [ffmpeg] [libx264 @ 00000145D0050D40] frame P:179253 Avg QP:17.01 size: 146
[2024-11-29 11:26:11.365] [info]
[2024-11-29 11:26:11.365] [info] [ffmpeg] [libx264 @ 00000145D0050D40] mb I I16..4: 100.0% 0.0% 0.0%
[2024-11-29 11:26:11.365] [info]
[2024-11-29 11:26:11.365] [info] [ffmpeg] [libx264 @ 00000145D0050D40] mb P I16..4: 0.0% 0.0% 0.0% P16..4: 0.0% 0.0% 0.0% 0.0% 0.0% skip:100.0%
[2024-11-29 11:26:11.365] [info]
[2024-11-29 11:26:11.365] [info] [ffmpeg] [libx264 @ 00000145D0050D40] coded y,uvDC,uvAC intra: 0.6% 1.2% 0.6% inter: 0.0% 0.0% 0.0%
[2024-11-29 11:26:11.365] [info]
[2024-11-29 11:26:11.365] [info] [ffmpeg] [libx264 @ 00000145D0050D40] i16 v,h,dc,p: 72% 5% 23% 0%
[2024-11-29 11:26:11.365] [info]
[2024-11-29 11:26:11.365] [info] [ffmpeg] [libx264 @ 00000145D0050D40] i8c dc,h,v,p: 95% 4% 0% 0%
[2024-11-29 11:26:11.365] [info]
[2024-11-29 11:26:11.365] [info] [ffmpeg] [libx264 @ 00000145D0050D40] kb/s:64.22
Do you have any understanding of the reason and hopefully solution for it?
Thanks
I’m not usre if the syntax for your scaling command is the one used by the newer ffmpeg code. You may need something more like -filter:v scale=640:360.
How large is the oberved latency? Low-latency and low bitrates are not good friends. Lowering latency usually means increasing the number of intra-coded frames, hence higher bitrate requirements. Increasing the latency should enable more in-depth analysis of the source content, enabling location of better P and B blended reference blocks. For H.264 I would expect the time offset between channel out as seen on a screen or Decklink consumer and the decoded output from VLC to be in the order of 1 second.
yes approximately one second… probably a bit less.
I will check the syntax and give a feedback.
Thanks
You are right syntax was not correct.
The image get scaled but the rendering is still slow as before.
I will check the rest 
This was the solution for the latency
' Set network caching via MediaPlayer options (this is better for network-based streaming)
mediaPlayer.NetworkCaching = (100) 'ms
So directly setting it on the mediaplayer.
Thanks @andyw I will set your reply as solution