521863 - Vorbis audio file with enormous hole in it refuses to play.

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Gregory Maxwell]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091008 Minefield/3.7a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091008 Minefield/3.7a1pre

This audio file was created by using vcut on a large stream. Firefox just gives the grey x.

Setting X-Content-Duration to either the duration including or excluding the hole doesn't make it play.  

Chris Double's "oggplayer" plays the file.






Reproducible: Always

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

[08:45]	<gmaxwell>	cpearce: the file has a page with granpos=1024. ... then it picks up again around 2^31. 

$ OggIndex.exe -d -p bug521863-0.ogg | grep granulepos
[?] page @0 length=58 granulepos=0 time=-1ms s=1492784537 eos=0
[V] page @58 length=4210 granulepos=0 time=-1ms s=1492784537 eos=0
[V] page @4268 length=88 granulepos=0 time=-1ms s=1492784537 eos=0
[V] page @4356 length=663 granulepos=1024 time=23ms s=1492784537 eos=0
[V] page @5019 length=4200 granulepos=2133998528 time=48389989ms s=1492784537 eos=0
[V] page @9219 length=4258 granulepos=2134011840 time=48390291ms s=1492784537 eos=0
[V] page @13477 length=4396 granulepos=2134024128 time=48390569ms s=1492784537 eos=0
[V] page @17873 length=4342 granulepos=2134036416 time=48390848ms s=1492784537 eos=0
[V] page @22215 length=4146 granulepos=2134047680 time=48391103ms s=1492784537 eos=0
[V] page @26361 length=4187 granulepos=2134058944 time=48391359ms s=1492784537 eos=0
[V] page @30548 length=4311 granulepos=2134071232 time=48391637ms s=1492784537 eos=0
[V] page @34859 length=4316 granulepos=2134084544 time=48391939ms s=1492784537 eos=0
[V] page @39175 length=4213 granulepos=2134096832 time=48392218ms s=1492784537 eos=0
[V] page @43388 length=4272 granulepos=2134108096 time=48392473ms s=1492784537 eos=0
[V] page @47660 length=4262 granulepos=2134120384 time=48392752ms s=1492784537 eos=0
[V] page @51922 length=4297 granulepos=2134131648 time=48393007ms s=1492784537 eos=0

Comment 2

[cajbir (:cajbir)]

What is the correct behaviour for the file? Should it pause after granpos 1024 until the time for the 2^31 granpos is hit?

Comment 3

[Chris Pearce [:cpearce (Not reading bugmail)]]

This file has a "huge hole". That is, it starts out at 23ms, and then the next packet has a timestamp of 48389989ms (about 13.5 hours).

There are two problems here. Firstly libfishsound can't handle vorbis comments with no value, e.g. "TITLE=", "ARTIST=". When it encounters them, it calculates their length as 0, and malloc(0) returns NULL, so libfishsound assumes that when malloc returns NULL it's OOM, and aborts.

Secondly, once we fix the above, the sound only plays for a fraction of a second. I suspect liboggplay can't handle the hole in data, we're spinning in our old friend oggplay_step_decoding.

I'll post a WIP patch for the first problem, and I or someone else may come back to the second problem. These problems may go away after the ogg decoder rewrite, depending on how it handles holes.

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to comment #2)
> What is the correct behaviour for the file? Should it pause after granpos 1024
> until the time for the 2^31 granpos is hit?

[08:56]	<gmaxwell>	Totem/gstream 'plays' the hole and even allows you to seek to the part with real audio. I think thats most correct. 

VLC also just skips over the hole and plays seemelessly.

Probably best for us to skip over the hole too.

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: WIP patch to address fishsound problem

WIP patch to fix problem 1.

Comment 6

[Chris Pearce [:cpearce (Not reading bugmail)]]

Conrad: You may want to take this patch upstream in libfishsound as it currently can't handle vorbis comments of he form "ARTIST=" etc. oggz-comment also can't handle them. See URL for testcase file.

Comment 7

[Matthew Gregan [:kinetik]]

It's really hard to read that patch with all that reformatting... but the first
issue sounds like bug 520500.

Comment 8

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to comment #7)
> It's really hard to read that patch with all that reformatting... but the first
> issue sounds like bug 520500.

Yeah, a diff -w wasn't much better unfortunately, and I couldn't stand reading the original code as its indentation was fubar.

Comment 9

[Chris Pearce [:cpearce (Not reading bugmail)]]

We'll fix the libfishsound problem over in bug 520500, since it was here first. We'll additionally need to do something about this "enormous hole in the ogg file" problem.

Comment 10

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to comment #9)
> We'll additionally need to do something about this "enormous hole in the ogg
> file" problem.

Let's do that in this bug.

Comment 11

[Conrad Parker]

(In reply to comment #6)
> Conrad: You may want to take this patch upstream in libfishsound as it
> currently can't handle vorbis comments of he form "ARTIST=" etc. oggz-comment
> also can't handle them. See URL for testcase file.

Applied in commit ac2015dbd72d59208a482de5b0e69e74774e7987

Comment 12

[Chris Pearce [:cpearce (Not reading bugmail)]]

We've got gap detection and silence insertion in the new decoder backend on trunk now, so resolving fixed. We now inject silence to cross gaps, so if you have a gap of N seconds, we will play N seconds of silence.