GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T14:32:58Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/207[PATCH] New histogram plugin for GRAY8 images2021-09-24T14:32:58ZBugzilla Migration User[PATCH] New histogram plugin for GRAY8 images## Submitted by Dimitrios Katsaros
**[Link to original bug (#744001)](https://bugzilla.gnome.org/show_bug.cgi?id=744001)**
## Description
This patchset creates a new histogram element for calculating histogram
metadata from a vide...## Submitted by Dimitrios Katsaros
**[Link to original bug (#744001)](https://bugzilla.gnome.org/show_bug.cgi?id=744001)**
## Description
This patchset creates a new histogram element for calculating histogram
metadata from a video stream. The plugin provides 2 elements:
vhist: An element for extracting histogram data from a stream. It can take
a single parameter, called "binno" for defining the number of bins. This
component calculates the histogram data for the provided image and adds it
to the pipeline using the gstmeta subsystem.
drawhist: A visualizer of the calculated metadata. Requires that metadata
be appended to the stream. The resulting output is a GREY8 image of the
histogram.
To test the plugin, the following pipeline can be used:
gst-launch-1.0 videotestsrc ! vhist binno=5 ! drawhist ! videoconvert ! ximagesink
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/206vc1parser: re-enable BDU parsing for bitstream2021-09-24T14:32:58ZBugzilla Migration Uservc1parser: re-enable BDU parsing for bitstream## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#743948)](https://bugzilla.gnome.org/show_bug.cgi?id=743948)**
## Description
Currently the parser is not able to parse bitstream like in this pipeline: ...## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#743948)](https://bugzilla.gnome.org/show_bug.cgi?id=743948)**
## Description
Currently the parser is not able to parse bitstream like in this pipeline:
gst-launch-1.0 filesrc location=mytestfile.vc1 ! vc1parse ! ..
Since the parser bails out with an error message.
This patch proposes a way re-enable it.
### Blocking
* [Bug 741237](https://bugzilla.gnome.org/show_bug.cgi?id=741237)
* [Bug 764874](https://bugzilla.gnome.org/show_bug.cgi?id=764874)
### See also
* [Bug 707123](https://bugzilla.gnome.org/show_bug.cgi?id=707123)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/205singledecodebin: A convenience element to decode a single stream2021-09-24T14:32:58ZBugzilla Migration Usersingledecodebin: A convenience element to decode a single stream## Submitted by Arun Raghavan `@arun`
**[Link to original bug (#743511)](https://bugzilla.gnome.org/show_bug.cgi?id=743511)**
## Description
This is a fairly simple bin that can be use to decode a single stream using
decodebin, wi...## Submitted by Arun Raghavan `@arun`
**[Link to original bug (#743511)](https://bugzilla.gnome.org/show_bug.cgi?id=743511)**
## Description
This is a fairly simple bin that can be use to decode a single stream using
decodebin, without having to deal with dynamic pads.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/204inter: Add an interappsrc and interappsink element2021-09-24T14:32:57ZBugzilla Migration Userinter: Add an interappsrc and interappsink element## Submitted by Arun Raghavan `@arun`
**[Link to original bug (#743510)](https://bugzilla.gnome.org/show_bug.cgi?id=743510)**
## Description
This element is meant to be used for inter-pipeline communication of non-raw
buffers.## Submitted by Arun Raghavan `@arun`
**[Link to original bug (#743510)](https://bugzilla.gnome.org/show_bug.cgi?id=743510)**
## Description
This element is meant to be used for inter-pipeline communication of non-raw
buffers.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/203vtenc_h264 ignores 'quality' setting2021-09-24T14:32:57ZBugzilla Migration Uservtenc_h264 ignores 'quality' setting## Submitted by Denis
**[Link to original bug (#742757)](https://bugzilla.gnome.org/show_bug.cgi?id=742757)**
## Description
I’ve found an issue in the vtenc.c when the ‘quality’ setting doesn’t get set for the VTCompressionSession ...## Submitted by Denis
**[Link to original bug (#742757)](https://bugzilla.gnome.org/show_bug.cgi?id=742757)**
## Description
I’ve found an issue in the vtenc.c when the ‘quality’ setting doesn’t get set for the VTCompressionSession object because self->session is not yet set within the gst_vtenc_create_session(). The fix is to replace
gst_vtenc_set_quality (self, self->quality);
with
gst_vtenc_session_configure_property_double (self, session,
kVTCompressionPropertyKey_Quality, self->quality);
which will also remove redundant lock on self if gst_vtenc_set_quality is called. Diff file attached.
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/202ksvideosrc, dx9screencapsrc: fix latency handling2021-09-24T14:32:57ZBugzilla Migration Userksvideosrc, dx9screencapsrc: fix latency handling## Submitted by Christoph Rackwitz
**[Link to original bug (#742562)](https://bugzilla.gnome.org/show_bug.cgi?id=742562)**
## Description
when I render from dx9screencapsrc or ksvideosrc, display works but the reporting is switched....## Submitted by Christoph Rackwitz
**[Link to original bug (#742562)](https://bugzilla.gnome.org/show_bug.cgi?id=742562)**
## Description
when I render from dx9screencapsrc or ksvideosrc, display works but the reporting is switched. this also applies to "fps" and "drop rate".
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/200New element to parse Chinese AVS video streams2021-09-24T14:32:56ZBugzilla Migration UserNew element to parse Chinese AVS video streams## Submitted by Aurélien Zanelli
**[Link to original bug (#741868)](https://bugzilla.gnome.org/show_bug.cgi?id=741868)**
## Description
Created attachment 293191
Chinese AVS video extract
I would like to propose a new element...## Submitted by Aurélien Zanelli
**[Link to original bug (#741868)](https://bugzilla.gnome.org/show_bug.cgi?id=741868)**
## Description
Created attachment 293191
Chinese AVS video extract
I would like to propose a new element to parse Chinese AVS video stream, obviously named 'cavsvideoparse' :)
It is built against gst-plugins-bad codecparsers/videoparsers.
Currently, it only knows Jizhun profile, which is the only one supported by libav decoder iirc.
For parse element, I currently use video/x-gst-av-cavs as media type to be compatible with the current one of gst-libav. But I propose to define a shorter media-type like video/x-cavs if you are agree with that.
At this moment, this element is not complete as some features are missing (timestamping...) and still quite simple but it is usable and enables raw AVS byte stream to be played.
For an exemple of use, I attached an extract of AVS video stream which has been cutted quickly with 'dd' and which can be played with the following pipeline:
gst-launch-1.0 filesrc location=test.avs ! cavsvideoparse ! video/x-gst-av-cavs,stream-format=unit-frame ! avdec_cavs ! autovideosink
**Attachment 293191**, "Chinese AVS video extract":
[test.avs](/uploads/c37e9ed2232b73c0766bd107f05fc6f0/test.avs)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/199Proposal for a "framecache" element.2021-09-24T14:32:56ZBugzilla Migration UserProposal for a "framecache" element.## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#741754)](https://bugzilla.gnome.org/show_bug.cgi?id=741754)**
## Description
Filing against -bad because I am realistic :)
Warning:
This proposal assumes...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#741754)](https://bugzilla.gnome.org/show_bug.cgi?id=741754)**
## Description
Filing against -bad because I am realistic :)
Warning:
This proposal assumes correcly behaving elements. It isn't concerned with
closed / open GOP as it deals with already decoded frames.
Problem:
--------
One wants to be able to query "recently" decoded frames from a pipeline without
needing to decode them again.
One wants to be able to scrub forward *and* backward in an "as smooth as
possible" way.
Use cases:
----------
For now, in such a pipeline:
decodebin ! some_filter random_property=X ! sink
if one wants to update random_property in the PAUSED state and
get the same frame updated in the sink, one has to seek flush+accurate.
That's hardly ideal.
In the paused state again, if one wants to step to the next frame,
same deal, flush+accurate, decodebin crunches the same thing over again.
Proposed solution:
------------------
On modern-day workstations, a lot of RAM is readily available.
A full HD decoded picture in the RGBA colorspace is 8294400 bytes, ie roughly
7.91 megabytes.
On my machine with 16 GB of RAM, I'd happily sacrifice 1GB, keeping in mind that unused RAM is bad RAM.
This represents around 130 frames that could be stored.
The proposal here is to implement a framecache element to act as storage, active only in the PAUSED state, in passthrough mode in the PLAYING state.
This element would be inserted immediately after the decodebin.
One could imagine using multiple frame caches after each filter to maximize smoothness, but this would introduce complexity to decide who would handle the seek, as far as I can tell changing properties of elements in the decodebin can not affect the actual output image (or can it ?), whereas changing a property on a filter can.
Seek handling "negotiation" is thus out of scope and excluded of this proposal.
Part of the complexity in the proposed design will be due to the requirement of
having both forward *and* backward scrub seeking working smoothly.
How to ensure that the first seek to a given region remains as fast as without the framecache, and at the same time store frames as soon as possible in the surrounding region.
Solution: the frame cache intercepts the seek, and returns TRUE. Caller is responsible for checking the bus for ASYNC_DONE, or if the seek actually failed, a custom "async seek failed" that need not be defined in this proposal. (does this already exist ?)
All the following operations take place in a task running on the sinkpad of the framecache.
The framecache element will then request a
SEEK_KEY_UNIT | GST_SEEK_FLAG_SNAP_BEFORE upstream, which should be as fast
as a normal seek (check -> is it true ?). start and stop are set at the required start.
Upon reception of the segment, the element knows where the previous keyframe was, takes note of that. It also knows the next position before which to seek when filling itself in the backward direction.
It then waits for EOS and pushes the last buffer it received downstream. All the buffers are stored, a counter is incremented to mark the number of buffers stored before the current position.
The element then requests a SEEK_KEY_UNIT | GST_SEEK_FLAG_SNAP_AFTER (note that some time is "wasted" in that first operation, ideally one would be able to specify "KEY_UNIT | SNAP_BEFORE" for the start and "KEY_UNIT | SNAP_AFTER" for the stop in the first seek but meh.
Buffers are stored blabla.
stop is noted, one now knows the next position to seek when filling the buffer in the forward direction. A counter is incremented to mark the number of buffers stored after the current position.
Things go on until the sum of "before" and "after" buffers exceeds a "soft limit".
When one receives a new seek, two solutions are possible:
1) The buffer is already stored in the framecache's memory -> it is sent, counters for "before" and "after" buffers are updated,
if needed some buffers are discarded on one side and seeks performed on the other side to maintain "symetry".
2) The buffer is not stored in the framecache's memory: immediately forward a new flushing seek upstream, repeating the process that happened on the first seek, the same update as in the other case is performed.
Flushes of course have to be handled appropriately by the element, this isn't detailed here.
As it is an element with only one sink and one source pad possibilities for race conditions seem low at first sight `^``^`https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/198androidmedia: Set KEY_IS_ADTS when using adts aac streams2021-09-24T14:32:56ZBugzilla Migration Userandroidmedia: Set KEY_IS_ADTS when using adts aac streams## Submitted by Edward Hervey `@bilboed`
**[Link to original bug (#741241)](https://bugzilla.gnome.org/show_bug.cgi?id=741241)**
## Description
Currently the androidmedia aac decoders state that they can consume ADTS aac (in additio...## Submitted by Edward Hervey `@bilboed`
**[Link to original bug (#741241)](https://bugzilla.gnome.org/show_bug.cgi?id=741241)**
## Description
Currently the androidmedia aac decoders state that they can consume ADTS aac (in addition to raw packetization).
When this happens, we also need to set the KEY_IS_ADTS to 1 on the media format, otherwise some implementations will barf at the stream (they assume it's raw and not in adts).
http://developer.android.com/reference/android/media/MediaFormat.html#KEY_IS_ADTShttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/197hlssink: Add support for PROGRAM-DATE-TIME on playlist creation2021-09-24T14:32:55ZBugzilla Migration Userhlssink: Add support for PROGRAM-DATE-TIME on playlist creation## Submitted by Flávio Ribeiro
**[Link to original bug (#741159)](https://bugzilla.gnome.org/show_bug.cgi?id=741159)**
## Description
There's some player implementations that take into account the PROGRAM-DATE-TIME to synchronize ti...## Submitted by Flávio Ribeiro
**[Link to original bug (#741159)](https://bugzilla.gnome.org/show_bug.cgi?id=741159)**
## Description
There's some player implementations that take into account the PROGRAM-DATE-TIME to synchronize timestamps and sequence number when switching levels.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/196tsdemux broken for network TS streams (NKF RTP/TS/MPEG2 stream)2021-09-24T14:32:55ZBugzilla Migration Usertsdemux broken for network TS streams (NKF RTP/TS/MPEG2 stream)## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#740959)](https://bugzilla.gnome.org/show_bug.cgi?id=740959)**
## Description
I am currenty looking into a number of regressions from 0.10 with old network camera sou...## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#740959)](https://bugzilla.gnome.org/show_bug.cgi?id=740959)**
## Description
I am currenty looking into a number of regressions from 0.10 with old network camera sources.
This one is about support on NKF MPEG2 cameras that send their payload in RTP/TS/MPEG2.
There seems to be a regression wrt 0.10.
I am listening to the stream:
gst-launch-1.0 rtpsrc uri=rtp://239.2.68.148:50010 ! rtpmp2tdepay ! tsparse ! tsdemux ! dumpinfo buffersize=1 ! fakesink dump=1 -v
the data is stuck at the tsdemux and even worse, it is leaking memory.
`<snip>`
2014-12-01T11:41:50.349328 3450 DEBUG tsdemux Moving data forward by 14 bytes (packet_size:0, have:183)
2014-12-01T11:41:50.388793 3450 DEBUG tsdemux stream:0x7f53f0026c60, pid:0x0100 stream_type:2 state:2
2014-12-01T11:41:50.389256 3450 DEBUG tsdemux Not enough information to push buffers yet, storing buffer
2014-12-01T11:41:50.389285 3450 DEBUG tsdemux stream PTS 99:99:99.999999999 DTS 99:99:99.999999999
2014-12-01T11:41:50.389293 3450 DEBUG tsdemux Moving data forward by 14 bytes (packet_size:0, have:183)
2014-12-01T11:41:50.429265 3450 DEBUG tsdemux stream:0x7f53f0026c60, pid:0x0100 stream_type:2 state:2
2014-12-01T11:41:50.429753 3450 DEBUG tsdemux Not enough information to push buffers yet, storing buffer
2014-12-01T11:41:50.429782 3450 DEBUG tsdemux stream PTS 99:99:99.999999999 DTS 99:99:99.999999999
2014-12-01T11:41:50.429791 3450 DEBUG tsdemux Moving data forward by 14 bytes (packet_size:0, have:183)
2014-12-01T11:41:50.468842 3450 DEBUG tsdemux stream:0x7f53f0026c60, pid:0x0100 stream_type:2 state:2
2014-12-01T11:41:50.469279 3450 DEBUG tsdemux Not enough information to push buffers yet, storing buffer
2014-12-01T11:41:50.469307 3450 DEBUG tsdemux stream PTS 99:99:99.999999999 DTS 99:99:99.999999999
2014-12-01T11:41:50.469316 3450 DEBUG tsdemux Moving data forward by 14 bytes (packet_size:0, have:183)
2014-12-01T11:41:50.508809 3450 DEBUG tsdemux stream:0x7f53f0026c60, pid:0x0100 stream_type:2 state:2
2014-12-01T11:41:50.509303 3450 DEBUG tsdemux Not enough information to push buffers yet, storing buffer
2014-12-01T11:41:50.509342 3450 DEBUG tsdemux stream PTS 99:99:99.999999999 DTS 99:99:99.999999999
2014-12-01T11:41:50.509379 3450 DEBUG tsdemux Moving data forward by 14 bytes (packet_size:0, have:183)
2014-12-01T11:41:50.548795 3450 DEBUG tsdemux stream:0x7f53f0026c60, pid:0x0100 stream_type:2 state:2
2014-12-01T11:41:50.549261 3450 DEBUG tsdemux Not enough information to push buffers yet, storing buffer
2014-12-01T11:41:50.549287 3450 DEBUG tsdemux stream PTS 99:99:99.999999999 DTS 99:99:99.999999999
2014-12-01T11:41:50.549295 3450 DEBUG tsdemux Moving data forward by 14 bytes (packet_size:0, have:183)
`<snip>`
Version: 1.10.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/194h265parse: Fix the logic for constructing a complete AU2021-09-24T14:32:54ZBugzilla Migration Userh265parse: Fix the logic for constructing a complete AU## Submitted by KyungYong KIM
**[Link to original bug (#740748)](https://bugzilla.gnome.org/show_bug.cgi?id=740748)**
## Description
In h265parse, it doesn't consider all nal_unit_type about VCL(Video Coding Layer) to construct a co...## Submitted by KyungYong KIM
**[Link to original bug (#740748)](https://bugzilla.gnome.org/show_bug.cgi?id=740748)**
## Description
In h265parse, it doesn't consider all nal_unit_type about VCL(Video Coding Layer) to construct a complete AU.
It can resolve using following patch.
diff --git a/gst/videoparsers/gsth265parse.c b/gst/videoparsers/gsth265parse.c
index 2d7b997..4a36e3b 100644
--- a/gst/videoparsers/gsth265parse.c
+++ b/gst/videoparsers/gsth265parse.c
@@ -693,10 +693,8 @@ gst_h265_parse_collect_nal (GstH265Parse * h265parse, const
GST_LOG_OBJECT (h265parse, "nal type: %d %s", nal_type, _nal_name (nal_type))
/* coded slice NAL starts a picture,
* i.e. other types become aggregated in front of it */
- h265parse->picture_start |= ((nal_type >= GST_H265_NAL_SLICE_TRAIL_N
- && nal_type <= GST_H265_NAL_SLICE_TRAIL_R)
- || (nal_type >= GST_H265_NAL_SLICE_BLA_W_LP
- && nal_type <= RESERVED_IRAP_NAL_TYPE_MAX));
+ h265parse->picture_start |= (nal_type >= GST_H265_NAL_SLICE_TRAIL_N
+ && nal_type <= RESERVED_IRAP_NAL_TYPE_MAX);
/* consider a coded slices (IRAP or not) to start a picture,
* (so ending the previous one) if first_slice_segment_in_pic_flag == 1*/
@@ -711,10 +709,8 @@ gst_h265_parse_collect_nal (GstH265Parse * h265parse, const
/* Any VCL Nal unit with first_slice_segment_in_pic_flag == 1 considered star
complete |= h265parse->picture_start
- && (((nal_type >= GST_H265_NAL_SLICE_TRAIL_N
- && nal_type <= GST_H265_NAL_SLICE_TRAIL_R)
- || (nal_type >= GST_H265_NAL_SLICE_BLA_W_LP
- && nal_type <= RESERVED_IRAP_NAL_TYPE_MAX))
+ && ((nal_type >= GST_H265_NAL_SLICE_TRAIL_N
+ && nal_type <= RESERVED_IRAP_NAL_TYPE_MAX)
&& (nnalu.data[nnalu.offset + 2] & 0x80));
GST_LOG_OBJECT (h265parse, "au complete: %d", complete);
Version: 1.4.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/191mpegtsmux: set group-id in stream-start event2021-09-24T14:32:53ZBugzilla Migration Usermpegtsmux: set group-id in stream-start event## Submitted by Aurélien Zanelli
**[Link to original bug (#740124)](https://bugzilla.gnome.org/show_bug.cgi?id=740124)**
## Description
Currently, mpegts muxer create a new STREAM_START event and push it downstream without setting g...## Submitted by Aurélien Zanelli
**[Link to original bug (#740124)](https://bugzilla.gnome.org/show_bug.cgi?id=740124)**
## Description
Currently, mpegts muxer create a new STREAM_START event and push it downstream without setting group_id causing a basesink derived element to output following FIXME message:
0:00:00.044971265 7168 0x92d8a60 FIXME basesink gstbasesink.c:3064:gst_base_sink_default_event:`<fakesink0>` stream-start event without group-id. Consider implementing group-id handling in the upstream elements
I propose to set a new group_id using helper before sending stream-start event.
This FIXME will also happen with others muxer, I can fix them if the solution is correct.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/190h264parse: not correctly parsing or passing through avc2021-09-24T14:32:53ZBugzilla Migration Userh264parse: not correctly parsing or passing through avc## Submitted by Semen Belozorov
**[Link to original bug (#740118)](https://bugzilla.gnome.org/show_bug.cgi?id=740118)**
## Description
I have ip camera that sends the h264 stream over rtsp. When I try to display this stream using GS...## Submitted by Semen Belozorov
**[Link to original bug (#740118)](https://bugzilla.gnome.org/show_bug.cgi?id=740118)**
## Description
I have ip camera that sends the h264 stream over rtsp. When I try to display this stream using GStreamer 1.4.4, i get a broken picture.
Problem appears when using the following simple pipeline:
rtspsrc location=rtsp://10.0.6.189/mpeg4 protocols=tcp ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! autovideosink
I can temporary get a correct picture, if I remove h264parse from the pipeline. Also, I can temporary get a correct picture if I use a GStreamer SDK 0.10. But in both cases, the picture may break later.
I found that the difference in behavior occurred after applying the following commit:
Revision: a41e8698b1ae62b18fd2449dfcb7c1b9d39d02b9
Author: Matej Knopp <matej.knopp@gmail.com>
Date: 08.09.2013 1:09:31
Message:
h264parse: don't update src caps if only codec_data differs
https://bugzilla.gnome.org/show_bug.cgi?id=705333
----
Modified: gst/videoparsers/gsth264parse.c
When I build the videoparsers in the state before applying this commit, I get the same behavior as in the case with a GStreamer SDK 0.10. But after some time the picture is still broke.
I recorded a part of the stream on which the picture is often broken. Sorry, it took so long. I've put it there:
https://drive.google.com/file/d/0Bw5nWXOdi4FybXpPMmVlQWsyVWs/view?usp=sharing
To reproduce the problem can be used the following pipeline:
gst-launch-1.0 filesrc location="CH9Hstream00002.gdp" ! gdpdepay ! rtph264depay ! avdec_h264 ! videoconvert ! autovideosinkhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/189amcaudiodec error: 'first buffer should have OMX_BUFFERFLAG_CODECCONFIG set'2021-09-24T14:32:53ZBugzilla Migration Useramcaudiodec error: 'first buffer should have OMX_BUFFERFLAG_CODECCONFIG set'## Submitted by Jonas Larsson
**[Link to original bug (#740101)](https://bugzilla.gnome.org/show_bug.cgi?id=740101)**
## Description
Created attachment 290679
gst logs
Environment: Google Nexus 9, Android 5.0 (L), non custom ...## Submitted by Jonas Larsson
**[Link to original bug (#740101)](https://bugzilla.gnome.org/show_bug.cgi?id=740101)**
## Description
Created attachment 290679
gst logs
Environment: Google Nexus 9, Android 5.0 (L), non custom factory image, official 1.4.4 Android debug binaries
App: Unmodified gst sdk tutorial 5
Error description:
Tested out the latest Android binaries for kicks, fail to play back lots of streams.
11-13 17:33:16.110 5481 5773 D GStreamer+amcaudiodec: 0:26:00.482850462 0xab9894f0 gstamcaudiodec.c:775:gst_amc_audio_dec_set_format:`<amcaudiodec-omxgoogleaacdecoder2>` Setting new caps audio/mpeg, framed=(boolean)true, mpegversion=(int)4, level=(string)1, base-profile=(string)lc, profile=(string)lc, rate=(int)24000, channels=(int)2, stream-format=(string)adts
11-13 17:33:16.110 5481 5773 D GStreamer+amcaudiodec: 0:26:00.482993212 0xab9894f0 gstamcaudiodec.c:891:gst_amc_audio_dec_set_format:`<amcaudiodec-omxgoogleaacdecoder2>` Configuring codec with format: {channel-count=2, mime=audio/mp4a-latm, sample-rate=24000}
11-13 17:33:16.118 5481 5777 E SoftAAC2: first buffer should have OMX_BUFFERFLAG_CODECCONFIG set
11-13 17:33:16.118 5481 5777 W SoftAAC2: aacDecoder_ConfigRaw decoderErr = 0x2003
11-13 17:33:16.118 5481 5776 E ACodec : [OMX.google.aac.decoder] ERROR(0x80001001)
11-13 17:33:16.121 5481 5779 E GStreamer+amcaudiodec: 0:26:00.494109128 0xab7cb000 gstamcaudiodec.c:476:gst_amc_audio_dec_loop:`<amcaudiodec-omxgoogleaacdecoder2>` Failure dequeueing output buffer
11-13 17:33:16.121 5481 5779 W GStreamer+amcaudiodec: 0:26:00.494204545 0xab7cb000 gstamcaudiodec.c:590:gst_amc_audio_dec_loop:`<amcaudiodec-omxgoogleaacdecoder2>` error: Failed to dequeue output buffer: java.lang.IllegalStateException
More complete log and media sample attached.
It appears that amcaudiodec advertises support for AAC in adts format. aacparse isn't producing any "codec_data" or "stream_header" so no "csd-0" parameter is set. Furthermore, the equivalent of
mediaFormat.setInteger(MediaFormat.KEY_IS_ADTS, 1);
isn't done either. MediaCodec therefore assumes raw AAC and expects the first buffer to contain ESDS and have the flag MediaCodec.BUFFER_FLAG_CODEC_CONFIG set. When that's not the case, this error is thrown.
adts AAC streams are quite common so a bug like this is a blocker for broader adoption on Android (as is` #731204`)
A workaround is to compile in faad which works perfectly.
(This is based on a one time reading of the code and logs, once I figure out how to actually build gst for android without cerbero failing left and right on my 64 bit system looking for 32 bit libs I *may* be able to offer more insight)
**Attachment 290679**, "gst logs":
[gst_log.txt](/uploads/520f56198c671bed3bb06d56d3057aef/gst_log.txt)
Version: 1.4.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/188h263parse: ignores width/height on the sink pad and produces wrong size2021-09-24T14:32:52ZBugzilla Migration Userh263parse: ignores width/height on the sink pad and produces wrong size## Submitted by Josep Torra `@adn770`
**[Link to original bug (#740072)](https://bugzilla.gnome.org/show_bug.cgi?id=740072)**
## Description
Run the following to reproduce the issue:
gst-launch-1.0 playbin uri=http://samples.mp...## Submitted by Josep Torra `@adn770`
**[Link to original bug (#740072)](https://bugzilla.gnome.org/show_bug.cgi?id=740072)**
## Description
Run the following to reproduce the issue:
gst-launch-1.0 playbin uri=http://samples.mplayerhq.hu/V-codecs/h263/100374.mov
In the sink pad video size is 240x180 and in the src pad is declared 352x288.
The correct size is 240x180 as it's specified in the container.
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstH263Parse:h263parse0.GstPad:sink: caps = "video/x-h263\,\ variant\=\(string\)itu\,\ width\=\(int\)240\,\ height\=\(int\)180\,\ framerate\=\(fraction\)12000/1001\,\ pixel-aspect-ratio\=\(fraction\)1/1"
Redistribute latency...
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/avdec_h263:avdec_h263-0.GstPad:sink: caps = "video/x-h263\,\ variant\=\(string\)itu\,\ width\=\(int\)352\,\ height\=\(int\)288\,\ framerate\=\(fraction\)12000/1001\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ parsed\=\(boolean\)true\,\ annex-d\=\(boolean\)true\,\ annex-e\=\(boolean\)false\,\ annex-f\=\(boolean\)false\,\ annex-g\=\(boolean\)false\,\ annex-i\=\(boolean\)false\,\ annex-j\=\(boolean\)false\,\ annex-k\=\(boolean\)false\,\ annex-m\=\(boolean\)false\,\ annex-n\=\(boolean\)false\,\ annex-q\=\(boolean\)false\,\ annex-r\=\(boolean\)false\,\ annex-s\=\(boolean\)false\,\ annex-t\=\(boolean\)false\,\ annex-u\=\(boolean\)false\,\ annex-v\=\(boolean\)false\,\ profile\=\(string\)1"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstH263Parse:h263parse0.GstPad:src: caps = "video/x-h263\,\ variant\=\(string\)itu\,\ width\=\(int\)352\,\ height\=\(int\)288\,\ framerate\=\(fraction\)12000/1001\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ parsed\=\(boolean\)true\,\ annex-d\=\(boolean\)true\,\ annex-e\=\(boolean\)false\,\ annex-f\=\(boolean\)false\,\ annex-g\=\(boolean\)false\,\ annex-i\=\(boolean\)false\,\ annex-j\=\(boolean\)false\,\ annex-k\=\(boolean\)false\,\ annex-m\=\(boolean\)false\,\ annex-n\=\(boolean\)false\,\ annex-q\=\(boolean\)false\,\ annex-r\=\(boolean\)false\,\ annex-s\=\(boolean\)false\,\ annex-t\=\(boolean\)false\,\ annex-u\=\(boolean\)false\,\ annex-v\=\(boolean\)false\,\ profile\=\(string\)1"https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/187mpeg4videoparse xvid packed bitstream2021-09-24T14:32:52ZBugzilla Migration Usermpeg4videoparse xvid packed bitstream## Submitted by Athanasios Oikonomou
**[Link to original bug (#740015)](https://bugzilla.gnome.org/show_bug.cgi?id=740015)**
## Description
DivX Networks introduced a hack with their so-called dx50 VOP mode, inserting
dummy frame...## Submitted by Athanasios Oikonomou
**[Link to original bug (#740015)](https://bugzilla.gnome.org/show_bug.cgi?id=740015)**
## Description
DivX Networks introduced a hack with their so-called dx50 VOP mode, inserting
dummy frames into the AVI as placeholders and packing the b-frame itself
into the same chunk together with the I/P frame it is referencing to.
XviD does that also, but if offering a so-called 'packed bitstream' mode
also as alternative. IN both cases parser, reading the MPEG4
frames , would have to get rid of the dummy frames and reorder the
b-frames such that coding order is achieved in the final output.
-----------------
The n-vops are inserted into "empty" frames when using packed-mode.
[foo] represents an avi frame, [-] re e.g.
unpacked: [I] [P] [B] [B] [P] [B] [B] [P]
packed [I] [PB] [B] [-] [PB] [B] [-] [P]
The empty frames cannot be set to length=0, because vfw decoding
interprets this as a frame drop and doesnt bother calling the codec.
So to get arround this, divx5.02 inserts a n-vop using the previous
p-vop's timecode. xvid does the same to remain compatible.
-----------------
There is no way to differentiate "packed-n-vops" from real n-vop.
however, packed bitstream can be detected from the divx userdata tag.
the tag takes the form "DivX%dB%d%c", version, build, packed.
-----------------
Packed b-frames: In packed b-frame mode there are fake nvops written
to the output by the encoder. Those are not real nvops but are rather
supposed to be totally ignored by the decoder. As such it is not really
a proper use of nvops but it's become the defacto standard how the b-frame
encoder delay got handled with the AVI container. If you don't want to
mux your output into AVI, use the "-nopacked" switch and there should be
no fake nvops added anymore.
-----------------
Currently the mpeg4videoparse doesn't discard those "fake n-vops" causing issues in playback.
The following is what we receive to render function of our sink:
unpacked xvid:
0x000000: 00 00 01 b0 f5 00 00 01 ........
0x000008: b5 09 00 00 01 00 00 00 ........
0x000010: 01 20 08 86 87 ff ff 0a . ......
0x000018: ad 88 82 19 0a 31 00 00 .....1..
0x000020: 01 b2 58 76 69 44 30 30 ..XviD00
0x000028: 34 33 00 00 01 b6 10 00 43......
0x000030: 0c 06 30 47 b6 fe 36 db ..0G..6.
0x000038: f8 db 6f e3 6d bf 8d b6 ..o.m...
0x000040: fe 36 db f8 db 6f e3 6d .6...o.m
0x000048: bf 8d b6 fe 36 db f8 db ....6...
0x000050: 6f e3 6d bf 8d b6 fe 36 o.m....6
0x000058: db f8 db 6f e3 6d bf 8d ...o.m..
0x000060: b6 fe 36 db f8 db 6f e3 ..6...o.
0x000068: 6d bf 8d b6 fe 36 db f8 m....6..
packed xvid:
0x000000: 00 00 01 b0 f5 00 00 01 ........
0x000008: b5 09 00 00 01 00 00 00 ........
0x000010: 01 20 08 86 87 ff ff 0a . ......
0x000018: ad 88 82 19 0a 31 00 00 .....1..
0x000020: 01 b2 44 69 76 58 35 30 ..DivX50
0x000028: 33 62 31 33 39 33 70 00 3b1393p.
0x000030: 00 01 b2 58 76 69 44 30 ...XviD0
0x000038: 30 34 33 00 00 01 b6 10 043.....
0x000040: 00 0c 06 30 47 b6 fe 36 ...0G..6
0x000048: db f8 db 6f e3 6d bf 8d ...o.m..
0x000050: b6 fe 36 db f8 db 6f e3 ..6...o.
0x000058: 6d bf 8d b6 fe 36 db f8 m....6..
0x000060: db 6f e3 6d bf 8d b6 fe .o.m....
0x000068: 36 db f8 db 6f e3 6d bf 6...o.m.
unpacked xvid:
XviD Packet Dump
0x000000: 00 00 01 b0 f5 00 00 01 ........
0x000008: b5 09 00 00 01 00 00 00 ........
--
XviD Packet Dump
0x000000: 00 00 01 b6 52 22 78 10 ....R"x.
0x000008: b1 93 b1 95 90 be 97 04 ........
--
XviD Packet Dump
0x000000: 00 00 01 b6 91 28 38 29 .....(8)
0x000008: 3f f4 fc a9 b9 a6 3d 06 ?.....=.
--
XviD Packet Dump
0x000000: 00 00 01 b6 91 a5 58 31 ......X1
0x000008: 34 ff fe 8e be 48 e1 ef 4....H..
--
XviD Packet Dump
0x000000: 00 00 01 b6 53 99 dc 14 ....S...
0x000008: be fb eb 62 e5 f0 70 60 ...b..p`
--
XviD Packet Dump
0x000000: 00 00 01 b6 92 9f 98 29 .......)
0x000008: 3f a7 fc 89 b4 b3 83 83 ?.......
--
XviD Packet Dump
0x000000: 00 00 01 b6 93 1c b8 31 .......1
0x000008: 3f ff 4f ff ff 4b ff 09 ?.O..K..
--
XviD Packet Dump
0x000000: 00 00 01 b6 55 11 38 10 ....U.8.
0x000008: b7 8b 56 c1 62 af d8 70 ..V.b..p
--
XviD Packet Dump
0x000000: 00 00 01 b6 94 16 f8 39 .......9
0x000008: 3a 3f fe 08 8e 74 18 9c :?...t..
--
XviD Packet Dump
0x000000: 00 00 01 b6 94 94 18 31 .......1
0x000008: 3d 3f ff 4e 9f d1 bf fa =?.N....
--
XviD Packet Dump
0x000000: 00 00 01 b6 56 88 9c 10 ....V...
0x000008: b7 85 88 78 2f 01 29 3c ...x/.)<
packed xvid:
XviD Packet Dump
0x000000: 00 00 01 b0 f5 00 00 01 ........
0x000008: b5 09 00 00 01 00 00 00 ........
--
XviD Packet Dump
0x000000: 00 00 01 b6 52 22 78 10 ....R"x.
0x000008: b1 93 b1 95 90 be 97 04 ........
--
XviD Packet Dump
0x000000: 00 00 01 b6 91 28 38 29 .....(8)
0x000008: 3f f4 fc a9 b9 a6 3d 06 ?.....=.
--
XviD Packet Dump
0x000000: 00 00 01 b6 91 a5 58 31 ......X1
0x000008: 34 ff fe 8e be 48 e1 ef 4....H..
--
XviD Packet Dump
0x000000: 00 00 01 b6 52 22 73 ....R"s
--
XviD Packet Dump
0x000000: 00 00 01 b6 53 99 dc 14 ....S...
0x000008: be fb eb 62 e5 f0 70 60 ...b..p`
--
XviD Packet Dump
0x000000: 00 00 01 b6 92 9f 98 29 .......)
0x000008: 3f a7 fc 89 b4 b3 83 83 ?.......
--
XviD Packet Dump
0x000000: 00 00 01 b6 93 1c b8 31 .......1
0x000008: 3f ff 4f ff ff 4b ff 09 ?.O..K..
--
XviD Packet Dump
0x000000: 00 00 01 b6 53 99 d3 ....S
--
XviD Packet Dump
0x000000: 00 00 01 b6 55 11 38 10 ....U.8.
0x000008: b7 8b 56 c1 62 af d8 70 ..V.b..p
--
XviD Packet Dump
0x000000: 00 00 01 b6 94 16 f8 39 .......9
0x000008: 3a 3f fe 08 8e 74 18 9c :?...t..
--
XviD Packet Dump
0x000000: 00 00 01 b6 94 94 18 31 .......1
0x000008: 3d 3f ff 4e 9f d1 bf fa =?.N....
--
XviD Packet Dump
0x000000: 00 00 01 b6 55 11 33 ....U.3
--
XviD Packet Dump
0x000000: 00 00 01 b6 56 88 9c 10 ....V...
0x000008: b7 85 88 78 2f 01 29 3c ...x/.)<
--
Packed XviD has extra packets received on sink and those are causing problems in rendering.
0x000000: 00 00 01 b6 52 22 73 ....R"s
--
0x000000: 00 00 01 b6 53 99 d3 ....S
--
0x000000: 00 00 01 b6 55 11 33 ....U.3
So if those packets removed and also packed bitstream (DivX503b1393p) removed, then there will be no difference between packed and unpacked xvid.
More info:
https://bugzilla.gnome.org/show_bug.cgi?id=739196
http://itsjustonesandzeros.blogspot.ca/2007/01/what-is-packed-bitstream.html
http://list.xvid.org/pipermail/xvid-devel/2002-September/000870.html
http://lists.matroska.org/pipermail/matroska-devel/2003-June/000603.html
http://list.xvid.org/pipermail/xvid-devel/2004-March/004091.html
http://list.xvid.org/pipermail/xvid-devel/2014-April/006418.html
Version: 1.4.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/185MPEG-PS fails to parse and play2021-09-24T14:32:51ZBugzilla Migration UserMPEG-PS fails to parse and play## Submitted by Athanasios Oikonomou
**[Link to original bug (#739303)](https://bugzilla.gnome.org/show_bug.cgi?id=739303)**
## Description
The following MPEG-PS file fails to parse and play.
Subtitle-sample.mkv 4.0 MB https://...## Submitted by Athanasios Oikonomou
**[Link to original bug (#739303)](https://bugzilla.gnome.org/show_bug.cgi?id=739303)**
## Description
The following MPEG-PS file fails to parse and play.
Subtitle-sample.mkv 4.0 MB https://mega.co.nz/#!SdcyHRBA!qwfAF-YUIpPmB2nphYCoOArSLyXRO8JaIh6hSlNSseY
gst-launch-1.0 -v playbin uri=file:///media/usb/1/Subtitle-sample.mkv
Setting pipeline to PAUSED ...
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: ring-buffer-max-size = 0
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: buffer-size = -1
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: buffer-duration = -1
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: use-buffering = false
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: download = false
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: uri = file:///media/usb/1/Subtitle-sample.mkv
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: connection-speed = 0
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: source = "\(GstFileSrc\)\ source"
Pipeline is PREROLLING ...
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = "video/mpeg\,\ systemstream\=\(boolean\)true\,\ mpegversion\=\(int\)2"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_0: caps = audio/x-private1-dts
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_0: caps = audio/x-private1-dts
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_1: caps = "audio/mpeg\,\ mpegversion\=\(int\)1"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpegAudioParse:mpegaudioparse0.GstPad:sink: caps = "audio/mpeg\,\ mpegversion\=\(int\)1"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_2: caps = "audio/mpeg\,\ mpegversion\=\(int\)1"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_2: caps = "audio/mpeg\,\ mpegversion\=\(int\)1"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpegAudioParse:mpegaudioparse1.GstPad:sink: caps = "audio/mpeg\,\ mpegversion\=\(int\)1"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_3: caps = "audio/mpeg\,\ mpegversion\=\(int\)1"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_3: caps = "audio/mpeg\,\ mpegversion\=\(int\)1"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpegAudioParse:mpegaudioparse2.GstPad:sink: caps = "audio/mpeg\,\ mpegversion\=\(int\)1"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_4: caps = "audio/mpeg\,\ mpegversion\=\(int\)1"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_4: caps = "audio/mpeg\,\ mpegversion\=\(int\)1"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpegAudioParse:mpegaudioparse3.GstPad:sink: caps = "audio/mpeg\,\ mpegversion\=\(int\)1"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_5: caps = subpicture/x-dvd
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_5: caps = subpicture/x-dvd
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_6: caps = subpicture/x-dvd
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_6: caps = subpicture/x-dvd
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_7: caps = subpicture/x-dvd
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_7: caps = subpicture/x-dvd
ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpegAudioParse:mpegaudioparse0: No valid frames found before end of stream
Additional debug info:
/opt/openpli/openpligst/build/tmp/work/mips32el-oe-linux/gstreamer1.0/1.4.3-r1/gstreamer-1.4.3/libs/gst/base/gstbaseparse.c(1155): gst_base_parse_sink_event_default (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpegAudioParse:mpegaudioparse0
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpegAudioParse:mpegaudioparse3.GstPad:sink: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpegAudioParse:mpegaudioparse2.GstPad:src: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpegAudioParse:mpegaudioparse2.GstPad:src: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpegAudioParse:mpegaudioparse2.GstPad:sink: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpegAudioParse:mpegaudioparse1.GstPad:sink: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpegAudioParse:mpegaudioparse0.GstPad:sink: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:src_0: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:src_1: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:src_2: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:src_3: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:src_4: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:src_5: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:src_6: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:src_7: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_0: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_1: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_2: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_3: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_4: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_5: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_6: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0.GstPad:sink_7: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpegPSDemux:mpegpsdemux0.GstPad:audio_89: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpegPSDemux:mpegpsdemux0.GstPad:audio_c3: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpegPSDemux:mpegpsdemux0.GstPad:audio_c2: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpegPSDemux:mpegpsdemux0.GstPad:audio_c0: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpegPSDemux:mpegpsdemux0.GstPad:audio_c4: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpegPSDemux:mpegpsdemux0.GstPad:subpicture_20: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpegPSDemux:mpegpsdemux0.GstPad:subpicture_22: caps = "NULL"
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMpegPSDemux:mpegpsdemux0.GstPad:subpicture_21: caps = "NULL"
Freeing pipeline ...
Version: 1.4.3https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/184Plugin rtmp segmentation fault when stopping stream almost immediately2021-09-24T14:32:51ZBugzilla Migration UserPlugin rtmp segmentation fault when stopping stream almost immediately## Submitted by Athanasios Oikonomou
**[Link to original bug (#739263)](https://bugzilla.gnome.org/show_bug.cgi?id=739263)**
## Description
Created attachment 289484
segmentation fault of rtmp when stopping stream almost immediate...## Submitted by Athanasios Oikonomou
**[Link to original bug (#739263)](https://bugzilla.gnome.org/show_bug.cgi?id=739263)**
## Description
Created attachment 289484
segmentation fault of rtmp when stopping stream almost immediately
Stopping rtmp stream almost immediately after start causes segmentation fault.
This observed using Enigma2 and changing fast between rtmp streams. The segmentation fault is happening when Enigma2 tries to stop the stream using gst_element_set_state(m_gst_playbin, GST_STATE_NULL).
Before the Enigma2 crashed the following messages appearing:
eServiceMP3::stop gst_element_get_state
eServiceMP3::stop gst_element_get_state PLAYING -> VOID_PENDING
eServiceMP3::stop rtmp://live2.ertopen.com/live2/e600 live=1 timeout=10
eServiceMP3::stop done...
eServiceMP3::m_nownext_timer->stop
eServiceMP3::m_nownext_timer->stop done
eServiceMP3::~eServiceMP3
eServiceMP3::destruct!
eServiceMP3::eServiceMP3
eServiceMP3::construct!
getResolvedKey config.mediaplayer.extraHeaders failed !! (Typo??)
eServiceMP3::playbin uri=rtmp://82.192.84.30:1935/live/myStream.sdp
eServiceMP3::start
eServiceMP3::starting pipeline
eServiceMP3::updateEpgCacheNowNext
resolved to PLAY
gst_element_query_position failed in getPlayPosition
resolved to PLAY
gst_element_query_position failed in getPlayPosition
resolved to PLAY
gst_element_query_position failed in getPlayPosition
new service started! trying to download cuts!
download failed, no cuesheet interface
RemovePopup, id = ZapError
[DVBCAHandler] no more services
release cached channel (timer timeout)
[eDVBLocalTimerHandler] remove channel 0x1794af8
[eEPGCache] remove channel 0x1794af8
[EPGC] abort caching events !!
stop release channel timer
eTsRemoteSource::gst_message from playbin: GstMessageStateChanged, old-state=(GstState)GST_STATE_NULL, new-state=(GstState)GST_STATE_READY, pending-state=(GstState)GST_STATE_PLAYING;
eServiceMP3::state transition NULL -> READY
eTsRemoteSource::gst_message from src: GstMessageStreamStatus, type=(GstStreamStatusType)GST_STREAM_STATUS_TYPE_CREATE, owner=(GstElement)"\(GstRTMPSrc\)\ source", object=(GstTask)"\(GstTask\)\ source:src";
eTsRemoteSource::gst_message from src: GstMessageStreamStatus, type=(GstStreamStatusType)GST_STREAM_STATUS_TYPE_ENTER, owner=(GstElement)"\(GstRTMPSrc\)\ source", object=(GstTask)"\(GstTask\)\ source:src";
action -> InfobarChannelSelection keyUp
action -> OkCancelActions ok
playing 4097:0:1:0:0:0:0:0:0:0:rtmp%3a//live2.ertopen.com/live2/e600 live=1 timeout=10:!Ert3 Open {Rtmp}
eServiceMP3::stop
eServiceMP3::stop gst_element_get_state
eServiceMP3::stop gst_element_get_state READY -> PLAYING
eServiceMP3::stop rtmp://82.192.84.30:1935/live/myStream.sdp
Segmentation fault (core dumped)
The backtrace from the above core dump shows the following information:
```
(gdb) bt
#0 0x80004f82 in ?? ()
#1 0x73a1371c in RTMP_ReadPacket (r=0x1788400, packet=0x709f6a68) at rtmp.c:3705
#2 0x73a17b80 in RTMP_GetNextMediaPacket (r=0x1788400, packet=0x709f6a68) at rtmp.c:1181
#3 0x73a17ccc in Read_1_Packet (r=0x1788400,
buf=0x72e1b1d2 "\312\342\242\353m\212\306\a`:\252h\351\065,\340\310we\335b*Y\\\200\224m\256=\323\222\340u\n\357\002X\264+\271g*:\275\316\066\225dk\037\320f9S\036Y\273=\307\245\350<\313\367\224\203v\356h\020\242\253\304z\377\317\212\004\302\225G\361\016\313\037\232\336\352\361\020\331C&\372\313\246\211\v\336:M\356\300\021]\237\024\347\345\251", buflen=3454) at rtmp.c:4499
#4 0x73a187f8 in RTMP_Read (r=0x1788400,
buf=0x72e1b1d2 "\312\342\242\353m\212\306\a`:\252h\351\065,\340\310we\335b*Y\\\200\224m\256=\323\222\340u\n\357\002X\264+\271g*:\275\316\066\225dk\037\320f9S\036Y\273=\307\245\350<\313\367\224\203v\356h\020\242\253\304z\377\317\212\004\302\225G\361\016\313\037\232\336\352\361\020\331C&\372\313\246\211\v\336:M\356\300\021]\237\024\347\345\251", size=3454) at rtmp.c:5063
#5 0x73a33cac in gst_rtmp_src_create (pushsrc=0x17835c8, buffer=0x709f6c68)
at /opt/openpli/openpligst/build/tmp/work/mips32el-oe-linux/gstreamer1.0-plugins-bad/1.4.3-r4/gst-plugins-bad-1.4.3/ext/rtmp/gstrtmpsrc.c:333
#6 0x768ae0bc in gst_base_src_get_range (src=0x17835c8, offset=<optimized out>, length=4096, buf=0x709f6d58)
at /opt/openpli/openpligst/build/tmp/work/mips32el-oe-linux/gstreamer1.0/1.4.3-r1/gstreamer-1.4.3/libs/gst/base/gstbasesrc.c:2445
#7 0x768b0588 in gst_base_src_loop (pad=0x17ca978)
at /opt/openpli/openpligst/build/tmp/work/mips32el-oe-linux/gstreamer1.0/1.4.3-r1/gstreamer-1.4.3/libs/gst/base/gstbasesrc.c:2721
#8 0x77611b1c in gst_task_func (task=0x72e2ce10)
at /opt/openpli/openpligst/build/tmp/work/mips32el-oe-linux/gstreamer1.0/1.4.3-r1/gstreamer-1.4.3/gst/gsttask.c:317
#9 0x77462be0 in ?? () from /usr/lib/libglib-2.0.so.0
```
Also a log (with the last 245 lines) is attached using command GST_DEBUG_NO_COLOR=1 GST_DEBUG=*:6 enigma2 > segmentation_fault.log
**Attachment 289484**, "segmentation fault of rtmp when stopping stream almost immediately":
[segmentation_fault.log](/uploads/29e6c33013ed0568b8e9aaead5305605/segmentation_fault.log)
Version: 1.4.3
### See also
* [Bug 729099](https://bugzilla.gnome.org/show_bug.cgi?id=729099)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/183hlssink: Add URI handler interface2021-09-24T14:32:51ZBugzilla Migration Userhlssink: Add URI handler interface## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#738608)](https://bugzilla.gnome.org/show_bug.cgi?id=738608)**
## Description
Created attachment 288651
HLS uri handler
This patch adds a uri-handler to hlssin...## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#738608)](https://bugzilla.gnome.org/show_bug.cgi?id=738608)**
## Description
Created attachment 288651
HLS uri handler
This patch adds a uri-handler to hlssink.
Greetings from Dusseldorf; Tim just complained there were not enough bugs and companies were not contributing enough :-)
~~**Patch 288651**~~, "HLS uri handler":
[0001-hls-uri-registered-on-hlssink.patch](/uploads/7360f1da367b5ddf2e4052c0410880ba/0001-hls-uri-registered-on-hlssink.patch)
Version: 1.10.4
### Depends on
* [Bug 779765](https://bugzilla.gnome.org/show_bug.cgi?id=779765)