RTP JPEG problem

Application Development
1

Hi, all!

I’m using gstreamer 1.18 and I have a video in MJPEG format. ffmpeg shows the following information about it:

Input #0, matroska,webm, from ‘D:\Movies\1920x1080\mjpeg_1920x1080.mkv’:
Metadata:
ENCODER : Lavf58.12.100
Duration: 00:01:12.24, start: 0.000000, bitrate: 15763 kb/s
Stream #0:0: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/unknown), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 1k tbn (default)
Metadata:
ENCODER : Lavc58.18.100 mjpeg
DURATION : 00:01:12.240000000

I can play it correctly using the command:

.\gst-launch-1.0.exe filesrc location=D:/Movies/1920x1080/mjpeg_1920x1080.mkv ! matroskademux ! jpegparse ! jpegdec ! videoconvert ! autovideosink

But if I try to send the file as an RTP stream and then receive it, the resulting picture is completely broken. Here are the commands:

.\gst-launch-1.0.exe filesrc location=D:/Movies/1920x1080/mjpeg_1920x1080.mkv ! matroskademux ! jpegparse ! rtpjpegpay ! udpsink host=127.0.0.1 port=5000

.\gst-launch-1.0.exe udpsrc uri=udp://127.0.0.1:5000 caps=“application/x-rtp, media=video, encoding-name=JPEG” ! rtpjpegdepay ! jpegparse ! jpegdec ! videoconvert ! autovideosink

There is a problem file: MJPEG file

Could you please advise me what could be the problem?

2

Have you tried a newer version (1.24.x) yet to see if it’s still a problem with that?

3

Yeah, nothing’s changed.

4

Reason I asked is because there was https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/999

5

I installed version 1.24.8 and saw no change in behavior. The picture is still corrupted

6

But if I explicitly call transcoding, it’s fine.

.\gst-launch-1.0.exe filesrc location=D:/Movies/1920x1080/mjpeg_1920x1080.mkv ! matroskademux ! jpegdec ! jpegenc ! rtpjpegpay ! udpsink host=127.0.0.1 port=5000

7

Not sure at all, but does adding identity or identity sync=1 after jpegparse (or rtpjpegpay) help ?

8

Tried identity, it didn’t work

9

This link requires “the e-mail address this file was shared with” in order to download it.

10

Here is the new link, the file should be downloadable
New MJPEG link

11

Issue can also be reproduced on Linux with

gst-launch-1.0 filesrc location=mjpeg_1920x1080.mkv ! matroskademux ! jpegparse ! rtpjpegpay ! rtpjpegdepay ! jpegdec ! videoconvert ! glimagesink

New RTP JPEG payloader/depayloader from gst-plugins-rs errors out with:

Failed parsing JPEG header: Component 0 has same quantization table as component 1
12

Is there any way to solve this problem? Is it a bug in a particular clip or in gstreamer itself?

13

Unclear, needs more investigation :slightly_smiling_face:

14

See RFC 2435 4.1

   The two RTP/JPEG types currently defined are described below:

                            horizontal   vertical   Quantization
           types  component samp. fact. samp. fact. table number
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       |  1 (Y)  |     2     |     1     |     0     |
         | 0, 64 |  2 (U)  |     1     |     1     |     1     |
         |       |  3 (V)  |     1     |     1     |     1     |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       |  1 (Y)  |     2     |     2     |     0     |
         | 1, 65 |  2 (U)  |     1     |     1     |     1     |
         |       |  3 (V)  |     1     |     1     |     1     |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The current RFC only supports 4:2:2 and 4:2:0 YUV JPEG, and Y and U/V need to have distinct quantization tables.

The old payloader just assumed this and didn’t check anything (resulting in broken output), the new payloader properly enforces this and errors out otherwise.