[mythtv-users] H264 conversion of interlaced MPEG2?

Mike Perkins mikep at randomtraveller.org.uk
Tue May 5 08:44:59 UTC 2015


On 05/05/15 00:50, Dave MythTV wrote:
> On Mon, May 4, 2015 at 5:11 PM, Mike Perkins <mikep at randomtraveller.org.uk>
> wrote:
>
>> On 04/05/15 22:30, Dave MythTV wrote:
>>
>>> On Sun, May 3, 2015 at 6:22 PM, Michael Stucky <mike at stucky.us> wrote:
>>>
>>>   On Sun, May 3, 2015 at 5:46 PM, Dave MythTV <dave.mythtv at gmail.com>
>>>> wrote:
>>>>
>>>>   Hello everyone.
>>>>>
>>>>> I'm running some tests, preparing to reconfigure my backend to transcode
>>>>> certain shows from US-broadcast ATSC MPEG2 to H264 for hardware
>>>>> accelerated
>>>>> playback on our various portable devices.  In doing this, I've been
>>>>> experimenting with Mike Stucky's user job script:
>>>>> https://www.mythtv.org/wiki/Transcode_Mpeg2_to_H264
>>>>>
>>>>>
>>>>> However, I've hit a snag...  If I run this script on an MPEG2 file with
>>>>> interlaced SD content, MythTV no longer recognizes the resulting H264
>>>>> file
>>>>> as being interlaced, and playback in the MythTV frontend shows
>>>>> interlacing
>>>>> artifacts.
>>>>>
>>>>> I know I could modify Mike's script to specifically deinterlace the
>>>>> content before or during the H264 conversion... but I didn't think this
>>>>> would have been necessary?   Shouldn't it be possible to convert
>>>>> interlaced
>>>>> MPEG2 to interlaced H264, and continue using the frontend's
>>>>> deinterlacer?
>>>>>
>>>>>
>>>>> Additional information:
>>>>> 'mediainfo' detects the input MPEG2 file as being interlaced, but shows
>>>>> the output H264 file as being progressive scan.  So I think this might
>>>>> be
>>>>> an issue with the ffmpeg conversion flagging (or encoding) the
>>>>> non-deinterlaced output as progressive... and not an issue with MythTV's
>>>>> player?
>>>>>
>>>>>
>>>>> Thanks for the help.
>>>>> - Dave
>>>>>
>>>>>
>>>>>   I have recently discovered this same behavior and I think you are right
>>>> about it being an ffmpeg issue. It looks like ffmpeg automatically
>>>> deinterlaces SD content, so I have modified the "transcode" section to
>>>> do a
>>>> better job of deinterlacing (this has the added benefit of allowing
>>>> ffmpeg
>>>> to do a better job of compressing), this appears to be working for me, at
>>>> least for SD content:
>>>>
>>>>        task = System(path=transcoder, db=db)
>>>>        try:
>>>>               output = task('-i "%s"' % tmpfile,
>>>>                             '-filter:v yadif=1',
>>>>                             '-sws_flags spline',
>>>>                             '-r 60000/1001',
>>>>                             '-c:v libx264',
>>>>                             '-preset:v slow',
>>>>                             '-crf:v 18',
>>>>                             '-threads 0',
>>>>                             '-c:a copy',
>>>>                             '-metadata:s:a:0',
>>>>                             'language="eng"',
>>>>                             '"%s"' % outfile,
>>>>                             '2> /dev/null')
>>>>
>>>> If you find that this helps let me know and I will update the script on
>>>> the wiki.
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>> Thanks Mike!  I'll do some experimenting with your changes this evening.
>>>
>>> A couple questions:
>>> * What made you select 'spline' as the scaler method?  (just curious)
>>> * Did you have a frame rate issue that required forcing the output frame
>>> rate explicitly?
>>>
>>> Also, I think there may be an issue with the yadif filter...
>>> The FFmpeg docs state that the third yadif parameter (deint) controls
>>> which
>>> frames to deinterlace.  The default is "all", but I've been reading that
>>> applying yadif on **progressive** source content will negatively impact
>>> the
>>> quality.
>>> (example: https://ffmpeg.org/pipermail/ffmpeg-user/2014-May/021412.html)
>>>
>>> So I think to make your script flexible for both interlaced and
>>> progressive
>>> source content, we would need to either call yadif as yadif=1:-1:1  (and
>>> hope that the frames are properly flagged?), or do some sort of other
>>> method (idet filter?) to detect the interlacing and convert as necessary?
>>> There is a solution in the message linked above using idet, but the author
>>> (Nick) reports "mixed success"...  not sure what to make of that.
>>>
>>> (Other links for reference...)
>>> https://ffmpeg.org/ffmpeg-filters.html#yadif-1
>>> https://ffmpeg.org/ffmpeg-filters.html#idet
>>>
>>>   To your frame rate question: Digital transmissions can change frame
>> rates all the time, along with almost all other parameters. Typically this
>> will happen at advert breaks where the commercials are formatted
>> differently than the program - and each commercial may have its own
>> formatting. Trailers can also be different.
>>
>> Varying frame rates can break seek tables so it is better, if you are
>> processing the file anyway, to force a consistent frame rate on the output.
>>
>> --
>>
>> Mike Perkins
>>
>
>
> But a frame rate conversion is going to have a negative impact on picture
> quality.   Everything else in Mike Stucky's script is optimized for quality
> ('slow' preset and crf of 18), so I doubt he would want to do that.   If
> broken seektables are the problem, I would think it would be a far better
> solution to just rebuild the seektable(s) if necessary after the conversion
> as part of the script...
>
> - Dave
>
Not so simple. Some programs assume a constant frame rate calculated on what 
they find at the beginning of the file. If they use this rate further down the 
file, where there could likely be more frames per second - based on the premise 
that commercials / trailers will be at lower rates than the program - you end up 
with a seek to the wrong place, or maybe beyond what the seek mechanism thinks 
is the end of the file.

Constant frame rates no longer exist with digital transmission. In the 'old' 
analog days, your tuner card encoded the input with a fixed frame rate you 
defined and you knew what to expect from the whole file. These days digital 
tuners just accept what gets thrown at them, strip out the bits you are 
interested in and dump it on your disk.

Add in to that the fact that commercials, trailers and even different parts of 
the same program may be broadcast with different frame rates, bit rates and even 
audio encodings and the job of myth to make sense of it all becomes 
significantly harder.

-- 

Mike Perkins



More information about the mythtv-users mailing list