[mythtv] Keyframe adjust table (posibel bug(s))

[Geoffrey Hausheer]

On Sun, 4 Jan 2004 18:34:33 +0100, "Torbjörn Jansson
torbjorn.jansson-at-mbox200.swipnet.se |mythtv/1.0-Allow|"
<0gw0hqvx8y0t at sneakemail.com> said:
> I have been looking into the keyframe adjust table in nuv files so i can
> implement it in the directshow filters.
> 
> I have found some things i find a bit strange.
> The function NuppelDecoder::GetKeyIndex does it work?
It used to.

> Maybe i'm missing
> something but the keyframe adjust table is keyframe numbers and not frame
> numbers, so how can "if (keyiter.key() == curFrame)" work if curFrame is
> a
> frame number and keyiter.key() is a keyframe number?

Yep, it looks broken.  As far as I can tell it has been broken for quite
a long time.  At least as far back as adding FIFO support, and maybe as
far back as when I first wrote it.  Interesteing that it's never caused
me any issues.

> 
> After i have transcoded a file, the offsets in the seektable isn't
> pointing
> to video sync frames any longer, they are a few frameheaders earlier than
> the video sync frame.

That's not good

> 
> Is there any tool that can fix a broken seektable in a nuv file incase
> you
> terminated the backend during a recording? I tried mythcommflag but that
> didn't work.

you probably need to hack nuppeldecoder to ignore the kfa 'K' frame
during openFile.  But I haven't actually tried it.

> 
> When a file is transcoded the data in recordedmarkup table for that file
> is
> removed, i can understand that, but when is it rebuilt?

It's not.  The transcoded file is gauranteed to contain a seek table, so
the one in the database isn't needed anymore.

It sounds like I need to go back and check this stuff again.  Honestly, I
don't use the MPEG4->MPE4 commerical cutting stuff often, so it has been
tested (by me) a lot less throuhly than the MPEG2->MPEG4 stuff which I
use every day (though I've been having some problems since I upgraded
mythtv yesterday)

Also, I am considering trashing the KFA table and using micro-jumps; that
is just specify a short (1-30) frame jump instead of moving the
key-frames around.  Since this is likely the way we'll need to deal with
MPEG2, it probably makes sense to be consistant.  The cleanest solution
would probably be to have a converter than can replace KFA tables with
the micro-jump table, so we don't need to keep the KFA support code
around.  Anyhow, none of that helps you right now, and I'm not sure I'll
even do it (I'm planning on converting to an all MPEG2 setup, which would
let me save shows to DVD easily in the future, which means not much
further development by me on the nuv side of things).

.Geoff