Why do some versions of Flash Player 9 work on YouTube while other ver

[rloew]

While this model (= working hypotesis) seems to explain all the facts considered, it's still just a guess, at this point. A detailed study of the machine codes for the SSE instructions is required, to see which can be misunderstood for MMX machine codes, leading to which results. Then those instructions would have to be sought out in the actual code and patched by hand (= cold code patching) instead of by warm code patching (i.e.: execution time patching, which is done by RLoew's patcher). Once all "bad behaved" SSE instructions were dealt with, by using RLoew's patcher with the cleansed Flash 9.0.280.0, one should be able to play OK every video clip in YouTube and elsewhere. So this model is testable, but, at this point in time, I have not enough information to truly evaluate how time consuming the cold code patching phase would be, nor whether are there feasible patches for everyone of the "bad behaved" SSE instructions, much less how many different "bad behaved" SSE instructions do exist, and of those, how many different instructions actually exist in the code of Flash 280. Moreover, how does a processor actually behave when faced with instructions it wasn't designed to understand is, of course, undocumented behavior, which requires testing to find out. And this is why I'm somewhat despondent we'll ever solve this problem effectively just by software.

I suspect it has to do with the SSE Instructions that use the F2 or F3 Prefix to distinguish them from other Instructions.

These originally were the REPZ/REPNZ Prefixes for String Instructions.

Processors generally ignore these prefixes when applied to unexpected Instructions rather than Fault them. So older ones will use the unprefixed Instructions instead.

An Instruction Boundary Aware scan would be needed to find them. Patching them depends on what actually exists in the code. The three documented problems were easy to Patch.

The Pentium III tests will help narrow things down.

@jds: It is a bit premature to publish a Patch that has not been proven to work.

[larryb123456]

Many thanks, dencorso, for responding:

Out of respect for your hard work, I'll apply myself some more to this problem...

The main reason for this *short* message is to express my gratitude to you for sticking with this issue rather than simply "blowing off" my "thoughts"(?), "logic"(?) and **hard** work ! !

That would have been so easy to do (probably 9.9 out of 10 people would simply have ignored me and my "half-baked" comments).

And, I so **appreciate** your continued "rephrasing" and adding more info a tidbit at a time (like you did in this post with the machine codes for the SSE instructions) so that I can continue to *learn*.

Indeed, this has been one fascinating mental journey for me. Thanks to you -- and, of course to RLoew -- for that.

While this model (= working hypotesis) seems to explain all the facts considered, it's still just a guess, at this point.

I'm so glad you didn't take the "hoitey-toitey" attitude here and say "this model (= fact)". (Many people probably would have said "proven fact" and then gone on about their business, *ignoring* further commentary from me.)

It's clear, dencorso, that you have learned a lot from the Runs in Post # 55 and have established a "template" for assessing the results from my present Runs. (It seems like it is taking forever to get my report done -- I just can't believe the number of interruptions that I am having.)

I'm sure when I give my report, you can chew through the results "super fast" -- something akin to Godzilla eating Tokyo.

larryb123456

[CyberyogiCoWindler]

Just about the "random" behaviour when playing the same video multiple times. May it be that there is a race condition somewhere - e.g. between a graphics card accelerator function and the CPU?

I mean a certain GPU function (e.g. hsync IRQ?) is intended to be always slower than a certain routine running on the CPU, but here the patch reverses this, which was not expected (causing something similar like a buffer underrun). E.g. I have some 386er/486er games those render their 3D graphics incomplete on later PCs (even my 166MHz Pentium MMX laptop, missing or half-drawn sprites etc.) because the timing did not expect that the cpu would ever finish a task faster than the graphics card, causing the too fast running game routine to restart the screen redraw before it can finish. Also on Amiga computers with upgraded CPU (faster than the original 7MHz) existed this problem when the code expected the AGNUS chip (area fill, line draw acelarator) to be always faster than the CPU. There were lots of such timing bugs when first time XT games (containing active waiting counter as timing loops and such stuff) were confronted with faster PCs than they expected. This is like the fabula of the hare and the hedgehog; one expects that the other has finished something that the other didn't.

Edited September 8, 2010 by CyberyogiCoWindler

[rloew]

