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

[larryb123456]

@dencorso

@rloew

Hello, again.

I am making this short, new post, so the content won't be missed if you have already started to answer my last post, # 75.

In my last post I forgot to mention that ShadowBurn426 *also* said:

"I also do not get this problem (i.e., the crash problem) with FP 9.0.115.0 *if* I use a PIII instead of a PII."

My question:

Exactly at which point(s) -- in the step-sequence mentioned in post # 75 -- would the Pentium lll enter in to solve the problems that the Pentium ll could not solve ? (And how does the P lll do it -- i.e., the behind the scenes "mechanics" ?)

I know that these two posts seem to have a lot of questions, but I'm sure you two can provide "concise", detailed answers -- if that is not an oxymoron (?) -- so that you would not have to spend too much time in responding.

But, the "bottom line" is that your response will fill gaps in my knowledge that have been present for a long time.

Again, many thanks.

larryb123456

[larryb123456]

@dencorso

@rloew

Hello.

I was just curious about what I discuss here. A "super-duper" quick response is not required. But I would like (and I do need) a response "sometime".

I have noticed that if I place the "regular" URL for the Bjork YouTube video, "All is Full of Love", into a message post, then this URL is **replaced** by the YouTube player for this video.

Note: This "magic trick" was not accomplished by me -- someone else (I have no idea who) did it.

Would **I** be allowed to use this "magic trick" -- once I knew the steps behind the "magic secret" -- to post the YouTube players for other videos into a message post that I'm making ?

My question(s) is(are):

What steps are required to turn the "regular" video URL into the YouTube player -- seen immediately below in this message post ? I'm sure the embed code would also have to be considered in these steps, so I am also presenting it here (below) -- for convenience.

