They're hardly used, and probably more confusing than anything
else, and it's not clear that anyone would really need to be
able to tell them apart at the media type level.
This never really took off - it's hardly used anywhere
and deprecated in favour of Kate. Exposing pads just
leads to confusing 'you are missing a plug-in' messages
when people come across such streams. We could still post
the data on the bus for applications to parse.
In case many packets fit on a page, we may not see a granpos for
a while, and granpos interpolation can wrap the 'frames since last
keyframe' part of the granpos, generating a granpos which is smaller
than what it should be.
This is fixed by detecting keyframe packets (at least for Theora),
and updating the last keyframe granpos from this.
This may still be generating potentially wrong granpos for streams
which have a Theora like granpos (keyframes, a max keyframe distance
and a count of frames since last keyframe), and which allow implicit
granules on packets. For these streams, a custom keyframe detection
routine should be plugged into their GstOggStream mapper.
https://bugzilla.gnome.org/show_bug.cgi?id=669164
When I first implemented push mode seeking, I removed the chain
freeing there as it could be used later. The current code does not
seem to do that though, so I'm restoring the previous freeing,
which plugs the leak while apparently not reintroducing use of
freed data with chained and normal files, both with gst-launch
playbin2 and Totem.
A first hang was happening when trying to locate a page backwards,
where we'd sync forever on the same page.
With that fixed, a second hang would happen after preparing an EOS
event, but with no chain created yet to send it to, the pipeline
would stay idle forever.
An element error is now emitted for this case.
This prevents trying to seek and failing, then ending up unable
to stream because we can't get back at the headers.
A more robust way would be to find a good place to reinject the
headers when a seek fails, but I can't seem to get this to work.
Add private replacements for deprecated functions such as
g_mutex_new(), g_mutex_free(), g_cond_new() etc., mostly
to avoid the deprecation warnings. We'll change these
over to the new API once we depend on glib >= 2.32.
Replace g_thread_create() with g_thread_try_new().
If we already saw the keyframes that we need to find,
we do not need to bisect to find them.
This will always be the case for streams with audio only,
where each frame acts as a keyframe, but will occasionally
also happen for streams with video.
https://bugzilla.gnome.org/show_bug.cgi?id=662475
In push mode, we determine duration by doing a seek to the end of the
stream. However, a skeleton stream with an index will cause the duration
to be known already, and we end up never setting the push_time_duration
variable which we use to know duration has been determined.
https://bugzilla.gnome.org/show_bug.cgi?id=662049
The codec setup headers are a lot more likely to have correct information,
especially as it's easy to remux a skeleton in a file where streams don't
have the same parameters (I've even seen a file with two skeletons).
Still, this is useful in the case we have a codec we can't decode, so we
can at least (theoretically) convert granpos to time, so we discard this
information if the codec setup has already provided it.
This fixes playback on (at lesat) the original archive.org encoding of
"The Night of the Living Dead" (now replaced by another encoding).
https://bugzilla.gnome.org/show_bug.cgi?id=612443
This could happen when testing with navseek, and pressing
right and left at roughly the same time. The current chain
is temporarily moved away, and this caused the flush events
not to be sent to the source pads, which would cause the
data queues downstream to reject incoming data after the
seek, and shut down, wedging the pipeline.
Now, I can't really decide whether this is a nasty steaming
hack or a good fix, but it certainly does fix the issue, and
does not seem to break anything else so far.
https://bugzilla.gnome.org/show_bug.cgi?id=621897
This patch implements seeking in push mode (eg, over the net)
in Ogg, using the double bisection method.
As a side effect, it also fixes duration determination of network
streams, by seeking to the end to check the actual duration.
Known issues:
- Getting an EOS while seeking stops the streaming task, I can't
find a way to prevent this (eg, by issuing a seek in the event
handler).
- Seeking twice in a VERY short succession with playbin2 fails
for streams with subtitles, we end up pushing in a dataqueue
which is flushing. Rare in normal use AFAICT.
- Seeking is slow on slow links - byte ranges guesses could be
made better, decreasing the number of required requests
- If no granule position is found in the last 64 KB of a stream,
duration will be left unknown (should be pretty rare)
https://bugzilla.gnome.org/show_bug.cgi?id=621897
The first packet of a sparse stream may arrive after an initial
delay in the stream. If ogg_stream_packetout reports a discontinuity
in a sparse stream, do not propagate it to other streams in the
chain unnecessarily.
https://bugzilla.gnome.org/show_bug.cgi?id=621897
After all, we do hope to find actual data for these streams.
However, warn if we could not set up a chain when we find a
non BOS page, as that means we don't have a valid Ogg stream.
https://bugzilla.gnome.org/show_bug.cgi?id=657151
While the casual reader might end up bewildered by just why this
change might increase clarity, it just happens than, in the libogg
and associated sources, op is the canonical name for an ogg_packet
whlie og is the canonical name for an ogg_page, and reading this
code confuses me.
https://bugzilla.gnome.org/show_bug.cgi?id=657151
Headers are inherently durationless.
Instead, set duration to 0 to avoid increasing tracked granpos,
and do not warn about it, since it is totally expected.
https://bugzilla.gnome.org/show_bug.cgi?id=657151
If ints are 64 bits, 32 bits should get promoted in varargs anyway,
and we don't care about 16 bit ints.
This makes the code a lot more readable, and still gets us nice
hexadecimal 32 bit serialnos.
https://bugzilla.gnome.org/show_bug.cgi?id=656775
This was causing keyframe_granule to be set to 0 for all streams
when seeking to the beginning of the stream, i.e., at the
beginning of playback. Fixes#619778.
allocate buffers using gst_buffer_new_and_alloc() instead of
gst_pad_alloc_buffer_and_set_caps(), as the first one will
cause the pad to block, and we don't want that since that will
prevent subsequent pads from being fed if a block occurs at
start, when all pads must be fed for playback to start.
This fixes autoplugging of the tiger element and other things.
https://bugzilla.gnome.org/show_bug.cgi?id=637822
