[MPlayer-dev-eng] Re: [PATCH] dvr-ms fixes for pts, key frame detection and seeking

[John Donaghy]

>
> At the very least I could document all that I now know about
> the format in the multi-media wiki. But how much detail should go in
there?

I'm going to document this soon but for now I have a question. I've
discovered what is probably a way to reliably determine the average frame
time as soon as you read the first video frame segment. One of the payload
extensions starts with a byte that contains various bit flags (see below for
my interpretation of this based on experimentation on a wide variety of
samples)

It seems to me that I can set the sh_video->fps in the demuxer and provide
useful pts values for most frames straight from the container - though in
some cases the container only provides pts values intermittently. However,
video.c works on the basis that you cant get the fps from the asf container.
I  think I'd need to change that to behave differently when the asf is
dvr-ms and I believe that this will allow the rest of the program to cope
with non-cronological and missing pts values but I'm not certain. Can we
change video.c to behave differently for a dvr-ms asf?

Note I'm assuming here that because this is recorded TV that we'll only see
30i/p and 25i/p. However the initial value could be adjusted once more
frames are read.

Is this a viable approach????

Any insights on the following also appreciated:
The value in question contains...
NTSC/ATSC (29.97fps):        0X4A 01001010
                             0X4B 01001011
                             0X49 01001001

PAL/ATSC (25fps):            0X3A 00111010
                             0X3B 00111011
                             0X39 00111001

ATSC progressive (29.97fps): 0X7A 01111010
                             0X7B 01111011
                             0X79 01111001
  11111111
      ^    this is new video frame marker

  ^^^^     these bits appear to indicate the framerate
           0X4 is 29.97i, 0X3 is 25i, 0X7 is 29.97p, ??=25p

      ^^^^ these bits indicate the frame type (1001 means I-frame)
           ie useful only when it's a new frame segment