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

[Soundwin / Andy]

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?

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.

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)

-----Original Message-----
From: ffmpeg-user-bounces at ffmpeg.org [mailto:ffmpeg-user-bounces at ffmpeg.org]
On Behalf Of Andy Furniss
Sent: Wednesday, June 18, 2014 1:01 AM
To: FFmpeg user questions
Subject: Re: [FFmpeg-user] problem of transcoding HD DVB-T program

Soundwin / Andy wrote:
> Thanks a lot.
>
>
>
> I modify the DVR_BUFFER_SIZE of drivers/media/dvb/dvb-core/dmxdev.h
> to original (10*188*1024) due to dvb will drop the whole buffer if it
> fills.
>
>
>
> I found that using dvblast can prevent this issue, including "Value
> too large for defined data type" problem which I doesn't mention
> before.

That's good, though looking at you command -

home/andy/ffmpeg -f mpegts -i pipe:0 -c:v libx264 -preset medium -crf 23
-bufsize 3000K -minrate 1200k -maxrate 1200k -pix_fmt yuv420p -g 50 -s
1024x768 -acodec libmp3lame -b:a 128k -ac 2 -ar 44100 -f mpegts
udp://225.0.6.4:50000 &

I don't think crf and fixed rate are supposed to go together.

The biggest issue I think you will have is the resizing. If the content
is interlaced then you will be scaling down weave and it won't look
good, or be able to be deinterlaced.

Of course a lot of broadcast is progressive, so that will be OK.

It is possible to detect and control a de-interlacer before the recode,
but it will add more cpu usage.

You could do an interlace aware scale - but I don't know how much that
would mess  up progressive, or if it's possible to change the scale on
the fly depending on the content.

I am not sure there are easy solutions if you have to scale down and are
short of cpu.





_______________________________________________
ffmpeg-user mailing list
ffmpeg-user at ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user