[mythtv-users] H264 conversion of interlaced MPEG2?

Dave MythTV dave.mythtv at gmail.com
Mon May 4 23:50:49 UTC 2015


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20150504/a14cfd20/attachment.html>


More information about the mythtv-users mailing list