The edit rate is only supposed to be the same in a source package, but there
might be multiple source packages with the same essence container. As such
just comparing the body/index SID is not sufficient.
Rectangle textures don't use normalized coordinates so subsampling needs to be
factored in explicitly.
Fixes YUV => RGB conversion for rectangle textures.
This was completely broken before and could only work on a very constrained
set of files. After these changes it should work except for situations where
PTS != DTS, which is not handled at all in mxfdemux currently.
https://bugzilla.gnome.org/show_bug.cgi?id=759118
According to S377-1-2009c 9.2 the local tags must not be resolved from the
primer pack, which as a result means that there can't be any other tags than
statically assigned ones.
Setting the seek flags to GST_SEEK_FLAG_SNAP_* will change the seek
target time to a segment boundary.
Based on original work by Ben Willers <bwillers@digisoft.tv>.
https://bugzilla.gnome.org/show_bug.cgi?id=759108
Dashdemux has set the width and height information from MPD manifest.
Some embedded devices which are not insufficient H/W resources need more information such as framerate
to assign H/W resources. So I suggested that dashdemux also needs to set the framerate information from MDP manifest.
https://bugzilla.gnome.org/show_bug.cgi?id=758515
This is to support byte-stream decoder that does not remember the
PPS/SPS after a flush. This is not needed by all decoders, but is
harmless for those that do remember.
https://bugzilla.gnome.org/show_bug.cgi?id=758405
To use GLMemory and EGLImage allocators, one need to know the
libgstgl API. This is only expected if the associated caps features
have been negotiated. Generic element that otherwise receive those
allocators may fail, resulting in broken pieline. We don't want to
force all generic element to check if the allocator is a custom
allocator or a normal allocator (which implement the _alloc method).
https://bugzilla.gnome.org/show_bug.cgi?id=758877
As HLS does not provide any way of knowing the server's clock, and we do
buffering of "live" streams, at some point we will fall behind the server in
many cases and would have to advance to a fragment that is not in the playlist
anymore.
Previously we would've just resynced to the next oldest fragment that is still
there, but this causes problems as from this point onwards we would always
fall off the playlist again all the time.
Instead we now resync and move to the 3rd newest fragment like we would do
when starting playback of a live stream.
https://bugzilla.gnome.org/show_bug.cgi?id=758987
The order in which program switch must happen is:
1) drain all data on old pads (but don't push EOS)
2) add new pads (but don't push any data on them)
3) Push EOS and remove old pads
4) Start pushing data on new pads
There was one caveat in this implementation, which is that when
we activate a sparse pad (step 2) we would push a GAP event. The problem
is that, while being an event, it is actually *data*.
We therefore need to make sure pushing those GAP event is done at the step
we start pushing data.
https://bugzilla.gnome.org/show_bug.cgi?id=750402
Before we add any streams, make sure we drain all streams. This ensures
there's consistency that only "new" data will be pushed on buffers once
the new pads are added
https://bugzilla.gnome.org/show_bug.cgi?id=750402
When changing programs, the order of events needs to be the following:
* add pads from new program
* send EOS on old pads
* remove old pads
* emit 'no-more-pads'
Previously tsdemux was not doing that, and was first deactivating and
removing old pads before adding new ones.
We fix this by allowing subclasses of mpegtsbase to be able to handle
themselves the deactivation of programs. In this case tsdemux will
properly deactivate it once it has activated the new program.
https://bugzilla.gnome.org/show_bug.cgi?id=750402
If connection speed is set, playlist according
to connection speed is selected as current playlist.
Problem is that the current variant of main playlist still
points to previously set variant.
If previously set variant doesn't correspond to current
playlist, then it causes unnecessary change of playlist
to the same playlist after first fragment is downloaded,
because of not updated current variant.
To fix this, we need to make sure that current variant
of main playlist corresponds to the current playlist
https://bugzilla.gnome.org/show_bug.cgi?id=758946
Don't jump backward to 3 files from the end of the playlist
when switching variants - it just means we downloaded
fragments fast and caught up to the end of the playlist.
Disable that by treating a variant switch as a playlist
update, not a restart due to a seek or so.
