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

[Ivan Kalvachev]

On 7/2/05, Ivan Kalvachev <ikalvachev at gmail.com> wrote:
> On 7/2/05, Shachar Raindel <shacharr at gmail.com> wrote:
> > Hi,
> >  I have been having a problem with decoding WMV3 files, getting the
> > following (interesting) messages (sorry, long post to show what is
> > going on):
> > <snip loads of not so interesting startup messages>
> > Playing ******.wmv.
> > ASF file format detected.
> > VIDEO:  [WMV3]  320x240  24bpp  1000.000 fps    0.0 kbps ( 0.0 kbyte/s)
> > Clip info:
> >  name:
> >  author:
> >  copyright:
> >  comments:
> > ==========================================================================
> > Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
> > AUDIO: 44100 Hz, 2 ch, s16le, 48.0 kbit/3.40% (ratio: 6003->176400)
> > Selected audio codec: [ffwmav2] afm:ffmpeg (DivX audio v2 (FFmpeg))
> > ==========================================================================
> > vo: X11 running at 1024x768 with depth 24 and 32 bpp (":0.0" => local display)
> > ==========================================================================
> > Opening video decoder: [dmo] DMO video codecs
> > DMO dll supports VO Optimizations 0 1
> > DMO dll might use previous sample when requested
> > GetOutput r=0x0   size:230400  align:1
> > StreamCount r=0x0  1  1
> > Decoder supports the following formats: YV12 YUY2 UYVY YVYU RGB8
> > RGB555 RGB565 RGB24 RGB32
> > Decoder is capable of YUV output (flags 0x1b)
> > VDec: vo config request - 320 x 240 (preferred csp: Packed YUY2)
> > VDec: using Planar YV12 as output csp (no 0)
> > Movie-Aspect is undefined - no prescaling applied.
> > VO: [xv] 320x240 => 320x240 Planar YV12
> > Selected video codec: [wmv9dmo] vfm:dmo (Windows Media Video 9 DMO)
> > ==========================================================================
> > Building audio filter chain for 44100Hz/2ch/s16le -> 0Hz/0ch/??...
> > [libaf] setting tempo 1.000000
> > alsa-init: 1 soundcard found, using: default
> > alsa: 44100 Hz/2 channels/4 bpf/32768 bytes buffer/Signed 16 bit Little Endian
> > AO: [alsa] 44100Hz 2ch s16le (2 bps)
> > Building audio filter chain for 44100Hz/2ch/s16le -> 44100Hz/2ch/s16le...
> > [libaf] setting tempo 1.000000
> > Starting playback...
> > ProcessInputError  FALSE ?? (keyframe: 0)
> > ProcessInputError  FALSE ?? (keyframe: 0)  1/  1 ??% ??% ??,?% 1 0 98%
> > ProcessInputError  r:0x80004005=-2147467259 (keyframe: 1)??,?% 2 0 98%
> > ProcessInputError  r:0x80004005=-2147467259 (keyframe: 0)??,?% 2 0 98%
> > ProcessInputError  r:0x80004005=-2147467259 (keyframe: 1)??,?% 3 0 98%
> > ProcessInputError  r:0x80004005=-2147467259 (keyframe: 1)??,?% 3 0 98%
> > ProcessInputError  r:0x80004005=-2147467259 (keyframe: 1)??,?% 3 0 98%
> > ProcessInputError  r:0x80004005=-2147467259 (keyframe: 1)??,?% 3 0 98%
> > ProcessInputError  r:0x80004005=-2147467259 (keyframe: 1)??,?% 3 0 98%
> > <snip tons and tons of these messages>
> >
> > Audio was playing-back great, video remained a black screen.
> > What is more interesting was that seeking to the beginning of the file
> > after few seconds of playback revived the video stream. After some
> > messing around with DMO_VideoDecoder.c, I found out the reason: The
> > first 2 calls to DMO_VideoDecoder_DecodeInternal (and therefore to the
> > ProcessInput method of the DMO itself) are done with is_keyframe = 0
> > (which should actually be called should_drop, and is actually rather
> > redundant), since mplayer wants to drop the first frame as it is
> > lagging behind the audio (it gets more audio in the beginning), and
> > confuses the codec internal state, as it misses the first sync
> > signals.
> >
> > Removing the dependency in the phony flag of is_keyframe solved the
> > problem, and now my WMV files play great.
> >
> > Note that this is just a work-around, not a correct fix as the DMO now
> > thinks that any bit we feed it with is a sync point (which is of
> > course wrong and buggy). Someone who knows what is going on in the
> > rest of this mess should fix it to provide useful information to the
> > codec (probably extracted from the carrying ASF container).
> >
> >    Shachar
> 
> Hi,
> 
> (the usual declaimer, i'm not win32 loader & dmo expert).
> 
> It looks like DMO interface have 2 phases.
> Phase1 - feed data into the decoder.
> Phase2 - get ready data from the decoder.
> 
> To be more confusing we do hardframedrop for all small framedrops on phase1.
> 
> Probably the right way to make an soft drop is to use
> DMO_PROCESS_OUTPUT_DISCARD_WHEN_NO_BUFFER flag on
> ProcessOutput() and not supply the output buffer, as described here:
> http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c/directx/htm/imediaobjectprocessoutput.asp
>


Try this patch

 Ivan Kalvachev
  iive
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmo_framedrop.patch
Type: application/octet-stream
Size: 402 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20050702/274aaba3/attachment.obj>