[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