gst-plugins-bad issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues2021-09-24T14:36:05Zhttps://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/651wasapi: Implement automatic stream management2022-04-17T19:55:18ZBugzilla Migration Userwasapi: Implement automatic stream management## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#793059)](https://bugzilla.gnome.org/show_bug.cgi?id=793059)**
## Description
Currently, when using wasapisrc/wasapisink, if the default source devices changes WA...## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#793059)](https://bugzilla.gnome.org/show_bug.cgi?id=793059)**
## Description
Currently, when using wasapisrc/wasapisink, if the default source devices changes WASAPI captures and sends us silence, and if the default sink device changes WASAPI throws away all rendered audio. Starting with Windows 10, WASAPI now has automatic stream management:
https://msdn.microsoft.com/en-us/library/windows/desktop/mt784437(v=vs.85).aspx
We should implement this in such a way that this mechanism is used at runtime if running on Windows 10, and a fallback mechanism (manually switching devices) is used when running on Windows 7 or 8.https://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/648smoothstreaming: fix H264 CodecPrivateData parsing, need to skip NALU type wh...2020-03-10T14:11:50ZBugzilla Migration Usersmoothstreaming: fix H264 CodecPrivateData parsing, need to skip NALU type when using gst_h264_parse_sps()## Submitted by yyc..@..il.com
**[Link to original bug (#792448)](https://bugzilla.gnome.org/show_bug.cgi?id=792448)**
## Description
Created attachment 366694
smoothstreaming-fix-H264-CodecPrivateData-parsing-ne.patch
gstmss...## Submitted by yyc..@..il.com
**[Link to original bug (#792448)](https://bugzilla.gnome.org/show_bug.cgi?id=792448)**
## Description
Created attachment 366694
smoothstreaming-fix-H264-CodecPrivateData-parsing-ne.patch
gstmssmanifest.c use function _gst_mss_stream_add_h264_codec_data() to parse
the H264CodecPrivateData. But gst_h264_video_calculate_framerate() might get
an incorrect framerate, because SPS NALU type(0x67) was forgot to skip by
using gst_h264_parse_sps() to do the parsing.
~~**Attachment 366694**~~, "smoothstreaming-fix-H264-CodecPrivateData-parsing-ne.patch":
[0001-smoothstreaming-fix-H264-CodecPrivateData-parsing-ne.patch](/uploads/924ad84e46c594bbfa9890d8c14673e1/0001-smoothstreaming-fix-H264-CodecPrivateData-parsing-ne.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/647dashdemux: do not parse mpd file and setup streams if updated mpd file is not...2021-10-20T08:30:37ZBugzilla Migration Userdashdemux: do not parse mpd file and setup streams if updated mpd file is not changed at all## Submitted by Jun Xie
**[Link to original bug (#792263)](https://bugzilla.gnome.org/show_bug.cgi?id=792263)**
## Description
if updated mpd file is the same with last one, not changed at all, then no bother to parse mpd file and s...## Submitted by Jun Xie
**[Link to original bug (#792263)](https://bugzilla.gnome.org/show_bug.cgi?id=792263)**
## Description
if updated mpd file is the same with last one, not changed at all, then no bother to parse mpd file and setup streams.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/646hlsdemux: setup new stream if current variant stream becomes invalid and is r...2023-06-16T12:07:35ZBugzilla Migration Userhlsdemux: setup new stream if current variant stream becomes invalid and is removed from master playlist## Submitted by Jun Xie
**[Link to original bug (#792232)](https://bugzilla.gnome.org/show_bug.cgi?id=792232)**
## Description
During updating manifest, current variant stream is checked for validity.
If it becomes invalid, master...## Submitted by Jun Xie
**[Link to original bug (#792232)](https://bugzilla.gnome.org/show_bug.cgi?id=792232)**
## Description
During updating manifest, current variant stream is checked for validity.
If it becomes invalid, master playlist is updated and old variant streams are compared new variant stream.
Currently, only a warning log is shown.
>hlsdemux gsthlsdemux.c:1288:gst_hls_demux_update_variant_playlist:[00m Unable to match current playlist
I think we need to :
1) reset current variant,
2) setup new stream.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/645nvdec: Fail to load plugin - missing cudart library in runtime2018-11-26T00:17:08ZBugzilla Migration Usernvdec: Fail to load plugin - missing cudart library in runtime## Submitted by Snir Sheriber `@snir`
**[Link to original bug (#792171)](https://bugzilla.gnome.org/show_bug.cgi?id=792171)**
## Description
When compiling nvdec, linking is done against the libs (libcuda, libcudart) that are provid...## Submitted by Snir Sheriber `@snir`
**[Link to original bug (#792171)](https://bugzilla.gnome.org/show_bug.cgi?id=792171)**
## Description
When compiling nvdec, linking is done against the libs (libcuda, libcudart) that are provided by cuda-tools (path is set by the --with-cuda-prefix or pkg-config).
In runtime, required libraries are searched in the runtime-library-path.
libcudart is installed only by cuda-tools in a path does not exist by default in runtime-library-paths, so libcudart cannot be found and nvdec fails to load.
Adding cuda-tools libraries directory to runtime-library-path overcomes this issue.
There are no issues with libcuda since the library is also installed by the driver installer in the default library path location.
Steps to reproduce
1. Have a supported Nvidia card and install driver & cuda tools 8.0
2. Build nvdec with --with-cuda-prefix to installed location (or set PKG_CONFIG_PATH)
3. Try to use nvdechttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/644hlsdemux: check sequence number as spec defined2023-05-16T16:27:43ZBugzilla Migration Userhlsdemux: check sequence number as spec defined## Submitted by Jun Xie
**[Link to original bug (#791981)](https://bugzilla.gnome.org/show_bug.cgi?id=791981)**
## Description
#quoted from hls spec:
6.2.2. Live Playlists
Media Segments MUST be removed from the Pla...## Submitted by Jun Xie
**[Link to original bug (#791981)](https://bugzilla.gnome.org/show_bug.cgi?id=791981)**
## Description
#quoted from hls spec:
6.2.2. Live Playlists
Media Segments MUST be removed from the Playlist file in the order
that they appear in the Playlist; otherwise, client playback can
malfunction.
6.3.4. Reloading the Media Playlist File
After reloading a Media Playlist, the client SHOULD verify that each
Media Segment in it has the same URI (and byte range, if specified)
as the Media Segment with the same Media Sequence Number in the
previous Media Playlist. It SHOULD halt playback if it does not, as
this normally indicates a server error.https://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/642Improve support for KLV metadata in tsdemuxer and tsmuxer2023-11-20T06:57:53ZBugzilla Migration UserImprove support for KLV metadata in tsdemuxer and tsmuxer## Submitted by Michael Fien
**[Link to original bug (#791533)](https://bugzilla.gnome.org/show_bug.cgi?id=791533)**
## Description
Created attachment 365454
Mpeg2 transport stream descriptor for KLV
Add additions to tsdemuxe...## Submitted by Michael Fien
**[Link to original bug (#791533)](https://bugzilla.gnome.org/show_bug.cgi?id=791533)**
## Description
Created attachment 365454
Mpeg2 transport stream descriptor for KLV
Add additions to tsdemuxer and tsmuxer that handle synchronous and asynchronous metadata streams per MISB-0604
**Patch 365454**, "Mpeg2 transport stream descriptor for KLV":
[0001-Add-MPEG2-TS-descriptor-support-for-KLV-metadata.patch](/uploads/59a5e1767a3994cafa3dc482345e58e2/0001-Add-MPEG2-TS-descriptor-support-for-KLV-metadata.patch)
Version: 1.12.0https://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/636dashdemux: doesn't play facebook live streams2021-10-20T08:33:39ZBugzilla Migration Userdashdemux: doesn't play facebook live streams## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#791207)](https://bugzilla.gnome.org/show_bug.cgi?id=791207)**
## Description
I'm trying to play MPEG-DASH streams from facebook live
1. go to https://www.faceboo...## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#791207)](https://bugzilla.gnome.org/show_bug.cgi?id=791207)**
## Description
I'm trying to play MPEG-DASH streams from facebook live
1. go to https://www.facebook.com/live/ and select a random stream
2. view the stream, right-click, display stream uri
3. copy that stream uri and run it though youtube-dl -g $uri
4. you get the actual MPEG DASH manifest uri which can be fed into gst-play
e.g. gst-play-1.0 "https://video.ftxl1-1.fna.fbcdn.net/hvideo-ash5/v/rMTvKZnCY3MLMygC0gCTG/live-dash/dash-abr1/761610404036944.mpd?_nc_rl=AfAdnDdKb8wmBUW6&oh=5199f0f8ddb5624c41c42a93727af578&oe=5A27CF0B" -v
result is just a tiny thumbnail which doesn't move
with gst-launch-1.0 uridecodebin uri="..." ! autovideosink sync=false at least there is a little bit of motion but the stream is also full of defects
... ! autoaudiosink sync=false will usually sound fine though
when looking at the timestamps falling out of the dashdemux with
gst-launch-1.0 souphttpsrc location="https://video.ftxl1-1.fna.fbcdn.net/hvideo-atn2/v/r9sFsHpnUNM2jJZUix-M2/live-dash/dash-abr4/2081836301833050.mpd?_nc_rl=AfDWx0uVBpW-bxwm&oh=77a92c9031f065a1e801f47bfdcadaa6&oe=5A278CA6" ! dashdemux ! fakesink silent=false -v
...
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (664 bytes, dts: none, pts: 1:00:50.381000000, duration: none, offset: 0, offset_end: 664, flags: 00000040 discont , meta: none) 0x7f0cf801c620
it seems that the timestamps start way in the future which prevents the playback
Version: 1.12.3https://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)