[mythtv] commflag debugging
jwestfall at surrealistic.net
Tue Jan 3 01:09:09 EST 2006
I looked a bit more today. Alot of the rebuilding problems seem to
revolve around the changing keyframedist and how the MARK_GOP_START map
data is stored in the database. It ends up with bogus data because its
saving the map as (frame#/keyframedist -> filepos).
2006-01-02 19:28:53.638 AFD: positionMap[ 742 ] == 312602076.
2006-01-02 19:28:53.730 AFD: positionMap[ 743 ] == 313036168.
2006-01-02 19:28:53.753 AFD: HandleGopStart: Key frame distance changed from 15 to 3.
2006-01-02 19:28:53.754 AFD: positionMap[ 3718 ] == 313227364.
once its had a large jump like that it will no longer accept any new
keyframes until frame#/keyframedist is above that bad value. We end up
with huge gaps.
also the following code in AvFormatDecoder::HandleGopStart() seems bugged.
bool is_ivtv = (keyframedist == 15) || (keyframedist == 12);
positionMapType = (is_ivtv) ? MARK_GOP_START : MARK_GOP_BYFRAME;
Its triggered when there has been a keyframedist change. If the last
keyframedist before we write to the database isnt 15 or 12 (and not 1) it
will write the map as MARK_GOP_BYFRAME. MARK_GOP_BYFRAME is stored in the
database as (frame# -> filepos), but we are storing the map locally as
(frame#/keyframedist -> filepos). This causes the frontend to think there
are only frame#/keyframedist total frames in the recording.
I am curious why the MARK_GOP_START map is stored as (frame#/keyframedist
-> filepos) in the database instead of just (frame# -> filepos) like
almost all references I could find just undo the division to get the frame
number. seems like there is alot of potential for error with the
changing keyframedist when storing the data, as well as possibly using a
different/wrong keyframedist to convert the map index back to a frame #.
Daniel Chassot <daniel.chassot at gmail.com> wrote [01.02.06]:
> On 1/2/06, Jim Westfall <jwestfall at surrealistic.net> wrote:
> > This fixed the map for me and made the commflag breaks match up right when
> > playing.
> Happy that it helps. Now the question is how to fix this properly?
> Any idea???
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
More information about the mythtv-dev