GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2023-07-02T16:33:48Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/263flvdemux: Expose pads as early as possible and use GstStreams API2023-07-02T16:33:48ZBugzilla Migration Userflvdemux: Expose pads as early as possible and use GstStreams API## Submitted by Yann Jouanin
**[Link to original bug (#764260)](https://bugzilla.gnome.org/show_bug.cgi?id=764260)**
## Description
Created attachment 324837
Patch to add no-more-pads-threshold property
Currently when first v...## Submitted by Yann Jouanin
**[Link to original bug (#764260)](https://bugzilla.gnome.org/show_bug.cgi?id=764260)**
## Description
Created attachment 324837
Patch to add no-more-pads-threshold property
Currently when first video packet is more than 6 seconds delayed from first audio packet (or vice versa), the filter sends a no-more-pads events.
Because I encountered some case where this delay is not enough to read the stream (long GOP, still image), I wrote a patch to switch from a constant to a property
add no-more-pads-threshold property , default is set to 6 (like the previous constant)
**Patch 324837**, "Patch to add no-more-pads-threshold property":
[gstflvdemux_no-more-pads.patch](/uploads/abc6261a75321cf886de50a1853a55be/gstflvdemux_no-more-pads.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/260rtspsrc: Add special support for ONVIF servers (custom headers, timestamp ext...2022-05-06T08:48:51ZBugzilla Migration Userrtspsrc: Add special support for ONVIF servers (custom headers, timestamp extraction, ...)## Submitted by Nicola `@drakkan`
**[Link to original bug (#762910)](https://bugzilla.gnome.org/show_bug.cgi?id=762910)**
## Description
Created attachment 322727
extract and apply onvif timestamp
extract absolute timestamp f...## Submitted by Nicola `@drakkan`
**[Link to original bug (#762910)](https://bugzilla.gnome.org/show_bug.cgi?id=762910)**
## Description
Created attachment 322727
extract and apply onvif timestamp
extract absolute timestamp from onvif rtp extension and apply to rtp buffers,
onvif ntp timestamp are converted to unix timestamp, the output is something like this
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (4434 bytes, dts: 404561:47:11.657000000, pts: 404561:47:11.657000000, duration: none, offset: -1, offset_end: -1, flags: 00004000 tag-memory ) 0x7fa7ac0132d0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (4454 bytes, dts: 404561:47:11.993000000, pts: 404561:47:11.993000000, duration: none, offset: -1, offset_end: -1, flags: 00004000 tag-memory ) 0x7fa7ac0134f0
**Patch 322727**, "extract and apply onvif timestamp":
[0001-onvifparse-extract-and-apply-onvif-timestamp.patch](/uploads/f8d11767a2a5f073a99375f3081ed48b/0001-onvifparse-extract-and-apply-onvif-timestamp.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/256rtpbin/rtxsend: Add unicast re-transmit support and support for session broad...2020-01-12T01:21:17ZBugzilla Migration Userrtpbin/rtxsend: Add unicast re-transmit support and support for session broadcasting using a multiudpsink## Submitted by GstBlub
**[Link to original bug (#761960)](https://bugzilla.gnome.org/show_bug.cgi?id=761960)**
## Description
rtpbin: Add rtcp-send-eos property.
This allows rtpbin to be used with a multiudpsink to broadcast t...## Submitted by GstBlub
**[Link to original bug (#761960)](https://bugzilla.gnome.org/show_bug.cgi?id=761960)**
## Description
rtpbin: Add rtcp-send-eos property.
This allows rtpbin to be used with a multiudpsink to broadcast to multiple endpoints. Setting this property to FALSE disables sending a EOS event to be sent to the send_rtcp_src_%u pad when a session is terminated, which would otherwise cause all further RTCP packets to be dropped.
rtprtxsend: Add a rtx_src request pad to allow sending unicast retransmits.
This allows a multiudpsink to be hooked up to rtpbin to broadcast to multiple receivers and use a rtprtxsend aux element to send lost packets only to the appropriate receiver using a dynudpsink.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/255decodebin/vaapi: ranking vaapi breaks plugging2023-10-13T15:26:04ZBugzilla Migration Userdecodebin/vaapi: ranking vaapi breaks plugging## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#761405)](https://bugzilla.gnome.org/show_bug.cgi?id=761405)**
## Description
Installing gstreamer-vaapi is enough to break auto plugging behaviour.
Because vaa...## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#761405)](https://bugzilla.gnome.org/show_bug.cgi?id=761405)**
## Description
Installing gstreamer-vaapi is enough to break auto plugging behaviour.
Because vaapi modules require specific hardware (e.g. QuickSync) and a specific environment (DISPLAY set with running X Server); installing these modules break systems that depends on autoplugging.
Consider a simple application that does transcoding in the background, while using vaapi to decode video if an X server is running.
Due to the higher ranking (PRIMARY+2), the vaapi modules are always picked over the generic sofware based solution.
See the att'd simple example.
barco@EMS-005008087c8a:~$ gst-launch-1.0 uridecodebin uri=file:///home/barco/some-file.mkv ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Stream with high frequencies VQ coding
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns 1
libva error: va_getDriverName() failed with operation failed,driver_name=i965
ERROR: from element /GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstVaapiDecodeBin:vaapidecodebin0/GstVaapiDecode:vaapidecode: Could not initialize supporting library.
Additional debug info:
gstvideodecoder.c(2571): gst_video_decoder_change_state (): /GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstVaapiDecodeBin:vaapidecodebin0/GstVaapiDecode:vaapidecode:
Failed to open decoder
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns 1
libva error: va_getDriverName() failed with operation failed,driver_name=i965
Freeing pipeline ...
The current workaround is lowering the ranking of the hardware based elements:
We might need to resort to (in the app):
GstPluginFeature *feature;
GstRegistry *registry = gst_registry_get();
feature = gst_registry_lookup_feature (registry, "vaapidecodebin");
if (feature != NULL) {
gst_plugin_feature_set_rank (feature, GST_RANK_NONE);
gst_object_unref (feature);
}
and so forth :-(
Though this is obviously not a viable solution when new modules are installed that were not yet considered.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/239splitmuxsrc: Implement segment query2020-09-18T16:14:57ZBugzilla Migration Usersplitmuxsrc: Implement segment query## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#758365)](https://bugzilla.gnome.org/show_bug.cgi?id=758365)**
## Description
Summary says it all, this is required to be able to seek correctly through gst-rtsp-serve...## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#758365)](https://bugzilla.gnome.org/show_bug.cgi?id=758365)**
## Description
Summary says it all, this is required to be able to seek correctly through gst-rtsp-server, in particular for formats with no parser.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/237gst_mini_object_unlock: assertion 'state >= SHARE_ONE' failed2023-04-11T00:57:37ZBugzilla Migration Usergst_mini_object_unlock: assertion 'state >= SHARE_ONE' failed## Submitted by bill-auger
**[Link to original bug (#758060)](https://bugzilla.gnome.org/show_bug.cgi?id=758060)**
## Description
Created attachment 315406
minimal pipeline exposing this bug
upon setting pipeline state to NUL...## Submitted by bill-auger
**[Link to original bug (#758060)](https://bugzilla.gnome.org/show_bug.cgi?id=758060)**
## Description
Created attachment 315406
minimal pipeline exposing this bug
upon setting pipeline state to NULL at shutdown the following assertion is thrown repeatedly countless times:
```
GStreamer-CRITICAL **: gst_mini_object_unlock: assertion 'state >= SHARE_ONE' failed
```
this is accompanied by wild disk thrashing and in the larger project where this was discovered it quite often also renders the entire system unresponsive where the only remedy is to pull the plug
i have isolated this behavior to a bin containing a pngdec and imagefreeze and ghostpad src to another bin
a .cpp file with a minimal pipeline exposing this is attached - a thread dump and valgrind profile is available in this gist along with the same .cpp file
https://gist.github.com/bill-auger/b003a77c20cfbe8a704b
**Attachment 315406**, "minimal pipeline exposing this bug":
[pngdec.cpp](/uploads/2685e8aa9729c3df2a8dd3e48d63b4e5/pngdec.cpp)
Version: 1.6.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/234Matroskademux fails to create caps for ACM audio2018-11-28T12:03:45ZBugzilla Migration UserMatroskademux fails to create caps for ACM audio## Submitted by Matej `@Knopp`
**[Link to original bug (#757583)](https://bugzilla.gnome.org/show_bug.cgi?id=757583)**
## Description
Created attachment 314809
Patch
gst_riff_create_audio_caps expects codec data in strf, but ...## Submitted by Matej `@Knopp`
**[Link to original bug (#757583)](https://bugzilla.gnome.org/show_bug.cgi?id=757583)**
## Description
Created attachment 314809
Patch
gst_riff_create_audio_caps expects codec data in strf, but matroskademux passes it as strd
Sample file
https://s3.amazonaws.com/MatejK/Samples/2001-start.mkv
**Patch 314809**, "Patch":
[0001-matroskademux-pass-riff-codec-data-as-strf-not-strd.patch](/uploads/c79aa8790e1fd3408d15513c3b59e9ee/0001-matroskademux-pass-riff-codec-data-as-strf-not-strd.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/231libgstosxvideosink.so causes hangs on plugin load on OS X 10.62023-10-12T17:58:02ZBugzilla Migration Userlibgstosxvideosink.so causes hangs on plugin load on OS X 10.6## Submitted by Ryan Hendrickson `@rhendric`
**[Link to original bug (#756918)](https://bugzilla.gnome.org/show_bug.cgi?id=756918)**
## Description
(This is with the patch that I submitted in https://bugzilla.gnome.org/show_bug.cgi?...## Submitted by Ryan Hendrickson `@rhendric`
**[Link to original bug (#756918)](https://bugzilla.gnome.org/show_bug.cgi?id=756918)**
## Description
(This is with the patch that I submitted in https://bugzilla.gnome.org/show_bug.cgi?id=756154, for what it's worth.)
Any gst-launch, gst-inspect, etc. hangs on startup as long as libgstosxvideosink.so is in the plugin dir. When I manually remove it, problem goes away.
Version: 1.6.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/220qtdemux: segfault when running reverse playback validate scenario for a parti...2023-07-02T16:31:00ZBugzilla Migration Userqtdemux: segfault when running reverse playback validate scenario for a particular file## Submitted by Vineeth
**[Link to original bug (#755102)](https://bugzilla.gnome.org/show_bug.cgi?id=755102)**
## Description
I get a segfault when i run reverse playback scenario with a particular mp4 file.
This is the stack ...## Submitted by Vineeth
**[Link to original bug (#755102)](https://bugzilla.gnome.org/show_bug.cgi?id=755102)**
## Description
I get a segfault when i run reverse playback scenario with a particular mp4 file.
This is the stack trace.
gst_qtdemux_seek_to_previous_keyframe (qtdemux=`<optimized out>`) at qtdemux.c:3983
3983 seg_media_start_mov = seg->trak_media_start;
```
(gdb) bt
#0 gst_qtdemux_seek_to_previous_keyframe (qtdemux=<optimized out>) at qtdemux.c:3983
#1 gst_qtdemux_loop (pad=0x9b9270) at qtdemux.c:5235
#2 0x00007ffff75ac451 in gst_task_func (task=0x9d75f0) at gsttask.c:331
#3 0x00007ffff702688c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007ffff7025f05 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007ffff6da2182 in start_thread (arg=0x7fffe6bd2700) at pthread_create.c:312
#6 0x00007ffff6acf47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
```
The crash is because, segment_index is -1.
For this particular sample, in gst_qtdemux_advance_sample
/* see if we are past the segment */
if (G_UNLIKELY (QTSAMPLE_DTS (stream, sample) >= segment->media_stop))
goto next_segment;
This condition gets satisfied and in next_segment label, segment_index is set to -1.
I was able to solve the crash .. but not sure if it is really correct..
While checking if we are past the segment, >= is being checked, so even though qtsample time is same as media_stop, we are skipping to next_segment.
Changing the check to '>' fixes the issue. We are really past the segment only when is greater than media_stop. Not sure if >= is really needed..https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/216avidemux/qtdemux: Output raw video in unaligned buffers causing crashing in O...2019-09-03T07:19:21ZBugzilla Migration Useravidemux/qtdemux: Output raw video in unaligned buffers causing crashing in ORC video conversion code## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#754353)](https://bugzilla.gnome.org/show_bug.cgi?id=754353)**
## Description
+++ This bug was initially created as a clone of [Bug 736965](https://bugzilla.gnome.org...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#754353)](https://bugzilla.gnome.org/show_bug.cgi?id=754353)**
## Description
+++ This bug was initially created as a clone of [Bug 736965](https://bugzilla.gnome.org/show_bug.cgi?id=736965) +++
See discussions there
Version: 1.4.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/209osxaudiosrc drops frames when osxaudiosink misses frames2023-07-03T09:39:16ZBugzilla Migration Userosxaudiosrc drops frames when osxaudiosink misses frames## Submitted by Ilya Konstantinov
**[Link to original bug (#753112)](https://bugzilla.gnome.org/show_bug.cgi?id=753112)**
## Description
To reproduce:
$ gst-launch-1.0 osxaudiosrc ! identity drop-probability=0.1 ! osxaudiosink ...## Submitted by Ilya Konstantinov
**[Link to original bug (#753112)](https://bugzilla.gnome.org/show_bug.cgi?id=753112)**
## Description
To reproduce:
$ gst-launch-1.0 osxaudiosrc ! identity drop-probability=0.1 ! osxaudiosink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstAudioSrcClock
WARNING: from element /GstPipeline:pipeline0/GstOsxAudioSrc:osxaudiosrc0: Can't record audio fast enough
Additional debug info:
gstaudiobasesrc.c(866): GstFlowReturn gst_audio_base_src_create(GstBaseSrc *, guint64, guint, GstBuffer **) (): /GstPipeline:pipeline0/GstOsxAudioSrc:osxaudiosrc0:
Dropped 9261 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.
WARNING: from element /GstPipeline:pipeline0/GstOsxAudioSrc:osxaudiosrc0: Can't record audio fast enough
I don't quite understand why osxaudiosrc drops frames when the *sink* is the one that's not receiving all of the frames. This doesn't happen with fakesink or filesink.
Also, it's "solved" by setting "osxaudiosink sync=0".https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/197rtpjitterbuffer: wastes CPU processing too many unnecessary timers2019-05-30T16:22:01ZBugzilla Migration Userrtpjitterbuffer: wastes CPU processing too many unnecessary timers## Submitted by Miguel París Díaz `@mparisdiaz`
**[Link to original bug (#751636)](https://bugzilla.gnome.org/show_bug.cgi?id=751636)**
## Description
I have found a case where the jitterbuffer gets a lot of timers and it spends a l...## Submitted by Miguel París Díaz `@mparisdiaz`
**[Link to original bug (#751636)](https://bugzilla.gnome.org/show_bug.cgi?id=751636)**
## Description
I have found a case where the jitterbuffer gets a lot of timers and it spends a lot of CPU processing them.
I open this bug to provide some patches to fix this problem.
### Blocking
* [Bug 740149](https://bugzilla.gnome.org/show_bug.cgi?id=740149)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/194souphttpsrc: add cookie jar2023-10-12T18:04:35ZBugzilla Migration Usersouphttpsrc: add cookie jar## Submitted by Eunhae Choi
**[Link to original bug (#751371)](https://bugzilla.gnome.org/show_bug.cgi?id=751371)**
## Description
In case of adaptive streaming, there is a additional http src element in the adaptive demux to downlo...## Submitted by Eunhae Choi
**[Link to original bug (#751371)](https://bugzilla.gnome.org/show_bug.cgi?id=751371)**
## Description
In case of adaptive streaming, there is a additional http src element in the adaptive demux to download content fragments.
In some cases, user-agent and cookie is needed to set to connect the http server but there is no way to get the current user-agent and cookie data from souphttpsrc.
I think souphttpsrc should handle the custom query of user-agent and cookies.
### Blocking
* [Bug 751372](https://bugzilla.gnome.org/show_bug.cgi?id=751372)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/187videocrop: Make videocrop controllable2021-03-13T12:57:20ZBugzilla Migration Uservideocrop: Make videocrop controllable## Submitted by Lazar Claudiu
**[Link to original bug (#749916)](https://bugzilla.gnome.org/show_bug.cgi?id=749916)**
## Description
Useful for video effect
### Depends on
* [Bug 740502](https://bugzilla.gnome.org/show_bug.cgi?id...## Submitted by Lazar Claudiu
**[Link to original bug (#749916)](https://bugzilla.gnome.org/show_bug.cgi?id=749916)**
## Description
Useful for video effect
### Depends on
* [Bug 740502](https://bugzilla.gnome.org/show_bug.cgi?id=740502)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/186deinterleave: allow switching between 1 channel configs2019-01-28T23:39:22ZBugzilla Migration Userdeinterleave: allow switching between 1 channel configs## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#749434)](https://bugzilla.gnome.org/show_bug.cgi?id=749434)**
## Description
Created attachment 303424
deinterleave: allow switching between 1 channel configs...## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#749434)](https://bugzilla.gnome.org/show_bug.cgi?id=749434)**
## Description
Created attachment 303424
deinterleave: allow switching between 1 channel configs
This patch allows changing between configs that have positioning information if both are 1 channel, where positioning doesn't matter.
One could argue that upstream should not include any positioning, and this this patch should not be merged, so I'm putting it here.
**Attachment 303424**, "deinterleave: allow switching between 1 channel configs":
[0001-deinterleave-allow-switching-between-1-channel-confi.patch](/uploads/e84e21476417c1868d94fe0ceece7226/0001-deinterleave-allow-switching-between-1-channel-confi.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/185v4l2sink: Playback does not work if V4L2 buffers are smaller than GStreamer b...2023-07-25T16:37:33ZBugzilla Migration Userv4l2sink: Playback does not work if V4L2 buffers are smaller than GStreamer buffers## Submitted by Tobias Modschiedler
**[Link to original bug (#749016)](https://bugzilla.gnome.org/show_bug.cgi?id=749016)**
## Description
This topic was started in the discussion of [bug 746834](https://bugzilla.gnome.org/show_bug....## Submitted by Tobias Modschiedler
**[Link to original bug (#749016)](https://bugzilla.gnome.org/show_bug.cgi?id=749016)**
## Description
This topic was started in the discussion of [bug 746834](https://bugzilla.gnome.org/show_bug.cgi?id=746834) at Comment 18 (https://bugzilla.gnome.org/show_bug.cgi?id=746834#c18).
If GStreamer source buffers are larger that V4L2 buffers (which makes sense for MPEG-TS data), copying them fails in gst_v4l2_buffer_pool_copy_buffer().
I'll copy the relevant part of Nicolas' comment here:
---
GstV4l2 also kind of lack some support. If the buffer is bigger then the v4l2 buffer size, it simply fails. It's fine for raw data, but for encoded data it should probably spread the data over multiple buffers and properly set the size for the last one. For mpegts, the buffer size will always be a multiple of 188 anyway.
I think we could have mpegts specific code to select a decent default size (N * 188), or change the driver to pick a better default. Then if a buffer is bigger and we have encoded data, we should loop (copy and queue), until all data has been consumed.
---
I'm having problems coming up with a patch. The "multi-buffer" handling will probably be in gst_v4l2_buffer_pool_process() at label "copying". But what happens if only a part of the source buffer can be copied, i.e. not enough destination buffers can be acquired?https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/181rtpbin: RTX packets only forwarded after two are received (probation period)2022-10-11T11:29:59ZBugzilla Migration Userrtpbin: RTX packets only forwarded after two are received (probation period)## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#747919)](https://bugzilla.gnome.org/show_bug.cgi?id=747919)**
## Description
Currently an RTX packet is queued up in rtpsource on the receiver until a second one is ...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#747919)](https://bugzilla.gnome.org/show_bug.cgi?id=747919)**
## Description
Currently an RTX packet is queued up in rtpsource on the receiver until a second one is received... because of the probation period. That's obviously not a good idea for RTX packets, as that one will then be far too late and we don't really have that many packets anyway.
Problem now is that nothing in rtpbin knows about RTX, and somehow we need to get this information to rtpsource so that it does not queue up things.Sebastian DrögeSebastian Drögehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/176v4l2: Improve URI handler2023-10-12T18:07:37ZBugzilla Migration Userv4l2: Improve URI handler## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#746818)](https://bugzilla.gnome.org/show_bug.cgi?id=746818)**
## Description
Created attachment 300359
v4l2: add uri hander interface
patch against 1.4.5
Gs...## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#746818)](https://bugzilla.gnome.org/show_bug.cgi?id=746818)**
## Description
Created attachment 300359
v4l2: add uri hander interface
patch against 1.4.5
GstUri backported from git in core
~~**Patch 300359**~~, "v4l2: add uri hander interface":
[0001-v4l2-add-GstUri-interface-to-v4l2-elements.patch](/uploads/529f7b48ebdbb064e83eeee1311309fd/0001-v4l2-add-GstUri-interface-to-v4l2-elements.patch)
Version: 1.10.4
### Depends on
* [Bug 779765](https://bugzilla.gnome.org/show_bug.cgi?id=779765)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/165flacdec: silence happens with specific flac2023-05-30T10:05:00ZBugzilla Migration Userflacdec: silence happens with specific flac## Submitted by stephane Cerveau `@dabrain34`
**[Link to original bug (#745609)](https://bugzilla.gnome.org/show_bug.cgi?id=745609)**
## Description
After 10 seconds, the sound becomes silence and come back after a few seconds.
...## Submitted by stephane Cerveau `@dabrain34`
**[Link to original bug (#745609)](https://bugzilla.gnome.org/show_bug.cgi?id=745609)**
## Description
After 10 seconds, the sound becomes silence and come back after a few seconds.
In GST_DEBUG=flacdec:4, there is this message:
gst_flac_dec_handle_frame:`<flacdec638>` process_single failed
It looks like the file is damaged but in VLC or audirvana, the playback jumps to the new working timestamp.
Is it a normal behaviour ?
File link:
https://www.dropbox.com/s/4q82cpafhalovfb/06-Love_Man.flac?dl=0
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/154rtsp stream playback issue2023-07-02T16:26:48ZBugzilla Migration Userrtsp stream playback issue## Submitted by swapnil
**[Link to original bug (#743618)](https://bugzilla.gnome.org/show_bug.cgi?id=743618)**
## Description
While playing rtsp streams on ubuntu14.04, video is stuck.
Below mentioned gstreamer-1.0 pipeline wa...## Submitted by swapnil
**[Link to original bug (#743618)](https://bugzilla.gnome.org/show_bug.cgi?id=743618)**
## Description
While playing rtsp streams on ubuntu14.04, video is stuck.
Below mentioned gstreamer-1.0 pipeline was run to test this issue.
gst-launch-1.0 rtspsrc location= rtsp://10.25.20.77:554/3gp/H264+aac/H264_BP_level3_2000kbps_320x240_36fps_aac_112kbps_44.1khz_stereo.3gp ! rtph264depay ! avdec_h264 ! xvimagesink -v
Version: 1.x