gst-plugins-bad issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues2021-09-24T14:36:02Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/643new element: gpsdsrc2021-09-24T14:36:02ZBugzilla Migration Usernew element: gpsdsrc## Submitted by Martin Kelly
**[Link to original bug (#791601)](https://bugzilla.gnome.org/show_bug.cgi?id=791601)**
## Description
Created attachment 365510
0001-new-element-gpsdsrc.patch
new element: gpsdsrc
This el...## Submitted by Martin Kelly
**[Link to original bug (#791601)](https://bugzilla.gnome.org/show_bug.cgi?id=791601)**
## Description
Created attachment 365510
0001-new-element-gpsdsrc.patch
new element: gpsdsrc
This element reads data from gpsd (http://www.catb.org/gpsd/). Right now
the GPS data type is not used in other plugins, but eventually it could
be used to multiplex and integrate with other A/V data types.
~~**Patch 365510**~~, "0001-new-element-gpsdsrc.patch":
[0001-new-element-gpsdsrc.patch](/uploads/5bb2f44c83ad7bd1ce4717bc48ccba40/0001-new-element-gpsdsrc.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/642Improve support for KLV metadata in tsdemuxer and tsmuxer2023-11-20T06:57:53ZBugzilla Migration UserImprove support for KLV metadata in tsdemuxer and tsmuxer## Submitted by Michael Fien
**[Link to original bug (#791533)](https://bugzilla.gnome.org/show_bug.cgi?id=791533)**
## Description
Created attachment 365454
Mpeg2 transport stream descriptor for KLV
Add additions to tsdemuxe...## Submitted by Michael Fien
**[Link to original bug (#791533)](https://bugzilla.gnome.org/show_bug.cgi?id=791533)**
## Description
Created attachment 365454
Mpeg2 transport stream descriptor for KLV
Add additions to tsdemuxer and tsmuxer that handle synchronous and asynchronous metadata streams per MISB-0604
**Patch 365454**, "Mpeg2 transport stream descriptor for KLV":
[0001-Add-MPEG2-TS-descriptor-support-for-KLV-metadata.patch](/uploads/59a5e1767a3994cafa3dc482345e58e2/0001-Add-MPEG2-TS-descriptor-support-for-KLV-metadata.patch)
Version: 1.12.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/641h265parse: Messes up timestamps for byte-stream2021-09-24T14:36:01ZBugzilla Migration Userh265parse: Messes up timestamps for byte-stream## Submitted by Matej `@Knopp`
**[Link to original bug (#791495)](https://bugzilla.gnome.org/show_bug.cgi?id=791495)**
## Description
It happens when previous frame has trailing zero. Parser split frame too early, leaving trailing z...## Submitted by Matej `@Knopp`
**[Link to original bug (#791495)](https://bugzilla.gnome.org/show_bug.cgi?id=791495)**
## Description
It happens when previous frame has trailing zero. Parser split frame too early, leaving trailing zeros as prefix for new frame, which results in messed up timestamps.
Caused by following code in gst_h265_parser_identify_nalu
/* Mini performance improvement:
* We could have a way to store how many 0s were skipped to avoid
* parsing them again on the next NAL */
while (off2 > 0 && data[nalu->offset + off2 - 1] == 00)
off2--;
Annex B does says that there should be zero byte before AU startcode, however it also says that during parsing the zero byte should be discarded. So maybe determining the timestamp from zero byte is not a very good idea.
The stream already parsed by FFMPEG HEVC parser, which seems to leave zero byte trailing, but that doesn't mean such files can't be encountered in the wild.
Btw. Why's there loop? Why skipping more than 1 zero byte? Doesn't that just increases chance of messed up timestamps?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/640kmssink: Crop Meta support only works if the proposed pool has been used2021-09-24T14:36:01ZBugzilla Migration Userkmssink: Crop Meta support only works if the proposed pool has been used## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#791450)](https://bugzilla.gnome.org/show_bug.cgi?id=791450)**
## Description
++ This is the same as https://bugzilla.gnome.org/show_bug.cgi?id=791449
Whene...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#791450)](https://bugzilla.gnome.org/show_bug.cgi?id=791450)**
## Description
++ This is the same as https://bugzilla.gnome.org/show_bug.cgi?id=791449
Whenever the proposed pool is not used upstream, the element fails. The reason is that buffer containing crop meta are larger then caps width/height used to create the internal pool.
We need to delay the creation of the pool, and then alter the caps width/height with the width/height found in the incoming buffer video meta. As a side effect, we also need to validate this width/height every-time.
I'll post the videocrop patches needed to test this easily soon, meanwhile the test pipeline will be:
videotestsrc ! videocrop top=100 ! tee ! kmsimagesink
Tee does not drop the allocation query, but will not use downstream pools.
The result is a black or green image (depends on the color format) and:
CRITICAL **: gst_video_frame_copy: assertion 'dinfo->width == sinfo->width && dinfo->height == sinfo->height' failed
### Blocking
* [Bug 746087](https://bugzilla.gnome.org/show_bug.cgi?id=746087)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/639kmssink: fix kmssink fail to start when not connect display2021-09-24T14:36:00ZBugzilla Migration Userkmssink: fix kmssink fail to start when not connect display## Submitted by Haihua Hu `@JaredHu`
**[Link to original bug (#791374)](https://bugzilla.gnome.org/show_bug.cgi?id=791374)**
## Description
Currently kmssink will fail when not connect display to device. Get display connected status...## Submitted by Haihua Hu `@JaredHu`
**[Link to original bug (#791374)](https://bugzilla.gnome.org/show_bug.cgi?id=791374)**
## Description
Currently kmssink will fail when not connect display to device. Get display connected status from drm connector, drop all buffer when display not connected to make pipeline can run.
Version: 1.12.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/638interaudio: Add option to enable/disable gap flags in nullsample buffers2021-09-24T14:36:00ZBugzilla Migration Userinteraudio: Add option to enable/disable gap flags in nullsample buffers## Submitted by Carlos Rafael Giani
**[Link to original bug (#791353)](https://bugzilla.gnome.org/show_bug.cgi?id=791353)**
## Description
If the interaudio channel runs out of data, nullsample buffers are created.
interaudiosrc s...## Submitted by Carlos Rafael Giani
**[Link to original bug (#791353)](https://bugzilla.gnome.org/show_bug.cgi?id=791353)**
## Description
If the interaudio channel runs out of data, nullsample buffers are created.
interaudiosrc sets the GAP flag of these buffers. In some cases, it may
be preferable to not set the flag (for example, to produce one continuous
seamless stream even if the other side of the channel is currently paused).
One such case would be a system with a producer and a consumer pipeline, linked
together through an interaudio channel. The consumer pipeline always runs, while
the producer pipeline may sometimes be stopped, seeking, paused etc. In such a
case, it is necessary to make sure the consumer's interaudiosrc produces a
continuous stream. GAP flags would introduce unnecessary resynchronization events
inside the consumer pipeline's audio sink.
### Depends on
* [Bug 781721](https://bugzilla.gnome.org/show_bug.cgi?id=781721)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/637interaudio: Drain samples before setting new caps2021-09-24T14:36:00ZBugzilla Migration Userinteraudio: Drain samples before setting new caps## Submitted by Carlos Rafael Giani
**[Link to original bug (#791348)](https://bugzilla.gnome.org/show_bug.cgi?id=791348)**
## Description
Currently, when caps change, any samples remaining inside the channel are thrown away, causin...## Submitted by Carlos Rafael Giani
**[Link to original bug (#791348)](https://bugzilla.gnome.org/show_bug.cgi?id=791348)**
## Description
Currently, when caps change, any samples remaining inside the channel are thrown away, causing data loss. Fix this by draining them before the caps are changed in gst_inter_audio_sink_set_caps().
### Depends on
* [Bug 781721](https://bugzilla.gnome.org/show_bug.cgi?id=781721)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/635opusparse: subtract clipped audio to buffer duration2021-09-24T14:35:59ZBugzilla Migration Useropusparse: subtract clipped audio to buffer duration## Submitted by Alicia Boya García `@ntrrgc`
**[Link to original bug (#791099)](https://bugzilla.gnome.org/show_bug.cgi?id=791099)**
## Description
opusparse is not subtracting codec delay from the buffer duration.
Generate tes...## Submitted by Alicia Boya García `@ntrrgc`
**[Link to original bug (#791099)](https://bugzilla.gnome.org/show_bug.cgi?id=791099)**
## Description
opusparse is not subtracting codec delay from the buffer duration.
Generate test vector:
$ gst-launch-1.0 audiotestsrc num-buffers=1 samplesperbuffer=24000 ! audio/x-raw, rate=48000 ! opusenc ! identity error-after=2 ! webmmux ! filesink location=/tmp/audio-clipping-test-vector.webm
Test:
$ gst-launch-1.0 -v pushfilesrc location=/tmp/audio-clipping-test-vector.webm \
! matroskademux ! identity name="after_matroskademux" silent=false \
! opusparse ! identity name="after_opusparse" silent=false \
! opusdec ! identity name="after_opusdec" silent=false \
! fakesink 2>&1 |grep chain
/GstPipeline:pipeline0/GstIdentity:after_matroskademux: last-message = chain ******* (after_matroskademux:sink) (160 bytes, dts: none, pts: 0:00:00.000000000, duration: 0:00:00.013500000, offset: -1, offset_end: -1, flags: 00004040 discont tag-memory , meta: GstAudioClippingMeta) 0x7f13c800a060
/GstPipeline:pipeline0/GstIdentity:after_opusparse: last-message = chain ******* (after_opusparse:sink) (160 bytes, dts: 0:00:00.000000000, pts: 0:00:00.000000000, duration: 0:00:00.020000000, offset: 20000000, offset_end: 960, flags: 00004040 discont tag-memory , meta: GstAudioClippingMeta) 0x7f13c800a060
/GstPipeline:pipeline0/GstIdentity:after_opusdec: last-message = chain ******* (after_opusdec:sink) (1296 bytes, dts: none, pts: 0:00:00.000000000, duration: 0:00:00.013500000, offset: -1, offset_end: -1, flags: 00000040 discont , meta: none) 0x7f13c800ab00
Note the inconsistency in durations and GstAudioClippingMeta:
Expected*:
matroskademux ------------> opusparse -----------> opusdec ------------>
13.5ms 13.5ms 13.5ms
clip meta clip meta no clip meta
Actual:
matroskademux ------------> opusparse -----------> opusdec ------------>
13.5ms 20.0ms 13.5ms
clip meta clip meta no clip meta
* I'm supposing that GstBuffer durations should already have GstAudioClippingMeta subtracted. I could not find any hints in the documentation one way or the other, so I'm picking sides with matroskademux because is gst-plugins-good. In any case, the current behavior is definitively inconsistent because matroskademux is subtracting them while opusparse is not.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/634CineForm plugin for GStreamer bad2021-09-24T14:35:58ZBugzilla Migration UserCineForm plugin for GStreamer bad## Submitted by Emeric Grange `@emericg`
**[Link to original bug (#790793)](https://bugzilla.gnome.org/show_bug.cgi?id=790793)**
## Description
Created attachment 364334
add CineForm to cerbero
So this is an initial submissio...## Submitted by Emeric Grange `@emericg`
**[Link to original bug (#790793)](https://bugzilla.gnome.org/show_bug.cgi?id=790793)**
## Description
Created attachment 364334
add CineForm to cerbero
So this is an initial submission for a CineForm plugin with encoding and decoding capability. It use the official CineForm SDK from https://github.com/gopro/cineform-sdk.
CineForm is an I frame only codec, which makes this plugin very simple.
The pixel formats used internally by the SDK are not mapping very well with the ones from GStreamer, so the decoder plugin output regular 8b RGB and the encoder can take YUY2 or r210 buffers, but it is planned to go full b64a (ARGB64_BE) to avoid unnecessary conversions and take advantage of the 10-12 bits per pixel without subsampling of the CineForm coding.
Right now we have a few limitations:
- Pixel formats used by the plugin are not optimal (we are working on ARGB64 BE/LE support for GStreamer).
- The CineForm SDK does not build on mingw (still working on that).
- Performances of the open source CineForm SDK (v10) doesn't match the performances of the proprietary SDK (<= v9).
We do not seek inclusion yet, just comments. Attached are cerbero and gst-plugins-bad patches.
Thanks.
~~**Patch 364334**~~, "add CineForm to cerbero":
[0001-Add-CineForm-SDK-to-the-recipes-and-as-a-dependency-.patch](/uploads/740403ad3f089a43faefeaba274cad21/0001-Add-CineForm-SDK-to-the-recipes-and-as-a-dependency-.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/633h264parse: early set src caps when input is avc2021-09-24T14:35:57ZBugzilla Migration Userh264parse: early set src caps when input is avc## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#790709)](https://bugzilla.gnome.org/show_bug.cgi?id=790709)**
## Description
.## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#790709)](https://bugzilla.gnome.org/show_bug.cgi?id=790709)**
## Description
.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/631Files with CRLF encoding2021-09-24T14:35:56ZBugzilla Migration UserFiles with CRLF encoding## Submitted by Ben
**[Link to original bug (#790235)](https://bugzilla.gnome.org/show_bug.cgi?id=790235)**
## Description
Some files still have CRLF line endings.
This might cause problems for example when using the git crlfau...## Submitted by Ben
**[Link to original bug (#790235)](https://bugzilla.gnome.org/show_bug.cgi?id=790235)**
## Description
Some files still have CRLF line endings.
This might cause problems for example when using the git crlfautofix setting especially in combination with debian build tools. (Will be recognized as unexpected upstream changes)
commit d364c7b44359941d6afb2022c764af771b807846
```
find . -name "*.h" -o -name "*.xml" -o -name "*.txt" -o -name "*.cpp" -o -name "*.c" | xargs file "{}" | grep CRLF
./gst/dvdspu/Notes.txt: ASCII text, with CRLF line terminators
./sys/decklink/win/DeckLinkAPI_i.c: C source, ASCII text, with CRLF line terminators
./sys/decklink/win/DeckLinkAPIDispatch.cpp: C source, ASCII text, with CRLF line terminators
./sys/decklink/win/DeckLinkAPI.h: C source, ASCII text, with CRLF line terminators
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/630directsoundsrc: unstable audio2021-09-24T14:35:56ZBugzilla Migration Userdirectsoundsrc: unstable audio## Submitted by Rytis Kymantas
**[Link to original bug (#790014)](https://bugzilla.gnome.org/show_bug.cgi?id=790014)**
## Description
Starting with 1.12.0 (ignoring the unstable 1.11 release), can't get direcsoundsrc to work cleanly...## Submitted by Rytis Kymantas
**[Link to original bug (#790014)](https://bugzilla.gnome.org/show_bug.cgi?id=790014)**
## Description
Starting with 1.12.0 (ignoring the unstable 1.11 release), can't get direcsoundsrc to work cleanly.
There's always some audio garbling or clipping / popping sounds. Changing configuration / devices / pipeline only changes the severity of the issue. About the only thing to provide a stable improvement is increasing latency-time to at least 100ms which is far too high for the intended low-latency application.
1.10.5 version did not have these issues, but had constantly increasing latency that 1.12.3 does not.
Version: 1.12.3https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/629tsdemux: Support legacy DTS bluray streams2021-09-24T14:35:55ZBugzilla Migration Usertsdemux: Support legacy DTS bluray streams## Submitted by Gabby Park
**[Link to original bug (#789949)](https://bugzilla.gnome.org/show_bug.cgi?id=789949)**
## Description
Created attachment 363030
Add identifier for legacy DTS bluray stream
Currently, the DTS bluray...## Submitted by Gabby Park
**[Link to original bug (#789949)](https://bugzilla.gnome.org/show_bug.cgi?id=789949)**
## Description
Created attachment 363030
Add identifier for legacy DTS bluray stream
Currently, the DTS bluray track was not recognized.
So I added it at Blu-ray specific cases.
**Patch 363030**, "Add identifier for legacy DTS bluray stream":
[0001-tsdemux-Add-stream_type-for-legacy-DTS-track.patch](/uploads/58efc86b2b6448733edbd3a831bb675f/0001-tsdemux-Add-stream_type-for-legacy-DTS-track.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/628Add missing features in MediaSDK plugin [metabug]2021-09-24T14:35:55ZBugzilla Migration UserAdd missing features in MediaSDK plugin [metabug]## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#789886)](https://bugzilla.gnome.org/show_bug.cgi?id=789886)**
## Description
The gst-msdk plugin is missing many of the features required for customers.
This ...## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#789886)](https://bugzilla.gnome.org/show_bug.cgi?id=789886)**
## Description
The gst-msdk plugin is missing many of the features required for customers.
This is a meta bug for tracking media-sdk GStreamer plugin development and also to discuss the design options.
Please file separate bugs for each feature listing here.
### Depends on
* [Bug 786879](https://bugzilla.gnome.org/show_bug.cgi?id=786879)
* [Bug 793411](https://bugzilla.gnome.org/show_bug.cgi?id=793411)
* [Bug 793414](https://bugzilla.gnome.org/show_bug.cgi?id=793414)
* [Bug 793495](https://bugzilla.gnome.org/show_bug.cgi?id=793495)
* [Bug 793782](https://bugzilla.gnome.org/show_bug.cgi?id=793782)
* [Bug 793784](https://bugzilla.gnome.org/show_bug.cgi?id=793784)
* [Bug 793906](https://bugzilla.gnome.org/show_bug.cgi?id=793906)
* [Bug 794851](https://bugzilla.gnome.org/show_bug.cgi?id=794851)
* [Bug 794944](https://bugzilla.gnome.org/show_bug.cgi?id=794944)
* [Bug 796232](https://bugzilla.gnome.org/show_bug.cgi?id=796232)
* [Bug 796459](https://bugzilla.gnome.org/show_bug.cgi?id=796459)
* [Bug 796460](https://bugzilla.gnome.org/show_bug.cgi?id=796460)
* [Bug 796461](https://bugzilla.gnome.org/show_bug.cgi?id=796461)
* [Bug 796462](https://bugzilla.gnome.org/show_bug.cgi?id=796462)
* [Bug 796521](https://bugzilla.gnome.org/show_bug.cgi?id=796521)
* [Bug 796522](https://bugzilla.gnome.org/show_bug.cgi?id=796522)
* [Bug 796819](https://bugzilla.gnome.org/show_bug.cgi?id=796819)
* [Bug 789751](https://bugzilla.gnome.org/show_bug.cgi?id=789751)
* [Bug 789752](https://bugzilla.gnome.org/show_bug.cgi?id=789752)
* [Bug 789847](https://bugzilla.gnome.org/show_bug.cgi?id=789847)
* [Bug 790312](https://bugzilla.gnome.org/show_bug.cgi?id=790312)
* [Bug 790752](https://bugzilla.gnome.org/show_bug.cgi?id=790752)
* [Bug 791479](https://bugzilla.gnome.org/show_bug.cgi?id=791479)
* [Bug 791599](https://bugzilla.gnome.org/show_bug.cgi?id=791599)
* [Bug 791637](https://bugzilla.gnome.org/show_bug.cgi?id=791637)
* [Bug 792260](https://bugzilla.gnome.org/show_bug.cgi?id=792260)
* [Bug 792589](https://bugzilla.gnome.org/show_bug.cgi?id=792589)
* [Bug 793236](https://bugzilla.gnome.org/show_bug.cgi?id=793236)
* [Bug 793412](https://bugzilla.gnome.org/show_bug.cgi?id=793412)
* [Bug 793413](https://bugzilla.gnome.org/show_bug.cgi?id=793413)
* [Bug 793415](https://bugzilla.gnome.org/show_bug.cgi?id=793415)
* [Bug 793525](https://bugzilla.gnome.org/show_bug.cgi?id=793525)
* [Bug 793705](https://bugzilla.gnome.org/show_bug.cgi?id=793705)
* [Bug 793707](https://bugzilla.gnome.org/show_bug.cgi?id=793707)
* [Bug 793708](https://bugzilla.gnome.org/show_bug.cgi?id=793708)
* [Bug 793741](https://bugzilla.gnome.org/show_bug.cgi?id=793741)
* [Bug 793781](https://bugzilla.gnome.org/show_bug.cgi?id=793781)
* [Bug 793786](https://bugzilla.gnome.org/show_bug.cgi?id=793786)
* [Bug 793787](https://bugzilla.gnome.org/show_bug.cgi?id=793787)
* [Bug 793864](https://bugzilla.gnome.org/show_bug.cgi?id=793864)
* [Bug 793865](https://bugzilla.gnome.org/show_bug.cgi?id=793865)
* [Bug 793867](https://bugzilla.gnome.org/show_bug.cgi?id=793867)
* [Bug 793869](https://bugzilla.gnome.org/show_bug.cgi?id=793869)
* [Bug 793872](https://bugzilla.gnome.org/show_bug.cgi?id=793872)
* [Bug 793873](https://bugzilla.gnome.org/show_bug.cgi?id=793873)
* [Bug 793904](https://bugzilla.gnome.org/show_bug.cgi?id=793904)
* [Bug 794276](https://bugzilla.gnome.org/show_bug.cgi?id=794276)
* [Bug 794817](https://bugzilla.gnome.org/show_bug.cgi?id=794817)
* [Bug 794946](https://bugzilla.gnome.org/show_bug.cgi?id=794946)
* [Bug 794991](https://bugzilla.gnome.org/show_bug.cgi?id=794991)
* [Bug 795707](https://bugzilla.gnome.org/show_bug.cgi?id=795707)
* [Bug 795783](https://bugzilla.gnome.org/show_bug.cgi?id=795783)
* [Bug 796118](https://bugzilla.gnome.org/show_bug.cgi?id=796118)
* [Bug 796119](https://bugzilla.gnome.org/show_bug.cgi?id=796119)
* [Bug 796464](https://bugzilla.gnome.org/show_bug.cgi?id=796464)
* [Bug 796465](https://bugzilla.gnome.org/show_bug.cgi?id=796465)
* [Bug 796467](https://bugzilla.gnome.org/show_bug.cgi?id=796467)
* [Bug 796468](https://bugzilla.gnome.org/show_bug.cgi?id=796468)
* [Bug 796469](https://bugzilla.gnome.org/show_bug.cgi?id=796469)
* [Bug 796566](https://bugzilla.gnome.org/show_bug.cgi?id=796566)
* [Bug 796699](https://bugzilla.gnome.org/show_bug.cgi?id=796699)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/627adaptivedemux: deadlock on task stop2021-09-24T14:35:54ZBugzilla Migration Useradaptivedemux: deadlock on task stop## Submitted by Ravi
**[Link to original bug (#789844)](https://bugzilla.gnome.org/show_bug.cgi?id=789844)**
## Description
Created attachment 362871
if the streams are not cancelled during task stop and we are in prerolling then ...## Submitted by Ravi
**[Link to original bug (#789844)](https://bugzilla.gnome.org/show_bug.cgi?id=789844)**
## Description
Created attachment 362871
if the streams are not cancelled during task stop and we are in prerolling then unblock the data push thread.
The deadlock is observed when we quickly do start-stop pipeline.
The other use case if you push new mpd buffer to adaptivedemux and then shutdown the pipeline.
**Patch 362871**, "if the streams are not cancelled during task stop and we are in prerolling then unblock the data push thread.":
[deadlockFix.patch](/uploads/7d4ac7dbb84f019655f2a9262a86db5c/deadlockFix.patch)
Version: 1.12.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/625[hlsdemux] Use of ID3 PTS for buffer timestamping for live radio streaming2021-09-24T14:35:54ZBugzilla Migration User[hlsdemux] Use of ID3 PTS for buffer timestamping for live radio streaming## Submitted by mki..@..il.com
**[Link to original bug (#789253)](https://bugzilla.gnome.org/show_bug.cgi?id=789253)**
## Description
In live radio streaming use case, buffers pushed by hlsdemux don't have time information and base ...## Submitted by mki..@..il.com
**[Link to original bug (#789253)](https://bugzilla.gnome.org/show_bug.cgi?id=789253)**
## Description
In live radio streaming use case, buffers pushed by hlsdemux don't have time information and base parser stamps them based on properties like ADTS frame duration. In case of the network problems, when not all manifests are downloaded, gaps in playback are not correctly set.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/623assrender: doesn't properly render multiple subtitles2021-09-24T14:35:53ZBugzilla Migration Userassrender: doesn't properly render multiple subtitles## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#789239)](https://bugzilla.gnome.org/show_bug.cgi?id=789239)**
## Description
gstreamer only displays the first (ASS) subtitle rectangle and ignores all others that...## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#789239)](https://bugzilla.gnome.org/show_bug.cgi?id=789239)**
## Description
gstreamer only displays the first (ASS) subtitle rectangle and ignores all others that might be supposed to be displayed simultaneously.
check out:
gst-play-1.0 http://dreambox.guru/multiple-subtitles-ass.mkv
versus the same video played with vlchttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/620mxfmux : Mxfmux is not functional with splitmuxsink2021-09-24T14:35:53ZBugzilla Migration Usermxfmux : Mxfmux is not functional with splitmuxsink## Submitted by Baby octopus
**[Link to original bug (#788827)](https://bugzilla.gnome.org/show_bug.cgi?id=788827)**
## Description
There are two issues
1. Pad templates of mxfmux is not generic like that of mp4. Splitmuxsink does...## Submitted by Baby octopus
**[Link to original bug (#788827)](https://bugzilla.gnome.org/show_bug.cgi?id=788827)**
## Description
There are two issues
1. Pad templates of mxfmux is not generic like that of mp4. Splitmuxsink does't have support for such pad templates(ex: mpeg_audio_sink_%u). Its good to have generic pad template such as audio_%d, video_%d etc
2. With workaround for above issue(hardcoding in splitmuxsink), I tried to run a pipeline to fragment filed and mux them into MXF. Issue happens during the creation of second fragment. EOS isn't handled properly I guess which is leading to crash.
Here is the pipeline
gst-launch-1.0 videotestsrc is-live=1 ! video/x-raw,format=I420 ! x264enc ! splitmuxsink muxer=mxfmux location=/root/out_%d.mxf max-size-time=4000000000
ERROR:mxfmux.c:1571:gst_mxf_mux_handle_eos: assertion failed: (mux->offset == body_partition)
Version: 1.12.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/619dashdemux: segmentbase type with 'sidx' is not working as expected.2021-09-24T14:35:52ZBugzilla Migration Userdashdemux: segmentbase type with 'sidx' is not working as expected.## Submitted by Jun Xie
**[Link to original bug (#788763)](https://bugzilla.gnome.org/show_bug.cgi?id=788763)**
## Description
e.g.
http://dash.edgesuite.net/dash264/TestCases/1a/netflix/exMPD_BIP_TC1.mpd
currently, a whole ...## Submitted by Jun Xie
**[Link to original bug (#788763)](https://bugzilla.gnome.org/show_bug.cgi?id=788763)**
## Description
e.g.
http://dash.edgesuite.net/dash264/TestCases/1a/netflix/exMPD_BIP_TC1.mpd
currently, a whole file is downloaded without using range download, and also bitrate switch is not available.
The expected behaviour shall be that 'sidx' parsed,
and segments be retrieved by range download, and bitrate can be switched.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/618ahc2src: Introduce a new source for Android Camera 2 NDK API2021-09-24T14:35:52ZBugzilla Migration Userahc2src: Introduce a new source for Android Camera 2 NDK API## Submitted by Justin Kim `@joykim`
**[Link to original bug (#788696)](https://bugzilla.gnome.org/show_bug.cgi?id=788696)**
## Description
Created attachment 361159
ahc2src: new source element for camera2ndk on Android
Since...## Submitted by Justin Kim `@joykim`
**[Link to original bug (#788696)](https://bugzilla.gnome.org/show_bug.cgi?id=788696)**
## Description
Created attachment 361159
ahc2src: new source element for camera2ndk on Android
Since Android Nougat, Android provides Camera 2 NDK APIs so no JNI wrappers are required to implement ahc2src. Therefore, cebero's 'target_distro_version' should be 'DistroVersion.ANDROID_NOUGAT' or greater to build this element.
One outstanding result of this element is the quick response to discarding internal buffers so 763308 will not happen.
~~**Patch 361159**~~, "ahc2src: new source element for camera2ndk on Android":
[0001-ahc2src-Add-support-android-camera2ndk.patch](/uploads/ebeaad27b3bce661f77d5b36a6ecc894/0001-ahc2src-Add-support-android-camera2ndk.patch)