GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2019-03-15T21:27:40Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/219audioencoder: timestamp headers same as first buffer and use duration 02019-03-15T21:27:40ZBugzilla Migration Useraudioencoder: timestamp headers same as first buffer and use duration 0## Submitted by Håvard Graff (hgr)
**[Link to original bug (#754224)](https://bugzilla.gnome.org/show_bug.cgi?id=754224)**
## Description
Created attachment 310164
patch
It makes sense that the headers being pushed out just before the first buffer should be timestamped like the first buffer.
As for duration 0, I think this makes more sense then -1, and plays nicer with muxers etc.
**Patch 310164**, "patch":
[audioencoder-headers-timestamp.patch](/uploads/07c95389623bba9533b9fecbaa820c76/audioencoder-headers-timestamp.patch)
### Depends on
* [Bug 754223](https://bugzilla.gnome.org/show_bug.cgi?id=754223)
### Blocking
* [Bug 754226](https://bugzilla.gnome.org/show_bug.cgi?id=754226)
* [Bug 756386](https://bugzilla.gnome.org/show_bug.cgi?id=756386)## Submitted by Håvard Graff (hgr)
**[Link to original bug (#754224)](https://bugzilla.gnome.org/show_bug.cgi?id=754224)**
## Description
Created attachment 310164
patch
It makes sense that the headers being pushed out just before the first buffer should be timestamped like the first buffer.
As for duration 0, I think this makes more sense then -1, and plays nicer with muxers etc.
**Patch 310164**, "patch":
[audioencoder-headers-timestamp.patch](/uploads/07c95389623bba9533b9fecbaa820c76/audioencoder-headers-timestamp.patch)
### Depends on
* [Bug 754223](https://bugzilla.gnome.org/show_bug.cgi?id=754223)
### Blocking
* [Bug 754226](https://bugzilla.gnome.org/show_bug.cgi?id=754226)
* [Bug 756386](https://bugzilla.gnome.org/show_bug.cgi?id=756386)Bugzillahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/218payloaders: memory performance2019-03-15T21:27:40ZBugzilla Migration Userpayloaders: memory performance## Submitted by Miguel París Díaz `@mparisdiaz`
**[Link to original bug (#754189)](https://bugzilla.gnome.org/show_bug.cgi?id=754189)**
## Description
Hello,
I have done some profiling about some payloaders and I have realized that an important CPU percentage is used for memory management:
1 - allocating and freeing RTP buffers
2 - mapping/unmapping RTP buffers
Possible solutions to improve efficiency:
1 - Could we use a kind of buffer pool instead of creating new buffers and freeing again and again?
2 - Could be a way of improve mapping/unmapping of RTP buffers?
---- PROFILE REPORT ----
VP8 payloader:
gst-launch-1.5 videotestsrc num-buffers=100 ! vp8enc ! rtpvp8pay ! fakesink enable-last-sample=false
Percentages of usage (with gst_rtp_base_payload_chain as root):
100 - gst_rtp_base_payload_chain (ir per call: 15283)
98.67 - gst_rtp_vp8_pay_handle_buffer
7.29 - gst_buffer_copy_region
4.18 - gst_buffer_append
29.67 - gst_rtp_vp8_create_header_buffer
17.94 - gst_rtp_buffer_new_allocate
14.57 - gst_rtp_buffer_allocate_data
3.16 - gst_buffer_new
35.24 - gst_rtp_base_payload_push_list
8.96 - gst_rtp_base_payload_prepare_push
6.65 - set_headers
4.24 - gst_rtp_buffer_map
1.42 - gst_rtp_buffer_unmap
22.41 - gst_base_sink_chain_list
12.38 - gst_mini_object_unref
7.13 - _gst_buffer_list_free
3.94 - _gst_buffer_free
OPUS payloader
gst-launch-1.5 audiotestsrc num-buffers=1000 ! opusenc ! rtpopuspay ! fakesink enable-last-sample=false
Percentages of usage (with gst_rtp_base_payload_chain as root):
100 - gst_rtp_base_payload_chain
96.62 - gst_rtp_opus_pay_handle_buffer
8.38 - gst_buffer_append
22.56 - gst_rtp_buffer_new_allocate
16,83 - gst_rtp_buffer_allocate_data
5.31 - gst_buffer_new
63.42 - gst_rtp_base_payload_push
16.40 - gst_rtp_base_payload_prepare_push
12.98 - set_headers
8.04 - gst_rtp_buffer_map
2.92 - gst_rtp_buffer_unmap
37.62 - gst_base_sink_chain
20.98 - gst_mini_object_unref
18.97 - _gst_buffer_free
Version: 1.5.2## Submitted by Miguel París Díaz `@mparisdiaz`
**[Link to original bug (#754189)](https://bugzilla.gnome.org/show_bug.cgi?id=754189)**
## Description
Hello,
I have done some profiling about some payloaders and I have realized that an important CPU percentage is used for memory management:
1 - allocating and freeing RTP buffers
2 - mapping/unmapping RTP buffers
Possible solutions to improve efficiency:
1 - Could we use a kind of buffer pool instead of creating new buffers and freeing again and again?
2 - Could be a way of improve mapping/unmapping of RTP buffers?
---- PROFILE REPORT ----
VP8 payloader:
gst-launch-1.5 videotestsrc num-buffers=100 ! vp8enc ! rtpvp8pay ! fakesink enable-last-sample=false
Percentages of usage (with gst_rtp_base_payload_chain as root):
100 - gst_rtp_base_payload_chain (ir per call: 15283)
98.67 - gst_rtp_vp8_pay_handle_buffer
7.29 - gst_buffer_copy_region
4.18 - gst_buffer_append
29.67 - gst_rtp_vp8_create_header_buffer
17.94 - gst_rtp_buffer_new_allocate
14.57 - gst_rtp_buffer_allocate_data
3.16 - gst_buffer_new
35.24 - gst_rtp_base_payload_push_list
8.96 - gst_rtp_base_payload_prepare_push
6.65 - set_headers
4.24 - gst_rtp_buffer_map
1.42 - gst_rtp_buffer_unmap
22.41 - gst_base_sink_chain_list
12.38 - gst_mini_object_unref
7.13 - _gst_buffer_list_free
3.94 - _gst_buffer_free
OPUS payloader
gst-launch-1.5 audiotestsrc num-buffers=1000 ! opusenc ! rtpopuspay ! fakesink enable-last-sample=false
Percentages of usage (with gst_rtp_base_payload_chain as root):
100 - gst_rtp_base_payload_chain
96.62 - gst_rtp_opus_pay_handle_buffer
8.38 - gst_buffer_append
22.56 - gst_rtp_buffer_new_allocate
16,83 - gst_rtp_buffer_allocate_data
5.31 - gst_buffer_new
63.42 - gst_rtp_base_payload_push
16.40 - gst_rtp_base_payload_prepare_push
12.98 - set_headers
8.04 - gst_rtp_buffer_map
2.92 - gst_rtp_buffer_unmap
37.62 - gst_base_sink_chain
20.98 - gst_mini_object_unref
18.97 - _gst_buffer_free
Version: 1.5.2EnhancementBugzillahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/217audiobasesrc/ringbuffer: Uses too small integers for segment counters2019-03-15T21:27:40ZBugzilla Migration Useraudiobasesrc/ringbuffer: Uses too small integers for segment counters## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#754180)](https://bugzilla.gnome.org/show_bug.cgi?id=754180)**
## Description
See https://github.com/EricssonResearch/openwebrtc/pull/456 for some discussion. Problem is this code: http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/gst-libs/gst/audio/gstaudiobasesrc.c#n927
running_time_segment is only an integer (as required by g_atomic_int_*), and will overflow after a while. And it will cause problems immediately if having a huge running time, e.g. when explicitly setting base_time=0 and having a clock with a high current time.
Not sure yet how to fix this as the segment counters are part of the public API unfortunately, and also there are not atomic ops on 64 bit integers.
### Depends on
* [Bug 754182](https://bugzilla.gnome.org/show_bug.cgi?id=754182)## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#754180)](https://bugzilla.gnome.org/show_bug.cgi?id=754180)**
## Description
See https://github.com/EricssonResearch/openwebrtc/pull/456 for some discussion. Problem is this code: http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/gst-libs/gst/audio/gstaudiobasesrc.c#n927
running_time_segment is only an integer (as required by g_atomic_int_*), and will overflow after a while. And it will cause problems immediately if having a huge running time, e.g. when explicitly setting base_time=0 and having a clock with a high current time.
Not sure yet how to fix this as the segment counters are part of the public API unfortunately, and also there are not atomic ops on 64 bit integers.
### Depends on
* [Bug 754182](https://bugzilla.gnome.org/show_bug.cgi?id=754182)Bugzillahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/216videoconvert: overlay negotiation fails2019-03-15T21:27:40ZBugzilla Migration Uservideoconvert: overlay negotiation fails## Submitted by Arnaud Vrac `@rawoul`
**[Link to original bug (#754076)](https://bugzilla.gnome.org/show_bug.cgi?id=754076)**
## Description
Created attachment 309955
videoconvert: properly transform caps containing added features
With the following pipeline overlay negotiation fails between textoverlay and the sink:
gst-launch-1.0 videotestsrc ! video/x-raw,format=YUV9 ! textoverlay text=YEAH font-desc="Arial 60" ! videoconvert ! glimagesink
The caps filter forces videoconvert in non-passthrough mode. The transform_meta and filter_meta callbacks in videoconvert do let the overlay composition meta pass, but the caps transformation function (that remove the video format info) does not account for it. This means the caps with SystemMemory and other caps features will be ignored.
The attached patch fixes this issue.
Note that there are probably other elements with the same issue. videoscale for example, but in this case it's more complicated because we also need to scale the overlay composition.
**Patch 309955**, "videoconvert: properly transform caps containing added features":
[0001-videoconvert-properly-transform-caps-containing-adde.patch](/uploads/ee4bac406b52d3fc0e7e229cfe822716/0001-videoconvert-properly-transform-caps-containing-adde.patch)## Submitted by Arnaud Vrac `@rawoul`
**[Link to original bug (#754076)](https://bugzilla.gnome.org/show_bug.cgi?id=754076)**
## Description
Created attachment 309955
videoconvert: properly transform caps containing added features
With the following pipeline overlay negotiation fails between textoverlay and the sink:
gst-launch-1.0 videotestsrc ! video/x-raw,format=YUV9 ! textoverlay text=YEAH font-desc="Arial 60" ! videoconvert ! glimagesink
The caps filter forces videoconvert in non-passthrough mode. The transform_meta and filter_meta callbacks in videoconvert do let the overlay composition meta pass, but the caps transformation function (that remove the video format info) does not account for it. This means the caps with SystemMemory and other caps features will be ignored.
The attached patch fixes this issue.
Note that there are probably other elements with the same issue. videoscale for example, but in this case it's more complicated because we also need to scale the overlay composition.
**Patch 309955**, "videoconvert: properly transform caps containing added features":
[0001-videoconvert-properly-transform-caps-containing-adde.patch](/uploads/ee4bac406b52d3fc0e7e229cfe822716/0001-videoconvert-properly-transform-caps-containing-adde.patch)Bugzillahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/215tags: Add support for ImageNumber / ImageID EXIF tags2019-03-15T21:27:40ZBugzilla Migration Usertags: Add support for ImageNumber / ImageID EXIF tags## Submitted by min..@..arp.fm
**[Link to original bug (#753781)](https://bugzilla.gnome.org/show_bug.cgi?id=753781)**
## Description
The following patch adds support for ImageNumber / ImageID tags:
#define EXIF_TAG_IMAGE_ID 0x800d
#define EXIF_TAG_IMAGE_NUMBER 0x9211## Submitted by min..@..arp.fm
**[Link to original bug (#753781)](https://bugzilla.gnome.org/show_bug.cgi?id=753781)**
## Description
The following patch adds support for ImageNumber / ImageID tags:
#define EXIF_TAG_IMAGE_ID 0x800d
#define EXIF_TAG_IMAGE_NUMBER 0x9211EnhancementBugzillahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/214tags: Add support for CinemaDNG EXIF tags2019-03-15T21:27:40ZBugzilla Migration Usertags: Add support for CinemaDNG EXIF tags## Submitted by min..@..arp.fm
**[Link to original bug (#753779)](https://bugzilla.gnome.org/show_bug.cgi?id=753779)**
## Description
Created attachment 309506
Patch file
This patch adds support for the following CinemaDNG EXIF tags:
/* Cinema DNG */
#define DNGTAG_TimeCodes 0xC763 /* 51043 */
#define DNGTAG_FrameRate 0xC764 /* 51044 */
#define DNGTAG_TStop 0xC772 /* 51058 */
#define DNGTAG_ReelName 0xC789 /* 51081 */
#define DNGTAG_CameraLabel 0xC7A1 /* 51105 */
~~**Patch 309506**~~, "Patch file":
[gstreamer-exifcinemadng.patch](/uploads/b9068a77112a1d8459d05c670d6a22dc/gstreamer-exifcinemadng.patch)
### Depends on
* [Bug 753922](https://bugzilla.gnome.org/show_bug.cgi?id=753922)## Submitted by min..@..arp.fm
**[Link to original bug (#753779)](https://bugzilla.gnome.org/show_bug.cgi?id=753779)**
## Description
Created attachment 309506
Patch file
This patch adds support for the following CinemaDNG EXIF tags:
/* Cinema DNG */
#define DNGTAG_TimeCodes 0xC763 /* 51043 */
#define DNGTAG_FrameRate 0xC764 /* 51044 */
#define DNGTAG_TStop 0xC772 /* 51058 */
#define DNGTAG_ReelName 0xC789 /* 51081 */
#define DNGTAG_CameraLabel 0xC7A1 /* 51105 */
~~**Patch 309506**~~, "Patch file":
[gstreamer-exifcinemadng.patch](/uploads/b9068a77112a1d8459d05c670d6a22dc/gstreamer-exifcinemadng.patch)
### Depends on
* [Bug 753922](https://bugzilla.gnome.org/show_bug.cgi?id=753922)EnhancementBugzillahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/213exif: write_exif_integer_tag_from_taglist: Silently ignores unsigned int values2019-03-15T21:27:40ZBugzilla Migration Userexif: write_exif_integer_tag_from_taglist: Silently ignores unsigned int values## Submitted by min..@..arp.fm
**[Link to original bug (#753773)](https://bugzilla.gnome.org/show_bug.cgi?id=753773)**
## Description
Created attachment 309502
Patch to fix the problem
The write_exif_integer_tag_from_taglist() function will only write the value if the GValue is a signed integer, unsigned integers are not supported (even though both EXIF short and long are unsigned).
Patch attached to fix this.
~~**Patch 309502**~~, "Patch to fix the problem":
[gstreamer-exifinteger.patch](/uploads/6a586e58f9f3ff7672925afbf8440ef1/gstreamer-exifinteger.patch)## Submitted by min..@..arp.fm
**[Link to original bug (#753773)](https://bugzilla.gnome.org/show_bug.cgi?id=753773)**
## Description
Created attachment 309502
Patch to fix the problem
The write_exif_integer_tag_from_taglist() function will only write the value if the GValue is a signed integer, unsigned integers are not supported (even though both EXIF short and long are unsigned).
Patch attached to fix this.
~~**Patch 309502**~~, "Patch to fix the problem":
[gstreamer-exifinteger.patch](/uploads/6a586e58f9f3ff7672925afbf8440ef1/gstreamer-exifinteger.patch)Bugzillahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/212opusenc: Bitrate limit is too low2019-03-15T21:27:39ZBugzilla Migration Useropusenc: Bitrate limit is too low## Submitted by cai..@..il.com
**[Link to original bug (#753737)](https://bugzilla.gnome.org/show_bug.cgi?id=753737)**
## Description
Created attachment 309431
opusenc: Raise bitrate limit
The bitrate property has a limit of 650 kb/s. However the actual valid limit is around 255 kb/s per channel, and Opus supports up to 8 channels with defined mappings, and up to 255 channels with a user-defined mapping.
**Patch 309431**, "opusenc: Raise bitrate limit":
[0001-opusenc-Raise-bitrate-limit.patch](/uploads/94891bccf58e2bb0587153cb5e9bb6d7/0001-opusenc-Raise-bitrate-limit.patch)## Submitted by cai..@..il.com
**[Link to original bug (#753737)](https://bugzilla.gnome.org/show_bug.cgi?id=753737)**
## Description
Created attachment 309431
opusenc: Raise bitrate limit
The bitrate property has a limit of 650 kb/s. However the actual valid limit is around 255 kb/s per channel, and Opus supports up to 8 channels with defined mappings, and up to 255 channels with a user-defined mapping.
**Patch 309431**, "opusenc: Raise bitrate limit":
[0001-opusenc-Raise-bitrate-limit.patch](/uploads/94891bccf58e2bb0587153cb5e9bb6d7/0001-opusenc-Raise-bitrate-limit.patch)EnhancementBugzillahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/211theoraenc/oggmux: advertise fixed-framerate-ness properly, allow non-fixed fr...2019-03-15T21:27:39ZBugzilla Migration Usertheoraenc/oggmux: advertise fixed-framerate-ness properly, allow non-fixed framerate in theoranc for RTP etc.## Submitted by Tim Müller `@tpm`
**[Link to original bug (#753517)](https://bugzilla.gnome.org/show_bug.cgi?id=753517)**
## Description
+++ This bug was initially created as a clone of [Bug 748877](https://bugzilla.gnome.org/show_bug.cgi?id=748877) +++
Cloning this as a reminder and to collect ideas. Not sure if we really need to do anything or not.
theoraenc currently doesn't work with framerate=0/1 but enforces a fixed framerate. The fixed framerate-ness is really a property of the ogg mapping though, not of the Theora codec or library per se (fact?). If that is actually the case, we should add the framerate limitation for theora to the oggmux template caps and expand the theoraenc caps, so that theoraenc can produce/handle framerate=0/1 for RTP/other containers.## Submitted by Tim Müller `@tpm`
**[Link to original bug (#753517)](https://bugzilla.gnome.org/show_bug.cgi?id=753517)**
## Description
+++ This bug was initially created as a clone of [Bug 748877](https://bugzilla.gnome.org/show_bug.cgi?id=748877) +++
Cloning this as a reminder and to collect ideas. Not sure if we really need to do anything or not.
theoraenc currently doesn't work with framerate=0/1 but enforces a fixed framerate. The fixed framerate-ness is really a property of the ogg mapping though, not of the Theora codec or library per se (fact?). If that is actually the case, we should add the framerate limitation for theora to the oggmux template caps and expand the theoraenc caps, so that theoraenc can produce/handle framerate=0/1 for RTP/other containers.EnhancementBugzillahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/210Opus: playback gain always relative to EBU R128 level (-23db LUFS), must be p...2019-03-15T21:27:39ZBugzilla Migration UserOpus: playback gain always relative to EBU R128 level (-23db LUFS), must be played 5db louder to match ReplayGain level (-18db LUFS) when using ReplayGain## Submitted by Nikolaus Waxweiler `@madig`
**[Link to original bug (#753275)](https://bugzilla.gnome.org/show_bug.cgi?id=753275)**
## Description
(not sure if this is the correct place to ask for this)
I use Clementine (GStreamer-based) and ReplayGain all my music. I noticed that while playing around with the new Opus format, those files are played much quieter than music in other formats. After digging around, I found: Opus files are by design always normalized to -23db LUFS (R128), while ReplayGain defaults to -18db LUFS. Foobar2000 seems to simply preamp these files +5db when playing. Could GStreamer do the same? Or maybe take an argument of what reference level to use so players can set and forget it?
(Maybe related: [Bug 751534](https://bugzilla.gnome.org/show_bug.cgi?id=751534))## Submitted by Nikolaus Waxweiler `@madig`
**[Link to original bug (#753275)](https://bugzilla.gnome.org/show_bug.cgi?id=753275)**
## Description
(not sure if this is the correct place to ask for this)
I use Clementine (GStreamer-based) and ReplayGain all my music. I noticed that while playing around with the new Opus format, those files are played much quieter than music in other formats. After digging around, I found: Opus files are by design always normalized to -23db LUFS (R128), while ReplayGain defaults to -18db LUFS. Foobar2000 seems to simply preamp these files +5db when playing. Could GStreamer do the same? Or maybe take an argument of what reference level to use so players can set and forget it?
(Maybe related: [Bug 751534](https://bugzilla.gnome.org/show_bug.cgi?id=751534))Bugzillahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/209glupload: Raw upload could be optimized using a BufferPool2019-03-15T21:27:39ZBugzilla Migration Userglupload: Raw upload could be optimized using a BufferPool## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#752961)](https://bugzilla.gnome.org/show_bug.cgi?id=752961)**
## Description
Currently when doing raw upload, we create a new GstBuffer and set of new texture every time we receives an input. This could be slightly optimized by reusing the textures through a BufferPool.
Note that a mechanism would be needed to properly attach the mapped input buffer so the buffer pool can detach it when the buffer comes back to the pool. What I would saggest is to add a method to attach the user_data/GDestroyNotify pair as qdata to each memory using a well known name. Then the pool reset() method could remove this qdata on each memory. The destroy notify would also be called if the memory is destroyed outside of the buffer.## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#752961)](https://bugzilla.gnome.org/show_bug.cgi?id=752961)**
## Description
Currently when doing raw upload, we create a new GstBuffer and set of new texture every time we receives an input. This could be slightly optimized by reusing the textures through a BufferPool.
Note that a mechanism would be needed to properly attach the mapped input buffer so the buffer pool can detach it when the buffer comes back to the pool. What I would saggest is to add a method to attach the user_data/GDestroyNotify pair as qdata to each memory using a well known name. Then the pool reset() method could remove this qdata on each memory. The destroy notify would also be called if the memory is destroyed outside of the buffer.EnhancementBugzillahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/208crossfade: New example for crossfading audio tracks using audiomixer2019-03-15T21:27:39ZBugzilla Migration Usercrossfade: New example for crossfading audio tracks using audiomixer## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#752762)](https://bugzilla.gnome.org/show_bug.cgi?id=752762)**
## Description
Created attachment 307971
crossfade: New example for crossfading audio tracks using audiomixer
/*
* crossfade: An example application to play a list of audio files with
* cross-fade between each file.
*
* This example application uses the audiomixer element combined with
* GstController and pad probes to play a list of audio files in such a way that
* the audio is cross-faded while switching between files.
*
* Each file is played by a decoder bin inside each CrossfadeItem. This bin has
* a queue right before its srcpad which has a "max-size-time" of
* 2 * CROSSFADE_TIME_MS. When an EOS is detected on the sinkpad of this queue,
* the next CrossfadeItem is attached to audiomixer, the correct pad offset is
* set, and fadein/fadeout is scheduled using GstControlSources.
*
* A crossfade can also be scheduled immediately by switching to the next item
* "early" using crossfade_app_activate_next_item_early().
*
* The list of CrossfadeItems can be edited and added to dynamically; except the
* currently-playing item and the next one (which has been prepared already).
*
* Bugs:
* - If the size of the file being played is smaller than 3*CROSSFADE_TIME_MS
* and the file was played with a fadein crossfade (i.e., it was not the first
* file to be played), the queue before audiomixer which is used to detect a
* file going EOS will contain buffers of a total time less than
* CROSSFADE_TIME_MS. The crossfade will hence happen in whatever buffer-time
* is available.
* - If CROSSFADE_TIME_MS is set to a value less than the duration of a single
* buffer, no crossfade will happen, but the switch will be gapless.
*/
This is a decent example of how to use audiomixer for gapless/crossfade playback in an audio player. Although the example expects files, this method of doing crossfade/gapless should also work with arbitrary URIs.
**Patch 307971**, "crossfade: New example for crossfading audio tracks using audiomixer":
[0001-New-example-for-audio-crossfade-using-audiomixer-and.patch](/uploads/6d4240403aee74b2b91964b5838152b2/0001-New-example-for-audio-crossfade-using-audiomixer-and.patch)## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#752762)](https://bugzilla.gnome.org/show_bug.cgi?id=752762)**
## Description
Created attachment 307971
crossfade: New example for crossfading audio tracks using audiomixer
/*
* crossfade: An example application to play a list of audio files with
* cross-fade between each file.
*
* This example application uses the audiomixer element combined with
* GstController and pad probes to play a list of audio files in such a way that
* the audio is cross-faded while switching between files.
*
* Each file is played by a decoder bin inside each CrossfadeItem. This bin has
* a queue right before its srcpad which has a "max-size-time" of
* 2 * CROSSFADE_TIME_MS. When an EOS is detected on the sinkpad of this queue,
* the next CrossfadeItem is attached to audiomixer, the correct pad offset is
* set, and fadein/fadeout is scheduled using GstControlSources.
*
* A crossfade can also be scheduled immediately by switching to the next item
* "early" using crossfade_app_activate_next_item_early().
*
* The list of CrossfadeItems can be edited and added to dynamically; except the
* currently-playing item and the next one (which has been prepared already).
*
* Bugs:
* - If the size of the file being played is smaller than 3*CROSSFADE_TIME_MS
* and the file was played with a fadein crossfade (i.e., it was not the first
* file to be played), the queue before audiomixer which is used to detect a
* file going EOS will contain buffers of a total time less than
* CROSSFADE_TIME_MS. The crossfade will hence happen in whatever buffer-time
* is available.
* - If CROSSFADE_TIME_MS is set to a value less than the duration of a single
* buffer, no crossfade will happen, but the switch will be gapless.
*/
This is a decent example of how to use audiomixer for gapless/crossfade playback in an audio player. Although the example expects files, this method of doing crossfade/gapless should also work with arbitrary URIs.
**Patch 307971**, "crossfade: New example for crossfading audio tracks using audiomixer":
[0001-New-example-for-audio-crossfade-using-audiomixer-and.patch](/uploads/6d4240403aee74b2b91964b5838152b2/0001-New-example-for-audio-crossfade-using-audiomixer-and.patch)EnhancementBugzillahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/207glfiltercube: the cube does not look like a cube2019-03-15T21:27:39ZBugzilla Migration Userglfiltercube: the cube does not look like a cube## Submitted by Julien Isorce `@cap`
**[Link to original bug (#752745)](https://bugzilla.gnome.org/show_bug.cgi?id=752745)**
## Description
glfiltercube does not output a cube :)
Instead of properly computing the Model-View-Projection matrixes, we currently provide this fixed matrix: http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gl/gstglfiltercube.c#n454
The cube was showing ok when not using shaders but since we moved to use shaders not only on gles2 I realize the cube was already wrong with gles2+GstGL-0.10 (see http://cgit.freedesktop.org/gstreamer/attic/gst-plugins-gl/commit/gst/gl/gstglfiltercube.c?id=e12532c6c5bb0fcbbf94abb6aa8e98757e536d1d)
But it requires to manually do some maths. See http://cgit.freedesktop.org/gstreamer/gst-omx/tree/examples/egl/testegl.c#n123
Maybe we can add gst_gl_matrix_load_identity/gst_gl_matrix_multiply/gst_gl_matrix_translate/gst_gl_matrix_frustum/gst_gl_matrix_perspective
It seems to me to be "a small piece of library API there" (from "master feature freeze email") but not sure.
Otherwise we keep these functions locally in glfiltercube and move them to GstGL after 1.6, see following patch.## Submitted by Julien Isorce `@cap`
**[Link to original bug (#752745)](https://bugzilla.gnome.org/show_bug.cgi?id=752745)**
## Description
glfiltercube does not output a cube :)
Instead of properly computing the Model-View-Projection matrixes, we currently provide this fixed matrix: http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gl/gstglfiltercube.c#n454
The cube was showing ok when not using shaders but since we moved to use shaders not only on gles2 I realize the cube was already wrong with gles2+GstGL-0.10 (see http://cgit.freedesktop.org/gstreamer/attic/gst-plugins-gl/commit/gst/gl/gstglfiltercube.c?id=e12532c6c5bb0fcbbf94abb6aa8e98757e536d1d)
But it requires to manually do some maths. See http://cgit.freedesktop.org/gstreamer/gst-omx/tree/examples/egl/testegl.c#n123
Maybe we can add gst_gl_matrix_load_identity/gst_gl_matrix_multiply/gst_gl_matrix_translate/gst_gl_matrix_frustum/gst_gl_matrix_perspective
It seems to me to be "a small piece of library API there" (from "master feature freeze email") but not sure.
Otherwise we keep these functions locally in glfiltercube and move them to GstGL after 1.6, see following patch.Awaiting feedbackBugzillahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/206cannot get SSRC from internal stream2019-03-15T21:27:39ZBugzilla Migration Usercannot get SSRC from internal stream## Submitted by Maciej Skrzypek
**[Link to original bug (#752108)](https://bugzilla.gnome.org/show_bug.cgi?id=752108)**
## Description
Created attachment 307056
current ssrc patch
added current-ssrc property to be able to get ssrc from internal source
**Patch 307056**, "current ssrc patch":
[current_ssrc.patch](/uploads/65679b22d43e66a4bbb8d0159eb704be/current_ssrc.patch)
Version: 1.4.5## Submitted by Maciej Skrzypek
**[Link to original bug (#752108)](https://bugzilla.gnome.org/show_bug.cgi?id=752108)**
## Description
Created attachment 307056
current ssrc patch
added current-ssrc property to be able to get ssrc from internal source
**Patch 307056**, "current ssrc patch":
[current_ssrc.patch](/uploads/65679b22d43e66a4bbb8d0159eb704be/current_ssrc.patch)
Version: 1.4.5Bugzillahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/205gst-play: print audio/video/subtitle tracks details2019-03-15T21:27:39ZBugzilla Migration Usergst-play: print audio/video/subtitle tracks details## Submitted by Hugues Fruchet
**[Link to original bug (#751903)](https://bugzilla.gnome.org/show_bug.cgi?id=751903)**
## Description
Created attachment 306712
tools: gst-play: print audio/video/subtitle tracks details
Allows to print tracks details when playbin reach playing state:
* audio
$> gst-play-1.0 /gorillaz.wav
0 video stream(s), 1 audio stream(s), 0 text stream(s)
|
|-[audio]
|-[audio stream 0]
|- codec: Uncompressed 16-bit PCM audio
* video
$> gst-play-1.0 /foreman.3gp
1 video stream(s), 0 audio stream(s), 0 text stream(s)
|-[video]
|-[video stream 0]
|- codec: H.264
* audio/video
$> gst-play-1.0 /big_buck_bunny_1080p_h264.mov
1 video stream(s), 1 audio stream(s), 0 text stream(s)
|-[video]
| |-[video stream 0]
| |- codec: H.264
|
|-[audio]
|-[audio stream 0]
|- codec: MPEG-4 AAC
|- bitrate: 359245
* audio/video/subtitles, multiple tracks
$> gst-play-1.0 "dvb://ARTE HD"
1 video stream(s), 4 audio stream(s), 3 text stream(s)
|-[video]
| |-[video stream 0]
| |- codec: H.264
|
|-[audio]
| |-[audio stream 0]
| | |- codec: MPEG-1 Layer 2 (MP2)
| | |- language: fr
| | |- bitrate: 256000
| |-[audio stream 1]
| | |- codec: MPEG-1 Layer 2 (MP2)
| | |- language: qaa
| | |- bitrate: 256000
| |-[audio stream 2]
| | |- codec: MPEG-1 Layer 2 (MP2)
| | |- language: de
| | |- bitrate: 128000
| |-[audio stream 3]
| |- codec: MPEG-1 Layer 2 (MP2)
| |- language: qad
| |- bitrate: 128000
|
|-[subtitle]
|-[subtitle stream 0]
| |- language: fr
|-[subtitle stream 1]
| |- language: de
|-[subtitle stream 2]
|- language: fr
**Patch 306712**, "tools: gst-play: print audio/video/subtitle tracks details":
[0001-tools-gst-play-print-audio-video-subtitle-tracks-det.patch](/uploads/c3257ac336d9d9c196f22d516183b593/0001-tools-gst-play-print-audio-video-subtitle-tracks-det.patch)## Submitted by Hugues Fruchet
**[Link to original bug (#751903)](https://bugzilla.gnome.org/show_bug.cgi?id=751903)**
## Description
Created attachment 306712
tools: gst-play: print audio/video/subtitle tracks details
Allows to print tracks details when playbin reach playing state:
* audio
$> gst-play-1.0 /gorillaz.wav
0 video stream(s), 1 audio stream(s), 0 text stream(s)
|
|-[audio]
|-[audio stream 0]
|- codec: Uncompressed 16-bit PCM audio
* video
$> gst-play-1.0 /foreman.3gp
1 video stream(s), 0 audio stream(s), 0 text stream(s)
|-[video]
|-[video stream 0]
|- codec: H.264
* audio/video
$> gst-play-1.0 /big_buck_bunny_1080p_h264.mov
1 video stream(s), 1 audio stream(s), 0 text stream(s)
|-[video]
| |-[video stream 0]
| |- codec: H.264
|
|-[audio]
|-[audio stream 0]
|- codec: MPEG-4 AAC
|- bitrate: 359245
* audio/video/subtitles, multiple tracks
$> gst-play-1.0 "dvb://ARTE HD"
1 video stream(s), 4 audio stream(s), 3 text stream(s)
|-[video]
| |-[video stream 0]
| |- codec: H.264
|
|-[audio]
| |-[audio stream 0]
| | |- codec: MPEG-1 Layer 2 (MP2)
| | |- language: fr
| | |- bitrate: 256000
| |-[audio stream 1]
| | |- codec: MPEG-1 Layer 2 (MP2)
| | |- language: qaa
| | |- bitrate: 256000
| |-[audio stream 2]
| | |- codec: MPEG-1 Layer 2 (MP2)
| | |- language: de
| | |- bitrate: 128000
| |-[audio stream 3]
| |- codec: MPEG-1 Layer 2 (MP2)
| |- language: qad
| |- bitrate: 128000
|
|-[subtitle]
|-[subtitle stream 0]
| |- language: fr
|-[subtitle stream 1]
| |- language: de
|-[subtitle stream 2]
|- language: fr
**Patch 306712**, "tools: gst-play: print audio/video/subtitle tracks details":
[0001-tools-gst-play-print-audio-video-subtitle-tracks-det.patch](/uploads/c3257ac336d9d9c196f22d516183b593/0001-tools-gst-play-print-audio-video-subtitle-tracks-det.patch)EnhancementBugzillahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/204audio/video: Copy over more metas by default2019-03-15T21:27:39ZBugzilla Migration Useraudio/video: Copy over more metas by default## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#751647)](https://bugzilla.gnome.org/show_bug.cgi?id=751647)**
## Description
For audio/video decoder/encoder/filter/etc we're currently copying all metas without tags and with audio/video tags only.
We could also copy over things with e.g. the video-dimensions tag if the input and output caps are the same, or even in other cases by calling the meta's transform function.
### Depends on
* [Bug 742385](https://bugzilla.gnome.org/show_bug.cgi?id=742385)## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#751647)](https://bugzilla.gnome.org/show_bug.cgi?id=751647)**
## Description
For audio/video decoder/encoder/filter/etc we're currently copying all metas without tags and with audio/video tags only.
We could also copy over things with e.g. the video-dimensions tag if the input and output caps are the same, or even in other cases by calling the meta's transform function.
### Depends on
* [Bug 742385](https://bugzilla.gnome.org/show_bug.cgi?id=742385)Bugzillahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/203video: Add a &quot;crop&quot; GstMeta transform type2019-03-15T21:27:39ZBugzilla Migration Uservideo: Add a "crop" GstMeta transform type## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#751639)](https://bugzilla.gnome.org/show_bug.cgi?id=751639)**
## Description
See summary, could be useful to have for things like ROI meta.## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#751639)](https://bugzilla.gnome.org/show_bug.cgi?id=751639)**
## Description
See summary, could be useful to have for things like ROI meta.EnhancementBugzillahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/202audiobasesrc, audiobasesink: incorrect ringbuffer refcount when create_ringbu...2019-03-15T21:27:39ZBugzilla Migration Useraudiobasesrc, audiobasesink: incorrect ringbuffer refcount when create_ringbuffer returns a non-floating ref## Submitted by Michał Wróbel
**[Link to original bug (#751606)](https://bugzilla.gnome.org/show_bug.cgi?id=751606)**
## Description
gst_audio_base_{src,sink}_create_ringbuffer() calls the virtual function create_ringbuffer() to get a GstAudioRingBuffer, sets its parent to the GstAudioBase{Src,Sink} and returns a pointer to the ringbuffer without passing the reference (transfer none).
When create_ringbuffer() virtual function returns a floating ref (which is done by the default implementation in GstAudio{Src,Sink}), everything is fine, as the floating ref is consumed by gst_object_ref_sink() in gst_object_set_parent() and the "unfloated" ref is stored in the Src/Sink object.
However, when create_ringbuffer() virtual function returns a non-floating ref, the gst_object_ref_sink() inside gst_object_set_parent() increments the refcount which is wrong. For example, if the create_ringbuffer() vfunc returned object with refcount = 1, the gst_audio_base_{src,sink}_create_ringbuffer() returns the object with refcount = 2, while there is in fact only one ref held by the src/sink which is ringbuffer's parent.
### Blocking
* [Bug 751601](https://bugzilla.gnome.org/show_bug.cgi?id=751601)## Submitted by Michał Wróbel
**[Link to original bug (#751606)](https://bugzilla.gnome.org/show_bug.cgi?id=751606)**
## Description
gst_audio_base_{src,sink}_create_ringbuffer() calls the virtual function create_ringbuffer() to get a GstAudioRingBuffer, sets its parent to the GstAudioBase{Src,Sink} and returns a pointer to the ringbuffer without passing the reference (transfer none).
When create_ringbuffer() virtual function returns a floating ref (which is done by the default implementation in GstAudio{Src,Sink}), everything is fine, as the floating ref is consumed by gst_object_ref_sink() in gst_object_set_parent() and the "unfloated" ref is stored in the Src/Sink object.
However, when create_ringbuffer() virtual function returns a non-floating ref, the gst_object_ref_sink() inside gst_object_set_parent() increments the refcount which is wrong. For example, if the create_ringbuffer() vfunc returned object with refcount = 1, the gst_audio_base_{src,sink}_create_ringbuffer() returns the object with refcount = 2, while there is in fact only one ref held by the src/sink which is ringbuffer's parent.
### Blocking
* [Bug 751601](https://bugzilla.gnome.org/show_bug.cgi?id=751601)Bugzillahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/201GstVideoEncoder could expose a &quot;max-keyframe-distance&quot; property2019-03-15T21:27:39ZBugzilla Migration UserGstVideoEncoder could expose a "max-keyframe-distance" property## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#751554)](https://bugzilla.gnome.org/show_bug.cgi?id=751554)**
## Description
From IRC:
`<Mathieu_Du>` Hm I've got an interesting issue here, so youtube says "key-int-max" should be half the framerate, I'd like to have that in the preset, seems a bit involved tho
`<__tim>` you can't really specify that currently
`<Mathieu_Du>` Yep that's understandable
`<Mathieu_Du>` Alternate solution would be to have a key-int-max / framerate ratio in x264enc, but that might be a little too specific ?
`<Mathieu_Du>` (as a new prop)
`<__tim>` max-keyframe-distance in nanosecs perhaps
[snip]
__tim> the encoder base class can probably "enforce" that even if the encoder supports forcing keyframes
[snip]
`<__tim>` the encoder can still set key-int-max based on that property
`<__tim>` the base class handling is just a fallback really
So yep, being able to specify a maximum keyframe distance in nanoseconds would be a valuable addition, and putting that in the baseclass would indeed allow enforcability, what do you folks think ?## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#751554)](https://bugzilla.gnome.org/show_bug.cgi?id=751554)**
## Description
From IRC:
`<Mathieu_Du>` Hm I've got an interesting issue here, so youtube says "key-int-max" should be half the framerate, I'd like to have that in the preset, seems a bit involved tho
`<__tim>` you can't really specify that currently
`<Mathieu_Du>` Yep that's understandable
`<Mathieu_Du>` Alternate solution would be to have a key-int-max / framerate ratio in x264enc, but that might be a little too specific ?
`<Mathieu_Du>` (as a new prop)
`<__tim>` max-keyframe-distance in nanosecs perhaps
[snip]
__tim> the encoder base class can probably "enforce" that even if the encoder supports forcing keyframes
[snip]
`<__tim>` the encoder can still set key-int-max based on that property
`<__tim>` the base class handling is just a fallback really
So yep, being able to specify a maximum keyframe distance in nanoseconds would be a valuable addition, and putting that in the baseclass would indeed allow enforcability, what do you folks think ?EnhancementBugzillahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/200encodebin: Expose more specific sink template caps.2019-03-15T21:27:39ZBugzilla Migration Userencodebin: Expose more specific sink template caps.## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#751475)](https://bugzilla.gnome.org/show_bug.cgi?id=751475)**
## Description
Having STATIC_CAPS_ANY on both templates led to issues
in gst-launch with such a profile:
application/ogg:video/x-theora:audio/x-vorbis
ie one audio and one video encoding profile, both with no
presence.
This led gst_element_request_compatible_pad (gst-utils.c)
to return either template, which was not necessarily compatible.
The reason for having STATIC_CAPS_ANY was to allow for
"avoid-reencoding", however there only is a small set of formats
that can be directly remuxed, we thus specify them all
in the video template caps.## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#751475)](https://bugzilla.gnome.org/show_bug.cgi?id=751475)**
## Description
Having STATIC_CAPS_ANY on both templates led to issues
in gst-launch with such a profile:
application/ogg:video/x-theora:audio/x-vorbis
ie one audio and one video encoding profile, both with no
presence.
This led gst_element_request_compatible_pad (gst-utils.c)
to return either template, which was not necessarily compatible.
The reason for having STATIC_CAPS_ANY was to allow for
"avoid-reencoding", however there only is a small set of formats
that can be directly remuxed, we thus specify them all
in the video template caps.Bugzilla