You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Select any Run, Video and QP combination from the dropdown selection interfaces.
2.1 (If you don't select a value for all three fields, the OPEN button will be insensitive/grayed out and non-functional, but a URL shown below can be copy-pasted instead.)
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.
The text was updated successfully, but these errors were encountered:
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 .ivf or .y4m file available on the public internet.
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:
Run
,Video
andQP
combination from the dropdown selection interfaces.2.1 (If you don't select a value for all three fields, the
OPEN
button will be insensitive/grayed out and non-functional, but a URL shown below can be copy-pasted instead.)OPEN
button below.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 valuef=[SOME_VIDEO_FILE_HERE]
and prepends the value fromp=[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 thed=[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 thef=[SOME_VIDEO_FILE_HERE]
andd=[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 parameterd=
. (Implies adjusting URL generation to include a full path for thed=
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.
The text was updated successfully, but these errors were encountered: