Without a specified framerate from the sink, the decoder frame interval
should be set using the framerate of the encoded video stream.
Therefore, the v4l2object should be able to change the framerate on the
output if the V4L2 device accepts it.
This is also necessary for mem2mem encoders so that their bitrate
calculation code may work correctly and they may report the correct
frame duration on the capture queue.
https://bugzilla.gnome.org/show_bug.cgi?id=779466
If the duration of the v4l2object is GST_CLOCK_TIME_NONE, because the
sink did not specify a framerate in the caps and the driver accepts the
framerate, the decoder element uses GST_CLOCK_TIME_NONE to calculate and
set the element latency.
While this is a bug of the capture driver, the decoder element should
not use the invalid duration to calculate a latency, but print a warning
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=779466
The correct behaviour of anything stuck in the ->render() function
between ->unlock() and ->unlock_stop() is to call
gst_base_sink_wait_preroll() and only return an error if this returns an
error, otherwise, it must continue where it left off!
https://bugzilla.gnome.org/show_bug.cgi?id=774945
According to ISO/IEC:14496-2:2009 , in the case of HE-AACv2 (audioObjecType
29) parametric stereo is used (a single mono track is used and then
transformations are applied to it to provide a stereo output).
We therefore report two channels in the case where there is one reported
in the audioChannelConfiguration.
Fixes the various issues where a demuxer would report two channels, but
then the parser would say there's only one channel, and then the decoder
would output two channels.
last_buf is the one we're going to write next, not buf. As such we
should check timestamps against that one if there is one to select the
earliest pad.
Also remember the currently selected pad in the very beginning when
storing the first last_buf.
This both solves some edge cases where not the correct next pad was
selected corresponding to the target interleave.
This is an update of d78d589627
We still exit as early as possible in case of non-ok/non-unlinked combined
flow, but we first make sure that we update the internal position variables.
This ensures that if upstreams "ignores" the flow return (and carries on pushing),
we don't end up processing data with completely bogus variables/positions.
If self->channel_positions == NULL (which seems unlikely),
self->default_channels_ordering_map will be used unintialised.
We avoid that by keeping track of the channel_mask, which is set when
the ordering map is initialised.
https://bugzilla.gnome.org/show_bug.cgi?id=780331
When there are more than 64 channels, we don't want to exceed the
bounds of the ordering_map buffer, and in these cases we don't want to
rempa at all. Here we avoid doing that.
https://bugzilla.gnome.org/show_bug.cgi?id=780331
TFDTs with time 0 are being ignored since commit 1fc3d42f. They're
mistaken with the case of not having TFDT, but those two cases
must be distinguished in some way.
This patch passes an extra boolean flag when the TFDT is present.
This is now the condition being evaluated, instead of checking for
0 time.
https://bugzilla.gnome.org/show_bug.cgi?id=780410
If we have multiple tracks with timecodes, or it's not the first track
that has timecodes, or not the first buffer, we already started a chunk
for media data. We now need to "close" that chunk because we wrote data
for the timecode track and a new chunk has to be started for the
original track the next time it has data.
Similar to what was done in adaptivedemux, ignore seek
events we've already handled - such as when they are received
on every srcpad of files with lots of streams.
Otherwise mdatleft will have a value calculated from the initial
mdatsize minus the parts of the stream that we saw, which is not
including all the parts of the stream that might've been skipped.
This breaks gst-validate on the build server (though not locally),
and a unit test, and I can't run unit tests right now for some
unrelated reason.
This reverts commit 0747b56f8e.
This debug statement is meant to print the time since the last (early)
RTCP transmission, not the last regular RTCP transmission (which also
happens to be set a few lines above to current_time, so the debug output
is just confusing)
Take into account the atoms at the end of the 'trak' atom when
recovering it. So that its size (already computed and added in the trak
size) isn't making offsets wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=771478
That example only tested the property probe interface, which has been removed.
The same kind of thing can now be done with the generic gst-device-monitor tool.
