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

[Andy Furniss]

Soundwin / Andy wrote:
> Thank you,
>
> Now I modify the command to the below. (remove the minrate and
> maxrate, keep crf, remove -s 640x480, output to m3u8 format)
>
> /home/soundwin/ffmpeg -re -f mpegts -i udp://127.0.0.1:50000 -c:v
> libx264 -preset slow -crf 23 -b:v 1000k -bufsize 1000k -pix_fmt
> yuv420p -g 50 -acodec libvo_aacenc -b:a 128k -ac 2 -ar 44100
> -loglevel debug -hls_time 5 -hls_wrap 100 -f hls
> /mnt/video/1/E139091DC956.m3u8
>
> Is this command has other problems?

I don't know really but I thought crf was variable bitrate any you now
say -b:v 1000k which if it works is quite low for full res HD. I also
don't know whether the buffer size is sane or not. Preset slow will use
more cpu which could be an issue.

There is still a slight issue with progressive vs interlaced in that
x264 should probably be be set up differently for weave.

>
> BTW, sometimes the output stream appears only has video or audio.
> Sorry I don't keep the complete ffmpeg output, the reason is that
> there is a shell script will restart ffmpeg when it outputs specific
>  string. (Non-monotonous DTS in output stream, Delay between the
> first packet and last packet, no picture) I will try to keep all the
> output logs.

You could still be loosing buffers I suppose. Perhaps you could try
-threads X where X is one less that how many cores you have so that
there is spare for dvblast/v4l. Alternately you could try renice to give
more prio to dvblast. I have no idea if either will help, just thinking
of things to try.

>
> The three specific string outputted from ffmpeg which I mention
> before will be occurred in random time(sometimes < 30mins, sometimes
>> 18hrs). If occurred, the monitor shell script will restart that
> ffmpeg. In the same time, the UDP input stream looks normal from VLC
>  player. Restarting the ffmpeg usually solves the problem, but
> sometimes the computer needs to be rebooted or the ffmpeg will always
> failed to generate normal output stream. Can the ffmpeg transcode the
> input stream normally all year? (7*24*365)

I don't know - the problem with broadcast transport streams is there are
likely to be errors or gaps from missed reads caused by cpu load from
transcoding in them that can trip up encoders.

I don't know what your requirements/constraints are, but for home TV use
I wouldn't consider transcoding live - far easier just to stream the ts
with something like tvheadend and you get a pvr + epg + browser
interface thrown in too.