This patch should improve things when a correct bitrate is configured in the codecs.

commit f9ca4f60975121f73a0683466bb7dae035cd42e3
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Fri Apr 30 17:41:05 2010 +0200

    oggdemux: use bitrate to estimate length in pushmode
    
    Parse the bitrate from the various streams.
    Use the bitrate and the upstream length in bytes to estimate the total stream
    duration in push mode.

For accurate length reporting we need to perform some seeking on the server (get the last page). In push mode this is a little awkward but doable.

when that fails, we should fall back to the estimation code that is currently in git master.

Push mode seeking implementation for oggdemux, and duration determination by seeking to the end of the stream:
http://git.collabora.co.uk/?p=user/vincent/gst-plugins-base;a=shortlog;h=refs/heads/seeking
Please report if this doesn't work with your test cases.

Does it work with Vincent's branch? Also, could we get Vincent's branch merged now or is there anything left to be done? :)

I think it was mostly there for non chained streams. Might need some work porting it though as I haven't touched this branch in ages.
I can't recall if there were remaining issues with chained streams, but I think I might have disabled seeking for those.

Timely ping, I was just working on this again, to move the seeking into the streaming thread, as there is some occasional lockup. Once I get that done and debugged, I'll post an updated patch.

That experiment was not such a good idea, and the wedging issue seem to also be present (though less) with other formats (at least matroska and MP4). So I've just rebased the patch, it's in https://bugzilla.gnome.org/show_bug.cgi?id=621897

This looks quite nifty, seems to work well for me, at least with the stream above (even if a bit slow, but that's the server I think, would be nice to give the user some feedback that something is happening though).


First, a couple of style nitpicks, if I may:

 - in assignments like a = b == c; please do:
        a = (b == c) ,
    also when using the ? operator
    (e.g. close_enough = ...)

 - try to aovid comments "inside" code, e.g.
    /*stop */ twice in submit_page()

 - please leave an empty line between a variable
   declaration and code (even if gst-indent doesn't
   enforce it)

 - avoid comments at the end of long lines, because
   this seems to prevent gst-indent from wrapping
   them (which arguably is a bug, but still), e.g. in
   gst_ogg_demux_get_duration_push(). Put comments
   in a separate line before the code in such cases.


Then:

 - GST_PUSH_{LOCK,UNLOCK}: why not just use the
   sinkpad's stream lock? (which is taken by default
   anyway) (just needs extra care in functions that
   might be called from non-streaming thread such
   as src event/query funcs)

 - GST_PUSH_{LOCK,UNLOCK}: use TRACE debug
   level if you keep the lock

 - maybe use gst_ogg_stream_get_media_type()
   for gst_structure_get_name (gst_caps_get_structure (pad->map.caps, 0))
   (in some GST_DEBUG_OBJECT statement)

 - GST_PUSH_LOCK/UNLOCK should probably be
   inside of
any if (!ogg->pullmode) instead of
   outside of it? (see e.g. submit_packet)

 - in gst_ogg_demux_seek_back_after_push_duration_check_unlock():
    why does the seek back seek to byte 1 instead of byte 0?

 - I'd skip remove the #ifndef GST_DISABLE_GST_DEBUG
    in _submit_page(), there's no real work done in there to
    warrant that besides that if() - it affects readability imho

 - would it be possible to move that huge push-related block
   in submit_page() into a separate function?

 - in submit_page(), should probably post an error message
    using GST_ELEMENT_ERROR when we (if we) return
    GST_FLOW_ERROR (return res ? GST_FLOW_OK : GST_FLOW_ERROR)
    (didn't check if it's propagated upstream though)

 - I wonder if pushing a seek event upstream from the streaming
   thread is really kosher, or if it just happens to work in this case..

Wrong bug, sorry.

*** Bug 661965 has been marked as a duplicate of this bug. ***