[FFmpeg-user] Live transcoding to an rtp stream is unreliable.

David Pottage david at electric-spoon.com
Mon Apr 11 14:26:22 CEST 2011


On 07/04/11 14:05, Alexandre Ferrieux wrote:
> Look at these lines. Aren't they ominous ?
>
>>> [mpeg2video @ 0xa193990]ac-tex damaged at 11 22=4.52 bitrate=
>>> 73.2kbits/s dup=12 drop=0
>>> [mp2 @ 0xa1940f0]incomplete frame
>>> Error while decoding stream #0.1
>
> Clearly this indicates a problem in the input bitstream. Maybe some 
> network latency stalled the TCP (on the http leg) a bit, producing an 
> oveerun at the source, resulting in TS discontinuity ?
>
> Given the above observations, I'd concentrate on the input decoding 
> step, and on the video only. For this, use vocdec copy and the 
> container format that is the simplest for the given codec, here 
> mpeg2video:
>
>     ffmpeg -loglevel verbose \
>         -pix_fmt yuv422p -s 720x576 -i http://david-laptop:8000/4228 \
>         \
>         -an -sn -vcodec copy -f mpeg2video - > out.m2v
>
> With this, you're guaranteed that ffmpeg will not be the limiting 
> factor (unlike a possibly costly x264), since basically it just has to 
> write to disk (you can even use /dev/null instead of out.m2v, just in 
> case).

I tried that with this command line:

ffmpeg -loglevel debug -pix_fmt yuv422p -s 720x576 -i 
http://10.10.10.10:8000/4228 -an -sn -vcodec copy -f mpeg2video - > 
/dev/null

> FFmpeg version 0.6.1, Copyright (c) 2000-2010 the FFmpeg developers
>   built on Apr  4 2011 16:31:39 with gcc 4.4.3
>   configuration: --enable-postproc --extra-ldflags=-static 
> --extra-libs='-lvorbis -logg -lxvidcore -lx264 -lopencore-amrnb 
> -lopencore-amrwb -lfaad -lfaac -lm -lpthread' --enable-gpl 
> --enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb 
> --enable-libopencore-amrwb --enable-libvorbis --enable-libx264 
> --enable-libxvid --enable-nonfree --enable-shared --enable-version3 
> --enable-libfaad --enable-small --disable-ffplay --disable-ffserver 
> --disable-doc
>   libavutil     50.15. 1 / 50.15. 1
>   libavcodec    52.72. 2 / 52.72. 2
>   libavformat   52.64. 2 / 52.64. 2
>   libavdevice   52. 2. 0 / 52. 2. 0
>   libswscale     0.11. 0 /  0.11. 0
>   libpostproc   51. 2. 0 / 51. 2. 0
> [NULL @ 0xa89cae0]Probed with size=2048 and score=100
> [mpegts @ 0xa89cae0]stream=0 stream_type=2 pid=262 prog_reg_desc=
> [mpegts @ 0xa89cae0]stream=1 stream_type=3 pid=263 prog_reg_desc=
> [mpegts @ 0xa89cae0]stream=2 stream_type=3 pid=264 prog_reg_desc=
> [mpegts @ 0xa89cae0]stream=3 stream_type=6 pid=267 prog_reg_desc=
> [mpegts @ 0xa89cae0]stream=4 stream_type=5 pid=26b prog_reg_desc=
> [mpegts @ 0xa89cae0]stream=5 stream_type=b pid=3f0 prog_reg_desc=
> [mpegts @ 0xa89cae0]stream=6 stream_type=b pid=3f1 prog_reg_desc=
> [mpegts @ 0xa89cae0]stream=7 stream_type=b pid=3f2 prog_reg_desc=
> [mpegts @ 0xa89cae0]stream=8 stream_type=b pid=28a prog_reg_desc=
> [mpegts @ 0xa89cae0]stream=9 stream_type=b pid=28b prog_reg_desc=
> [mpegts @ 0xa89cae0]stream=10 stream_type=b pid=28c prog_reg_desc=
> [mpeg2video @ 0xa8a2990]mpeg_decode_postinit() failure
>     Last message repeated 7 times
> [mpegts @ 0xa89cae0]max_analyze_duration reached
> [mpegts @ 0xa89cae0]Estimating duration from bitrate, this may be 
> inaccurate
> Input #0, mpegts, from 'http://10.10.10.10:8000/4228':
>   Duration: N/A, start: 33989.713744, bitrate: 15256 kb/s
>   Program 4228
>     Stream #0.0[0x262], 129, 1/90000: Video: mpeg2video, yuv420p, 
> 720x576 [PAR 64:45 DAR 16:9], 1/50, 15000 kb/s, 26.24 fps, 25 tbr, 90k 
> tbn, 50 tbc
>     Stream #0.1[0x263](eng), 211, 1/90000: Audio: mp2, 48000 Hz, 2 
> channels, s16, 256 kb/s
>     Stream #0.2[0x264](eng), 0, 1/90000: Audio: mp3, 0 channels, s16
>     Stream #0.3[0x267](eng), 1, 1/90000: Subtitle: dvbsub
>     Stream #0.4[0x26b], 0, 1/90000: Data: 0x0005
>     Stream #0.5[0x3f0], 0, 1/90000: Data: 0x000b
>     Stream #0.6[0x3f1], 0, 1/90000: Data: 0x000b
>     Stream #0.7[0x3f2], 0, 1/90000: Data: 0x000b
>     Stream #0.8[0x28a], 0, 1/90000: Data: 0x000b
>     Stream #0.9[0x28b], 0, 1/90000: Data: 0x000b
>     Stream #0.10[0x28c], 0, 1/90000: Data: 0x000b
> Output #0, mpeg2video, to 'pipe:':
>   Metadata:
>     encoder         : Lavf52.64.2
>     Stream #0.0, 0, 1/90000: Video: mpeg2video, yuv420p, 720x576 [PAR 
> 64:45 DAR 16:9], 1/25, q=2-31, 15000 kb/s, 90k tbn, 25 tbc
> Stream mapping:
>   Stream #0.0 -> #0.0
> Press [q] to stop encoding
> [mpegts @ 0xa89cae0]Invalid timestamps stream=0, pts=7076, 
> dts=8589930868, size=23135
> [mpegts @ 0xa89cae0]Invalid timestamps stream=0, pts=3684, 
> dts=8589927476, size=10251
> [mpegts @ 0xa89cae0]Invalid timestamps stream=0, pts=292, 
> dts=8589924084, size=8591
> frame=6744789 fps= 25 q=-1.0 Lsize=95343472kB time=269792.20 
> bitrate=2895.0kbits/s
> video:95343472kB audio:0kB global headers:0kB muxing overhead 0.000000%
> Received signal 2: terminating.

