After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 632167 - [oggdemux] doesn't parse/push all headers in pull mode
[oggdemux] doesn't parse/push all headers in pull mode
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal blocker
: 0.10.31
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-10-14 18:31 UTC by David Schleef
Modified: 2010-10-29 11:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
possible patch (1.89 KB, patch)
2010-10-29 10:57 UTC, Wim Taymans
accepted-commit_now Details | Review

Description David Schleef 2010-10-14 18:31:58 UTC
On most streams with kate subtitles, oggdemux does not read (and queue) all the headers of the kate streams before starting to push buffers downstream.  This causes the kate decoder to get confused and error out.

File: http://www.schleef.org/~ds/whatever.ogv

(This also happens with sintel-1280.ogv)

'gst-launch filesrc location=whatever.ogv ! oggdemux ! subtitle/x-kate ! fakesink -v' shows only 5 headers sent downstream.

'oggz-dump whatever.ogv' shows that there are 8 kate headers.

The gstoggstream code correctly reports that there are 8 kate header packets, so it's somewhere in the demuxer code itself that decides to start sending packets too soon.
Comment 1 Sebastian Dröge (slomo) 2010-10-25 14:12:03 UTC
The problem here seems to be, that gst_ogg_demux_read_chain() stops at header 5 because it reads at EOS for some reason.
Comment 2 Sebastian Dröge (slomo) 2010-10-25 14:22:21 UTC
This file also has non-header packets for the Vorbis/Theora stream before all headers packets for the Kate stream are there. IIRC this is not allowed.
Comment 3 Sebastian Dröge (slomo) 2010-10-25 14:47:46 UTC
So gst_ogg_demux_read_chain() iterates over all pages, looks at all packets and everything... but for some reason stops with EOS. Later on after starting the streams it pushes all 9 header buffers.
Comment 4 David Schleef 2010-10-27 12:37:36 UTC
(In reply to comment #2)
> This file also has non-header packets for the Vorbis/Theora stream before all
> headers packets for the Kate stream are there. IIRC this is not allowed.

This is incorrect.  The order is bos pages, kate headers, vorbis headers, theora headers, skeleton EOS, then non-header packets.
Comment 5 Sebastian Dröge (slomo) 2010-10-28 13:17:04 UTC
I guess I misread the debug log then. oggdemux is really confusing and hard to debug ;)
Comment 6 Wim Taymans 2010-10-29 10:57:16 UTC
Created attachment 173468 [details] [review]
possible patch

broken by commit 6357bdef63b1f6fca0890c1b98132e5ba54f71df
Comment 7 Sebastian Dröge (slomo) 2010-10-29 11:03:46 UTC
Looks good and makes sense. oggdemux needs some more cleanup after the release I guess, to get rid of all the other old things everywhere ;)
Comment 8 Wim Taymans 2010-10-29 11:13:39 UTC
commit e0d683f3ed13e66fc9054a85a1bfec2618583006
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Fri Oct 29 11:48:18 2010 +0100

    oggdemux: fix wrong flowreturn handling
    
    Oggdemux will currently try to pad alloc a buffer from the peer when it is
    reading the header files. This is a relic from the time where we had an internal
    parser and needs to be removed at some point in time.
    
    The problem is that when there is no peer pad yet (which is normal when
    collecting headers) we should still continue to parse all the packets of a
    page instead of erroring out on NOT_LINKED.
    
    Fixes #632167