My five-part series on our low-latency VLC setup ended yesterday, with a discussion about muxing and various one-frame-latency-inducing effects in different parts of VLC. Before that, I'd been talking about motivations, the overall plan, codec latency and timing.
This time there is no new material, only a few comments from readers of the series of the last few days. Thanks; you know who you are.
- The UDP output is not the only VLC output that can multicast; in particular, the RTP mux/output can do it, too, in which case the audio and video streams are just sent out more or less as separate streams. This would avoid any problems the TS mux might have, and probably replace them with a whole new and much more interesting set. (I've never ever had any significant success with RTP as a user, so I don't think I'll dare to unleash it from the server side. In any case we need TS for the HTTP streams, and sticking with fewer sets of options is less confusing if we can get away with it.)
- VLC 1.1.x can reportedly use H.264 decoding hardware if your machine, OS and drivers all support that. I have no idea how it impacts latency (it could go both ways, I reckon), but presumably it should at least make decoding on the client side cheaper in terms of CPU.
- If you're running slice-based threads, you might not want to use too many threads, or bitrate allocation might be very inefficient.
- The DVD LPCM encoder is now in VLC's git repository. Yay :-)
- The collective bag of hacks I use that have not been sent upstream can be found here. Caveat emptor.
Finally, I realized I hadn't actually posted our current command-line anywhere, so here goes:
vlc \
--decklink-caching 20 --sout-mux-caching 1 --sout-ts-dts-delay 60 --sout-ts-shaping 1 --sout-udp-caching 1 --no-sout-transcode-hurry-up \
--decklink-aspect-ratio 16:9 --decklink-mode pal \
--sout-x264-preset medium --sout-x264-tune zerolatency,film \
--sout-x264-intra-refresh --no-sout-x264-interlaced --sout-x264-weightp 0 --sout-x264-bpyramid strict --sout-x264-ref 1 \
--sout-x264-keyint 25 --sout-x264-lookahead 0 \
--sout-x264-vbv-bufsize 60 --sout-x264-vbv-maxrate 1500 \
-I dummy -v decklink:// vlc://quit \
--sout '#transcode{vcodec=h264,vb=1500,acodec=lpcm}:std{access=udp,mux=ts,dst=10.0.0.1:9094}'
You'll probably want to up the bitrate for a real stream. A lot. And of course, coding PAL as non-interlaced doesn't make much sense either, unless it happens to be a progressive signal sent as interlaced.
I'll keep you posted if there's any new movement (new latency tests, more patches going into VLC, or similar), but for now, that's it. Enjoy :-)