Botch Tuesday: Redmond frags video codec Last week's Patch Tuesday has reportedly gone sour, with one of patches released by Redmond causing trouble for video playback. The 34-bug patches issued on July 9 include a fix for Microsoft's WMV codec used in wmv9vcm.dll, wmvdmod.dll for WMF Runtime 9 and 9.5, and wmvdecod.dll in WMF runtime 11 and Windows Media Player 11 …
"Glad to see that Microsoft is still testing their patches before they send them out."
.
Your right, they need to test against every single one of the hundreds of thousands of bits of software, just in case 3 or 4 don't work properly.
Still I'm sure every other software maker does much more deep level testing.
Google must be mazing, testing the almost weekly updates of Chrome against every single website ever made for the last 20 years.
> Your right, they need to test against every single one of the hundreds of thousands of bits of software, just in case 3 or 4 don't work properly.
In the case of codecs you should have a test suite of audio/video that exercises all the code and all the compression/decompression elements together with any extreme cases the codecs allow for.
This is called good practice. Since this problem is occurring with newer software rather than older software it appears that its test suite doesn't test some of the newer codecs (or newer features of older codecs). So yes, this is a fail for MS.
Guess what, there is a DVD full of tests for all those edge cases. I never ran the whole set - needed a spare hard drive just to collect the results and it would have taken days just pulling the results off the mobile, for a codec that never aimed to pass all tests.
Raises suspicion that MS don't follow their own certification procedures. Wouldn't be the first time there were different rules for internal and external MS developers.
> Your right, they need to test against every single one of the hundreds of thousands of bits of software, just in case 3 or 4 don't work properly.
Than what's the point of having an industry standard ecosystem. I thought only Open Source suffered from the fragmentation 'issue` ..
To be fair, NT4 SP6a was released on 26 July 2001, if that's how far you have to go back for an update seriously breaking something, that's pretty good going. In that time I can remember a few of occasions where my Linux boxes have been knackered by updates. Mainly commercial software killed by FOSS updates, but also Ubuntu rendered unbootable by upgrades on more than one occasion and more than one hardware.
> To be fair, NT4 SP6a was released on 26 July 2001, if that's how far you have to go back for an update seriously breaking something,
To be fair, you are talking complete and utter bollocks.
KB2823324, issued this year, caused WIndows 7 to continuously reboot.
KB2753842, issued this year, broke several fonts.
KB2670838, issued this year, broke Aero.
KB2455033, issued this year, resulted in builds failed due to missing header files.
That was the results of a quick search. How many would I find with an in depth search?
In the previous month's collection we had KB2821895, which made a complete mess of things.
See: http://answers.microsoft.com/en-us/windows/forum/windows_8-windows_update/kb2821895-windows-8-x64-update-06112013-problem/eed54c3d-37c2-4965-8974-3f323b4e8e24
Title intentional BTW.
what about Google sneaking Chrome downloads and installation under the guise of Flash Player updates in Windows 7 and with IE10!
seems if you install Adobe's flash player plugin manually, you can if you read the instructions, stop the automatically defaulted (didn't the EU fine Microsoft for this nonsense) Google Chrome browser installation.
however, if you select Adobe Flash player to AUTOMATICALLY update, Google CHROME downloads and installs ITSELF (no prompts) and wipes out privacy settings (well some) exposing certain documents in key places to 'other web services' - potentially to public offerings or sync services - might just as well open your front door.
why is Google allowed to do this when Microsoft is fined to the hilt by legislators?
is Google playing GOD (or maybe thinks it is God) - the reverse of which according to my client - DOG seems more appropriate (Dog's dinner of their Windows 7 installation anyway)
Perhaps as Apple and Google like to takeover your machine, perhaps Microsoft ought to be able to RECLAIM its installations.
BIZARRE!
I know, most will just say it's Microsoft's fault for not validating this patch enough. But, I'm curious if anyone knows which secnario is occuring:
1) Is the codec just flat-out malfunctioning, dumping the top half of any video that is high enough resolution and/or high enough bitrate?
2) Is the codec incorrectly rejecting certain vallid bitstreams?
3) Are the bitstreams from these couple video editors invalid? In this case, Microsoft's patch is technically operating correctly, (hopefully) Microsoft will just have to patch the patch to make the validation lenient enough to accomodate these encoder's eccentricites. mplayer has several warning messages about detecing invalid frames or bitstreams or what have you from one or another specific encoder (which mplayer then either accepts because it's lenient, or has a specific workaround for...), this is more common than one would expect. Not that these codecs put out garbage, they'll just break some rule or other in the specification while making a video that works so long as that specific rule isn't actually enforced.
I use a Grundig TV set-top box to record United Kingdom "Freeview" video broadcasts onto USB sticks.
This plays in VLC but without a time counter displayed. It doesn't play in some other programs.
I also record "radio" broadcasts on the same device, with no video content, just supposed-to-be-MPEG2 audio.
The "radio" programs don't play in VLC. They do play in SMplayer (mplayer with a GUI), so I use that.
I used to have another set top box for recording, with a working time counter, but it broke.
And these are -standard- UK television service broadcasts. Plus whatever the set-top box does.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
