[MPlayer-dev-eng] [BUG][PATCH] Decoding of WMV3 files fail, shows only black screen

[Shachar Raindel]

On 7/3/05, Ivan Kalvachev <ikalvachev at gmail.com> wrote:
> On 7/2/05, Shachar Raindel <shacharr at gmail.com> wrote:
> > Now, Ivan, the patch you sent in your second e-mail is nice, but sadly
> > doesn't solve the bug (since, as I shown to you it is caused by the
> > fact that we use frame dropping to decide which frames are keyframes
> > and which aren't (which is absolutely crazy).
> > The correct fix is to pass the information about which frames are
> > key-frames and which aren't from the ASF demuxer to the DMO decoder,
> > but this is rather complex, and setting all of the frames to be
> > treated as key-frames seems to work fine most of the time.
> >
> >    Shachar
> 
> I think I found error in my patch ;) It need to be , !flag&2, 0);
> Anyway the SYNC flag have nothing to do with keyframes, other than
> that an keyframe could be sync point.
> The other 2 siblinc to  SYNC flags are to point PTS or duration.
> Obviously there should be no problem to have SYNC set at all times.
> So it looks the decoder needs to know some pts, no matter if it is valid or not.
> (my assumption was that zero flags mean no stream process)
> 

Straight from the MSDN docs (
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directshow/htm/dmo_input_data_buffer_flagsenumeration.asp
):
DMO_INPUT_DATA_BUFFERF_SYNCPOINT

The beginning of the data is a synchronization point.

Where sync point is defined as:

synchronization point
A media sample that can be decoded without requiring the decompressor
to examine any other samples. One example is a key frame.

=> We are doing wrong, but the codec recovers. I think that the codec
uses this flag to know where to try and start decoding from in case of
a stream error or a seek, but I am not sure. It will process the data
anyway after the first few frames was processed.

> Well if nobody objects I will apply your patch.
> 

Great.

> BTW I cannot preproduce your problem. File plays just fine even with
> cpu thottling set to 5% (well it doesn't play as it need 6 times more
> cpu, but i see image at the start, and no errors like yours);
> 

Well, my tree is bit patched-up here and there, causing it to always
try to drop the first 2 frames or so (side effect by a patch I wrote
for smooth playback speed change without distorting the sound, not
ready yet to go public...). Anyway, the current code in the DMO loader
is a total mess, and I think we all agree it must be changed somehow.

    Have fun,
    Shachar

NB: I will not be able to respond to any further e-mails until Thursday.