GNOME Bugzilla – Bug 679567
oggmux: support muxing content without natural duration
Last modified: 2012-08-12 07:59:51 UTC
Oggmux intentionally eats seeek events without any obvious reasons. Removing that fixes recording a segment. See http://buzztard.git.sourceforge.net/git/gitweb.cgi?p=buzztard/buzztard;a=blob;f=design/gst/encode.c;hb=HEAD for a standalone example.
Created attachment 218238 [details] [review] fix muxing a segment If we don't want to allow seeking, we could let seeks with start=0 through.
If you create a file like that, does it pass oggz-validate? ogg demuxers will not expect and poorly handle random discontinuities in the stream. You could make the muxer finish the old chains and start a new chain with new headers/serial numbers etc. though, but that takes some more work and might also need encoder support.
oggz-validate did not complain about the vorbis-ogg nor the flac-ogg. In my case I have a stream without natural duration (audiotestsrc) and I need to seek to set the duration. If this should be done differently, I am all ears.
Created attachment 218387 [details] [review] allow initial seeks that set stop pos
I have a similar patch for 0.11
> I have a similar patch for 0.11 Can we please only do this in 0.11 and not mess with it in 0.10 any more? You'd also need to make sure that oggmux either gets all the headers from caps *or* has already received the header packets in-band, since someone could do a flushing seek and flush headers before they arrive, which would not make for a good ogg stream later. It would be even better if we could fix this for the general case. This needs someone to investigate what happens when we do a flushing seek to the middle of the stream - if oggmux will just create continuous timestamps or not (and if not, if we can just offset them after the seek). I'd rather see the general case fixed.
Created attachment 218575 [details] [review] only drop flushing seeks after we started # non flushing seeks (first seek at start) ./oggmux 0; oggz-validate oggmux.ogg; gst-discoverer-0.10 oggmux.ogg seek accepted seek accepted seek accepted seek accepted Analyzing file:///home/ensonic/projects/buzztard/buzztard/design/gst/oggmux.ogg Done discovering file:///home/ensonic/projects/buzztard/buzztard/design/gst/oggmux.ogg Topology: container: Ogg audio: Vorbis Properties: Duration: 0:00:27.196371882 Seekable: yes Tags: container format: Ogg encoder: Xiph.Org libVorbis I 20090709 encoder version: 0 nominal bitrate: 80000 bitrate: 80000 audio codec: Vorbis # flushing seeks (first seek at start) ./oggmux 1; oggz-validate oggmux.ogg; gst-discoverer-0.10 oggmux.ogg seek accepted seek failed seek failed seek failed Analyzing file:///home/ensonic/projects/buzztard/buzztard/design/gst/oggmux.ogg Done discovering file:///home/ensonic/projects/buzztard/buzztard/design/gst/oggmux.ogg Topology: container: Ogg audio: Vorbis Properties: Duration: 0:00:30.109024943 Seekable: yes Tags: container format: Ogg encoder: Xiph.Org libVorbis I 20090709 encoder version: 0 nominal bitrate: 80000 bitrate: 80000 audio codec: Vorbis
Created attachment 218577 [details] test app
(In reply to comment #6) > > I have a similar patch for 0.11 > > Can we please only do this in 0.11 and not mess with it in 0.10 any more? The patch is very small, I'd like to get it fixed on both branches. > > You'd also need to make sure that oggmux either gets all the headers from caps > *or* has already received the header packets in-band, since someone could do a > flushing seek and flush headers before they arrive, which would not make for a > good ogg stream later. > > It would be even better if we could fix this for the general case. This needs > someone to investigate what happens when we do a flushing seek to the middle of > the stream - if oggmux will just create continuous timestamps or not (and if > not, if we can just offset them after the seek). flushing seeks in the middle of the steam create broken files. > > I'd rather see the general case fixed. No problem with that.
Comment on attachment 218575 [details] [review] only drop flushing seeks after we started similar patch on 0.11
commit 493bc1236c14483a38f6360b25fa364fb8248979 Author: Stefan Sauer <ensonic@users.sf.net> Date: Tue Jul 10 07:59:59 2012 +0200 oggmux: only drop flushing seeks after we started to mux Don't drop all seek events. It is okay to seek before we send the headers. Non flushing seeks are okay at any time later as well.
There seems to be some confusion here. Before the change: * oggmux rejects all seeks, without even a comment in the code why * this can make applications hang indefinitely (no eos/segment_done) After the change: * it makes sense to reject seeks while muxing * we have narrowed down the conditions when we reject seeks * applications don't need to special case oggmux when encoding generated content As with any other change, if someone find a regression, this change can be reverted or corrected.
You're leaking the event in the "eat" case btw.
commit 4d22a0b57c6aa7bf30e6c0fe2f9116901ebca2c1 Author: Stefan Sauer <ensonic@users.sf.net> Date: Sun Aug 12 09:58:34 2012 +0200 oggmux: don't leak the event in the 'eat' case