gst-plugins-good issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues2021-09-24T13:29:50Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/28shapewipe, matroskademux, matroskaparse: post QoS messages when dropping buff...2021-09-24T13:29:50ZBugzilla Migration Usershapewipe, matroskademux, matroskaparse: post QoS messages when dropping buffers due to QoS## Submitted by Tim Müller `@tpm`
**[Link to original bug (#617022)](https://bugzilla.gnome.org/show_bug.cgi?id=617022)**
## Description
Subject says it all really. Should go through decoders that implement QoS and make them post Qo...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#617022)](https://bugzilla.gnome.org/show_bug.cgi?id=617022)**
## Description
Subject says it all really. Should go through decoders that implement QoS and make them post QoS messages on the bus when they drop stuff.
ext/dv/gstdvdemux.c: case GST_EVENT_QOS:
ext/jpeg/gstjpegdec.c: case GST_EVENT_QOS:{
gst/avi/gstavidemux.c: case GST_EVENT_QOS:
gst/deinterlace/gstdeinterlace.c: case GST_EVENT_QOS:{
gst/goom/gstgoom.c: case GST_EVENT_QOS:
gst/goom2k1/gstgoom.c: case GST_EVENT_QOS:
gst/interleave/interleave.c: case GST_EVENT_QOS:
gst/matroska/matroska-demux.c: case GST_EVENT_QOS:
gst/monoscope/gstmonoscope.c: case GST_EVENT_QOS:{
gst/qtdemux/qtdemux.c: case GST_EVENT_QOS:
gst/rtsp/gstrtspsrc.c: case GST_EVENT_QOS:
gst/rtsp/gstrtspsrc.c: case GST_EVENT_QOS:
gst/shapewipe/gstshapewipe.c: case GST_EVENT_QOS:{
gst/videomixer/videomixer.c: case GST_EVENT_QOS:{https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/30[2.0] qtdemux: mpeg audio version 2 is reported as version 12021-09-24T13:29:51ZBugzilla Migration User[2.0] qtdemux: mpeg audio version 2 is reported as version 1## Submitted by Josep Torra `@adn770`
**[Link to original bug (#619300)](https://bugzilla.gnome.org/show_bug.cgi?id=619300)**
## Description
The demuxer generate caps with version 1 for mpeg audio in both cases.
Version: 2.x## Submitted by Josep Torra `@adn770`
**[Link to original bug (#619300)](https://bugzilla.gnome.org/show_bug.cgi?id=619300)**
## Description
The demuxer generate caps with version 1 for mpeg audio in both cases.
Version: 2.x2.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/31mpegaudioparse: Add support for LAME tags and adjust segments based on the pa...2022-05-04T19:50:42ZBugzilla Migration Usermpegaudioparse: Add support for LAME tags and adjust segments based on the padding information from it## Submitted by nyall
**[Link to original bug (#620323)](https://bugzilla.gnome.org/show_bug.cgi?id=620323)**
## Description
Currently, gstreamer is ignoring the lame tags in mp3s during gapless playback. These tags contain informat...## Submitted by nyall
**[Link to original bug (#620323)](https://bugzilla.gnome.org/show_bug.cgi?id=620323)**
## Description
Currently, gstreamer is ignoring the lame tags in mp3s during gapless playback. These tags contain information about the padding at the start and end of the files, which should be skipped to get perfect gapless playback of these files. Without using these tags, there'll always be a tiny silence or glitch between songs.
Here's an example of the lame tags in a file which should play back gaplessly:
$eyeD3 --lametag Track01.mp3
Track01.mp3 [ 3.77 MB ]
Encoder Version : LAME3.98r
LAME Tag Revision : 0
VBR Method : Variable Bitrate method2 (mtrh)
Lowpass Filter : 18500
Radio Replay Gain : -2.0 dB (Set automatically)
Encoding Flags : --nspsytune --nssafejoint
ATH Type : 4
Bitrate (Minimum) : 192
Encoder Delay : 576 samples
Encoder Padding : 960 samples
Noise Shaping : 1
Stereo Mode : Joint
Unwise Settings : False
Sample Frequency : 44.1 kHz
MP3 Gain : 0 (+0.0 dB)
Preset : V2
Surround Info : None
Music Length : 3.77 MB
Music CRC-16 : 07F9
LAME Tag CRC-16 : E5BF
The encoder delay and encoder padding tags describe how many samples were added at the start and end of the audio to complete the frames. Some more information is available on this page: http://gabriel.mp3-tech.org/mp3infotag.html
### Depends on
* [Bug 740196](https://bugzilla.gnome.org/show_bug.cgi?id=740196)1.21.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/32rtspsrc: backward playback2023-10-13T23:43:34ZBugzilla Migration Userrtspsrc: backward playback## Submitted by Tibor Kocsis
**[Link to original bug (#626811)](https://bugzilla.gnome.org/show_bug.cgi?id=626811)**
## Description
Hi,
are you planning to implement the support of backward playback (seek with negative rate on ...## Submitted by Tibor Kocsis
**[Link to original bug (#626811)](https://bugzilla.gnome.org/show_bug.cgi?id=626811)**
## Description
Hi,
are you planning to implement the support of backward playback (seek with negative rate on the client side) in rtspsrc? Is there any proposed release date for that? What are the reasons it isn't ready yet, maybe there are technical issues?
Regards
Tibor2023-10-21https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/34rtpmp4apay: add "config-interval" property to multiplex aac audio config data...2021-09-24T13:29:54ZBugzilla Migration Userrtpmp4apay: add "config-interval" property to multiplex aac audio config data into resulting data stream## Submitted by wul..@..il.com
**[Link to original bug (#629545)](https://bugzilla.gnome.org/show_bug.cgi?id=629545)**
## Description
Freature Request: rtpmp4apay element GStreamer
Up till now with the help of rtpmp4apay one is...## Submitted by wul..@..il.com
**[Link to original bug (#629545)](https://bugzilla.gnome.org/show_bug.cgi?id=629545)**
## Description
Freature Request: rtpmp4apay element GStreamer
Up till now with the help of rtpmp4apay one is able to stream aac audio data compliant to RFC 3016. But it's still necessary to tell the backend
the config parameter (StreamMuxConfig element) by means of SDP for example in order to listen to the music at the receiver side. This request
is about adding the feature of multiplexing aac audio config data into the resulting data stream.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/36[flacenc] does not support changing the number of channels on the fly2021-09-24T13:29:55ZBugzilla Migration User[flacenc] does not support changing the number of channels on the fly## Submitted by Julien Isorce `@cap`
**[Link to original bug (#632798)](https://bugzilla.gnome.org/show_bug.cgi?id=632798)**
## Description
Created attachment 172941
aac file that contains 2 audio channels then 6 then 2 then 6 (re...## Submitted by Julien Isorce `@cap`
**[Link to original bug (#632798)](https://bugzilla.gnome.org/show_bug.cgi?id=632798)**
## Description
Created attachment 172941
aac file that contains 2 audio channels then 6 then 2 then 6 (recorded with faac outputformat=1)
** steps to reproduce:
gst-launch-0.10 filesrc location=res.aac ! aacparse ! faad ! flacenc ! fakesink
** Actual result:
"WARNING: flac already initialized -- fixme allow this"
** Excepted result:
Does the 'fixme allow this' mean that it would be possible to call 'gst_flac_enc_sink_setcaps' if encoder is already initialized ? flac specs ?
**Attachment 172941**, "aac file that contains 2 audio channels then 6 then 2 then 6 (recorded with faac outputformat=1)":
[res.aac](/uploads/307793f0af9adcab9da1fd42fae88db4/res.aac)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/39jpegdec: Pixart JPEG support2023-07-01T21:34:28ZBugzilla Migration Userjpegdec: Pixart JPEG support## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#642411)](https://bugzilla.gnome.org/show_bug.cgi?id=642411)**
## Description
Created attachment 180937
gdp payloaded stream
I've got a webcam that...## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#642411)](https://bugzilla.gnome.org/show_bug.cgi?id=642411)**
## Description
Created attachment 180937
gdp payloaded stream
I've got a webcam that produces Progressive JPG frames and it seems jpegdec can't handle it.
I'm attaching the output of:
gst-launch v4l2src device=/dev/video1 num-buffers=5 ! gdppay ! filesink
**Attachment 180937**, "gdp payloaded stream":
[progressive-jpg.gdp](/uploads/e261fbf24de5d97ae6f62d54b408a510/progressive-jpg.gdp)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/41[dcaparse] implement 14-to-16-bit conversion2021-09-24T13:29:57ZBugzilla Migration User[dcaparse] implement 14-to-16-bit conversion## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#644768)](https://bugzilla.gnome.org/show_bug.cgi?id=644768)**
## Description
this is an extension for https://bugzilla.gnome.org/show_bug.cgi?id=644208
some deco...## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#644768)](https://bugzilla.gnome.org/show_bug.cgi?id=644768)**
## Description
this is an extension for https://bugzilla.gnome.org/show_bug.cgi?id=644208
some decoders can only handle 16 bit streams, so the 14 bit streams which are present in some wav containers would have to be adapted respectivelyhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/46udp: add support for IGMPv3 SSM (Source Specific Multicast RFC 4604)2023-06-23T22:16:15ZBugzilla Migration Userudp: add support for IGMPv3 SSM (Source Specific Multicast RFC 4604)## Submitted by Julien Isorce `@cap`
**[Link to original bug (#652711)](https://bugzilla.gnome.org/show_bug.cgi?id=652711)**
## Description
Created attachment 190026
when joining a multicast stream, users can select the source the...## Submitted by Julien Isorce `@cap`
**[Link to original bug (#652711)](https://bugzilla.gnome.org/show_bug.cgi?id=652711)**
## Description
Created attachment 190026
when joining a multicast stream, users can select the source they want to receive the stream from
* Overview: for now when joining a multicast stream, users cannot select the source they want to receive the stream from.
* Additional Information: The kernel configuration determines which IGMP version to use.
On linux you can select the minimum IGMP version to use.
On windows, you can only select the maximum IGMP version to use. IGMPv3 + SSM is avaible from winXP_SP1. On winXP (don't know on vista and seven) when a network interface sees a IGMPv1 or IGMPv2 it becomes impossible to send a IGMPv3 packet without restarting the network interface (http://support.microsoft.com/kb/815752)
~~**Patch 190026**~~, "when joining a multicast stream, users can select the source they want to receive the stream from":
[0001-udp-add-support-for-IGMPv3-SSM-Source-Specific-Multi.patch](/uploads/fab8301eb8905242656e9dec43e7807b/0001-udp-add-support-for-IGMPv3-SSM-Source-Specific-Multi.patch)
### Depends on
* [Bug 740791](https://bugzilla.gnome.org/show_bug.cgi?id=740791)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/47wavenc: Go EOS and report an error if larger than 2GB2024-03-07T13:02:34ZBugzilla Migration Userwavenc: Go EOS and report an error if larger than 2GB## Submitted by j^
**[Link to original bug (#654243)](https://bugzilla.gnome.org/show_bug.cgi?id=654243)**
## Description
encoding files longer than 1h40m with this pipeline:
gst-launch-0.10 pulsesrc ! queue ! audio/x-raw-int,r...## Submitted by j^
**[Link to original bug (#654243)](https://bugzilla.gnome.org/show_bug.cgi?id=654243)**
## Description
encoding files longer than 1h40m with this pipeline:
gst-launch-0.10 pulsesrc ! queue ! audio/x-raw-int,rate=44100,channels=2 ! wavenc ! filesink location=/tmp/test.wav
creates a corrupt wav files. its opened in totem/audacity but only the first 2GB of data are played.
Ot is possible to open the file in audacity as raw samples, skipping the header(first 20bytes). So data gets written to disk but the wav headers are wrong.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/50isomp4: Add support for GstForceKeyUnit events2023-07-02T16:24:35ZBugzilla Migration Userisomp4: Add support for GstForceKeyUnit events## Submitted by Andoni Alastruey `@ylatuya`
**[Link to original bug (#660260)](https://bugzilla.gnome.org/show_bug.cgi?id=660260)**
## Description
Created attachment 197584
0002-Add-support-for-GstForceKeyUnit-events.patch
Th...## Submitted by Andoni Alastruey `@ylatuya`
**[Link to original bug (#660260)](https://bugzilla.gnome.org/show_bug.cgi?id=660260)**
## Description
Created attachment 197584
0002-Add-support-for-GstForceKeyUnit-events.patch
The flowing patch adds support for GstForceKeyUnit events to ismlmux.
I have added a new property called 'fragment-method':
* NONE: do not fragment (default value for muxers that are not the ismlmux)
* TIME: fragment by time, set in the fragment-duration property (default value for the ismlmux, keeping the old behaviour)
* EVENT: Uses the GstForceKeyUnit event to generate fragments.
This muxer is different from the other ones (webm or mpegts) in the sense that it can mux several video qualities and the audio track is packed in a separate fragment. So to make it work the audio pad should be receiving GstForceKeyUnits too.
I have tested this patch using Flumotion's smooth streamer[1] with a pipeline similar to:
vsource ! keyunitsscheduler ! tee name=t ! h264enc ! ismlmux name=mux ! streamer
t. ! h264enc ! mux.
t. ! h264enc ! mux.
asource ! keyunitsscheduler ! aacenc ! mux.
This patch relies in the new API for GstForceKeyUnit events
[1] https://code.flumotion.com/cgit/flumotion-fragmented-streaming/
~~**Patch 197584**~~, "0002-Add-support-for-GstForceKeyUnit-events.patch":
[0002-Add-support-for-GstForceKeyUnit-events.patch](/uploads/176b0d0fd46156272a997d70b08f2e1e/0002-Add-support-for-GstForceKeyUnit-events.patch)
### Depends on
* [Bug 607742](https://bugzilla.gnome.org/show_bug.cgi?id=607742)
### Blocking
* [Bug 668091](https://bugzilla.gnome.org/show_bug.cgi?id=668091)
* [Bug 668094](https://bugzilla.gnome.org/show_bug.cgi?id=668094)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/51mp4mux: should add support for PSP ftyp2021-09-24T13:30:00ZBugzilla Migration Usermp4mux: should add support for PSP ftyp## Submitted by an unknown user
**[Link to original bug (#660783)](https://bugzilla.gnome.org/show_bug.cgi?id=660783)**
## Description
the Playstation portable uses its own ftyp for what is basically a mp42 file with some size/fps a...## Submitted by an unknown user
**[Link to original bug (#660783)](https://bugzilla.gnome.org/show_bug.cgi?id=660783)**
## Description
the Playstation portable uses its own ftyp for what is basically a mp42 file with some size/fps and codec limitations. List below of file information as provided by the mediainfo tool.
General
Complete name : PSPGO_FINAL.MP4
Format : MPEG-4
Format profile : Sony PSP
Codec ID : MSNV
File size : 32.6 MiB
Duration : 1mn 44s
Overall bit rate : 2 610 Kbps
Encoded date : UTC 2009-05-26 23:23:08
Tagged date : UTC 2009-05-26 23:23:08
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L2.1
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1mn 44s
Bit rate mode : Variable
Bit rate : 1 568 Kbps
Width : 480 pixels
Height : 270 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.404
Stream size : 19.6 MiB (60%)
Language : English
Encoded date : UTC 2009-05-26 23:23:08
Tagged date : UTC 2009-05-26 23:23:08
Color primaries : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M
Transfer characteristics : BT.601-6 525, BT.601-6 625, BT.1358 525, BT.1358 625, BT.1700 NTSC, SMPTE 170M
Matrix coefficients : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M
Audio` #1`
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 1mn 44s
Bit rate mode : Variable
Bit rate : 128 Kbps
Maximum bit rate : 384 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 1.60 MiB (5%)
Language : English
Encoded date : UTC 2009-05-26 23:23:08
Tagged date : UTC 2009-05-26 23:23:08
Correct example file:
http://gstreamer.freedesktop.org/media/large/PSPGO_FINAL.MP4https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/55qtmux: Add support for DASH2023-07-01T21:39:31ZBugzilla Migration Userqtmux: Add support for DASH## Submitted by Andoni Alastruey `@ylatuya`
**[Link to original bug (#668091)](https://bugzilla.gnome.org/show_bug.cgi?id=668091)**
## Description
Created attachment 205444
Add DASH comtaible muxer
Dash support for the ISO fi...## Submitted by Andoni Alastruey `@ylatuya`
**[Link to original bug (#668091)](https://bugzilla.gnome.org/show_bug.cgi?id=668091)**
## Description
Created attachment 205444
Add DASH comtaible muxer
Dash support for the ISO file format has been defined in the Amendment 3 of the ISO/IEC 14496-12 standard.
Basic support can be added by appending the new 'styp', identical to the ftyp box in front of each fragment.
~~**Patch 205444**~~, "Add DASH comtaible muxer":
[0001-mp4dashmux-Add-DASH-compatible-mp4-muxer.patch](/uploads/dd2b0e8235d8c729a5b08e0f7ffb7b42/0001-mp4dashmux-Add-DASH-compatible-mp4-muxer.patch)
### Depends on
* [Bug 660260](https://bugzilla.gnome.org/show_bug.cgi?id=660260)
### Blocking
* [Bug 777984](https://bugzilla.gnome.org/show_bug.cgi?id=777984)
* [Bug 668094](https://bugzilla.gnome.org/show_bug.cgi?id=668094)
* [Bug 708221](https://bugzilla.gnome.org/show_bug.cgi?id=708221)
* [Bug 777540](https://bugzilla.gnome.org/show_bug.cgi?id=777540)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/57rtspsrc enhancement with events2021-09-24T13:30:02ZBugzilla Migration Userrtspsrc enhancement with events## Submitted by Farkas Levente `@lfarkas`
Assigned to **Farkas Levente `@lfarkas`**
**[Link to original bug (#669746)](https://bugzilla.gnome.org/show_bug.cgi?id=669746)**
## Description
hi,
currently the rtspsrc in gstreamer ar...## Submitted by Farkas Levente `@lfarkas`
Assigned to **Farkas Levente `@lfarkas`**
**[Link to original bug (#669746)](https://bugzilla.gnome.org/show_bug.cgi?id=669746)**
## Description
hi,
currently the rtspsrc in gstreamer are not able to handle any kind of play related events except seek. even seek was implemented at the rtsp level (send a pause then seek and play). all other events are dropped in
http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtsp/gstrtspsrc.c
in gst_rtspsrc_handle_src_event then in gst_rtspsrc_handle_internal_src_event function which simple drop these events.
we'd like to implement at least SEEK, RATE, STEP and NAVIGATION event in rtspsrc to be able to send these events through rtspsrc and the server get it. so we'd like to play with different rate, backward and frame by frame through rtsp. and if the server implements it than it can handle it. (of course we'd like to implement the server side too).
of course we'd like to add the patches to gstreamer, but before we start to implement it we'd like to ask core gstreamer developers which would be the preferred way you ie. how to implement it to be easily accepted by you to inclusion. we thought the best would be to send these events through the rtcp protocol which is something for it.
we'd like to do it first in the 0.10 branch.
what do you think about it?
thanks in advance.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/58vp8enc: better defaults, more presets/profiles2020-01-28T07:33:40ZBugzilla Migration Uservp8enc: better defaults, more presets/profiles## Submitted by Tim Müller `@tpm`
**[Link to original bug (#670108)](https://bugzilla.gnome.org/show_bug.cgi?id=670108)**
## Description
Just some quick comments on our default values from an e-mail exchange with Ronald:
> mod...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#670108)](https://bugzilla.gnome.org/show_bug.cgi?id=670108)**
## Description
Just some quick comments on our default values from an e-mail exchange with Ronald:
> mode : Mode
> Enum "GstVP8EncMode" Default: 0, "vbr"
> (0): vbr - Variable Bit Rate (VBR) mode
> (1): cbr - Constant Bit Rate (CBR) mode
You may want to look into CQ mode (2) also.
> max-keyframe-distance: Maximum distance between key frames
> Integer. Range: 0 - 9999 Default: 60
60 is quite low (for high-quality encodes), any particular reason for that?
I think in our tests and on webmproject.org, we recommend 120 frames
as kf interval.
> multipass-mode : Multipass encode mode
> Enum "GstVP8EncMultipassMode" Default: 0, "one-pass"
> (0): one-pass - One pass encoding (default)
> (1): first-pass - First pass of multipass encoding
> (2): last-pass - Last pass of multipass encoding
Can the default be changes to 2pass? We really do all our internal
testing for high-quality encodes on 2pass, it'll generate much better
output (in the range of >1dB difference).
(tpm: can't ever default to 2-pass, since that requires co-operation by the application. 2-pass can only ever be opt-in)
> auto-alt-ref-frames : Automatically create alternative
> reference frames
> Boolean. Default: false
This isn't a good idea, alt-refs by themselves will also cause several
tenths of dB difference (in a positive way), I'd highly recommend you
turn them on for high-quality (2pass) encodes.
(tpm: only for high-quality 2-pass encodes? BBB: yes)
> lag-in-frames : If set, this value allows the encoder to consume
> a number of input frames before producing output frames.
> Unsigned Integer. Range: 0 - 64 Default: 0
Probably want to up this to e.g. 25 for high-quality encodes (unless 0
means 'don't touch').
(tpm: I think 0 means whatever the library default is, someone needs to check this)
> tune : Tune
> Enum "GstVP8EncTune" Default: 0, "psnr"
> (0): psnr - Tune for PSNR
> (1): ssim - Tune for SSIM
Minor nit, most people would claim ssim is a better default here, but
it's not that relevant.
I see you haven't mapped the ARNR options, which provide a quality
boost for noisy input (without affecting noiseless input much), are
you guys interested in exposing these options also? They affect the
way the alt-ref frame is used.
(tpm: might be good for input from webcams - though what would be even better if we could detect that kind of input and switch to that mode automatically)
Other possibly interesting pages:
http://www.webmproject.org/tools/encoder-parameters/https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/59qtdemux: better handling of unknown QuickTime tag warnings2021-09-24T13:30:03ZBugzilla Migration Userqtdemux: better handling of unknown QuickTime tag warnings## Submitted by Matej `@Knopp`
**[Link to original bug (#670214)](https://bugzilla.gnome.org/show_bug.cgi?id=670214)**
## Description
I'm getting lot of when opening a quicktime file, perhaps these should be added?
WARN gst.qt...## Submitted by Matej `@Knopp`
**[Link to original bug (#670214)](https://bugzilla.gnome.org/show_bug.cgi?id=670214)**
## Description
I'm getting lot of when opening a quicktime file, perhaps these should be added?
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type elng
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type pinf
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type UUID
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type elng
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type avc1
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type avcC
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type pasp
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type pinf
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type UUID
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type fall
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type elng
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type ac-3
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type elng
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type c608
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type apID
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type cnID
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type atID
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type plID
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type geID
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type sfID
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type akID
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type hdvd
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type tvnn
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type stik
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type purd
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type xid
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type flvr
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type mean
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type name
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type ldes
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type sdes
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type mean
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type name
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type elng
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type pinf
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type UUID
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type elng
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type avc1
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type avcC
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type pasp
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type pinf
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type UUID
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type fall
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type elng
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type ac-3
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type elng
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type c608
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type apID
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type cnID
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type atID
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type plID
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type geID
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type sfID
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type akID
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type hdvd
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type tvnn
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type stik
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type purd
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type xid
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type flvr
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type mean
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type name
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type ldes
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type sdes
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type mean
WARN gst.qtdemux qtdemux_types.c:191 unknown QuickTime node type name
WARN gst.qtdemux qtdemux.c:7053 - - - unknown version 00000000
WARN gst.qtdemux qtdemux.c:7053 - - - unknown version 00000000
WARN gst.qtdemux qtdemux.c:8381 - - - This tag com.apple.iTunes:iTunEXTC type:1 is not mapped, file a bug at bugzilla.gnome.org
WARN gst.qtdemux qtdemux.c:8381 - - - This tag com.apple.iTunes:iTunMOVI type:1 is not mapped, file a bug at bugzilla.gnome.orghttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/60udpsink: implement timestamp smoothing / sender throttling (for rtprawpay and...2021-09-24T13:30:03ZBugzilla Migration Userudpsink: implement timestamp smoothing / sender throttling (for rtprawpay and gigabit ethernet)## Submitted by kwisp
**[Link to original bug (#673794)](https://bugzilla.gnome.org/show_bug.cgi?id=673794)**
## Description
Created attachment 211668
good
It is some problem with rtpvrawdepay and gigabit ethernet.
All righ...## Submitted by kwisp
**[Link to original bug (#673794)](https://bugzilla.gnome.org/show_bug.cgi?id=673794)**
## Description
Created attachment 211668
good
It is some problem with rtpvrawdepay and gigabit ethernet.
All right, if we use Fast Ethernet mode:
sender:
kwisp@klochkov ~ $ LANG=en.en GST_PLUGIN_PATH=/usr/local/lib/gstreamer-0.10/ GST_PLUGIN_SYSTEM_PATH=/usr/lib/gstreamer-0.10/ gst-launch-0.10 -v videotestsrc ! video/x-raw-yuv,format=\(fourcc\)I420,width=320,height=240 ! rtpvrawpay ! udpsink host="192.168.136.130" port=5000
Setting pipeline to PAUSED ...
/GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0.GstPad:src: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)320, height=(int)240, color-matrix=(string)sdtv, chroma-site=(string)mpeg2, framerate=(fraction)30/1
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)320, height=(int)240, color-matrix=(string)sdtv, chroma-site=(string)mpeg2, framerate=(fraction)30/1
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)320, height=(int)240, color-matrix=(string)sdtv, chroma-site=(string)mpeg2, framerate=(fraction)30/1
/GstPipeline:pipeline0/GstRtpVRawPay:rtpvrawpay0.GstPad:src: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)RAW, sampling=(string)YCbCr-4:2:0, depth=(string)8, width=(string)320, height=(string)240, colorimetry=(string)BT601-5, payload=(int)96, ssrc=(uint)2837818414, clock-base=(uint)2969841640, seqnum-base=(uint)10940
/GstPipeline:pipeline0/GstRtpVRawPay:rtpvrawpay0.GstPad:sink: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)320, height=(int)240, color-matrix=(string)sdtv, chroma-site=(string)mpeg2, framerate=(fraction)30/1
/GstPipeline:pipeline0/GstRtpVRawPay:rtpvrawpay0: timestamp = 2969841640
/GstPipeline:pipeline0/GstRtpVRawPay:rtpvrawpay0: seqnum = 10940
/GstPipeline:pipeline0/GstUDPSink:udpsink0.GstPad:sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)RAW, sampling=(string)YCbCr-4:2:0, depth=(string)8, width=(string)320, height=(string)240, colorimetry=(string)BT601-5, payload=(int)96, ssrc=(uint)2837818414, clock-base=(uint)2969841640, seqnum-base=(uint)10940
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
receiver:
unit29@calligraphy2:~$ LANG=en.en gst-launch -v udpsrc uri="udp://192.168.136.130:5000" caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)RAW, sampling=(string)YCbCr-4:2:0, depth=(string)8, width=(string)320, height=(string)240, colorimetry=(string)BT601-5, payload=(int)96, ssrc=(uint)3179834474, clock-base=(uint)2843576415, seqnum-base=(uint)64658" ! rtpvrawdepay ! xvimagesink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
/GstPipeline:pipeline0/GstRtpVRawDepay:rtpvrawdepay0.GstPad:src: caps = video/x-raw-yuv, width=(int)320, height=(int)240, format=(fourcc)I420, framerate=(fraction)0/1
/GstPipeline:pipeline0/GstRtpVRawDepay:rtpvrawdepay0.GstPad:sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)RAW, sampling=(string)YCbCr-4:2:0, depth=(string)8, width=(string)320, height=(string)240, colorimetry=(string)BT601-5, payload=(int)96, ssrc=(uint)3179834474, clock-base=(uint)2843576415, seqnum-base=(uint)64658
/GstPipeline:pipeline0/GstXvImageSink:xvimagesink0.GstPad:sink: caps = video/x-raw-yuv, width=(int)320, height=(int)240, format=(fourcc)I420, framerate=(fraction)0/1
`<good>`
If we use Gigabit ethernet mode:
sender:
LANG=en.us gst-launch -v videotestsrc ! video/x-raw-yuv,format=\(fourcc\)I420,width=320,height=240 ! rtpvrawpay ! udpsink host="192.168.192.2" port=5000
Setting pipeline to PAUSED ...
/GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0.GstPad:src: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)320, height=(int)240, color-matrix=(string)sdtv, chroma-site=(string)mpeg2, framerate=(fraction)30/1
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)320, height=(int)240, color-matrix=(string)sdtv, chroma-site=(string)mpeg2, framerate=(fraction)30/1
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)320, height=(int)240, color-matrix=(string)sdtv, chroma-site=(string)mpeg2, framerate=(fraction)30/1
/GstPipeline:pipeline0/GstRtpVRawPay:rtpvrawpay0.GstPad:src: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)RAW, sampling=(string)YCbCr-4:2:0, depth=(string)8, width=(string)320, height=(string)240, colorimetry=(string)BT601-5, payload=(int)96, ssrc=(uint)2151192507, clock-base=(uint)1835557868, seqnum-base=(uint)14436
/GstPipeline:pipeline0/GstRtpVRawPay:rtpvrawpay0.GstPad:sink: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)320, height=(int)240, color-matrix=(string)sdtv, chroma-site=(string)mpeg2, framerate=(fraction)30/1
/GstPipeline:pipeline0/GstRtpVRawPay:rtpvrawpay0: timestamp = 1835557868
/GstPipeline:pipeline0/GstRtpVRawPay:rtpvrawpay0: seqnum = 14436
/GstPipeline:pipeline0/GstUDPSink:udpsink0.GstPad:sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)RAW, sampling=(string)YCbCr-4:2:0, depth=(string)8, width=(string)320, height=(string)240, colorimetry=(string)BT601-5, payload=(int)96, ssrc=(uint)2151192507, clock-base=(uint)1835557868, seqnum-base=(uint)14436
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
receiver2:
unit29@calligraphy2:~$ LANG=en.en gst-launch -v udpsrc uri="udp://192.168.192.2:5000" caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)RAW, sampling=(string)YCbCr-4:2:0, depth=(string)8, width=(string)320, height=(string)240, colorimetry=(string)BT601-5, payload=(int)96, ssrc=(uint)2151192507, clock-base=(uint)1835557868, seqnum-base=(uint)14436" ! rtpvrawdepay ! ffmpegcolorspace ! ximagesink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
/GstPipeline:pipeline0/GstRtpVRawDepay:rtpvrawdepay0.GstPad:src: caps = video/x-raw-yuv, width=(int)320, height=(int)240, format=(fourcc)I420, framerate=(fraction)0/1
/GstPipeline:pipeline0/GstRtpVRawDepay:rtpvrawdepay0.GstPad:sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)RAW, sampling=(string)YCbCr-4:2:0, depth=(string)8, width=(string)320, height=(string)240, colorimetry=(string)BT601-5, payload=(int)96, ssrc=(uint)2151192507, clock-base=(uint)1835557868, seqnum-base=(uint)14436
/GstPipeline:pipeline0/GstFFMpegCsp:ffmpegcsp0.GstPad:src: caps = video/x-raw-rgb, bpp=(int)16, depth=(int)16, endianness=(int)1234, red_mask=(int)63488, green_mask=(int)2016, blue_mask=(int)31, width=(int)320, height=(int)240, framerate=(fraction)0/1, pixel-aspect-ratio=(fraction)1/1
/GstPipeline:pipeline0/GstFFMpegCsp:ffmpegcsp0.GstPad:sink: caps = video/x-raw-yuv, width=(int)320, height=(int)240, format=(fourcc)I420, framerate=(fraction)0/1
/GstPipeline:pipeline0/GstXImageSink:ximagesink0.GstPad:sink: caps = video/x-raw-rgb, bpp=(int)16, depth=(int)16, endianness=(int)1234, red_mask=(int)63488, green_mask=(int)2016, blue_mask=(int)31, width=(int)320, height=(int)240, framerate=(fraction)0/1, pixel-aspect-ratio=(fraction)1/1
`<bad>`
We need show video more then 320x240 resolution
1024x768
`<very bad>`
It is Intel Atom 1.6GHz on the receiver side.
Gigabit ethernet maximum load is 6Mb/sec
Maximum CPU load is 30%.
gstrtpjitterbuffer dont save us too.
mailto: kwispost@gmail.com
**Attachment 211668**, "good":
![good](/uploads/edbb70980ebf02d7694c583073365ac4/good.png)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/62matroskademux, avidemux: implement accurate keyframe snapping seeks2021-09-24T13:30:04ZBugzilla Migration Usermatroskademux, avidemux: implement accurate keyframe snapping seeks## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#676630)](https://bugzilla.gnome.org/show_bug.cgi?id=676630)**
## Description
When the ACURATE flag is set for snapping keyframe seeks, we seek to the
previous...## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#676630)](https://bugzilla.gnome.org/show_bug.cgi?id=676630)**
## Description
When the ACURATE flag is set for snapping keyframe seeks, we seek to the
previous known keyframe and scan forward till the required keyframe is
found. For backward snapping, this will require an extra seek.
Note that this will be unneeded if all keyframes are indexed. I have no
idea whether Matroska requires this or not.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/63[2.0] qtdemux/qtmux: merge image/x-j2c and image/x-jpc and drop non-standard ...2021-09-24T13:30:04ZBugzilla Migration User[2.0] qtdemux/qtmux: merge image/x-j2c and image/x-jpc and drop non-standard boxing in the jpeg2000 elements## Submitted by Tim Müller `@tpm`
**[Link to original bug (#677754)](https://bugzilla.gnome.org/show_bug.cgi?id=677754)**
## Description
From commit message:
From 426b2db2cba849ab4f64a6ba91047380ff338837 Mon Sep 17 00:00:00 200...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#677754)](https://bugzilla.gnome.org/show_bug.cgi?id=677754)**
## Description
From commit message:
From 426b2db2cba849ab4f64a6ba91047380ff338837 Mon Sep 17 00:00:00 2001
From: Sebastian Dröge <slomo@circular-chaos.org>
Date: Mon, 01 Dec 2008 15:48:13 +0000
Subject: ext/jp2k/: Add image/x-jpc caps name for real, raw JPEG2000 codestream data.
Original commit message from CVS:
* ext/jp2k/gstjasperdec.c: (gst_jasper_dec_sink_setcaps):
* ext/jp2k/gstjasperenc.c: (gst_jasper_enc_reset),
(gst_jasper_enc_set_src_caps), (gst_jasper_enc_init_encoder),
(gst_jasper_enc_sink_setcaps), (gst_jasper_enc_get_data):
* ext/jp2k/gstjasperenc.h:
Add image/x-jpc caps name for real, raw JPEG2000 codestream data.
In 0.11 we should merge image/x-j2c and image/x-jpc and simply drop
the non-standard boxing in the jasper elements and handle it in
qtmux/qtdemux.
image/x-jpc will be used by mxfdemux later.
Also add support for JP2 output in jp2kenc.2.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/64apedemux: APE tags should be preffered over ID3v12021-09-24T13:30:05ZBugzilla Migration Userapedemux: APE tags should be preffered over ID3v1## Submitted by k.p..@..il.com
**[Link to original bug (#677919)](https://bugzilla.gnome.org/show_bug.cgi?id=677919)**
## Description
If for example an MP3 file includes both APE tags and ID3v1 tags at the end of the file, typefind ...## Submitted by k.p..@..il.com
**[Link to original bug (#677919)](https://bugzilla.gnome.org/show_bug.cgi?id=677919)**
## Description
If for example an MP3 file includes both APE tags and ID3v1 tags at the end of the file, typefind first finds the ID3v1 tag at the end and after id3demux having parsed that the APE tag that comes before the ID3v1 tag is found and read.
Now with ID3v1 being a very limited format and not having a clear definition of the character set used, reading non-ASCII titles (especially Shift-JIS or GB18030) from ID3v1 mostly results in garbled characters. As it is parsed before the APE tag, media players etc. will usually display the not very useful ID3v1 title. I would therefore propose that in case of ID3v1 and APE tag both being present, the APE tag should be preffered.