gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2023-07-04T15:46:46Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2761Application Development Manual: add gst-launch crash course before diving int...2023-07-04T15:46:46ZBugzilla Migration UserApplication Development Manual: add gst-launch crash course before diving into code## Submitted by Tim Müller `@tpm`
**[Link to original bug (#707586)](https://bugzilla.gnome.org/show_bug.cgi?id=707586)**
## Description
Ian Davidson suggested this:
On the GStreamer web site it says “Application Development Ma...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#707586)](https://bugzilla.gnome.org/show_bug.cgi?id=707586)**
## Description
Ian Davidson suggested this:
On the GStreamer web site it says “Application Development Manual (Read this first) ” - so that would seem to be the place to start if you want to learn about Gstreamer.
Very early in the document (section 2.1), it says that “The programmer can use an extensive set of powerful tools to create media pipelines without writing a single line of code. ” That is good to know and is brought about by the library of 'Plug-ins'.
But – then as you continue to read the manual, you are thrown heavily into programming. Straight away.
Might I suggest that very early on you have mention of gst-launch – since, using that you can do things without having to write a single line of coding. However, the chapter on gst-launch itself is not an easy-to-read chapter: It starts with a 'simple commandline' and then shows a more complex one – but without any explanation. If we take the first example
gst-launch filesrc location=hello.mp3 ! mad ! audioresample ! osssink
you could then describe what is happening. e.g.:
gst-launch is a program which enables the user to construct pipelines using command-line parameters.
Filesrc is an element (or a plugin) – in this case it will read data from a file and needs to know the name of the file to open. It will output the data so as to be the source for the next element in the pipe-line.
The “!” symbol separates the first element from the next.
mad is the next element in the pipe-line: It will decode mp3 data. It picks up the source provided by the previous element and then outputs the decoded data for the next element in the pipe-line.
Once again, a “!” symbol separates the elements.
audioresample resamples the Audio. (I don’t know why this is a benefit – it could be explained)
Another “!”
osssink takes the audio signal and sends it to an output device which supports (or is supported by) OSS.
The second example could then be similarly explained – which would be a useful exercise since the single vob file is being demuxed with part of the data going one way and the rest another. A reference, at this point to the Overview of available plug-ins would be beneficial. Perhaps an example where more options need to be specified could also be explained.
Then you can say that, if you need to build this into an application, you can do the same stuff with code and if you need to do something which is not currently supported, you can write your own plug-in – so read on...
I hope this is usefulhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2750vtenc: vtenc_h264 causing too many Redistribute latency...2023-08-04T20:57:05ZBugzilla 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.3Piotr BrzezińskiPiotr Brzezińskihttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2747wavparse: doesn't detect ac3 streams marked as PCM2023-07-01T21:43:21ZBugzilla Migration Userwavparse: doesn't detect ac3 streams marked as PCM## Submitted by Putinei Ionut
**[Link to original bug (#701502)](https://bugzilla.gnome.org/show_bug.cgi?id=701502)**
## Description
Gstreamer can not detect wav files with ac3 stream.(Wavparse)## Submitted by Putinei Ionut
**[Link to original bug (#701502)](https://bugzilla.gnome.org/show_bug.cgi?id=701502)**
## Description
Gstreamer can not detect wav files with ac3 stream.(Wavparse)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2746avidemux: Doesn't handle files with large gaps between audio/video streams pr...2023-07-10T14:54:29ZBugzilla Migration Useravidemux: Doesn't handle files with large gaps between audio/video streams properly## Submitted by Cristian Aravena Romero `@caravena`
**[Link to original bug (#608945)](https://bugzilla.gnome.org/show_bug.cgi?id=608945)**
## Description
Open bug in lauchpad.net:
https://bugs.edge.launchpad.net/ubuntu/+source/gs...## Submitted by Cristian Aravena Romero `@caravena`
**[Link to original bug (#608945)](https://bugzilla.gnome.org/show_bug.cgi?id=608945)**
## Description
Open bug in lauchpad.net:
https://bugs.edge.launchpad.net/ubuntu/+source/gstreamer0.10/+bug/516832
loop in gstpad.c
"$ LANGUAGE=C GST_DEBUG_NO_COLOR=1 GST_DEBUG=*:2 totem 2> log
0:00:00.091962270 4404 0x99e0080 WARN pyplugin gstpythonplugin.c:343:plugin_init: Couldn't g_module_open libpython. Reason: /usr/lib/libpython2.6.so: cannot open shared object file: No such file or directory
0:00:00.092094409 4404 0x99e0080 WARN GST_PLUGIN_LOADING gstplugin.c:422:gst_plugin_register_func: plugin "/usr/lib/gstreamer-0.10/libgstpython.so" failed to initialise
0:00:00.093664162 4404 0x99e0080 WARN GST_PLUGIN_LOADING gstplugin.c:422:gst_plugin_register_func: plugin "/usr/lib/gstreamer-0.10/libgstladspa.so" failed to initialise
(totem:4403): GLib-GObject-WARNING **: value "10752000" of type `guint' is invalid or out of range for property `connection-speed' of type `guint'
0:00:05.426087788 4403 0x99e0080 WARN GST_SCHEDULING gstpad.c:4603:gst_pad_get_range:<source:src> getrange failed unexpected
0:00:05.426199813 4403 0x99e0080 WARN GST_SCHEDULING gstpad.c:4715:gst_pad_pull_range:<decodebin20:sink> pullrange failed unexpected
0:00:05.426238924 4403 0x99e0080 WARN GST_SCHEDULING gstpad.c:4603:gst_pad_get_range:<source:src> getrange failed unexpected
0:00:05.426270213 4403 0x99e0080 WARN GST_SCHEDULING gstpad.c:4715:gst_pad_pull_range:<decodebin20:sink> pullrange failed unexpected
0:00:05.426303737 4403 0x99e0080 WARN GST_SCHEDULING gstpad.c:4603:gst_pad_get_range:<source:src> getrange failed unexpected
0:00:05.426333629 4403 0x99e0080 WARN GST_SCHEDULING gstpad.c:4715:gst_pad_pull_range:<decodebin20:sink> pullrange failed unexpected
..."
### See also
* https://launchpad.net/bugs/516832Edward HerveyEdward Herveyhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2745decodebin3: Race with caps changing in stream2023-07-10T13:17:57ZBugzilla Migration Userdecodebin3: Race with caps changing in stream## Submitted by Arun Raghavan `@arun`
**[Link to original bug (#607471)](https://bugzilla.gnome.org/show_bug.cgi?id=607471)**
## Description
While playing the following file, I do not see the video, only a still image:
http://s...## Submitted by Arun Raghavan `@arun`
**[Link to original bug (#607471)](https://bugzilla.gnome.org/show_bug.cgi?id=607471)**
## Description
While playing the following file, I do not see the video, only a still image:
http://samples.mplayerhq.hu/archive/container/mov/mov+svq3+aac++animatrix_2_program_640-sample.mov
gst-launch then quits with the following error:
$ gst-launch playbin2 uri=file:///$PWD/mov+svq3+aac++animatrix_2_program_640-sample.mov
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstPulseSinkClock
ERROR: from element /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstJpegDec:jpegdec0: Failed to decode JPEG image
Additional debug info:
gstjpegdec.c(1261): gst_jpeg_dec_chain (): /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstJpegDec:jpegdec0:
Error` #70`: Unsupported marker type 0x%02x
Execution ended after 3505994408 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
----
FWIW, I noticed that the stream topology that gets posted looks like this:
CONTAINER: video/quicktime
AUDIO: audio/mpeg, mpegversion=(int)4, framed=(boolean)true, codec_data=(buffer)1210, rate=(int)44100, channels=(int)2
AUDIO: audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)16, depth=(int)16, rate=(int)44100, channels=(int)2
UNKNOWN: image/jpeg, width=(int)640, height=(int)272, framerate=(fraction)15/1
VIDEO: video/x-raw-yuv, format=(fourcc)I420, width=(int)640, height=(int)272, framerate=(fraction)15/1Edward HerveyEdward Herveyhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2744audiofirfilter: Add support for changing kernel size without draining the sam...2023-07-01T21:18:37ZBugzilla Migration Useraudiofirfilter: Add support for changing kernel size without draining the sample history## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#606322)](https://bugzilla.gnome.org/show_bug.cgi?id=606322)**
## Description
It would be nice if draining the history could be prevented when changing the kernel siz...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#606322)](https://bugzilla.gnome.org/show_bug.cgi?id=606322)**
## Description
It would be nice if draining the history could be prevented when changing the kernel size too. Currently it's only supported if the kernel size stays the same.
Following are some patches that partially implement this and some notes on what still needs to be done.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2743RTP depayloaders should send tags with metadata such as codec and bitrate2023-07-01T19:23:24ZBugzilla Migration UserRTP depayloaders should send tags with metadata such as codec and bitrate## Submitted by an unknown user
**[Link to original bug (#536453)](https://bugzilla.gnome.org/show_bug.cgi?id=536453)**
## Description
http://www.nanog.org/qtstream.mov
Streams, but lots of rendering artifacts at start of strea...## Submitted by an unknown user
**[Link to original bug (#536453)](https://bugzilla.gnome.org/show_bug.cgi?id=536453)**
## Description
http://www.nanog.org/qtstream.mov
Streams, but lots of rendering artifacts at start of stream. More importantly though the plugins in question seem to report no information for Totem's proprties tab. Totem screenshot attached.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2742qtdemux: Support chapters and provide a GstToc2023-07-01T19:20:38ZBugzilla Migration Userqtdemux: Support chapters and provide a GstToc## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#540887)](https://bugzilla.gnome.org/show_bug.cgi?id=540887)**
## Description
There's currently no chapters support in qtdemux. This could be used to browse in files ...## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#540887)](https://bugzilla.gnome.org/show_bug.cgi?id=540887)**
## Description
There's currently no chapters support in qtdemux. This could be used to browse in files such as:
http://downloads.oreilly.com/make/MAKE_2005-07-18.m4b
### Depends on
* [Bug 540890](https://bugzilla.gnome.org/show_bug.cgi?id=540890)
### Blocking
* [Bug 163546](https://bugzilla.gnome.org/show_bug.cgi?id=163546)
* [Bug 328298](https://bugzilla.gnome.org/show_bug.cgi?id=328298)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2741avidemux, qtdemux, dvdec: signal DVCPRO50 codec properly2023-07-03T07:51:12ZBugzilla Migration Useravidemux, qtdemux, dvdec: signal DVCPRO50 codec properly## Submitted by j^
**[Link to original bug (#526481)](https://bugzilla.gnome.org/show_bug.cgi?id=526481)**
## Description
add fourcc for DVCPRO50 to qtdemux
dv5n is DVCPRO50 NTSC and
dv5c is DVCPRO50 PAL
right now only ffde...## Submitted by j^
**[Link to original bug (#526481)](https://bugzilla.gnome.org/show_bug.cgi?id=526481)**
## Description
add fourcc for DVCPRO50 to qtdemux
dv5n is DVCPRO50 NTSC and
dv5c is DVCPRO50 PAL
right now only ffdec_dvvideo is able to decode those files properly
but totem chooses dvdec, not sure how to fix that.
playing them via gst-launch works:
gst-launch filesrc location=test.mov ! qtdemux ! ffdec_dvvideo ! ffmpegcolorspace ! xvimagesinkhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2740matroskademux: support for multi-segment Matroska files2023-07-01T19:09:29ZBugzilla Migration Usermatroskademux: support for multi-segment Matroska files## Submitted by Lionel Dricot `@ldricot`
**[Link to original bug (#334082)](https://bugzilla.gnome.org/show_bug.cgi?id=334082)**
## Description
If you play a matroska (.mkv) file with segments, Totem will only play the
first segme...## Submitted by Lionel Dricot `@ldricot`
**[Link to original bug (#334082)](https://bugzilla.gnome.org/show_bug.cgi?id=334082)**
## Description
If you play a matroska (.mkv) file with segments, Totem will only play the
first segment without allowing you to switch to another one.
Unfortunatly, I can't upload an example file (I've seen this with a 4Go file).
Perhaps is there one in the Gstreamer test suite ?
Following Haali on #matroska, it's not about chapter but about segment.
Most files are one segment only and totem only support one segment (as all
others *NIX players).
My file is multi-segment, which is one step over chapters. (If I understand
correctly the spec, each segment can have his own tracks and chapters. Chapters
are only "bookmarks" in a big file)
The spec : http://www.matroska.org/technical/specs/index.htmlhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2726rmdemux: REAL Media File make system Hang <gst_rmdemux_chain:Bogus looking he...2023-06-27T23:17:01ZBugzilla Migration Userrmdemux: REAL Media File make system Hang <gst_rmdemux_chain:Bogus looking header, unprintable FOURCC>## Submitted by Orange Ashu
**[Link to original bug (#755723)](https://bugzilla.gnome.org/show_bug.cgi?id=755723)**
## Description
Hello,
I were checking the GST-Real media Parser code and found that one clip (Test file) makes...## Submitted by Orange Ashu
**[Link to original bug (#755723)](https://bugzilla.gnome.org/show_bug.cgi?id=755723)**
## Description
Hello,
I were checking the GST-Real media Parser code and found that one clip (Test file) makes my system Hangs (Windows x86, Linux, Win CE etc).
this problem for the video file is present from GST 0.1 to Even in GST 1.6. please help to guide me which part of code can be debugged further for the same.
>1: Test clip run command
gst-launch-1.0 --gst-debug-level=5 playbin uri=file:///D:/11_OnePiece_RV4.rmvb
>2: Test clip source file
Will attach somewhere and share the location in comment later on this bug.
>3: Logs with Debug level 5
Attached.
>4: My Analysis:
a. Test real media clip headers are correct.
I checked each and every information and links (including size and other details for all Types of FOURCC.
b. While decoding, it detects [.RMF, PROP , MDPR , MDPR, MDPR, CONT] correctly next available FOURCC is "DATA", which were never detected.
c. This file i am able to play on lots of other frameworks and plateform (VLC (Win/ Linux), Android devices etc.).
Logs analysis is as below (Line# 97156)
----
0:00:05.198350818 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2350:gst_base_src_update_length:`<source>` reading offset 858, length 31, size 178754120, segment.stop -1, maxsize 178754120
0:00:05.198403458 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2451:gst_base_src_get_range:`<source>` calling create offset 858 length 31, time 0
0:00:05.198453449 6904 0F7AEA08 DEBUG GST_MEMORY gstmemory.c:138:gst_memory_init: new memory 005683F0, maxsize:34 offset:0 size:31
0:00:05.198512048 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2305:gst_base_src_do_sync:`<source>` we have no clock
0:00:05.198562370 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2515:gst_base_src_get_range:`<source>` buffer ok
0:00:05.198611699 6904 0F7AEA08 DEBUG default rmutils.c:83:gst_rm_utils_read_tags: File Content : (CONT) len = 31
0:00:05.198662022 6904 0F7AEA08 DEBUG default rmutils.c:111:gst_rm_utils_read_tags: title =
0:00:05.198718965 6904 0F7AEA08 DEBUG default rmutils.c:104:gst_rm_utils_read_tags: converting tag from CP1252 to UTF-8
0:00:05.198790807 6904 0F7AEA08 DEBUG default rmutils.c:111:gst_rm_utils_read_tags: artist = û¤·¤ÎZHU
0:00:05.198845433 6904 0F7AEA08 DEBUG default rmutils.c:111:gst_rm_utils_read_tags: copyright = bbs.jumpcn.com
0:00:05.198896418 6904 0F7AEA08 DEBUG default rmutils.c:111:gst_rm_utils_read_tags: comment =
0:00:05.198949058 6904 0F7AEA08 DEBUG GST_MEMORY gstmemory.c:87:_gst_memory_free: free memory 005683F0
0:00:05.199001698 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2350:gst_base_src_update_length:`<source>` reading offset 178576568, length 10, size 178754120, segment.stop -1, maxsize 178754120
0:00:05.199054999 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2451:gst_base_src_get_range:`<source>` calling create offset 178576568 length 10, time 0
0:00:05.199105653 6904 0F7AEA08 DEBUG GST_MEMORY gstmemory.c:138:gst_memory_init: new memory 0F7EC500, maxsize:13 offset:0 size:10
0:00:05.199173191 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2305:gst_base_src_do_sync:`<source>` we have no clock
0:00:05.199224506 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2515:gst_base_src_get_range:`<source>` buffer ok
0:00:05.199275822 6904 0F7AEA08 WARN rmdemux rmdemux.c:1039:gst_rmdemux_chain:`<rmdemux0>` Bogus looking header, unprintable FOURCC
0:00:05.199327800 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2350:gst_base_src_update_length:`<source>` reading offset 178576568, length 10, size 178754120, segment.stop -1, maxsize 178754120
0:00:05.199381102 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2451:gst_base_src_get_range:`<source>` calling create offset 178576568 length 10, time 0
0:00:05.199475787 6904 0F7AEA08 DEBUG GST_MEMORY gstmemory.c:138:gst_memory_init: new memory 0F7EC4A0, maxsize:13 offset:0 size:10
0:00:05.199536372 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2305:gst_base_src_do_sync:`<source>` we have no clock
0:00:05.199586695 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2515:gst_base_src_get_range:`<source>` buffer ok
0:00:05.199635362 6904 0F7AEA08 DEBUG GST_PERFORMANCE gstadapter.c:502:gst_adapter_map: copy remaining 10 bytes from adapter
0:00:05.199684691 6904 0F7AEA08 DEBUG adapter gstadapter.c:296:copy_into_unchecked: bsize 10, skip 4, csize 6
0:00:05.199736338 6904 0F7AEA08 WARN rmdemux rmdemux.c:1039:gst_rmdemux_chain:`<rmdemux0>` Bogus looking header, unprintable FOURCC
0:00:05.199784673 6904 0F7AEA08 DEBUG GST_PERFORMANCE gstadapter.c:502:gst_adapter_map: copy remaining 10 bytes from adapter
0:00:05.199833340 6904 0F7AEA08 DEBUG adapter gstadapter.c:296:copy_into_unchecked: bsize 10, skip 8, csize 2
0:00:05.199883994 6904 0F7AEA08 WARN rmdemux rmdemux.c:1039:gst_rmdemux_chain:`<rmdemux0>` Bogus looking header, unprintable FOURCC
0:00:05.199931999 6904 0F7AEA08 DEBUG GST_MEMORY gstmemory.c:87:_gst_memory_free: free memory 0F7EC500
0:00:05.199983645 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2350:gst_base_src_update_length:`<source>` reading offset 178576568, length 10, size 178754120, segment.stop -1, maxsize 178754120
0:00:05.200037278 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2451:gst_base_src_get_range:`<source>` calling create offset 178576568 length 10, time 0
0:00:05.200087932 6904 0F7AEA08 DEBUG GST_MEMORY gstmemory.c:138:gst_memory_init: new memory 0F7EC440, maxsize:13 offset:0 size:10
0:00:05.200147855 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2305:gst_base_src_do_sync:`<source>` we have no clock
0:00:05.200198177 6904 0F7AEA08 DEBUG basesrc gstbasesrc.c:2515:gst_base_src_get_range:`<source>` buffer ok
0:00:05.200246844 6904 0F7AEA08 DEBUG GST_PERFORMANCE gstadapter.c:502:gst_adapter_map: copy remaining 10 bytes from adapter
0:00:05.200295511 6904 0F7AEA08 DEBUG adapter gstadapter.c:296:copy_into_unchecked: bsize 10, skip 2, csize 8
0:00:05.200346827 6904 0F7AEA08 WARN rmdemux rmdemux.c:1039:gst_rmdemux_chain:`<rmdemux0>` Bogus looking header, unprintable FOURCC
----
Version: 1.6.0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2725mpeg2dec: fix decoding into hardware-mapped buffers2023-06-27T18:06:23ZBugzilla Migration Usermpeg2dec: fix decoding into hardware-mapped buffers## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#735391)](https://bugzilla.gnome.org/show_bug.cgi?id=735391)**
## Description
Make sure to commit decoded contents into hardware mapped buffers. In some situations, a...## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#735391)](https://bugzilla.gnome.org/show_bug.cgi?id=735391)**
## Description
Make sure to commit decoded contents into hardware mapped buffers. In some situations, and for performance reasons actually, we might not be able to directly write into buffers backed by 3rdparty hardware. So, this means that we need to maintain some temporary surface/buffers and those are what are being exposed through GstVideoMeta info. Then, internally, the implementation may decide to efficiently convert that into a native format instead.
More precisely, VA-API exposes a vaDeriveImage() API but it might not always be efficient to directly expose GPU memory buffers. So, a temporary surface suitable for CPU interop is being exposed instead. This same happens for VDPAU where there is no direct rendering API, so a temporary image is being used and exposed.
In practice, we just need to carefully maintain map/unmap chains. On map, a clean writable memory buffer is being exposed. On unmap, the contents written by the SW decoder is to be committed. Then, if the frame is to be used again (as reference for example), then it can be mapped again, but with read-only flags this time.
### Blocking
* https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/21 (was: [Bug 735360](https://bugzilla.gnome.org/show_bug.cgi?id=735360))https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2704tag: exif: wrong parsing of ISO_SPEED and PHOTOGRAPHIC_SENSITIVITY tags2023-06-23T12:21:49ZBugzilla Migration Usertag: exif: wrong parsing of ISO_SPEED and PHOTOGRAPHIC_SENSITIVITY tags## Submitted by Paulo Neves
**[Link to original bug (#764093)](https://bugzilla.gnome.org/show_bug.cgi?id=764093)**
## Description
Created attachment 324607
A proposed patch.
The comments below take into account the standard ...## Submitted by Paulo Neves
**[Link to original bug (#764093)](https://bugzilla.gnome.org/show_bug.cgi?id=764093)**
## Description
Created attachment 324607
A proposed patch.
The comments below take into account the standard description summary found in
http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html
According to the site above:
0x8827 is ISO or PhotographicSensitivity in EXIF2.3
0x8833 is ISOSpeed (dependent of SensitivityType in ExifISOTag)
According to gstexif.c:
0x8827 is EXIF_TAG_PHOTOGRAPHIC_SENSITIVITY
0x8833 is EXIF_TAG_ISO_SPEED
Then we have following in gstexif.c@373
/* don't need the serializer as we always write the iso speed alone */
{GST_TAG_CAPTURING_ISO_SPEED, EXIF_TAG_PHOTOGRAPHIC_SENSITIVITY,
EXIF_TYPE_SHORT, 0, NULL,
deserialize_add_to_pending_tags},
{GST_TAG_CAPTURING_ISO_SPEED, EXIF_TAG_SENSITIVITY_TYPE, EXIF_TYPE_SHORT, 0,
serialize_sensitivity_type, deserialize_sensitivity_type},
{GST_TAG_CAPTURING_ISO_SPEED, EXIF_TAG_ISO_SPEED, EXIF_TYPE_LONG, 0, NULL,
NULL},
Which means that EXIF_TAG_PHOTOGRAPHIC_SENSITIVITY will have deferred parsing depending on the EXIF_TAG_SENSITIVITY_TYPE which is wrong as seen from the relation established before in the site.
Instead, the Tag dependent on EXIF_TAG_SENSITIVITY_TYPE should be EXIF_TAG_ISO_SPEED which is not happening.
This creates a bug that results in the ISO parameter never being parsed. A scenario where this happens is if Sensitivity Type is different than 3 (ISO Speed) and instead is 2 (Recommended Exposure Index). What will happen is that no EXIF_TAG_ISO_SPEED (0X8833) will exist because the type is 2 and the deferred EXIF_TAG_PHOTOGRAPHIC_SENSITIVITY (0x8827) was discarded in the SensitivityType parsing because type is different than 3. No more ISO information can be retrieved from the file.
So assuming we now correctly make the EXIF_TAG_ISO_SPEED dependent on the EXIF_TAG_SENSITIVITY_TYPE and leave the EXIF_TAG_PHOTOGRAPHIC_SENSITIVITY correctly represent the GST_TAG_CAPTURING_ISO_SPEED the problem outlined before does not happen because a standard compliant exif field will not even have EXIF_TAG_ISO_SPEED if the EXIF_TAG_SENSITIVITY_TYPE is different than 3. For the example above where the EXIF_TAG_SENSITIVITY_TYPE is 2, the exif will have a RecommendedExposureIndex (0x8832) tag which is currently not handled. The EXIF_TAG_PHOTOGRAPHIC_SENSITIVITY would then be parseable and not dependent on anything.
The problem is that EXIF_TAG_PHOTOGRAPHIC_SENSITIVITY is of size type EXIF_TYPE_SHORT which for a reason I do not understand does not have a function that parses shorts like parse_exif_`<type>`_tag. This happens with other types. I propose thus the following:
static void parse_exif_short_tag(GstExifReader * reader, const GstExifTagMatch tag, guint32 count, guint32 offset, const guint8 * offset_as_data)
This way in gstexif.c@parse_exif_long_tag we can parse EXIF_TYPE_SHORTs.
With everything together the problem is solved on my side.
I attach a proposed patch.
Hoping I was clear and thankful for Gstreamer
Paulo Neves
~~**Patch 324607**~~, "A proposed patch.":
[ISO_tag.patch](/uploads/610d2a895d79718c110f829dfded76ab/ISO_tag.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2693asfdemux: add support for trick play in push mode2023-06-20T17:14:05ZBugzilla Migration Userasfdemux: add support for trick play in push mode## Submitted by Rajesh Singh
**[Link to original bug (#749956)](https://bugzilla.gnome.org/show_bug.cgi?id=749956)**
## Description
Current implementation of ASFDemux, does not support the push mode Trick Play.
Trick Play means Fo...## Submitted by Rajesh Singh
**[Link to original bug (#749956)](https://bugzilla.gnome.org/show_bug.cgi?id=749956)**
## Description
Current implementation of ASFDemux, does not support the push mode Trick Play.
Trick Play means Forward(1/2X, 2X, 4X) and Rewind (-1/2X, -2X, -4X).
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2692asfdemux: Seeking close to duration not working2023-06-20T16:33:55ZBugzilla Migration Userasfdemux: Seeking close to duration not working## Submitted by Nirmal Palanisamy
**[Link to original bug (#789710)](https://bugzilla.gnome.org/show_bug.cgi?id=789710)**
## Description
When we seek close to file duration, playback exits immediately for the attached stream. Playba...## Submitted by Nirmal Palanisamy
**[Link to original bug (#789710)](https://bugzilla.gnome.org/show_bug.cgi?id=789710)**
## Description
When we seek close to file duration, playback exits immediately for the attached stream. Playback is not continuing from the seek position.
Attached stream duration is 50 sec. When seek is issued between 42 to 46 sec, playback ends immediately. Ideally playback should continue from 42 to 46 sec after seek operation.
Version: 1.12.0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2689tags: better metadata / tag editing API2023-06-20T16:15:00ZBugzilla Migration Usertags: better metadata / tag editing API## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#613320)](https://bugzilla.gnome.org/show_bug.cgi?id=613320)**
## Description
GStreamer has no easy to use and efficient api for metadata editing of files. These are th...## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#613320)](https://bugzilla.gnome.org/show_bug.cgi?id=613320)**
## Description
GStreamer has no easy to use and efficient api for metadata editing of files. These are the usecases which are not well supported:
- add new metadata to a file (tagging)
- changing existing metadata in a file (editing)
- strippping some (or all) metadata from a file (privacy filter)
In-place editing would be fast (no need to rewrite long files), but difficult to achieve with gstreamer and would only cover striping and a subset of editing (new size <= old size).
The classic way would be to do
filesrc location=a.mp4 ! mp4demux name=d ! queue ! mp4mux name=m ! filesink location=b.mp4
with extra .d ! queue ! .m for each stream. This is cumbersome as one would need to filter/process the tag-events either on each stream or via tagSetter on the muxer.
Thus we would like to have remux elements that have same in/out caps. Eventually demuxer code could register remuxers as well and reuse the parsing code. One would run them as below and do an atomic delete and rename upon success.
Adding:
- filesrc location=a.mp4 ! mp4remux tags-add=tags ! filesink location=b.mp4
- tags is GstTagList of tags to add
- go to playing
- wait for eos
Editing:
- tagreadbin uri=file://a.mp4
- wait for tags
- edit values
- filesrc location=a.mp4 ! mp4remux tags=tags ! filesink location=b.mp4
- tags is GstTagList of tags to set
- go to playing
- wait for eos
Filtering:
- filesrc location=a.mp4 ! mp4remux tags-remove=tags ! filesink location=b.mp4
- tags is GList of tags to supress
- go to playing
- wait for eos
One alternative would be also to always supply tags-old=tags1 and tags-new=tags2 - both GstTagLists.
Problems:
- Remux elements would need to buffer the whole file in memory until they get to a point where no further metadata is in the file. Then the size corrected headers followed by the data can be written. Trailing buffers can be pushed as they are.
Does this sound doable? Does it stretch what GStreamer is covering too much?
One alternative would be to have a tageditbin, that does the classic pipeline, but manages the internals.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2667Delayed linking fails when requesting non NV12 colorspaces from decodebin2023-06-13T18:00:28ZBugzilla Migration UserDelayed linking fails when requesting non NV12 colorspaces from decodebin## Submitted by Florent Thiery `@florent.thiery`
**[Link to original bug (#772457)](https://bugzilla.gnome.org/show_bug.cgi?id=772457)**
## Description
The following pipeline crashes (Internal data stream error):
gst-launch-1.0...## Submitted by Florent Thiery `@florent.thiery`
**[Link to original bug (#772457)](https://bugzilla.gnome.org/show_bug.cgi?id=772457)**
## Description
The following pipeline crashes (Internal data stream error):
gst-launch-1.0 filesrc location=bbb-1920-1080-30.mp4 num-buffers=180 ! decodebin ! videoscale ! video/x-raw\,\ format\=\(string\)I420\,\ width\=\(int\)1920\,\ height\=\(int\)1080\,\ framerate\=\(fraction\)30/1 ! filesink location=samples/tmp.raw
WARNING: from element /GstPipeline:pipeline0/GstDecodeBin:decodebin0: Delayed linking failed.
ERROR: from element /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstQTDemux:qtdemux0: Internal data stream error.
Sample: http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_1080p_30fps_normal.mp4
This didn't fail on 1.8.3, and i checked that it does not happen when vaapi is not present.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2659typefinding: mis-detects true type font file as mp32023-06-12T11:53:47ZBugzilla Migration Usertypefinding: mis-detects true type font file as mp3## Submitted by gno..@..il.com
**[Link to original bug (#732923)](https://bugzilla.gnome.org/show_bug.cgi?id=732923)**
## Description
Created attachment 280191
Rhythmbox window showing TTF files as valid audio tracks.
TTF fon...## Submitted by gno..@..il.com
**[Link to original bug (#732923)](https://bugzilla.gnome.org/show_bug.cgi?id=732923)**
## Description
Created attachment 280191
Rhythmbox window showing TTF files as valid audio tracks.
TTF font file is reported as "audio/mpeg" as shown below:
sid@unstable:~/work/gstreamer$ gst-typefind-1.0 /usr/share/fonts/truetype/fonts-japanese-gothic.ttf
/usr/share/fonts/truetype/fonts-japanese-gothic.ttf - audio/mpeg, mpegversion=(int)1, layer=(int)1, parsed=(boolean)false
GstDiscoverer library also returned "audio/mpeg"
More information on the file:
sid@unstable:~$ ls -l /usr/share/fonts/truetype/fonts-japanese-gothic.ttf
lrwxrwxrwx 1 root root 43 Jul 7 13:11 /usr/share/fonts/truetype/fonts-japanese-gothic.ttf -> /etc/alternatives/fonts-japanese-gothic.ttf
sid@unstable:~$ ls -l /etc/alternatives/fonts-japanese-gothic.ttf
lrwxrwxrwx 1 root root 53 Jul 7 13:11 /etc/alternatives/fonts-japanese-gothic.ttf -> /usr/share/fonts/opentype/ipaexfont-gothic/ipaexg.ttf
sid@unstable:~$ dpkg -S /usr/share/fonts/opentype/ipaexfont-gothic/ipaexg.ttf
fonts-ipaexfont-gothic: /usr/share/fonts/opentype/ipaexfont-gothic/ipaexg.ttf
Due to this, rhythmbox imports incorrect files ( refer attachment )
**Attachment 280191**, "Rhythmbox window showing TTF files as valid audio tracks.":
![Rhythmbox-GST-bug](/uploads/0ef4a088193d3763160a5ce127e23dd2/Rhythmbox-GST-bug.png)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2655uridecodebin: Add properties and documentation for better control over buffering2023-08-03T12:52:05ZBugzilla Migration Useruridecodebin: Add properties and documentation for better control over buffering## Submitted by Carlos Rafael Giani
**[Link to original bug (#762125)](https://bugzilla.gnome.org/show_bug.cgi?id=762125)**
## Description
Created attachment 321347
uridecodebin patch for enhanced buffering control
Currently,...## Submitted by Carlos Rafael Giani
**[Link to original bug (#762125)](https://bugzilla.gnome.org/show_bug.cgi?id=762125)**
## Description
Created attachment 321347
uridecodebin patch for enhanced buffering control
Currently, there are only two properties for controlling the buffering: buffer-size and buffer-duration. Properties for the low/high percentage thresholds are missing. Also, the default value for buffer-size and buffer-duration is -1, which means "automatic/default". It is not obvious what this exactly means, and relies on hardcoded internal values.
Furthermore, buffer-duration conflates two distinct concepts: its value is used both for bitrate-based and for input data rate based buffer size estimation. As a result, a buffer-duration value of for example 5 seconds can either mean a buffer size of bitrate*5 seconds , or in case of slow connections, in-data-rate*5 seconds, whichever is lower. In many cases, it is desirable to use only one of these two estimations.
The exact way how buffering behaves, how the properties work, and how it should be used is not documented.
This is the first version of a patch that deprecates buffer-size and buffer-duration in favor of three new properties: max-buffer-size, max-buffering-duration, and buffer-estimate-duration.
The new properties work as follows:
* max-buffer-size: The upper limit for the buffer size, in bytes; this value is passed to the internal queue/decodebin as the "max-size-bytes" property; default value is 10 MB
* max-buffering-duration: The in-data-rate*duration estimate mentioned above; this value is passed to the internal queue/decodebin as the "max-size-time" property, but it is *not* used for bitrate based estimations; default value is 0 (= disables data rate based estimates)
* buffer-estimate-duration: The bitrate*duration estimate mentioned above; this value is not passed to the internal queue, and used only if a bitrate tag is encountered; default value is 6.5 seconds
Out of these three, the lowest size (in bytes) is picked.
The patch also makes it possible to set these property during playback; the buffer size will be readjusted on the fly.
Properties for low/high percentage are also introduced. Default values are: low 5%, high 5%. Together with the default values for the other three properties, this means buffering messages will reach 100% once 1.5 seconds are buffered. During playback, if the source can deliver data faster than realtime, additional 5 second can be buffered on the fly. This makes streaming playback more robust against network bandwidth drops without having to let the user wait too long for buffering to finish.
gtkdoc documentation for how to use these new properties and how configuring buffer size works is also added.
Also, a new "will-post-buffering" signal is added. This is emitted whenever uridecodebin sets the "use-buffering" property of an internal queue to TRUE. This is useful for applications to let them know that they should *not* switch to PLAYING just yet, because buffering messages *will* be posted soon. This prevents the possibility that the PLAYING state is reached, playback goes on briefly, and then the application receives the first BUFFERING message, and pauses playback again.
In subsequent patches, playbin could also get these new properties (they'd be forwarded to uridecodebin just like buffer-size and buffer-duration are now), and the new signal. Another planned addition is a "current-buffer-level" property; however, this first requires a patch for multiqueue, since it doesn't have any property like that (queue2 does have "current-level-bytes"). Also, several parsers such as flacparse, wavparse, aiffparse have been found to not push bitrate tags downstream, and therefore also require patching to further improve buffering behavior.
**Patch 321347**, "uridecodebin patch for enhanced buffering control":
[0001-uridecodebin-Add-properties-and-signals-for-better-c.patch](/uploads/dab7fd226cd0303c015cf427dd222271/0001-uridecodebin-Add-properties-and-signals-for-better-c.patch)Edward HerveyEdward Herveyhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2654uridecodebin3: Disabling byte limite (and just have time limit)2023-06-09T08:39:46ZBugzilla Migration Useruridecodebin3: Disabling byte limite (and just have time limit)## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#733308)](https://bugzilla.gnome.org/show_bug.cgi?id=733308)**
## Description
Currently there's no way in decodebin to disable one buffering limit (or both). In my ca...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#733308)](https://bugzilla.gnome.org/show_bug.cgi?id=733308)**
## Description
Currently there's no way in decodebin to disable one buffering limit (or both). In my case I just want to have a time based limit, no byte based one.