- Sep 23, 2021
- Sep 22, 2021
-
-
Tim-Philipp Müller authored
Part-of: <!1091>
-
- Sep 15, 2021
-
-
This feels like exactly like a case that should fail. Part-of: <!1059>
-
Part-of: <gstreamer/gst-plugins-good!1059>
-
- Sep 14, 2021
-
-
Seungha Yang authored
AAC codec_data is a just collection of AAC profile, samplerate, and channels. We can know samplerate and channels from parsed SampleEntry data. Although the AAC profile is unknown there, let's assume it as AAC-LC like we've been doing for the version 1 atom. Part-of: <!1082>
-
- Sep 13, 2021
-
-
Part-of: <!1078>
-
All of that is advertised through the codec_data itself so can change just fine within isomp4. Part-of: <gstreamer/gst-plugins-good!1071>
-
Sebastian Dröge authored
Previously only demuxing when stored via the RIFF/AVI mapping was supported. See https://github.com/FFmpeg/FFV1/blob/master/ffv1.md#matroska-file-format Fixes #923 Part-of: <!1080>
-
- Sep 12, 2021
-
-
Philippe Normand authored
Part-of: <gstreamer/gst-plugins-good!1081>
-
- Sep 07, 2021
-
-
In case of interlaced JPEG file, we are doubling stride. The scratch scan line should take account of it as well. Part-of: <!1042>
-
- Sep 02, 2021
-
-
This works around some AVI files storing byte-stream data in the codec_data. The previous workaround was only checking for 0x00000001 (4 bytes) instead of 0x000001 (3 bytes). Part-of: <!1072>
-
- Aug 31, 2021
- Aug 30, 2021
-
-
This makes it clearer how to use the plugin in an API driven application. Part-of: <!1058>
-
Otherwise, it just fails to add the extension, which makes no sense. And our level element produces levels higher than 127 in some cases. Part-of: <!1058>
-
This makes it a bit easier to understand how to use it in an application. Part-of: <gstreamer/gst-plugins-good!1058>
-
Tests adding the extension based on the caps. Part-of: <gstreamer/gst-plugins-good!1058>
-
- Aug 27, 2021
-
-
When re-using streams, we *do* need to push a `stream-start` event downstream if we previously were EOS'd. Failure to do that would never remove the EOS status on all downstream elements and cause weird issues. Part-of: <gstreamer/gst-plugins-good!1067>
-
FreeBSD/NetBSD/OpenBSD amd64 use the ELF binary format. Part-of: <!1066>
-
Matthew Waters authored
Accessing the unset GstVideoInfo would result in criticals Part-of: <!1065>
-
- Aug 25, 2021
-
-
Sebastian Dröge authored
Part-of: <gstreamer/gst-plugins-good!927>
-
Part-of: <gstreamer/gst-plugins-good!927>
-
For TWCC we are more interested to track the arrival time (receive side) and the current time (sender side) of the buffers rather than the running time. Part-of: <!927>
-
The consumer of the stats can then separate between different media-types, and do individual stats for each of them. Part-of: <!927>
-
Meaning that if a caps comes along that does NOT have TWCC in it, this does not turn of TWCC for the rest, as this is in fact completely allowed. (To have some payload-types not containing TWCC seqnums). Part-of: <gstreamer/gst-plugins-good!927>
-
Prevent cluttering up the rtpsession, and keeping things localized. Also write TWCC-seqnums for *all* streams in the session if configured by caps. A while back WebRTC was not doing TWCC for audio, basically breaking the whole idea of a "transport-wide seqnuencenumber" applying for all bundled streams. However, they have since fixed this, and now it no longers makes sense to be able to single out certain payloadtypes for use with TWCC, rather just including them all. This also makes using RTX, RED, FEC etc much simpler, as it will apply to them all as they enter the rtpsession. Part-of: <gstreamer/gst-plugins-good!927>
-
Part-of: <gstreamer/gst-plugins-good!927>
-
Co-authored-by: Havard Graff <havard.graff@gmail.com> Part-of: <gstreamer/gst-plugins-good!927>
-
Using the proper API to do this is obviously an improvement, and adding a test for the case of a packet-loss when the seqnum wrap is also a good idea. Co-authored-by: Tulio Beloqui <tulio.beloqui@pexip.com> Part-of: <gstreamer/gst-plugins-good!927>
-
packets to be processed Co-authored-by: Havard Graff <havard.graff@gmail.com> Part-of: <gstreamer/gst-plugins-good!927>
-
Co-authored-by: Havard Graff <havard.graff@gmail.com> Part-of: <!927>
-
Co-authored-by: Havard Graff <havard.graff@gmail.com> Part-of: <!927>
-
To allow RTCP TWCC reports to be scheduled on a timer instead of per marker-bit. Part-of: <!927>
-
Not in use. Part-of: <gstreamer/gst-plugins-good!927>
-
They were a bit racy. Part-of: <gstreamer/gst-plugins-good!927>
-
- Aug 24, 2021
-
-
Might be 24bpp in case an alpha channel is coded but the image is always opaque. Part-of: <gstreamer/gst-plugins-good!1061>
-
e.g. when exporting an opaque image, yet with alpha channel. Apple ProRes certification requires that, when a ProRes-writing application *knows* that the entire frame is opaque, the application writes only RGB without alpha even when the clip is RGBA. For that, this tiny change allows the app to override pixel depth when writing ProRes. Part-of: <gstreamer/gst-plugins-good!1061>
-
- Aug 23, 2021
-
-
When a buffer is pushed downstream, we should try not to hold the buffer mapped with write access. Doing so would often lead to an unneccesary memcpy later. For instance, gst_buffer_make_writable() in gst_video_decoder_finish_frame() will cause a memcpy because of _memory_get_exclusive_reference(). We know that we can perform a two-step remap when using system memory, as this will not cause the location of the memory to change. Part-of: <!812>
-
We do it enough times that this makes sense. Also add a debug log line for the seek position requested. Part-of: <gstreamer/gst-plugins-good!1060>
-
When outputting fragmented mp4, with a seekable downstream, we rewrite the moov to maybe add a duration to the mvex. If we start by not writing the initial moov->mvex->mhed duration and then overwrite with a moov containing mhed atom, the moov's will have different sizes and could overwrite subsequent data and result in an unplayable file. e.g. The initial moov would be of size 842 and the final moov would have a size of 862. Fix by always pushing out the mhed duration in the moov when fragmenting. Fixes #898 Part-of: <!1060>
-
We weren't setting the fragment_mode field anymore now that the implementation doesn't change based on the value of the streamable property. This lead to invalid files. Part-of: <!1060>
-