Pick delta pad earlier during header parsing, and pick it based
on whether it's a video stream or not rather than some rather
byzantine signalling from theoraenc etc. which would set the delta
flag on header packets which oggmux would then pick up and determine
that this is a "delta-able" stream.
Since the new videodecoder-based theoraenc didn't do that any more,
we would only see the first delta flag on the second video packet,
which is after we've already muxed a few audio packets flagged as
key units, which trips up the unit test.
Fixes pipelines/oggmux unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=679958
A crafted file with invalid pages will cause repeated searches from
earlier offsets in steps of 8500 bytes, but reading till the end of
the stream. Since we know the maximum size of an Ogg page, we can
bound the search for next page, to get a linear behavior (though
still not good enough as it will read the entire file backwards if
there's no valid page till then).
Take chain lock when accessing chains. Fall back gracefully
when there's no current chain Hopefully fixes crash when
seeking in Jamendo or Magnatune streams in Amarok.
https://bugzilla.gnome.org/show_bug.cgi?id=675609
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.
This reverts commit 5df30c1b90.
I must have dreamt the Valgrind logs, reverting this reintroduces
no leak, and gets rid of the test failures it introduced :S
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.
Pads are initialized twice: when requesting pads and when
initializing collectpads. Avoid double initialization by
checking if collectpads are still going to be initialized when
creating request pads.
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
Opus streams outside of Ogg may not have headers, and oggstream
may be used by oggmux to mux an Opus stream which does not come
from Ogg - thus without headers.
Determining headerness by packet count would strip the first two
packets from such an Opus stream, leading to a very small amount
of audio being clipped at the beginning of the stream.
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
