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

[Shachar Raindel]

On 7/5/05, Ivan Kalvachev <ikalvachev at gmail.com> wrote:
> Commited
> 
> 
Thanks
> 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
> >
> 
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>