<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 4, 2015 at 5:11 PM, Mike Perkins <span dir="ltr"><<a href="mailto:mikep@randomtraveller.org.uk" target="_blank">mikep@randomtraveller.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On 04/05/15 22:30, Dave MythTV wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sun, May 3, 2015 at 6:22 PM, Michael Stucky <<a href="mailto:mike@stucky.us" target="_blank">mike@stucky.us</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sun, May 3, 2015 at 5:46 PM, Dave MythTV <<a href="mailto:dave.mythtv@gmail.com" target="_blank">dave.mythtv@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello everyone.<br>
<br>
I'm running some tests, preparing to reconfigure my backend to transcode<br>
certain shows from US-broadcast ATSC MPEG2 to H264 for hardware accelerated<br>
playback on our various portable devices. In doing this, I've been<br>
experimenting with Mike Stucky's user job script:<br>
<a href="https://www.mythtv.org/wiki/Transcode_Mpeg2_to_H264" target="_blank">https://www.mythtv.org/wiki/Transcode_Mpeg2_to_H264</a><br>
<br>
<br>
However, I've hit a snag... If I run this script on an MPEG2 file with<br>
interlaced SD content, MythTV no longer recognizes the resulting H264 file<br>
as being interlaced, and playback in the MythTV frontend shows interlacing<br>
artifacts.<br>
<br>
I know I could modify Mike's script to specifically deinterlace the<br>
content before or during the H264 conversion... but I didn't think this<br>
would have been necessary? Shouldn't it be possible to convert interlaced<br>
MPEG2 to interlaced H264, and continue using the frontend's deinterlacer?<br>
<br>
<br>
Additional information:<br>
'mediainfo' detects the input MPEG2 file as being interlaced, but shows<br>
the output H264 file as being progressive scan. So I think this might be<br>
an issue with the ffmpeg conversion flagging (or encoding) the<br>
non-deinterlaced output as progressive... and not an issue with MythTV's<br>
player?<br>
<br>
<br>
Thanks for the help.<br>
- Dave<br>
<br>
<br>
</blockquote>
I have recently discovered this same behavior and I think you are right<br>
about it being an ffmpeg issue. It looks like ffmpeg automatically<br>
deinterlaces SD content, so I have modified the "transcode" section to do a<br>
better job of deinterlacing (this has the added benefit of allowing ffmpeg<br>
to do a better job of compressing), this appears to be working for me, at<br>
least for SD content:<br>
<br>
task = System(path=transcoder, db=db)<br>
try:<br>
output = task('-i "%s"' % tmpfile,<br>
'-filter:v yadif=1',<br>
'-sws_flags spline',<br>
'-r 60000/1001',<br>
'-c:v libx264',<br>
'-preset:v slow',<br>
'-crf:v 18',<br>
'-threads 0',<br>
'-c:a copy',<br>
'-metadata:s:a:0',<br>
'language="eng"',<br>
'"%s"' % outfile,<br>
'2> /dev/null')<br>
<br>
If you find that this helps let me know and I will update the script on<br>
the wiki.<br>
<br>
Mike<br>
<br>
<br>
</blockquote>
<br>
Thanks Mike! I'll do some experimenting with your changes this evening.<br>
<br>
A couple questions:<br>
* What made you select 'spline' as the scaler method? (just curious)<br>
* Did you have a frame rate issue that required forcing the output frame<br>
rate explicitly?<br>
<br>
Also, I think there may be an issue with the yadif filter...<br>
The FFmpeg docs state that the third yadif parameter (deint) controls which<br>
frames to deinterlace. The default is "all", but I've been reading that<br>
applying yadif on **progressive** source content will negatively impact the<br>
quality.<br>
(example: <a href="https://ffmpeg.org/pipermail/ffmpeg-user/2014-May/021412.html" target="_blank">https://ffmpeg.org/pipermail/ffmpeg-user/2014-May/021412.html</a>)<br>
<br>
So I think to make your script flexible for both interlaced and progressive<br>
source content, we would need to either call yadif as yadif=1:-1:1 (and<br>
hope that the frames are properly flagged?), or do some sort of other<br>
method (idet filter?) to detect the interlacing and convert as necessary?<br>
There is a solution in the message linked above using idet, but the author<br>
(Nick) reports "mixed success"... not sure what to make of that.<br>
<br>
(Other links for reference...)<br>
<a href="https://ffmpeg.org/ffmpeg-filters.html#yadif-1" target="_blank">https://ffmpeg.org/ffmpeg-filters.html#yadif-1</a><br>
<a href="https://ffmpeg.org/ffmpeg-filters.html#idet" target="_blank">https://ffmpeg.org/ffmpeg-filters.html#idet</a><br>
<br>
</blockquote></div></div>
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.<br>
<br>
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.<span><font color="#888888"><br>
<br>
-- <br>
<br>
Mike Perkins<br>
</font></span></blockquote></div><br><br></div><div class="gmail_extra">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... <br><br></div><div class="gmail_extra">- Dave<br></div></div>