When initializing a timecode from a GDateTime, and the remaining time
until the new second is less than half a frame (according to the given
frame rate), it would lead to the creation of an invalid timecode, e.g.
00:00:00:25 (at 25 fps) instead of 00:00:01:00. Fixed.
https://bugzilla.gnome.org/show_bug.cgi?id=779866
Use G_GUINT64_FORMAT for guint64 values.
Introduced by fcb63e77a9
Found by Alexander Larsson
gstvideodecoder.c: In function 'gst_video_decoder_have_frame':
gstvideodecoder.c:3312:51: error: format '%u' expects argument of type 'unsigned int', but argument 8 has type 'guint64 {aka long long unsigned int}' [-Werror=format=]
The expanded 4 second buffering was making radio streams that are
being delivered at real-time speeds too slow. We might need
a better plan for matching the queue2 size to incoming bitrate
in the absence of tag information or timestamping.
In uridecodebin, it used tags on the output of decodebin to
adjust the queue2 buffering, but urisourcebin doesn't have that
view - decodebin is downstream from us.
Use new message notify API and print caps and taglists in a nicer
to read way, just like gst-launch-1.0 does nowadays, without
escaping everything three times.
Fix various issues with reverse playback by clearing tracking
vars when working in reverse, and where possible using the
timestamp interpolation code to generate timestamps for
outgoing buffers. Make sure to mark things as discontinuous
only when looping backward to a new position and fix seeking
to the next page when starting.
In gst_ogg_demux_do_seek() when calculating the
keyframe time, account for a non-zero start-time
Handle a discontinuous first packet in
gst_ogg_demux_setup_first_granule() because that's pretty
normal after a seek. Also differentiate between a genuinely
truncated first packet and just bailing out early, by not using
granule = -1 as an error code.
Make the debug output logs clearer about which timestamps
are stream times (PTS) and which are ogg timestamps.
Don't guess a timestamp of the start of the segment when running
in reverse mode, as more likely it means we're discontinuous somewhere
in the middle of the segment, and we'll fix up timestamps once
the frames are decoded and reversed.
When a PTS is not set, we still want to store the rest of the
buffer information, or else we lose important things like the
duration or buffer flags when parsing.
This is a followup commit to b95725c37e
* Resetting the decoder should only happen when we get a new initialization
header (0x01) and not on the other headers
* The initialized variable only gets set to TRUE once all headers have
been parsed. Also check if the vorbis_info struct has been properly resetted
also. Failure to do that would cause vorbisdec to error if it got
two initialization header in a row (the first would configure the underlying
library and the second one would error out because it's already initialized)
https://bugzilla.gnome.org/show_bug.cgi?id=779515
This adds a property to select the maximum number of threads to use for
conversion and scaling. During processing, each plane is split into
an equal number of consecutive lines that are then processed by each
thread.
During tests, this gave up to 1.8x speedup with 2 threads and up to 3.2x
speedup with 4 threads when converting e.g. 1080p to 4k in v210.
https://bugzilla.gnome.org/show_bug.cgi?id=778974
In gst_video_time_code_is_valid, also check for invalid
ranges when using drop-frame TC. Refactor some code which
broke after the check was added.
https://bugzilla.gnome.org/show_bug.cgi?id=779010
See https://bugzilla.gnome.org/show_bug.cgi?id=773666
This would ideally be solved in baseparse but that requires further
thought at this point, and in the meantime it would be good to have
rawbaseparse not assert on this but handle it gracefully instead.
It was taking the initial input y-offset from the output value, which
only works for y=0 (in which case both are the same). If y > 0, we would
always stay behind the requested input offset and never ever read
anything from the input.
The parser might do some conversion on a stream but the stream keeps
being the same, and we need to make sure GstDiscoverer detects it is the
case.
https://bugzilla.gnome.org/show_bug.cgi?id=778298
Probe for MultiQueue source pad might receive EOS twice,
the first is fake-eos and the other is actual EOS.
And the slot can be freed with fake-eos/EOS if the slot has no input.
Since slot freeing is async, double free can be possible.
So, decodebin3 needs to remove the probe also with slot freeing.
https://bugzilla.gnome.org/show_bug.cgi?id=777530
