Broken URLs generated by the arewecompressedyet.com/analyzer landing page
Opened this issue · 2 comments
Hi folks. There seems to be a "prefix" URL parameter that the web app is misusing. This causes users to visit a non-working or mis-formed URL of the webapp, which in turn causes the demo to error out and not to function.
Steps to reproduce:
- Visit https://arewecompressedyet.com/analyzer/
- Select any
Run,VideoandQPcombination from the dropdown selection interfaces.
2.1 (If you don't select a value for all three fields, theOPENbutton will be insensitive/grayed out and non-functional, but a URL shown below can be copy-pasted instead.) - Press the
OPENbutton below. - Observe that the demo that the webapp has opened does not work.
4.1 Generated URL example: https://arewecompressedyet.com/analyzer/?maxFrames=4&p=https://arewecompressedyet.com/runs/av1-10-11-2019-sp5@2019-10-11T18:33:02.178Z/&d=js/decoder.js&f=objective-1-fast/Netflix_Boat_1920x1080_60fps_8bit_420_60f.y4m-20.ivf
4.2 Error message example: "Loading Decoders Failed: Cannot load decoder, check url: https://arewecompressedyet.com/runs/av1-10-11-2019-sp5@2019-10-11T18:33:02.178Z/js/decoder.js"
Background:
I observe that the generated URL contains a p=[SOME_PATH_HERE] parameter, which I interpret to be taken as a "prefix" for other paths. Thus the webapp takes the value f=[SOME_VIDEO_FILE_HERE] and prepends the value from p=[SOME_PATH_HERE], yielding a final "video file with path: `https://arewecompressedyet.com/runs/av1-10-11-2019-sp5@2019-10-11T18:33:02.178Z/objective-1-fast/Netflix_Boat_1920x1080_60fps_8bit_420_60f.y4m-20.ivf"
Problem:
The webapp also prepends the prefix from p= to the d=[DECODER_FILE_HERE] parameter. Example final "decoder file with path: "https://arewecompressedyet.com/runs/av1-10-11-2019-sp5@2019-10-11T18:33:02.178Z/js/decoder.js" (This is an erroneous path/file that leads to a 404.)
I assume there are generally no AV1 decoders bundled where the AWCY runs are stored, in the runs' respective directories. So the "decoder" parameter should not use the directories used to store AWCY runs as a prefix for the decoder location.
Suggested solution 1
Change the way URLs are generated by the web app. Particularly, not using the p= URL parameter seems easiest. (This implies full paths be given for the f=[SOME_VIDEO_FILE_HERE] and d=[SOME_VIDEO_FILE_HERE] parameters).
OR
Suggested solution 2
Change the way URLs are consumed by the web app. Particularly, not taking the value of p= as a prefix for the decoder parameter d=. (Implies adjusting URL generation to include a full path for the d= parameter, or else this issue would effectively not be fixed.) (Maybe some UI in the URL generation phase for a custom decoder URL/location would be nice?)
OR
Suggested solution 3
Ensure valid decoders are bundled (included in the same folder) with AWCY runs. This would solve the "decoder not found" error, by providing a working decoder at the location the web app currently looks for one.
Workaround is to edit the URL manually.
-
Ensure the
p=[prefix]parameter is removed, since there is apparently no way to construct a valid URL with this parameter included when using the arewecompressedyet.com runs as a video source. -
Use a full path+filename for the
f=[file]parameter. This should be the full URL of a.ivfor.y4mfile available on the public internet. -
Use a full path+filename for the
d=[decoder]parameter. This should be a decoder that can run in the browser, such as: https://people.xiph.org/~mbebenita/analyzer/inspect.jsor https://people.xiph.org/~mbebenita/analyzer/inspect.wasm .[Edit: the web app refuses to loadinspect.wasm.]
https://people.xiph.org/~mbebenita/analyzer/inspect.js is still broken.