[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