(Note: I have added the (X)'s -- as shown below -- to the "regular" video URL to "deactivate" it to keep the player from being shown here for a second time.)

Bjork -- "All is Full of Love" -- "regular" video URL:

(X)(X)h(X)t(X)t(X)p(X):(X)/(X)/w(X)w(X)w(X).y(X)o(X)

u(X)t(X)u(X)b(X)e.(X)com/(X)watch(X)?(X)v=(X)t(X)vo

(X)EZ(X)Xo(X)p4(X)zM(X)&N(X)R=1(X)(X)

YouTube embed code for Bjork video:

<object width="640" height="385"><param name="movie" value="

?fs=1&

hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="

?fs=1&

hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>

What is the proper terminology to describe the player shown in this post ? Is it "the YouTube player **embedded** into this website (in general) and into this message post (*specifically*)" ?

What are the differences (that is, *step-sequence* differences -- as I have mentioned in my last two posts) in me playing the Bjork video in the usual way (i.e., by entering the "regular" video URL in the browser address line and then clicking "enter") as compared to just clicking the arrow in the YouTube player shown in this message post ?

Maybe to make the last paragraph simpler, let me restate it:

If the "embedded" YouTube player (if that's the proper terminology) eliminates some steps in the video playing step-sequence -- as compared to the "usual URL method in getting the video to play" -- then, what would these eliminated steps be ?

Many thanks, in advance, for your answers.

larryb123456

-----------------------------------------------------

P.S., This question is not specifically related to this post, but I would also appreciate an answer.

Question:

First, a little background:

At the bottom of YouTube's player, there is a pink line and there is a red line. The pink line indicates how much "video information" has been loaded into the player at a specific time. The red line "tracks" how much of the song has been played at a given moment. If the red line "catches up" with the pink line, there will result a "stuttering" video play that will last until the pink line can sufficiently get ahead of the red line again.

----------------------

Finally, my question:

What are *all* the factors that can influence the "speed" of the pink line advancing in the player ?

----------------------

Based on random and casual (i.e., totally non-systematic) observations, it seems that emptying browser disk cache before playing a video causes the pink line to advance more slowly, so that the pink is only slightly ahead of the red (but sufficiently far enough ahead that "stuttering" operation does not result). If the disk cache is not emptied after playing the video time after time, the pink *rapidly* moves to the right side of the player (i.e., to the end of the song).

Based on my understanding of browser disk cache, it would seem that all the *pink line info* would be stored in cache -- if it were not emptied before playing a video -- so that the YouTube video player could "access" it much quicker -- that is, to allow the pink to rapidly move to the end of the song.

Am I correct in my understanding and explanation of the effect of "clearing browser disk cache" ?

Again, many thanks.

Your answers are *greatly appreciated*.

larryb123456

-----------------------------------------------------

Edited September 11, 2010 by dencorso

[dencorso]

Reply to Post # 75

Question 1: I don't know.

"markup" = html

You can display the true "embed URL" using code tags. Like this:

http://www.youtube.com/watch?v=tvoEZXop4zM&NR=1

Question 2: I guess so.

Step 4: Yes.

Step 5: No. It depends on whether the local processor can interpret the instructions inside the *specific* FP version installed, no matter what anyone says or thinks about it.

If you could provide a COMPLETE step sequence in getting a YouTube video to play

This would mean having access to Adobe's unpublished documentation or performing a full reverse engeneering of the player. The former is improbable, and the latter too much time consuming to be worth it. By tests alone, the nearer to it you might get is to reach a theoretical hypothesis of what the COMPLETE step sequence you're asking about is, after performing an impressive amount od tests... so that's even more time consuming.

Can you explain what would happen (i.e., the steps involved) if my browser (with FP 9 > 9.0.47.0 installed with the Patcher turned off, of course) -- while trying to apply the YouTube embed info -- ran into the SSE instructions (which are not understood by my Pentium ll).

Yes. The SSE is reached and the processor issues an "Invalid Instruction Fault" which is an interrupt that transfers control to a handler. If the handler is the default windows handler, you'll have a BSOD or even a crash. If it's RLoew's patcher it'll patch the code in memory to eliminate the invalid instruction by substituting it by code the Pentium II can execute and tranfer control back to the flash player at the point where the SSE instruction originally was. That would be it. Unless... Unless the Pentium II thinks it understands the instruction and performs some unpredictable action, instead of duly issuing the "Invalid Instruction Fault"!

I think this is the reason why RLoew's patch doesn't actually get flash to work, although it takes good care of eliminating all crashes/BSODs. Observe that I didn't say here one single thing that had not been said before either by myself or by RLoew. I've just rephrased part of it and integrated it all in a single big picture.

And yes, the forum software has been updated, and the new version has the player displaying ability, which the former versions did not.

=========

Reply to Post #76

Because the Pentium III knows SSE.

=========

Now, you had a simple problem: how to be able to use Flash v. 9.0.280.0

We offered you two possibilities:

1) A software solution (RLoew's patcher) that treated the disease we diagnosed but did not cure the patient (so it was not enough).

2) A hardware solution (the drop-in Pentium III) that is guaranteed to solve your issue (at least as far as V. 9.0.115.0, that is, and using videos that can play with it) but that, in solving your problem will not allow us to ever diagnose what more was needed for RLoew's solution to work. However, in the unlikely case that even the Pentiun III prove not to be enough, then we may infer RLoew's patcher may have been enough (but the patient's illness is even more serious than I thought).

For me that's quite enough. If you become able to use 9.0.280.0, on substituting the processor, I'd consider the original problem solved, and move on.

Now, with all due respect: The number of users still running SSE ignorant processors is even smaller than that of 9x/ME users, which is already small. If 9x/ME has a future, which I still believe it does, that will require us to do our best to keep it compatible with contemporary hardware. We simply cannot afford to cater also for hardware that is falling out of use faster than the OS we're trying to keep viable, unless that doesn't require a considerable effort.

Just as there's a time to sow... and a time to reap, there's also a time to keep trying... and a time to let go, IMHO. Of course, YMMV, though.

[rloew]

Now, with all due respect: The number of users still running SSE ignorant processors is even smaller than that of 9x/ME users, which is already small. If 9x/ME has a future, which I still believe it does, that will require us to do our best to keep it compatible with contemporary hardware. We simply cannot afford to cater also for hardware that is falling out of use faster than the OS we're trying to keep viable, unless that doesn't require a considerable effort.

Just as there's a time to sow... and a time to reap, there's also a time to keep trying... and a time to let go, IMHO. YMMV, though.

Actually I am one of them. My development system uses an AMD-K6. The P3CPU Patcher is a rewrite of one I wrote previously to allow the GOM Player to run on it. It has a different set of incompatable commands. Unfortunately the CMOVcc commands cannot be Patched automatically and emulating was too slow, so I added a logger to create a list of instructions that needed Patching manually.

[dencorso]

Well, for what it's worth, me too!

I still keep a rare K6-III machine working, but I'm thinking of decommissioning it before this year's end or a little later. However, it was so hard, way back when, to get the K6-III, that I keep postponing it for sentimental reasons alone. Nowadays it is used for little more than word processing, if at all used. It once was my primary machine, and I thought it was lightning fast! Now it seems slow as a drunk turtle. Sign of the times.

But it nevetheless works...

[CyberyogiCoWindler]

KernelEx 4.5 RC1 bug-report | Emulate 686er programs on lower CPUs?

First thank you very much for making KernelEx.

I employ a historical PC with 550MHz AMD K6-3+ CPU and 512MB RAM running on Windows 98SE; 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.

- Firefox 3.6

Firefox 2 ran great on it but was not supported by many websites anymore (YouTube etc.,some eBay problems) and so made more and more trouble with non-working scripts. So I had to install KernelEx to run Firefox 3.

With KernelEx 4.5 Beta 2 I tried Firefox 3.6.3 which was quite slow, but Firefox 3.6.4 ran wonderful (as fast as Firefox 2). With some tricks I also managed to install Flash Player 10.0. Unfortunately each later Firefox version became slower and slower (scrolling pages with about 3fps), often crashing Windoze after a while. Also other stuff got slow and Windows often locked up during shutdown, so I suspect a memory leak problem somewhere. (I use as spam filter WebWasher 3.4, a ZoneAlarm 6.1 firewall and Avast AntiVirus 4.8.)

After installing KernelEx 4.5 RC1, Firefox 3.6.8 runs nicely fast again. The only small annoyance is that that it still tends to crash when I try to delete a folder from within the "save as" dialogue box and that it displays instead of "..." a "|" which looks ugly. The latter is likely a simple unicode translation flaw - please fix this.

Another small bug is that after any update of Firefox 3 the HTML file extension gets partly unassigned with the browser, i.e. although you can start Firefox by clicking on a HTML file, any further clicks on HTML files will be ignored (files don't open) so long the browser is running. (Draging and dropping them into the browser windows works ok.) This can be fixed by manually re-assigning the "HTML" and "HTM" file extensions with Firefox 3 using "open with..." in the Explorer context menu.

- screen mess after loading many pictures

Another bug is that after loading in Firefox large webpages with many pictures, Windows first turns slower and finally fails to update the screen properly. Typically first the browser menus don't get updated anymore (showing residues of previous screen content when clicking other programs in front and back again) and scrolling makes the the lower row of the HTML page smear a trail across the screen. This happens particularly in the Google image search by scrolling down the search result page with its hundreds of thumbnails. Also other programs (e.g. IrfanView Thumbnails or the Zoombrowser EX of my Canon Ixus 800IS digicam) make such bugs when lots of thumbnails are displayed. This bug may be also related to the FreeCell graphics mess mentioned by other users.

The bug can be temporary stopped by making the browser window smaller or closing some tabs, but it finally returns and can eventually only eliminated by restarting Windows. When I had less RAM, I regularly used the memory manager BySoft FreeRAM 3.0. I still can use it to manually clean up the memory, which also seems to temporary stop the bug, but it won't work for longer and also increases the Windows lockup risk, so I don't use FreeRAM regularly anymore.

I think it is a memory overflow problem of an image cache caused by some kind of memory leak or internal fragmentation phenomenon of the virtual memory. I am not sure if this is related to KernelEx at all, but I think it happened much earlier with KernelEx 4.5 Beta than with the current 4.5 RC1 release, so it may be that everything that slows down Windows 98SE also furthers this bug (or vice versa??), e.g. by somehow preventing proper garbage collection.

- 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.

- Flash Player 10.1 not working

I read that Flash Player 10.1 would run on the new KernelEx 4.5 RC1, but it doesn't, so I had to return to version 10.0 (install_flash_player_10.0.45.2.exe). Is this a KernelEx bug or another 686er issue? Are there newer VLC versions compiled for 586er?

- cpu wrapper/emulator to run 686er code on 586er?

It is a severe annoyance that many modern programs are compiled 686er-only and can not run on normal Pentium/K6 or lower CPUs idependent from their actual speed.

Technically it should be no problem to trap the "illegal instruction" errors and emulate the missing opcodes in software. I am aware that it will be certainly slow, but at least it would make it possible to run programs those are 686-only by lazy programmers those omitted an include file. But it should be the sovereignous customer's right to test and decide what is too slow and not some money hungry ripoff software industry's decision to pollute the environment by randomly forcing people to discard and replace their perfectly working PC once some cravat wearers command that 586er are to be classified "outdated".

Has anybody written such a CPU enhancer for Windows? I am not talking about a virtual machine that simulates a whole PC (causing huge overhead) but only a tiny piece of code that traps and simulates missing CPU opcodes. I know that some special Linux versions for handheld computers contain the "x86-emu" as part of their kernel, but is there a Windows counterpart? If not, please integrate it into KernelEx or a separate small program. I could be even made into something like a bootloader to install operating systems those expect a higher CPU.

Edited September 5, 2010 by CyberyogiCoWindler

[dencorso]

- cpu wrapper/emulator to run 686er code on 586er?

[...]

Has anybody written such a CPU enhancer for Windows? I am not talking about a virtual machine that simulates a whole PC (causing huge overhead) but only a tiny piece of code that traps and simulates missing CPU opcodes. I know that some special Linux versions for handheld computers contain the "x86-emu" as part of their kernel, but is there a Windows counterpart? If not, please integrate it into KernelEx or a separate small program. I could be even made into something like a bootloader to install operating systems those expect a higher CPU.

Well, sort of. It's complicated... Read this thread, though, and you'll know what is there.

[Sfor]

- 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.

[CyberyogiCoWindler]

It should be the sovereignous customer's right to test and decide what is too slow and not some money hungry ripoff software industry's decision to pollute the environment by randomly forcing people to discard and replace their perfectly working PC once some cravat wearers command that 586er are to be classified "outdated".

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.

Thanks to KernelEx 4.5 RC1 I run Flash Player 10.0 now without trouble. Before KernelEx I had version 9, that tended to crash once it started to play a video. I simply prevented this by installing the TubeStop(?) plugin in Firefox 2 and downloading the YouTube clips manually using the Video DownloadHelper plugin (and some predecessors). By my slow analogue modem I can not watch videos in realtime anyway.

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+.

See here:

Please continue with the patcher program. But I worry about the concept of changing program code in file cache and writing it accidentally back to disk when the program is copied by Explorer etc, which leads to unpredictable random behaviour. IMO the explorer should at least be enabled to flush altered EXE files from the file cache before copying them, or better the "illegal instructions" should be only emulated in realtime by a CPU wrapper without changing the actual EXE (but this may be way too slow).

ShadowBurn426 mentioned that a certain video size triggered the crash. May it be that like with "screen ratio" in GOM, some scaling algorithm in Flash Player contains 686er code that is only triggered by certain sizes?

larryb123456 made tests due to random behaviour of the patcher. A major source of unrepeatable errors can be the daily update of antivirus programs. I realized that the system performance varied very much (and usually got worse over time) by updating it. Particularly my PC often locked up during shutdown, which happened or stopped to happen typically after the antivirus update. (I went through a lot of different ones, now using Avast Home 4.8.)

Edited September 5, 2010 by CyberyogiCoWindler

[rloew]

It should be the sovereignous customer's right to test and decide what is too slow and not some money hungry ripoff software industry's decision to pollute the environment by randomly forcing people to discard and replace their perfectly working PC once some cravat wearers command that 586er are to be classified "outdated".

You might want to tone down your remarks. The programs you are complaining about are FREE.

As for the commercial software industry, money is the reason why they are in the business in the first place.

Would you go to work if you didn't get paid?

I sell a number of Programs and Patches for DOS and Windows 9x. It's not enough to live on.

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 understand. My development system uses a 450MHz AMD K6-2 and I still use it.

Unfortunately, I think most violin repair shops would go out of business if they had to stock spare parts for Stradivarius and other Classical violins.

Please continue with the patcher program. But I worry about the concept of changing program code in file cache and writing it accidentally back to disk when the program is copied by Explorer etc, which leads to unpredictable random behaviour. IMO the explorer should at least be enabled to flush altered EXE files from the file cache before copying them, or better the "illegal instructions" should be only emulated in realtime by a CPU wrapper without changing the actual EXE (but this may be way too slow).

I have no immediate plans to continue. It does not appear to be a viable solution.

The Explorer would have to be Patched to flush the cache. I use a separate Program to do that.

My original VXD emulated the "illegal instructions". It had to, since the CMOV instructions used by the GOM Player cannot be easily Patched.

It was way too slow. I ended up adding a logger to record the Addresses of the "illegal instructions" so that I could manually Patch the GOM DLL later.

[dencorso]

I'm anxiously waiting for larryb123456 to report his results after the upgrade to the Pentium III processor, because:

1) I'd be glad to know it solved his issues (and I bet it'll).

2) It would prove beyond reasonable doubt that there are instructions in the Flash Players > 9.0.47.0 that are not correctly executed by the Pentium II, but which do not elicit a "invalid instruction fault", which I think is the only reasonable explanation for the results reported by larryb123456 with RLoew's real-time patcher VxD.

