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

[Alexandre Ferrieux]

On 07/04/2011 14:41, David Pottage wrote:
> On 07/04/11 12:39, Alexandre Ferrieux wrote:
>>
>> First, give the ffmpeg output (giving the version, detected container
>> and codec, stream mapping etc.).
>
> Here:
>
>> 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

Thanks.

>> [mpeg2video @ 0x9943990]mpeg_decode_postinit() failure
>> Last message repeated 13 times
>> [mpegts @ 0x993dae0]max_analyze_duration reached
>> [mpegts @ 0x993dae0]Estimating duration from bitrate, this may be
>> inaccurate
>> Input #0, mpegts, from 'http://10.10.10.10:8000/4228':
>> Duration: N/A, start: 55166.391433, bitrate: 15256 kb/s
>> Program 4228
>> Stream #0.0[0x262]: Video: mpeg2video, yuv420p, 720x576 [PAR 64:45 DAR
>> 16:9], 15000 kb/s, 27.63 fps, 25 tbr, 90k tbn, 50 tbc
>> Stream #0.1[0x263](eng): Audio: mp2, 48000 Hz, 2 channels, s16, 256 kb/s
>> Stream #0.2[0x264](eng): Audio: mp3, 0 channels, s16
>> Stream #0.3[0x267](eng): Subtitle: dvbsub
>> Stream #0.4[0x26b]: Data: 0x0005
>> Stream #0.5[0x3f0]: Data: 0x000b
>> Stream #0.6[0x3f1]: Data: 0x000b
>> Stream #0.7[0x3f2]: Data: 0x000b
>> Stream #0.8[0x28a]: Data: 0x000b
>> Stream #0.9[0x28b]: Data: 0x000b
>> Stream #0.10[0x28c]: Data: 0x000b
>> [libx264 @ 0x99fe790]using SAR=4/3
>> [libx264 @ 0x99fe790]VBV buffer (3000) > level limit (2000)
>> [libx264 @ 0x99fe790]using cpu capabilities: MMX2 SSE2 SSE3 Cache64
>> [libx264 @ 0x99fe790]profile Constrained Baseline, level 1.3
>> [libx264 @ 0x99fe790]264 - core 114 r1913 5fd3dce - H.264/MPEG-4 AVC
>> codec - Copyleft 2003-2011 - http://www.videolan.org/x264.html -
>> options: cabac=0 ref=4 deblock=1:0:0 analyse=0x1:0x111 me=umh subme=8
>> psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1
>> 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2
>> threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0
>> constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25
>> scenecut=40 intra_refresh=0 rc_lookahead=40 rc=abr mbtree=1
>> bitrate=200 ratetol=20.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4
>> vbv_maxrate=768 vbv_bufsize=3000 nal_hrd=none ip_ratio=1.41 aq=1:1.00
>
> When it is not working, ffmpeg usualy stops at that point and produces
> no more output until I kill it with ^C

And no error is printed ?

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.

> Sometimes it gets as far as emmiting the stream mappings & SDP file. I
> then get:
>

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 ?

>> Also, I'd try to decorrelate
>> depayloading/decoding/encoding/repayloading, and see which (if any)
>> crashes. To do so, use several ffmpeg processes connected by pipes,
>> and -[av]codec copy (and explicit -f values).
>
> OK, I will try that. What container format do you recommend for the
> pipes? In the past I have tried yuv4mpegpipe, but found it unstable as
> it only works for video, not audio, so I used matroska. Is that a good
> choice? Is there another container format that is good for raw streams.

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).

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.

-Alex