Media Player Classic 6.4.6.7 (MAJ 12/10)

Une grosse mise à jour pour ce lecteur multimédia vient de sortir, plusieurs améliorations y ont été apporté...
MAJ : Petite mise à jour de la version 6.4.6.6 vers 6.4.6.7

Télécharger Media Player Classic 6.4.6.7 pour Windows 2000/XP (885 Ko) @ sourceforge.net
Télécharger Media Player Classic 6.4.6.7 pour Windows 98/Me (885 ko) @ sourceforge.net

Source: Le site officiel du projet MPC

Changelog:
The "VMR7/9 (renderless)" output can be configured to use textures and 3d rendering, this way you can avoid the "point-sampling" bug of StretchRect. Because there is this new rendering mode now, the old 2d mode won't crop the upper left side anymore to force bilinear filtering. So, if you find the image pixelated, try the 3d mode instead.
Subresync toolbar can delete entries from vobsub files without crashing! (why noone noticed this? ) Finally, this makes cutting idx/sub in mpc possible!
In dvd mode when a menu is running, the auto-hideing controls will only reappear if you move the mouse cursor at the very bottom of the screen. This helps activating buttons in that region a bit
Two new renderers: null (any) and null (uncompressed). They weren't too hard to make , but they can be useful for example if you want to save cpu cycles by turning of the video when you only want to hear the audio. "any" will connect to any media type which can be recognized as video or audio, "uncompressed" also checks for the common rgb/yuv (video), pcm/ieee (audio) types and only connects on them.
I read the bugreport about the crashing of the player when network connection get broken or the cd gets ejected. It happened because of an unhandled exception I forgot to catch. Now it won't crash at that same place for sure, but it might later somehwhere, I haven't had time to test it completely.
Just came across a strange dvd this week where the "fbi warning" clip at the beginning was playing a "little" skippy. This was the first mpeg2 stream libmpeg2 was decompressing into two picture descriptors per frame, both had one field only. Because I had no idea about what to do with the second one or how to handle it, the dshow decoder only summed up the time length of the first picture (time per frame * number of fields / 2). Basically this means every frame lasted half long and the image was slowly falling behind then catching up continuously.
Speeded up built-in avi splitter's interleaving verifier a bit (this pops up that new error dialog occasionally telling you sequential playback is not possible). The scanning time for a regular 700MB avi decreased from 200ms to 50ms on my cpu.
After desktop resolution switches the alternative renderers will recover much better now.
Lastly, the biggest news at the end, hoping noone will notice it (hehe): Smacker/Bink playback support (shh, don't tell anyone), now you can view old and new game movies in mpc! Of course there is no decoder inside (it would cost a fortune for me), so smackw32.dll/binkw32.dll has to be put next to mplayerc.exe to make it work. The larger the dll the higher the chance it will be able to open recent smk/bik files (hint: up-to-date smackw32.dll: ~150k, binkw32.dll: ~360k). The just released halo (pc) game has the newest dll I could find for bink at the moment, but there are many others to test on p2p networks like edonkey. A newer smackw32.dll is a little harder to find for v4 smacker files (which the current "rad video tools" will produce) if you are browsing your old game collection, but I could find a usable dll with emule just as easy. Also, mpc will even open videos from self-playing exes, but only the first one. If there are many packed into one exe, or if the container file is a large, merged data file of a game, then get a hex editor (e.g. hex workshop) and extract the videos one-by-one (it was fun to rewatch a few ff8 videos this way, they were still amazing . Smacker usually starts with SMKn (n: 1-4), while Bink starts with BIKh or BIKi and the second DWORD (4 bytes) equals to the total length - 8. Sadly, Smacker doesn't seem to have a length field , for that you have to search the next SMK.. header, or extract it until the end of the file. Another bad thing about Smacker and Bink: they rarely have keyframes, very-very rare. For this reason Smacker will show messed up picture after a seek, but Bink will correctly decompress every previous since the last keyframe, which of course will go painfully slow for a large file (just try it on that 100MB+ half-life 2 video .

meilleur lecteur RV9 !