gst-plugins-bad issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues2021-09-24T14:36:07Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/661srtpenc/srtpdec force application/x-srtp even when encryption disabled2021-09-24T14:36:07ZBugzilla Migration Usersrtpenc/srtpdec force application/x-srtp even when encryption disabled## Submitted by David Woodhouse
**[Link to original bug (#793704)](https://bugzilla.gnome.org/show_bug.cgi?id=793704)**
## Description
Created attachment 368731
Use application/x-rtp caps when decryption is disabled
See https...## Submitted by David Woodhouse
**[Link to original bug (#793704)](https://bugzilla.gnome.org/show_bug.cgi?id=793704)**
## Description
Created attachment 368731
Use application/x-rtp caps when decryption is disabled
See https://bugs.freedesktop.org/show_bug.cgi?id=105193
The FarStream fsrtpconference creates srtpenc/srtpdec elements unconditionally. If no encryption is negotiated, they pass RTP packets through with no effect. But the negotiated caps are still application/x-srtp, not application/x-rtp which is what's actually being sent.
This works OK when the transmitter is some UDP network thing which accepts anything and doesn't care.
However, in my case I do care, because I'm connecting fsrtpconference up to my own RTP depayload which really does need it to be correctly labelled as application/x-rtp.
Here's a half-baked attempt at making it work, which might work for srtpenc but has certainly broken srtpdec.
**Patch 368731**, "Use application/x-rtp caps when decryption is disabled":
[srtp-allow-rtp.patch](/uploads/3f0d7f96cc776fac0ed47fcc3791469e/srtp-allow-rtp.patch)
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/659msdk (vaapi/x264/etc): encode: renaming the target-usage to speed-preset2021-09-24T14:36:07ZBugzilla Migration Usermsdk (vaapi/x264/etc): encode: renaming the target-usage to speed-preset## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#793495)](https://bugzilla.gnome.org/show_bug.cgi?id=793495)**
## Description
This is for discussing the unification of speed-quality-tradeoff property in differ...## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#793495)](https://bugzilla.gnome.org/show_bug.cgi?id=793495)**
## Description
This is for discussing the unification of speed-quality-tradeoff property in different encoders which could be most commonly used tuning option for general users.
The current msdk encoders have a property "target-usage":
target-usage : 1: Best quality, 4: Balanced, 7: Best speed
flags: readable, writable
Unsigned Integer. Range: 1 - 7 Default: 4
The same thing in gstreamer-vaapi is:
quality-level : Encoding Quality Level (lower value means higher-quality/slow-encode, higher value means lower-quality/fast-encode)
flags: readable, writable
Unsigned Integer. Range: 1 - 7 Default: 4
x264enc has this:
speed-preset : Preset name for speed/quality tradeoff options (can affect decode compatibility - impose restrictions separately for your target decoder)
flags: readable, writable
Enum "GstX264EncPreset" Default: 6, "medium"
(0): None - No preset
(1): ultrafast - ultrafast
(2): superfast - superfast
(3): veryfast - veryfast
(4): faster - faster
(5): fast - fast
(6): medium - medium
(7): slow - slow
(8): slower - slower
(9): veryslow - veryslow
(10): placebo - placebo
Does it make sense to use the same property for all?
It could break the backward compatibility for gstreamr-vaapi and x264.
But for msdk, this seems to be the right time for a change like this.
I would like to get some general opinion on this.
Version: 1.13.1
### Blocking
* [Bug 789886](https://bugzilla.gnome.org/show_bug.cgi?id=789886)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/658msdk: refactor removing duplicated code in encoder and decoder.2021-09-24T14:36:07ZBugzilla Migration Usermsdk: refactor removing duplicated code in encoder and decoder.## Submitted by Hyunjun Ko `@zzoon`
**[Link to original bug (#793414)](https://bugzilla.gnome.org/show_bug.cgi?id=793414)**
## Description
There are some duplicate code and can be placed in one place, so called, gstmsdkutil.c.
...## Submitted by Hyunjun Ko `@zzoon`
**[Link to original bug (#793414)](https://bugzilla.gnome.org/show_bug.cgi?id=793414)**
## Description
There are some duplicate code and can be placed in one place, so called, gstmsdkutil.c.
Let's refactor and clean it up.
### Blocking
* [Bug 789886](https://bugzilla.gnome.org/show_bug.cgi?id=789886)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/657msdk: avoid explicit sync2021-09-24T14:36:06ZBugzilla Migration Usermsdk: avoid explicit sync## Submitted by Hyunjun Ko `@zzoon`
**[Link to original bug (#793411)](https://bugzilla.gnome.org/show_bug.cgi?id=793411)**
## Description
Avoiding Explicit Sync if there are back to back msdk plugins in a pipeline might improve per...## Submitted by Hyunjun Ko `@zzoon`
**[Link to original bug (#793411)](https://bugzilla.gnome.org/show_bug.cgi?id=793411)**
## Description
Avoiding Explicit Sync if there are back to back msdk plugins in a pipeline might improve performonce of the pipeline.
We can think about this way and do benchmarking at least.
### Blocking
* [Bug 789886](https://bugzilla.gnome.org/show_bug.cgi?id=789886)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/656lv2: Parameter metadata is not supported2021-09-24T14:36:06ZBugzilla Migration Userlv2: Parameter metadata is not supported## Submitted by Wellington Wallace
**[Link to original bug (#793384)](https://bugzilla.gnome.org/show_bug.cgi?id=793384)**
## Description
Hi GStreamer developers! I would like to use the convolver from Linux Studio Plugins http://ls...## Submitted by Wellington Wallace
**[Link to original bug (#793384)](https://bugzilla.gnome.org/show_bug.cgi?id=793384)**
## Description
Hi GStreamer developers! I would like to use the convolver from Linux Studio Plugins http://lsp-plug.in/?page=manuals§ion=impulse_responses_stereo in my application https://github.com/wwmm/pulseeffects. But although the plugin is successfully loaded by GStreamer there are two parameters that are not show in the output of gst-inspect-1.0. The ones used to load the impulse response file for each channel. In the plugin ttl file they are defined as:
lsp_p:ifn0
a lv2:Parameter ;
rdfs:label "Impulse file 1" ;
rdfs:range atom:Path
.
lsp_p:ifn1
a lv2:Parameter ;
rdfs:label "Impulse file 2" ;
rdfs:range atom:Path
I took a look at the lv2 plugin sources and it seems that there is no support for lv2:Parameter. So this may be the reason why they are not shown in the output of gst-inspect-1.0.
Although I would like to help I just don't have the knowledge to do that yet. I have never worked at GStreamer lower levels and I know nothing about the LV2 api.
I am open to alternative solutions in case this is a feature we can't have any time soon.
Best regards,
Wellington
Version: 1.12.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/655Crashing on iOS: [ALAssetRepresentation release]: message sent to deallocated...2021-09-24T14:36:05ZBugzilla Migration UserCrashing on iOS: [ALAssetRepresentation release]: message sent to deallocated instance, [GstAssetsLibrary .cxx_destruct] XCode 9.2, iOS 11.2 (15C107)## Submitted by Louis Le
**[Link to original bug (#793383)](https://bugzilla.gnome.org/show_bug.cgi?id=793383)**
## Description
I'm stuck on crashing issue: message sent to deallocated instance zombie object with GStreamer tutorial ...## Submitted by Louis Le
**[Link to original bug (#793383)](https://bugzilla.gnome.org/show_bug.cgi?id=793383)**
## Description
I'm stuck on crashing issue: message sent to deallocated instance zombie object with GStreamer tutorial project for iOS with this version of XCode, the app crashes when trying to unref the player or pipeline after playing a AVI file saved in Camera Roll using ALAsset with prefix:
assets-library://asset/asset.AVI?id=ID_OF_AVI_FILE&ext=AVI.
Crash point: typefind:sink -> [GstAssetsLibrary .cxx_destruct]
Crash callStackSymbols
`<_NSCallStackArray 0x604000452180>`(
```
0 ??? 0x00000001226dbf1c 0x0 + 4872584988,
1 Tutorial 5 0x0000000103211300 main + 0,
2 libobjc.A.dylib 0x000000010bbb6912 _ZL27object_cxxDestructFromClassP11objc_objectP10objc_class + 127,
3 libobjc.A.dylib 0x000000010bbc21a4 objc_destructInstance + 124,
4 libobjc.A.dylib 0x000000010bbc21db object_dispose + 22,
5 AssetsLibrary 0x00000001088a6acd -[ALAssetsLibrary dealloc] + 98,
6 libobjc.A.dylib 0x000000010bbcca2e _ZN11objc_object17sidetable_releaseEb + 202,
7 libobjc.A.dylib 0x000000010bbcd178 _ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 860,
8 libobjc.A.dylib 0x000000010bbce31b _ZN12_GLOBAL__N_119AutoreleasePoolPage11tls_deallocEPv + 127,
9 libsystem_pthread.dylib 0x000000010ca0f27e _pthread_tsd_cleanup + 534,
10 libsystem_pthread.dylib 0x000000010ca0efbd _pthread_exit + 79,
11 libsystem_pthread.dylib 0x000000010ca0d6cc pthread_sigmask + 0,
12 libsystem_pthread.dylib 0x000000010ca0d56d _pthread_body + 0,
13 libsystem_pthread.dylib 0x000000010ca0cc5d thread_start + 13
)
```
>https://github.com/sdroege/gst-player
>https://github.com/GStreamer/gst-docs/tree/master/examples/tutorials/xcode%20iOS
Version: 1.12.3https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/654kmssink: Renders at half my display refresh rate2021-09-24T14:36:05ZBugzilla Migration Userkmssink: Renders at half my display refresh rate## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#793339)](https://bugzilla.gnome.org/show_bug.cgi?id=793339)**
## Description
While doing some latency test, I notice that kmssink renders at half the speed of m...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#793339)](https://bugzilla.gnome.org/show_bug.cgi?id=793339)**
## Description
While doing some latency test, I notice that kmssink renders at half the speed of my display. My test pipeline was:
gst-launch-1.0 -v videotestsrc ! video/x-raw,framerate=60/1 ! fpsdisplaysink text-overlay=0 video-sink=kmssink
Commenting out the code that (according to comment) tries to wait for previous frame to finish fixes it.
https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/sys/kms/gstkmssink.c#n1499
My impression is that we endup waiting for an extra vblank all the time as the previous blank is behind.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/653iOS 11.2 vtdec ! glimagesink decoding broken on iphone 62021-09-24T14:36:05ZBugzilla Migration UseriOS 11.2 vtdec ! glimagesink decoding broken on iphone 6## Submitted by Jan Schmidt `@thaytan`
**[Link to original bug (#793323)](https://bugzilla.gnome.org/show_bug.cgi?id=793323)**
## Description
In iOS 11.2.5 testing with GStreamer 1.12.4 on an iPhone 6, I'm currently seeing that vtde...## Submitted by Jan Schmidt `@thaytan`
**[Link to original bug (#793323)](https://bugzilla.gnome.org/show_bug.cgi?id=793323)**
## Description
In iOS 11.2.5 testing with GStreamer 1.12.4 on an iPhone 6, I'm currently seeing that vtdec ! glimagesink output plays incorrectly, with frames showing out of order.
It only happens with GL output from vtdec, and I suspect is related to the GL textures being invalidated too early, or otherwise not having the content we think they do.
The same build works fine on an older ipad3 with iOS 9.2, and since the latest work on vtdec references iOS 11.1, I suspect it worked there and is therefore possibly an iOS change we need to find a solution for.
Has anyone else been testing on iOS 11.2 recently?
Version: 1.12.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/652frames are pixelated/blurred on ios2021-09-24T14:36:04ZBugzilla Migration Userframes are pixelated/blurred on ios## Submitted by Muhammet Ilendemli
**[Link to original bug (#793118)](https://bugzilla.gnome.org/show_bug.cgi?id=793118)**
## Description
I am working on an iOS app, my coworker is working on an Android app
We almost have the s...## Submitted by Muhammet Ilendemli
**[Link to original bug (#793118)](https://bugzilla.gnome.org/show_bug.cgi?id=793118)**
## Description
I am working on an iOS app, my coworker is working on an Android app
We almost have the same pipeline:
rtspsrc location=%@ latency=50 !
rtpjitterbuffer !
rtph264depay !
avdec_h264 !
videoconvert !
glimagesink
I also have used this pipeline:
videotestsrc !
video/x-raw,width=1920,height=1080 !
glimagesink
Basically any drawn frame is blurred (you can see white fading to blue) when using videotestsrc and/or pixelated when using an rtspsrc for example any earthcam stream on my devices. It looks fine on android.
Recordings were done using this pipeline and they look absolutely fine:
rtspsrc location=%@ latency=0 connection-speed=30000 !
rtpjitterbuffer !
rtph264depay !
h264parse !
queue !
mp4mux !
filesink location=%@
Here is a gallery with some screenshots: https://imgur.com/a/QkSoV
Either I am missing something or I don't know why some streams are pixelated.
Version: 1.12.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/650waylandsink: gst-launch-1.0 windows does not mimic application well2021-09-24T14:36:04ZBugzilla Migration Userwaylandsink: gst-launch-1.0 windows does not mimic application well## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#792874)](https://bugzilla.gnome.org/show_bug.cgi?id=792874)**
## Description
Title is a little vagues, but how waylandsink works is that the application passes ...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#792874)](https://bugzilla.gnome.org/show_bug.cgi?id=792874)**
## Description
Title is a little vagues, but how waylandsink works is that the application passes a Surface, and waylandsink attach two subsurfaces to it (back plane for the black borders, and the video layer).
Though, when testing with gst-launch-1.0, the created "window" do have a surface, but that surface does not have a buffer attached to it. That makes gnome-shell think the "window" has a size of 0x0, while weston will assume the size of the sub-surfaces.
This is more visible if you set a render rectangle on that created windows, since this endup having absolutely no effect. I "think" that to better mimic applications we should attach a background buffer to this window, at the size we want this window to be. And update that surface when the window is being resized. We could make this background blue or something, that will ease testing the VideoOverlay render rectangle implementation, which seems to have some problems atm.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/649License incompatibility2021-09-24T14:36:03ZBugzilla Migration UserLicense incompatibility## Submitted by pau..@..oo.com
**[Link to original bug (#792577)](https://bugzilla.gnome.org/show_bug.cgi?id=792577)**
## Description
Hello,
I found some files in gst-plugins-bad - 1.6.1 which are incompatible with LGPL-2.0, LG...## Submitted by pau..@..oo.com
**[Link to original bug (#792577)](https://bugzilla.gnome.org/show_bug.cgi?id=792577)**
## Description
Hello,
I found some files in gst-plugins-bad - 1.6.1 which are incompatible with LGPL-2.0, LGPL-2.1 and GPL-2.0.
The ones listed below are under MPL-1.1:
https://github.com/GStreamer/gst-plugins-bad/blob/1.6.1/ext/resindvd/gstmpegdefs.h
https://github.com/GStreamer/gst-plugins-bad/blob/1.6.1/ext/resindvd/gstmpegdemux.c
https://github.com/GStreamer/gst-plugins-bad/blob/1.6.1/ext/resindvd/gstmpegdesc.c
https://github.com/GStreamer/gst-plugins-bad/blob/1.6.1/ext/resindvd/gstmpegdesc.h
and this one is under Apache-2.0:
https://github.com/GStreamer/gst-plugins-bad/blob/1.6.1/sys/androidmedia/gstjniutils.c
Can you please provide me with some additional information regarding these situations?
Version: 1.6.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/643new element: gpsdsrc2021-09-24T14:36:02ZBugzilla Migration Usernew element: gpsdsrc## Submitted by Martin Kelly
**[Link to original bug (#791601)](https://bugzilla.gnome.org/show_bug.cgi?id=791601)**
## Description
Created attachment 365510
0001-new-element-gpsdsrc.patch
new element: gpsdsrc
This el...## Submitted by Martin Kelly
**[Link to original bug (#791601)](https://bugzilla.gnome.org/show_bug.cgi?id=791601)**
## Description
Created attachment 365510
0001-new-element-gpsdsrc.patch
new element: gpsdsrc
This element reads data from gpsd (http://www.catb.org/gpsd/). Right now
the GPS data type is not used in other plugins, but eventually it could
be used to multiplex and integrate with other A/V data types.
~~**Patch 365510**~~, "0001-new-element-gpsdsrc.patch":
[0001-new-element-gpsdsrc.patch](/uploads/5bb2f44c83ad7bd1ce4717bc48ccba40/0001-new-element-gpsdsrc.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/641h265parse: Messes up timestamps for byte-stream2021-09-24T14:36:01ZBugzilla Migration Userh265parse: Messes up timestamps for byte-stream## Submitted by Matej `@Knopp`
**[Link to original bug (#791495)](https://bugzilla.gnome.org/show_bug.cgi?id=791495)**
## Description
It happens when previous frame has trailing zero. Parser split frame too early, leaving trailing z...## Submitted by Matej `@Knopp`
**[Link to original bug (#791495)](https://bugzilla.gnome.org/show_bug.cgi?id=791495)**
## Description
It happens when previous frame has trailing zero. Parser split frame too early, leaving trailing zeros as prefix for new frame, which results in messed up timestamps.
Caused by following code in gst_h265_parser_identify_nalu
/* Mini performance improvement:
* We could have a way to store how many 0s were skipped to avoid
* parsing them again on the next NAL */
while (off2 > 0 && data[nalu->offset + off2 - 1] == 00)
off2--;
Annex B does says that there should be zero byte before AU startcode, however it also says that during parsing the zero byte should be discarded. So maybe determining the timestamp from zero byte is not a very good idea.
The stream already parsed by FFMPEG HEVC parser, which seems to leave zero byte trailing, but that doesn't mean such files can't be encountered in the wild.
Btw. Why's there loop? Why skipping more than 1 zero byte? Doesn't that just increases chance of messed up timestamps?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/640kmssink: Crop Meta support only works if the proposed pool has been used2021-09-24T14:36:01ZBugzilla Migration Userkmssink: Crop Meta support only works if the proposed pool has been used## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#791450)](https://bugzilla.gnome.org/show_bug.cgi?id=791450)**
## Description
++ This is the same as https://bugzilla.gnome.org/show_bug.cgi?id=791449
Whene...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#791450)](https://bugzilla.gnome.org/show_bug.cgi?id=791450)**
## Description
++ This is the same as https://bugzilla.gnome.org/show_bug.cgi?id=791449
Whenever the proposed pool is not used upstream, the element fails. The reason is that buffer containing crop meta are larger then caps width/height used to create the internal pool.
We need to delay the creation of the pool, and then alter the caps width/height with the width/height found in the incoming buffer video meta. As a side effect, we also need to validate this width/height every-time.
I'll post the videocrop patches needed to test this easily soon, meanwhile the test pipeline will be:
videotestsrc ! videocrop top=100 ! tee ! kmsimagesink
Tee does not drop the allocation query, but will not use downstream pools.
The result is a black or green image (depends on the color format) and:
CRITICAL **: gst_video_frame_copy: assertion 'dinfo->width == sinfo->width && dinfo->height == sinfo->height' failed
### Blocking
* [Bug 746087](https://bugzilla.gnome.org/show_bug.cgi?id=746087)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/639kmssink: fix kmssink fail to start when not connect display2021-09-24T14:36:00ZBugzilla Migration Userkmssink: fix kmssink fail to start when not connect display## Submitted by Haihua Hu `@JaredHu`
**[Link to original bug (#791374)](https://bugzilla.gnome.org/show_bug.cgi?id=791374)**
## Description
Currently kmssink will fail when not connect display to device. Get display connected status...## Submitted by Haihua Hu `@JaredHu`
**[Link to original bug (#791374)](https://bugzilla.gnome.org/show_bug.cgi?id=791374)**
## Description
Currently kmssink will fail when not connect display to device. Get display connected status from drm connector, drop all buffer when display not connected to make pipeline can run.
Version: 1.12.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/638interaudio: Add option to enable/disable gap flags in nullsample buffers2021-09-24T14:36:00ZBugzilla Migration Userinteraudio: Add option to enable/disable gap flags in nullsample buffers## Submitted by Carlos Rafael Giani
**[Link to original bug (#791353)](https://bugzilla.gnome.org/show_bug.cgi?id=791353)**
## Description
If the interaudio channel runs out of data, nullsample buffers are created.
interaudiosrc s...## Submitted by Carlos Rafael Giani
**[Link to original bug (#791353)](https://bugzilla.gnome.org/show_bug.cgi?id=791353)**
## Description
If the interaudio channel runs out of data, nullsample buffers are created.
interaudiosrc sets the GAP flag of these buffers. In some cases, it may
be preferable to not set the flag (for example, to produce one continuous
seamless stream even if the other side of the channel is currently paused).
One such case would be a system with a producer and a consumer pipeline, linked
together through an interaudio channel. The consumer pipeline always runs, while
the producer pipeline may sometimes be stopped, seeking, paused etc. In such a
case, it is necessary to make sure the consumer's interaudiosrc produces a
continuous stream. GAP flags would introduce unnecessary resynchronization events
inside the consumer pipeline's audio sink.
### Depends on
* [Bug 781721](https://bugzilla.gnome.org/show_bug.cgi?id=781721)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/637interaudio: Drain samples before setting new caps2021-09-24T14:36:00ZBugzilla Migration Userinteraudio: Drain samples before setting new caps## Submitted by Carlos Rafael Giani
**[Link to original bug (#791348)](https://bugzilla.gnome.org/show_bug.cgi?id=791348)**
## Description
Currently, when caps change, any samples remaining inside the channel are thrown away, causin...## Submitted by Carlos Rafael Giani
**[Link to original bug (#791348)](https://bugzilla.gnome.org/show_bug.cgi?id=791348)**
## Description
Currently, when caps change, any samples remaining inside the channel are thrown away, causing data loss. Fix this by draining them before the caps are changed in gst_inter_audio_sink_set_caps().
### Depends on
* [Bug 781721](https://bugzilla.gnome.org/show_bug.cgi?id=781721)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/635opusparse: subtract clipped audio to buffer duration2021-09-24T14:35:59ZBugzilla Migration Useropusparse: subtract clipped audio to buffer duration## Submitted by Alicia Boya García `@ntrrgc`
**[Link to original bug (#791099)](https://bugzilla.gnome.org/show_bug.cgi?id=791099)**
## Description
opusparse is not subtracting codec delay from the buffer duration.
Generate tes...## Submitted by Alicia Boya García `@ntrrgc`
**[Link to original bug (#791099)](https://bugzilla.gnome.org/show_bug.cgi?id=791099)**
## Description
opusparse is not subtracting codec delay from the buffer duration.
Generate test vector:
$ gst-launch-1.0 audiotestsrc num-buffers=1 samplesperbuffer=24000 ! audio/x-raw, rate=48000 ! opusenc ! identity error-after=2 ! webmmux ! filesink location=/tmp/audio-clipping-test-vector.webm
Test:
$ gst-launch-1.0 -v pushfilesrc location=/tmp/audio-clipping-test-vector.webm \
! matroskademux ! identity name="after_matroskademux" silent=false \
! opusparse ! identity name="after_opusparse" silent=false \
! opusdec ! identity name="after_opusdec" silent=false \
! fakesink 2>&1 |grep chain
/GstPipeline:pipeline0/GstIdentity:after_matroskademux: last-message = chain ******* (after_matroskademux:sink) (160 bytes, dts: none, pts: 0:00:00.000000000, duration: 0:00:00.013500000, offset: -1, offset_end: -1, flags: 00004040 discont tag-memory , meta: GstAudioClippingMeta) 0x7f13c800a060
/GstPipeline:pipeline0/GstIdentity:after_opusparse: last-message = chain ******* (after_opusparse:sink) (160 bytes, dts: 0:00:00.000000000, pts: 0:00:00.000000000, duration: 0:00:00.020000000, offset: 20000000, offset_end: 960, flags: 00004040 discont tag-memory , meta: GstAudioClippingMeta) 0x7f13c800a060
/GstPipeline:pipeline0/GstIdentity:after_opusdec: last-message = chain ******* (after_opusdec:sink) (1296 bytes, dts: none, pts: 0:00:00.000000000, duration: 0:00:00.013500000, offset: -1, offset_end: -1, flags: 00000040 discont , meta: none) 0x7f13c800ab00
Note the inconsistency in durations and GstAudioClippingMeta:
Expected*:
matroskademux ------------> opusparse -----------> opusdec ------------>
13.5ms 13.5ms 13.5ms
clip meta clip meta no clip meta
Actual:
matroskademux ------------> opusparse -----------> opusdec ------------>
13.5ms 20.0ms 13.5ms
clip meta clip meta no clip meta
* I'm supposing that GstBuffer durations should already have GstAudioClippingMeta subtracted. I could not find any hints in the documentation one way or the other, so I'm picking sides with matroskademux because is gst-plugins-good. In any case, the current behavior is definitively inconsistent because matroskademux is subtracting them while opusparse is not.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/634CineForm plugin for GStreamer bad2021-09-24T14:35:58ZBugzilla Migration UserCineForm plugin for GStreamer bad## Submitted by Emeric Grange `@emericg`
**[Link to original bug (#790793)](https://bugzilla.gnome.org/show_bug.cgi?id=790793)**
## Description
Created attachment 364334
add CineForm to cerbero
So this is an initial submissio...## Submitted by Emeric Grange `@emericg`
**[Link to original bug (#790793)](https://bugzilla.gnome.org/show_bug.cgi?id=790793)**
## Description
Created attachment 364334
add CineForm to cerbero
So this is an initial submission for a CineForm plugin with encoding and decoding capability. It use the official CineForm SDK from https://github.com/gopro/cineform-sdk.
CineForm is an I frame only codec, which makes this plugin very simple.
The pixel formats used internally by the SDK are not mapping very well with the ones from GStreamer, so the decoder plugin output regular 8b RGB and the encoder can take YUY2 or r210 buffers, but it is planned to go full b64a (ARGB64_BE) to avoid unnecessary conversions and take advantage of the 10-12 bits per pixel without subsampling of the CineForm coding.
Right now we have a few limitations:
- Pixel formats used by the plugin are not optimal (we are working on ARGB64 BE/LE support for GStreamer).
- The CineForm SDK does not build on mingw (still working on that).
- Performances of the open source CineForm SDK (v10) doesn't match the performances of the proprietary SDK (<= v9).
We do not seek inclusion yet, just comments. Attached are cerbero and gst-plugins-bad patches.
Thanks.
~~**Patch 364334**~~, "add CineForm to cerbero":
[0001-Add-CineForm-SDK-to-the-recipes-and-as-a-dependency-.patch](/uploads/740403ad3f089a43faefeaba274cad21/0001-Add-CineForm-SDK-to-the-recipes-and-as-a-dependency-.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/633h264parse: early set src caps when input is avc2021-09-24T14:35:57ZBugzilla Migration Userh264parse: early set src caps when input is avc## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#790709)](https://bugzilla.gnome.org/show_bug.cgi?id=790709)**
## Description
.## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#790709)](https://bugzilla.gnome.org/show_bug.cgi?id=790709)**
## Description
.