GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T14:34:25Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/395openslessink: unconditionnally exposes volume and mute properties even if not...2021-09-24T14:34:25ZBugzilla Migration Useropenslessink: unconditionnally exposes volume and mute properties even if not supported## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#767066)](https://bugzilla.gnome.org/show_bug.cgi?id=767066)**
## Description
I have openslessink element in my android app, but setting the "mute" property does ...## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#767066)](https://bugzilla.gnome.org/show_bug.cgi?id=767066)**
## Description
I have openslessink element in my android app, but setting the "mute" property does nothing. It is probably not always supported by the hw? Or it's just simply broken?https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/22RTSP server won't be destroyed until media is pre-rolled (or 20s timeout)2021-09-24T11:03:53ZBugzilla Migration UserRTSP server won't be destroyed until media is pre-rolled (or 20s timeout)## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#767021)](https://bugzilla.gnome.org/show_bug.cgi?id=767021)**
## Description
Created attachment 328727
test case
My application has an RTSP server that ca...## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#767021)](https://bugzilla.gnome.org/show_bug.cgi?id=767021)**
## Description
Created attachment 328727
test case
My application has an RTSP server that can be started/stopped by the user. When shutting down the server, I disconnect all clients, unref the server, and call gst_rtsp_thread_pool_cleanup() to be sure all resources has been cleaned.
If a client connects just before I stop the server, it will wait for pre-roll in gst_rtsp_media_get_status(). If pre-roll never happens it will unblock on a 20s timeout.
I think in the case that the client disconnects, it should unblock that condition.
**Attachment 328727**, "test case":
[test-shutdown.c](/uploads/32f8ef90019129a6e68623eb40ac3694/test-shutdown.c)
### Depends on
* [Bug 750111](https://bugzilla.gnome.org/show_bug.cgi?id=750111)https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/39vaapidecode: mpeg-2 don't render with ximagesink2021-10-22T07:40:50ZBugzilla Migration Uservaapidecode: mpeg-2 don't render with ximagesink## Submitted by Tim Müller `@tpm`
**[Link to original bug (#766978)](https://bugzilla.gnome.org/show_bug.cgi?id=766978)**
## Description
$ gst-play-1.0 https://people.freedesktop.org/~tpm/samples/bbcnews.m2t
Doesn't work at all...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#766978)](https://bugzilla.gnome.org/show_bug.cgi?id=766978)**
## Description
$ gst-play-1.0 https://people.freedesktop.org/~tpm/samples/bbcnews.m2t
Doesn't work at all for me with gstreamer-vaapi (i.e. if vaapisink is picked as sink which it is by default). Lots of criticals and a pink image. Works with glimagesink and xvimagesink.
### Depends on
* [Bug 771382](https://bugzilla.gnome.org/show_bug.cgi?id=771382)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/270Playback hangs after audioresample gstaudioresample.c:1009:gst_audio_resample...2021-09-24T13:21:59ZBugzilla Migration UserPlayback hangs after audioresample gstaudioresample.c:1009:gst_audio_resample_check_discont:<resampler> encountered timestamp discontinuity## Submitted by Marcin Lewandowski
**[Link to original bug (#766871)](https://bugzilla.gnome.org/show_bug.cgi?id=766871)**
## Description
I am encountering hangs in playback after getting following warning from audioresample
au...## Submitted by Marcin Lewandowski
**[Link to original bug (#766871)](https://bugzilla.gnome.org/show_bug.cgi?id=766871)**
## Description
I am encountering hangs in playback after getting following warning from audioresample
audioresample gstaudioresample.c:1009:gst_audio_resample_check_discont:`<resampler>` encountered timestamp discontinuity of 26052735 samples = 0:09:50.764965986
No warnings and errors on bus, it just stops. It happens always at the same position.
I attach GST_DEBUG=*:5 log.
GStreamer 1.8.0 from Ubuntu 16.04.
Version: 1.8.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/393opencv: add cvclahe element to apply adaptive histogram equalization2021-09-24T14:34:25ZBugzilla Migration Useropencv: add cvclahe element to apply adaptive histogram equalization## Submitted by Joshua M. Doe
**[Link to original bug (#766865)](https://bugzilla.gnome.org/show_bug.cgi?id=766865)**
## Description
Created attachment 328507
patch adding cvclahe element
Patch attached which adds cvclahe, an...## Submitted by Joshua M. Doe
**[Link to original bug (#766865)](https://bugzilla.gnome.org/show_bug.cgi?id=766865)**
## Description
Created attachment 328507
patch adding cvclahe element
Patch attached which adds cvclahe, an OpenCV element which applies contrast limited adaptive histogram equalization (https://en.wikipedia.org/wiki/Adaptive_histogram_equalization) to RGB, GRAY8, and GRAY16_LE video.
This is useful to bring out detail in high dynamic range scenes. While it provides interesting results in RGB and GRAY8, it is most useful in GRAY16_LE video.
**Patch 328507**, "patch adding cvclahe element":
[0001-opencv-add-new-element-cvclahe-to-apply-CLAHE-to-16-.patch](/uploads/7638c1babee8919a4f75b0757e5765d8/0001-opencv-add-new-element-cvclahe-to-apply-CLAHE-to-16-.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/38vaapipostproc: deinterlace produces video jerking2021-10-22T07:40:50ZBugzilla Migration Uservaapipostproc: deinterlace produces video jerking## Submitted by Lim Siew Hoon
**[Link to original bug (#766862)](https://bugzilla.gnome.org/show_bug.cgi?id=766862)**
## Description
Created attachment 328488
test_video_h264_info.txt
Gstreamer framework 1.7.90 version
Gstr...## Submitted by Lim Siew Hoon
**[Link to original bug (#766862)](https://bugzilla.gnome.org/show_bug.cgi?id=766862)**
## Description
Created attachment 328488
test_video_h264_info.txt
Gstreamer framework 1.7.90 version
Gstreamer-vaapi: 1.7.90 version.
command:
gst-launch-1.0 filesrc location=/home/root/H264_Main_Interlaced_Sound_ToTheLimit.mp4 ! qtdemux ! vaapidecode ! vaapipostproc deinterlace-mode=1 deinterlace-method=1 ! vaapisink fullscreen=true
Combination:
deinterlace-mode=1 and deinterlace-method=0
deinterlace-mode=1 and deinterlace-method=1
deinterlace-mode=1 and deinterlace-method=2
deinterlace-mode=0 and deinterlace-method=0
deinterlace-mode=0 and deinterlace-method=1
deinterlace-mode=0 and deinterlace-method=2
H264 interlace video with vaapipostproc with above combination will causing the video jerking. The issue also able to reproduce in 1.8.1 version too.
flags = 0x0 and ttf=0x1
Original version: gst_vaapipostproc_process function
/* Second field */
append_output_buffer_metadata (postproc, outbuf, inbuf, 0);
meta = gst_buffer_get_vaapi_video_meta (outbuf);
outbuf_flags = flags;
outbuf_flags |= deint ? (tff ?
GST_VAAPI_PICTURE_STRUCTURE_BOTTOM_FIELD :
GST_VAAPI_PICTURE_STRUCTURE_TOP_FIELD) :
GST_VAAPI_PICTURE_STRUCTURE_FRAME;
gst_vaapi_video_meta_set_render_flags (meta, outbuf_flags);
Modify version:
/* Second field */
append_output_buffer_metadata (postproc, outbuf, inbuf, 0);
meta = gst_buffer_get_vaapi_video_meta (outbuf);
outbuf_flags = flags;
outbuf_flags |= deint ? (tff ?
GST_VAAPI_PICTURE_STRUCTURE_TOP_FIELD :
GST_VAAPI_PICTURE_STRUCTURE_BOTTOM_FIELD) :
GST_VAAPI_PICTURE_STRUCTURE_FRAME;
gst_vaapi_video_meta_set_render_flags (meta, outbuf_flags);
After I make the arrangement in outbuf_flags same as the fieldbuf_flags logic checking, the video jerking issue go away.
**Attachment 328488**, "test_video_h264_info.txt":
[test_video_h264_info.txt](/uploads/128fc2b9d7d364e0b3722202323af598/test_video_h264_info.txt)
Version: 1.7.90https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/31PKG_CONFIG_PATH incorrect for multiarch on Debian2021-09-17T07:28:51ZBugzilla Migration UserPKG_CONFIG_PATH incorrect for multiarch on Debian## Submitted by Richard Webb
**[Link to original bug (#766833)](https://bugzilla.gnome.org/show_bug.cgi?id=766833)**
## Description
It seems that the PKG_CONFIG_PATH that is set up in `cerbero/utils/__init__.py` is not always correc...## Submitted by Richard Webb
**[Link to original bug (#766833)](https://bugzilla.gnome.org/show_bug.cgi?id=766833)**
## Description
It seems that the PKG_CONFIG_PATH that is set up in `cerbero/utils/__init__.py` is not always correct.
On the board I am currently using (Wandboard with Ubuntu 14.04) for instance, arch specific pkgconfigs are in `/usr/lib/arm-linux-gnueabihf/pkgconfig`, while the python script assumes this is always 'usr/lib/%s-linux-gnu/pkgconfig' % arch. This doesn't take into account the Multiarch tuples as specified here:
https://wiki.debian.org/Multiarch/Tuples
I would suggest that this is changed (on Debian) to include the output of the following command:
dpkg-architecture -qDEB_HOST_MULTIARCH
On my system, the above outputs the correct multiarch tuple: `arm-linux-gnueabihf`.
Happy to attempt a patch if this seems acceptable.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/275isomp4: Use 64bit variables for elst2021-09-24T13:31:44ZBugzilla Migration Userisomp4: Use 64bit variables for elst## Submitted by Seungha Yang
**[Link to original bug (#766760)](https://bugzilla.gnome.org/show_bug.cgi?id=766760)**
## Description
isomp4: Use 64bit variables for elst
EditListBox can support 64bit variables based on the versi...## Submitted by Seungha Yang
**[Link to original bug (#766760)](https://bugzilla.gnome.org/show_bug.cgi?id=766760)**
## Description
isomp4: Use 64bit variables for elst
EditListBox can support 64bit variables based on the version box.
More specifically, version 1 of this box uses 64bit values for
segment_duration and media_time. Otherwise, 32bit values are used.
### See also
* [Bug 766301](https://bugzilla.gnome.org/show_bug.cgi?id=766301)https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/80Signing the distribution on Windows & Mac2018-11-03T10:48:10ZBugzilla Migration UserSigning the distribution on Windows & Mac## Submitted by Andy Robinson
**[Link to original bug (#766715)](https://bugzilla.gnome.org/show_bug.cgi?id=766715)**
## Description
(I've marked this bug as OS:Windows. It is really Windows and Mac but there's no way of indicating ...## Submitted by Andy Robinson
**[Link to original bug (#766715)](https://bugzilla.gnome.org/show_bug.cgi?id=766715)**
## Description
(I've marked this bug as OS:Windows. It is really Windows and Mac but there's no way of indicating that).
Is there any interest in signing the distributions for Windows and Mac? It certainly seems to me that the current absence of signatures must be a significant obstacle to the adoption of GStreamer on these two platforms which between them account for the vast majority of all desktop computers.
At present on Windows 10 32-bit I download gstreamer-1.0-x86-1.8.1.msi and when I try to run it I get (actually this is the Win7 message but the Win10 message is similar):
"The publisher could not be verified.
Are you sure you want to run this software?".
On Mac OS 10.10 with default security settings I get:
"gstreamer-1.0-1.8.1-x86_64.pkg" can't be opened because
it is from an unidentified developer.
Your security preferences allow installation of only
apps from the Mac App Store and identified developers.
The Mac doesn't allow the option of installing at all.
This will prevent many Windows users and practically all Mac users from installing it. I might be exaggerating slightly, but I would say that these days it is hardly worth producing Windows and Mac distributions at all if they are not signed.
Once the signing certificates are obtained then it's just one more step in the build script. I'm happy to help if I can though it seems to me the certificates should be owned and applied by the GStreamer organization, or by the person who builds the distribution packages. In particular I would be happy to pay the costs, which AFAIK would be something like $99 per year to be a member of the Apple Developer program and I currently pay around $400 per year for an authenticode certificate from Symantec, for Windows signing.
Obviously there is some self interest here on my part : the next release of my company's main product will not *require* GStreamer but I will be encouraging users to install it to add certain features (e.g. video, and more audio file formats).
Mac: I don't think there are identity checks and they have the concept of developer teams allowing more than one person to be able to sign.
Windows: you need to go through the procedure of ordering and collecting the certificate using the same browser and machine throughout - and I found it has to be IE not Edge. But once you have the certificate you can move the pfx file to a different machine and use it there. Of course, as soon as you send the pfx in an unencrypted email then it could potentially be leaked. There are also identity checks before the certificate is issued, depending on the certificate provider's procedures.
It is all a bit tedious and tricksy to get it set up. If the GStreamer people who prepare the Windows & Mac distributions want to do this then as I've said I would be happy to pay the cost, and this would be the right way to do it, with certificates issued to the GStreamer organisation. But I don't know if you have the time and the desire to make this happen.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1125mpegtsmux, high overhead for a small aac bitrate2022-11-10T09:21:12ZBugzilla Migration Usermpegtsmux, high overhead for a small aac bitrate## Submitted by Vincent Génieux
**[Link to original bug (#766618)](https://bugzilla.gnome.org/show_bug.cgi?id=766618)**
## Description
I am facing an issue with the following pipeline :
audiotestsrc num-buffers=100000 ! audio/x...## Submitted by Vincent Génieux
**[Link to original bug (#766618)](https://bugzilla.gnome.org/show_bug.cgi?id=766618)**
## Description
I am facing an issue with the following pipeline :
audiotestsrc num-buffers=100000 ! audio/x-raw,channels=2 ! voaacenc
bitrate=32000 ! mpegtsmux ! filesink location=test.ts
The tsdemux generate a stream with a huge bitrate compared to other
containers, such as mp4mux :
audiotestsrc num-buffers=100000 ! audio/x-raw,channels=2 ! voaacenc
bitrate=32000 ! mp4mux ! filesink location=test.mp4
$ ls -lh test.*
-rw-r--r-- 1 vincent vincent 9.6M May 18 10:56 test.mp4
-rw-r--r-- 1 vincent vincent 26M May 18 10:57 test.ts
I think there is a misconfiguration somewhere which leads the demux to
create very small chunk with many headers. I also noticed we can reduce
the size of the ts file with libav :
$ avconv -i test.ts -codec copy test2.ts
$ ls -lh *.ts
-rw-r--r-- 1 vincent vincent 26M May 18 10:57 test.ts
-rw-r--r-- 1 vincent vincent 9.8M May 18 11:03 test2.ts
The problem is most likely that we don't combine multiple AAC packets
into a single PES packet, and thus have a lot of overhead for each of
them. ffmpeg does this for audio at least if I remember the muxer code
correctly.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/269gst-play: implement TOC parsing and add keys (6/4) for jumping to next/previo...2021-09-24T13:21:57ZBugzilla Migration Usergst-play: implement TOC parsing and add keys (6/4) for jumping to next/previous chapter## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#766559)](https://bugzilla.gnome.org/show_bug.cgi?id=766559)**
## Description
Created attachment 328054
gst-play: implement TOC parsing and add keys (6/4) for jum...## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#766559)](https://bugzilla.gnome.org/show_bug.cgi?id=766559)**
## Description
Created attachment 328054
gst-play: implement TOC parsing and add keys (6/4) for jumping to next/previous chapter
descriptive summary is descriptive
**Patch 328054**, "gst-play: implement TOC parsing and add keys (6/4) for jumping to next/previous chapter":
[0001-implement-TOC-parsing-and-add-keys-6-4-jumping-to-ne.patch](/uploads/a1c3b79c7e08f2bfb80bee8c178f1a73/0001-implement-TOC-parsing-and-add-keys-6-4-jumping-to-ne.patch)
Version: 1.8.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/274souhttpsrc: Handle redirects to non-HTTP URLs2021-09-24T13:31:43ZBugzilla Migration Usersouhttpsrc: Handle redirects to non-HTTP URLs## Submitted by Carlos Rafael Giani
**[Link to original bug (#766555)](https://bugzilla.gnome.org/show_bug.cgi?id=766555)**
## Description
Sometimes, HTTP URLs might respond with 302/303 redirect to a non-HTTP URL. Some radio statio...## Submitted by Carlos Rafael Giani
**[Link to original bug (#766555)](https://bugzilla.gnome.org/show_bug.cgi?id=766555)**
## Description
Sometimes, HTTP URLs might respond with 302/303 redirect to a non-HTTP URL. Some radio stations do this to redirect to mms:// URLs for example. In such cases, souphttpsrc does not redirect properly. Add code to post a redirect message in case of non-HTTP URLs.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/172identity: add property keep every N-th buffer2021-09-24T11:10:14ZBugzilla Migration Useridentity: add property keep every N-th buffer## Submitted by Gregoire
**[Link to original bug (#766537)](https://bugzilla.gnome.org/show_bug.cgi?id=766537)**
## Description
Created attachment 328029
Patch identity drop every N frame
Here is a patch against head to add a...## Submitted by Gregoire
**[Link to original bug (#766537)](https://bugzilla.gnome.org/show_bug.cgi?id=766537)**
## Description
Created attachment 328029
Patch identity drop every N frame
Here is a patch against head to add a property to the identity plugin in order to drop every N frames.
It seems to be a no-risk patch and add an handy feature if one wants to drop every other frame for instance.
~~**Patch 328029**~~, "Patch identity drop every N frame":
[identity-drop.patch](/uploads/f717964df0e30d8a5018f24cc09b268c/identity-drop.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/391androidmedia: Reverse Play2021-09-24T14:34:24ZBugzilla Migration Userandroidmedia: Reverse Play## Submitted by Andy Devar
**[Link to original bug (#766514)](https://bugzilla.gnome.org/show_bug.cgi?id=766514)**
## Description
Reverse play (negative rates) do not work with androidmedia.
Application: https://cgit.freede...## Submitted by Andy Devar
**[Link to original bug (#766514)](https://bugzilla.gnome.org/show_bug.cgi?id=766514)**
## Description
Reverse play (negative rates) do not work with androidmedia.
Application: https://cgit.freedesktop.org/~slomo/gst-sdk-tutorials/tree/gst-sdk/tutorials/android-tutorial-5
To change to reverse direction, I added the following code:
/* Send seek event to change rate */
static void send_seek_event (CustomData *data) {
gint64 position;
GstEvent *seek_event;
/* Obtain the current position, needed for the seek event */
if (!gst_element_query_position (data->pipeline, GST_FORMAT_TIME, &position)) {
GST_DEBUG ("Unable to retrieve current position.\n");
return;
}
/* Get video sink */
if (data->video_sink == NULL) {
// If we have not done so, obtain the sink through which we will send the seek events
g_object_get (data->pipeline, "video-sink", &data->video_sink, NULL);
}
/* Create the seek event */
if (data->rate > 0) {
gst_element_seek(data->video_sink, data->rate, GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_ACCURATE,
GST_SEEK_TYPE_SET, position, GST_SEEK_TYPE_NONE, 0);
} else {
gst_element_seek(data->video_sink, data->rate, GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_ACCURATE | GST_SEEK_FLAG_TRICKMODE_KEY_UNITS | GST_SEEK_FLAG_TRICKMODE_NO_AUDIO,
GST_SEEK_TYPE_SET, 0, GST_SEEK_TYPE_SET, position);
}
GST_DEBUG ("Current rate: %g\n", data->rate);
}
static void gst_native_change_direction (JNIEnv* env, jobject thiz) {
CustomData *data = GET_CUSTOM_DATA (env, thiz, custom_data_field_id);
if (!data) return;
data->rate *= -1.0;
send_seek_event (data);
}
As in the original tutorial-5, I use playbin:
data->pipeline = gst_parse_launch("playbin", &error);
Results:
1. With androidmedia:
a) Forward play (rate=1):
Videos play smoothly (tried up to 1980x800) regardless of GOP size.
b) Reverse play (rate=-1):
A new frame is displayed only every few seconds. Eventually, video stops to play.
Same behavior regardless of resolution (even with 320x132) and GOP size (tried dynamic, 5 and 1).
CPU utilisation is no higher than with forward play, so I assume hardware acceleration is also used with reverse play.
2. Without androidmedia (commented out in plugins.mk):
(just for comparison - meets my expectation)
a) Forward play (rate=1):
1280x532, dynamic GOP size: Smooth
1280x532, GOP size 1: Smooth
640x266, dynamic GOP size: Smooth
640x266, GOP size 1: Smooth
b) Reverse play (rate=-1):
1280x532, dynamic GOP size: Choppy
1280x532, GOP size 1: Choppy
640x266, GOP size 1: Smooth
640x266, dynamic GOP size: Choppy
The video I used can be downloaded here:
http://www.dvdloc8.com/clip.php?movieid=12167&clipid=3
To create other resolutions/GOP sizes, I used FFMPEG.
Example (GOP size 1, resolution 640x266):
ffmpeg -i "The Simpsons Movie - 1080p Trailer.mp4" -g 1 scale=640:266 "The Simpsons Movie - 1080p Trailer_GOP0001_640.mp4"
Hardware: Lenovo Tab2 A10/30
Qualcomm APQ8009
Android 5.1.1
Version: 1.8.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/268videoscale: ignores possible passthrough in fixate_caps2021-09-24T13:21:57ZBugzilla Migration Uservideoscale: ignores possible passthrough in fixate_caps## Submitted by Matthew Waters `@ystreet`
**[Link to original bug (#766477)](https://bugzilla.gnome.org/show_bug.cgi?id=766477)**
## Description
While implementing [bug 756935](https://bugzilla.gnome.org/show_bug.cgi?id=756935), I n...## Submitted by Matthew Waters `@ystreet`
**[Link to original bug (#766477)](https://bugzilla.gnome.org/show_bug.cgi?id=766477)**
## Description
While implementing [bug 756935](https://bugzilla.gnome.org/show_bug.cgi?id=756935), I noticed that videoscale ignores the unfixed width/height and ends up scaling itself rather than in the sink.
If upstream has fixed caps (e.g. from a video file) and a preferred width/height in the first structure and unfixed width/height in subsequent structure/s, then videoscale is truncating before attempting to fixate which will lose the unfixed caps.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/389kmssink: add libdrm in gst-libs/ext2021-09-24T14:34:24ZBugzilla Migration Userkmssink: add libdrm in gst-libs/ext## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#766468)](https://bugzilla.gnome.org/show_bug.cgi?id=766468)**
## Description
It would be nice to add libdrm/libkms in gst-libs/ext so the users won't nee...## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#766468)](https://bugzilla.gnome.org/show_bug.cgi?id=766468)**
## Description
It would be nice to add libdrm/libkms in gst-libs/ext so the users won't need to have installed it in their systems (small embedded systems), also we could add particular hacks there for specific SoCs.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/273rtpmp4adepay: Should reject caps without codec configuration2021-09-24T13:31:43ZBugzilla Migration Userrtpmp4adepay: Should reject caps without codec configuration## Submitted by Peter Maersk-Moller
**[Link to original bug (#766267)](https://bugzilla.gnome.org/show_bug.cgi?id=766267)**
## Description
Trying to RTP stream AAC audio fails. The modules aacparse, avdec_aac or decodebin all fails ...## Submitted by Peter Maersk-Moller
**[Link to original bug (#766267)](https://bugzilla.gnome.org/show_bug.cgi?id=766267)**
## Description
Trying to RTP stream AAC audio fails. The modules aacparse, avdec_aac or decodebin all fails to output packets. Probable cause is something with rtpmp4apay/rtpmp4adepay.
Scripts documenting the problem:
Sender (one of the following):
$ AUDIO='audio/x-raw,rate=48000,channels=2'
$ gst-launch-1.0 -v audiotestsrc is-live=1 ! $AUDIO ! faac ! queue ! rtpmp4apay ! udpsink host=127.0.0.1 port=14002
$ gst-launch-1.0 -v audiotestsrc is-live=1 ! $AUDIO ! avenc_aac ! queue ! rtpmp4apay ! udpsink host=127.0.0.1 port=14002
$ gst-launch-1.0 -v audiotestsrc is-live=1 ! $AUDIO ! avenc_aac compliance=-2 ! queue ! rtpmp4apay ! udpsink host=127.0.0.1 port=14002
Receiver:
$ gst-launch-1.0 -v udpsrc port=14002 caps="application/x-rtp,media=audio,payload=96,clock-rate=48000,encoding-name=MP4A-LATM" do-timestamp=1 ! rtpmp4adepay ! aacparse ! identity silent=0 ! fakesink
At the receiver end you will see no packets coming from aacparse. You can replace aacparse with avdec_aac or decodebin and get same result.
Regards
Peterhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/267gst-play: Port to GstPlayer with a private copy for the time being2021-09-24T13:21:56ZBugzilla Migration Usergst-play: Port to GstPlayer with a private copy for the time being## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#766256)](https://bugzilla.gnome.org/show_bug.cgi?id=766256)**
## Description
See summary. We probably have all features now in GstPlayer but needs to be checked.
...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#766256)](https://bugzilla.gnome.org/show_bug.cgi?id=766256)**
## Description
See summary. We probably have all features now in GstPlayer but needs to be checked.
https://github.com/sdroege/gst-player/tree/master/gst-play has a port of it based on a much older version of gst-play.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/171gst-launch: Does not support non-UTF8 shell2021-09-24T11:10:14ZBugzilla Migration Usergst-launch: Does not support non-UTF8 shell## Submitted by Martin Proksa
**[Link to original bug (#766214)](https://bugzilla.gnome.org/show_bug.cgi?id=766214)**
## Description
Writing stream to file with local characters in filename fails on windows to open file with that na...## Submitted by Martin Proksa
**[Link to original bug (#766214)](https://bugzilla.gnome.org/show_bug.cgi?id=766214)**
## Description
Writing stream to file with local characters in filename fails on windows to open file with that name. Same filename works fine on linux.
example of problem:
gst-launch-1.0 videotestsrc ! filesink location=tést.raw
fails with
WARNING: erroneous pipeline: no element "filesink"
works fine:
gst-launch-1.0 videotestsrc ! filesink location=test.raw
Problem is in function gst_fopen in file gstfilesink.c, this function expect its argument filename to be in UTF8, but in fact filename is in ASCII and character é is represented as single BYTE 0xE9.
Converting filename to UTF8 before calling g_utf8_to_utf16 solves the problem.
gchar *ufilename = g_locale_to_utf8(filename, -1, NULL, NULL, NULL);
wchar_t *wfilename = g_utf8_to_utf16 (ufilename, -1, NULL, NULL, NULL);
Version: 1.6.3https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/388video decoding issue with mp4 container (Android playback)2021-09-24T14:34:23ZBugzilla Migration Uservideo decoding issue with mp4 container (Android playback)## Submitted by Gregoire
**[Link to original bug (#766201)](https://bugzilla.gnome.org/show_bug.cgi?id=766201)**
## Description
Summary: The presence of audio in an mp4 audio/video file confused typefind and decodebin to the point t...## Submitted by Gregoire
**[Link to original bug (#766201)](https://bugzilla.gnome.org/show_bug.cgi?id=766201)**
## Description
Summary: The presence of audio in an mp4 audio/video file confused typefind and decodebin to the point that the pipeline can't find the video decoder plugin.
I have two videos generated by gstreamer-0.10 on an embedded device. The same video encoder is used in both cases:
[1] video/videov.mp4 has only a h264 track. mp4info video/videov.mp4 reports:
videov.mp4:
Track Type Info
1 video H264 Baseline@4, 7.716 secs, 16614 kbps, 1280x1440 @ 50.155521 fps
[2] videoaudio/videov.mp4 has a h264 track and a mp3 track. mp4info videoaudio/videov.mp4 reports:
videov.mp4:
Track Type Info
1 video H264 Baseline@4, 7.199 secs, 16614 kbps, 1280x1440 @ 50.145854 fps
2 audio MPEG-1 Audio (11172-3), 7.176 secs, 48 kbps, 24000 Hz
The two files are provided here: http://gentil.com/tmp/samples.zip
I play both files on a PixelC Android 6.x tablet with gstreamer 1.7.91. Note that I have the same issue on Nexus 5x. The two pipeplines are:
[1] video/videov.mp4
filesrc location=/storage/emulated/0/aiTennis3D/video/videov.mp4 ! qtdemux name=q q.video_0 ! queue ! decodebin name=forhwgl ! queue ! identity name=forhalffps ! glimagesink force-aspect-ratio=false
[2] videoaudio/videov.mp4
filesrc location=/storage/emulated/0/aiTennis3D/videoaudio/videov.mp4 ! qtdemux name=q q.video_0 ! queue ! decodebin name=forhwgl ! queue ! identity name=forhalffps ! glimagesink force-aspect-ratio=false q.audio_0 ! queue ! decodebin ! queue ! autoaudiosink
When playing the video only file, there is no problem. log log-video.zip is attached.
When playing the video/audio file, gstreamer can't find the video decoder plugin. The log log-videoaudio.zip is attached.
A few additional notes:
- amcviddec-omxnvidiah264decode doesn't seem to be instantiated in the second case.
- The problem is the same with a simple playbin pipeline.
- If I replace decodebin by "h264parse ! amcviddec-omxnvidiah264decode", it's working.