ruffle
ruffle copied to clipboard
ruffle-rs
Multiple issues with z0r.de
I've been trying out ruffle to extract previews of all the swf from z0r.de (about 8000) using the exporter. Most seem to work (even though the first frame is white most of the time), but some of them fail badly:
- ~1722: thread 'main' panicked at 'already mutably borrowed: BorrowError', /build/rust/src/rustc-1.44.0-src/src/libcore/cell.rs:798:9~
- ~1724: leaking infinite loop~
- ~1966: thread 'main' panicked at 'not implemented: 15-bit PNG', core/src/backend/render.rs:319:42~
- 2021: leaking infinite loop
- ~2279: thread 'main' panicked at 'called
Result::unwrap()on anErrvalue: TryFromIntError(())', core/src/avm1.rs:418:19~ - ~3335: thread 'main' panicked at 'already mutably borrowed: BorrowError', /build/rust/src/rustc-1.44.0-src/src/libcore/cell.rs:798:9~
- ~3536: thread 'main' panicked at 'not implemented', core/src/display_object/movie_clip.rs:212:37 (defineFont4)~
- ~3845: thread 'main' panicked at 'not implemented', core/src/display_object/movie_clip.rs:212:37 (defineFont4)~
- ~5362: thread 'main' panicked at 'already mutably borrowed: BorrowError', /build/rust/src/rustc-1.44.0-src/src/libcore/cell.rs:798:9~
- ~5586: leaking infinite loop~
- ~6138: thread 'main' panicked at 'called
Result::unwrap()on anErrvalue: AllocationError(OutOfMemory(Device))', /home/ux/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-core-0.5.4/src/device/mod.rs:309:22~ - ~7765: thread 'main' panicked at 'called
Result::unwrap()on anErrvalue: AllocationError(OutOfMemory(Device))', /home/ux/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-core-0.5.4/src/device/mod.rs:402:22~ - ~7766: leaking infinite loop~
The "leaking infinite loop" are in my opinion the most problematic ones. Some seem relatively easily to address (defineFont4), but there is still a lot of unknown.
I'm aware this issue should be split in many different ones, but I think it could serve as reference ticket for the progress on the support of all those swf.
To reproduce:
wget -c https://z0r.de/L/z0r-de_{1722,1724,1966,2021,2279,3335,3536,3845,5362,5586,6138,7765,7766}.swfcargo run --package=exporter -- z0r-de_XXXX.swf
This is tested with the exporter of ruffle-rs @ a472005f1be668a79f74a25ef86b893523797b6d
Note that I also omitted the following failures:
2381,7546: 404 error (nothing to do here)- ~
2674: "Error decompressing SWF, may be corrupt: Adler32 checksum mismatched: value=1972812811, expected=2019525023"~ 3099: actually an MP4 file (nothing to do here)- ~
4399,6858,6975,7101,7144,7242,7246,7293,7522,7673,7758: "Support for LZMA compressed SWFs is not enabled."~ (--features lzma) - ~
6969: "Error decompressing SWF, may be corrupt: failed to fill whole buffer"~
Thank you for the report, this is extremely helpful!
We'll take a look and probably split off some issues later, but off-the-bat I can say that you can enable lzma support for those skipped swfs by passing --features lzma to cargo, provided that you have https://tukaani.org/xz/ installed.
Per discussion on Discord, the empty frames is because a lot of these swfs are videos - blocked on #723
For 1724 it does eventually load for me, but it's incredibly slow in the following block of code:
function trim(trimmed)
{
var _loc1_ = trimmed.length;
lfound = false;
while(!lfound)
{
_loc1_ = _loc1_ - 1;
if(trimmed.charAt(_loc1_) != " ")
{
lfound = true;
}
}
return trimmed.slice(0,_loc1_ + 1);
}
v_title = trim(" ");
v_url = trim(" ");
eventpar = trim(" ");
subs = trim(" ");
chapter = trim(" ");
swfset = trim("75`~,100 ");
I think that's a good case for us to look at avm performance. There's two hits - the actual computation, and then GC churn on the next frame.
We'll take a look and probably split off some issues later, but off-the-bat I can say that you can enable lzma support for those skipped swfs by passing
--features lzmato cargo, provided that you have https://tukaani.org/xz/ installed.
Thanks, I did that and I can confirm none of them triggers another specific issue.
Per discussion on Discord, the empty frames is because a lot of these swfs are videos - blocked on #723
z0r.de is indeed video-clip / loop oriented, so it's no surprise many of these swfs are affected by this. Using several checksums, I estimated around 2500/7900 blank white previews, which are likely from that specific issue. Many other may be affected one way or another.
For the record, the gallery is available here on https://ubitux.github.io/z0r/, with the code at https://github.com/ubitux/z0r/ if you want to experiment with it. The Makefile gives some hints about the current state of exceptions for ruffle, how to grab the swfs yourself etc.
Followup on the current state.
I updated the index with latest revision (a0159a5efaf9cb29f3d0e5b4a1e1173ad811728a), and here is the current state:
- ~~4167 and 6009 crash with
Error in Queue::write_texture: copy of 0..173352 would end up overruning the bounds of the Source buffer of size 57784 (src/backend/direct.rs:130:9)~~ - ~~1703, 1931~~, 2021, ~~6212~~ either infinite loop (or extremely slow)
- The elephant in the room: many previews are still white because of the missing video decoding
From the original report, only 2021 remains (which means 12/13 were fixed), but the 5 other reported here were new regressions. Strangely, 2674 and 6969 started working again, but it might have been a fix on z0r.de side.
AFAIK All of the reported "infinite loops" should be fixed with https://github.com/ruffle-rs/ruffle/pull/4339 .
AFAIK All of the reported "infinite loops" should be fixed with #4339 .
I confirm for 1703, 1931 and 6212, but 2021 still has the issue (worse, it membombs my machine).
So, this issue essentially got reduced to #2435?
So far it seems so currently yes (only z0r 2021 needs to be skipped) but I do have one regression (since a very long time now): a lot of swf are now giving a white preview (which was not always true). It seems to correspond to the white flash we get for the first (few?) frames in many of the swf. Using --skipframes with the exporter doesn't seem to help.
Here is an example: ~/src/ruffle/target/release/exporter --skipframes 50 --frames 1 -s --width 128 --height 80 swf/z0r-de_4097.swf /tmp/x.png. Same with 4098 and actually tons of them.
Note that it's logging out "Saved first frame of swf/z0r-de_4097.swf to /tmp/x.png", which may imply that --skipframes is being ignored.
Edit: to illustrate, here is the range of preview of z0r 4096 to 4352:
On 2021-08-22:
Now (2023-05-06):
