I have been trying to generate MPEG2 streams using FFMPEG for a cable TV project I'm working on. The streams are to be created in real-time and encapsulated in MPEG-TS and sent over an Ethernet network using multicast UDP. No RTP just plain MPEG-TS in UDP. These streams are to be received by Telesté Luminato boxes equipped with DVB-T muxes. This has been somewhat a struggle. Generating a stable stream without errors and dropouts was definitely harder than I initially thought. DVB muxers (or shall we call them modulators?) need to run at a constant bit rate, CBR. I won't go into the details of DVB-T modulation but this is quite reasonable since it is most likely the only way of keeping it in sync and locked. In the same time the material transferred is in most cases MPEG2 video (at least here in Sweden). This is a bit odd to begin with since as far as I know there is no such thing as a CBR MPEG2. But why are people in the TV biz talking about CBR MPEG2? This needed some research and I discovered that my assumption was not totally wrong. MPEG2 in its initial form will always be a stream with variable bit rate, VBR. In order to generate a CBR stream a buffer is used to "even out" the variable bit rate into a somewhat constant bit rate. INPUT--->[MPEG2 encoder]--VBR-->[buffer]--CBR-->OUTPUT Similarly a buffer is used on the receiving end to decode the MPEG2 stream. INPUT--CBR-->[buffer]--VBR-->[MPEG2 decoder]--->OUTPUT So far so good. No magic is happening here. Using a buffer in this way is quite common. Now let's look into how FFMPEG fits into this picture. My experiments are based on the latest release of FFMPEG (at the time of writing 0.11.1 "Happiness"). Creating a basic PAL MPEG2 TS stream using FFMPEG is quite straight forward. # ffmpeg -re -i [source] -vcodec mpeg2video -s 720x576 -r 25 -acodec mp2 -ac 2 -f mpegts outfile.ts This will generate an MPEG-TS file but sending the material over UDP requires just replacing "outfile.ts" with "udp://239.253.253.4:1234?pkt_size=1316". The size of an MPEG-TS packet is 188 Bytes and 7 of them will fit into an Ethernet frame, 7*188=1316. The command is simplified and since for example no bit rates are defined the resulting stream will be of low quality using the pre-compiled default values of FFMPEG. For my purpose the maximum bit rate per channel is 5Mbit/sec in order to not overload the muxes/modulators. The obvious first thing to try for me was to define some bit rates for FFMPEG to work with. For example "-b:v 2M" and "-b:a 192k" for video and audio respectively. # ffmpeg -re -i [source] -vcodec mpeg2video -s 720x576 -r 25 -b:v 2M -acodec mp2 -ac 2 -b:a 192k -f mpegts udp://239.253.253.4:1234?pkt_size=1316 The above command looks like a good start. 2Mb/s video and 192kb/s audio should give some headroom and not hit the limit of 5Mb/s. Right? Well, not really. Analyzing the resulting network utilization showed me an accumulated bit rate of over 50Mb/s at some points! This is quite far away from the requested 2Mb/s video bit rate. Obviously more is needed for this to work. FFMPEG has another parameter "-bt:v" which, according to the built in help, is the bit rate tolerance for video. However, adding something like "-bt:v 200k" to the command did not improve on the situation very much. The bit rate spikes was still way to high. Reading the documentation even further three other parameters looks promising, "-maxrate", "-minrate" and "-bufsize". Using these parameters instead of the single bit rate tolerance parameter has a better effect on the stream. # ffmpeg -re -i [source] -vcodec mpeg2video -s 720x576 -r 25 -b:v 2M -minrate:v 2M -maxrate:v 2M -bufsize:v 1.4M -acodec mp2 -ac 2 -b:a 192k -f mpegts udp://239.253.253.4:1234?pkt_size=1316 Using the command above the spikes are significantly reduced and the bandwidth looks like it is keeping well below 5Mb/s, more likely 2.5Mb/s. The stream actually plays quite nicely on my DVB-T receiver. The playback quality is however not as good as "real" DVB-T channels and there are occasional dropped frames and errors in both video and audio. Increasing the video bit rate variables and playing with GOP and BF, "-g 12 -bf 2", increases the quality to be quite good actually but the occasional dropouts and errors are still there. Forcing FFMPEG to use a constant GOP size with "-flags cgop -sc_threshold 1000000000" improves this even more but it is still not nearly perfect. It turns out that increasing bit rate also increases the frequency of the errors. A bit rate of around 1Mb/s has almost no errors but is of course of way to low quality. A bit rate of 3Mb/s yields good quality but too many errors. 2Mb/s is the best compromise by my observations. Worth mentioning is that VLC has no problem playing back this stream. Playing even more with bufsize shows that FFMPEG is a bit picky about this value. Too small and FFMPEG won't start and too large and it will run but give the following error: "Warning vbv_delay will be set to 0xFFFF (=VBR) as the specified vbv buffer is too large for the given bitrate!". Varying bufsize within the limits according to FFMPEG has no obvious impact on playback quality. The MPEG-TS muxer of FFMPEG has the ability to send out NULL packets using the parameter "-muxrate" to keep a constant total bit rate. This however does not make any difference. Probably because the Luminato modulators I use remuxes the streams anyway. The best working command I have for now is the following. # ffmpeg -re -i [source] -vcodec mpeg2video -s 720x576 -r 25 -flags cgop+ilme -sc_threshold 1000000000 -b:v 2M -minrate:v 2M -maxrate:v 2M -bufsize:v 1.4M -acodec mp2 -ac 2 -b:a 192k -f mpegts udp://239.253.253.4:1234?pkt_size=1316 Just sending out a raw DVB-T MPEG-TS recording using FFMPEG is working very well though. No errors during playback. # ffmpeg -re -i recording.ts -vcodec copy -acodec copy -f mpegts udp://239.253.253.4?pkt_size=1316 This makes me wonder. Even if the MPEG-TS muxer part of FFMPEG appears to be working, is the MPEG2 encoder still not keeping the bit rate under control? If the transfer bit rate is within limits, is the playback bit rate after the buffer within reasonable limits? Perhaps a hardware decoder such as an DVB-T set-top box have a lower limit for how high playback bit rate it can handle. More investigation is needed.