Even if watch->messages->length is 0 there may still be some
data from a message that was only written partially at the
previous attempt stored in watch->write_data, so check for
that as well. We don't want to write data into the middle
of another message, which could happen when there wasn't
enough bandwidth.
https://bugzilla.gnome.org/show_bug.cgi?id=669039
... so subclass can also rely upon never being bothered with some NULL buffer
it can't do any interesting with, or with any data before it received
any format configuration (and setup properly).
If we don't get a duration right away, set the pipeline to playing
and sleep a bit, then try again. This is ugly, but the least worst
we can do right now. The alternative would be to make parsers etc.
return some bogus duration estimate even after only having pushed
a single frame, for example.
Fixes discoverer showing 0 durations for some mp3 and aac files
(e.g. soweto-adts.aac).
Only return LIKELY probability if we've seen an SPS, PPS and an
IDR slice nal, i.e. try harder to avoid false positives such
as with certain VC-1 files.
https://bugzilla.gnome.org/show_bug.cgi?id=668565
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
It was matching non header packets.
This fixes various leaks, where buffers would be pushed onto a headers
list, but never popped.
Might also fix corruption as those buffers were dropped from the output
silently...
https://bugzilla.gnome.org/show_bug.cgi?id=669167
This is necessary in order to match what the caps strings in
video.h contain for 16-bit rgb formats and also to match how
gst_video_format_parse_caps expects them.
https://bugzilla.gnome.org/show_bug.cgi?id=667681
