[mythtv-users] H264 conversion of interlaced MPEG2?

[f-myth-users at media.mit.edu]

    > Date: Wed, 06 May 2015 14:40:39 +1200
    > From: Stephen Worthington <stephen_agent at jsw.gen.nz>

    > On Tue,  5 May 2015 18:17:05 -0400 (EDT), you wrote:

    > This option is unfortunately only available after you start playing an
    > individual file and is not stored for the next time you start playing
    > it.

OK.  That also implies to me that a slight patch to my own
mythfrontend might enable me to do that automatically based
on filename or some other such thing, if I go that route.

Or I could transcode to interlaced=MBAFF and hope that mythfrontend
correctly autodetects interleaving in this case.  (Do we have any
confirmation that it does?  I don't recall actually seeing such
confirmation, but maybe I missed it.)

    > There is probably a way of creating interlaced output modes using
    > xorg.conf,

!! It had not occurred to me that X might be involved in the choice.
Maybe I knew this once.  Hmm.  (Does 14.04 even still -use- X?  Maybe. :)

    > 	       but it is likely a pretty complicated process to produce
    > the correct modelines if they are not created automatically.  If it is
    > not happening automatically, it is likely that the EDID data from your
    > CRT (TV? monitor?) is not providing any interlaced modes, and that can

There won't be any EDID, since the connection is via the S-Video port
on the card, to the S-Video port on the TV, and that's a one-way path.

    > indicate that it is, in fact, not capable of interlaced modes.  But it
    > is more likely that the manufacturers simply did not bother to put in
    > the interlaced modes as "no-one ever needs interlaced when using a
    > screen as a computer monitor".

It's a CRT television (Sony WEGA), not a screen.  Yes, I am old skool.
(If it was an LCD, I'd be deinterlacing and outputting progressive.)

    > 							  So my suggestion
    > would be that you should do the deinterlacing in the best way possible
    > as part of your transcoding process and just put up with the slowdown
    > it causes in the process, as that will give the best result.

I've been operating under the (perhaps delusional) assumption that
nvidia's best deinterlacers produce superior results to what Handbrake
can do.  Since I'm not yet set up with the hardware to test this, I've
been assuming I should defer deinterlacing until the last possible
moment---since that deinterlacing might get better in the future,
but can't if I deinterlace now and lose the information.  (And I'd
very much like to do all this transcoding in advance of the cutover
to such hardware.)

Does anyone know if this assumption is in fact correct?

    > As an aside, are all the recordings you are working on all using the
    > same interlacing (top field first or bottom field first).  If not,
    > then you will need to detect what is in the file and use the right tff
    > or bff settings.

They appear to.  I ran mediainfo over a corpus of about 1000 of them
and every single one was TFF.  They're all the from PVR-x50 cards, so
my assumption is that these cards always output in TFF order.  If I
hadn't gotten those results, I'd just incorporate detection; I already
do a ton of preprocessing anyway to detect things like errant line-21
data in-frame, handle captioning, choose some intelligent cropping, etc.