I’m using latest CasparCG 2.0.7 and a simple playout controller for IPTV-playout. I have to produce accurate CBR mpegts multicast UDP stream which is sent to hardware DVB-T muxers. The muxers accept only CBR stream with PCR accuracy interval around 30ns. I put together a simple ffmpeg cmd which satisfies the requirements and it works ok.
The ffmpeg parameters I added to CasparCG and it (almost) all works perfectly without the “muxrate” parameter. The stream plays nice, but it’s VBR without proper muxrate setting and PCR interval isn’t accurate. If I add the muxrate parameter, I get lots of “PCR<DTS: TS is invalid” errors displaying all the time inside CasparCG console. The same parameters combination works perfectly nice if I run ffmpeg directly from command line, but it won’t work from CasparCG. I tried all possible combinations using different values and different codecs, but I’m out of luck.
The working combination is (just important video params): -c:v mpeg2video -minrate 5000k -maxrate 5000k -bufsize 700k -pcr_period 30 -f mpegts udp://239.1.1.1:5000?pkt_size=1316"
The same command with “muxrate” parameter added and all others left the same, produces errors: -c:v mpeg2video -minrate 5000k -maxrate 5000k -bufsize 700k -muxrate 5450k -pcr_period 30 -f mpegts udp://239.1.1.1:5000?pkt_size=1316"
I’m completely lost. Is there anything that can be done to use “muxrate” paramater without these errors? Am I missing some other parameter maybe? Lastly, why command line ffmpeg (v3.x and v4.x) with the same parameters and same video output work ok, but not from CasparCG?
Thank you in advance for any kind of help! Best regards.
What version of CasparCg are you using? Good ole 2.0.7 only has ffmpeg 2.8 so that might be a deal-breaker?
Version 2.2 (from builds.casparcg.com) has ffmpeg 3.4 but keep in mind it doesn’t accept the short hand parameters.
Lastly, I’d generally recommend to do something like a high bandwidth little encoding udp stream output (Unix sockets on Linux) and do the actual encoding in its own program.
Thanks for reply! I’m using 2.0.7 as written in my first post. Muxrate parameter is recognized, so version shouldn’t be an issue. I played a bit more around and added another parameter “max_delay” to ffmpeg and the DTS<PCR warningg are actually gone! If someone has knowledge to explain this behaviour, I’d highly appreciate it. Currently I have “minrate=5000k,maxrate=5000k,bufsize=700k,muxrate=5450k,max_delay=700k,pcr_period=30” and it seems to be working ok.
What do you mean by “short hand” parameters? Which are those?
Regarding your suggestion to use little encoding udp stream output and then probably another (separate) instance of ffmpeg to re-encode the stream with proper parameters. Why whould this be better then doing actual output from CasparCG directly? It’s one more app, one more thing that can “crash”, more CPU resources, one more startup-restart script to somehow automatize everything. I really don’t see the need for this, or am I missing something?
Lastly, is there an option to pass the “streamid” parameters to CasparCG in latest 2.2 version? I tried with 2.0.7 and it won’t accept them (unrecognized). For instance, -streamid=0:200 -streamid=1:300 should set video PID to 200 and audio PID to 300 for mpegts output stream. How can I do this with CasparCG?
Regards and thanks in advance again for your help!
Good to hear you managed to resolve it, that’s great!
Shorthands are parameters like using -f for -format.
I’d rather have a watcher running for 10 small scripts that each crash once a week than 1 big application crashing 10 times a week. In my experience everything that can crash will crash, and by seperating the encoding it is less likely to take the rest of CasparCG with it and it should be faster to restart the process. Concerning CPU resources, you will see very little overhead for a cli instance of ffmpeg compared to running the ffmpeg process from inside CasparCG. In my experience the ffmpeg consumer inside casparcg also doesn’t recover well from crashes, so it would likely be more stable this way. But I should note, I used to do this only on linux which can pipe the rawvideo over a unix socket. Having to run through udp might not be as stable as that, actually.
It is important to use a recent version of FFMPEG. I wrote a program a while back for playout on our ATSC TV station. I can dig up the encode settings I used. Last I checked ffmpeg had pacing issues with it’s udp portion. They may have fixed it, but I had to write my own udp packet sending routine to get smooth playback without overflowing the video buffer in the TV decoders. I don’t have the scheduler finished, but the manual stream from the settings page works, and all the stream code is isolated in a streaming library.