[CyberyogiCoWindler]

Not every program that contains 686er code is necessarily too slow when emulated.

Although there is nowadays more and more inefficient fatware bloat code around, it often tends to be laziness of programmers to compile for 686-only target because they just don't mind that others exist. E.g. simple Tetris-like games are nowadays labelled with requirements like "1.5GHz Pentium III, 1GB RAM", which is often simply the result of that nobody took the effort of fetching a weaker PC and testing on it despite the game may run well on a 200MHz CPU. E.g. my Thinkpad 760XD with its 166MHz runs a lot of programs those claim to need 450MHz etc. Also harddisk space can be often reduced dramatically by deleting unused language packs, themes/skins, game demos, instruction videos and other rubbish that comes with modern software installations. And with modern media players they usually tell the requirements for playing HD video contents and not for QVGA (320x240) resolution where they need only a few 100MHz. (Is it possible to to reduce CPU load by playing given HD or DVD videos in lower resolution?)

Does anybody know more about the "x86-emu" feature found in some Linux kernels?

[larryb123456]

@dencorso

@rloew

Hello, again.

----------------------------------------------------------

But first, and this is *very* important:

dencorso, this is from your Post # 78:

In regards to this Post I say:

I am *really confused now* from what you say here.

I just *carefully* read this info after I had written everything in this Post -- (beneath the line below). Based on my observation of the data briefly discussed below, I had concluded that rloew's Patcher *was* effective in eliminating "illegal operations" and "invalid instructions" that would have prevented Flash videos from playing.

