Flv does not support various channels in AAC stream format, for example
flvdemux detect an audio channels of 2(stereo) when the AAC really is 1(mono).
https://bugzilla.gnome.org/show_bug.cgi?id=797275
Flv does support changing the stream type and stream properties
after the headers were started to be written, and for example H264
codec_data changes can be supported.
https://bugzilla.gnome.org/show_bug.cgi?id=797256
For drop-frame framerates, when the expected next max timecode wraps
around at the end of the day, we have to subtract the offset of the
daily jam, otherwise we end up with a duration that's a few frames too
long.
https://bugzilla.gnome.org/show_bug.cgi?id=797270
This allows us to use the GstVideoOverlayComposition API and correctly
handle pre-multiplied alpha, while also only doing the alpha conversion
once instead of twice for the whole frame.
At a later point we can attach the meta to the buffer instead of
blending ourselves if downstream supports that.
https://bugzilla.gnome.org/show_bug.cgi?id=797091
This commit:
1. Reads the WebM and Matroska ContentEncryption subelements.
2. Creates a GST_PROTECTION event for each ContentEncryption, which
will be sent before pushing the first source buffer.
The DRM system id field in this event is set to GST_PROTECTION_UNSPECIFIED_SYSTEM_ID,
because it isn't specified neither by Matroska nor by the WebM spec.
3. Reads the protection information of encrypted Block/SimpleBlock and
extracts the IV and the partitioning format (subsamples).
4. Creates the metadata protection for each encrypted Block/SimpleBlock,
with those informations: KeyID (extracted from ContentEncryption element),
IV and partitioning format.
5. Adds a new caps for WebM encrypted content named "application/x-webm-enc",
with the following new fields:
"encryption-algorithm": The encryption algorithm used.
values: "None", "DES", "3DES", "Twofish", "Blowfish", "AES".
"encoding-scope": The field that describes which Elements have been modified.
Values: "frame", "codec-data", "next-content".
"cipher-mode": The cipher mode used in the encryption.
Values: "None", "CTR".
https://bugzilla.gnome.org/show_bug.cgi?id=765275
Strip ADTS headers if we detect any, apparently some Sony cameras
send AAC with ADTS headers. We could also change the stream-format
in the output caps, but that would be unexpected to pipeline builders
and would not exactly be backwards compatible.
... and fallback to gst_audio_info_set_format for not yet supported layouts.
Fix audio playback on iOS 12.
Based on patch from Byron Schiel <byron@canary.is>
https://bugzilla.gnome.org/show_bug.cgi?id=796919
qtdemux_update_streams() is only ever called after checking
`qtdemux->streams_aware` is TRUE. There is no need to check for that
condition again.
`qtdemux->streams_aware` is only modified when the demuxer is
hard-resetted, which is mutually exclusive with demuxing, so it cannot
be modified during the call.
https://bugzilla.gnome.org/show_bug.cgi?id=797191
Currently matroskademux does not emit no-more-pads until the first
Cluster is parsed, even though the Tracks have already been parsed and
from that point on there can be no more tracks.
This is important in MSE because the browser needs to know when the MSE
initialization segment has been completely parsed so that it can expose
the tracks to the user. Some applications depend on this been done
before they feed frames to the demuxer.
As a consequence, historically WebKit has relied on hacks such as
listening to the `pad-added` event, which made impossible to support
multiple tracks in the same file. Let's fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=797187
This patch allows matroskademux to parse a second Tracks element,
erroring out if the tracks are not compatible (different number, type or
codec) and emitting new caps and tag events should they have changed.
https://bugzilla.gnome.org/show_bug.cgi?id=793333
This splits gst_matroska_demux_add_stream() into:
* gst_matroska_demux_parse_stream(): will read the Matroska bytestream
and fill a GstMatroskaTrackContext.
* gst_matroska_demux_parse_tracks(): will check there are no repeated
tracks.
* gst_matroska_demux_add_stream(): creates and sets up the pad for the
track.
https://bugzilla.gnome.org/show_bug.cgi?id=793333
This is necessary for MSE, where a new MSE initialization segment may be
appended at any point. These MSE initialization segments consist of an
entire WebM file until the first Cluster element (not included). [1]
Note that track definitions are ignored on successive headers, they must
match, but this is not checked by matroskademux (look for
`(!demux->tracks_parsed)` in the code).
Source pads are not altered when the new headers are read.
This patch has been splitted from the original patch from eocanha in [2].
[1] https://www.w3.org/TR/mse-byte-stream-format-webm/
[2] https://bug334082.bugzilla-attachments.gnome.org/attachment.cgi?id=362212https://bugzilla.gnome.org/show_bug.cgi?id=793333
The behaviour of split-now is to output the current GOP after
starting a new file.
The newly-added split-after signal will output the current GOP
to the old file if possible once a new GOP is opened.
https://bugzilla.gnome.org/show_bug.cgi?id=796982
This is to support Amlogic CODEC driver which does not provide a full
list of formats when the driver is initially opened. GStreamer does
not strictly need this full list initially, but only later, in order
to negotiate with downstream if multiple format can be selected.
With this change, we will no longer probe twice the device, since the
probed list can be directly used for negotation.
Add a debug message right before waiting for the driver.
This is useful in order to debug drivers without a properly
implemented decoder or encoder stop command.
For 59.94 FPS, it's common to set 60000 as timescale. For that
timescale, if the audio is late by as little as 0:00:00.000016666
(definitely less than one audio sample), lateness gets rounded to 1.
Added a safeguard that allows lateness up to 1 sample with the specific
trak's timescale, to make sure that values less than e.g. one audio
sample won't break the prefill mode. What will happen in this case is
that the audio will get squeezed back to the video's timestamp, which in
practice means that the audio will be 0.000016666 seconds early (with
the patch).
https://bugzilla.gnome.org/show_bug.cgi?id=797133
