gst-plugins-bad issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues2023-12-20T15:04:25Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/136dvdspu: handle video/x-raw(ANY) if downstream supports the GstVideoOverlayCom...2023-12-20T15:04:25ZBugzilla Migration Userdvdspu: handle video/x-raw(ANY) if downstream supports the GstVideoOverlayCompositionMeta API## Submitted by Matthieu Bouron
**[Link to original bug (#725900)](https://bugzilla.gnome.org/show_bug.cgi?id=725900)**
## Description
This patch makes the dvdspu element handle video/x-raw(ANY) if downstream
supports the GstVideo...## Submitted by Matthieu Bouron
**[Link to original bug (#725900)](https://bugzilla.gnome.org/show_bug.cgi?id=725900)**
## Description
This patch makes the dvdspu element handle video/x-raw(ANY) if downstream
supports the GstVideoOverlayCompositionMeta API since in this case it only
places the correct meta on outgoing buffers.
This patch in based on the on-going work on the GstVideoOverlayCompositionMeta API support in the dvdspu element. See: https://bugzilla.gnome.org/show_bug.cgi?id=685282.
It also depends on https://bugzilla.gnome.org/show_bug.cgi?id=725893.
Development branch can be found here: http://cgit.collabora.com/git/user/mateo/gst-plugins-bad.git/log/?h=dvdspu
### Depends on
* [Bug 685282](https://bugzilla.gnome.org/show_bug.cgi?id=685282)
* [Bug 725893](https://bugzilla.gnome.org/show_bug.cgi?id=725893)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/78dvdspu: figure out how to make it work with hardware decoders and subpicture ...2023-12-18T15:36:59ZBugzilla Migration Userdvdspu: figure out how to make it work with hardware decoders and subpicture overlays## Submitted by Jan Schmidt `@thaytan`
Assigned to **Jan Schmidt `@thaytan`**
**[Link to original bug (#685282)](https://bugzilla.gnome.org/show_bug.cgi?id=685282)**
## Description
Getting the DVD SPU to paint generically is a req...## Submitted by Jan Schmidt `@thaytan`
Assigned to **Jan Schmidt `@thaytan`**
**[Link to original bug (#685282)](https://bugzilla.gnome.org/show_bug.cgi?id=685282)**
## Description
Getting the DVD SPU to paint generically is a requirement for allowing the DVD elements to plug / output hardware decoder caps.
Here's a conversation we had about it on IRC:
Sep 26 01:37:04 * thaytan wonders how SPU works
Sep 26 01:37:19 `<bilboed>` thaytan, with vdpau ?
Sep 26 01:37:24 `<thaytan>` *nod*
Sep 26 01:37:35 `<thaytan>` how it should work, that is
Sep 26 01:37:36 `<bilboed>` they have also VdpBitmapSurface
Sep 26 01:38:01 `<bilboed>` so VdpVideoSurface => YUV stuff, VdpBitmapSurface => RGB stuff
Sep 26 01:38:11 `<bilboed>` VdpOutputSurface => output of the compositor for display
Sep 26 01:38:40 `<bilboed>` you can create VdpBitmapSurface and map(write) stuff on it
Sep 26 01:39:01 `<bilboed>` then you give it to the compositor with coordinates (and whatever else) and that's basically it
Sep 26 01:39:09 `<thaytan>` hmmm
Sep 26 01:39:26 `<bilboed>` so as a result ... I'm also gonna have to figure out how to solve hw-compositing
Sep 26 01:39:28 `<thaytan>` not sure I see how that fits into a GStreamer/rsndvdbin context
Sep 26 01:39:31 `<bilboed>` in a generic fashion that is
Sep 26 01:39:55 `<bilboed>` thaytan, was thinking you could slap GstOverlayMeta (or sth like that) with attached GstBuffers
Sep 26 01:40:06 `<bilboed>` thaytan, maybe videomixer or some generic element could do that
Sep 26 01:40:09 `<thaytan>` I guess it's a vdpspu element with video and subpicture inputs as currently with dvdspu
Sep 26 01:40:25 `<thaytan>` except the video pad accepts vdp output surface caps
Sep 26 01:40:38 `<bilboed>` I'd prefer to avoid creating yet-another-custom-element
Sep 26 01:40:45 `<thaytan>` but, I don't know what it outputs
Sep 26 01:41:12 `<thaytan>` bilboed: I don't know how to build it generically
Sep 26 01:41:48 `<thaytan>` the dvdspu element uses the video stream passing through to a) paint onto b) uses the timestamps to crank the SPU state machine
Sep 26 01:42:44 `<bilboed>` what do you need more apart from "put this RGB bitmap at these coordinates for this timestamp and this duration"
Sep 26 01:43:48 `<thaytan>` it needs the timestamps and segment info on the video stream so it knows which pixels to generate
Sep 26 01:44:04 `<thaytan>` it's more "here's a video frame, what's the overlay?"
Sep 26 01:44:13 `<thaytan>` also, dvdspu works in YUV too
Sep 26 01:44:13 `<bilboed>` sure, but it doesn't care about the *content* of that frame
Sep 26 01:44:28 `<thaytan>` bilboed: not if it's not doing the compositing, no
Sep 26 01:44:34 `<bilboed>` right
Sep 26 01:45:11 `<bilboed>` so it could see the stream go through, watch/collect segment/timestamps and decide what subpicture to attach to it (without *actually* doing any processing and letting downstream handle that)
Sep 26 01:45:13 `<thaytan>` but the model is still to pass the video buffer stream through the spu element so it can see the timing info it needs, right?
Sep 26 01:45:22 `<thaytan>` oh, of course
Sep 26 01:45:28 `<thaytan>` that's what I was suggesting, I guess I wasn't clear
Sep 26 01:45:35 `<__tim>` thaytan, dvdspu should support GstVideoOverlayComposition imho
Sep 26 01:45:38 `<bilboed>` I'm not *that* familiar with SPU
Sep 26 01:45:42 `<bilboed>` also, what __tim said :)
Sep 26 01:45:54 `<bilboed>` like that I don't have to solve it in 500 different elements
Sep 26 01:45:56 `<thaytan>` ok, I guess I'll have to look at the GstVideoOverlayComposition API
Sep 26 01:46:54 * bilboed is not looking forward "at all" to fixing this for cluster-gst
Sep 26 01:47:12 `<__tim>` it's very dumb, you can provide one or more ARGB or AYUV rectangles and either use helper API to put them onto the raw video, or attach them to the buffer; the sink or whatever can then take over the overlaying using that
Sep 26 01:47:40 `<__tim>` and it will do a bunch of conversions for you and cache them if the sink or whatever does the overlaying doesn't support what you supplied
Sep 26 01:48:54 `<thaytan>` well, that sounds feasible - although less efficient than dvdspu painting natively if the composite is in software
Sep 26 01:49:28 `<thaytan>` maybe it can be extended to add RLE AYUV rectangles as a format though?
Sep 26 01:49:44 `<__tim>` thaytan, how sure are you of that? because basically you have to parse the RLE data for every single frame, right? is that really so much faster than blitting some ready-made rectangle using orc?
Sep 26 01:50:04 `<thaytan>` dvdspu gets to skip a lot of transparent pixels
Sep 26 01:52:21 `<__tim>` yeah, but it's if else and loops etc. You might be right, I'm just curious how much difference it actually makes. Also, you don't have to use the API to blit your pixels, you can still do that as you do now and only attach the AYUV rectangle if downstream supports that
Sep 26 01:54:13 `<__tim>` it's just convenient because you only have one code path
Sep 26 01:55:01 `<thaytan>` it sounds like a structural improvement
### Blocking
* [Bug 663750](https://bugzilla.gnome.org/show_bug.cgi?id=663750)
* [Bug 725900](https://bugzilla.gnome.org/show_bug.cgi?id=725900)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/16tsdemux: Better handle PCR<=>PTS conversion (big difference, latency, ...)2023-09-27T17:20:46ZBugzilla Migration Usertsdemux: Better handle PCR<=>PTS conversion (big difference, latency, ...)## Submitted by Marc-André Lureau `@elmarco`
**[Link to original bug (#608148)](https://bugzilla.gnome.org/show_bug.cgi?id=608148)**
## Description
Created attachment 152305
a segment
Yacast provides apple http live streaming...## Submitted by Marc-André Lureau `@elmarco`
**[Link to original bug (#608148)](https://bugzilla.gnome.org/show_bug.cgi?id=608148)**
## Description
Created attachment 152305
a segment
Yacast provides apple http live streaming streams, but the segments are not playable with ffdec_h264 (using 0.10.8.2)
ffmpeg can play it fine :)
(original "live" playlist http://stream7.nrj.yacast.net/iphone/nrj/nrjtp/nrj_tvparis_300.m3u8)
segment attached
**Attachment 152305**, "a segment":
[seq_nrj_tvparis_300-113780.ts](/uploads/a0cdcd68d106a18f18d5b26386c97304/seq_nrj_tvparis_300-113780.ts)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/241unable to dynamically insert tsmux into running pipeline2023-09-27T15:30:22ZBugzilla Migration Userunable to dynamically insert tsmux into running pipeline## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#747898)](https://bugzilla.gnome.org/show_bug.cgi?id=747898)**
## Description
Created attachment 301598
./tsswitchtest <short-file.ts>
i have a scenario wher...## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#747898)](https://bugzilla.gnome.org/show_bug.cgi?id=747898)**
## Description
Created attachment 301598
./tsswitchtest <short-file.ts>
i have a scenario where i wanna dynamically switch the input of a gst-rtsp-server streaming mpeg ts (with h.264 + aac es inside) from a ts stream delivered over a socket to a still image in case the input stream is lost.
so i destilled this into a minimal test case reading a ts from a file in an appsrc's need-data callback and then removing the appsrc and replacing it with testsources when the file is played completely.
so basically i have this pipeline (except with appsrc instead of filesrc)
gst-launch-1.0 filesrc location=test.ts ! queue name=ts_queue ! tsparse name=tsparse set-timestamps=TRUE ! tsdemux name=d d. ! queue ! faad ! audioconvert ! alsasink d. ! queue ! h264parse ! avdec_h264 ! autovideosink
and replace it with
gst-launch-1.0 videotestsrc ! capsfilter ! x264enc ! mpegtsmux name=m audiotestsrc ! capsfilter ! faac ! m. m. ! queue name=ts_queue ! tsparse name=tsparse set-timestamps=TRUE ! tsdemux name=d d. ! queue ! faad ! audioconvert ! alsasink d. ! queue ! h264parse ! avdec_h264 ! autovideosink
i did lots of experiments trying to get the timestamps right to achieve a seamless transition but I suspect some bugginess because there are also
(tsswitchtest:10281): GStreamer-WARNING **: gstpad.c:4802:store_sticky_event:<ts_queue:sink> Sticky event misordering, got 'segment' before 'caps'
the testsources seem to produce the buffers with the correct timestamps because they show up as
tsparse mpegtsparse.c:789:drain_pending_buffers:`<tsparse>` Pushing buffers - startTS 0:00:13.874543898 duration 0:00:00.119712000 16168 bytes
...
but then after each drain line, there are several
GST_PADS gstpad.c:4102:gst_pad_chain_list_default:<tsparse:sink> chaining each group in list as a merged buffer
and faad will eventually error out because it can't decode the stream
**Attachment 301598**, "./tsswitchtest <short-file.ts>":
[tsswitchtest.c](/uploads/e6f3d64f19d6bc8a906babd3c94aae90/tsswitchtest.c)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/257tsdemux: Not able to play HEVC video clip in pull mode2023-08-25T09:25:52ZBugzilla Migration Usertsdemux: Not able to play HEVC video clip in pull mode## Submitted by ris..@..il.com
**[Link to original bug (#750341)](https://bugzilla.gnome.org/show_bug.cgi?id=750341)**
## Description
Not able to play any big buck bunny HEVC video clip using tsdemux from video clip with file format...## Submitted by ris..@..il.com
**[Link to original bug (#750341)](https://bugzilla.gnome.org/show_bug.cgi?id=750341)**
## Description
Not able to play any big buck bunny HEVC video clip using tsdemux from video clip with file format MPEG-TS.
System: Feodra 21 64bit
Video clip URL: http://www.elecard.com/en/download/videos.html
Under Big Buck Bunny - SD, 720p and 1080p HEVC video clip
msg:
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstTSDemux:tsdemux0: Internal data stream error.
Additional debug info:
mpegtsbase.c(1342): mpegts_base_loop (): /GstPipeline:pipeline0/GstTSDemux:tsdemux0:
stream stopped, reason not-linked
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/769h264parse: wrong DTS calculation when not provided by the stream2023-07-11T12:06:53ZBugzilla Migration Userh264parse: wrong DTS calculation when not provided by the stream## Submitted by Gaylord Charles `@gaylord.charles`
**[Link to original bug (#796962)](https://bugzilla.gnome.org/show_bug.cgi?id=796962)**
## Description
Created attachment 373333
Logs with GST_DEBUG="tsdemux:5,baseparse:6,h264par...## Submitted by Gaylord Charles `@gaylord.charles`
**[Link to original bug (#796962)](https://bugzilla.gnome.org/show_bug.cgi?id=796962)**
## Description
Created attachment 373333
Logs with GST_DEBUG="tsdemux:5,baseparse:6,h264parse:5"
I experienced some problems while transmuxing an UDP TS stream (from a live streaming hardware encoder) to a RTMP stream with the following pipeline (Gstreamer 1.14.2):
gst-launch-1.0 flvmux name=mux streamable=true ! queue ! rtmpsink location=rtmp://192.168.1.26:1935/live/my_stream \
udpsrc uri=udp://192.168.1.43:9001 do-timestamp=false ! queue ! tsdemux name=dem \
dem. ! h264parse ! queue ! mux. dem. ! aacparse ! queue ! mux.
My encoder produces a H.264 + AAC program.
There are no errors while running the pipeline but the RTMP server is not able to correctly play the received stream.
After some debugging (GST_DEBUG="tsdemux:5,baseparse:6,h264parse:5"), I found out a possible problem with the DTS calculation on H.264 stream.
Here is an example of the logs from baseparse (the full log file is available as an attachment):
0:00:00.575681258 LOG baseparse gstbaseparse.c:2147:gst_base_parse_handle_buffer:`<h264parse0>` handling buffer of size 8174 with dts 0:00:00.033333332, pts 0:00:02.551755111, duration 99:99:99.999999999
The origin of the bug lays in the TS where DTS is not provided:
0:00:00.530313511 DEBUG tsdemux tsdemux.c:2297:gst_ts_demux_parse_pes_header:`<dem>` stream PTS 0:00:02.551755111 DTS 99:99:99.999999999
The compliance of such a stream is debatable, but there are no B frames in the H.264 stream from the encoder. So we could assume DTS = PTS.
I made a quick (and dirty) fix in tsdemux.c (please refer to the attached patch) to make my pipeline work (and the video correctly decoded on the RTMP server).
Do you have any suggestions to solve this cleanly (maybe in h264parse or baseparse) ?
**Attachment 373333**, "Logs with GST_DEBUG="tsdemux:5,baseparse:6,h264parse:5"":
[gst_debug_dump.log](/uploads/3d9d51d2585f346be7f889f496610f1c/gst_debug_dump.log)
Version: 1.14.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/122dvdspu: gst_segment_to_running_time: assertion 'segment->format == format' fa...2023-07-11T11:01:06ZBugzilla Migration Userdvdspu: gst_segment_to_running_time: assertion 'segment->format == format' failed## Submitted by Frank Ansari
**[Link to original bug (#719903)](https://bugzilla.gnome.org/show_bug.cgi?id=719903)**
## Description
What I want to achieve: DVD playback with totem media player.
I get this error message when I r...## Submitted by Frank Ansari
**[Link to original bug (#719903)](https://bugzilla.gnome.org/show_bug.cgi?id=719903)**
## Description
What I want to achieve: DVD playback with totem media player.
I get this error message when I run
gst-launch-1.0 playbin uri=dvd://
with "Desperate Housewives" (season 4, part 2, episodes 11-14).
gst_segment_to_running_time: assertion 'segment->format == format' failed
When I insert seasion 4, part 2, episodes 15-17 I get a different error message:
ERROR: from element /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:abin/GstAutoAudioSink:audiosink/GstPulseSink:audiosink-actual-sink-pulse: The stream is in the wrong format.
Additional debug info:
gstaudiobasesink.c(1972): gst_audio_base_sink_render (): /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:abin/GstAutoAudioSink:audiosink/GstPulseSink:audiosink-actual-sink-pulse:
sink not negotiated.
Both DVDs work fine using Fluendo DVD player.
What is going on?
I have a fresh Arch Linux instalation with these gstreamer compoments:
local/clutter-gst 2.0.8-1
GStreamer bindings for clutter
local/gnome-video-effects 0.4.0-2
A collection of GStreamer effects
local/gst-libav 1.2.1-1
Gstreamer libav Plugin
local/gst-plugins-bad 1.2.1-1
GStreamer Multimedia Framework Bad Plugins
local/gst-plugins-base 1.2.1-1
GStreamer Multimedia Framework Base Plugins
local/gst-plugins-base-libs 1.2.1-1
GStreamer Multimedia Framework Base Plugin libraries
local/gst-plugins-good 1.2.1-1
GStreamer Multimedia Framework Good Plugins
local/gst-plugins-ugly 1.2.1-2
GStreamer Multimedia Framework Ugly Plugins
local/gstreamer 1.2.1-1
GStreamer Multimedia Framework
local/gstreamer0.10 0.10.36-2
GStreamer Multimedia Framework
local/gstreamer0.10-bad 0.10.23-5
GStreamer Multimedia Framework Bad Plugin libraries (gst-plugins-bad)
local/gstreamer0.10-bad-plugins 0.10.23-5 (gstreamer0.10-plugins)
GStreamer Multimedia Framework Bad Plugins (gst-plugins-bad)
local/gstreamer0.10-base 0.10.36-1
GStreamer Multimedia Framework Base plugin libraries
local/gstreamer0.10-base-plugins 0.10.36-1 (gstreamer0.10-plugins)
GStreamer Multimedia Framework Base Plugins (gst-plugins-base)
local/gstreamer0.10-ffmpeg 0.10.13-1 (gstreamer0.10-plugins)
Gstreamer FFMpeg Plugin
local/gstreamer0.10-good 0.10.31-3
GStreamer Multimedia Framework Good plugin libraries
local/gstreamer0.10-ugly 0.10.19-7
GStreamer Multimedia Framework Ugly plugin libraries
local/gstreamer0.10-ugly-plugins 0.10.19-7 (gstreamer0.10-plugins)
GStreamer Multimedia Framework Ugly Plugins (gst-plugins-ugly)
local/gstreamer0.10-vaapi 0.5.7-1
GStreamer Multimedia Framework VA Plugins
local/phonon-gstreamer 4.7.0-2
Phonon GStreamer backend
local/totem 3.10.1-1 (gnome)
GNOME3 movie player based on GStreamer
Version: 1.2.1
### Depends on
* [Bug 695606](https://bugzilla.gnome.org/show_bug.cgi?id=695606)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/66mpegtsmux: mux private data streams2023-07-11T10:30:28ZBugzilla Migration Usermpegtsmux: mux private data streams## Submitted by Martijn Grendelman
**[Link to original bug (#673582)](https://bugzilla.gnome.org/show_bug.cgi?id=673582)**
## Description
Mpegtsdemux is capable of demuxing private data streams, like subtitles and teletext, but mpeg...## Submitted by Martijn Grendelman
**[Link to original bug (#673582)](https://bugzilla.gnome.org/show_bug.cgi?id=673582)**
## Description
Mpegtsdemux is capable of demuxing private data streams, like subtitles and teletext, but mpegtsmux is not capable of muxing them. So, if you want to transcode a TS, but keep all non-audio/video streams as-is, this is not possible.
This is a request to add private data stream support to mpegtsmux.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/104h264parse: Only resends SPS/PPS periodically on IDR streams2023-07-06T11:01:45ZBugzilla Migration Userh264parse: Only resends SPS/PPS periodically on IDR streams## Submitted by lor..@..il.com
**[Link to original bug (#705030)](https://bugzilla.gnome.org/show_bug.cgi?id=705030)**
## Description
Created attachment 250309
GST_DEBUG=h264parse:6
I have the following pipeline:
gst-la...## Submitted by lor..@..il.com
**[Link to original bug (#705030)](https://bugzilla.gnome.org/show_bug.cgi?id=705030)**
## Description
Created attachment 250309
GST_DEBUG=h264parse:6
I have the following pipeline:
gst-launch-1.0 mpegtsmux name=mux ! tcpserversink host=192.168.1.103 port=5005 filesrc location=./netbeans/mpeg2.ts ! tsdemux name=demux demux. ! queue ! mpegvideoparse ! omxmpeg2videodec ! omxh264enc ! h264parse config-interval=1 ! mux. demux. ! queue ! mpegaudioparse ! mux.
Naturally, I expect that SPS/PPS packets are being sent each second so that when clients are connected they can start rendering video, unfortunately however this is not happening. I've attached a log of h264parse.
**Attachment 250309**, "GST_DEBUG=h264parse:6":
[h264parse.log](/uploads/76bce830db5f02113c560f745f279b1f/h264parse.log)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/172h264parse: weird parsing behavior after aspect ratio change2023-07-06T10:50:13ZBugzilla Migration Userh264parse: weird parsing behavior after aspect ratio change## Submitted by m][sko
**[Link to original bug (#735655)](https://bugzilla.gnome.org/show_bug.cgi?id=735655)**
## Description
observed in this bug report
https://bugzilla.gnome.org/show_bug.cgi?id=732533
I still have problem ...## Submitted by m][sko
**[Link to original bug (#735655)](https://bugzilla.gnome.org/show_bug.cgi?id=735655)**
## Description
observed in this bug report
https://bugzilla.gnome.org/show_bug.cgi?id=732533
I still have problem with this
http://pastebin.com/UDcxixUa
after aspect ratio change h264 parser generate many
gst_h264_parse_reset_frame
If I add
h264parse disable-passthrought=true all works fine
GST_DEBUG="*:3,aacparse:3,tsmux:0,mpegtsmux:4,omx*:1,omxvideoenc:1,omxh264enc:1,h264parse:5"
\
gst-launch-1.0 uridecodebin
uri="file:///home/pi/test13_aspect_ratio_change/test_ar_problem2.ts"
use-buffering=false name=demux caps="video/mpeg, parsed=true; audio/x-raw;
text/x-raw" \
! 'video/mpeg, parsed=true' \
! omxmpeg2videodec ! tee name="decdata"\
! omxh264enc target-bitrate=1000000 control-rate=1 periodicty-idr=50
interval-intraframes=50 inline-header=true ! 'video/x-h264, profile=high' \
! h264parse disable-passthrough=false\
! fakesink \
demux. ! 'audio/x-raw' \
! fakesink \
2>&1
http://pastebin.com/wPdRhezj
0:00:09.248553095 29707 0xb06cc780 INFO baseparse
gstbaseparse.c:3583:gst_base_parse_set_passthrough:`<h264parse0>` passthrough:
yes
and whole parsing process stoped
I don't think that this is expected behavior.
Version: 1.4.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/255mpeg4videoparse: Need detect picture coding type when drain2023-07-06T09:52:22ZBugzilla Migration Usermpeg4videoparse: Need detect picture coding type when drain## Submitted by kevin
**[Link to original bug (#749617)](https://bugzilla.gnome.org/show_bug.cgi?id=749617)**
## Description
our use case is demuxer only output key frame when backward playback. every frame is DISCONT and KEY frame....## Submitted by kevin
**[Link to original bug (#749617)](https://bugzilla.gnome.org/show_bug.cgi?id=749617)**
## Description
our use case is demuxer only output key frame when backward playback. every frame is DISCONT and KEY frame. mpeg4videoparse will detect coding type when detect start code after VOP. our use case will drain after VOP and can't detect start code after VOP. Add check coding type code when drain.https://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/246directsoundsrc: device-name doesn't accept windows given names if there are s...2023-06-23T12:18:46ZBugzilla Migration Userdirectsoundsrc: device-name doesn't accept windows given names if there are special characters in## Submitted by Thomas Roos
**[Link to original bug (#748681)](https://bugzilla.gnome.org/show_bug.cgi?id=748681)**
## Description
device-name doesn't accept windows given names if there are special characters in - eg. german "(High...## Submitted by Thomas Roos
**[Link to original bug (#748681)](https://bugzilla.gnome.org/show_bug.cgi?id=748681)**
## Description
device-name doesn't accept windows given names if there are special characters in - eg. german "(High Definition Audio-Gerät)". But works if you change the naming in windows registry, which is only possible for testing purposes. May an device-ID (GUID) based solution is needed!?
$ GST_DEBUG=3,directsoundsrc:5 gst-launch-1.0.exe directsoundsrc buffer-time=10000 device-name="mic (High Definition Audio-Gerät)" ! directsoundsink buffer-time=200000
0:00:00.043914339 3444 02D27260 WARN audioresample gstaudioresample.c:1537:plugin_init: Orc disabled, can't benchmark int vs. float resampler
0:00:00.048490103 3444 02D27260 WARN GST_PERFORMANCE gstaudioresample.c:1540:plugin_init: orc disabled, no benchmarking done
0:00:00.064831675 3444 02D27260 DEBUG directsoundsrc gstdirectsoundsrc.c:164:gst_directsound_src_class_init: initializing directsoundsrc class
0:00:00.139332696 3444 02D27260 DEBUG directsoundsrc gstdirectsoundsrc.c:259:gst_directsound_src_init:<GstDirectSoundSrc@00513220> initializing directsoundsrc
0:00:00.144179343 3444 02D27260 ERROR GST_PIPELINE grammar.y:453:gst_parse_element_set: could not set property "device-name" in element "directsoundsrc0" to "mic (High Definition Audio-Gerät)"
0:00:00.148407097 3444 02D27260 DEBUG directsoundsrc gstdirectsoundsrc.c:202:gst_directsound_src_getcaps:`<directsoundsrc0>` get caps
0:00:00.151341707 3444 02D27260 DEBUG directsoundsrc gstdirectsoundsrc.c:202:gst_directsound_src_getcaps:`<directsoundsrc0>` get caps
[Invalid UTF-8] WARNING: erroneous pipeline: could not set property "device-name" in element "directsoundsrc0" to "mic (High Definition Audio-Ger\xe4t)"https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/646hlsdemux: setup new stream if current variant stream becomes invalid and is r...2023-06-16T12:07:35ZBugzilla Migration Userhlsdemux: setup new stream if current variant stream becomes invalid and is removed from master playlist## Submitted by Jun Xie
**[Link to original bug (#792232)](https://bugzilla.gnome.org/show_bug.cgi?id=792232)**
## Description
During updating manifest, current variant stream is checked for validity.
If it becomes invalid, master...## Submitted by Jun Xie
**[Link to original bug (#792232)](https://bugzilla.gnome.org/show_bug.cgi?id=792232)**
## Description
During updating manifest, current variant stream is checked for validity.
If it becomes invalid, master playlist is updated and old variant streams are compared new variant stream.
Currently, only a warning log is shown.
>hlsdemux gsthlsdemux.c:1288:gst_hls_demux_update_variant_playlist:[00m Unable to match current playlist
I think we need to :
1) reset current variant,
2) setup new stream.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/505Add vpx (de)muxing capabilities to mpegtsmux and mpegtsdemux2023-06-16T11:27:21ZBugzilla Migration UserAdd vpx (de)muxing capabilities to mpegtsmux and mpegtsdemux## Submitted by Yann Jouanin
**[Link to original bug (#776948)](https://bugzilla.gnome.org/show_bug.cgi?id=776948)**
## Description
Created attachment 343024
Patch to add vpx support to both mpegtsmux and mpegtsdemux
It is cu...## Submitted by Yann Jouanin
**[Link to original bug (#776948)](https://bugzilla.gnome.org/show_bug.cgi?id=776948)**
## Description
Created attachment 343024
Patch to add vpx support to both mpegtsmux and mpegtsdemux
It is currently impossible to stream vpx codec with MPEG-TS muxer (demuxer).
This patch add this functionnality by creating a new stream type (private 0xe0) and a descriptor.
tested with vp8 and vp9
**Patch 343024**, "Patch to add vpx support to both mpegtsmux and mpegtsdemux":
[0001-mpegtsmux-add-support-for-vpx-streams.patch](/uploads/4fe0e0113d4a773d1c1709e02a342f76/0001-mpegtsmux-add-support-for-vpx-streams.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/588mpegtemux/demux: support "interlaced" JPEG 2000 stream2023-06-16T11:22:45ZBugzilla Migration Usermpegtemux/demux: support "interlaced" JPEG 2000 stream## Submitted by Aaron Boxer
**[Link to original bug (#785225)](https://bugzilla.gnome.org/show_bug.cgi?id=785225)**
## Description
According to spec, interlaced mode specifies two J2K code streams placed in a single PES packet.
...## Submitted by Aaron Boxer
**[Link to original bug (#785225)](https://bugzilla.gnome.org/show_bug.cgi?id=785225)**
## Description
According to spec, interlaced mode specifies two J2K code streams placed in a single PES packet.
See https://bugzilla.gnome.org/show_bug.cgi?id=753323 for more details.
We should support muxing an interlaced signal into this format, rather than treating it as progressive as we currently do.
Also demuxing a stream in this format.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/723msdk: 2 cases vp9 decoding fail with error message "matroskademux0: Internal ...2023-06-15T16:33:38ZBugzilla Migration Usermsdk: 2 cases vp9 decoding fail with error message "matroskademux0: Internal data stream error"## Submitted by zj,wang
**[Link to original bug (#796462)](https://bugzilla.gnome.org/show_bug.cgi?id=796462)**
## Description
Description zj,wang 2018-05-18 08:43:35 UTC
Test Env:
============================================
...## Submitted by zj,wang
**[Link to original bug (#796462)](https://bugzilla.gnome.org/show_bug.cgi?id=796462)**
## Description
Description zj,wang 2018-05-18 08:43:35 UTC
Test Env:
============================================
Platform: APL/KBL
Arch: x86_64
Linux release 16.04
Kernel: 4.12.0-rc2
libva https://github.com/01org/libva.gitb
commit 3be72a5a110880f70626d7c3bed953cdde124b2
media_driver https://github.com/intel/media-driver
commit 1c2b0615d749c45c07f9aee6586774816989c5b3
MediaSDK: https://github.com/Intel-Media-SDK/MediaSDK
commit 7c2b069dce7bed268806f680412a2f3b09a52ce9
gst-bad master branch 0bdcf51baf77926b4f29c01a2fdf133c13aad62e
Reproduce Steps:
============================================
take one case for example
1. build enc as above lists
2. gst-launch-1.0 -f -q filesrc location=/media/VP9Conf700/g2_decoder_case_14096.webm '!' matroskademux '!' msdkvp9dec '!' videoconvert '!' video/x-raw,format=I420 '!' checksumsink2 frame-checksum=FALSE file-checksum=TRUE plane-checksum=FALSE dump-location=./dump.yuv
3. error message as below
ERROR: from element /GstPipeline:pipeline0/GstMatroskaDemux:matroskademux0: Internal data stream error.
Additional debug info:
matroska-demux.c(5072): gst_matroska_demux_loop (): /GstPipeline:pipeline0/GstMatroskaDemux:matroskademux0:
streaming stopped, reason not-linked (-1)
ERROR: pipeline doesn't want to preroll.
Failed cases
g2_decoder_case_14096.webm
g2_decoder_case_14104.webm
### Blocking
* [Bug 789886](https://bugzilla.gnome.org/show_bug.cgi?id=789886)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/86bayer: Caps for 16-bit Bayer2023-06-15T13:02:29ZBugzilla Migration Userbayer: Caps for 16-bit Bayer## Submitted by Joshua M. Doe
**[Link to original bug (#693666)](https://bugzilla.gnome.org/show_bug.cgi?id=693666)**
## Description
Currently in both 0.10 and 1.0 the caps for Bayer are limited to 8-bits, however 16-bit is quite co...## Submitted by Joshua M. Doe
**[Link to original bug (#693666)](https://bugzilla.gnome.org/show_bug.cgi?id=693666)**
## Description
Currently in both 0.10 and 1.0 the caps for Bayer are limited to 8-bits, however 16-bit is quite common, and I've seen 12-bit as well. I have seen three different ways to extend this to at least 16-bit:
1) I have used video/x-raw-bayer,format=(string){gbrg16, bggr16, grbg16, rggb16} so as to not conflict with the current expectation of 8-bit data from bayer2rgb and rgb2bayer. Alternatively, something like video/x-raw-bayer16 could work as well, if not an elegant solution.
2) gst-plugins-elphel has a "bpp" property in their bayer2rgb2 element which when true assumes the data to be 16-bit, otherwise 8-bit:
http://code.google.com/p/gst-plugins-elphel/source/browse/trunk/bayer2rgb2/src/gstbayer2rgb2.c#267
3) Aravis simply adds bpp and depth to the video/x-raw-bayer caps:
http://git.gnome.org/browse/aravis/tree/src/arvmisc.c#n635
`
#2` is clearly not a good solution since it moves the bpp out of the caps.` #3` is the most robust solution, though it would mean some applications would break, though if supporting elements always prioritize bpp=8,depth=8, then breakage would be minimal I believe. If changing the existing caps are unacceptable, then we'd have to go with` #1`.1.23.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/48mpeg2enc/x264enc: fails to encode 720x405 resolution2023-06-07T11:13:06ZBugzilla Migration Usermpeg2enc/x264enc: fails to encode 720x405 resolution## Submitted by Jeff Fortin Tam `@nekohayo`
**[Link to original bug (#659965)](https://bugzilla.gnome.org/show_bug.cgi?id=659965)**
## Description
+++ This bug was initially created as a clone of [Bug 658303](https://bugzilla.gnome....## Submitted by Jeff Fortin Tam `@nekohayo`
**[Link to original bug (#659965)](https://bugzilla.gnome.org/show_bug.cgi?id=659965)**
## Description
+++ This bug was initially created as a clone of [Bug 658303](https://bugzilla.gnome.org/show_bug.cgi?id=658303) +++
Steps to reproduce:
0. Insert the theora clip I'm linking here in the timeline
1. Click the render button to render a project
2. Click the "DVD" render preset
3. Try to render
Result: **ERROR: [python] vertical_size must be a even (4:2:0)