GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-04-22T07:06:28Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1160rtpbin/rtpjitterbuffer: Offsets timestamps based on RTCP in RFC7273 mode2022-04-22T07:06:28ZSebastian Drögertpbin/rtpjitterbuffer: Offsets timestamps based on RTCP in RFC7273 modeIn RFC7273 mode once the jitterbuffer is synced (media clock and offset), the timestamps are already mapping directly to the signalled clock's timestamps (adjusted to the pipeline clock).
The offsetting based on RTCP for either `ntp-syn...In RFC7273 mode once the jitterbuffer is synced (media clock and offset), the timestamps are already mapping directly to the signalled clock's timestamps (adjusted to the pipeline clock).
The offsetting based on RTCP for either `ntp-sync` or inter-stream sync will break synchronization afterwards.
----
The question is now how to handle this situation best:
1. adjust everything in the jitterbuffer to only apply the offset if *currently* there is no RFC7273 sync happening?
2. never offset timestamps if `rfc7273-sync=true`, even if the caps do not contain the required information or the clock is not synced yet
3. never offset timestamps if `rfc7273-sync=true`, even if the clock is not synced yet (but caps are containing all required information)
I think 1. would be the correct solution, but this also kind of ties in with the question whether packets should be forwarded at all before RFC7273 sync is actually happening.
CC @tpmhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1156[2.0] gst-video: turn GstVideoCodecFrame to a GstMiniObject2022-11-10T09:21:13ZGuillaume Desmottes[2.0] gst-video: turn GstVideoCodecFrame to a GstMiniObject`GstVideoCodecFrame` is currently a simple refcounted `struct`. I think it would be nice to turn it to a `GstMiniObject`at the next ABI break so it could be tracked by the leaks tracker.
(Should we have a specific "API/ABI break" label ...`GstVideoCodecFrame` is currently a simple refcounted `struct`. I think it would be nice to turn it to a `GstMiniObject`at the next ABI break so it could be tracked by the leaks tracker.
(Should we have a specific "API/ABI break" label for such tickets?)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1153AccessViolationException (gst-sharp)2022-11-10T09:21:12ZJake HedlundAccessViolationException (gst-sharp)### Describe your issue
After some time, a WinForms/Gstreamer application crashes with an AccessViolationException. Furthermore, there are many failed unref asserts from both GStreamer and GLib.
For example: `The program '[22176] Winfo...### Describe your issue
After some time, a WinForms/Gstreamer application crashes with an AccessViolationException. Furthermore, there are many failed unref asserts from both GStreamer and GLib.
For example: `The program '[22176] WinformSample.exe' has exited with code -1073740940 (0xc0000374).`
Earlier: (x100+) `(WinformSample.exe:22216): GStreamer-CRITICAL **: 12:34:56.880: gst_mini_object_unref: assertion 'GST_MINI_OBJECT_REFCOUNT_VALUE (mini_object) > 0' failed`
(x1000+) `(Gst1.18Test.exe:3392): GLib-CRITICAL **: 12:24:46.550: Source ID 155 was not found when attempting to remove it`
#### Expected Behavior
No crashing, no unref errors.
#### Observed Behavior
Many "Critical" log statements/errors - they do not always crash the app.
When a crash occurs -
```
Exception thrown: 'System.AccessViolationException' in gstreamer-sharp.dll
An unhandled exception of type 'System.AccessViolationException' occurred in gstreamer-sharp.dll
Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
```
#### Setup
- **Operating System:** Windows 10
- **Software:** .NET Framework 4.8, GstSharp 1.18, GStreamer MSVC 1.20.1
- **Device:** Computer/Laptop
- **GStreamer Version:** 1.20.1
- **Command line:** [NR in command line launch line]
### Steps to reproduce the bug
1. Download, compile, and run (in the debugger) the Gst-sharp samples (VideoOverlay form in WinformSample project) from: https://github.com/ttustonic/GStreamerSharpSamples
2. Choose an example .mp4 file.
3. Video plays.
4. Observe debug log and crash.
Seems to do with the disposal (or lack-thereof) of mini-objects.
### How reproducible is the bug?
Almost always, variable length of time. Always on closing of window.
### Solutions you have tried
Reinstalling gst-sharp, reinstalling gstreamer 1.20, reinstalling .net framework.
### Additional Information
Seems to be related to handling the messages on the Bus (`pipeline.Bus.Message += HandleMessage;`). Without a handler attached, the unref errors seem to go away.
This issue has only been observed using GstSharp v1.18 or above with MSVC builds of GStreamer. v1.16.3 works without these errors.
Also observed with other pipelines not using `playbin`, e.g.
* `videotestsrc ! video/x-raw,width=1280,height=720 ! queue ! autovideosink`
* `ksvideosrc ! queue ! videoconvert ! autovideosink`
However, these must be run from inside a WinForms program for the problem to be seen.
<details><summary>Log snippet</summary>
...
(Gst1.18Test.exe:11144): GLib-CRITICAL **: 12:52:30.463: Source ID 240 was not found when attempting to remove it
(Gst1.18Test.exe:11144): GLib-CRITICAL **: 12:52:30.463: Source ID 239 was not found when attempting to remove it
(Gst1.18Test.exe:11144): GStreamer-CRITICAL **: 12:52:30.463: gst_mini_object_unref: assertion 'GST_MINI_OBJECT_REFCOUNT_VALUE (mini_object) > 0' failed
(Gst1.18Test.exe:11144): GLib-CRITICAL **: 12:52:30.464: Source ID 242 was not found when attempting to remove it
(Gst1.18Test.exe:11144): GStreamer-CRITICAL **: 12:52:30.464: gst_mini_object_unref: assertion 'GST_MINI_OBJECT_REFCOUNT_VALUE (mini_object) > 0' failed
(Gst1.18Test.exe:11144): GLib-CRITICAL **: 12:52:30.464: Source ID 241 was not found when attempting to remove it
(Gst1.18Test.exe:11144): GStreamer-CRITICAL **: 12:52:30.464: gst_mini_object_unref: assertion 'GST_MINI_OBJECT_REFCOUNT_VALUE (mini_object) > 0' failed
(Gst1.18Test.exe:11144): GLib-CRITICAL **: 12:52:30.464: Source ID 244 was not found when attempting to remove it
...
(Gst1.18Test.exe:11144): GLib-CRITICAL **: 12:53:29.018: Source ID 590 was not found when attempting to remove it
(Gst1.18Test.exe:11144): GLib-CRITICAL **: 12:53:29.018: Source ID 589 was not found when attempting to remove it
(Gst1.18Test.exe:11144): GLib-CRITICAL **: 12:53:29.018: Source ID 588 was not found when attempting to remove it
(Gst1.18Test.exe:11144): GLib-CRITICAL **: 12:53:29.018: Source ID 587 was not found when attempting to remove it
(Gst1.18Test.exe:11144): GLib-CRITICAL **: 12:53:29.019: Source ID 586 was not found when attempting to remove it
(Gst1.18Test.exe:11144): GLib-CRITICAL **: 12:53:29.019: Source ID 585 was not found when attempting to remove it
...
</details>https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/110avenc_g726le: Format not mapped to caps2022-04-18T02:25:02ZDũng Hoàngavenc_g726le: Format not mapped to capsHi team, I have problem when using g 726 codec with little endian format. My pipeline can't work.
htdung@CaCs:~$ **gst-launch-1.0 audiotestsrc ! audio/x-raw,rate=8000 ! audioconvert ! avenc_g726le ! avdec_g726le ! wavenc ! > filesink lo...Hi team, I have problem when using g 726 codec with little endian format. My pipeline can't work.
htdung@CaCs:~$ **gst-launch-1.0 audiotestsrc ! audio/x-raw,rate=8000 ! audioconvert ! avenc_g726le ! avdec_g726le ! wavenc ! > filesink location=xxx.wav**
> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> ERROR: from element /GstPipeline:pipeline0/avenc_g726le:avenc_g726le0: GStreamer error: negotiation problem.
> Additional debug info:
> gstaudioencoder.c(1369): gst_audio_encoder_chain (): /GstPipeline:pipeline0/avenc_g726le:avenc_g726le0:
> encoder not initialized
> ERROR: pipeline doesn't want to preroll.
> Setting pipeline to NULL ...
> Freeing pipeline ...
I tried with big endian with same pipeline, and it is ok.
htdung@CaCs:~$ **gst-launch-1.0 audiotestsrc ! audio/x-raw,rate=8000,channels=1 ! audioconvert ! avenc_g726 ! avdec_g726 ! wavenc ! filesink location=xxx.wav**
> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> Pipeline is PREROLLED ...
> Setting pipeline to PLAYING ...
> New clock: GstSystemClock
> ^Chandling interrupt.
> Interrupt: Stopping pipeline ...
> Execution ended after 0:00:00.410484569
> Setting pipeline to PAUSED ...
> Setting pipeline to READY ...
> Setting pipeline to NULL ...
> Freeing pipeline ...
Thanks, version of my gstreamer is 1.16https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1147Missing EOS with qtdemux2022-04-13T05:35:06ZSanchayan Maitysanchayan@sanchayanmaity.netMissing EOS with qtdemux### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstream...### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstreamer.freedesktop.org/lists/ -->
A pipeline `qtdemux -> queue -> mp4mux` can get stuck in scenarios where the audio video track lengths are not equal. (Not sure what a good title would be here)
#### Expected Behavior
<!-- What did you expect to happen -->
Pipeline should not stall irrespective of the input stream
#### Observed Behavior
<!-- What actually happened -->
Pipeline stalls depending on input stream
#### Setup
- **Operating System:** Arch Linux
- **Device:** Computer<!-- Delete as appropriate !-->
- **GStreamer Version:** 1.20.1
- **Command line:** `gst-inspect-1.0 --version`
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
Generate a test video with
```bash
gst-launch-1.0 -e -v mp4mux name=m ! filesink location=video-qtdemux.mp4 sync=true \
videotestsrc ! video/x-raw,width=1920,height=1080,framerate=20/1 ! queue ! videorate ! x264enc bframes=0 ! video/x-h264,framerate=20/1 ! h264parse ! m.video_0 \
audiotestsrc ! queue ! fdkaacenc ! audio/mpeg,rate=48000,channels=2,stream-format=raw ! aacparse ! m.audio_0
```
Now run the below pipeline. The below pipeline hangs unless `max-size-time=0` is set on the `video_queue`.
```
GST_DEBUG=3 gst-launch-1.0 -e \
filesrc location=video-qtdemux.mp4 ! qtdemux name=d \
mp4mux name=m ! filesink location=video-qtdemux-fixed.mp4 \
d.video_0 ! queue name=video_queue ! h264parse ! m.video_0 \
d.audio_0 ! queue name=audio_queue ! aacparse ! m.audio_0
```
Testing with latest `main` and attaching with GDB shows
- The `mux` source thread stuck in `gst_aggregator_wait_and_check:841`
- `qtdemux` stuck in `gst_qtdemux_loop:6682` having pushed through and stuck in `gst_queue_chain_buffer_or_list:1251`
- Audio queue is stuck in `gst_queue_loop` and is empty
- Video queue stuck with back trace `gst_queue_loop:1541 (...) gst_aggregator_pad_chain_internal:3072`. It is not empty and has the stats
```
cur_level = {
buffers = 20,
bytes = 257902,
time = 1000000000
},
max_size = {
buffers = 200,
bytes = 10485760,
time = 1000000000
},
```
and being considered full due to time.
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
Consistent.
### Screenshots if relevant
Excerpt from the log where it stalls
```
0:00:01.982514010 114822 0x55d8b6164580 LOG qtdemux qtdemux.c:5197:gst_qtdemux_prepare_current_sample:<d> segment active, index = 4259 of 4292
0:00:01.982516856 114822 0x55d8b6164580 LOG qtdemux qtdemux.c:9634:qtdemux_parse_samples:<d> parsing samples for stream fourcc avc1, pad video_0
0:00:01.982519120 114822 0x55d8b6164580 LOG qtdemux qtdemux.c:10029:qtdemux_parse_samples:<d> Tried to parse up to sample 4259 but this sample has already been parsed
0:00:01.982526323 114822 0x55d8b6164580 DEBUG qtdemux qtdemux.c:6469:gst_qtdemux_loop_state_movie:<d> pushing from track-id 1, empty 0 offset 63038656, size 12436, dts=0:03:32.950000000, pts=0:03:32.950000000, duration 0:00:00.050000000
0:00:01.982528848 114822 0x55d8b6164580 LOG qtdemux qtdemux.c:6573:gst_qtdemux_loop_state_movie:<d> reading 12436 bytes @ 63038656
0:00:01.982542785 114822 0x55d8b6164580 LOG qtdemux qtdemux.c:5377:gst_qtdemux_sync_streams:<d> current position: 0:03:32.950000000, stream end: 0:03:31.797500000, demux seg pos: 0:03:32.950000000
0:00:01.982547293 114822 0x55d8b6164580 LOG qtdemux qtdemux.c:5869:gst_qtdemux_push_buffer:<d> Pushing buffer with dts 0:03:32.950000000, pts 0:03:32.950000000, duration 0:00:00.050000000 on pad video_0
0:00:01.982551521 114822 0x55d8b6164580 LOG queue_dataflow gstqueue.c:1204:gst_queue_chain_buffer_or_list:<video_queue> received buffer 0x7fb57804eb40 of size 12436, time 0:03:32.950000000, duration 0:00:00.050000000
0:00:01.982554968 114822 0x55d8b6164580 DEBUG queue_dataflow gstqueue.c:1245:gst_queue_chain_buffer_or_list:<video_queue> queue is full, waiting for free space
0:00:01.982559917 114822 0x55d8b6164580 LOG queue_dataflow gstqueue.c:1251:gst_queue_chain_buffer_or_list:<video_queue> (video_queue:sink) wait for DEL: 20 of 0-200 buffers, 257902 of 0-10485760 bytes, 1000000000 of 0-1000000000 ns, 20 items
```
In the case when `max-size-time=0` is used on the video queue, the EOS can be seen for the audio stream. Note the difference in active segment index here and above.
```
0:00:02.080051516 114985 0x55fece49b180 LOG qtdemux qtdemux.c:5197:gst_qtdemux_prepare_current_sample:<d> segment active, index = 4276 of 4292
0:00:02.080053419 114985 0x55fece49b180 LOG qtdemux qtdemux.c:9634:qtdemux_parse_samples:<d> parsing samples for stream fourcc avc1, pad video_0
0:00:02.080054862 114985 0x55fece49b180 LOG qtdemux qtdemux.c:10029:qtdemux_parse_samples:<d> Tried to parse up to sample 4276 but this sample has already been parsed
0:00:02.080058639 114985 0x55fece49b180 DEBUG qtdemux qtdemux.c:6469:gst_qtdemux_loop_state_movie:<d> pushing from track-id 1, empty 0 offset 63260745, size 12412, dts=0:03:33.800000000, pts=0:03:33.800000000, duration 0:00:00.050000000
0:00:02.080060282 114985 0x55fece49b180 LOG qtdemux qtdemux.c:6573:gst_qtdemux_loop_state_movie:<d> reading 12412 bytes @ 63260745
0:00:02.080070982 114985 0x55fece49b180 LOG qtdemux qtdemux.c:5377:gst_qtdemux_sync_streams:<d> current position: 0:03:33.800000000, stream end: 0:03:31.797500000, demux seg pos: 0:03:33.800000000
0:00:02.080072936 114985 0x55fece49b180 DEBUG qtdemux qtdemux.c:5385:gst_qtdemux_sync_streams:<d> sending EOS for stream audio_0
```
### Solutions you have tried
Setting `max-size-time=0` fixes it. Is it recommended having `max-size-*` property disabled for cases like this?
### Related non-duplicate issues
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->
It seems due to the below condition
```
if (GST_CLOCK_TIME_IS_VALID (end_time)
&& (end_time + 2 * GST_SECOND < demux->segment.position)) {
```
there is a window of time before the EOS is sent out for the audio stream in the test case above, but by then the downstream `queue` has already stalled. **EDIT**: Checking with `git blame` this seems to have been introduced with https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/3360f449c0bc70c91a82b5dd48da4546a1ae0192 and describes the exact issue we are running into here. Changing the above condition to use a gap of 1 second, also makes the test pipeline work.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1145gst-full: Generate normal .pc files pointing to libgstreamer-full.so2022-11-10T09:21:12ZSebastian Drögegst-full: Generate normal .pc files pointing to libgstreamer-full.soThis would allow existing applications to work and especially allow the whole thing to work from bindings.
@thiblahute said he's working on basically the same thing for the .gir files and it could be solved the same way.
CC @dabrain34This would allow existing applications to work and especially allow the whole thing to work from bindings.
@thiblahute said he's working on basically the same thing for the .gir files and it could be solved the same way.
CC @dabrain34https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1144meson: Tracking issue for enabling --fatal-meson-warnings2022-11-10T09:21:12ZNirbheek Chauhannirbheek.chauhan@gmail.commeson: Tracking issue for enabling --fatal-meson-warningsRequires a version bump to 0.54.
* [ ] all modules: `|WARNING: Project targeting '>= 0.48' but tried to use feature introduced in '0.54.0': native arg in add_languages`: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_request...Requires a version bump to 0.54.
* [ ] all modules: `|WARNING: Project targeting '>= 0.48' but tried to use feature introduced in '0.54.0': native arg in add_languages`: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/550, https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/729, https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/655, https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1391, https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/merge_requests/58
* [ ] `subprojects/gst-plugins-base/tests/validate/meson.build:4: WARNING: Trying to compare values of different types (ExecutableHolder, bool) using ==.` https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/729
* [ ] gst-plugins-base and gst-plugins-good `|WARNING: rcc dependencies will not work reliably until this upstream issue is fixed: https://bugreports.qt.io/browse/QTBUG-45460`: https://github.com/mesonbuild/meson/pull/7398
* [ ] `|subprojects/gst-plugins-base/pkgconfig/meson.build:57: WARNING: The variable(s) 'GL_CFLAGS' in the input file 'subprojects/gst-plugins-base/pkgconfig/gstreamer-gl.pc.in' are not present in the given configuration data.`: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1
* [ ] `|subprojects/gst-plugins-bad/gst-libs/gst/vulkan/meson.build:249: WARNING: No Windowing system found. vulkansink will not work` https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1391
* [ ] `||subprojects/openh264/test/meson.build:2: WARNING: Dependency gtest not found but it is available in a sub-subproject.`
- This is behind the `tests` option and it yields upwards, and passing `-Dopenh264:tests=disabled` has no effect (which is a meson bug)
* [ ] `|subprojects/gst-plugins-bad/pkgconfig/meson.build:59: WARNING: The variable(s) 'waylandlibdir' in the input file 'subprojects/gst-plugins-bad/pkgconfig/gstreamer-plugins-bad-uninstalled.pc.in' are not present in the given configuration data.`: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/merge_requests/1
* [ ] openh264 `||WARNING: Project targeting '>= 0.49.0' but tried to use feature introduced in '0.50.0': install arg in configure_file`: https://github.com/cisco/openh264/pull/3301
* [x] ffmpeg `WARNING: Project targeting '>= 0.49.0' but tried to use feature introduced in '0.50.0': install arg in configure_file`: https://gitlab.freedesktop.org/gstreamer/meson-ports/ffmpeg/-/commit/2a27f04b2d485c482b06f1fe82467d9e4d9d2a89 (can't go into `meson-4.1.5` branch)
* [ ] orc: https://gitlab.freedesktop.org/gstreamer/orc/-/merge_requests/43https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1143msdkh264enc: failed to get surface available, failed to create new MSDK memory2022-04-09T16:19:59Zvandanamsdkh264enc: failed to get surface available, failed to create new MSDK memoryI get the below error:
default gstmsdkvideomemory.c:77:gst_msdk_video_allocator_get_surface: failed to get surface available
0:00:00.191339172 27797 0x7fb9a8036770 ERROR msdkbufferpool gstmsdkbufferpool.c:270:gst_msdk_buffer_pool...I get the below error:
default gstmsdkvideomemory.c:77:gst_msdk_video_allocator_get_surface: failed to get surface available
0:00:00.191339172 27797 0x7fb9a8036770 ERROR msdkbufferpool gstmsdkbufferpool.c:270:gst_msdk_buffer_pool_alloc_buffer:<msdkbufferpool3> failed to create new MSDK memory
My Pipeline:
gst-launch-1.0 filesrc location=/home/radiant/.nvm/versions/node/v10.6.0/lib/node_modules/pm2/lib/public/uploads/drrahat.mp4 ! decodebin name=demux demux. ! queue ! audioresample ! audioconvert ! avenc_aac bitrate=192000 ! mux. mpegtsmux bitrate=5000000 alignment=7 name=mux ! filesink location=/home/radiant/.nvm/versions/node/v10.6.0/lib/node_modules/pm2/lib/public/converted/drrahat_resync.ts demux. ! queue ! msdkh264enc ! video/x-h264,stream-format=byte-stream,profile=high ! h264parse ! mux.
Pls suggest what could be wrong?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1142mp4mux drops frames on higher fragment duration for fMP42023-01-25T13:43:32ZSanchayan Maitysanchayan@sanchayanmaity.netmp4mux drops frames on higher fragment duration for fMP4### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstream...### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstreamer.freedesktop.org/lists/ -->
We currently run a pipeline in production which looks like `encoder -> mp4mux -> s3`. Trying to use fragment duration values higher than 1 second gives us videos which have glitchy playback with `gst-play` and are not playable in VLC or `ffplay` at all.
`mp4mux` seems to be dropping frames for higher values of fragment duration.
#### Expected Behavior
<!-- What did you expect to happen -->
Frames should not be dropped for higher values of fragment duration.
#### Observed Behavior
<!-- What actually happened -->
Frames get dropped for higher values of fragment duration.
#### Setup
- **Operating System:** Arch Linux
- **Device:** Computer <!-- Delete as appropriate !-->
- **GStreamer Version:** 1.20.1
- **Command line:** `gst-inspect-1.0 --version`
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
```bash
#!/bin/bash
# Delete all mp4 files and logs first
rm *.log
rm *.mp4
# Generate test fMP4 video with fragment duration of 20ms and 2s
GST_DEBUG=6 gst-launch-1.0 -e -vvv videotestsrc num-buffers=8192 pattern=ball ! video/x-raw,format=I420,framerate=50/1 ! videorate ! x264enc bframes=0 ! identity name=after-x264 silent=false ! mp4mux fragment-duration=20 ! identity name=after-mp4mux silent=false ! filesink location=video-frag-duration-20ms.mp4 2>&1 | tee identity-20ms.log
GST_DEBUG=6 gst-launch-1.0 -e -vvv videotestsrc num-buffers=8192 pattern=ball ! video/x-raw,format=I420,framerate=50/1 ! videorate ! x264enc bframes=0 ! identity name=after-x264 silent=false ! mp4mux fragment-duration=2000 ! identity name=after-mp4mux silent=false ! filesink location=video-frag-duration-2s.mp4 2>&1 | tee identity-2s.log
GST_PLUGIN_PATH=/usr/local/lib GST_DEBUG=6 gst-launch-1.0 videotestsrc num-buffers=8192 pattern=ball ! video/x-raw,format=I420,framerate=50/1 ! videorate ! x264enc bframes=0 ! identity name=after-x264 silent=false ! isofmp4mux header-update-mode=update fragment-duration=2000 write-mehd=false write-mfra=false ! identity name=after-mp4mux silent=false ! filesink location=video-fmp4-2s.mp4 2>&1 | tee identity-fmp4-2s.log
# Get streams and all frames info using ffprobe
ffprobe -v error -show_format -show_streams -show_frames video-frag-duration-20ms.mp4 > video-frag-duration-20ms-ffprobe.log
ffprobe -v error -show_format -show_streams -show_frames video-frag-duration-2s.mp4 > video-frag-duration-2s-ffprobe.log
ffprobe -v error -show_format -show_streams -show_frames video-fmp4-2s.mp4 > video-fmp4-2s-ffprobe.log
# Get logs from qtdemux while transmuxing
GST_DEBUG=3,qtdemux*:6 gst-launch-1.0 -e filesrc location=video-frag-duration-20ms.mp4 ! qtdemux ! queue ! h264parse ! mp4mux ! filesink location=video-frag-duration-20ms-fixed.mp4 2>&1 | tee video-frag-duration-20ms-qtdemux.log
GST_DEBUG=3,qtdemux*:6 gst-launch-1.0 -e filesrc location=video-frag-duration-2s.mp4 ! qtdemux ! queue ! h264parse ! mp4mux ! filesink location=video-frag-duration-2s-fixed.mp4 2>&1 | tee video-frag-duration-2s-qtdemux.log
```
Above is a test script to generate two test videos with 20ms and 2s fragment duration and then get logs from `identity` and `ffprobe`.
Looking at logs from the identity elements before and after `mp4mux`, it can be seen that
- `x264enc` is generating the 8191 frames as expected
- `mp4mux` is dropping frames when fragment duration is 2 seconds
`ffprobe` output also validates the same. For the 20ms case, 8191 frames can be seen while for the 2s case, only 205 frames are seen.
The video for the 2s case has a glitchy or discontinuous playback when using `gst-play`. With VLC, the video plays for the initial few seconds and then VLC stops playing the video.
**EDIT:** `fmp4mux` does not seem to give any problems in comparison to `mp4mux` in this same setup.
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
Consistently reproducible.
### Screenshots if relevant
No screenshots, but attaching the `ffprobe` logs.
[video-frag-duration-2s-ffprobe.log](/uploads/45bf65c268f6d6a3bd569ccfa7b1dbec/video-frag-duration-2s-ffprobe.log)
[video-frag-duration-20ms-ffprobe.log](/uploads/d7f0127d200e668824529bc82c645b59/video-frag-duration-20ms-ffprobe.log)
### Solutions you have tried
Have not found a solution so far. Is something missing from the pipeline?
### Related non-duplicate issues
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1141GstVideoInfo chroma_site is wrong for YUV444 formats (e.g. Y444_LE)2022-06-18T21:34:07ZAdrien De ConinckGstVideoInfo chroma_site is wrong for YUV444 formats (e.g. Y444_LE)GstVideoInfo chroma_site information should be GST_VIDEO_CHROMA_SITE_JPEG for YUV444 formats (e.g.Y444_LE)
Due to [this condition](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-base/gst-libs/gst/...GstVideoInfo chroma_site information should be GST_VIDEO_CHROMA_SITE_JPEG for YUV444 formats (e.g.Y444_LE)
Due to [this condition](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-base/gst-libs/gst/video/video-info.c#L169), it is set to GST_VIDEO_CHROMA_SITE_MPEG2 whatever the YUV format.
```
static void
set_default_colorimetry (GstVideoInfo * info)
{
const GstVideoFormatInfo *finfo = info->finfo;
if (GST_VIDEO_FORMAT_INFO_IS_YUV (finfo)) {
if (info->height > 576) {
info->chroma_site = GST_VIDEO_CHROMA_SITE_H_COSITED;
info->colorimetry = default_color[DEFAULT_YUV_HD];
} else {
info->chroma_site = GST_VIDEO_CHROMA_SITE_NONE;
info->colorimetry = default_color[DEFAULT_YUV_SD];
}
} else if (GST_VIDEO_FORMAT_INFO_IS_GRAY (finfo)) {
info->colorimetry = default_color[DEFAULT_GRAY];
} else if (GST_VIDEO_FORMAT_INFO_IS_RGB (finfo)) {
info->colorimetry = default_color[DEFAULT_RGB];
} else {
info->colorimetry = default_color[DEFAULT_UNKNOWN];
}
}
```
Here is a gst-launch-1.0 command line to run to get the "error".
```
gst-launch-1.0.exe videotestsrc ! "video/x-raw, width=(int)1920, height=(int)1080, framerate=(fraction)60/1, format=Y444_16LE" ! autovideosink
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1136Custom build doesn't build gstreamer tools anymore2023-03-08T19:31:00ZSebastian Frickesebastian.fricke@collabora.comCustom build doesn't build gstreamer tools anymore### Describe your issue
On 1.20, the following build configuration worked without problems:
```
meson -Dauto_features=disabled -Dbad=enabled -Dbase=enabled -Dgood=enabled -Dgst-plugins-bad:debugutils=enabled -Dgst-plugins-bad:ivfparse=en...### Describe your issue
On 1.20, the following build configuration worked without problems:
```
meson -Dauto_features=disabled -Dbad=enabled -Dbase=enabled -Dgood=enabled -Dgst-plugins-bad:debugutils=enabled -Dgst-plugins-bad:ivfparse=enabled -Dgst-plugins-bad:v4l2codecs=enabled -Dgst-plugins-bad:vid
eoparsers=enabled -Dgst-plugins-base:app=enabled -Dgst-plugins-base:playback=enabled -Dgst-plugins-base:tools=enabled -Dgst-plugins-base:typefind=enabled -Dgst-plugins-base:videoconvert=enabled -Dgst-plugins
-good:matroska=enabled -Dgstreamer:tools=enabled -Dwrap_mode=nofallback -Dgst-plugins-good:v4l2=enabled -Dgst-plugins-base:videotestsrc=enabled -Dgst-plugins-base:rawparse=enabled build_test
```
What I need is bascially everything required for running a pipeline like this:
`gst-launch-1.0 filesrc location=resources/JCT-VC-HEVC_V1/SAODBLK_B_MainConcept_4/SAODBLK_B_MainConcept_4/SAODBLK_B_MainConcept_4.bin ! h265parse ! v4l2slh265dec ! video/x-raw ! videoconvert dither=none ! video/x-raw,format=I420 ! videocodectestsink location=results/JCT-VC-HEVC_V1/SAODBLK_B_MainConcept_4.out`
And for further debugging in case of errors.
With the latest GStreamer sources (HEAD == '7604c7b08888487c797002ad8c141793cb3f91c1')
This build doesn't work anymore. The gstreamer tools are not built.
#### Expected Behavior
Creation of the same set of tools and plugins as in 1.20 with the same build configuration.
#### Observed Behavior
The GStreamer tools are not built.
```
$ ninja -C build_test
ninja: Entering directory `build_test'
[576/576] Linking target subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so
$ ls build_test/subprojects/gstreamer/tools/
$
```
(here is the **meson build log**: https://paste.debian.net/1237071/)
But they are built when all GStreamer features are used, e.g: `rm -rf build_test && meson build_test && ninja -C build_test`
Results:
```
$ ls build_test/subprojects/gstreamer/tools/
gst-inspect-1.0 gst-inspect-1.0.p gst-launch-1.0 gst-launch-1.0.p gst-stats-1.0 gst-stats-1.0.p gst-typefind-1.0 gst-typefind-1.0.p
$
```
#### Setup
- **Operating System:** Linux apertis 5.17.0-rc1-rockpidebug2 #97 SMP PREEMPT Wed Apr 6 16:09:09 CEST 2022 aarch64 unknown unknown GNU/Linux
- **Device:** Computer
- **GStreamer Version:** GStreamer Core Library version 1.21.0.1
- **Command line:** `meson -Dauto_features=disabled -Dbad=enabled -Dbase=enabled -Dgood=enabled -Dgst-plugins-bad:debugutils=enabled -Dgst-plugins-bad:ivfparse=enabled -Dgst-plugins-bad:v4l2codecs=enabled -Dgst-plugins-bad:vid
eoparsers=enabled -Dgst-plugins-base:app=enabled -Dgst-plugins-base:playback=enabled -Dgst-plugins-base:tools=enabled -Dgst-plugins-base:typefind=enabled -Dgst-plugins-base:videoconvert=enabled -Dgst-plugins
-good:matroska=enabled -Dgstreamer:tools=enabled -Dwrap_mode=nofallback -Dgst-plugins-good:v4l2=enabled -Dgst-plugins-base:videotestsrc=enabled -Dgst-plugins-base:rawparse=enabled build_test && ninja -C build_test`
### How reproducible is the bug?
Always
### Solutions you have tried
I tried to build the tools in isolation, which doesn't work either.
(**full log**: https://paste.debian.net/1237072/)
### Additional question
Is there an easy way in GStreamer to figure out the minimal set of required build options to satisfy a specific command like:
`gst-launch-1.0 filesrc location=resources/JCT-VC-HEVC_V1/SAODBLK_B_MainConcept_4/SAODBLK_B_MainConcept_4/SAODBLK_B_MainConcept_4.bin ! h265parse ! v4l2slh265dec ! video/x-raw ! videoconvert dither=none ! video/x-raw,format=I420 ! videocodectestsink location=results/JCT-VC-HEVC_V1/SAODBLK_B_MainConcept_4.out` ?https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/99Gradle sync failed: NDK not configured error occurred at the time of syncing ...2022-04-06T05:11:31ZHemant ZarkarGradle sync failed: NDK not configured error occurred at the time of syncing Gradle of android-tutorial-4Hi, I am new in Gstreamer. I want to play video by using Gstreamer, so I have cloned your code and opened android-tutorial-4 in my Android Studio 4.1 in Windows 10. After that I am trying to sync Gradle, but it gives error given below,
...Hi, I am new in Gstreamer. I want to play video by using Gstreamer, so I have cloned your code and opened android-tutorial-4 in my Android Studio 4.1 in Windows 10. After that I am trying to sync Gradle, but it gives error given below,
`FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring project ':android-tutorial-1'.
> NDK not configured.
Download it with SDK manager.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 2s`
But I already have NDK downloaded at my NDK location.![ndk](/uploads/cae6150a71d1af6fb5891c1222cb90f7/ndk.PNG)
I also added NDK path in local.properties file. Please help me to solve this issue.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1135ImportError: cannot import name Gst, introspection typelib not found2022-04-05T04:35:03ZequalmanImportError: cannot import name Gst, introspection typelib not found![QQ图片20220405123200](/uploads/edc9966c0ea782d9ca6a27ed7752eb37/QQ图片20220405123200.png)![QQ图片20220405123200](/uploads/edc9966c0ea782d9ca6a27ed7752eb37/QQ图片20220405123200.png)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1131New elements for AVIF2022-04-02T22:52:01ZkriptonNew elements for AVIFAVIF is the image format derived from HEIF and AV1. I would expect avifenc and avifdec elements similar to the existing webpenc and webpdecAVIF is the image format derived from HEIF and AV1. I would expect avifenc and avifdec elements similar to the existing webpenc and webpdechttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1130gst_value_union fails union of two identical values.2022-04-26T11:21:09ZStirling Westrupgst_value_union fails union of two identical values.When you call gst_value_union with two identical primitive values (either equal values in two GValue variables, or the same GValue twice), it creates a list with two copies of the value, rather than just returning a copy of the primitive...When you call gst_value_union with two identical primitive values (either equal values in two GValue variables, or the same GValue twice), it creates a list with two copies of the value, rather than just returning a copy of the primitive value.
#### Expected Behavior
Showing the contents of the values, instead of the values, I would expect:
gst_value_union((int)14,(int)14) = (int)14
gst_value_union((string)"blue", (string)"blue") = (string)"blue"
#### Observed Behavior
what we actually get is:
gst_value_union((int)14,(int)14) = { (int)14, (int)14 }
gst_value_union((string)"blue", (string)"blue") = {(string)"blue"], (string)"blue"}
#### Setup
Linux (CentOS 8)
GStreamer 18.0 through 21.0
### Steps to reproduce the bug
int main
( int argc
, char * argv[]
)
{ GValue v1 = G_VALUE_INIT;
GValue v2 = G_VALUE_INIT;
GValue n = G_VALUE_INIT;
gst_init(&argc,&argv);
g_value_init(&v1, G_TYPE_INT);
g_value_init(&v2, G_TYPE_INT);
g_value_set_int(&v1, 15);
g_value_set_int(&v2, 15);
gst_value_union(&n, &v1, &v2);
gchar * ns = gst_value_serialize(&n);
gchar * v1s = gst_value_serialize(&v1);
gchar * v2s = gst_value_serialize(&v2);
gst_print("Union(\"%s\", \"%s\") = \"%s\"\n", v1s, v2s, ns);
return 0;
}
### How reproducible is the bug?
Always.
### Screenshots if relevant
### Solutions you have tried
### Related non-duplicate issues
### Additional Information
The problem seems to stem from using gst_value_list_concat as the default operation inside gst_value_union instead of gst_value_list_merge.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1125mpegtsmux, high overhead for a small aac bitrate2022-11-10T09:21:12ZBugzilla Migration Usermpegtsmux, high overhead for a small aac bitrate## Submitted by Vincent Génieux
**[Link to original bug (#766618)](https://bugzilla.gnome.org/show_bug.cgi?id=766618)**
## Description
I am facing an issue with the following pipeline :
audiotestsrc num-buffers=100000 ! audio/x...## Submitted by Vincent Génieux
**[Link to original bug (#766618)](https://bugzilla.gnome.org/show_bug.cgi?id=766618)**
## Description
I am facing an issue with the following pipeline :
audiotestsrc num-buffers=100000 ! audio/x-raw,channels=2 ! voaacenc
bitrate=32000 ! mpegtsmux ! filesink location=test.ts
The tsdemux generate a stream with a huge bitrate compared to other
containers, such as mp4mux :
audiotestsrc num-buffers=100000 ! audio/x-raw,channels=2 ! voaacenc
bitrate=32000 ! mp4mux ! filesink location=test.mp4
$ ls -lh test.*
-rw-r--r-- 1 vincent vincent 9.6M May 18 10:56 test.mp4
-rw-r--r-- 1 vincent vincent 26M May 18 10:57 test.ts
I think there is a misconfiguration somewhere which leads the demux to
create very small chunk with many headers. I also noticed we can reduce
the size of the ts file with libav :
$ avconv -i test.ts -codec copy test2.ts
$ ls -lh *.ts
-rw-r--r-- 1 vincent vincent 26M May 18 10:57 test.ts
-rw-r--r-- 1 vincent vincent 9.8M May 18 11:03 test2.ts
The problem is most likely that we don't combine multiple AAC packets
into a single PES packet, and thus have a lot of overhead for each of
them. ffmpeg does this for audio at least if I remember the muxer code
correctly.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1123Follow-up from "Make Android app possible without cerbero"2022-11-10T09:21:12ZXavier Claessensxclaesse@gmail.comFollow-up from "Make Android app possible without cerbero"The following discussions from !617 should be addressed:
- [ ] @ystreet started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/617#note_617971): (+6 comments)
> As you are moving this to GStream...The following discussions from !617 should be addressed:
- [ ] @ystreet started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/617#note_617971): (+6 comments)
> As you are moving this to GStreamer, you can move the default log handler into GStreamer itself instead of overriding it from the 'application'
- [ ] @xclaesse started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/617#note_622660): (+1 comment)
> Discussed with @ndufresne and he had a great idea of moving fonts/certs assets into GResource, directly on libgstreamer-1.0.so, that we can copy in native code from JNI_OnLoad(). That way we could remove GStreamer.java completely, the app will only be responsible to call `System.loadLibrary("gstreamer-full-1.0");` or `System.loadLibrary("gstreamer_android");`.
- [ ] @ystreet started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/617#note_623223): (+4 comments)
> I'm not sure I like this default handling of the debug level from java. Shouldn't the app have complete control over this?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1122jpegdec: decoding erro when trying to convert from RGB to BGRx2022-08-18T08:38:52ZHaihua Hujpegdec: decoding erro when trying to convert from RGB to BGRxReproduce pipeline:
**gst-launch-1.0 videotestsrc num-buffers=300 ! video/x-raw,format=RGB,width=1280,height=800,framerate=30/1 ! jpegenc ! jpegparse ! jpegdec ! videoconvert ! waylandsink sync=false**
```
Setting pipeline to PAUSED ....Reproduce pipeline:
**gst-launch-1.0 videotestsrc num-buffers=300 ! video/x-raw,format=RGB,width=1280,height=800,framerate=30/1 ! jpegenc ! jpegparse ! jpegdec ! videoconvert ! waylandsink sync=false**
```
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstJpegDec:jpegdec0: Failed to decode JPEG image
Additional debug info:
../ext/jpeg/gstjpegdec.c(1557): gst_jpeg_dec_handle_frame (): /GstPipeline:pipeline0/GstJpegDec:jpegdec0:
Decode error #20: Improper call to JPEG library in state 205
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
ERROR: from element /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: Internal data stream error.
Additional debug info:
../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0:
streaming stopped, reason error (-5)
ERROR: pipeline doesn't want to preroll.
Freeing pipeline ...
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1121jpegdec: decoding erro when trying to convert from I420 to BGRx2023-01-24T10:30:17ZGuillaume Desmottesjpegdec: decoding erro when trying to convert from I420 to BGRxI found another conversion issue with `jpegdec`. Like #916 `jpegdec` is trying to convert from I420 to BGRx but this one is not fixed by https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1687
cc @marex
```
GST_DEBUG="...I found another conversion issue with `jpegdec`. Like #916 `jpegdec` is trying to convert from I420 to BGRx but this one is not fixed by https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1687
cc @marex
```
GST_DEBUG="jpegdec:6,2" gst-launch-1.0 filesrc location=test.jpg ! jpegdec ! video/x-raw,format=BGRx ! imagefreeze ! videoconvert ! xvimagesink
(...)
0:00:00.030223393 214060 0x111e060 LOG jpegdec gstjpegdec.c:202:gst_jpeg_dec_init_source:<jpegdec0> init_source
0:00:00.030251889 214060 0x111e060 LOG jpegdec gstjpegdec.c:1154:gst_jpeg_dec_prepare_decode:<jpegdec0> num_components=3
0:00:00.030260867 214060 0x111e060 LOG jpegdec gstjpegdec.c:1155:gst_jpeg_dec_prepare_decode:<jpegdec0> jpeg_color_space=3
0:00:00.030268771 214060 0x111e060 LOG jpegdec gstjpegdec.c:1163:gst_jpeg_dec_prepare_decode:<jpegdec0> r_h = 2, r_v = 2
0:00:00.030275680 214060 0x111e060 LOG jpegdec gstjpegdec.c:1179:gst_jpeg_dec_prepare_decode:<jpegdec0> [0] h_samp_factor=2, v_samp_factor=2, cid=1
0:00:00.030282394 214060 0x111e060 LOG jpegdec gstjpegdec.c:1179:gst_jpeg_dec_prepare_decode:<jpegdec0> [1] h_samp_factor=1, v_samp_factor=1, cid=2
0:00:00.030287994 214060 0x111e060 LOG jpegdec gstjpegdec.c:1179:gst_jpeg_dec_prepare_decode:<jpegdec0> [2] h_samp_factor=1, v_samp_factor=1, cid=3
0:00:00.030473805 214060 0x111e060 DEBUG jpegdec gstjpegdec.c:1022:gst_jpeg_turbo_parse_ext_fmt_convert: Received caps from peer: video/x-raw, format=(string)BGRx, width=(int)[ 1, 16384 ], height=(int)[ 1, 16384 ], framerate=(fraction)[ 0/1, 2147483647/1 ]
0:00:00.030491062 214060 0x111e060 DEBUG jpegdec gstjpegdec.c:1058:gst_jpeg_turbo_parse_ext_fmt_convert:<jpegdec0> format_convert=1
0:00:00.030497639 214060 0x111e060 LOG jpegdec gstjpegdec.c:1203:gst_jpeg_dec_prepare_decode:<jpegdec0> starting decompress
0:00:00.030695189 214060 0x111e060 DEBUG jpegdec gstjpegdec.c:1022:gst_jpeg_turbo_parse_ext_fmt_convert: Received caps from peer: video/x-raw, format=(string)BGRx, width=(int)[ 1, 16384 ], height=(int)[ 1, 16384 ], framerate=(fraction)[ 0/1, 2147483647/1 ]
0:00:00.030707874 214060 0x111e060 DEBUG jpegdec gstjpegdec.c:1058:gst_jpeg_turbo_parse_ext_fmt_convert:<jpegdec0> format_convert=1
0:00:00.031294755 214060 0x111e060 DEBUG jpegdec gstjpegdec.c:1138:gst_jpeg_dec_negotiate:<jpegdec0> max_v_samp_factor=2
0:00:00.031308433 214060 0x111e060 DEBUG jpegdec gstjpegdec.c:1139:gst_jpeg_dec_negotiate:<jpegdec0> max_h_samp_factor=2
0:00:00.031349077 214060 0x111e060 LOG jpegdec gstjpegdec.c:1436:gst_jpeg_dec_handle_frame:<jpegdec0> width 1049, height 590, fields 1
0:00:00.031355799 214060 0x111e060 LOG jpegdec gstjpegdec.c:1292:gst_jpeg_dec_decode:<jpegdec0> decompressing (required scanline buffer height = 2)
0:00:00.031361128 214060 0x111e060 DEBUG jpegdec gstjpegdec.c:789:gst_jpeg_dec_decode_indirect:<jpegdec0> unadvantageous width or r_h, taking slow route involving memcpy
0:00:00.031391721 214060 0x111e060 LOG jpegdec gstjpegdec.c:666:gst_jpeg_dec_ensure_buffers:<jpegdec0> allocated temp memory, 1056 bytes/row
0:00:00.031461087 214060 0x111e060 WARN videodecoder gstvideodecoder.c:4797:_gst_video_decoder_error:<jpegdec0> error: Failed to decode JPEG image
0:00:00.031466820 214060 0x111e060 WARN videodecoder gstvideodecoder.c:4799:_gst_video_decoder_error:<jpegdec0> error: Decode error #20: Improper call to JPEG library in state 205
0:00:00.031524574 214060 0x111e060 WARN videodecoder gstvideodecoder.c:1416:gst_video_decoder_sink_event_default:<jpegdec0> error: No valid frames decoded before end of stream
0:00:00.031532316 214060 0x111e060 WARN videodecoder gstvideodecoder.c:1416:gst_video_decoder_sink_event_default:<jpegdec0> error: no valid frames found
```
Here is the test image.
![test](/uploads/5b7d64efc77b75a415aaccbefaac7c18/test.jpg)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1119macos: gst-inspect is very slow for the first time2022-11-10T19:39:19ZStéphane Cerveauscerveau@igalia.commacos: gst-inspect is very slow for the first time### Describe your issue
In the devenv, after a build, gst-inspect-1.0 is very slow (about 30 seconds) on a M1 with SSD.
#### Expected Behavior
To be as fast as a desktop linux such as i7/SSD
#### Observed Behavior
it spents a lot of ti...### Describe your issue
In the devenv, after a build, gst-inspect-1.0 is very slow (about 30 seconds) on a M1 with SSD.
#### Expected Behavior
To be as fast as a desktop linux such as i7/SSD
#### Observed Behavior
it spents a lot of time scanning
#### Setup
- **Operating System:** MacOs Monterey
- **Device:** Computer
- **GStreamer Version:** 1.21
- **Command line:** gst-inspect-1.0
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. make a clean build
2. gst-inspect-1.0
### How reproducible is the bug?
Difficult to tell but the gap is big between a macbook and a linux laptop
### Screenshots if relevant
### Solutions you have tried
### Related non-duplicate issues
### Additional Information
Removing the registry.dat does not help to reproduce the bug always