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

[Ivan Kalvachev]

Commited


On 7/3/05, Shachar Raindel <shacharr at gmail.com> wrote:
> 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.
> 
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>