gst-plugins-good issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues2021-06-02T18:24:34Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/889rtpjpegpay: Passing JPEG images through 'rtpjpegpay' and 'rtpjpegdepay' resul...2021-06-02T18:24:34ZAbleBaconrtpjpegpay: Passing JPEG images through 'rtpjpegpay' and 'rtpjpegdepay' results in corrupt output on Windows# Details
On Windows, version 1.18.4:
This pipeline (on both Windows and Linux) results in a corrupted output:
```filesrc location=C:/test_in.jpeg ! jpegparse ! rtpjpegpay ! rtpjpegdepay ! filesink location=C:/test_out.jpeg```
This p...# Details
On Windows, version 1.18.4:
This pipeline (on both Windows and Linux) results in a corrupted output:
```filesrc location=C:/test_in.jpeg ! jpegparse ! rtpjpegpay ! rtpjpegdepay ! filesink location=C:/test_out.jpeg```
This pipeline (possibly only on Windows) also results in a corrupted output:
```videotestsrc ! jpegenc ! rtpjpegpay ! rtpjpegdepay ! jpegdec ! autovideosink```
In either of the above pipelines, it's easy to confirm that the payloader and/or depayloader are responsible for this by simply removing them from the pipeline. I am confident that it is the payloader and/or depayloader that are at fault based on several hours of trying different combinations of encoders, decoders, and other methods of sending and receiving JPEG data, also using different pixel formats.
| Result Without Payloader and Depayloader | Result with Payloader and Depayloader |
| ------ | ------ |
| ![capture2_test_pay2](/uploads/3df2dc21b278cc81e4d5db0ee581e3e8/capture2_test_pay2.jpeg) | ![capture2_test_pay](/uploads/9f1bbd667361d0da33b1ca3c623f04cf/capture2_test_pay.jpeg)|
You can see that the result with the payloader and depayloader (the "corrupted" image):
1. has the wrong colors (too bright),
2. is shifted over to the left (and wraps back around on the right), and
3. has a small corrupted rectangle in the bottom right corner.
Certain images may only exhibit the first problem.
# Research
I haven't been able to determine what specifically might be causing this, but I have made three important observations about the image that results from passing through the payloader and depayloader:
1. Any `APP0` headers from the original image (the "uncorrupted" image) will be missing.
2. Each color component has an ID 1 less than those of the uncorrupted image (0, 1, 2 instead of 1, 2, 3).
3. Two consecutive bytes are missing from the `SOS` section (this can occur in different places depending on the image)
It seems that fixing the third issue on any given image (adding back in the two missing consecutive bytes) is enough to fix the result image so that it is identical to the uncorrupted image.
I made these observations:
- using `xxd` via my MinGW terminal to convert JPEG images into hexadecimal (and back),
- comparing hexadecimal dumps of images using a diff tool,
- examining RTP packets prepared by the payloading using Wireshark, and
- comparing JPEG header contents using the tool at https://cyber.meme.tips/jpdump/https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/739speexdec: Crash when stopping the pipeline2020-05-29T12:26:26ZPascal Carrierspeexdec: Crash when stopping the pipelineGStreamer version: 1.16.2.
Operating system: Windows 10 x64 (desktop).
**Reproduce:** run the following command:
`gst-launch-1.0.exe -v filesrc location=sample1.spx ! oggdemux ! speexdec ! audioconvert ! audioresample ! autoaudiosink`...GStreamer version: 1.16.2.
Operating system: Windows 10 x64 (desktop).
**Reproduce:** run the following command:
`gst-launch-1.0.exe -v filesrc location=sample1.spx ! oggdemux ! speexdec ! audioconvert ! audioresample ! autoaudiosink`
**Expected:** When I press CTRL+C to stop the pipeline, it does not crash.
**Actual:** When I press CTRL+C to stop the pipeline, it crash. I've tried setting gst-debug=4 but I've not found any error or warning that could cause the problem.`.
**Note:** The file "sample1.spx" was downloaded from [https://filesamples.com/formats/spx](https://filesamples.com/formats/spx)1.16.3Seungha Yangseungha@centricular.comSeungha Yangseungha@centricular.comhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/524New cairo overlay_rectangle premultiply function sometimes has pathological r...2020-07-10T11:13:48ZNirbheek Chauhannirbheek.chauhan@gmail.comNew cairo overlay_rectangle premultiply function sometimes has pathological runtimes on WindowsWhen processing ARGB frames, we need to premultiply the RGB with alpha because that's the format that cairo expects, and when we output frames, we then need to unpremultiply the alpha. This should be really fast, and it is really fast on...When processing ARGB frames, we need to premultiply the RGB with alpha because that's the format that cairo expects, and when we output frames, we then need to unpremultiply the alpha. This should be really fast, and it is really fast on Linux. However, on Windows the behaviour is very variable.
On my i5-4590 3.3GHz, premultiply_3 on a single 1920x1080 frame sometimes takes 0.75s, sometimes 4.7s, and upto 9.8s. Same for unpremultiply_3. This makes the overlay element totally useless with ARGB frames, and is a regression from 1.14 where we were output incorrect frames but at least they were outputted on time. The same behaviour is observed with both the MinGW and MSVC compilers.
The contents of the frame do not correlate with the time taken. Memsetting the frame to 0x0 or 0xff before calling premultiply does not seem to correlate with any changes in how much time it takes.
The assembly generated also looks correct and efficient, so more investigation is needed. For instance, it could be related scheduling priority (can be checked by raising the priority of that thread).
This issue is also very difficult to debug currently because all of Cerbero is still built with MinGW which makes it impossible to use any profiling tools on the code. I have meson ports for all the dependencies of gstcairo, ~~but SIMD optimizations are not correctly enabled in them, so further investigation is blocked on that~~. Even after enabling SIMD optimizations the problems are still seen. Needs someone to investigate.1.17.90