[mythtv-users] H264 conversion of interlaced MPEG2?

[Mike Perkins]

On 12/05/15 02:49, Michael Stucky wrote:
> On May 11, 2015 4:17 PM, "Jay Foster" <jayf0ster at roadrunner.com> wrote:
>>
>> On 5/11/2015 12:46 PM, Michael Stucky wrote:
>>>
> <deletia>
>>> Sorry for the delay, it was a busy weekend+... I am not an ffmpeg expert
> so all the syntax came either from the original shell script or searches
> for a better way to deinterlace. But I have done some additional searching
> and testing have updated my script on the wiki accordingly.
>>>
>>> "yadif=1" has become "yadif=0:-1:1" (mode 0 = one frame out for one
> frame in, parity -1 = autodetect, and deint 1 = only deinterlace frames
> marked as interlaced). "sws_flags spline" is removed (only applies when
> scaling content?). "-r 60000/1001" is removed (this actually caused every
> frame to be duplicated for interlaced content). "threads 0" is removed (the
> h264 encoder uses all available threads by default). "-c:a copy" replaced
> with "-strict -2" to use the internal AAC encoder.
>>>
>>> This works and produces good quality output for all my content, 1080i,
> 720p, and 480i all OTA to HDHomerun tuners.
>>>
>>
>> I took a look at the script on the wiki and had a question.  Does this
> break commercial skipping?  The script does not appear to reschedule a
> commflag job after the transcoding.
>>
>
> The script was designed to prepare a recording for export to the Video
> Library where it can be played by different players/devices (vlc, mplayer,
> android, ios, etc.). As such commercial skipping wasn't a consideration.
> The script will remove a cutlist if it exists (so
> leaders/trailers/commercials should all be automatically removed before the
> transcoding takes place).
>
> If it is helpful, please take the script and modify it to do what you want
> it to and create a new wiki page for your script so we all can benefit from
> it!
>
A tricky one. Normally you'd edit the file - or commflag it - before processing 
so you only processed the parts you wanted.

However, with the likely changes in the stream when commercial / trailers / etc 
interrupt the program commflagging is not as perfect as it was in the analog days.

Preprocessing first into a uniform stream does at least give the commflag 
process a fighting chance, though whether you need to post-process to rebuild 
seek references (I didn't say seek tables, I know they're not used with h264) is 
an interesting question.

-- 

Mike Perkins