[FFmpeg-user] problem of transcoding HD DVB-T program

Andy Furniss adf.lists at gmail.com
Tue Jul 1 16:44:55 CEST 2014

Soundwin / Andy wrote:
> Thank you very much!
> Our system is responsible for transcoding the DVB-T streams(generated
> by dvblast) into HLS format, users can access our system to watch
> videos via smart phones
> I have tried to modify the parameters which you hint, and it seems
> that it is much more stable than before.
> The transcoding server is with the Intel Core i7 4770, and it runs
> two ffmpeg instances, one dvblast instance.
> Therefore, ffmpeg can use the slow preset because the cpu loading is
> not very heavy.
> PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+
> COMMAND 1130 root       0 -20 1042296 207644   3760 S 243.0  2.6
> 110:43.29 ffmpeg 11101 root       0 -20 1173340 206592   3788 S  59.1
> 2.6  31:58.05 ffmpeg 1117 root      -2   0   12352   2592    956 S
> 6.6  0.0   1:37.03 dvblast

Ok, though I don't always trust top/ps to reliably show me when I am
running out of CPU. I would also have only altered dvblast. Though
saying that I am not a dev and have never done what you are doing, so am
really just making this up :-)

> However, it stops to transcode sometimes in random.

> In addition, it sometimes outputs " Non-monotonous DTS in output
> stream", " Delay between the first packet and last packet", " no
> picture" and the ffmpeg should be restarted to return to normal. It's
> not big problem because the shell script will rerun it
> automatically, but I still desire to solve these problem.

Can't help with that I am afraid. Recording a stream to disk so it can
be reproduced from a file you can provise would be the best way to get

> Now, I try to record the udp stream generated by dvblast to a file.
> Second, that file will be transcoded by ffmpeg in same parameters to
> determine these strange phenomenon will not happen again
> The final command and output is in the below.
> /home/andy/ffmpeg -re -f mpegts -i udp:// -c:v
> libx264 -preset slow -deinterlace -crf 23 -pix_fmt yuv420p -g 150
> -acodec libfdk_aac -b:a 128k -ac 2 -ar 44100 -loglevel debug -threads
> 0 -hls_time 5 -hls_list_size 24 -hls_wrap 100 -f hls
> /mnt/video/1/E139091DC956.m3u8
> And, the below output is ffmpeg stops to transcode.

> Applying option deinterlace (this option is deprecated, use the yadif
> filter instead) with argument 1.

Side issue, I guess yadif is bettter, though -vf yadif=0 rather than one
would probably do for phone use. If you really wanted to it's possible
to use the idet filter and more arguments for yadif to only deinterlace
what is really interlaced, though on a phone the difference may be had
to see.

> Error while decoding stream #0:1: Invalid data found when processing
> input udp:// Input/output error [libx264 @ 0x3f80b00]
> frame=140638 QP=30.21 NAL=0 Slice:B Poc:104 I:0 P:122  SKIP:1198
> size=224 bytes [libx264 @ 0x3f80b00] frame=140639 QP=25.62 NAL=2
> Slice:P Poc:112 I:29 P:428  SKIP:863  size=2915 bytes [output stream
> 0:0 @ 0x3f8aa40] EOF on sink link output stream 0:0:default. [output
> stream 0:1 @ 0x3f85b80] EOF on sink link output stream 0:1:default.
> No more output streams to write to, finishing.

I am not sure how to read this, I don't know if ffmpeg is confused by
preceeding errors, or id dvblast does something.

More information about the ffmpeg-user mailing list