And I concluded -- at least for the 5 cases considered below -- that his Patcher "allowed" the videos to play perfectly. In other cases, where the video results were not as good, I concluded that there were as yet "unknown" factors involved -- and it is these factors that my present Test Runs are trying to "separate out" and "define".

If it turns out that my **basic logic** is flawed in what I say in this Post, well, I'm just going to........I don't know what I'm going to do ! ! !

You said:

The SSE is reached and the processor issues an "Invalid Instruction Fault" which is an interrupt that transfers control to a handler. If the handler is the default windows handler, you'll have a BSOD or even a crash. If it's RLoew's patcher it'll patch the code in memory to eliminate the invalid instruction by substituting it by code the Pentium II can execute and tranfer control back to the flash player at the point where the SSE instruction originally was. That would be it. Unless... Unless the Pentium II thinks it understands the instruction and performs some unpredictable action, instead of duly issuing the "Invalid Instruction Fault"!

I think this is the reason why RLoew's patch doesn't actually get flash to work, although it takes good care of eliminating all crashes/BSODs. Observe that I didn't say here one single thing that had not been said before either by myself or by RLoew. I've just rephrased part of it and integrated it all in a single big picture.

I say:

Thanks for that rephrasing, dencorso. Rephrasing is always good, IMO.

It seems that you are giving the *exact mechanism* by which rloew's Patcher *works* when you say:

