[FFmpeg-trac] #3823(avformat:closed): RTP encoding of MJPEG from Trendnet TV-IP651WI (IP cam) gives undecodable stream

[FFmpeg]

#3823: RTP encoding of MJPEG from Trendnet TV-IP651WI (IP cam) gives undecodable
stream
------------------------------------+------------------------------------
             Reporter:  Krieger     |                    Owner:
                 Type:  defect      |                   Status:  closed
             Priority:  normal      |                Component:  avformat
              Version:  git-master  |               Resolution:  invalid
             Keywords:  mjpeg rtp   |               Blocked By:
             Blocking:              |  Reproduced by developer:  0
Analyzed by developer:  0           |
------------------------------------+------------------------------------

Comment (by andrey.utkin):

 Working on a patch to support large JPEGs over RTP:
 https://github.com/bluecherrydvr/ffmpeg/commit/0f15de1bb10d8afa6c0fcbaa5eb1368e731a7b70

 This patch needs to be applied to test the source in orig.mkv.

 So, when it is used this way:
 {{{ffmpeg -re -i /tmp/orig.mkv -c copy -f rtp rtp://127.0.0.1:7777
 -loglevel debug | tee /tmp/sdp}}}
 with
 {{{ffplay  -i /tmp/sdp}}}

 The encoding side shows no errors, but ffplay gives decoding errors:
 {{{
 ffplay version N-77132-g0f15de1 Copyright (c) 2003-2015 the FFmpeg
 developers
   built with gcc 4.9.3 (Gentoo 4.9.3 p1.2, pie-0.6.3)
   configuration: --enable-debug=3 --disable-optimizations --extra-
 cflags='-O0 -g3 -ggdb3' --enable-pic --disable-stripping --enable-openssl
 --enable-protocol=file --enable-protocol=pipe --enable-protocol=http
 --enable-protocol=https --enable-muxer=matroska --enable-muxer=mjpeg
 --enable-muxer=rtp --enable-muxer=mp4 --enable-muxer=rtsp --enable-
 muxer=rawvideo --enable-muxer=data --enable-demuxer=rtsp --enable-
 demuxer=matroska --enable-demuxer=mjpeg --enable-decoder=h264 --enable-
 decoder=mpeg4 --enable-decoder=mjpeg --enable-parser=h264 --enable-
 parser=mpeg4video --enable-parser=mjpeg --enable-encoder=mjpeg --enable-
 encoder=mpeg4 --enable-encoder=rawvideo --enable-encoder=libx264 --enable-
 libx264 --enable-gpl --enable-nonfree --enable-libfreetype --enable-
 libopenh264 --enable-libvpx --enable-encoder=libopenh264
   libavutil      55. 10.100 / 55. 10.100
   libavcodec     57. 17.100 / 57. 17.100
   libavformat    57. 19.100 / 57. 19.100
   libavdevice    57.  0.100 / 57.  0.100
   libavfilter     6. 20.100 /  6. 20.100
   libswscale      4.  0.100 /  4.  0.100
   libswresample   2.  0.101 /  2.  0.101
   libpostproc    54.  0.100 / 54.  0.100
 [mjpeg @ 0x7fe9b4000e60] Changing bps to 8    0KB sq=    0B f=0/0
 [sdp @ 0x7fe9b4001760] max delay reached. need to consume packet0
 [mjpeg @ 0x7fe9b4000e60] RTP: missed 38 packets
 Input #0, sdp, from '/tmp/s':q=    0KB vq=    0KB sq=    0B f=0/0
   Metadata:
     title           : No Name
   Duration: N/A, start: 0.000000, bitrate: N/A
     Stream #0:0: Video: mjpeg, yuvj422p(pc, bt470bg/unknown/unknown),
 2048x1536 [SAR 1:1 DAR 4:3], 14.17 tbr, 90k tbn, 90k tbc
 [mjpeg @ 0x7fe9b4000e60] mjpeg_decode_dc: bad vlc: 0:0 (0x7fe9b4008fc0)
 [mjpeg @ 0x7fe9b4000e60] error dc
 [mjpeg @ 0x7fe9b4000e60] error y=0 x=16
 [swscaler @ 0x7fe9ac61b260] deprecated pixel format used, make sure you
 did set range correctly
 [mjpeg @ 0x7fe9b4000e60] mjpeg_decode_dc: bad vlc: 0:0 (0x7fe9b4008fc0)
 [mjpeg @ 0x7fe9b4000e60] error dc
 [mjpeg @ 0x7fe9b4000e60] error y=0 x=16
 [mjpeg @ 0x7fe9b4000e60] mjpeg_decode_dc: bad vlc: 0:0 (0x7fe9b4008fc0)
 [mjpeg @ 0x7fe9b4000e60] error dc
 [mjpeg @ 0x7fe9b4000e60] error y=0 x=16
 [mjpeg @ 0x7fe9b4000e60] mjpeg_decode_dc: bad vlc: 0:0 (0x7fe9b4008fc0)
 [mjpeg @ 0x7fe9b4000e60] error dc
 [mjpeg @ 0x7fe9b4000e60] error y=0 x=16
 }}}

 When I try synthetic yuvj422p source with {{{ffmpeg -f lavfi -i
 testsrc,format=pix_fmts=yuvj422p -c mjpeg -f rtp rtp://127.0.0.1:7777
 -loglevel debug}}} it says {{{Only 1x1 chroma blocks are supported}}}.
 Debugger shows the checked scaling factor values are 0x18 for Cb and Cr
 components in this case, and they are 0x17 here when ffmpeg does rtp
 encoding from ready mjpeg stream in above case, despite these bytes are
 0x11 in original file. I find this strange and I mention this detail just
 for your information.

 Is rtp encoding of yuvj422p MJPEG supposed to fail here? Or is it related
 not to "pixel format", but to another property of stream?

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