It ran all weekend until I stopped it myself, so it looks like the input 
processing is stable.

> Maybe ffmpeg is not proceeding because it is still expecting a GOP 
> start (a key frame). Do you have an idea of the gop size in your 
> source ? Is it stable ?
>
> Also, clearly the reproducibility of a live stream is poor. I'd 
> suggest saving the TS stream to a file for post mortem analysis.

The input stream is broadcast TV. From memory there is an I frame about 
once every 2 seconds, and about 3 P frames per second.

I saved a local copy of the input stream with wget:
> wget http://10.10.10.10:8000/4228 -O BBC2_4228.dvb

I then ran the live transcode command line again replacing the input URL 
with the filename:

ffmpeg -loglevel verbose -pix_fmt yuv422p -s 720x576 -i BBC2_4228.dvb 
-vn -sn -acodec libfaac -ar 48000 -ab 64000 -ac 2 -async 1 -flags 
+global_header -f rtp rtp://web-01:9022 -an -sn -vcodec libx264 -s 
320x240 -fpre resources/ffpreset/libx264-hq.ffpreset -fpre 
resources/ffpreset/libx264-ipod320.ffpreset -vglobal 1 -f rtp 
rtp://web-01:9020 -newvideo

This time the transcode ran to completion and did not fall over.

> If this setup reproduces the behavior, you have a source overrun or 
> corruption, either due to the network or something inside the source 
> machine itself (CPU bound ?).
>
> If not, then ffmpeg's slowness was the reason for the overrun (not 
> swallowing input fast enough), most likely due to the x264 CPU demand; 
> in that case, try with a more modest preset, resampling to smaller 
> size, etc.

Could there be another explanation?

I have been doing these tests on a powerful 8 Core machine, that is able 
to concurrently transcode 5 similar input streams to x264 using similar 
codec settings but using VLC. These 5 transcode jobs use about 60% of 
the machine's CPU together.

It sounds unlikey that one transcode process with ffmpeg would tax the 
machine if it can normaly do five such transcode processes using vlc.

-- 
David Pottage



More information about the ffmpeg-user mailing list