[MPlayer-dev-eng] Re: [PATCH] dvr-ms fixes for pts, key frame detection and seeking
johnfdonaghy at gmail.com
Fri Feb 16 18:44:46 CET 2007
> 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
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
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
PAL/ATSC (25fps): 0X3A 00111010
ATSC progressive (29.97fps): 0X7A 01111010
^ 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
More information about the MPlayer-dev-eng