GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2024-01-19T14:20:24Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2592avdec: Bogus green line at bottom when decoding into I420 using xvimagesink2024-01-19T14:20:24ZBugzilla Migration Useravdec: Bogus green line at bottom when decoding into I420 using xvimagesink## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#732351)](https://bugzilla.gnome.org/show_bug.cgi?id=732351)**
## Description
When playing a video file, sometimes the bottom line of the video shows bogu...## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#732351)](https://bugzilla.gnome.org/show_bug.cgi?id=732351)**
## Description
When playing a video file, sometimes the bottom line of the video shows bogus data. It depends on the resolution being used and it only happens with xvimagesink.
To reproduce:
1) Create a 16x16 h264 file:
gst-launch-1.0 videotestsrc pattern=white num-buffers=1000 ! \
"video/x-raw, format=(string)I420, width=(int)16, height=(int)16, \
framerate=(fraction)1/1" ! x264enc ! qtmux ! filesink location=/tmp/test.mov
2) Play this file:
gst-launch-1.0 playbin uri="file:///tmp/test.ogg" video-sink=xvimagesink
3) Check the bottom line (This scenario also shows the right column with bogus data
Details I found out so far about this:
If I manually disable direct rendering in libav gstviddec it doesn't happen.
It doesn't happen with 480x320 resolution (and some others).
I'm marking this as being in gst-libav for now but I'm not sure, could be in libav itself and I also saw it happening with theoradec but with different resolutions.
### Blocking
* [Bug 732631](https://bugzilla.gnome.org/show_bug.cgi?id=732631)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2586vtenc: "Output state was not configured"2023-07-21T16:58:33ZBugzilla Migration Uservtenc: "Output state was not configured"## Submitted by Ilya Konstantinov
**[Link to original bug (#747546)](https://bugzilla.gnome.org/show_bug.cgi?id=747546)**
## Description
gst_vtenc_finish might be called before gst_vtenc_encode_frame ever manages to encode a single ...## Submitted by Ilya Konstantinov
**[Link to original bug (#747546)](https://bugzilla.gnome.org/show_bug.cgi?id=747546)**
## Description
gst_vtenc_finish might be called before gst_vtenc_encode_frame ever manages to encode a single frame, i.e.
```
i = 0;
while (g_async_queue_length (self->cur_outframes) > 0) {
GstVideoCodecFrame *outframe = g_async_queue_try_pop (self->cur_outframes);
/* Try to renegotiate once */
if (i == 0) {
meta = gst_buffer_get_core_media_meta (outframe->output_buffer);
if (!gst_vtenc_negotiate_downstream (self, meta->sample_buf)) {
`^``^` this code might never run before gst_vtenc_finish
```
In such case, VT's queue will be flushed and gst_video_encoder_finish_frame will be called for every frame, but negotiation will never happen, and therefore:
`ERROR videoencoder gstvideoencoder.c:2033:GstFlowReturn gst_video_encoder_finish_frame(GstVideoEncoder *, GstVideoCodecFrame *):<vtenc_h264-0> Output state was not configured`Piotr BrzezińskiPiotr Brzezińskihttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2579avdec: better multi-threaded decoding performance for live pipelines where do...2023-05-18T11:34:29ZBugzilla Migration Useravdec: better multi-threaded decoding performance for live pipelines where downstream does not sync to clock## Submitted by Tim Müller `@tpm`
**[Link to original bug (#696501)](https://bugzilla.gnome.org/show_bug.cgi?id=696501)**
## Description
Currently we always use FF_THREAD_SLICE mode for multithreaded H.264 decoding.
This mode r...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#696501)](https://bugzilla.gnome.org/show_bug.cgi?id=696501)**
## Description
Currently we always use FF_THREAD_SLICE mode for multithreaded H.264 decoding.
This mode requires encoder support, so multiple threads will only be used if the H.264 video is encoded in a suitable way (i.e. with multiple slices per frame). This is not necessarily the case, and where this is not the case decoding will be done in a single thread only, hampering performance.
We should use FF_THREAD_SLICE only for live pipelines where latency is important, and use FF_THREAD_FRAME for decoding scenarios where latency does not matter, to make sure we actually use multiple threads for decoding if possible.
### See also
* https://bugs.freedesktop.org/show_bug.cgi?id=56206https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2509rtpjitterbuffer/h264parse timestamp issue (regression)2023-04-20T11:16:15ZBugzilla Migration Userrtpjitterbuffer/h264parse timestamp issue (regression)## Submitted by Nicola `@drakkan`
**[Link to original bug (#788777)](https://bugzilla.gnome.org/show_bug.cgi?id=788777)**
## Description
Created attachment 361248
logs that show the issue
In a pipeline like this:
rtspsrc...## Submitted by Nicola `@drakkan`
**[Link to original bug (#788777)](https://bugzilla.gnome.org/show_bug.cgi?id=788777)**
## Description
Created attachment 361248
logs that show the issue
In a pipeline like this:
rtspsrc ! rtph264depay ! h264parse ! ...
using rtsp over tcp can happen that rtspsrc outputs buffers with the same timestamp, when this happen h264parse outputs buffer with invalid timestamps.
Please take a look at the attached logs, you can see:
rtpjitterbuffer.c:916:rtp_jitter_buffer_calculate_pts:[00m backwards timestamps, using previous time
so different buffers with pts 0:15:23.020362975 are sended.
Not sure how to handle this case, we need to change rtpjitterbuffer or h264parse?
This problem seems to happen only using rtsp over tcp, I'm unable to reproduce it using rtsp over udp.
**Attachment 361248**, "logs that show the issue":
[log.txt](/uploads/beac41b97709f74dfb724f589e3b11e4/log.txt)
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1645Opus: playback gain always relative to EBU R128 level (-23db LUFS), must be p...2023-01-04T00:28:23ZBugzilla Migration UserOpus: playback gain always relative to EBU R128 level (-23db LUFS), must be played 5db louder to match ReplayGain level (-18db LUFS) when using ReplayGain## Submitted by Nikolaus Waxweiler `@madig`
**[Link to original bug (#753275)](https://bugzilla.gnome.org/show_bug.cgi?id=753275)**
## Description
(not sure if this is the correct place to ask for this)
I use Clementine (GStrea...## Submitted by Nikolaus Waxweiler `@madig`
**[Link to original bug (#753275)](https://bugzilla.gnome.org/show_bug.cgi?id=753275)**
## Description
(not sure if this is the correct place to ask for this)
I use Clementine (GStreamer-based) and ReplayGain all my music. I noticed that while playing around with the new Opus format, those files are played much quieter than music in other formats. After digging around, I found: Opus files are by design always normalized to -23db LUFS (R128), while ReplayGain defaults to -18db LUFS. Foobar2000 seems to simply preamp these files +5db when playing. Could GStreamer do the same? Or maybe take an argument of what reference level to use so players can set and forget it?
(Maybe related: [Bug 751534](https://bugzilla.gnome.org/show_bug.cgi?id=751534))https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1175textoverlay: add background-color property2022-04-23T08:36:33ZBugzilla Migration Usertextoverlay: add background-color property## Submitted by Philippe Normand `@philn`
**[Link to original bug (#795850)](https://bugzilla.gnome.org/show_bug.cgi?id=795850)**
## Description
.## Submitted by Philippe Normand `@philn`
**[Link to original bug (#795850)](https://bugzilla.gnome.org/show_bug.cgi?id=795850)**
## Description
.Philippe NormandPhilippe Normandhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1125mpegtsmux, high overhead for a small aac bitrate2022-11-10T09:21:12ZBugzilla Migration Usermpegtsmux, high overhead for a small aac bitrate## Submitted by Vincent Génieux
**[Link to original bug (#766618)](https://bugzilla.gnome.org/show_bug.cgi?id=766618)**
## Description
I am facing an issue with the following pipeline :
audiotestsrc num-buffers=100000 ! audio/x...## Submitted by Vincent Génieux
**[Link to original bug (#766618)](https://bugzilla.gnome.org/show_bug.cgi?id=766618)**
## Description
I am facing an issue with the following pipeline :
audiotestsrc num-buffers=100000 ! audio/x-raw,channels=2 ! voaacenc
bitrate=32000 ! mpegtsmux ! filesink location=test.ts
The tsdemux generate a stream with a huge bitrate compared to other
containers, such as mp4mux :
audiotestsrc num-buffers=100000 ! audio/x-raw,channels=2 ! voaacenc
bitrate=32000 ! mp4mux ! filesink location=test.mp4
$ ls -lh test.*
-rw-r--r-- 1 vincent vincent 9.6M May 18 10:56 test.mp4
-rw-r--r-- 1 vincent vincent 26M May 18 10:57 test.ts
I think there is a misconfiguration somewhere which leads the demux to
create very small chunk with many headers. I also noticed we can reduce
the size of the ts file with libav :
$ avconv -i test.ts -codec copy test2.ts
$ ls -lh *.ts
-rw-r--r-- 1 vincent vincent 26M May 18 10:57 test.ts
-rw-r--r-- 1 vincent vincent 9.8M May 18 11:03 test2.ts
The problem is most likely that we don't combine multiple AAC packets
into a single PES packet, and thus have a lot of overhead for each of
them. ffmpeg does this for audio at least if I remember the muxer code
correctly.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1056v4l2object: non-default colorimetry broken for v4l2h264enc2022-11-17T22:49:34ZBugzilla Migration Userv4l2object: non-default colorimetry broken for v4l2h264enc## Submitted by Philipp Zabel `@pH5`
**[Link to original bug (#791471)](https://bugzilla.gnome.org/show_bug.cgi?id=791471)**
## Description
Created attachment 365355
v4l2object: Validate colorimetry in S_FMT only if skip_try_fmt_p...## Submitted by Philipp Zabel `@pH5`
**[Link to original bug (#791471)](https://bugzilla.gnome.org/show_bug.cgi?id=791471)**
## Description
Created attachment 365355
v4l2object: Validate colorimetry in S_FMT only if skip_try_fmt_probes is set
Since commit gst-plugins-good@558e9f4e574d8e1268d2d8d8fbccb1f13ecc391f ("v4l2object: Validate colorimetry in S/TRY_FMT"), trying to set a supported but non-default colorimetry on the sink pad of a v4l2h264enc element fails with an error message:
ERROR: from element /GstPipeline:pipeline0/v4l2h264enc:v4l2h264enc0:
Device '/dev/video14' does not support bt601 colorimetry
This currently causes a pipeline like:
videotestsrc ! v4l2h264enc ! fakesink
to fail when using the coda v4l2 driver, because bt601 is negotiated whereas the output queue defaults to bt709.
(probed caps: colorimetry=(string){ bt709, bt601, smpte240m, ... })
The same happens when forcing any non-default colorimetry:
videotestsrc ! video/x-raw,colorimetry=smpte240m ! v4l2h264enc ! fakesink
**Patch 365355**, "v4l2object: Validate colorimetry in S_FMT only if skip_try_fmt_probes is set":
[0001-v4l2object-Validate-colorimetry-in-S_FMT-only-if-ski.patch](/uploads/67bdfb3848b2d31e2032295a1fb2443c/0001-v4l2object-Validate-colorimetry-in-S_FMT-only-if-ski.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/836dashdemux: doesn't play facebook live streams2021-10-20T09:50:41ZBugzilla Migration Userdashdemux: doesn't play facebook live streams## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#791207)](https://bugzilla.gnome.org/show_bug.cgi?id=791207)**
## Description
I'm trying to play MPEG-DASH streams from facebook live
1. go to https://www.faceboo...## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#791207)](https://bugzilla.gnome.org/show_bug.cgi?id=791207)**
## Description
I'm trying to play MPEG-DASH streams from facebook live
1. go to https://www.facebook.com/live/ and select a random stream
2. view the stream, right-click, display stream uri
3. copy that stream uri and run it though youtube-dl -g $uri
4. you get the actual MPEG DASH manifest uri which can be fed into gst-play
e.g. gst-play-1.0 "https://video.ftxl1-1.fna.fbcdn.net/hvideo-ash5/v/rMTvKZnCY3MLMygC0gCTG/live-dash/dash-abr1/761610404036944.mpd?_nc_rl=AfAdnDdKb8wmBUW6&oh=5199f0f8ddb5624c41c42a93727af578&oe=5A27CF0B" -v
result is just a tiny thumbnail which doesn't move
with gst-launch-1.0 uridecodebin uri="..." ! autovideosink sync=false at least there is a little bit of motion but the stream is also full of defects
... ! autoaudiosink sync=false will usually sound fine though
when looking at the timestamps falling out of the dashdemux with
gst-launch-1.0 souphttpsrc location="https://video.ftxl1-1.fna.fbcdn.net/hvideo-atn2/v/r9sFsHpnUNM2jJZUix-M2/live-dash/dash-abr4/2081836301833050.mpd?_nc_rl=AfDWx0uVBpW-bxwm&oh=77a92c9031f065a1e801f47bfdcadaa6&oe=5A278CA6" ! dashdemux ! fakesink silent=false -v
...
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (664 bytes, dts: none, pts: 1:00:50.381000000, duration: none, offset: 0, offset_end: 664, flags: 00000040 discont , meta: none) 0x7f0cf801c620
it seems that the timestamps start way in the future which prevents the playback
Version: 1.12.3https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/835dashdemux: do not parse mpd file and setup streams if updated mpd file is not...2021-10-20T08:35:05ZBugzilla Migration Userdashdemux: do not parse mpd file and setup streams if updated mpd file is not changed at all## Submitted by Jun Xie
**[Link to original bug (#792263)](https://bugzilla.gnome.org/show_bug.cgi?id=792263)**
## Description
if updated mpd file is the same with last one, not changed at all, then no bother to parse mpd file and s...## Submitted by Jun Xie
**[Link to original bug (#792263)](https://bugzilla.gnome.org/show_bug.cgi?id=792263)**
## Description
if updated mpd file is the same with last one, not changed at all, then no bother to parse mpd file and setup streams.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/834dashdemux: use MPD.Location element for manifest URL if present2021-10-20T08:24:08ZBugzilla Migration Userdashdemux: use MPD.Location element for manifest URL if present## Submitted by A Ashley
**[Link to original bug (#783590)](https://bugzilla.gnome.org/show_bug.cgi?id=783590)**
## Description
The DVB DASH specification section 10.11 states:
Players shall use the MPD.Location element...## Submitted by A Ashley
**[Link to original bug (#783590)](https://bugzilla.gnome.org/show_bug.cgi?id=783590)**
## Description
The DVB DASH specification section 10.11 states:
Players shall use the MPD.Location element URL for all MPD
updates and not the URL used to initially retrieve the MPD.
This bug ticket is to request addition of code in dashdemux check if any Location elements are present in the manifest and use one of these to set the URL that is used for the next manifest refresh.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/833dashdemux: try all URLs in a UTCtiming element2021-10-20T08:21:53ZBugzilla Migration Userdashdemux: try all URLs in a UTCtiming element## Submitted by A Ashley
**[Link to original bug (#762739)](https://bugzilla.gnome.org/show_bug.cgi?id=762739)**
## Description
The UTCTiming element in a DASH manifest identifies a time synchronisation method and one or more URLs t...## Submitted by A Ashley
**[Link to original bug (#762739)](https://bugzilla.gnome.org/show_bug.cgi?id=762739)**
## Description
The UTCTiming element in a DASH manifest identifies a time synchronisation method and one or more URLs that can be contacted using the specified method.
Currently the gst_dash_demux_poll_clock_drift() function selects one server to poll and if that fails, it will wait 30 seconds before trying another server. If this error occurs when starting playback, dashdemux will start playback without achieving clock drift compensation, which can cause it to select the wrong starting segment. Selecting the wrong starting segment can cause requests for segments to fail with HTTP404 errors, as the chosen segment might have already been deleted from the origin or might not yet exist.
Also, when a manifest update occurs, gst_dash_demux_poll_clock_drift() does not check that the currently active URL is still valid.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/832dashdemux: Support cookies for DASH2021-10-20T08:19:07ZBugzilla Migration Userdashdemux: Support cookies for DASH## Submitted by Park Jun-soo
**[Link to original bug (#775920)](https://bugzilla.gnome.org/show_bug.cgi?id=775920)**
## Description
According to caluse 9.5 Stored Data Security of Freeview_Play_Technical_Specification, DASH Player s...## Submitted by Park Jun-soo
**[Link to original bug (#775920)](https://bugzilla.gnome.org/show_bug.cgi?id=775920)**
## Description
According to caluse 9.5 Stored Data Security of Freeview_Play_Technical_Specification, DASH Player shall support session cookie.
### Depends on
* [Bug 761099](https://bugzilla.gnome.org/show_bug.cgi?id=761099)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/831dashdemux: forward availabilityStartTime to application2022-11-10T09:21:09ZBugzilla Migration Userdashdemux: forward availabilityStartTime to application## Submitted by Julien Isorce `@cap`
**[Link to original bug (#758952)](https://bugzilla.gnome.org/show_bug.cgi?id=758952)**
## Description
The application needs a way to retrieve the "availabilityStartTime" field in mpd.
Indee...## Submitted by Julien Isorce `@cap`
**[Link to original bug (#758952)](https://bugzilla.gnome.org/show_bug.cgi?id=758952)**
## Description
The application needs a way to retrieve the "availabilityStartTime" field in mpd.
Indeed getStartDate method of HTML5 video tag shall return MPD@availabilityStartTime plus the PeriodStart time.
PeriodStart seems to be gst_adaptive_demux_get_period_start_time which should match start attribute in mpd, example: <Period .. start="PT0.00S">
One possible solution is to post a gst message. Should I add a new entry to GST_ADAPTIVE_DEMUX_STATISTICS_MESSAGE_NAME message: "start-date" ? Or a new message specific to dash where we can add as much as mpd's nodes/attributes that we need ?
(Currently with latest WebKit getStartDate always returns NaN since it is default implementation)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/830dashdemux: replace sscanf with strtoul2022-11-10T09:21:09ZBugzilla Migration Userdashdemux: replace sscanf with strtoul## Submitted by Florin Apostol
**[Link to original bug (#752428)](https://bugzilla.gnome.org/show_bug.cgi?id=752428)**
## Description
gstmpdparser.c file uses sscanf(..., "%u", ...) to read numbers from the xml file. sscanf is unabl...## Submitted by Florin Apostol
**[Link to original bug (#752428)](https://bugzilla.gnome.org/show_bug.cgi?id=752428)**
## Description
gstmpdparser.c file uses sscanf(..., "%u", ...) to read numbers from the xml file. sscanf is unable to indicate the fact that the input string was completely parsed or not. For example, for the input "123xyz" the sscanf function will return 1 (it successfully read an integer).
A better function is strtol (and strtoul, etc). This has the ability to provide a pointer to the next unparsed character in string. Using this, we can detect if the original string was valid or not.
The question is how restrictive the parser should be? Where a number is expected in an xml attribute and a "123xyz" is provided, should the parser read and use 123 or it should signal an error? Currently it reads just 123 and no error or warnings are issued (provided it does not need to parse the attribute further than the number).
So, should we make the parser more restrictive or not?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/829dashdemux: RepresentationIndex is not used2021-10-20T08:07:50ZBugzilla Migration Userdashdemux: RepresentationIndex is not used## Submitted by Florin Apostol
**[Link to original bug (#752727)](https://bugzilla.gnome.org/show_bug.cgi?id=752727)**
## Description
RepresentationIndex element from SegmentBase is designed to identify a single Segment Index for th...## Submitted by Florin Apostol
**[Link to original bug (#752727)](https://bugzilla.gnome.org/show_bug.cgi?id=752727)**
## Description
RepresentationIndex element from SegmentBase is designed to identify a single Segment Index for the entire representation. But RepresentationIndex is only parsed and not used.
gstadaptivedemux makes an attempt to download a single Segment Index for an entire representation in the gst_adaptive_demux_stream_download_header_fragment function. But the indexUrl and range are not obtained from RepresentationIndex. Instead, they are wrongly obtained from Initilization@SegmentBase and indexRange@SegmentBase.
See also https://bugzilla.gnome.org/show_bug.cgi?id=752718https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/828dashdemux: only one SegmentList element is supported2022-11-10T09:21:09ZBugzilla Migration Userdashdemux: only one SegmentList element is supported## Submitted by Florin Apostol
**[Link to original bug (#752229)](https://bugzilla.gnome.org/show_bug.cgi?id=752229)**
## Description
The standard specifies that "The Segment list is defined by one or more SegmentList elements".
...## Submitted by Florin Apostol
**[Link to original bug (#752229)](https://bugzilla.gnome.org/show_bug.cgi?id=752229)**
## Description
The standard specifies that "The Segment list is defined by one or more SegmentList elements".
But the implementation supports only 1 element. The SegmentList member of _GstRepresentationNode, _GstAdaptationSetNode, _GstPeriodNode is a pointer to GstSegmentListNode, instead of a list. So, these elements support only 1 instance of SegmentList element. When a second one is detected, the gst_mpdparser_parse_segment_list_node function will free the previous one:
gst_mpdparser_parse_segment_list_node (GstSegmentListNode ** pointer,
....
gst_mpdparser_free_segment_list_node (*pointer);
*pointer = new_segment_list = g_slice_new0 (GstSegmentListNode);https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/827[PLUGIN-MOVE] Move hlsdemux/dashdemux/mssdemux to gst-plugins-good2022-04-05T12:51:26ZBugzilla Migration User[PLUGIN-MOVE] Move hlsdemux/dashdemux/mssdemux to gst-plugins-good## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#672261)](https://bugzilla.gnome.org/show_bug.cgi?id=672261)**
## Description
We should probably move hlsdemux to -good at some time.
On IRC it has been sa...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#672261)](https://bugzilla.gnome.org/show_bug.cgi?id=672261)**
## Description
We should probably move hlsdemux to -good at some time.
On IRC it has been said that we should wait for` #657790` to be closed, and we might want to rename it from hls to something more generic (fragmented is the name of the plugin itself, just the folder is called hls). Ideally adding another fragmented streaming protocol with the help of the new base class.
Also there is no test suite yet but there is some work going on there.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/824add support for DASH events2021-10-20T07:34:15ZBugzilla Migration Useradd support for DASH events## Submitted by A Ashley
**[Link to original bug (#796923)](https://bugzilla.gnome.org/show_bug.cgi?id=796923)**
## Description
Section 5.10.3 (Inband Event Signalling) of the MPEG DASH specification defines a new box type "emsg" th...## Submitted by A Ashley
**[Link to original bug (#796923)](https://bugzilla.gnome.org/show_bug.cgi?id=796923)**
## Description
Section 5.10.3 (Inband Event Signalling) of the MPEG DASH specification defines a new box type "emsg" that is used to convey events. These events can be used to signal changes in the DASH stream, convey metadata or provide application specific information.
Section 5.10.4 (DASH-specific events) defines a method for an in-band signal to indicate that a live DASH stream has finished.
Currently there is no support in qtdemux or dashdemux for these DASH events.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/821dash: mpdparser: GstUri changed unexpectedly within combine_urls()2022-11-15T00:45:56ZBugzilla Migration Userdash: mpdparser: GstUri changed unexpectedly within combine_urls()## Submitted by WeiChungChang
**[Link to original bug (#765528)](https://bugzilla.gnome.org/show_bug.cgi?id=765528)**
## Description
Created attachment 326680
issued MPD file
Hi all:
I met a problem when combine_urls() ...## Submitted by WeiChungChang
**[Link to original bug (#765528)](https://bugzilla.gnome.org/show_bug.cgi?id=765528)**
## Description
Created attachment 326680
issued MPD file
Hi all:
I met a problem when combine_urls() is executed the result URL is broken.
Such as:
expected result =
"https://r8---sn-ipoxu-u2xl.googlevideo.com/videoplayback?id=cf12500690581ecb&itag=133&source=youtube&requiressl=yes&ms=au&pl=16&mm=31&mv=m&mn=sn-ipoxu-u2xl&initcwndbps=1245000&ratebypass=yes&mime=video/mp4&gir=yes&clen=3617089&lmt=1439380361025617&dur=121.746&signature=8C0600A08A8FA47C3734F42B4721E2143EACDF94.705D52170E63A2E70291789D67FAC9C139B12965&mt=1461557621&upn=hP1NJs1_Lng&sver=3&fexp=3300118,3300134,3300161,3312381,9410705,9416126,9416891,9422596,9426927,9427482,9428398,9431012,9431364,9431865,9432033,9432132,9432684,9432839,9433096,9433193,9433425,9433947,9433997&key=dg_yt0&ip=42.73.160.27&ipbits=0&expire=1461579370&sparams=ip,ipbits,expire,id,itag,source,requiressl,ms,pl,mm,mv,mn,initcwndbps,ratebypass,mime,gir,clen,lmt,dur <https://r8---sn-ipoxu-u2xl.googlevideo.com/videoplayback?id=cf12500690581ecb&itag=133&source=youtube&requiressl=yes&ms=au&pl=16&mm=31&mv=m&mn=sn-ipoxu-u2xl&initcwndbps=1245000&ratebypass=yes&mime=video/mp4&gir=yes&clen=3617089&lmt=1439380361025617&dur=121.746&signature=8C0600A08A8FA47C3734F42B4721E2143EACDF94.705D52170E63A2E70291789D67FAC9C139B12965&mt=1461557621&upn=hP1NJs1_Lng&sver=3&fexp=3300118%2c3300134%2c3300161%2c3312381%2c9410705%2c9416126%2c9416891%2c9422596%2c9426927%2c9427482%2c9428398%2c9431012%2c9431364%2c9431865%2c9432033%2c9432132%2c9432684%2c9432839%2c9433096%2c9433193%2c9433425%2c9433947%2c9433997&key=dg_yt0&ip=42.73.160.27&ipbits=0&expire=1461579370&sparams=ip%2cipbits%2cexpire%2cid%2citag%2csource%2crequiressl%2cms%2cpl%2cmm%2cmv%2cmn%2cinitcwndbps%2cratebypass%2cmime%2cgir%2cclen%2clmt%2cdur>
"
broken result = "https://r8---sn-ipoxu-u2xl.googlevideo.com/videoplayback
"
static GstUri *
combine_urls (GstUri * base, GList * list, gchar ** query,
GstActiveStream * stream)
{
GstUri *ret = base;
...
/*here the ret is still sound*/
gst_uri_set_query_table (ret, NULL);
/*here the ret is broken...*/
}
The attached is the DASH MPD where this issue happened.
Could someone help on checking it?
Thanks.
**Attachment 326680**, "issued MPD file":
[1245000.mpd](/uploads/11a99708c1f0508a96ef0c9c5aeb03c9/1245000.mpd)