"If the handler is ...... RLoew's patcher it'll patch the code in memory to eliminate the invalid instruction by substituting it by code the Pentium II can execute and tranfer control back to the flash player at the point where the SSE instruction originally was."

But, then you say:

Unless... Unless the Pentium II thinks it understands the instruction and performs some unpredictable action, instead of duly issuing the "Invalid Instruction Fault"!

I think this is the reason why RLoew's patch doesn't actually get flash to work.

Are you trying to explain the "apparently irreproducible" results of Post # 55 -- for FP 9.0.115.0 and FP 9.0.280.0 -- by saying that the Pentium ll "most always" performs some unpredictable action (as evidenced by the "variety" of video playing results) instead of "handing off" the Invalid Instruction Fault to the Patcher so that the Patcher can "fix it" ?

Or, equivalently, are you saying that the Pentium ll is "hogging the whole show" by "shutting out the Patcher" and then "acting a fool" so that the video playing results are "all over the map" ?

In my opinion, the two or three Runs that were made in Post # 55 for each video/browser combination were simply not enough to draw definitive conclusions about

"unpredictable actions" -- or anything else, either.

My present results show that when *more* Test Runs are made for each variable set, definite patterns emerge. I classify the results into what I call "Behaviors" -- which I can assign a number to. I hope this approach will make data presentation "cleaner" and will allow one to say -- with certainty -- whether a certain Behavior is associated with