Just about the "random" behaviour when playing the same video multiple times. May it be that there is a race condition somewhere - e.g. between a graphics card accelerator function and the CPU?

I mean a certain GPU function (e.g. hsync IRQ?) is intended to be always slower than a certain routine running on the CPU, but here the patch reverses this, which was not expected (causing something similar like a buffer underrun). E.g. I have some 386er/486er games those render their 3D graphics incomplete on later PCs (even my 166MHz Pentium MMX laptop, missing or half-drawn sprites etc.) because the timing did not expect that the cpu would ever finish a task faster than the graphics card, causing the too fast running game routine to restart the screen redraw before it can finish. Also on Amiga computers with upgraded CPU (faster than the original 7MHz) existed this problem when the code expected the AGNUS chip (area fill, line draw acelarator) to be always faster than the CPU. There were lots of such timing bugs when first time XT games (containing active waiting counter as timing loops and such stuff) were confronted with faster PCs than they expected. This is like the fabula of the hare and the hedgehog; one expects that the other has finished something that the other didn't.

You are describing the exact opposite of the possible problem here. Here the Videos play fine on faster modern CPUs but not on the older Pentium IIs. Timing problems are entirely possible but for different reasons than you described. This is why it was suggested to test with a Pentium III of exactly the same speed, to minimize any speed improvement in the CPU.

[jds]

@ rloew :

Hi. Yes, I'm aware this is beta, I've no problem with that.

BTW, I'd also be interested in trying your CMOV patch, that you concluded was too slow to be practical ... for an entirely different application, on an entirely different machine. :-)

@ all :

I'm wondering ... if copying the cached/running application (eg. the Flash plugin) may result in a patched version instead of the original, what happens to compressed applications? Wouldn't they be copied in their decompressed form? Or are these two situations different somehow?

Joe.

[rloew]

@ rloew :

Hi. Yes, I'm aware this is beta, I've no problem with that.

Not even Beta. More like Alpha.

BTW, I'd also be interested in trying your CMOV patch, that you concluded was too slow to be practical ... for an entirely different application, on an entirely different machine. :-)

That one is not a Patch. CMOV Instructions would be very difficult to Patch dynamically. The Instructions are emulated.

@ all :

I'm wondering ... if copying the cached/running application (eg. the Flash plugin) may result in a patched version instead of the original, what happens to compressed applications? Wouldn't they be copied in their decompressed form? Or are these two situations different somehow?

Joe.

Only Read Only Code Blocks are run from Cache. A Compressed application has to create it's own Code Blocks dynamically. These would not be treated as File Cache since they do not correspond to Disk data.

[rilef]

- GOM Player working, newer VLC crash

As my main media player I got GOM Player 2,1,21,4846 (Unicode) to work, but I have to disable the built-in codecs and must not change the screen ratio(?) setting because this crashes GOM as soon I play any videos. I expect that there is optimized 686er code buried in these GOM functions, because also as FFDShow codec pack I could not use the newest one but only install ffdshow_rev1936_20080413_clsid.exe; later versions complain that they do not support 586er CPUs anymore. A big benefit of GOM is that it also plays slightly damaged FLV files from YouTube, those refuse to play on MediaPlayer Classic. I also tried VLC, but only the ancient version "0.8.6i Janus (wx_Widget Interface)" works, which user interface in fullscreen mode is awful.

I have tried to install newer VLC versions now, but none worked. With vlc-1.0.3-win32.exe I first got a page fault error in RPCRT4.DLL (was version 4.71.3328), so I upgraded the DCOM98 package (using 269874usa8.exe, Q240664.EXE, OLEUP.EXE and the unofficial DCOM98UP.EXE) which made that bug disappear. But best I can get is still only the VLC window and configuration window come up, but they immediately crash when I try to play any videos. I already disabled built-in codecs without success. So far I remember, vlc-1.1.4-win32.exe did not start at all. Dependency Walker revealed a "illegal instruction" message, so I conclude that they contain 686er-only code that refuses to run on my K6-3+.

By the way, I even got the GOM Player 2 to work on my antique IBM Thinkpad 760XD laptop (Pentium MMX 166MHz, 96MB RAM, 2GB HDD), however although videos in 320x240 run surprisingly smooth, they run systematically too slow and so the sound track gets out of sync soon. Also Media Player Classic has some sync problem on the laptop. Surprising is that VLC 0.8.6i here makes almost no sync problems despite it jerks noticeably.

