Ogg opus file load/playback issues when length > approx 12h
Categories
(Core :: Audio/Video: Playback, defect)
Tracking
()
People
(Reporter: itzexor, Unassigned)
Details
Attachments
(1 file)
|
687.17 KB,
application/octet-stream
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:108.0) Gecko/20100101 Firefox/108.0
Steps to reproduce:
Load a large ogg opus file via file:// or served streaming from a remote server.
Actual results:
There is a very large delay in starting playback or seeking. The delay for a 20 hour file direct via file:// is approx 15-20s on my machine. Additionally, the built in player only works up to 12h 25m 39s.
Expected results:
File should play immediately like a smaller file does. Player should support actual file duration.
The attached test file is just filled with silence. The actual files in question contain copyrighted audio and can't be shared here. Since the test file is so much smaller and also compression_level 0, it actually loads immediately but still exhibits seeking delay and the player time truncation.
|
||
Comment 2•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
I have since discovered that this issue seems to only affect Linux. Someone has told me the windows client plays such files fine, and I have tested on Firefox Android and did not have issues.
Additionally, the same non-working ogg opus file (basically any > 12h) works perfectly if remuxed to opus webm with no other changes.
for ex a command like
$ opusenc 15_hours.wav 15_hours.opus
creates a 15 hour ogg opus that does not play properly in firefox linux
if you simply remux it
$ mkvmerge -o 15_hours.webm -w 15_hours.opus -> plays perfectly, even at 60 hours long
it now works without any reencode
Bonus bug: multi-segmented-track webm files don't seek properly... I don't actually know what it's called but if you multiplex multiple individual ogg opus files into a single webm track, then it plays okay but doesn't seek properly.
ex for multi-segment-track mux
$mkvmerge -o muxed.webm -w part1.opus + part2.opus + part3.opus
I don't know if this is even a standard webm format, but it plays in other things properly. I was testing this method before testing the "single-segment-track opus webm" since I expected the single huge track to break the same way whether in ogg or webm. It didn't.
|
|
||
Comment 5•2 years ago
|
||
The severity field is not set for this bug.
:jimm, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Updated•2 years ago
|
Still happening on 113.0.2 linux 64 bit, here's a screen cap using the attached ogg opus file, and a webm remux[comment 3]:
https://s12.gifyu.com/images/SuTcM.gif
as of january 23 2024 it still truncates test ogg opus playback to 12:25:39 on:
121.0.1 (64-bit) arch linux package
122.0 (64-bit) mozilla-flatpak
|
||
Comment 9•10 months ago
|
||
Took forever to sync to 05:33:52
Truncated playback @ 12:25:39
Mozilla Firefox 124.0.1
Linux latitude 6.5.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Mar 12 10:22:43 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
Just worked fine on Chrome and Epiphany/GNOME web so there's at least two other engines without issue in this configuration where Firfox fails, confirms itzexor.
|
|
||
Comment 10•10 months ago
|
||
I was also able to confirm that this occurs when trying to play a file through the file:// url notation.
I found it rather frustrating that FF would not play the file on my nfs mount... I get that when I moved it locally to my /cache drive which is a symlink to /dev/shm/cache that there might be some security issues there, but it should play an nfs share. Why do I have to go through all these machinations and why isn't the error message better — just to get the file to play?
|
|
||
Comment 11•10 months ago
|
||
I looked up a bind mount https://unix.stackexchange.com/questions/30637/mount-error-is-not-a-block-device so that I could mount /dev/shm as an actual directory /cache and it still refuses to play the perfectly comulent path.
VLC? Plays.
Chrome? Plays.
Firefox? Makes me jump through hoops to play media and it's gotta be local and it's gotta be in ... .
Description
•