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

[Nico Sabbi]

John Donaghy wrote:

>
> It is worth stressing that dvr-ms file are a special case of ASF files
> that do not conform to the usual rules so, as in my initial patch, I
> suggest the case limb above should do something different if the file
> is a dvr-ms file rather than a standard asf file.
>
> MPlayer can play WMV files well enough (AFAIK) but it still cant play
> dvr-ms files properly. (I wrote a bit about the dvr-ms format in the
> multimedia wiki if you are interested.) In essence a video frame is
> split across multiple payloads/segments and unlike with WMV files the
> container doesn't tell you via the 'media object number' when you've
> read a complete video frame.


this explains the nonsense pts we were seeing. Why didn't you say it 
sooner? :))

>
> demux_asf.c gets round this problem by parsing the video stream (which
> is always mpeg2 for now at least) to see when it's read a complete
> frame. I borrowed the idea for this from looking at the ffmpeg code
> but the way it is implemented now in the demux_asf.c could hardly be
> considered a modular approach.  Neither was my second patch to also
> pick up the framerate from the codec but at least it worked.
>
> On the subject of the pts values picked up by demux_asf.c heres what
> happens: dvr-ms files use the 'replicated data' feature of asf for
> including extra data in a segment. The replicated data contains the
> size of the segment followed by the presentation time - demux_asf.c
> uses the presentation time of the first segment in the frame to set
> the frame's pts value. The rest of this replicated data possibly
> contains more useful information but there's no documentation on how
> to make sense of it.
>
> Regarding what we can at least parse, I added some debug statements to
> indicate what the sequence number, presentation and duration (ie asf
> packet duration time - not segment duration) do in a typical dvr-ms
> file (see below).
>
> I think this indicates that the video pts times returned by the
> demux_asf.c are useless because it appears that the presentation_time
> field isn't being used for it's intended purpose in a dvr-ms file.


so it seems


>
> I'd like to try to come up with an acceptable way to solve this issue
> in mplayer if someone is willing to mentor me. I don't want to waste
> time writing another patch that gets rejected and I dont have neither
> a good enough understanding of how mplayer works nor a knowledge of
> other container formats.


ths right solution, IMO, is to try and understand how to use those optional
fields; I can't believe the extended asf just to store mpeg2, so there
must a general way to handle that frame fragmentation. How does vlc cope
with dvr-ms/asf ?

>
> I suggest the approach should use the same technique employed by the
> lavf demuxer - ie find an way to pick up the missing information from
> the decoder when you cant get it from the demuxer but I'd like to hear
> other opinions. Nico's patch may be close to what is needed and as he
> pointed out regarding this:
>
> "on the other side delegating
> this assignment to the decoder can help to fix one of mplayer's 
> limitation:
> when playing file formats that don't have a nominal framerate  (such as
> asf, mpeg*) video.c tries to parse the video stream headers to set the
> framerate,
> an operation that it should _not_ do."
>
>
> Here's the output I refered to above that shows why the presentation
> times picked up by demux_asf.c are likely wrong for dvr-ms files (but
> probably ok for WMV files)
>
> NEW VIDEO pts=0.000
> NEW AUDIO pts=4.000
> VIDEO SEG: seq_num=2 pres_time=5 duration=6

duration 6 what? what's the unit?

> VIDEO SEG: seq_num=3 pres_time=6 duration=6
> VIDEO SEG: seq_num=3 pres_time=6 duration=4
> VIDEO SEG: seq_num=4 pres_time=7 duration=4
> VIDEO SEG: seq_num=5 pres_time=8 duration=4
> NEW VIDEO pts=8.000
> VIDEO SEG: seq_num=6 pres_time=9 duration=4
> VIDEO SEG: seq_num=7 pres_time=10 duration=4
> VIDEO SEG: seq_num=7 pres_time=10 duration=4


is the one above  the second fragment of a frame?