GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T13:31:09Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/189vp9enc: remove token partitions property and support tile and row columns2021-09-24T13:31:09ZBugzilla Migration Uservp9enc: remove token partitions property and support tile and row columns## Submitted by Vittorio Palmisano
**[Link to original bug (#750219)](https://bugzilla.gnome.org/show_bug.cgi?id=750219)**
## Description
Created attachment 304355
Patch adding tile and row columns properties
From [1][2], vp9...## Submitted by Vittorio Palmisano
**[Link to original bug (#750219)](https://bugzilla.gnome.org/show_bug.cgi?id=750219)**
## Description
Created attachment 304355
Patch adding tile and row columns properties
From [1][2], vp9 encoder doesn't support the token partition property. Instead, tile and row columns properties should be used in order to allow multi-threading encoding [3].
Ref:
[1] http://www.webmproject.org/docs/encoder-parameters/#vp9-specific-options
[2] http://www.webmproject.org/docs/webm-sdk/group__vp8__encoder.html
[3] http://comments.gmane.org/gmane.comp.multimedia.webm.devel/2357
**Patch 304355**, "Patch adding tile and row columns properties":
[gst-plugins-good_vp9enc_tile-row-columns.patch](/uploads/fa554525115828a467a459f586bb92e2/gst-plugins-good_vp9enc_tile-row-columns.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/188rtpmp4gpay ! rtpmp4gdepay causes video artefacts2021-09-24T13:31:08ZBugzilla Migration Userrtpmp4gpay ! rtpmp4gdepay causes video artefacts## Submitted by Mingke Wang
**[Link to original bug (#750091)](https://bugzilla.gnome.org/show_bug.cgi?id=750091)**
## Description
using "test-uri" application in rtsp-server package to streaming some mp4 files.
(I'd like to uploa...## Submitted by Mingke Wang
**[Link to original bug (#750091)](https://bugzilla.gnome.org/show_bug.cgi?id=750091)**
## Description
using "test-uri" application in rtsp-server package to streaming some mp4 files.
(I'd like to upload a mp4 file, but the attachment was limited to 1600K. )
test-uri file://somefile.mp4
client:
gst-launch-1.0 playbin uri=rtsp://IP:8554/test
video playing is not smooth and got quite noticeable mosaic.
actually, the problem can be easily reproduced by local playback:
gst-launch-1.0 filesrc location=FILE ! video/quicktime ! demuxer ! rtpmp4gpay ! rtpmp4gdepay ! decoder ! videosink sync=true
seems some packets are lost in rtpmp4gpay or rtpmp4gdepay.
but if replace rtpmp4gpay/rtpmp4gdepay with rtpmp4vpay/rtpmp4vdepay. then no problem.
is it a bug of rtpmp4gpay or rtpmp4gdepay? or rtpmp4gpay or rtpmp4gdepay is not suitable for all mp4 files?
since we have a dedicate rtpmp4vpay/rtpmp4vdepay for mp4 video, I think the rank of rtpmp4vpay/rtpmp4vdepay should larger than rtpmp4gpay or rtpmp4gdepay, otherwise, application may chose to rtpmp4gpay or rtpmp4gdepay easily because they have same caps and same rank, and rtpmp4gpay or rtpmp4gdepay has priority in alphabet listing.
So I recommend decrease the rank of rtpmp4gpay or rtpmp4gdepay.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/184rtsp/rtp*: Streaming local TV hangs after less than 2 minutes2021-09-24T13:31:08ZBugzilla Migration Userrtsp/rtp*: Streaming local TV hangs after less than 2 minutes## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#748844)](https://bugzilla.gnome.org/show_bug.cgi?id=748844)**
## Description
My ISP provides (nearly) all the TV channels through local RTSP streams.
This is im...## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#748844)](https://bugzilla.gnome.org/show_bug.cgi?id=748844)**
## Description
My ISP provides (nearly) all the TV channels through local RTSP streams.
This is implemented in grilo in the freebox plugin:
https://git.gnome.org/browse/grilo-plugins/tree/src/freebox
gstreamer1-plugins-good-1.4.5-2.fc22.x86_64
gstreamer1-plugins-ugly-1.4.3-1.fc21.x86_64
gstreamer1-plugins-bad-free-1.4.5-2.fc22.x86_64
gstreamer1-plugins-base-1.4.5-2.fc22.x86_64
gstreamer1-libav-1.4.3-1.fc21.x86_64
gstreamer1-1.4.5-1.fc22.x86_64
Log coming.
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/183pulsesink: doesn't notify about volume changes in paused state or after conne...2021-09-24T13:31:07ZBugzilla Migration Userpulsesink: doesn't notify about volume changes in paused state or after connecting to pulseaudio## Submitted by Christoph Reiter (lazka)
**[Link to original bug (#748577)](https://bugzilla.gnome.org/show_bug.cgi?id=748577)**
## Description
Due to flat-volumes I'm exposing the pulsesink volume property in the UI now and noticed...## Submitted by Christoph Reiter (lazka)
**[Link to original bug (#748577)](https://bugzilla.gnome.org/show_bug.cgi?id=748577)**
## Description
Due to flat-volumes I'm exposing the pulsesink volume property in the UI now and noticed some problems:
1) When the pulsesink is created it returns 1.0 for volume and after going to paused it returns the actual volume assigned by PA. notify::volume never gets fired in between.
2) When in playing state, changing the volume in the gnome sound preferences or pavucontrol, pulsesink fires notify::volume. In the paused state it never fires notify::volume but the volume values changes.
I've currently worked this around my polling pulsesink in case of state change messages on the bus and when the user interacts with the volume widget. It would be nice if pulsesink would notify in all cases where volume potentially changes.
Version: 1.4.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/182ximagesrc: add uri handler interface2021-09-24T13:31:07ZBugzilla Migration Userximagesrc: add uri handler interface## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#748042)](https://bugzilla.gnome.org/show_bug.cgi?id=748042)**
## Description
Created attachment 301819
add xwin uri handler to ximagesrc
add a uri handler
...## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#748042)](https://bugzilla.gnome.org/show_bug.cgi?id=748042)**
## Description
Created attachment 301819
add xwin uri handler to ximagesrc
add a uri handler
xwin://.....
~~**Patch 301819**~~, "add xwin uri handler to ximagesrc":
[19_Add-x-uri-handler-to-ximagesrc.patch](/uploads/42209e80898bbdb01a58ef7e2c433615/19_Add-x-uri-handler-to-ximagesrc.patch)
Version: 1.10.4
### Depends on
* [Bug 779765](https://bugzilla.gnome.org/show_bug.cgi?id=779765)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/180rtpsession: Forward stream-start events to send_rtcp srcpad2021-09-24T13:31:06ZBugzilla Migration Userrtpsession: Forward stream-start events to send_rtcp srcpad## Submitted by Carlos Rafael Giani
**[Link to original bug (#747829)](https://bugzilla.gnome.org/show_bug.cgi?id=747829)**
## Description
Created attachment 301514
Patch to forward stream-start events to send_rtcp srcpad
Cur...## Submitted by Carlos Rafael Giani
**[Link to original bug (#747829)](https://bugzilla.gnome.org/show_bug.cgi?id=747829)**
## Description
Created attachment 301514
Patch to forward stream-start events to send_rtcp srcpad
Currently, if the send_rtp sinkpad receives a stream-start event, it is only forwarded to the send_rtp srcpad, not the send_rtcp one. Any sink linked to the send_rtcp srcpad will not ever receive stream-start events. But sinks need to receive these events so they can post stream-start messages, and in GStreamer, the pipeline will not dispatch stream-start messages until *all* sinks have posted this message. As a result, the application's bus watch / bus sync handler will never see stream-start events.
This patch corrects that by simply sending stream-start & caps & segment events to the send_rtcp srcpad when the stream-start event is received. With it, application bus watch/sync handler callbacks receive stream-start messages again.
I am not sure if this could be done in an easier way, probably by using sticky events. But the relevant events are sticky on the send_rtp sinkpad, not on the send_rtcp srcpad.
**Patch 301514**, "Patch to forward stream-start events to send_rtcp srcpad":
[0001-rtpsession-send-stream-start-caps-segment-events-to-.patch](/uploads/ca4a1b6b276b957c5ce7443f4805491c/0001-rtpsession-send-stream-start-caps-segment-events-to-.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/179v4l2: adding cropping and compose functionality2021-09-24T13:31:06ZBugzilla Migration Userv4l2: adding cropping and compose functionality## Submitted by Dimitrios Katsaros
**[Link to original bug (#747606)](https://bugzilla.gnome.org/show_bug.cgi?id=747606)**
## Description
This patch adds cropping and composition to the v4l2src. The reason for limiting the patch to ...## Submitted by Dimitrios Katsaros
**[Link to original bug (#747606)](https://bugzilla.gnome.org/show_bug.cgi?id=747606)**
## Description
This patch adds cropping and composition to the v4l2src. The reason for limiting the patch to the source is the lack of a v4l2 output device to test on. The device available also only supports cropping, so composition also requires additional testing
This patch has been developed with the current master branch, commit id: 8cfebfec8c6ca7a47dd064c8f5d3e587973f31a1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/178vp8dec: add deadline option2021-09-24T13:31:05ZBugzilla Migration Uservp8dec: add deadline option## Submitted by Cecill Etheredge (ijsf)
**[Link to original bug (#747534)](https://bugzilla.gnome.org/show_bug.cgi?id=747534)**
## Description
Created attachment 301163
Patch that adds deadline option to gstvp8dec
This patch ...## Submitted by Cecill Etheredge (ijsf)
**[Link to original bug (#747534)](https://bugzilla.gnome.org/show_bug.cgi?id=747534)**
## Description
Created attachment 301163
Patch that adds deadline option to gstvp8dec
This patch adds support for a "deadline" option in vp8dec, similar to that in gstvp8dec.
This option is required to force the deadline to real-time (VPX_DL_REALTIME) in applications where real-time video is essential, e.g. in OpenWebRTC.
I have tested and verified that the calculated deadline is actually 0 in the case of OpenWebRTC, and should be 1. By adding this option, the deadline can be overruled from the application end.
**Patch 301163**, "Patch that adds deadline option to gstvp8dec":
[ijsf_gstvp8dec_deadline.patch](/uploads/d432b57c21bbaee3573a6da9c4dec770/ijsf_gstvp8dec_deadline.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/177qtmux/mp4mux can't change size after first buffer.2021-09-24T13:31:05ZBugzilla Migration Userqtmux/mp4mux can't change size after first buffer.## Submitted by Marcin Kolny `@loganek`
**[Link to original bug (#747184)](https://bugzilla.gnome.org/show_bug.cgi?id=747184)**
## Description
Created attachment 300752
test application
Hi,
I've udp video stream, which can ...## Submitted by Marcin Kolny `@loganek`
**[Link to original bug (#747184)](https://bugzilla.gnome.org/show_bug.cgi?id=747184)**
## Description
Created attachment 300752
test application
Hi,
I've udp video stream, which can change its resolution. I've noted, that qtmux/mp4mux fails, when video size is changed. I did simple application, which triggers this bug (see attachment).
I digged a little, and noted, that the problem is in method gst_qt_mux_video_sink_set_caps. At the beginning, function checks, whether previous caps are subset of new caps (gst_qtmux_caps_is_subset_full). It obviously isn't true, because caps have other size. I saw comment above - Does it mean, that there is no possibility to renegotiate caps in mp4mux/qtmux?
IMO it's a bug in a plugin, but have no idea how to fix it in a proper way.
**Attachment 300752**, "test application":
[muxtest.c](/uploads/1fff4d4074eb510bd28c7cb61a2868dc/muxtest.c)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/175rtpsource: Stats contain useless SR fields for receiver sources2021-09-24T13:31:05ZBugzilla Migration Userrtpsource: Stats contain useless SR fields for receiver sources## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#746743)](https://bugzilla.gnome.org/show_bug.cgi?id=746743)**
## Description
On the sender side, we currently have one rtpsource for sending, and then the N rtpsourc...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#746743)](https://bugzilla.gnome.org/show_bug.cgi?id=746743)**
## Description
On the sender side, we currently have one rtpsource for sending, and then the N rtpsources for all the receivers.
The receiver rtpsource will then get the RRs at some point, and generate stats from it, which can be retrieved with the "stats" property. However these stats contain lots of fields that are always going to be 0: sr-*, packets/octets-received/sent, etc.
The sr-* fields look like they should contain the values from the last SR that was sent, but that one comes from a different rtpsource and the receiver rtpsource never sees that.
The packets/octets-received/sent fields would only contain a value if this was a source that sends data, or receives data. So never the receiver sources on the sender side.
Is this all intended as is? Should the SR at the sender side also go to all the receiver sources so that they can know the SR that resulted in the RRs that are received?https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/174videorate: Should transform the caps in allocation2021-09-24T13:31:04ZBugzilla Migration Uservideorate: Should transform the caps in allocation## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#746657)](https://bugzilla.gnome.org/show_bug.cgi?id=746657)**
## Description
Videorate passthrough allocation query, but it does not transform the framerate in ...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#746657)](https://bugzilla.gnome.org/show_bug.cgi?id=746657)**
## Description
Videorate passthrough allocation query, but it does not transform the framerate in the allocation query caps. If downstream element prepare a pool base on the caps it got in set_format(), the caps won't match and it may fail. Videorate should probably transform the caps in the allocation query.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/173rtpsession: Add property to set minimum time between regular RTCP and early RTCP2021-09-24T13:31:04ZBugzilla Migration Userrtpsession: Add property to set minimum time between regular RTCP and early RTCP## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#746542)](https://bugzilla.gnome.org/show_bug.cgi?id=746542)**
## Description
Currently we allow to send an early RTCP packet immediately after the previous regular R...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#746542)](https://bugzilla.gnome.org/show_bug.cgi?id=746542)**
## Description
Currently we allow to send an early RTCP packet immediately after the previous regular RTCP packet. This will be suboptimal if we have reasons to send another early RTCP packet soon afterwards... as that one would now have to wait until the next regular RTCP packet could be sent (and the next regular RTCP packet is now also delayed in the future because of the early one we just sent).
It would be better in some situations if we set some minimum delay from the previous regular RTCP packet. That way we would allow for other feedback to be accumulated into the same early feedback RTCP packet more likely.
The delay could either be specified in milliseconds, or as a relative value relative to the regular RTCP scheduling interval we currently decided to use. Not sure which one is better.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/172dvdemux: timecode displayed incorrectly2021-09-24T13:31:03ZBugzilla Migration Userdvdemux: timecode displayed incorrectly## Submitted by RaviKiran
**[Link to original bug (#746505)](https://bugzilla.gnome.org/show_bug.cgi?id=746505)**
## Description
gst_dvdemux_get_timecode() doesn't get the timecode correctly.
timecode information for seconds and m...## Submitted by RaviKiran
**[Link to original bug (#746505)](https://bugzilla.gnome.org/show_bug.cgi?id=746505)**
## Description
gst_dvdemux_get_timecode() doesn't get the timecode correctly.
timecode information for seconds and minutes are 0-6 bits, however
last bit is ignored.
This timecode is used for debug message only.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/171gstrtpmp4adepay cannot handle in band config2021-09-24T13:31:03ZBugzilla Migration Usergstrtpmp4adepay cannot handle in band config## Submitted by Nick Stoughton
**[Link to original bug (#746475)](https://bugzilla.gnome.org/show_bug.cgi?id=746475)**
## Description
The rtpmp4adepay module cannot handle payloads created by iOS which send the streamMuxConfig in-ba...## Submitted by Nick Stoughton
**[Link to original bug (#746475)](https://bugzilla.gnome.org/show_bug.cgi?id=746475)**
## Description
The rtpmp4adepay module cannot handle payloads created by iOS which send the streamMuxConfig in-band. The following extract is from the Apple "Bluetooth Accessory Design Guidelines for Apple Products":
> The AudioMuxElement is the same as the RTP payload in RFC 3016. It is defined in Section 1.7.3, Table
> 1.32 in ISO/IEC 13818-3:2005, subpart 1. The muxConfigPresent argument to the AudioMuxElement
> is set to 1 (in-band mode), as recommended in Section 4.1 of RFC 3016. As recommended in Section 4.3
> of RFC 3016, only one AudioMuxElement is put into each AVDTP packet
Further, Apple fail to implement RFC 3016 correct, in that they never set the Marker bit in the RTP header.
I don't have the bandwidth right now to come up with a patch, but will probably do so in the next few months unless someone else has something to offer!
Need a mechanism to say "assume every packet has the Marker set" (I might be able to do this in my source element), and to handle in-band config data.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/170souphttpsrc: Use proxy username/password from http_proxy2021-09-24T13:31:03ZBugzilla Migration Usersouphttpsrc: Use proxy username/password from http_proxy## Submitted by Rajat Verma
**[Link to original bug (#746382)](https://bugzilla.gnome.org/show_bug.cgi?id=746382)**
## Description
http_proxy variable may also contain proxy username & password in below format:
`<protocol>`://`...## Submitted by Rajat Verma
**[Link to original bug (#746382)](https://bugzilla.gnome.org/show_bug.cgi?id=746382)**
## Description
http_proxy variable may also contain proxy username & password in below format:
`<protocol>`://`<username>`:`<password>`@`<proxy ip>`:`<proxy port>`
souphttpsrc only sets proxy url (`<proxy ip>` & `<proxy port>`) is http_proxy variable is defined in environment but not proxy-id and proxy-pw.
Problem I am facing is "proxy authentication required 407" while testing MPEG-DASH, which plays a .mpd located outside my company network.
dashdemux, for fetching a segment, uses gst_element_make_from_uri(). Now I have no way to set proxy-id/proxy-pw on this particular souphttpsrc instance, due to which segment fetching fails.
If souphttpsrc may start parsing proxy-id/proxy-pw using below functions from soup library:
soup_uri_get_user()
soup_uri_get_password()
then my issue would be resolved.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/169qtdemux: Support for gapless playback for .m4a files2021-09-24T13:31:02ZBugzilla Migration Userqtdemux: Support for gapless playback for .m4a files## Submitted by Carlos Rafael Giani
**[Link to original bug (#746109)](https://bugzilla.gnome.org/show_bug.cgi?id=746109)**
## Description
Hello,
I am currently investigating how to enable gapless playback for .m4a files. From ...## Submitted by Carlos Rafael Giani
**[Link to original bug (#746109)](https://bugzilla.gnome.org/show_bug.cgi?id=746109)**
## Description
Hello,
I am currently investigating how to enable gapless playback for .m4a files. From what I gathered, the primary way is to read out the information from the iTunSMPB tag. If it is not present, the Nero method can be used/assumed as fallback (which is, drop the first frame, usually 1024 samples for AAC LC).
The former has been introduced by Apple for iTunes. The latter is commonly done by FAAC/FAAD and Nero AAC software.
Looking at the qtdemux code, one approach that seems promising is to modify the segment in gst_qtdemux_activate_segment() prior to sending the newsegment event. That is, the data in stream->segment would *not* be modified; instead, the segment structure would be copied, the copy modified, and passed over to gst_event_new_segment(). This way, downstream sees a segment with the base/start/stop/duration values adjusted to exclude the padding samples. (The reason why this is done in a local copy is to prevent early buffer clipping in qtdemux itself; clipping needs to be applied on the decoded samples).
I'll come up with a patch that implement it and post it here, but in the meantime, if somebody knows a good reason why it shouldn't be done like that, it would be great to hear about it.
### Depends on
* [Bug 753631](https://bugzilla.gnome.org/show_bug.cgi?id=753631)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/168v4l2: enumerate output ports and add a property to select input/output2021-09-24T13:31:02ZBugzilla Migration Userv4l2: enumerate output ports and add a property to select input/output## Submitted by Aurélien Zanelli
**[Link to original bug (#746080)](https://bugzilla.gnome.org/show_bug.cgi?id=746080)**
## Description
V4L2 device can have multiple input/output port and they expose them through ENUMINPUT/ENUMOUTPU...## Submitted by Aurélien Zanelli
**[Link to original bug (#746080)](https://bugzilla.gnome.org/show_bug.cgi?id=746080)**
## Description
V4L2 device can have multiple input/output port and they expose them through ENUMINPUT/ENUMOUTPUT ioctls. But currently we only enumerate input whatever device is a capture one or an output one. I think, we should enumerate according to the device type.
Also I think it can be useful to enable user to select which input/output they want to use. To solve this I propose to add a property to v4l2object to let user select input/output.
I found this while playing with Vivid which have multiple input/output port.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/167rtpjitterbuffer: Does not handle bursts properly2021-09-24T13:31:01ZBugzilla Migration Userrtpjitterbuffer: Does not handle bursts properly## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#746035)](https://bugzilla.gnome.org/show_bug.cgi?id=746035)**
## Description
Created attachment 299099
Sample rtsp audio stream which yields duplicate timestam...## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#746035)](https://bugzilla.gnome.org/show_bug.cgi?id=746035)**
## Description
Created attachment 299099
Sample rtsp audio stream which yields duplicate timestamps with rtpjitterbuffer
When the attached gdp-payloaded file is run through rtpjitterbuffer, with mode=slave (the default), the output audio has buffers with duplicate pts, but not with mode=buffer/synced/none. Those buffers all seem to contain silence (see [bug 746032](https://bugzilla.gnome.org/show_bug.cgi?id=746032)).
Bad:
gst-launch-1.0 filesrc location=output-gdp-audio.bin ! gdpdepay ! rtpjitterbuffer ! rtpmp4adepay ! decodebin ! ...
Good:
gst-launch-1.0 filesrc location=output-gdp-audio.bin ! gdpdepay ! rtpjitterbuffer mode=buffer ! rtpmp4adepay ! decodebin ! ...
gst-launch-1.0 filesrc location=output-gdp-audio.bin ! gdpdepay ! rtpjitterbuffer mode=synced ! rtpmp4adepay ! decodebin ! ...
gst-launch-1.0 filesrc location=output-gdp-audio.bin ! gdpdepay ! rtpjitterbuffer mode=none ! rtpmp4adepay ! decodebin ! ...
All the incoming packets are sequential and evenly-spaced (captured from gst-rtsp-server over a link-local network), so in theory there shouldn't be a "discontinuity" like that.
~~**Attachment 299099**~~, "Sample rtsp audio stream which yields duplicate timestamps with rtpjitterbuffer":
[output-gdp-video.bin](/uploads/11eacf4143df56e805eb5563536fb67f/output-gdp-video.bin)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/166wavparse: support for partially unpositioned channels2021-09-24T13:31:01ZBugzilla Migration Userwavparse: support for partially unpositioned channels## Submitted by Ilya Konstantinov
**[Link to original bug (#745871)](https://bugzilla.gnome.org/show_bug.cgi?id=745871)**
## Description
Here's a sample:
http://www-mmsp.ece.mcgill.ca/documents/AudioFormats/WAVE/Samples/Microso...## Submitted by Ilya Konstantinov
**[Link to original bug (#745871)](https://bugzilla.gnome.org/show_bug.cgi?id=745871)**
## Description
Here's a sample:
http://www-mmsp.ece.mcgill.ca/documents/AudioFormats/WAVE/Samples/Microsoft/8_Channel_ID.wav
This is a file with 8 channels and the following speaker locations:
FL FR FC LF BL BR - -
(Only 6 allocated, the mask is 0x3f.)
As per spec:
"Should nChannels exceed the number of bits set in dwChannelMask, then the remaining channels are not assigned to any particular speaker location. An audio device would render the remaining channel data to output ports not in use." [1]
Since GstAudioChannelPositions requires channels to be either all positioned or all unpositioned, I think we should opt to offer caps of: channels:6, channel-mask:0x3f. (The remaining 2 channels can be only thrown away.)
Current GStreamer this warning out a few times, since wavparse produces 'channels:8, channel-mask:0x3f':
** (gst-launch-1.0:14286): WARNING **: Invalid channel positions
[1] https://msdn.microsoft.com/en-us/library/windows/hardware/dn653308(v=vs.85).aspxhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/164rtpsession: Implement RFC 27622021-09-24T13:31:00ZBugzilla Migration Userrtpsession: Implement RFC 2762## Submitted by sancane
**[Link to original bug (#745586)](https://bugzilla.gnome.org/show_bug.cgi?id=745586)**
## Description
Created attachment 298511
patch generated using git format-patch
rtpsession declares an array of m...## Submitted by sancane
**[Link to original bug (#745586)](https://bugzilla.gnome.org/show_bug.cgi?id=745586)**
## Description
Created attachment 298511
patch generated using git format-patch
rtpsession declares an array of maps to store srrcs but only the
the key 0 is being used. This patch replaces the array of maps
for just one map and remove useless parameters in rtpsession
**Patch 298511**, "patch generated using git format-patch":
[0001-rtpsession-Do-not-use-an-array-of-maps-if-they-are-n.patch](/uploads/d67acf1b4732cc695d88adcfec21430d/0001-rtpsession-Do-not-use-an-array-of-maps-if-they-are-n.patch)