GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2023-10-06T13:24:54Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/5qtdemux: Support chapters2023-10-06T13:24:54ZBugzilla Migration Userqtdemux: Support chapters## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#540887)](https://bugzilla.gnome.org/show_bug.cgi?id=540887)**
## Description
There's currently no chapters support in qtdemux. This could be used to browse in files ...## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#540887)](https://bugzilla.gnome.org/show_bug.cgi?id=540887)**
## Description
There's currently no chapters support in qtdemux. This could be used to browse in files such as:
http://downloads.oreilly.com/make/MAKE_2005-07-18.m4b
### Depends on
* [Bug 540890](https://bugzilla.gnome.org/show_bug.cgi?id=540890)
### Blocking
* [Bug 163546](https://bugzilla.gnome.org/show_bug.cgi?id=163546)
* [Bug 328298](https://bugzilla.gnome.org/show_bug.cgi?id=328298)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/4RTP depayloaders should send tags with metadata such as codec and bitrate2023-10-06T13:24:54ZBugzilla Migration UserRTP depayloaders should send tags with metadata such as codec and bitrate## Submitted by an unknown user
**[Link to original bug (#536453)](https://bugzilla.gnome.org/show_bug.cgi?id=536453)**
## Description
http://www.nanog.org/qtstream.mov
Streams, but lots of rendering artifacts at start of strea...## Submitted by an unknown user
**[Link to original bug (#536453)](https://bugzilla.gnome.org/show_bug.cgi?id=536453)**
## Description
http://www.nanog.org/qtstream.mov
Streams, but lots of rendering artifacts at start of stream. More importantly though the plugins in question seem to report no information for Totem's proprties tab. Totem screenshot attached.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/3avidemux, qtdemux, dvdec: signal DVCPRO50 codec properly2023-10-06T13:24:53ZBugzilla Migration Useravidemux, qtdemux, dvdec: signal DVCPRO50 codec properly## Submitted by j^
**[Link to original bug (#526481)](https://bugzilla.gnome.org/show_bug.cgi?id=526481)**
## Description
add fourcc for DVCPRO50 to qtdemux
dv5n is DVCPRO50 NTSC and
dv5c is DVCPRO50 PAL
right now only ffde...## Submitted by j^
**[Link to original bug (#526481)](https://bugzilla.gnome.org/show_bug.cgi?id=526481)**
## Description
add fourcc for DVCPRO50 to qtdemux
dv5n is DVCPRO50 NTSC and
dv5c is DVCPRO50 PAL
right now only ffdec_dvvideo is able to decode those files properly
but totem chooses dvdec, not sure how to fix that.
playing them via gst-launch works:
gst-launch filesrc location=test.mov ! qtdemux ! ffdec_dvvideo ! ffmpegcolorspace ! xvimagesinkhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/2matroskademux: support for multi-segment Matroska files2023-10-06T13:24:53ZBugzilla Migration Usermatroskademux: support for multi-segment Matroska files## Submitted by Lionel Dricot `@ldricot`
**[Link to original bug (#334082)](https://bugzilla.gnome.org/show_bug.cgi?id=334082)**
## Description
If you play a matroska (.mkv) file with segments, Totem will only play the
first segme...## Submitted by Lionel Dricot `@ldricot`
**[Link to original bug (#334082)](https://bugzilla.gnome.org/show_bug.cgi?id=334082)**
## Description
If you play a matroska (.mkv) file with segments, Totem will only play the
first segment without allowing you to switch to another one.
Unfortunatly, I can't upload an example file (I've seen this with a 4Go file).
Perhaps is there one in the Gstreamer test suite ?
Following Haali on #matroska, it's not about chapter but about segment.
Most files are one segment only and totem only support one segment (as all
others *NIX players).
My file is multi-segment, which is one step over chapters. (If I understand
correctly the spec, each segment can have his own tracks and chapters. Chapters
are only "bookmarks" in a big file)
The spec : http://www.matroska.org/technical/specs/index.htmlhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/1[matroskamux] doesn't add references between I/B/P frames2023-10-06T13:24:52ZBugzilla Migration User[matroskamux] doesn't add references between I/B/P frames## Submitted by John Cannon
**[Link to original bug (#140783)](https://bugzilla.gnome.org/show_bug.cgi?id=140783)**
## Description
When muxing an AVI containing XviD video and MP3 audio into a MKV with the
matroskamux element it p...## Submitted by John Cannon
**[Link to original bug (#140783)](https://bugzilla.gnome.org/show_bug.cgi?id=140783)**
## Description
When muxing an AVI containing XviD video and MP3 audio into a MKV with the
matroskamux element it produces an invalid file with the following problems:
1) It sets the codec ID in the file to the native mpeg-4 identifier which is
wrong unless the framing meets extra requirements. Until you add mpeg4 frame
referencing you should use the VfW compatibility ID.
2) No references are written at all.
3) No track UID is written for the tracks.
4) Clusters are extremely small. You should put more frames in each cluster, ie
500ms.
### Blocking
* [Bug 309429](https://bugzilla.gnome.org/show_bug.cgi?id=309429)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/812codecparsers_h26x: Should return NO_NAL_END on 5/6 bytes NALs2018-11-06T07:26:18ZBugzilla Migration Usercodecparsers_h26x: Should return NO_NAL_END on 5/6 bytes NALs## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#797371)](https://bugzilla.gnome.org/show_bug.cgi?id=797371)**
## Description
-- regression introduce by https://bugzilla.gnome.org/show_bug.cgi?id=732553 ---
...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#797371)](https://bugzilla.gnome.org/show_bug.cgi?id=797371)**
## Description
-- regression introduce by https://bugzilla.gnome.org/show_bug.cgi?id=732553 ---
If you pass any valid 5 first bytes of a NAL to the parser, it will now always return OK instead of NO_NAL_END. This is caused by broken code trying to handle single byte SEQ_END / STREAM_END as being complete NAL.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/811dtlsdec: Critical warnings in gst-inspect2019-05-02T10:20:59ZBugzilla Migration Userdtlsdec: Critical warnings in gst-inspect## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#797364)](https://bugzilla.gnome.org/show_bug.cgi?id=797364)**
## Description
** (gst-inspect-1.0:23460): CRITICAL **: 23:38:49.968: file gstdtlsagent.c: line 188 (gs...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#797364)](https://bugzilla.gnome.org/show_bug.cgi?id=797364)**
## Description
** (gst-inspect-1.0:23460): CRITICAL **: 23:38:49.968: file gstdtlsagent.c: line 188 (gst_dtls_agent_init): should not be reached
** (gst-inspect-1.0:23460): CRITICAL **: 23:38:49.968: gst_dtls_agent_set_property: assertion 'self->priv->ssl_context' failed
[...]
** (gst-inspect-1.0:23460): CRITICAL **: 23:38:49.968: gst_dtls_agent_get_certificate_pem: assertion 'GST_IS_DTLS_CERTIFICATE (self->priv->certificate)' failedhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/810waylandsink: resize didn't support set window position2019-02-15T14:05:22ZBugzilla Migration Userwaylandsink: resize didn't support set window position## Submitted by Haihua Hu `@JaredHu`
**[Link to original bug (#797360)](https://bugzilla.gnome.org/show_bug.cgi?id=797360)**
## Description
when resize using videooverlay interface, the window position (x,y)didn't take effect for wa...## Submitted by Haihua Hu `@JaredHu`
**[Link to original bug (#797360)](https://bugzilla.gnome.org/show_bug.cgi?id=797360)**
## Description
when resize using videooverlay interface, the window position (x,y)didn't take effect for waylandsink. Do we have any software limitation.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/809meson: Unkonw variables while disabling msdk plugin2018-11-06T22:12:16ZBugzilla Migration Usermeson: Unkonw variables while disabling msdk plugin## Submitted by Jordan Petridis
**[Link to original bug (#797354)](https://bugzilla.gnome.org/show_bug.cgi?id=797354)**
## Description
While building with auto_features=enabled -Dmsdk=disabled I encountered the following error.
...## Submitted by Jordan Petridis
**[Link to original bug (#797354)](https://bugzilla.gnome.org/show_bug.cgi?id=797354)**
## Description
While building with auto_features=enabled -Dmsdk=disabled I encountered the following error.
'tests/check/meson.build:18:0: ERROR: Unknown variable "have_msdk".'
same error was also thrown later for "msdk_dep".
This happened right after 55134df54c99b09556d3d0f60b9b4f029123af0e which to my understanding added an early exit before the variables where declared.
I am not sure if the following patch is the proper way to fix it, using auto-feature magic in the test too would probably be cleaner but I did not managed to figure out if its possible.
Tested the following patch in gnome-build-meta. https://gitlab.gnome.org/GNOME/gnome-build-meta/commit/8915cb51a25559163e2f1e6736742d8c242acf5fhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/807dshowvideosrc: add device-index, add GstDeviceMonitor, and several fixes2018-11-09T09:53:29ZBugzilla Migration Userdshowvideosrc: add device-index, add GstDeviceMonitor, and several fixes## Submitted by Joshua M. Doe
**[Link to original bug (#797338)](https://bugzilla.gnome.org/show_bug.cgi?id=797338)**
## Description
Created attachment 374042
0001 - dshowsrcwrapper: add debug category for general dshowsrcwrapper ...## Submitted by Joshua M. Doe
**[Link to original bug (#797338)](https://bugzilla.gnome.org/show_bug.cgi?id=797338)**
## Description
Created attachment 374042
0001 - dshowsrcwrapper: add debug category for general dshowsrcwrapper
It seems the DirectShow source dshowvideosrc hasn't seen much attention lately. The plugin winks provides ksvideosrc which supports most modern video sources, that is devices supporting the USB Video Class (UVC). However there are still several sources which are stuck with DirectShow, which I happen to be stuck using, so I worked on it a bit to make it usable for me.
They can be seen here:
https://github.com/joshdoe/gst-plugins-bad/tree/dshowsrc
There are 11 patches, should I upload them all here? I already did some squashing, but perhaps could go further to limit the number of patches.
**Patch 374042**, "0001 - dshowsrcwrapper: add debug category for general dshowsrcwrapper":
[0001-dshowsrcwrapper-add-debug-category-for-general-dshow.patch](/uploads/d8f6f12d2f5d9f240560c6dbfb237072/0001-dshowsrcwrapper-add-debug-category-for-general-dshow.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/806Live Audio Playback from Microphone Goes Silent on Windows wasapi2019-11-28T20:38:48ZBugzilla Migration UserLive Audio Playback from Microphone Goes Silent on Windows wasapi## Submitted by Michael MacIntosh
**[Link to original bug (#797329)](https://bugzilla.gnome.org/show_bug.cgi?id=797329)**
## Description
Created attachment 374015
An excerpt of the ringbuffer:5 debug logs.
I am running into a...## Submitted by Michael MacIntosh
**[Link to original bug (#797329)](https://bugzilla.gnome.org/show_bug.cgi?id=797329)**
## Description
Created attachment 374015
An excerpt of the ringbuffer:5 debug logs.
I am running into audio playback issues in the latest versions of gstreamer. I am using 1.14.4 on windows 10 but have also experienced this issue on windows 7. It is most pronounced with wasapisrc and wasapisink, but I have experienced this issue with directsoundsrc and directsoundsink and combinations thereof. My current workaround (that I am still testing, but getting better results) is using directsoundsrc and directsoundsink with double the default buffer times and latency times.
With wasapisrc, playback via wasapisink will go silent after a certain amount of time or go choppy. The audio will usually play for a few seconds, go silent for about 15-20 seconds, then play again for another 3 seconds. It usually repeats this process until it will eventually cut out completely.
A simple pipeline to reproduce this issue would be something like:
wasapisrc ! queue ! audioconvert ! audioresample ! wasapisink
(the audioconvert and audioresample are probably superfluous)
This is assuming you are using headphones and have a microphone plugged in, so it can select them as default devices.
Running the pipeline with gst-debug="ringbuffer:5" gives log output that appears to indicate that the read pointer is getting ahead of the write pointer in the ringbuffer (the diff goes negative and the sink stops playing the audio).
I do not get this issue with file or network sources of audio. It is more common / severe with wasapisrc over directsoundsrc (it takes much longer for directsoundsrc to play nothing).
I have tried increasing the latency-time and the buffer-time of wasapisink, which does improve the audio quality quite a bit, however it still runs into issues.
Attached is an excerpt of the ringbuffer:5 log. In this section the diff goes to -20 out of 20 (segtotal). I presume that this negative diff causes audio to not play since it sets skip to true, and doesn't copy anything into the ringbuffer.
I was also noticing negative diffs with the audiosrc ringbuffer, and I can provide logs of that as well.
This bug might be a duplicate / related to
https://bugzilla.gnome.org/show_bug.cgi?id=796354
However, they do not make any mention to silence.
Let me know if there is anything else I can provide / clarify.
**Attachment 374015**, "An excerpt of the ringbuffer:5 debug logs.":
[ringbuffer_5_debug_excerpt.txt](/uploads/de66909a8d85f5bf7cdef75b978d4d80/ringbuffer_5_debug_excerpt.txt)
Version: 1.14.4
### See also
* [Bug 797334](https://bugzilla.gnome.org/show_bug.cgi?id=797334)
* [Bug 796354](https://bugzilla.gnome.org/show_bug.cgi?id=796354)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/805webrtcbin: GStreamer-CRITICAL (padname not unique) with enabled both ULP_FEC ...2022-10-25T03:10:10ZBugzilla Migration Userwebrtcbin: GStreamer-CRITICAL (padname not unique) with enabled both ULP_FEC and RTX using iOS devices## Submitted by Szymon Piechaczek
**[Link to original bug (#797328)](https://bugzilla.gnome.org/show_bug.cgi?id=797328)**
## Description
I'm using webrtcbin as sendrecv endpoint (H264 video and Opus audio) with iOS devices (native W...## Submitted by Szymon Piechaczek
**[Link to original bug (#797328)](https://bugzilla.gnome.org/show_bug.cgi?id=797328)**
## Description
I'm using webrtcbin as sendrecv endpoint (H264 video and Opus audio) with iOS devices (native WebRTC SDK) and I've been facing many video issues over wireless networks (dropped keyframes etc.).
I enabled FEC and RTX on webrtcbin with this Python code:
def _on_new_transceiver(self, element, transceiver):
if transceiver.mline == 1:
transceiver.set_property("fec-type", GstWebRTC.WebRTCFECType.ULP_RED)
transceiver.set_property("do-nack", True)
The problem is that enabling _both_ of them makes webrtcbin to double-create "src_1" pad:
app_1 | #ERR#Stream 5bcf2d353a11a300394baf0f#: 0:00:09.072505020 212 0x7f4df0095050 DEBUG webrtcbin gstwebrtcbin.c:3369:on_rtpbin_request_pt_map:`<webrtcbin0>` getting pt map for pt 99 in session 1
app_1 | #ERR#Stream 5bcf2d353a11a300394baf0f#: 0:00:09.073430701 212 0x7f4df0095050 INFO rtpjitterbuffer rtpjitterbuffer.c:778:rtp_jitter_buffer_calculate_pts: resync to time 0:00:07.084805979, rtptime 8:16:32.042122222
app_1 | #ERR#Stream 5bcf2d353a11a300394baf0f#: 0:00:09.073458015 212 0x7f4dac003c50 INFO rtpjitterbuffer gstrtpjitterbuffer.c:3942:do_deadline_timeout:`<rtpjitterbuffer2>` got deadline timeout
app_1 | #ERR#Stream 5bcf2d353a11a300394baf0f#: 0:00:09.073584023 212 0x7f4df02a21e0 DEBUG webrtcbin gstwebrtcbin.c:3562:on_rtpbin_request_fec_decoder:`<webrtcbin0>` Creating ULPFEC decoder for pt 97 in session 1
app_1 | #ERR#Stream 5bcf2d353a11a300394baf0f#: 0:00:09.074065056 212 0x7f4df02a21e0 DEBUG webrtcbin gstwebrtcbin.c:3301:copy_sticky_events:<webrtcbin0:src_1> store sticky event stream-start event: 0x7f4dc40055e0, time 99:99:99.999999999, seq-num 741, GstEventStreamStart, stream-id=(string)d86ca30418e5b0ec624d6b445597ed11, flags=(GstStreamFlags)GST_STREAM_FLAG_NONE, group-id=(uint)6;
app_1 | #ERR#Stream 5bcf2d353a11a300394baf0f#: 0:00:09.074097198 212 0x7f4df02a21e0 DEBUG webrtcbin gstwebrtcbin.c:3301:copy_sticky_events:<webrtcbin0:src_1> store sticky event caps event: 0x7f4dc8001c40, time 99:99:99.999999999, seq-num 17928, GstEventCaps, caps=(GstCaps)"application/x-rtp\,\ media\=\(string\)video\,\ payload\=\(int\)99\,\ clock-rate\=\(int\)90000\,\ encoding-name\=\(string\)RTX\,\ apt\=\(string\)110\,\ ssrc\=\(uint\)572172575";
app_1 | 0:00:09.074150118 212 0x7f4df02a21e0 DEBUG webrtcbin gstwebrtcbin.c:3301:copy_sticky_events:<webrtcbin0:src_1> store sticky event segment event: 0x7f4dc4005650, time 99:99:99.999999999, seq-num 736, GstEventSegment, segment=(GstSegment)"GstSegment, flags=(GstSegmentFlags)GST_SEGMENT_FLAG_NONE, rate=(double)1, applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, base=(guint64)0, offset=(guint64)0, start=(guint64)0, stop=(guint64)18446744073709551615, time=(guint64)0, position=(guint64)0, duration=(guint64)18446744073709551615;";
app_1 | (python3:212): GStreamer-CRITICAL **: 16:16:35.793: Padname src_1 is not unique in element webrtcbin0, not adding
app_1 | #ERR#Stream 5bcf2d353a11a300394baf0f#: 0:00:09.130071459 212 0x7f4df0095940 WARN basesrc gstbasesrc.c:3055:gst_base_src_loop:`<nicesrc3>` error: Internal data stream error.
app_1 | 0:00:09.130115420 212 0x7f4df0095940 WARN basesrc gstbasesrc.c:3055:gst_base_src_loop:`<nicesrc3>` error: streaming stopped, reason not-linked (-1)
app_1 | #Stream 5bcf2d353a11a300394baf0f#: BUS ERROR: gst-stream-error-quark 1 | DEBUG: gstbasesrc.c(3055): gst_base_src_loop (): /GstPipeline:episode_5bcf2d353a11a300394baf0f/GstBin:compositor_1001/GstWebRTCBin:webrtcbin0/TransportReceiveBin:transportreceivebin1/GstNiceSrc:nicesrc3:
app_1 | streaming stopped, reason not-linked (-1)
With WebRTC peer on Google Chrome everything is OK (SDP answer is almost the same) and ULPFEC decoder is create earilier. On iOS it is somehow delayed.
I've looked into the source code and found two possible bug-causing lines:
https://github.com/GStreamer/gst-plugins-bad/blob/master/ext/webrtc/gstwebrtcbin.c#L4506-L4507
https://github.com/GStreamer/gst-plugins-bad/blob/master/ext/webrtc/gstwebrtcbin.c#L4589-L4594
Version: 1.14.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/803srtp: Add support for MKI2018-11-10T02:25:53ZBugzilla Migration Usersrtp: Add support for MKI## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#797305)](https://bugzilla.gnome.org/show_bug.cgi?id=797305)**
## Description
Currently, our SRTP elements don't support MKIs. This patch series adds support for them....## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#797305)](https://bugzilla.gnome.org/show_bug.cgi?id=797305)**
## Description
Currently, our SRTP elements don't support MKIs. This patch series adds support for them.
It has 2 parts:
* Encoder
I just added an MKI property and then it puts a "mki" element in the caps with the MKI in a buffer. This still only allows for one MKI.
* Decoder
This may be a bit more controversial, as I'm allowing multiple MKIs, instead of having separate CAPS, I'm putting them all in one with "srtp-key=X, mki=X, mki2=Y, srtp-key2=Y, mki3=Z, srtp-key3=Z", up to 15, which is the maximum allowed by libsrtp.
The other thing that could be controversial is that support for MKIs were added in libsrtp 2.1. So I put the whole thing behind ifdeds, included the extra MKI property. If no one yells, I would be tempted to just drop the ifdefs and require libsrtp 2.1 at least for everyone.
I'm also attaching a patch against Cerbero to bump libsrtp to 2.2.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/802mpegts: support for JPEG 2000 is broken2019-11-20T13:08:07ZBugzilla Migration Usermpegts: support for JPEG 2000 is broken## Submitted by Aaron Boxer
**[Link to original bug (#797292)](https://bugzilla.gnome.org/show_bug.cgi?id=797292)**
## Description
The following pipeline used to work:
$ gst-launch-1.0 -v videotestsrc ! openjpegenc ! jpeg2000pa...## Submitted by Aaron Boxer
**[Link to original bug (#797292)](https://bugzilla.gnome.org/show_bug.cgi?id=797292)**
## Description
The following pipeline used to work:
$ gst-launch-1.0 -v videotestsrc ! openjpegenc ! jpeg2000parse ! mpegtsmux ! tsdemux ! jpeg2000parse ! openjpegdec ! videoconvert ! ximagesink
Now, with gst-plugins-bad master and OpenJPEG master, I get these errors:
:00:00.076905409 26973 0x194c0a0 ERROR tsdemux tsdemux.c:2795:parse_jp2k_access_unit: Required size (23237) greater than remaining size in buffer (23229)
0:00:00.076924988 26973 0x194c0a0 ERROR tsdemux tsdemux.c:2807:parse_jp2k_access_unit: Failed to parse JP2K access unithttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/801d3dvideosink is broken in git master2018-11-09T08:31:13ZBugzilla Migration Userd3dvideosink is broken in git master## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#797285)](https://bugzilla.gnome.org/show_bug.cgi?id=797285)**
## Description
Steps to reproduce:
gst-launch-1.0 videotestsrc ! d3dvideosink
Results: vi...## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#797285)](https://bugzilla.gnome.org/show_bug.cgi?id=797285)**
## Description
Steps to reproduce:
gst-launch-1.0 videotestsrc ! d3dvideosink
Results: video is stuck on the first frame and the console is flooded with:
0:00:01.436545748 6772 0000000002B18000 ERROR default video-frame.c:162:gst_video_frame_map_id: failed to map video frame plane 1
glimagesink works perfectly.1.15.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/800h264parse/h265parse: Multi-slices and NAL alignments fixes2020-04-15T16:24:28ZBugzilla Migration Userh264parse/h265parse: Multi-slices and NAL alignments fixes## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#797281)](https://bugzilla.gnome.org/show_bug.cgi?id=797281)**
## Description
I've been working on multi slices H264/H265 streaming and encounter several issues ...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#797281)](https://bugzilla.gnome.org/show_bug.cgi?id=797281)**
## Description
I've been working on multi slices H264/H265 streaming and encounter several issues with h264parse/h265parse. This encoding method is used to reduce the latency. When used, we want the decoder to start decoding the frame as soon as a slice is received rather then when a complete image was found.
My patchset is not full ready yet, specially that I need to add unit test for each of the aspect corrected. If we merge the base class for these, we'll probably be able to reduce this patchset size, though we need to rewrite it at the same time.
Overall, I've been addressing issues like:
- Input alignment isn't used to reduce parsing latency
- Timestamps/Duration issues
- Marker flags not being used/transferred
- Missing AUD insertion (h265parse)
- First NAL is pushed because we have complete caps (need work still)
- Bug in H265parse caused by SUFFIX SEI not being treaded as such
https://gitlab.collabora.com/nicolas/gst-plugins-bad/commits/h26xparse-fixeshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/798[regression] h265parser: Fix wrong maximum range check in gst_h265_parse_vps()2018-11-09T08:31:13ZBugzilla Migration User[regression] h265parser: Fix wrong maximum range check in gst_h265_parse_vps()## Submitted by Seungha Yang
**[Link to original bug (#797279)](https://bugzilla.gnome.org/show_bug.cgi?id=797279)**
## Description
I found regression after fix of [bug 754124](https://bugzilla.gnome.org/show_bug.cgi?id=754124).
T...## Submitted by Seungha Yang
**[Link to original bug (#797279)](https://bugzilla.gnome.org/show_bug.cgi?id=797279)**
## Description
I found regression after fix of [bug 754124](https://bugzilla.gnome.org/show_bug.cgi?id=754124).
The patch in [bug 754124](https://bugzilla.gnome.org/show_bug.cgi?id=754124) seems to correct but the actual bug is in h265parser1.14.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/794h265parser: Fails to parse VUI when default display window is missing2020-05-27T23:45:32ZBugzilla Migration Userh265parser: Fails to parse VUI when default display window is missing## Submitted by Matej `@Knopp`
**[Link to original bug (#797228)](https://bugzilla.gnome.org/show_bug.cgi?id=797228)**
## Description
Created attachment 373810
Patch
This is just sad.
As far as I can tell, these files ar...## Submitted by Matej `@Knopp`
**[Link to original bug (#797228)](https://bugzilla.gnome.org/show_bug.cgi?id=797228)**
## Description
Created attachment 373810
Patch
This is just sad.
As far as I can tell, these files are non compliant. Unfortunately, there are out in the wild (the sample I have is from streaming service) and they decode with both FFmpeg and hardware decoders. So obviously users expect them to play.
Relevant issues in FFmpeg:
https://trac.ffmpeg.org/ticket/6644
https://trac.ffmpeg.org/ticket/4035
Sample file:
https://trac.ffmpeg.org/attachment/ticket/6644/%5BH265%5D%20Goodbye%20Happiness_cut.mkv
~~**Patch 373810**~~, "Patch":
[0001-h265parser-handle-VUI-with-default-display-window-mi.patch](/uploads/7acb9a17fdf3cabeda99d781d1cfac1c/0001-h265parser-handle-VUI-with-default-display-window-mi.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/790h264/5parse: mark SEI Recovery Point as keyframes2018-12-02T02:13:36ZBugzilla Migration Userh264/5parse: mark SEI Recovery Point as keyframes## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#797216)](https://bugzilla.gnome.org/show_bug.cgi?id=797216)**
## Description
The AVC and HEVC spec states that "recovery point SEI message assists a decoder i...## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#797216)](https://bugzilla.gnome.org/show_bug.cgi?id=797216)**
## Description
The AVC and HEVC spec states that "recovery point SEI message assists a decoder in determining when the decoding process will produce acceptable pictures for display after the decoder initiates random access or after the encoder indicates a broken link in the coded video sequence."
Mark those as keyframes so muxers will mark them as seek points and
decoders will be able to start decoding from them rather than waiting
for an IDR.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/778Add split-field interlacing to h265parse & interlace elements2020-03-31T15:17:55ZBugzilla Migration UserAdd split-field interlacing to h265parse & interlace elements## Submitted by Zeeshan Ali `@zeenix`
**[Link to original bug (#797063)](https://bugzilla.gnome.org/show_bug.cgi?id=797063)**
## Description
These patches add split-field (alternate) interlacing support to h265parse and interlace el...## Submitted by Zeeshan Ali `@zeenix`
**[Link to original bug (#797063)](https://bugzilla.gnome.org/show_bug.cgi?id=797063)**
## Description
These patches add split-field (alternate) interlacing support to h265parse and interlace elements.
These patches are not yet ready to be merged as the caps lack the needed feature, which will be added soon. The point of submitting them already was to already get opinions/suggestions on the main changes.
Also I'm not entirely sure if the (short-cut) approach I took for interlace is what we would want. Suggestions welcome.