>
>Minor addendums...
>
>> By: Adam Albright In: microsoft.public.windows.vista.general
>
>> The point is Media Player won't accept or stumbles on some codecs even if
>> they're installed on your system.
>
>There are four different common interfaces a 'normal' codec might support
>(ACM/ICM/VFW, DShow, WMFSDK DMO, MF TF). WMP supports all of those. You
>can have locked codecs too, but we'll ignore those since I doubt that anyone
>else here will ever see or run into those.
>
>If a codec isn't working, it's typically a problem with the codec. There's
>little ability (typically) for it to "stumble" or not accept a codec, given
>that it's pretty much the reference standard to test a correct codec
>implementation.
>
>> Now here's the fun part. What did Media Player just say? It acquired the
>> codec. So you would think if I click on the file a second time it would
>> just
>> start to play right? No, it again says acquiring codec, another 20 seconds
>> goes by, then again it plays just the video portion. If I repeat this
>> exercise in stupidty ten times then Meida Player will say "acquiring
>> codec"
>> 10 times each time again going out on the web looking for another copy of
>> the
>> same codec it already obviously has and again saying it is "installing"
>> it,
>> but never is it able to play the audio portion.
>
>This has been the case since codec download / codec rollover was first
>implemented. If render fails against the first codec, that'll rollover to
>the next codec ("codec acquired") and then try again.
>
>> Now the funniest part of all is I can open this video file in any one of
>> my
>> other players and it plays fine, BOTH the audio and video tracks, and no
>> player except for brain dead Media Player needs to acquire any new codec
>> off
>> the web.
>
>Apples to oranges, given that it's doubtful that they support the full set
>of codec interfaces that WMP supports. I'll gladly pay $2 if they support
>DShow filters and roll over to VFW in case of failure. =)
>
>More accurate rephrase: "No player except for Media Player tries using the
>codec
>that you installed..."
>
>> Lets have even more fun. I open the example file in GSpot. (version
>> 2.70a)Surprise it isn't a AVI like the file pretends, it is a divX file.
>
>Is it RIFF AVI, or is it .divx ?
>
http://en.wikipedia.org/wiki/Divx#DivX_Media_Format_.28DMF.29>
>> Since AVI is a wrapper, Media Player should be smart enough to read the
>> file
>> header like all my other players do before trying to play or jumping to
>> conclusions it is a avi file. But alas, we're talking Microsoft software,
>> which we all know isn't too smart.
>
>riffwalk -f0 1048878.divx
>00000000 RIFF (0173EB0E) 'AVI '
>0000000C LIST (00000256) 'hdrl'
>00000018 avih (00000038)
> TotalFrames : 4284
> Streams : 2
> InitialFrames: 0
> MaxBytes : 0
> BufferSize : 0
> uSecPerFrame : 40000
> Rate : 25.000 fps
> Size : (528, 352)
> Flags : 0x00000110
> AVIF_HASINDEX
> AVIF_ISINTERLEAVED
>
>leading 8 character header sample: "RIFF....AVI."
>
>This is pretty deliberately an attempt to play back in non-'.divx' aware
>applications while leveraging off of their background in AVI.
>
>So, as far as I'm aware, WMP is doing the right thing here.
>
>> Lets look deeper. According to Gspot my system has no less then 6 codecs
>> that can play the video stream in this file. Since Media Player did play
>> the
>> video portion it obviously used one of these, but apparently can't
>> remember
>> since it keeps going out to the web to get a fresh copy every time I ask
>> Media Player to play it.
>
>Yeah, it doesn't devalidate the broken codec because the notion that you
>would have two codecs on your system, one of them broken, is pretty awful
>and has been pretty unsupported since the system began ... ten years ago.
>
>Codec rollover should generally never ever ever ever come in handy. It is
>coming in handy here because of problems generally outside of WMP's control.
>
>> So does my test file have corruption in it? Yes! The GOP visual shows
>> several flaws or corrupt frames, all happen to be I frames. This is likely
>> what is preventing Media Player from playing the audio portion, since the
>> first frame in this video is one that happens to be corrupt. Apparently
>> Media Player was able to get over the hump and play the video track
>> anyway,
>
>This could be why the first codec (presumably a filter) rejected the
>content, causing the rollover. If the fixed file could be rendered in
>WMP/GSpot, that'd be interesting. Presumably then the vendor of the first
>codec might want to think about how to handle corrupt frames. Although
>that's a can of worms anyways.
>
>> but failed to play the audio for this reason, while other players
>> apparently
>> were smart enough to skip over the file corruption.
>
>Skipping over file corruption is actually an extremely interesting action.
>You'll note that tendency in Vista is to stop allowing any sort of
>corruption: it's a really bad plan, generally. Maybe you can get away with
>"skipping over it", but that's not an action that Microsoft as a major
>corporation can really get behind. That's the action of a garage company
>that can afford to play it a little more fast and loose. =)
>
>-Zach