"unpredictable action of the Pentium ll" or something else.

I did not mean for this "preface" to be this long. Sorry.

Thanks for reading.

----------------------------------------------------------

To continue with the first posted message:

Sorry for being away for the last couple of days. I will try to get caught up here now. The Pentium lll arrived last Friday. (Today is Monday.) My nephew is combining some accumulated vacation time from work with the Labor Day weekend to take something of an extended out-of-town holiday. He is supposed to be back late this Wednesday evening. I do not know when, after that, he will be able to install the Pentium lll for me.

In all the spare time I have had, I have been running more video Tests. The process of running these Tests has suggested even more Tests -- which has been a good thing. It is kind of a slow, painstaking process -- one of careful organization and interpretation of the data as I proceed. A major concern is that I have my report clear and well organized so that you both can easily understand it. That way you might have some "code-based" explanations of the data trends that I am not qualified to give.

The important thing in the Tests that I am doing is to be systematic -- that is, to change

only one variable at a time, so that the effects of just that *one variable* can be analyzed. It is also important to make *many* repeat Runs for each "variable set" to verify reproducibility. This way we can have confidence in the conclusions.

It's kind of like a "distillation" procedure, in which more things are becoming clearer as I proceed. I wish the process were going a little faster, but it just can't be rushed along.

There is one thing that has been proven -- to me, at least -- beyond a shadow of a doubt:

Rloew's Patcher is *extremely effective* in eliminating "illegal operations" and "invalid instructions" in the Shockwave Flash plugin module, NPSWF32.dll. (These errors can result in a browser shut-down or a computer hang or crash.)

Remember, in Post # 55, I had noticed that -- for FP 9.0.280.0 -- Opera 9.64 played Bjork's "All is Full of Love" perfectly -- without any failures -- three times. And I then said that I was curious to see how many times in a row Opera could play Bjork. So, that was the first thing I tried (in Test 1).

I made 50 Runs and 15 Reproducibility Runs with perfect success over and over again.

I then turned the Patcher off and made 15 Runs -- each of which, of course, was a

total failure. Those 15 failures demonstrated *all* the results that I personally have experienced for FP 9 > 9.0.47.0 in trying to play videos on YouTube (with the Patcher turned off, of course).

So, this demonstrated the effectiveness of the Patcher: Patcher "on" = success; Patcher "off" = failure.

In addition to Bjork's "All is Full of Love" -- which played with great success -- I have found 4 other "new" videos which played with equal success, over and over again -- with the Opera browser. (But, for these 4 videos, I limited the number of Runs to 15 -- in the interest of time.) I am sure there are many other videos that Opera can play -- (and, maybe the other browsers, too) -- but I want to spend some time trying to better sort out "browser effects" for my "given set" of videos that I have accumulated so far.

After *each* of the Tests for the 4 videos mentioned above, I turned the Patcher off and made 5 Runs -- and, of course -- each of these 4 x 5 = 20 Runs were total failures, in the manner described above.

So, we see that the effectiveness of the Patcher is demonstrated again: Patcher "on" = success; Patcher "off" = failure.

There is one point which should not be missed here. I'm sure it is obvious, but it bears repeating anyway. In *each and every case* where the Patcher has provided total success -- or even "apparently mixed results", as in Post # 55 -- it is resolving -- *behind the scenes* -- the "illegal operations" and "invalid instructions" (which would lead to a browser shut-down with the NPSWF32.dll error or a computer hang or crash).

So, again, we see that the effectiveness of the Patcher is demonstrated again: Patcher "on" = total success or "apparently mixed results"; Patcher "off" = failure.

The purpose of the video Tests I am now doing is to better characterize these "apparently mixed results".

