GStreamer issues
https://gitlab.freedesktop.org/groups/gstreamer/-/issues
2021-09-24T14:32:47Z
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/176
h264parse: sets parsed=true on output even in passthrough mode
2021-09-24T14:32:47Z
Bugzilla Migration User
h264parse: sets parsed=true on output even in passthrough mode
## Submitted by Matej `@Knopp`
**[Link to original bug (#737487)](https://bugzilla.gnome.org/show_bug.cgi?id=737487)**
## Description
This doesn't seem right. Just because both input and output are in same format, the parser should ...
## Submitted by Matej `@Knopp`
**[Link to original bug (#737487)](https://bugzilla.gnome.org/show_bug.cgi?id=737487)**
## Description
This doesn't seem right. Just because both input and output are in same format, the parser should claim that it has parsed the input and then enable passthrough.
In may case matroskademux output AVC H.264 (unparsed), decoder requires AVC with parsed=true and parser just appends parsed=true to the caps without even looking at the stream.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/175
dashdemux: fix gst_mpdparser_get_rep_idx_with_max_bandwidth return
2021-09-24T14:32:46Z
Bugzilla Migration User
dashdemux: fix gst_mpdparser_get_rep_idx_with_max_bandwidth return
## Submitted by Matthieu Bouron
**[Link to original bug (#737293)](https://bugzilla.gnome.org/show_bug.cgi?id=737293)**
## Description
If bandwidth <=0, gst_mpdparser_get_rep_idx_with_max_bandwidth should return -1 as no correspondi...
## Submitted by Matthieu Bouron
**[Link to original bug (#737293)](https://bugzilla.gnome.org/show_bug.cgi?id=737293)**
## Description
If bandwidth <=0, gst_mpdparser_get_rep_idx_with_max_bandwidth should return -1 as no corresponding representation is found.
This makes dashdemux select the lowest representation for the first fragment.
Version: 1.4.1
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/174
dshowvideosrc: Needs filtercaps with Apple FaceTime HD camera
2021-09-24T14:32:45Z
Bugzilla Migration User
dshowvideosrc: Needs filtercaps with Apple FaceTime HD camera
## Submitted by Joshua M. Doe
**[Link to original bug (#736916)](https://bugzilla.gnome.org/show_bug.cgi?id=736916)**
## Description
With the Apple FaceTime HD camera (in a MacBook Pro Retina Mid-2012), this simple pipeline results ...
## Submitted by Joshua M. Doe
**[Link to original bug (#736916)](https://bugzilla.gnome.org/show_bug.cgi?id=736916)**
## Description
With the Apple FaceTime HD camera (in a MacBook Pro Retina Mid-2012), this simple pipeline results in an error:
gst-launch-1.0 dshowvideosrc device-name="FaceTime HD Camera (Built-in)" ! videoconvert ! autovideosink
gstdshowvideosrc.cpp:665:gst_dshowvideosrc_set_caps: Can't connect
capture filter with fakesink filter (error=0x80070491)
If I specify one of the supported resolutions using filter caps it works fine:
gst-launch-1.0 dshowvideosrc device-name="FaceTime HD Camera (Built-in)" ! video/x-raw,width=640 ! videoconvert ! autovideosink
I tried every supported resolution specifying it in this manner and it worked fine. I looked around in the caps code for a bit, but didn't find anything obvious.
With another webcam (Creative Live! VF0400) it works fine, no filter caps are needed.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/173
pcapparse: add support for IPv6
2021-09-24T14:32:45Z
Bugzilla Migration User
pcapparse: add support for IPv6
## Submitted by Felipe Alexandre Ferreira
**[Link to original bug (#735991)](https://bugzilla.gnome.org/show_bug.cgi?id=735991)**
## Description
Created attachment 285288
Changes to add support for IPv6 and IP in IP tunneling
...
## Submitted by Felipe Alexandre Ferreira
**[Link to original bug (#735991)](https://bugzilla.gnome.org/show_bug.cgi?id=735991)**
## Description
Created attachment 285288
Changes to add support for IPv6 and IP in IP tunneling
pcapparse bad plugin don't support IPv6 packages, just IPv4. I made a patch to add IPv6 support, and tunneling 6in4 or 4in6.
I've made the patch based in 0.10 branch, but since the code of function that decodes IP header don't changed, i think it will work in 1.x branches.
~~**Patch 285288**~~, "Changes to add support for IPv6 and IP in IP tunneling":
[pcapparse.patch](/uploads/a58f38441a4bec771f71946070135b52/pcapparse.patch)
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/171
tsdemux: fix "none" seek target being ignored on rate change seeks
2021-09-24T14:32:44Z
Bugzilla Migration User
tsdemux: fix "none" seek target being ignored on rate change seeks
## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#735100)](https://bugzilla.gnome.org/show_bug.cgi?id=735100)**
## Description
Created attachment 283969
fix "none" seek target being ignored on rate change see...
## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#735100)](https://bugzilla.gnome.org/show_bug.cgi?id=735100)**
## Description
Created attachment 283969
fix "none" seek target being ignored on rate change seeks
If the seek target is none, we bypass most of the seek code, ensuring that new segments will be reemitted from the streaming thread.
**Patch 283969**, "fix "none" seek target being ignored on rate change seeks":
[0001-tsdemux-handle-seeks-with-no-target-ie-keep-current-.patch](/uploads/69b8fc18901c51f5313eebc89e556437/0001-tsdemux-handle-seeks-with-no-target-ie-keep-current-.patch)
### Blocking
* [Bug 747442](https://bugzilla.gnome.org/show_bug.cgi?id=747442)
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/170
[API] Add gstgralloc library
2021-09-24T14:32:44Z
Bugzilla Migration User
[API] Add gstgralloc library
## Submitted by Mohammed Sameer
**[Link to original bug (#734908)](https://bugzilla.gnome.org/show_bug.cgi?id=734908)**
## Description
Created attachment 283596
proposed patch
Attaching a patch that adds a GstGralloc allocato...
## Submitted by Mohammed Sameer
**[Link to original bug (#734908)](https://bugzilla.gnome.org/show_bug.cgi?id=734908)**
## Description
Created attachment 283596
proposed patch
Attaching a patch that adds a GstGralloc allocator with its GstGrallocMemory and also a buffer pool (GstGrallocBufferPool) for usage with elements utilizing the above mentioned allocator.
gralloc is the library used by Android to allocate android native buffers used for graphics rendering and zero copy media decoding (Probably it has other uses as well).
The only issue I see with the patch is I had to lie and set the format to GST_VIDEO_FORMAT_I420 because I cannot use GST_VIDEO_FORMAT_ENCODED since it's size is 0 and various GStreamer API dealing with allocation queries expect size which is not 0
The allocator will be used to add support to gst-omx (And perhaps glimagesink too)
~~**Patch 283596**~~, "proposed patch":
[0001-Add-gstgralloc-library.patch](/uploads/8275103a78f6a1db16a0d1f3bd13a1f9/0001-Add-gstgralloc-library.patch)
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/169
tsdemux: update output segments on seek
2021-09-24T14:32:43Z
Bugzilla Migration User
tsdemux: update output segments on seek
## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#734711)](https://bugzilla.gnome.org/show_bug.cgi?id=734711)**
## Description
Created attachment 283263
update output segments on seek
This fixes at least...
## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#734711)](https://bugzilla.gnome.org/show_bug.cgi?id=734711)**
## Description
Created attachment 283263
update output segments on seek
This fixes at least the case where a non flushing rate changing seek
is done, but the new rate would not be communicated downstream.
I'm not sure whether it'd be best to only set this when the seek is non flushing, assuming that downstream will resend a segment when stopping flushing...
~~**Patch 283263**~~, "update output segments on seek":
[0001-tsdemux-update-output-segments-on-seek.patch](/uploads/889ac0c6f01b4e616b4b932203515f43/0001-tsdemux-update-output-segments-on-seek.patch)
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/168
dvbsrc: tuning block in playing state
2021-09-24T14:32:43Z
Bugzilla Migration User
dvbsrc: tuning block in playing state
## Submitted by jingbo.hou
**[Link to original bug (#734392)](https://bugzilla.gnome.org/show_bug.cgi?id=734392)**
## Description
when failure to tune in playing state , task can't read data from dvr node and will be in a infinite ...
## Submitted by jingbo.hou
**[Link to original bug (#734392)](https://bugzilla.gnome.org/show_bug.cgi?id=734392)**
## Description
when failure to tune in playing state , task can't read data from dvr node and will be in a infinite loop. now tuning again, we will be in blocking.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/167
mpegvideoparse: generate proper PTS for outgoing frames
2021-09-24T14:32:41Z
Bugzilla Migration User
mpegvideoparse: generate proper PTS for outgoing frames
## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#734386)](https://bugzilla.gnome.org/show_bug.cgi?id=734386)**
## Description
The parser elements are not generating right PTS for the outgoing frames in current...
## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#734386)](https://bugzilla.gnome.org/show_bug.cgi?id=734386)**
## Description
The parser elements are not generating right PTS for the outgoing frames in current implementation. This is a feature request to add PTS generation in mpegvideoparse element.The same has been implemented in gstreamer-vaapi https://gitorious.org/vaapi/gstreamer-vaapi/source/7ac501d026036887c114b28bc9fb4aabc557e91a:gst-libs/gst/vaapi/gstvaapidecoder_mpeg2.c
### Blocking
* [Bug 734135](https://bugzilla.gnome.org/show_bug.cgi?id=734135)
* [Bug 734547](https://bugzilla.gnome.org/show_bug.cgi?id=734547)
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/166
h264parse: output frames with no pts causes jerky rendering
2021-09-24T14:32:41Z
Bugzilla Migration User
h264parse: output frames with no pts causes jerky rendering
## Submitted by Aurélien Zanelli
**[Link to original bug (#734124)](https://bugzilla.gnome.org/show_bug.cgi?id=734124)**
## Description
Playing a specific ts file using this kind of pipeline:
gst-launch-1.0 filesrc location=1seg.t...
## Submitted by Aurélien Zanelli
**[Link to original bug (#734124)](https://bugzilla.gnome.org/show_bug.cgi?id=734124)**
## Description
Playing a specific ts file using this kind of pipeline:
gst-launch-1.0 filesrc location=1seg.ts ! tsdemux program-number=23992 ! h264parse ! video/x-h264,stream-format=byte-stream,alignment=au ! avdec_h264 ! autovideosink
causes the rendering to be jerky.
The test file can be downloaded here: http://www.darkosphere.fr/tmp/gstreamer/1seg.ts
I think it could be caused by the h264parse element sending frame to decoder without pts.
Here is what I understand about the issue:
I notice that h264parse, in this case, rely on timestamp provided by upstream, ie tsdemux. But buffers pushed by tsdemux element can contain more than one AU, so sone of them will be pushed with a non valid PTS causing decoder to be confused.
Currently, I wrote an ugly ugly ugly hack (and pretty unclear) which slightly improve the rendering. My approach was to try to interpolate PTS using timing info through using gst_h264_parse_get_timestamp() in pre_push_frame().
What do you think about this issue, do you have better ideas ?
P.S: This issue can be a duplicate of [bug 659489](https://bugzilla.gnome.org/show_bug.cgi?id=659489), but I'm not sure.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/165
mpegpsdemux: Confused when receiving segment updates from upstream
2021-09-24T14:32:41Z
Bugzilla Migration User
mpegpsdemux: Confused when receiving segment updates from upstream
## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#734036)](https://bugzilla.gnome.org/show_bug.cgi?id=734036)**
## Description
I'm working on implementing DLNA time based fast forward. The idea is to
implem...
## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#734036)](https://bugzilla.gnome.org/show_bug.cgi?id=734036)**
## Description
I'm working on implementing DLNA time based fast forward. The idea is to
implement fast forward in dlnasrc by requesting smaller parts of the file to
the HTTP server. Dlnasrc then sends segment updates for each fragment of the
file to play (for example, if rate=2 and we use chunk of 1 second we could have
something like [00:00, 00:01] then [00:02, 00:03] then [00:04; 00:05]).
This works fine with mpegpsdemux when doing fast forward but not when going in reverse to do fast backward (rate=-2 for example). It starts playing the requested chunks fine but at some point it just stops.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/164
mpegtsdemux: Confused when receiving segment updates from upstream
2021-09-24T14:32:40Z
Bugzilla Migration User
mpegtsdemux: Confused when receiving segment updates from upstream
## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#734024)](https://bugzilla.gnome.org/show_bug.cgi?id=734024)**
## Description
I'm working on implementing DLNA time based fast forward. The idea is to implemen...
## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#734024)](https://bugzilla.gnome.org/show_bug.cgi?id=734024)**
## Description
I'm working on implementing DLNA time based fast forward. The idea is to implement fast forward in dlnasrc by requesting smaller parts of the file to the HTTP server. Dlnasrc then sends segment updates for each fragment of the file to play (for example, if rate=2 and we use chunk of 1 second we could have something like [00:00, 00:01] then [00:02, 00:03] then [00:04; 00:05]).
This works fine with mpegpsdemux but not so much with mpegtsdemux. With 1.4 playback just stops when starting the fast forward.
With this patch http://cgit.freedesktop.org/~bilboed/gst-plugins-bad/commit/?h=trickmodes&id=bcde22f243a4cc6e053b7d89a435ee021d237214 playback is fine but the reported time is wrong (the position slider in playback-test is always stuck between the 2 same values).
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/163
Configuring Encoder Output Fails on Android - Nexus
2021-09-24T14:32:40Z
Bugzilla Migration User
Configuring Encoder Output Fails on Android - Nexus
## Submitted by Eric
**[Link to original bug (#733739)](https://bugzilla.gnome.org/show_bug.cgi?id=733739)**
## Description
I'm using ges-launch and transcoding a video file, this works fine on several devices. However, with the Ne...
## Submitted by Eric
**[Link to original bug (#733739)](https://bugzilla.gnome.org/show_bug.cgi?id=733739)**
## Description
I'm using ges-launch and transcoding a video file, this works fine on several devices. However, with the Nexus, the video successfully makes it through the pipeline, but no output file is created, I receive the following error message:
07-25 10:05:54.749: E/ACodec(5316): [OMX.qcom.video.encoder.avc] storeMetaDataInBuffers (output) failed w/ err -2147483648
Version: 1.4.0
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/162
tsdemux: implement convert queries on the sinkpad
2021-09-24T14:32:39Z
Bugzilla Migration User
tsdemux: implement convert queries on the sinkpad
## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#733532)](https://bugzilla.gnome.org/show_bug.cgi?id=733532)**
## Description
.
## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#733532)](https://bugzilla.gnome.org/show_bug.cgi?id=733532)**
## Description
.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/161
low frame rate with multiple d3dvideosinks
2021-09-24T14:32:39Z
Bugzilla Migration User
low frame rate with multiple d3dvideosinks
## Submitted by Steven
**[Link to original bug (#733481)](https://bugzilla.gnome.org/show_bug.cgi?id=733481)**
## Description
When using multiple d3dvideosink elements in the same pipeline the frame rate drops very noticeably for so...
## Submitted by Steven
**[Link to original bug (#733481)](https://bugzilla.gnome.org/show_bug.cgi?id=733481)**
## Description
When using multiple d3dvideosink elements in the same pipeline the frame rate drops very noticeably for some of the video sinks.
Here is my pipeline:
uridecodebin name=vehiclebin uri=rtsp://127.0.0.1:8554/vehicle.sdp !
tee name=tp
tp. ! queue ! videocrop top=0 left=10 right=376 bottom=290 ! d3dvideosink name=rear
tp. ! queue ! videocrop top=0 left=400 right=0 bottom=290 ! d3dvideosink name=forward
tp. ! queue ! videocrop top=290 left=10 right=376 bottom=6 ! d3dvideosink name=left
tp. ! queue ! videocrop top=290 left=398 right=0 bottom=6 ! d3dvideosink name=right
The video plays smoothly with 1.0.10 but will not play at all with versions up to 1.3.91 due to a different bug.
Version: 1.4.0
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/160
Add depthsense plugin and depthsense2src element
2021-09-24T14:32:38Z
Bugzilla Migration User
Add depthsense plugin and depthsense2src element
## Submitted by Miguel Casas-Sanchez `@miguelecasassanchez`
**[Link to original bug (#733222)](https://bugzilla.gnome.org/show_bug.cgi?id=733222)**
## Description
DepthSense is the name of the SDK used by Time-Of-Flight cameras base...
## Submitted by Miguel Casas-Sanchez `@miguelecasassanchez`
**[Link to original bug (#733222)](https://bugzilla.gnome.org/show_bug.cgi?id=733222)**
## Description
DepthSense is the name of the SDK used by Time-Of-Flight cameras based on SoftKinetic chip, f.i. DS325 [1] or Creative Senz3d [2]. This bug tracks the landing of a plugin and element to capture the 3D information, streaming 16-bit depth maps (sent as GRAY16_LE).
[1] http://www.softkinetic.com/products/depthsensecameras.aspx
[2] http://us.creative.com/p/web-cameras/creative-senz3d
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/159
mpegts: add cell list and cell frequency link descriptors
2021-09-24T14:32:38Z
Bugzilla Migration User
mpegts: add cell list and cell frequency link descriptors
## Submitted by Stefan Ringel
**[Link to original bug (#733145)](https://bugzilla.gnome.org/show_bug.cgi?id=733145)**
## Description
mpegts: add cell list and cell frequency link descriptors
## Submitted by Stefan Ringel
**[Link to original bug (#733145)](https://bugzilla.gnome.org/show_bug.cgi?id=733145)**
## Description
mpegts: add cell list and cell frequency link descriptors
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/157
dvbcam: error witing TPDU (5): Input/output error afther being connected
2021-09-24T14:32:37Z
Bugzilla Migration User
dvbcam: error witing TPDU (5): Input/output error afther being connected
## Submitted by Steven Vanden Branden `@StevenVB`
**[Link to original bug (#732643)](https://bugzilla.gnome.org/show_bug.cgi?id=732643)**
## Description
Created attachment 279792
gstreamer trace
when trying to use gstreamer t...
## Submitted by Steven Vanden Branden `@StevenVB`
**[Link to original bug (#732643)](https://bugzilla.gnome.org/show_bug.cgi?id=732643)**
## Description
Created attachment 279792
gstreamer trace
when trying to use gstreamer to record video encrypted with a ci smartcard from tv vlaanderen (dvb-s channel) the cam card gets connected and the slot gets defined , but a little later the connection gets input/output problems
dvbcam camtransport.c:243:cam_tl_connection_write_tpdu: error witing TPDU (5): Input/output error
i use a tbs 5980 with a driver that is updated to latest git code. watching without the encryption works fine.
see stack trace (short version) with is run together with the gnome-dvb-deamon gst1.0 that is still in development.
the following error also happens at some point before it:
0:07:44.121090623 5096 0x7f41f40034f0 ERROR dvbcam camapplication.c:334:session_data_cb: unexpected APDU length 20 expected 26
i also noticed that it opens 3 new sessions in the run? is this normal?
greetings
Steven
**Attachment 279792**, "gstreamer trace":
[stacktrace.log](/uploads/d6ff30dfb19ce3435fa12b9bea99be1e/stacktrace.log)
Version: 1.4.0
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/156
h264parse: extract base stream from MVC or SVC encoded streams
2021-09-24T14:32:36Z
Bugzilla Migration User
h264parse: extract base stream from MVC or SVC encoded streams
## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#732267)](https://bugzilla.gnome.org/show_bug.cgi?id=732267)**
## Description
If downstream decoder, or an intermediate capsfilter, requests caps with only Annex.A pr...
## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#732267)](https://bugzilla.gnome.org/show_bug.cgi?id=732267)**
## Description
If downstream decoder, or an intermediate capsfilter, requests caps with only Annex.A profiles, then h264parse should discard any MVC (Annex.H) specific NAL units from the output stream.
### Depends on
* [Bug 732203](https://bugzilla.gnome.org/show_bug.cgi?id=732203)
* [Bug 732239](https://bugzilla.gnome.org/show_bug.cgi?id=732239)
### Blocking
* [Bug 732265](https://bugzilla.gnome.org/show_bug.cgi?id=732265)
* [Bug 732266](https://bugzilla.gnome.org/show_bug.cgi?id=732266)
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/155
h264parse: default to byte-stream/nalu format (Annex B)
2021-09-24T14:32:35Z
Bugzilla Migration User
h264parse: default to byte-stream/nalu format (Annex B)
## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#732167)](https://bugzilla.gnome.org/show_bug.cgi?id=732167)**
## Description
Always default to stream-format=byte-stream,alignment=nalu if avcC format was not detect...
## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#732167)](https://bugzilla.gnome.org/show_bug.cgi?id=732167)**
## Description
Always default to stream-format=byte-stream,alignment=nalu if avcC format was not detected. This is not only the natural byte stream format specified in the standard (Annex B), but is also the fastest format to process on the decoder side. Indeed, with NALU alignment, scan for start codes could be avoided by taking the first GstBuffer from the input GstAdapter: this matches a complete NAL unit.