[MPlayer-dev-eng] [PATCH] further dvr-ms playback improvements

[John Donaghy]

> the frame time doesn't depend on the progressiveness/interlacing
> of the video, but on the framerate. For some time now, for some obscure
> reason,
> many american broadcasters have been transmitting ntsc content
> tricked (changing the repeat-* in the sequence headers) so as to make
> the video stream look like encoded ad double the framerate.
> The decoder will have to deal with this change somehow in order it to show
> it correctly on tv (that accepts 59.94 _fields_ per second, not _frames_
> per
> second as  indicated by the sequence headers), and repeat the other field
> when indicated in the stream, so what's the benefit of this abomination
> is really beyond my understanding.
> I guess you stumbled on a transmission of this kind

The transmission in question was from Australia which I believe means
it is PAL. Also when playing it with -demuxer 35 you can see that the
average frame time as picked up from the codec is .040. Also, I
received a new PAL sample today and discovered that the average frame
time in the container was 0.0333667 - which is obviously bollocks
frankly. I.e. the container based average frame time is basically
useless I'm afraid.

>
> >
> > Seeking will still not work correctly with the current version because
> > you really need the frame number after the seek to set the correct PTS
> > value based on the average frame time. I dont know if there's a way to
> > calculate it though. The alternative is to use the file based PTS as
> > the starting point after the seek and then start adding the average
> > frame time but if the first file PTS value is significantly wrong then
> > the audio and video might not be exactly in sync after a seek.
>
>
> maybe ask microsoft. Isn't there any useful information in msdn? :)

I take it that's a joke right? ;)

Seriously though, the only documentation from them that I've found is
the ASF spec and there are a number of areas where dvr-ms doesn't
conform. Such as the average frame time being the actual average frame
time - or the frame size being the actual frame size. (Yes, that's
right,  the frame size is wrong too - 720x480 in both PAL and NTSC SD,
and.... 704!!!x480 in the HD PAL sample from Australia). Apparently
the only way to get both of these rather important pieces of
information is from the codec.

Anyway, I think there's a way to at least get fairly accurate PTS
values from the container based on some form of "smoothing out"
technique applied to the PTS values in the file. Plus I can send a
patch that does a better job of marking key frames (another dvr-ms
non-compliance issue!).

That would leave the frame size, about which I currently dont know
what to do. What about a generic mechanism in mplayer for picking that
up the frame size from the codec when there's no other way?