[mythtv-users] H264 conversion of interlaced MPEG2?

[Michael Stucky]

On Tue, May 12, 2015 at 6:29 AM, John Pilkington <J.Pilk at tesco.net> wrote:

> On 12/05/15 10:17, Mike Perkins wrote:
>
>> 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.
>>
>>
> But assuming that Mike S's updated script does what his comment says (and
> if it doesn't apply the cutlist), surely
> " "yadif=0:-1:1" (mode 0 = one frame out for one frame in,"
> implies that a surviving cutlist would retain its original validity?
>
> I'm afraid I haven't tested this :-)
>
>
I do not use commercial flagging for all of the reasons discussed many
times here. I manually edit my recordings marking everything that I do not
want to keep leaders/trailers/commercials/etc.

The script does two separate things with the recordings that I run it
against, first it checks for a cutlist and removes it if it exists using
"mythtranscode", second if uses "ffmpeg" to transcode from mpeg2 to h264.
So by the time ffmpeg gets the file it no longer contains a cutlist, yadif
mode 0 means one frame into the deinterlacer and one frame out of the
deinterlacer as opposed to yadif mode 1 which outputs one frame for each
field input into the deinterlacer. Interlaced content has 2 fields
interlaced together to make one frame, this has, IMHO, the negative effect
of creating two virtually identical frames of output for each frame input.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20150512/c578fd58/attachment.html>