gst-plugins-bad issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues2021-09-24T14:35:58Zhttps://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/632hlsdemux: Playback of some non-live stream stops2023-05-16T16:29:52ZBugzilla Migration Userhlsdemux: Playback of some non-live stream stops## Submitted by mki..@..il.com
**[Link to original bug (#790330)](https://bugzilla.gnome.org/show_bug.cgi?id=790330)**
## Description
Created attachment 363592
Stream versus buffer PTS on tsdemux element
Playback of http://c....## Submitted by mki..@..il.com
**[Link to original bug (#790330)](https://bugzilla.gnome.org/show_bug.cgi?id=790330)**
## Description
Created attachment 363592
Stream versus buffer PTS on tsdemux element
Playback of http://c.brightcove.com/services/mobile/streaming/index/master.m3u8?videoId=5390088162001&pubId=5136026552001 with use gst-play-1.0 (with and without --use-playbin3) stops due to timestamping problem.
The stream seem to be correct and can be played without problem with player like http://players.akamai.com/hls/.
I see two types of problems:
- invalid buffer PTS on tsdemux output as showed on attached images: hls-problem-playbin.png and hls-problem-playbin3.png,
- invalid data stream on tsdemux input due to hlsdemux threads race(?) as showed in attached log prove1.txt (please consider entries from 0:00:03.98 to 0:00:11.74.
**Attachment 363592**, "Stream versus buffer PTS on tsdemux element":
![hls-problem-playbin](/uploads/049ccd4955dec91bc29c60fd90f65aa1/hls-problem-playbin.png)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/626vtenc: vtenc_h264 causing too many Redistribute latency...2023-07-03T14:19:44ZBugzilla Migration Uservtenc: vtenc_h264 causing too many Redistribute latency...## Submitted by Miki Grof-Tisza
**[Link to original bug (#789415)](https://bugzilla.gnome.org/show_bug.cgi?id=789415)**
## Description
I'm having some trouble with the pipeline:
gst-launch-1.0 --gst-debug=*:2,vtenc:4 videotestsrc ...## Submitted by Miki Grof-Tisza
**[Link to original bug (#789415)](https://bugzilla.gnome.org/show_bug.cgi?id=789415)**
## Description
I'm having some trouble with the pipeline:
gst-launch-1.0 --gst-debug=*:2,vtenc:4 videotestsrc ! videorate ! video/x-raw, format=UYVY, width=1920, height=1080, framerate=30/1 ! queue ! vtenc_h264 ! fakesink
I’m running gstreamer version 1.12.3 built from git source, on a 2017 15” Macbook Pro, w/macOS 10.12.6.
The relevant output:
Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:00:00.154950000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 5 fps 30/1 time 0:00:00.166666665
Redistribute latency...
0:00:00.235169000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 6 fps 30/1 time 0:00:00.199999998
Redistribute latency...
0:00:00.241439000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 5 fps 30/1 time 0:00:00.166666665
Redistribute latency...
0:00:00.253913000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 6 fps 30/1 time 0:00:00.199999998
Redistribute latency...
0:00:00.278467000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 7 fps 30/1 time 0:00:00.233333331
Redistribute latency...
0:00:00.288046000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 6 fps 30/1 time 0:00:00.199999998
Redistribute latency...
0:00:00.371569000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 7 fps 30/1 time 0:00:00.233333331
Redistribute latency...
0:00:03.043466000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 6 fps 30/1 time 0:00:00.199999998
Redistribute latency...
0:00:03.065692000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 5 fps 30/1 time 0:00:00.166666665
Redistribute latency...
0:00:03.090887000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 4 fps 30/1 time 0:00:00.133333332
Redistribute latency...
The vtenc_h264 element is calling gst_video_encoder_set_latency() seemingly way too often. It results in gst-launch printing "Redistribute latency..." quite often (several times per second sometimes).
What's happening seems to be the element keeping track of the underlying encoder's pending frame count. If the pending frame count ever changes (checked every frame), then it calls gst_video_encoder_set_latency().
Is it not the case that instead of tracking exact latency each frame and forcing a pipeline latency redistribution every time it changes at all, the element should just check if the latency is greater than the currently configured range (checked via call to gst_video_encoder_get_latency()) and only call gst_video_encoder_set_latency() if it's outside the range?
I will attach a patch that works for me shortly.
Version: 1.12.3https://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/624Playback with playbin3 of MPEG TS file with two stream collections for a prog...2023-06-06T11:54:16ZBugzilla Migration UserPlayback with playbin3 of MPEG TS file with two stream collections for a program does not preroll## Submitted by mki..@..il.com
**[Link to original bug (#789247)](https://bugzilla.gnome.org/show_bug.cgi?id=789247)**
## Description
Created attachment 361943
MPEG TS with program, which starts with only video stream, but shortly...## Submitted by mki..@..il.com
**[Link to original bug (#789247)](https://bugzilla.gnome.org/show_bug.cgi?id=789247)**
## Description
Created attachment 361943
MPEG TS with program, which starts with only video stream, but shortly has video and audio streams
Brief analysis done by Edward Hervey at Hackfest identified at least two problems:
- mpegtsdemux does not add audio pad for second streams collection,
- playbin3 unnecessary blocks streaming.
Information about TS file from tsinfo tool:
Packet 1 is PAT
Program list:
Program 1 -> PID 0100 (256)
Packet 2 is PMT with PID 0100 (256)
Program 1, version 0, PCR PID 1fff (8191)
Program streams:
PID 0101 ( 257) -> Stream type 1b ( 27) H.264/14496-10 video (MPEG-4/AVC)
Packet 159 is PMT with PID 0100 (256) - content changed
Program 1, version 1, PCR PID 0101 (257)
Program streams:
PID 0101 ( 257) -> Stream type 1b ( 27) H.264/14496-10 video (MPEG-4/AVC)
PID 0102 ( 258) -> Stream type 0f ( 15) 13818-7 Audio with ADTS transport syntax
**Attachment 361943**, "MPEG TS with program, which starts with only video stream, but shortly has video and audio streams":
[ntv-collections-v-va.ts](/uploads/0f9f0d37cbe4321cf370b2cf0446cc88/ntv-collections-v-va.ts)Edward HerveyEdward Herveyhttps://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/622opencv: new cameracalibrate and cameraundistort elements2019-08-13T05:21:46ZBugzilla Migration Useropencv: new cameracalibrate and cameraundistort elements## Submitted by Philippe Renon
**[Link to original bug (#789075)](https://bugzilla.gnome.org/show_bug.cgi?id=789075)**
## Description
The two new elements are based on this OpenCV tutorial : Based on this tutorial: https://docs.open...## Submitted by Philippe Renon
**[Link to original bug (#789075)](https://bugzilla.gnome.org/show_bug.cgi?id=789075)**
## Description
The two new elements are based on this OpenCV tutorial : Based on this tutorial: https://docs.opencv.org/2.4/doc/tutorials/calib3d/camera_calibration/camera_calibration.html
In a nutshell:
The cameracalibrate elements takes an operator through a camera calibration procedure. The operator presents a calibration pattern to the camera for multiple detections. See the photos at the end of the tutorial to get a glimpse of what it looks like. This procedure can be CPU intensive while it is in progress. All the processing is done inline (can stall the pipeline at times).
The cameraundistort uses the results of the calibration to correct the camera images. In that process some pixels will be lost and the images will be scaled up.
It is basically a transform element and CPU usage is moderate.
Version: 1.12.31.15.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/621Support SMPTE 2022-1 FEC2020-10-07T06:34:28ZBugzilla Migration UserSupport SMPTE 2022-1 FEC## Submitted by Aaron Boxer
**[Link to original bug (#789074)](https://bugzilla.gnome.org/show_bug.cgi?id=789074)**
## Description
Python implementation:
https://github.com/davidfischer-ch/pytoolbox/tree/master/pytoolbox/networ...## Submitted by Aaron Boxer
**[Link to original bug (#789074)](https://bugzilla.gnome.org/show_bug.cgi?id=789074)**
## Description
Python implementation:
https://github.com/davidfischer-ch/pytoolbox/tree/master/pytoolbox/network/smpte2022https://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)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/617h264parse: May break stream further rather then fixing it2021-09-24T14:35:51ZBugzilla Migration Userh264parse: May break stream further rather then fixing it## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#788595)](https://bugzilla.gnome.org/show_bug.cgi?id=788595)**
## Description
As found with this file in [bug 787795](https://bugzilla.gnome.org/show_bug.cgi?id=...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#788595)](https://bugzilla.gnome.org/show_bug.cgi?id=788595)**
## Description
As found with this file in [bug 787795](https://bugzilla.gnome.org/show_bug.cgi?id=787795), with the following FLV file:
https://bugzilla.gnome.org/attachment.cgi?id=360317
h264parse turns a slightly broken stream into an un-playable stream. As an example, the display video will be gray with the parser:
filesrc location=test.flv ! flvdemux ! h264parse ! avdec_h264 ! autovideosink
But looks fine without:
filesrc location=/tmp/test.flv ! flvdemux ! video/x-h264,alignment=au ! avdec_h264 ! autovideosinkhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/616android: glimagesink/amcvideodec unable to retain and save last-sample2021-09-24T14:35:51ZBugzilla Migration Userandroid: glimagesink/amcvideodec unable to retain and save last-sample## Submitted by Nicola `@drakkan`
**[Link to original bug (#788116)](https://bugzilla.gnome.org/show_bug.cgi?id=788116)**
## Description
I have a pipeline like this:
decoder ! glupload ! glocolorconvert ! glimagesink
to ta...## Submitted by Nicola `@drakkan`
**[Link to original bug (#788116)](https://bugzilla.gnome.org/show_bug.cgi?id=788116)**
## Description
I have a pipeline like this:
decoder ! glupload ! glocolorconvert ! glimagesink
to take a snapshot I get the last-sample from glimagesink and then save it as jpeg with a pipeline like this:
appsrc ! gldownload ! videoconvert ! jpegenc ! filesink
the snapshot can be generated even after the decoding pipeline is finalized, this should be ok since last-sample returns a reference to the sample and an user can keep this reference until needed
this works fine with a sw decoder such as avdec_h264 but if I use an hw decoder such as amcvideodec and you try to generate a snapshot after the decoding pipeline is setted to NULL then the snapshot pipeline will hang after changing state from NULL to READY,
probably after the pipeline is finalized gldownload cannot get a context or access to the glmemory.
This seems a bug ot at least should be documented.
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/615mpegtsdemux: DVB recording transport streams (with errors) cannot be played back2021-09-24T14:35:50ZBugzilla Migration Usermpegtsdemux: DVB recording transport streams (with errors) cannot be played back## Submitted by Zeno Endemann
**[Link to original bug (#787959)](https://bugzilla.gnome.org/show_bug.cgi?id=787959)**
## Description
Created attachment 360156
Example video
In comparison ffplay prints out a bunch of errors on...## Submitted by Zeno Endemann
**[Link to original bug (#787959)](https://bugzilla.gnome.org/show_bug.cgi?id=787959)**
## Description
Created attachment 360156
Example video
In comparison ffplay prints out a bunch of errors on the console but keeps playing back the file. Would be nice if gstreamer could be error resilient like that.
**Attachment 360156**, "Example video":
[R_0563.trp](/uploads/2ae9530cc836ef44871ea967e7454108/R_0563.trp)
Version: 1.10.4