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

[Torbjörn Jansson]

So how shoud this be fixed?
What woud be the best way of handling this problem in the directshow
filters?

Shoud I just ignore the seektable and kfa table if keyframeadjust_offset>0 ?
I have a thread that is started when the seektable is missing and not
streaming from mythbackend directly that takes care of scanning the file for
video sync frames and building a new seektable internaly.

The problem is that this broken seektable messes up the timestamp
calculations, so with my sample file (Antz) if I seek to a position near the
end of the file, I will have to wait 8-9 minutes afte a seek before the
video starts.

I gues I will have to consider the seektable broken if keyframeadjust is >0

> > 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
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>