[FFmpeg-trac] #10296(undetermined:new): ffmpeg is not aware of the attribute x-dimensions when ingesting an MJPEG RTSP stream

[FFmpeg]

#10296: ffmpeg is not aware of the attribute x-dimensions when ingesting an MJPEG
RTSP stream
-------------------------------------+-------------------------------------
             Reporter:  johnab       |                    Owner:  (none)
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  unspecified  |               Resolution:
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Description changed by johnab:

Old description:

> Summary of the bug: When ingesting RTSP that is carrying an MJPEG video
> stream, ffmpeg is not aware of the attribute x-dimensions, causing it to
> incorrectly detect picture size as 0x0, leading to process closure.
> x-dimensions is used when either the height or the width is above 2040
> pixels.
>
> I have an RTSP source at 172.18.50.13, producing an MJPEG RTSP stream.
> The output in this case is videotest.mkv with a copy of the video codec,
> but the output is arbitrary and doesn't affect the issue.
>
> {{{
> % ffmpeg -loglevel debug -rtsp_transport tcp -i
> rtsp://172.18.50.13:8554/test -c:v copy -an videotest.mkv -y
>
> ffmpeg version N-109877-g9f7e51e513
> built with gcc 11 (Ubuntu 11.3.0-1ubuntu1~22.04)
> }}}
>
> Also tested with most recent stable, including distribution version with
> Ubuntu 22.04 via apt.
>
> To verify function, this was tested against VLC which uses live555 to
> handle the stream and that is x-dimensions aware. Stream previewed
> without any issue.
>
> Sample output:
> {{{
> [rtsp @ 0x559ac6928600] SDP:
> v=0
> o=- 17815773839113936454 1 IN IP4 172.18.50.13
> s=Session streamed with GStreamer
> i=rtsp-server
> t=0 0
> a=tool:GStreamer
> a=type:broadcast
> a=control:*
> a=range:npt=0-
> m=video 0 RTP/AVP 26
> c=IN IP4 0.0.0.0
> a=rtpmap:26 JPEG/90000
> a=framerate:10.000000
> a=x-dimensions:3840,2160
> a=control:stream=0
> a=ts-refclk:local
> a=mediaclk:sender
>
> Failed to parse interval end specification ''
> [rtsp @ 0x559ac6928600] video codec set to: mjpeg
> [rtsp @ 0x559ac6928600] setting jitter buffer size to 0
> [rtsp @ 0x559ac6928600] hello state=0
> Failed to parse interval end specification ''
> [mjpeg @ 0x559ac692d200] marker=d8 avail_size_in_buf=490868
> [mjpeg @ 0x559ac692d200] marker parser used 0 bytes (0 bits)
> [mjpeg @ 0x559ac692d200] marker=e0 avail_size_in_buf=490866
> [mjpeg @ 0x559ac692d200] marker parser used 16 bytes (128 bits)
> [mjpeg @ 0x559ac692d200] marker=db avail_size_in_buf=490848
> [mjpeg @ 0x559ac692d200] index=0
> [mjpeg @ 0x559ac692d200] qscale[0]: 2
> [mjpeg @ 0x559ac692d200] index=1
> [mjpeg @ 0x559ac692d200] qscale[1]: 4
> [mjpeg @ 0x559ac692d200] marker parser used 132 bytes (1056 bits)
> [mjpeg @ 0x559ac692d200] marker=c4 avail_size_in_buf=490714
> [mjpeg @ 0x559ac692d200] marker parser used 0 bytes (0 bits)
> [mjpeg @ 0x559ac692d200] marker=c0 avail_size_in_buf=490294
> [mjpeg @ 0x559ac692d200] Changing bps from 0 to 8
> [mjpeg @ 0x559ac692d200] sof0: picture: 0x0
> [mjpeg @ 0x559ac692d200] [IMGUTILS @ 0x7ffe65402a00] Picture size 0x0 is
> invalid
> }}}

New description:

 Summary of the bug: When ingesting RTSP that is carrying an MJPEG video
 stream, ffmpeg is not aware of the attribute x-dimensions, causing it to
 incorrectly detect picture size as 0x0, leading to process closure.
 x-dimensions is used when either the height or the width is above 2040
 pixels. The headers for picture size is set to 0x0 when either is above
 2040, which is why x-dimensions is critical.

 I have an RTSP source at 172.18.50.13, producing an MJPEG RTSP stream.
 The output in this case is videotest.mkv with a copy of the video codec,
 but the output is arbitrary and doesn't affect the issue.

 {{{
 % ffmpeg -loglevel debug -rtsp_transport tcp -i
 rtsp://172.18.50.13:8554/test -c:v copy -an videotest.mkv -y

 ffmpeg version N-109877-g9f7e51e513
 built with gcc 11 (Ubuntu 11.3.0-1ubuntu1~22.04)
 }}}

 Also tested with most recent stable, including distribution version with
 Ubuntu 22.04 via apt.

 To verify function, this was tested against VLC which uses live555 to
 handle the stream and that is x-dimensions aware. Stream previewed without
 any issue.

 Sample output:
 {{{
 [rtsp @ 0x559ac6928600] SDP:
 v=0
 o=- 17815773839113936454 1 IN IP4 172.18.50.13
 s=Session streamed with GStreamer
 i=rtsp-server
 t=0 0
 a=tool:GStreamer
 a=type:broadcast
 a=control:*
 a=range:npt=0-
 m=video 0 RTP/AVP 26
 c=IN IP4 0.0.0.0
 a=rtpmap:26 JPEG/90000
 a=framerate:10.000000
 a=x-dimensions:3840,2160
 a=control:stream=0
 a=ts-refclk:local
 a=mediaclk:sender

 Failed to parse interval end specification ''
 [rtsp @ 0x559ac6928600] video codec set to: mjpeg
 [rtsp @ 0x559ac6928600] setting jitter buffer size to 0
 [rtsp @ 0x559ac6928600] hello state=0
 Failed to parse interval end specification ''
 [mjpeg @ 0x559ac692d200] marker=d8 avail_size_in_buf=490868
 [mjpeg @ 0x559ac692d200] marker parser used 0 bytes (0 bits)
 [mjpeg @ 0x559ac692d200] marker=e0 avail_size_in_buf=490866
 [mjpeg @ 0x559ac692d200] marker parser used 16 bytes (128 bits)
 [mjpeg @ 0x559ac692d200] marker=db avail_size_in_buf=490848
 [mjpeg @ 0x559ac692d200] index=0
 [mjpeg @ 0x559ac692d200] qscale[0]: 2
 [mjpeg @ 0x559ac692d200] index=1
 [mjpeg @ 0x559ac692d200] qscale[1]: 4
 [mjpeg @ 0x559ac692d200] marker parser used 132 bytes (1056 bits)
 [mjpeg @ 0x559ac692d200] marker=c4 avail_size_in_buf=490714
 [mjpeg @ 0x559ac692d200] marker parser used 0 bytes (0 bits)
 [mjpeg @ 0x559ac692d200] marker=c0 avail_size_in_buf=490294
 [mjpeg @ 0x559ac692d200] Changing bps from 0 to 8
 [mjpeg @ 0x559ac692d200] sof0: picture: 0x0
 [mjpeg @ 0x559ac692d200] [IMGUTILS @ 0x7ffe65402a00] Picture size 0x0 is
 invalid
 }}}

--
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/10296#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker