gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2022-11-10T09:20:44Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/66queue2: Process SEEKING query2022-11-10T09:20:44ZBugzilla Migration Userqueue2: Process SEEKING query## Submitted by Jan Alexander Steffens `@heftig`
**[Link to original bug (#733351)](https://bugzilla.gnome.org/show_bug.cgi?id=733351)**
## Description
Created attachment 281085
patch
In order to seek FLV streams, flvdemux cr...## Submitted by Jan Alexander Steffens `@heftig`
**[Link to original bug (#733351)](https://bugzilla.gnome.org/show_bug.cgi?id=733351)**
## Description
Created attachment 281085
patch
In order to seek FLV streams, flvdemux creates a seek index;
however, this index is not created if upstream is not seekable.
gst_flv_demux_check_seekability was copied nearly verbatim from
GstBaseParse.
This commit adds QUERY_SEEKING handling to queue2, so RTMP live
streams become seekable when a queue2 in download or ringbuffer
mode is inserted:
rtmpsrc ! queue2 ! flvdemux
Alternatively, flvdemux could be altered to not require
seekability. I am unsure what is the best approach.
~~**Patch 281085**~~, "patch":
[0001-queue2-Process-SEEKING-query.patch](/uploads/df33bc06c04b65b6738288e18ea70f7c/0001-queue2-Process-SEEKING-query.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/65baseparse: Return FLOW_FLUSHING when pushing a frame on a pad that is flushing2022-11-10T09:20:44ZBugzilla Migration Userbaseparse: Return FLOW_FLUSHING when pushing a frame on a pad that is flushing## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#733320)](https://bugzilla.gnome.org/show_bug.cgi?id=733320)**
## Description
Another solution would be to set a dedictaed flag in PAUSED_TO_READY before linkin...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#733320)](https://bugzilla.gnome.org/show_bug.cgi?id=733320)**
## Description
Another solution would be to set a dedictaed flag in PAUSED_TO_READY before linking
up so we could detect that precise case, but that patch solves the issue and sounds
correct to me.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/64review debugging env vars2023-02-03T20:16:28ZBugzilla Migration Userreview debugging env vars## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#733188)](https://bugzilla.gnome.org/show_bug.cgi?id=733188)**
## Description
Current debug-log env vars
GST_DEBUG_FILE (defaults to stderr)
when not set log t...## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#733188)](https://bugzilla.gnome.org/show_bug.cgi?id=733188)**
## Description
Current debug-log env vars
GST_DEBUG_FILE (defaults to stderr)
when not set log to stderr, when set points to path for the debug log
GST_DEBUG_COLOR_MODE (defaults to color) (deprecated)
when set use ansi color codes, otherwise plain text
GST_DEBUG_NO_COLOR ("on", "auto", "off", "disable", "unix")
on = auto: platform specific color codes
off = disabled: no color codes
unix = force ansi
Proposed env vars
GST_DEBUG_CHANNEL (defaults to stderr)
stderr
fd://stderr, fd://stdout
file:///path/to/file (or /path/to/file , file)
tcp://`<ip>`:`<port>` (or just `<ip>`:`<port>`)
mem://`<size>`
Log to the given channel.
Alternative names GST_DEBUG_{STREAM,OUT,METHOD,....}
GST_DEBUG_FORMAT (default to text/auto-color)
text/plain (plain text)
text/auto-color (platform specific color codes)
text/ansi (ansi color coded)
binary/ctf (see babeltrace (Common Trace Format (CTF), e.g. used by lttng)
These could be sort-of mime-types.
We also could discuss if we just want to have one at a time, or even allow multiple pairs. The ater makes it tricky for the variables though.
Another alternative would be to merge CHANNEL+FORMAT as a uri:
GST_DEBUG_OUT=fd://stderr#format=text/plain&option1=value&option2=value
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/63gst_element_state_* functions should read gst_state_*2021-09-24T11:11:20ZBugzilla Migration Usergst_element_state_* functions should read gst_state_*## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#733088)](https://bugzilla.gnome.org/show_bug.cgi?id=733088)**
## Description
It is inconsistent with respects to the rest of the API, it seems more intuitive to me...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#733088)](https://bugzilla.gnome.org/show_bug.cgi?id=733088)**
## Description
It is inconsistent with respects to the rest of the API, it seems more intuitive to me to write gst_state_get_name (GstState state);
That was my nitpick of the day :)
Version: 2.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/62regression in position queries when seeking in READY2021-09-24T11:11:20ZBugzilla Migration Userregression in position queries when seeking in READY## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#733031)](https://bugzilla.gnome.org/show_bug.cgi?id=733031)**
## Description
Something changed in gstreamer to break seek in READY again. The pipeline plays
from the...## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#733031)](https://bugzilla.gnome.org/show_bug.cgi?id=733031)**
## Description
Something changed in gstreamer to break seek in READY again. The pipeline plays
from the right pos, but reports position starting from 0 instead of seek-pos.
Seeking in ready is important for me, when the user want to play from somewhere in the middle and/or wants to play in a loop. If I send the flushing seek in PAUSED it works, but then I preroll twice - once where gstreamer assumes playback will start at 0 (is open ended and not using the segment flag) and once for the actual segment.
I was iterating the pipeline in ready and sending the seek to each source-element (as e.g. bins were dropping the seek as the flags where flushing). Now this is not good anymore. Most likely something change with regard to segment initialization in bins.
Now of course seek-in-ready is not officially supported (maybe). So what can we do instead to actually make that use-case work?
a) I don't tink we can just add a new seek-flag
b) new seek-like event to init the segment?
c) ?
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/60Specify, design and implement a base class for demuxers2021-09-24T11:11:20ZBugzilla Migration UserSpecify, design and implement a base class for demuxers## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#732616)](https://bugzilla.gnome.org/show_bug.cgi?id=732616)**
## Description
I open that bug report so we can gather requirements and design ideas for a base demux...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#732616)](https://bugzilla.gnome.org/show_bug.cgi?id=732616)**
## Description
I open that bug report so we can gather requirements and design ideas for a base demuxer class, hopefully it will end up RESOLVED FIXED :)
I don't have many ideas, only two requirements that I will detail in the following comment.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/59bytereader: SIMD-based optimization to find start code on H.264 and H.265 str...2021-09-24T11:11:21ZBugzilla Migration Userbytereader: SIMD-based optimization to find start code on H.264 and H.265 streams## Submitted by Sungho Bae
**[Link to original bug (#730783)](https://bugzilla.gnome.org/show_bug.cgi?id=730783)**
## Description
Created attachment 277253
001_gstbytereader_neon_improvement_patch
In the parse phase for video...## Submitted by Sungho Bae
**[Link to original bug (#730783)](https://bugzilla.gnome.org/show_bug.cgi?id=730783)**
## Description
Created attachment 277253
001_gstbytereader_neon_improvement_patch
In the parse phase for video streams, bytescanning is performed to find the start and end of each NAL unit. This implementation is to improve the performance of bytescanning for start code using both ARM NEON instructions and pointer access instead of indexed access.
The advantages are to reduce CPU usage and to enhance the scanning performance.
This patch assumes that '0x0000' is unlikely to appear and the zeros are part of the start code, that is, '0x010000'.
Our proposed idea is based on the assumption.
If we quickly know whether or not there exists '0x0000' in the scanning area to find the start code, we can skip the scanning process for the start code.
We thus implemented the preprocessing to know whether or not there exists '0x0000'.
Because the probability of zeros to appear is low, its performance dramatically improved.
~~**Patch 277253**~~, "001_gstbytereader_neon_improvement_patch":
[001_bytereader_improve_v1.0_baver.bae.patch](/uploads/bee61bab7bf965d77351d3c59ae5b818/001_bytereader_improve_v1.0_baver.bae.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/58check: add chain list function on sinkpad2021-09-24T11:11:21ZBugzilla Migration Usercheck: add chain list function on sinkpad## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#730639)](https://bugzilla.gnome.org/show_bug.cgi?id=730639)**
## Description
In order to easily test their "chain_list" code path it would be useful to add a ...## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#730639)](https://bugzilla.gnome.org/show_bug.cgi?id=730639)**
## Description
In order to easily test their "chain_list" code path it would be useful to add a chain_list hook on the test sink pad.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/57failed to parse '%' character in gst_structure_from_string2021-09-24T11:11:21ZBugzilla Migration Userfailed to parse '%' character in gst_structure_from_string## Submitted by Justin Kim `@joykim`
**[Link to original bug (#730181)](https://bugzilla.gnome.org/show_bug.cgi?id=730181)**
## Description
gst_structure_from_string seems not to accept '%' character due to missing define in ASCII_I...## Submitted by Justin Kim `@joykim`
**[Link to original bug (#730181)](https://bugzilla.gnome.org/show_bug.cgi?id=730181)**
## Description
gst_structure_from_string seems not to accept '%' character due to missing define in ASCII_IS_STRING in gst_private.h
Is that omitted on purpose?
154 /* used in gstvalue.c and gststructure.c */
155 #define GST_ASCII_IS_STRING(c) (g_ascii_isalnum((c)) || ((c) == '_') || \
156 ((c) == '-') || ((c) == '+') || ((c) == '/') || ((c) == ':') || \
157 ((c) == '.'))https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/56Problem playing a 1 frame mp3 (encoded as a data: URL or from file)2021-09-24T11:11:22ZBugzilla Migration UserProblem playing a 1 frame mp3 (encoded as a data: URL or from file)## Submitted by Colin Guthrie
**[Link to original bug (#729625)](https://bugzilla.gnome.org/show_bug.cgi?id=729625)**
## Description
I believe (from speaking to Sebastian) that this is actually two bugs, but I'll explain below.
...## Submitted by Colin Guthrie
**[Link to original bug (#729625)](https://bugzilla.gnome.org/show_bug.cgi?id=729625)**
## Description
I believe (from speaking to Sebastian) that this is actually two bugs, but I'll explain below.
Background: The nuvolaplayer (https://nuvolaplayer.fenryxo.cz) uses GStreamer to provide HTML5 support for Google Music. This avoids the need for using the Flash plugin to play the audio content, and we'd all like to see less use of Flash I'm sure!
The problem comes when the Google side does a test to see if the HTML5 support is functional. It does this by playing a silent, one-frame mp3 encoded as a data: url in base64. With GStreamer, this fails and thus HTML5 support is not enabled and Google Music thus falls back to Flash (ugg).
Here is a test pipleline:
gst-launch-1.0 playbin uri="data:audio/mpeg;base64,//vgZAAACZ2B1FVl4ACUEFrIoJgAagonULndgAK2RKx7FtAAAAC4AABKIwQSyZbdAOkWy+AgQUbTx98nvic7ZnhsfTkLYFxFcD/Q801XIhhoE4NAnZO0eTAOAA0AFARhOg2AVAuBoIYrFYyPL+jx5ElP8nYmgagHIEgEMLgyUgP37Gr0PQ80y3k7HoHoHoIQTg6FAyRLsZzlvJ2TsuZpqNDEMUCsZHkSkNWQS/i3ibi5mW+OQesXMhZczTQ9D1e/iU1ljT6jfEoBzhIyXu2BDEMQxDDTOtD0PV6vfx8J9R2PwWwHIDkFgcS2EILgaBoHQhiseR77gKw5DQUEFgVjJEyxoeW8uY9A9BCCcE4JwXA0DoOtD0PQ85zTJ2XM61ArFYyPKe7948pSlKfNNXhv7+A8V6vV6vV6vV6fUaGIYhiGIYrEMQxDDTNM0zrQ9D1ezv3jx48eRKAGAAAAxjGMb3AAAFHEREREZv//92QIRH/////92QjO99ou7u7smmQIEIiIMIAMBhZMmTu7iIiIiIu73xERd3e////xEZ4iIiP/////+0RH////e7uIiIiIi7JkyZMmTuIiIiP4//7QQAYDJkyZMmTJkCBAghERBNO98REXd3d3dxEGECCGOQQiIiCBAmTJkyZMmns4AwAIABg6IximJldpt0cA4xxL4z2OorDYw8rYFBiZEuAGTMYJAaYXiIkqapA4CgXMBEjCwKrh/tPQaMVJN/M/ugNtwzOgZQZnRnnEZ2A/5mPGBnTvtxLcmFDYFbjVgv88QauGkjf3fMBCg1nQ8QmlpU6aBNt/tf+4KSb//m09DIgQyQHfQuclSg6oKIHoBKbrc1/mEoAtPUfP/5aZofFmqthwn1dkQCFYzM5v///ocLKplR9j//uYFSAyUKQ2fqtTRqYCosHFta2CiCK9//jIFGygZ/yaEkPf/4JGDtnf8aS4S7lTmNg5eFTWVS54X2S3EAIwFYv/pPQx4C5///XBGkCV//+lWYyC5f//mjoHFNXrXcqGDR0HRySGaSxGBePSletpQIustFFVCT///////3cFqEwXh//+hIUbH///////////yYYFFrb///IWEnK6AAAAABAAAAAAChLqAAkbf5sLM9YLgmjtHGW4DOAB96S2/F4xpBxGWHCY6JiXUxMOYCjxcHqPYxLprt6vw2Aph7DiJEeo9SWE6+FGXG9YBvHq0VGQW+C2t6y7CdN8Ygna0dahPzBE1Ft9YmqeS35IEPRU5mNJeJIxHqPUyNw4przUT5/kV282GFf5FHo9SKKI7BuSzJFEQ5ID2HsYl01//YXDb6x8Pf//mxA/JEopiCmopmXHJyXGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=="
It produces:
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind: Could not determine type of stream.
Additional debug info:
gsttypefindelement.c(1067): gst_type_find_element_loop (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
Enabling debugging I can make a few observations:
The dataurisrc seems to correctly extract the mime type from the URL and properly decode the payload. Good start.
When the type find system kicks in, it does not see that some caps are set and still tries to determine the type of the stream by parsing an extension out of the URL. With data: URLs this is really not a nice idea.
I tried a hideous hack >:) to make dataurisrc "fake" the URL provided to the rest of the system (i.e. I replaced it with "file:///fake-uri.mp3"). This allowed things to get further, but type find still failed to detect the type of the stream. I presume this is because it was simply too short.
To confirm this last theory, I took the base64 data, passed it through base64 -d and piped it to a file mp3.mp3 and tried a simple playbin pipeline, avoiding the dataurisrc completely. It still failed with the same error as above:
gst-launch-1.0 playbin uri=file://`pwd`/mp3.mp3
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind: Could not determine type of stream.
Additional debug info:
gsttypefindelement.c(1067): gst_type_find_element_loop (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
However, specifying the pipeline manually (to avoid typefind) works fine:
gst-launch-1.0 filesrc location=mp3.mp3 ! mpeg2dec ! autoaudiosink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.000087481
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
For reference, vlc (I think), mplayer and mpg123 play the file fine, although mpg123 does print out an amusing:
[parse.c:1007] warning: Cannot read next header, a one-frame stream? Duh...
:)
I spoke privately to Sebastian about this before reporting the bug. I had hoped that it was just that the dataurisrc's caps were not being trusted by the core when in pull mode and thus the typefind kicked in, but he corrected me saying that the mime type was not sufficient on it's own anyway. The fact that I could make it fail without the dataurisrc makes me confident he's correct, but I'm fairly certainly that you would want to avoid trying to extract a file extension from a data: uri anyway (hence why I think this is actually two bugs).
This was reported a long time ago in Launchpad for Ubuntu but I see no progress and no actual upstream report which is pretty weird (why did no one report this upstream yet? That said, I did find a potential duplicate... from 2006, but Tim says it's fixed ;) [bug 153004](https://bugzilla.gnome.org/show_bug.cgi?id=153004) this fix may have been lost over the years I guess)
Anyway, Launchpad bug:
https://bugs.launchpad.net/ubuntu/+source/gstreamer1.0/+bug/1204672
Version: 1.2.2https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/55Core could be more helpful with respect to event ordering2021-09-24T11:11:22ZBugzilla Migration UserCore could be more helpful with respect to event ordering## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#728138)](https://bugzilla.gnome.org/show_bug.cgi?id=728138)**
## Description
A precise sequence of events need to be sent before starting data flow. There's alread...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#728138)](https://bugzilla.gnome.org/show_bug.cgi?id=728138)**
## Description
A precise sequence of events need to be sent before starting data flow. There's already code that ensures ordering, could gst instead of throwing warnings and errors when the ordering is not respected provide vmethods in GstElement for handling that ?
ie we can find send_caps, send_stream_start and send_segment boolean fields variations in multiple element methods (videomixer / adder are the ones that come to mind), would be nice to delegate that to GstElement and have vmethods such as get_stream_id, get_segment etc ..
I have no API proposal, just starting the discussion :)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/54baseparse: Misplaced negative playback rate handling code when pushing frames2021-09-24T11:11:22ZBugzilla Migration Userbaseparse: Misplaced negative playback rate handling code when pushing frames## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#727767)](https://bugzilla.gnome.org/show_bug.cgi?id=727767)**
## Description
As found by Coverity, some code in baseparse is unreachable:
ret = gst_base_...## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#727767)](https://bugzilla.gnome.org/show_bug.cgi?id=727767)**
## Description
As found by Coverity, some code in baseparse is unreachable:
ret = gst_base_parse_scan_frame (parse, klass);
if (ret != GST_FLOW_OK)
goto done;
/* eat expected eos signalling past segment in reverse playback */
if (parse->segment.rate < 0.0 && ret == GST_FLOW_EOS &&
parse->segment.position >= parse->segment.stop) {
GST_DEBUG_OBJECT (parse, "downstream has reached end of segment");
Looking back at the history, the ret tested by the EOS condition was not what _scan_frame returned: there was an intervening call to gst_base_parse_handle_and_push_frame:
- ret = gst_base_parse_scan_frame (parse, klass, &frame, TRUE);
+ ret = gst_base_parse_scan_frame (parse, klass, TRUE);
if (ret != GST_FLOW_OK)
goto done;
- /* This always cleans up frame, even if error occurs */
- ret = gst_base_parse_handle_and_push_frame (parse, klass, &frame);
-
/* eat expected eos signalling past segment in reverse playback */
if (parse->segment.rate < 0.0 && ret == GST_FLOW_EOS &&
parse->segment.position >= parse->segment.stop) {
GST_DEBUG_OBJECT (parse, "downstream has reached end of segment");
This removal was done in b761f5479a2ca977c07d70be39f1f0eb764b034e. It's not quite clear to me where this EOS code should be moved. The current implementation of gst_base_parse_handle_and_push_frame is the only place where gst_base_parse_handle_and_push_frame is called, but only one of the calls in the original version had this test/code. Moreover, a comment for gst_base_parse_finish_frame mentions the return value of gst_base_parse_handle_and_push_frame should be returned to the caller's caller, but the negative rate check resets the return if taken, which may have side effects.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/53gstreamer: non writable output buffer in do_transform_frame2021-09-24T11:11:23ZBugzilla Migration Usergstreamer: non writable output buffer in do_transform_frame## Submitted by ticapix
**[Link to original bug (#727702)](https://bugzilla.gnome.org/show_bug.cgi?id=727702)**
## Description
Hi,
I have a issue with Gstreamer 1.0 using the GstVideo.VideoFilter class.
The buffer of the o...## Submitted by ticapix
**[Link to original bug (#727702)](https://bugzilla.gnome.org/show_bug.cgi?id=727702)**
## Description
Hi,
I have a issue with Gstreamer 1.0 using the GstVideo.VideoFilter class.
The buffer of the outframe is not writable.
How data is supposed to be written back on the frame ?
(afaiu, do_tranform_frame_ip should not be used to modify buffer, but only to do read-only operation, right ?)
Sample code attached, used with python2
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/52Gstbaseparse: why need report error if no valid frame before EOS?2022-11-10T09:20:44ZBugzilla Migration UserGstbaseparse: why need report error if no valid frame before EOS?## Submitted by kevin
**[Link to original bug (#726956)](https://bugzilla.gnome.org/show_bug.cgi?id=726956)**
## Description
Why need report error if no valid frame before EOS? We have one test stream which have audio track. But hav...## Submitted by kevin
**[Link to original bug (#726956)](https://bugzilla.gnome.org/show_bug.cgi?id=726956)**
## Description
Why need report error if no valid frame before EOS? We have one test stream which have audio track. But haven't any valid AC3 data in it. Application got error and stopped playback. Below is the source code in gstbaseparse.c
/* If we STILL have zero frames processed, fire an error */
if (parse->priv->framecount == 0) {
GST_ELEMENT_ERROR (parse, STREAM, WRONG_TYPE,
("No valid frames found before end of stream"), (NULL));
}
Version: 1.2.3https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/51[API] Need a way to set per pipeline/bin/element policies2022-11-10T09:20:44ZBugzilla Migration User[API] Need a way to set per pipeline/bin/element policies## Submitted by Nicola `@drakkan`
**[Link to original bug (#726381)](https://bugzilla.gnome.org/show_bug.cgi?id=726381)**
## Description
avdec_h264 has more latency than ffdec_h264, please test with these pipelines:
server (use...## Submitted by Nicola `@drakkan`
**[Link to original bug (#726381)](https://bugzilla.gnome.org/show_bug.cgi?id=726381)**
## Description
avdec_h264 has more latency than ffdec_h264, please test with these pipelines:
server (use 0.10 since gdppay is a bit broken in 1.0):
gst-launch-0.10 v4l2src ! x264enc tune=zerolatency ! gdppay ! tcpserversink host=127.0.0.1 port=3000 sync-method=2
client 1.0:
gst-launch-1.0 -v tcpclientsrc host=127.0.0.1 port=3000 ! gdpdepay ! fakesink sync=false silent=false
client 0.10:
gst-launch-0.10 -v tcpclientsrc host=127.0.0.1 port=3000 ! gdpdepay ! fakesink sync=false
stop the server or kill both clients at the same time (kill -9 `<pid1>` `<pid2>`), they will print exactly the same timestamp, for example:
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (8576 bytes, dts: 0:00:00.000000000, pts: 0:00:34.139030609, duration: 0:00:00.033333333, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7f43240069a0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (8576 bytes, timestamp: 0:00:34.139030609, duration: 0:00:00.033333333, offset: -1, offset_end: -1, flags: 8192 ) 0x7fa300002bf0"
now change the client pipelines
client 1.0:
gst-launch-1.0 -v tcpclientsrc host=127.0.0.1 port=3000 ! gdpdepay ! avdec_h264 ! fakesink sync=false silent=false
client 0.10:
gst-launch-0.10 -v tcpclientsrc host=127.0.0.1 port=3000 ! gdpdepay ! ffdec_h264 ! fakesink sync=false
stop the server or kill the clients, you see the delay:
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (1382400 bytes, dts: 0:00:39.664793944, pts: 0:00:39.664793944, duration: 0:00:00.033333333, offset: -1, offset_end: -1, flags: 00004000 in-caps ) 0x7f8b50cf2740
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (1382400 bytes, timestamp: 0:00:39.896504848, duration: 0:00:00.033333333, offset: -1, offset_end: -1, flags: 256 delta_unit ) 0x7fcd94002dc0"
so 1.0 has about 250 milliseconds delay more than 0.10 (I observed 0.5 second too)
version used:
gstreamer 1.2.3
gstreamer 0.10.36https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/50element: add function to sync element state with target state of the parent2022-11-10T09:20:44ZBugzilla Migration Userelement: add function to sync element state with target state of the parent## Submitted by Miguel París Díaz `@mparisdiaz`
**[Link to original bug (#722767)](https://bugzilla.gnome.org/show_bug.cgi?id=722767)**
## Description
I suggest adding a function to set the element state to the target state of its p...## Submitted by Miguel París Díaz `@mparisdiaz`
**[Link to original bug (#722767)](https://bugzilla.gnome.org/show_bug.cgi?id=722767)**
## Description
I suggest adding a function to set the element state to the target state of its parent. This is useful for avoiding race condition problems in dynamic pipelines.
gboolean
gst_element_sync_target_state_with_parent (GstElement * element)
{
GstElement *parent;
GstState target;
GstStateChangeReturn ret;
g_return_val_if_fail (GST_IS_ELEMENT (element), FALSE);
parent = GST_ELEMENT_CAST (gst_element_get_parent (element));
if (element == NULL) {
GST_DEBUG_OBJECT (element, "element has no parent");
return FALSE;
}
GST_OBJECT_LOCK (parent);
target = GST_STATE_TARGET (parent);
GST_OBJECT_UNLOCK (parent);
GST_DEBUG_OBJECT (element,
"setting parent (%s) target state %s",
GST_ELEMENT_NAME (parent),
gst_element_state_get_name (target));
gst_object_unref (parent);
ret = gst_element_set_state (element, target);
if (ret == GST_STATE_CHANGE_FAILURE) {
GST_DEBUG_OBJECT (element,
"setting target state failed (%s)",
gst_element_state_change_return_get_name (ret));
return FALSE;
}
return TRUE;
}
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/48typefind does not find the correct media type for mpg with http streaming2022-11-10T09:20:44ZBugzilla Migration Usertypefind does not find the correct media type for mpg with http streaming## Submitted by satish kumar
**[Link to original bug (#721676)](https://bugzilla.gnome.org/show_bug.cgi?id=721676)**
## Description
Created attachment 265502
The patch analyzes the data to find the max probabiltity till the max da...## Submitted by satish kumar
**[Link to original bug (#721676)](https://bugzilla.gnome.org/show_bug.cgi?id=721676)**
## Description
Created attachment 265502
The patch analyzes the data to find the max probabiltity till the max data size is reached.
Sometimes for some mpg streams in http streaming case, only audio is decoded. Video is not displayed. streams has both audio/video content.
Analysis:
The issue is coming from typefind element. In this, minimum data size required for parsing is set to 2048 bytes and max as 128*1024.
Failing case: in this case, httpsrc (soup) source gives 2625 bytes to typefind as first buffer. This buffer is used for parsing to find the suitable data type for further auto plugging. For this size, five consecutive frames of mp3 are found. So typefind declares it as mpeg/audio with probability 99. This is maximum for current case. Hence only audio pipeline is created and so no video at all.
Passing case: when this passes ( showing video/audio both) then httpsrc(soup) gives 1165 bytes which are less than min size( 2048) so they are stored and soup again gives 4096 bytes which makes a total of 5261 bytes to typefind. With this data length video/mpeg-sys with probability 100 is declared as typefind output. This causes further auto plugging of demuxer and audio/video decoding path. Hence working fine.
These figures are based on some logs and may vary for different run case, but the issue should remain same. Main issue is that when some format is found then it does not check for case where some other format might be found with more probability if some more data is used for parsing.
Also proposed a patch to fix the issue.
~~**Patch 265502**~~, "The patch analyzes the data to find the max probabiltity till the max data size is reached. ":
[0001-typefind-find-media-type-in-typefind-with-maximum-pr.patch](/uploads/0e550990d65a9e2164d88f1ca5473fa2/0001-typefind-find-media-type-in-typefind-with-maximum-pr.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/47pad: Add API to wakeup pad blocks2022-11-10T09:20:44ZBugzilla Migration Userpad: Add API to wakeup pad blocks## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#721548)](https://bugzilla.gnome.org/show_bug.cgi?id=721548)**
## Description
+++ This bug was initially created as a clone of [Bug 721289](https://bugzilla.gnome.org...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#721548)](https://bugzilla.gnome.org/show_bug.cgi?id=721548)**
## Description
+++ This bug was initially created as a clone of [Bug 721289](https://bugzilla.gnome.org/show_bug.cgi?id=721289) +++
See the original bug for a use case. API should probably be something like
void gst_pad_unblock(pad, probe_return);
Which then broadcasts the GCond and stores the probe_return somewhere. What should then happen is:
a) PROBE_OK
- Run all probes another time
b) PROBE_PASS
- Do as if one of the probes had returned PASS
c) PROBE_DROP
- Do as if one of the probes had returned DROP
d) PROBE_REMOVE
- Nothinghttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/46[PATCH] RFC: additional toc api to represent edit lists and loops2022-06-07T11:23:37ZBugzilla Migration User[PATCH] RFC: additional toc api to represent edit lists and loops## Submitted by Stefan Kost `@ensonic`
Assigned to **Stefan Kost `@ensonic`**
**[Link to original bug (#721362)](https://bugzilla.gnome.org/show_bug.cgi?id=721362)**
## Description
GstTocEntries can be sequence types for chapters/...## Submitted by Stefan Kost `@ensonic`
Assigned to **Stefan Kost `@ensonic`**
**[Link to original bug (#721362)](https://bugzilla.gnome.org/show_bug.cgi?id=721362)**
## Description
GstTocEntries can be sequence types for chapters/tracks/titles. Right now they only have start/stop times. Having a loop_type and a repeat could would allow to represent all kind of edit-lists.
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/44caps: Add GI friendly variants of make_writable () and copy()2021-11-26T08:24:44ZBugzilla Migration Usercaps: Add GI friendly variants of make_writable () and copy()## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#710407)](https://bugzilla.gnome.org/show_bug.cgi?id=710407)**
## Description
Looks like the Rename to: annotation does not work in this case as the other varia...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#710407)](https://bugzilla.gnome.org/show_bug.cgi?id=710407)**
## Description
Looks like the Rename to: annotation does not work in this case as the other variant
is not introspected at all, what do you suggest?
Another question is, couldn't we make those function not inlined?