GOM Player works fine on Windows 98 without Kernel EX installed.

Several programs that run successfully on Pentium III or better processors, have issues when run on K6 or Pentium II processors (with or without Kernelex). For example, it has been several years since a version of the GOM Player has run successfully on my K6-2 computer. Similarly, recent versions of Videolan(VLC) will not run on my computer, even with Kernelex installed.

CyberyogiCoWindler,

"As my main media player I got GOM Player 2,1,21,4846 (Unicode) to work, but I have to disable the built-in codecs ... "

GOM, Media Player Classic("MPC"), and Windows Media Player("WMP") are all DirectShow media players. If you've disabled GOM Player's built-in codecs, GOM is using "ffdshow_rev1936" and other DirectShow filters, splitters, and codecs to play all media files.

"A big benefit of GOM is that it also plays slightly damaged FLV files from YouTube, those refuse to play on MediaPlayer Classic."

For DirectShow players, if a needed DirectShow filter/splitter or codec is missing or the wrong version, your media file will not play correctly and/or the player may crash. And, if multiple codecs are installed to play the same audio or video format, the DirectShow player generally uses the codec with the highest Window's priority or "merit" setting.

MPC includes many internal DirectShow filters and codecs, which filters take priority over external filters. Thus, if a video file plays correctly in GOM, but does not play correctly in MPC, try disabling the related internal DirectShow filter in MPC to fix the problem. Also, make sure you've installed the latest version of MPC that's compatible with Windows 98 and your K6 processor (available here: http://sourceforge.net/projects/guliverkli2/files/Media%20Player%20Classic/6.4.9.1/mplayerc_20081005_win9x.zip/download'>http://sourceforge.net/projects/guliverkli2/files/Media%20Player%20Classic/6.4.9.1/mplayerc_20081005_win9x.zip/download ).

"I got GOM Player 2,1,21,4846 (Unicode) to work, but I ... must not change the screen ratio(?) setting because this crashes GOM as soon I play any videos."

There are several DirectShow alternatives to GOM to choose from, that run on Windows 98 computers with a K6 processor-- and that won't crash when you change the screen ratio. These include perhaps a prior version of GOM Player, MPC, and WMP. Also, Winamp can play video files with DirectShow, using its DirectShow plugin (I use Winamp version 5.33 with the WINAMP5_Classified_v5.5 skin).

Note that MPC's Internal DirectShow filters, compatible with Windows 98 and your K6 processor, are available for download and installation externally: (available here: http://sourceforge.net/projects/guliverkli2/files/ ). Use of these DirectShow filters is recommended, to spread the functionality of MPC to other media players using DirectShow (such as Winamp and WMP). These external MPC DirectShow filters do not come with an installer. To install, unzip the downloaded file(s) to folder(s) in Windows (say "C:\Program Files\DirectShow\___"). Register each of these new filters using a batch file; or use a DirectShow filter manager, such as "DSFM" (available here: http://www.softella.com/dsfm/index.en.htm ), or RadLight Filter Manager

(available here: http://www.free-codecs.com/RadLight_Filter_Manager_download.htm ).

"VLC 0.8.6i here makes almost no sync problems despite it jerks noticeably."

To fix this problem, try VLC 0.8.6d in both computers, with Kernelex disabled in the program's Properties Compatibility tab.

[CyberyogiCoWindler]

Several programs that run successfully on Pentium III or better processors, have issues when run on K6 or Pentium II processors (with or without Kernelex). For example, it has been several years since a version of the GOM Player has run successfully on my K6-2 computer. Similarly, recent versions of Videolan(VLC) will not run on my computer, even with Kernelex installed.

CyberyogiCoWindler,

"As my main media player I got GOM Player 2,1,21,4846 (Unicode) to work, but I have to disable the built-in codecs ... "

GOM, Media Player Classic("MPC"), and Windows Media Player("WMP") are all DirectShow media players. If you've disabled GOM Player's built-in codecs, GOM is using "ffdshow_rev1936" and other DirectShow filters, splitters, and codecs to play all media files.

"A big benefit of GOM is that it also plays slightly damaged FLV files from YouTube, those refuse to play on MediaPlayer Classic."

For DirectShow players, if a needed DirectShow filter/splitter or codec is missing or the wrong version, your media file will not play correctly and/or the player may crash. And, if multiple codecs are installed to play the same audio or video format, the DirectShow player generally uses the codec with the highest Window's priority or "merit" setting.

MPC includes many internal DirectShow filters and codecs, which filters take priority over external filters. Thus, if a video file plays correctly in GOM, but does not play correctly in MPC, try disabling the related internal DirectShow filter in MPC to fix the problem. Also, make sure you've installed the latest version of MPC that's compatible with Windows 98 and your K6 processor (available here: http://sourceforge.net/projects/guliverkli2/files/Media%20Player%20Classic/6.4.9.1/mplayerc_20081005_win9x.zip/download ).

My MPC version is 6.4.8.4. It anyway uses solely the external ffdshow codec pack (mine is the last version that supports 586er). But GOM can handle incompletely downloaded FLV files from YouTube, those make MPC lock up with black screen and not even show file info.

"I got GOM Player 2,1,21,4846 (Unicode) to work, but I ... must not change the screen ratio(?) setting because this crashes GOM as soon I play any videos."

There are several DirectShow alternatives to GOM to choose from, that run on Windows 98 computers with a K6 processor-- and that won't crash when you change the screen ratio.

That screen ratio option is a completely redundant internal tweak feature. When turned off, I can still switch between 4:3 and 16:9 etc. without any problem (which is apparently handled by the ffdshow codec pack, while the other option only postprocesses the output of a codec or the like). It is a feature that nobody needs.

These include perhaps a prior version of GOM Player, MPC, and WMP. Also, Winamp can play video files with DirectShow, using its DirectShow plugin (I use Winamp version 5.33 with the WINAMP5_Classified_v5.5 skin).

I got already ffdshow to work in Winamp 5.05 using osflvsplitter.1.0.0.4_win32.exe, but it wastes much CPU capacity an can not display damaged FLV files either. (On the laptop it shows video with only about 2 fps.)

"VLC 0.8.6i here makes almost no sync problems despite it jerks noticeably."

To fix this problem, try VLC 0.8.6d in both computers, with Kernelex disabled in the program's Properties Compatibility tab.

Kernelex has nothing to do with it. VLC 0.8.6i jerks solely on the Thinkpad 760XD, which is no wonder regarding the Pentium MMX 166MHz CPU with very archaic GPU (Vesa Local Bus graphics?). The machine is from 1996/97, has no 3D acceleration at all and can not even properly stretch DOS text mode to fullscreen despite its initial retail price was about 7000EUR. The TFT has only 16bit colours (very off, violet appears light blue, red way too strong, faces in intense pink, all bright colours very pale). Funny is that it even contains a hardware MPEG2 decoder chip in half horizontal resolution (with CVBS video in/out jack), which however is only supported by an ancient (16bit?) Video for Windows driver in the first issue of the Windows Media Player (that came also with Windoze 3.11?). I yet found no way to use that codec in any modern media players. (Is there a trick?)

Edited September 9, 2010 by CyberyogiCoWindler

[CyberyogiCoWindler]

Just about the "random" behaviour when playing the same video multiple times. May it be that there is a race condition somewhere - e.g. between a graphics card accelerator function and the CPU?

I mean a certain GPU function (e.g. hsync IRQ?) is intended to be always slower than a certain routine running on the CPU, but here the patch reverses this, which was not expected (causing something similar like a buffer underrun). E.g. I have some 386er/486er games those render their 3D graphics incomplete on later PCs (even my 166MHz Pentium MMX laptop, missing or half-drawn sprites etc.) because the timing did not expect that the cpu would ever finish a task faster than the graphics card, causing the too fast running game routine to restart the screen redraw before it can finish. Also on Amiga computers with upgraded CPU (faster than the original 7MHz) existed this problem when the code expected the AGNUS chip (area fill, line draw acelarator) to be always faster than the CPU. There were lots of such timing bugs when first time XT games (containing active waiting counter as timing loops and such stuff) were confronted with faster PCs than they expected. This is like the fabula of the hare and the hedgehog; one expects that the other has finished something that the other didn't.

You are describing the exact opposite of the possible problem here. Here the Videos play fine on faster modern CPUs but not on the older Pentium IIs. Timing problems are entirely possible but for different reasons than you described. This is why it was suggested to test with a Pentium III of exactly the same speed, to minimize any speed improvement in the CPU.

But the patched code segments will be of course slower than the original on 686er and thus may cause trouble when that code section is re-started with fixed frequency e.g. by a scanline IRQ of the graphics card and (perhaps depending on actual CPU load) gets not enough time to finish.

Another thought - may it be that instructions those were designed to be uninterruptable are now replaced with an interruptable piece of code, so an IRQ can hail into a transaction-like piece of code that should have been atomic (i.e. executed in one piece without getting cut apart by multitasking or whatever that may change register contents or such things where it shouldn't).

When you finally get the patcher to work well (I consider it currently alpha code), the file cache mechanism of Windows should be modified to prevent accidentally copying of patched code. Either a 2nd file cache only for executables should be added or the patched code should be marked somehow that they will be only recognized by the execution but not by the file copy functions of Windows. By the way, may it be that code in the file cache is read by certain executables by random access and though can trip on patched code?

(Please don't laugh - does self-modifying code or jumps into the middle of a piece of code still exist, or are such principles anyway impossible with the several caches and parallel execution units of modern CPUs? I am no expert in x86 assembler nor Windows internals, but I survived university studies in computer science and well remember how timing problems with multitasking or interrupts can produce unpredictable results. I still remember how extraterrestial the concept of Transmeta Crusoe CPU appeared to me and how the company Starbridge wanted to created even a desktop supercomputer of fully programmable FPGA chips instead of a CPU with given instruction set. The concept of the realtime patcher appears a bit similar to me and I imagine that many kinds programming tricks may make it trip.)

[rloew]

But the patched code segments will be of course slower than the original on 686er and thus may cause trouble when that code section is re-started with fixed frequency e.g. by a scanline IRQ of the graphics card and (perhaps depending on actual CPU load) gets not enough time to finish.

Possibly. It would be just one more possible timing issue to consider.

Another thought - may it be that instructions those were designed to be uninterruptable are now replaced with an interruptable piece of code, so an IRQ can hail into a transaction-like piece of code that should have been atomic (i.e. executed in one piece without getting cut apart by multitasking or whatever that may change register contents or such things where it shouldn't).

Not the instructions currently being Patched.

When you finally get the patcher to work well (I consider it currently alpha code), the file cache mechanism of Windows should be modified to prevent accidentally copying of patched code. Either a 2nd file cache only for executables should be added or the patched code should be marked somehow that they will be only recognized by the execution but not by the file copy functions of Windows. By the way, may it be that code in the file cache is read by certain executables by random access and though can trip on patched code?

I did say Alpha above.

This File Cache behavior is a "Feature" Microsoft bragged about when Windows 98 was released. Read Only Code is not supposed to be altered in any way.

The file copying issue only affects executables that are already causing errors. Well behaved Programs are not affected.

Taking advantage of it, may allow permanent Patches to be applied so there would be no actions by the Patcher and it could be disabled.

I have no intentions of altering the File Cache behavior.

(Please don't laugh - does self-modifying code or jumps into the middle of a piece of code still exist, or are such principles anyway impossible with the several caches and parallel execution units of modern CPUs?

Of course it still exists. If necessary, all of the caches can be flushed with a single instruction.

I am no expert in x86 assembler nor Windows internals, but I survived university studies in computer science and well remember how timing problems with multitasking or interrupts can produce unpredictable results. I still remember how extraterrestial the concept of Transmeta Crusoe CPU appeared to me and how the company Starbridge wanted to created even a desktop supercomputer of fully programmable FPGA chips instead of a CPU with given instruction set. The concept of the realtime patcher appears a bit similar to me and I imagine that many kinds programming tricks may make it trip.)

Been there. Done that.

[rloew]

Several programs that run successfully on Pentium III or better processors, have issues when run on K6 or Pentium II processors (with or without Kernelex). For example, it has been several years since a version of the GOM Player has run successfully on my K6-2 computer. Similarly, recent versions of Videolan(VLC) will not run on my computer, even with Kernelex installed.

GOM Player uses instructions that are not supported on K6-2 Processors. KernelEx will not help with this issue.

I wrote an Emulator for the problem Instructions. This allowed it to run but was way too slow.

I ended up using the Emulator log to manually Patch the GOM Player

[rilef]

My MPC version is 6.4.8.4. It anyway uses solely the external ffdshow codec pack (mine is the last version that supports 586er). But GOM can handle incompletely downloaded FLV files from YouTube, those make MPC lock up with black screen and not even show file info.

The latest MPC version is 6.4.9.1 (available in both unicode and non-unicode(win9x) versions here: http://sourceforge.net/projects/guliverkli2/files/ ). To try MPC version 6.4.9.1, download and unzip MPC version 6.4.9.1 to a different folder from where you've installed your MPC version 6.4.8.4 program. You may also be able to try the unicode version of MPC 6.4.9.1 under Kernelex, again from a separate folder (you may also have to disable all or some of MPC's internal filters).

When playing FLV test files in MPC, I noted the DirectShow filters, "ffdshow" and "AC3Filter" were both running. You already have ffdshow. AC3Filter ver 1.63b (for win9x), if needed for MPC and WMP, is available here: http://ac3filter.net/ .

[jds]

@ rloew :

Hi. Yes, I'm aware this is beta, I've no problem with that.

Not even Beta. More like Alpha.

Yes ... I chose my wording for discretionary reasons. <G>

BTW, I'd also be interested in trying your CMOV patch, that you concluded was too slow to be practical ... for an entirely different application, on an entirely different machine. :-)

That one is not a Patch. CMOV Instructions would be very difficult to Patch dynamically. The Instructions are emulated.

OK, here I chose my wording badly. I didn't mean to imply the executable code was being patched, rather I tend to use that word in a more general context to describe system tools that alter the behaviour of a system.

Yes, you explained that because the CMOV instructions were emulated, there was a significant performace penalty. That's fine, the applications I want to try this on are not real-time anyway (they're the mjpeg utilities, which run on my Pentium II but not my Pentium MMX, so I figure it must be the CMOV stuff that's the problem).

Joe.

[LoneCrusader]

I employ a historical PC with 550MHz AMD K6-3+ CPU and 512MB RAM running on Windows 98SE+KernelEx; it is optimized for historical games and made from finest DOS-age hardware, including 2 genuine ISA soundcards (SoundBlaster AWE64 Gold, Gravis UltraSound Classic) and a Riva TNT2 combined with Voodoo 1 3D graphics card in a DFI K6BV3+/66 mainboard. I can not upgrade to a higher CPU because I need this special mainboard to use historical ISA soundcards. Discarding them is like requesting musicians to throw away their stradivarius and replace them with some brand new carbon plastic violins mass produced by Yamaha or whatever.

I have several computers with that same motherboard.. I used to collect them on eBay

At that time I was still stuck using Dial-Up Internet, and insisted on being able to use my US Robotics 56k ISA modem if I upgraded my hardware further. This led me on a search for newer motherboards that supported ISA. There are several Pentium III motherboards that have ISA slots, including the DFI CB60-BX and CB61 and if you really want to bump up your hardware, there is always the SOYO P4 I845PE ISA. I have several of these boards, and I have never had a problem with any of them. Too bad SOYO no longer makes motherboards.

[rloew]

Yes, you explained that because the CMOV instructions were emulated, there was a significant performace penalty. That's fine, the applications I want to try this on are not real-time anyway (they're the mjpeg utilities, which run on my Pentium II but not my Pentium MMX, so I figure it must be the CMOV stuff that's the problem).

Joe.

I don't have the mjpeg utilities so I don't know if CMOV Instructions are the issue.

You would have to examine the Illegal Instruction Details to get the OP Codes of the failing Instructions.

I have two versions of my software.

1. The Patcher discussed in this Thread that Patches the three Instructions known to cause problems with Flash.

2. The Emulator I wrote to handle GOM. It emulates CMOV Instructions and one specific PREFETCH Instruction.

I don't know if either or both would handle the mjpeg utilities.