Size parsing of Vorbis failed for a OGG Theora file

RESOLVED FIXED

Status

()

RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: zikzakfr, Assigned: cajbir)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a2pre) Gecko/20080816020720 Minefield/3.1a2pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a2pre) Gecko/20080816020720 Minefield/3.1a2pre

When I try to display a OGG Theora file with the video tag I get the following error message in my terminal:
WARNING: size parsing failed for VORBIS mode packets

Same issue with maintream Theora code and the latest SVN code.

Reproducible: Always

Steps to Reproduce:
1.visit http://home.tele2.fr/crossover
2.check the terminal used to launch firefox
3.
Actual Results:  
WARNING: size parsing failed for VORBIS mode packets
and what seems to be the first frame of the video
Component: File Handling → Video/Audio
Product: Firefox → Core
QA Contact: file.handling → video.audio
Version: unspecified → Trunk
(Reporter)

Comment 1

10 years ago
It is still happening with Minefield/3.1b1pre
WARNING: size parsing failed for VORBIS mode packets

http://home.tele2.fr/crossover
video file is: http://home.tele2.fr/crossover/256.ogg

ogginfo 256.ogg:
Xiph.Org libVorbis I 20070622 (1.2.0)
Theora stream 1:
        Total data length: 2057580 bytes
        Playback length: 0m:41.149s
        Average bitrate: 400,015553 kb/s
Vorbis stream 2:
        Total data length: 116567 bytes
        Playback length: 0m:41.168s
        Average bitrate: 22,651424 kb/s

Comment 2

10 years ago
I can also "WARNING: size parsing failed for VORBIS mode packets" in console, but video can starts if I add controls attribute and start it. So problem is just with parsing and message?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080920033605 Minefield/3.1b1pre
(Reporter)

Comment 3

10 years ago
Exact it works.
Then this video parameter is not handeld properly, even set at 'false' it is still displayed to the user.

Updated

10 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 4

10 years ago
zikzak, what parameter is not handled properly? What parameter, when set at 'false', is still displayed to the user?
(Reporter)

Comment 5

10 years ago
controls, of course.
Looks like the controls parameter is not ready yet.
Clicking on 'stop' acts like clicking on 'pause', the video is not returning to the start of the file.

http://home.tele2.fr/crossover
You can see that controls=false there.
(Assignee)

Comment 6

10 years ago
'controls=false' in HTML means the same as 'controls=true'. It's the absence of the controls attribute that means no controls. See here for example:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/016159.html

So behavior of that works correctly. Video not returning to the start of the file is bug 449154.
(Reporter)

Comment 7

10 years ago
Ok, now I see the point.
I used w3schools page about the video tag to create my test.
Firefox is compliant with http://www.w3.org/html/wg/html5/#controls

Is the 'controls' parameter mandatory to play the file ? I can not find a statement about it in the W3c draft.

Comment 8

10 years ago
> Is the 'controls' parameter mandatory to play the file ?

It isn't. You can use just

<video src="" autoplay>  /* but user cannot control or even stop video here */

or better:

<video src=".." onclick = "if (this.paused) this.play(); else this.pause()"> /* user can play/stop video just by clicking */

Attr controls is usefull only if page author doesn't provide other way for video control.
(Assignee)

Comment 9

10 years ago
Created attachment 345022 [details] [diff] [review]
Wrap stdout printf statement in #ifdef DEBUG
Assignee: nobody → chris.double
Status: NEW → ASSIGNED
(Assignee)

Comment 10

10 years ago
Created attachment 345024 [details] [diff] [review]
Use #ifdef not #if

See annodex ticket 431:

http://trac.annodex.net/ticket/431
Attachment #345022 - Attachment is obsolete: true
(Assignee)

Updated

10 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.