----------------------------------------------------------

In rloew's Post # 72:

dencorso, on 22 August 2010 - 02:35 AM, said:

My point in suggesting the Pentium III is answering RLoew's question: Do these videos play with a Pentium III?

If they do so correctly and without issues (without the patcher, of course), we'll know there is more that the patcher must know to work right, even if that more are not "invallid instructions". Now, if they don't we may infer that the patch achieved simulating a Pentium III out of a Pentium II well enough, but that even a Pentium III is not enough to actually have those videos play correctly.

I say:

I strongly feel that "illegal operations" and/or "invalid instructions" are not the reason that rloew's Patcher is not working *perfectly* at this time (see above comments) -- although I feel at this point the Patcher shows great promise.

I am trying to separate out "factors" and "behaviors" from the video Test Runs I am doing to try to provide insight and guidance that can be used to improve the Patcher through the "next step", if possible. In other words, suppose the data indicated a particular behavior happening -- to which you could assign a reason. Well, from that point, you could either correct it -- maybe, by an additional little program or something -- or you could definitively say that the behavior could not be corrected.

Also, it "might"(?) be possible that if the Pentium lll does not *totally* work, it could be for the *very same reasons* the Pentium ll -- now -- does not *totally* work.

That is, we "might"(?) actually have *now* (Pentium ll + Patcher) = (Pentium lll), it's just that those yet unsorted out factors "might be"(?) masking that fact.

Of course, all of the above is just conjecture on my part.

The main purpose of the immediate discussion above (below the line) is to try to thoroughly understand the nature of the (Pentium ll + Patcher) results -- as I am now getting in my current Test Runs -- *before* we forge ahead with the Pentium lll Test Runs.

But, we can discuss whether or not it is pointless to continue with the (Pentium ll + Patcher) results when I submit my report. Hopefully, at that point, you might suggest some other Test Runs I can make. For example, in the Tests I am making now, I am only considering FP 9.0.280.0 -- mainly for reasons of thoroughness and a concern that FP 9.0.115.0's more unstable nature might "confound" the data. But, we also could take a little time to consider 9.0.115.0 next with the Pentium ll -- just for completeness (and just in case the results might be "revealing").

I know that you think the results of Post # 55 are incomprehensible, but there is "a method to the madness" -- as indicated by my present results. The results of Post # 55 -- for FP 9.0.115.0 and FP 9.0.280.0 -- are confusing and basically worthless because these results were obtained in a rather haphazard way and not enough Runs were made for a given variable set.

----------------------------------------------------------

Many thanks in advance for a *thorough* response to

this post.

The reason I say that, is I feel that I'm dealing with issues

of *fundamental* logic and understanding here.

larryb123456

----------------------------------------------------------

[jds]

Hi all,

Very interesting discussion, this SSE dependency most likely explains the problems I've experienced with Flash on my Pentium II at home (mainly Yahoo Australia and some of the local media sites). Any chance I can get a copy of Mr Loew's patch to try?

Joe.

[dencorso]

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

Let's compare, from your post #55, task 1 to task 2( a & b ), limiting our analysis to Opera:

i) Bjork "All is Full of Love" played perfectly in both tasks.

ii) MGMT "Electric Feel" didn't play well in either... it seems to have problems.

iii) All other video clips played well in task 2, but had problems in 1.

My conclusion is Bjork's video elicits only "good behaved" SSE instructions (i.e.: those which cause "Invalid Instruction Faults", henceforward simply "IIFs" and cause RLoew's patcher to spring to action); all other video clips appear to elicit also some "bad behaved" SSE instructions, which are misunderstood by the Pentium II into doing silly things but never cause IIFs (so RLoew's patcher cannot help), and this is why they don't play as they should with Flash 280, but do so with Flash 47 (because it is SSE free). MGMT "Electric Feel" seems to be worse in that it is heavy on the internet connection, probably due to a high framerate (it played somewhat chopply for me even with Flash 10.1.82.76 / IE8, under Win XP SP3).

Things get worse on Firefox or Netscape possibly because the same Flash .dll playing the same video clip on different browsers apparently causes different execution paths to be followed inside the .dll, with the result that more "bad behaved" SSE instructions come into play with the above named brosers than with Opera.

===========

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.

===========

@jds: do send RLoew an e-mail about it, in case he doesn't post again here soon.