Opened 5 years ago

Last modified 2 years ago

#8211 open enhancement

ffplay doesn't play mjpeg stream

Reported by: Anh Owned by:
Priority: wish Component: avformat
Version: git-master Keywords: rtsp mjpeg
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: yes

Description

I have the "Happy Cow I-Spy" toy with the wi-fi camera that casts live video encoded with mjpeg. I try to connect the toy expecting to seen the video stream: ffplay rtsp://192.168.1.1:7070, but seen green screen only with small strip of image at the top. Sorry for screenshots, I have'nt the plain text output, except an error msg:

mjpeg_decode_dc: bad vlc: 0:0
error dc
error y=1 x=0

Attachments (7)

01.jpg​ (453.0 KB ) - added by Anh 5 years ago.
02.jpg​ (504.3 KB ) - added by Anh 5 years ago.
03.jpg​ (478.9 KB ) - added by Anh 5 years ago.
04.jpg​ (477.2 KB ) - added by Anh 5 years ago.
mjpegstream.dump​ (2.1 MB ) - added by Anh 5 years ago.
ffmpeg -i rtsp://192.168.1.1:7070/webcam -vcodec copy -map 0:v:0 -f rawvideo -fs 2200K mjpegstream.dump
ffmpeg_patch.txt​ (2.3 MB ) - added by HappyCow 4 years ago.
console ouput for patched ffmpeg
log.txt​ (233.8 KB ) - added by Obadiah 2 years ago.

Change History (33)

by Anh, 5 years ago

Attachment: 01.jpg​ added

by Anh, 5 years ago

Attachment: 02.jpg​ added

by Anh, 5 years ago

Attachment: 03.jpg​ added

by Anh, 5 years ago

Attachment: 04.jpg​ added

comment:1 by Carl Eugen Hoyos, 5 years ago

Component: ffplay → undetermined
Version: 4.2 → unspecified

Please test current FFmpeg git head, test ffmpeg instead of ffplay and please post the command line you tested together with the complete, uncut console output as text, do not attach screenshots.

comment:2 by Anh, 5 years ago 

C:\Users\иван\Луноход1>ffmpeg -loglevel debug -i rtsp://192.168.1.1:7070/webcam output.avi
ffmpeg version N-95129-g04858650b1 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 9.2.1 (GCC) 20190918
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt --enable-amf
  libavutil      56. 35.100 / 56. 35.100
  libavcodec     58. 59.101 / 58. 59.101
  libavformat    58. 33.100 / 58. 33.100
  libavdevice    58.  9.100 / 58.  9.100
  libavfilter     7. 59.100 /  7. 59.100
  libswscale      5.  6.100 /  5.  6.100
  libswresample   3.  6.100 /  3.  6.100
  libpostproc    55.  6.100 / 55.  6.100
Splitting the commandline.
Reading option '-loglevel' ... matched as option 'loglevel' (set logging level) with argument 'debug'.
Reading option '-i' ... matched as input url with argument 'rtsp://192.168.1.1:7070/webcam'.
Reading option 'output.avi' ... matched as output url.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option loglevel (set logging level) with argument debug.
Successfully parsed a group of options.
Parsing a group of options: input url rtsp://192.168.1.1:7070/webcam.
Successfully parsed a group of options.
Opening an input file: rtsp://192.168.1.1:7070/webcam.
[tcp @ 000002900432be40] No default whitelist set
[tcp @ 000002900432be40] Original list of addresses:
[tcp @ 000002900432be40] Address 192.168.1.1 port 7070
[tcp @ 000002900432be40] Interleaved list of addresses:
[tcp @ 000002900432be40] Address 192.168.1.1 port 7070
[tcp @ 000002900432be40] Starting connection attempt to 192.168.1.1 port 7070
[tcp @ 000002900432be40] Successfully connected to 192.168.1.1 port 7070
[rtsp @ 0000029004329540] SDP:
v=0
o=- 1 1 IN IP4 127.0.0.1
s=Test
a=type:broadcast
t=0 0
c=IN IP4 0.0.0.0
m=video 0 RTP/AVP 26
a=control:track0

[rtp @ 00000290043317c0] No default whitelist set
[udp @ 0000029004332ac0] No default whitelist set
[udp @ 0000029004332ac0] 'circular_buffer_size' option was set but it is not supported on this build (pthread support is required)
[udp @ 0000029004332ac0] end receive buffer size reported is 65536
[udp @ 0000029004342d80] No default whitelist set
[udp @ 0000029004342d80] 'circular_buffer_size' option was set but it is not supported on this build (pthread support is required)
[udp @ 0000029004342d80] end receive buffer size reported is 65536
[rtsp @ 0000029004329540] setting jitter buffer size to 500
[rtsp @ 0000029004329540] hello state=0
[mjpeg @ 000002900432d280] marker=d8 avail_size_in_buf=25200
[mjpeg @ 000002900432d280] marker parser used 0 bytes (0 bits)
[mjpeg @ 000002900432d280] marker=e0 avail_size_in_buf=25198
[mjpeg @ 000002900432d280] marker parser used 16 bytes (128 bits)
[mjpeg @ 000002900432d280] marker=dd avail_size_in_buf=25180
[mjpeg @ 000002900432d280] marker parser used 0 bytes (0 bits)
[mjpeg @ 000002900432d280] marker=db avail_size_in_buf=25174
[mjpeg @ 000002900432d280] index=0
[mjpeg @ 000002900432d280] qscale[0]: 11
[mjpeg @ 000002900432d280] index=1
[mjpeg @ 000002900432d280] qscale[1]: 21
[mjpeg @ 000002900432d280] marker parser used 132 bytes (1056 bits)
[mjpeg @ 000002900432d280] marker=c4 avail_size_in_buf=25040
[mjpeg @ 000002900432d280] marker parser used 0 bytes (0 bits)
[mjpeg @ 000002900432d280] marker=c0 avail_size_in_buf=24620
[mjpeg @ 000002900432d280] Changing bps from 0 to 8
[mjpeg @ 000002900432d280] sof0: picture: 640x480
[mjpeg @ 000002900432d280] component 0 2:2 id: 0 quant:0
[mjpeg @ 000002900432d280] component 1 1:1 id: 1 quant:1
[mjpeg @ 000002900432d280] component 2 1:1 id: 2 quant:1
[mjpeg @ 000002900432d280] pix fmt id 22111100
[mjpeg @ 000002900432d280] Format yuvj420p chosen by get_format().
[mjpeg @ 000002900432d280] marker parser used 17 bytes (136 bits)
[mjpeg @ 000002900432d280] escaping removed 39 bytes
[mjpeg @ 000002900432d280] marker=da avail_size_in_buf=24601
[mjpeg @ 000002900432d280] marker parser used 24562 bytes (196496 bits)
[mjpeg @ 000002900432d280] marker=d9 avail_size_in_buf=2
[mjpeg @ 000002900432d280] decode frame unused 2 bytes
[rtsp @ 0000029004329540] max delay reached. need to consume packet
[rtsp @ 0000029004329540] RTP: missed 11 packets
[rtsp @ 0000029004329540] RTP timestamps don't match.
[rtsp @ 0000029004329540] Received packet without a start chunk; dropping frame.
    Last message repeated 12 times
[rtsp @ 0000029004329540] All info found
Input #0, rtsp, from 'rtsp://192.168.1.1:7070/webcam':
  Metadata:
    title           : Test
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0, 21, 1/90000: Video: mjpeg (Baseline), 1 reference frame, yuvj420p(pc, bt470bg/unknown/unknown, center), 640x480 [SAR 1:1 DAR 4:3], 0/1, 20 tbr, 90k tbn, 90k tbc
Successfully opened the file.
Parsing a group of options: output url output.avi.
Successfully parsed a group of options.
Opening an output file: output.avi.
[file @ 00000290043909c0] Setting default whitelist 'file,crypto'
Successfully opened the file.
Stream mapping:
  Stream #0:0 -> #0:0 (mjpeg (native) -> mpeg4 (native))
Press [q] to stop, [?] for help
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
[mjpeg @ 0000029004355d00] marker=d8 avail_size_in_buf=25200
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=e0 avail_size_in_buf=25198
[mjpeg @ 0000029004355d00] marker parser used 16 bytes (128 bits)
[mjpeg @ 0000029004355d00] marker=dd avail_size_in_buf=25180
[mjpeg @ 0000029004355d00] restart interval: 944
[mjpeg @ 0000029004355d00] marker parser used 4 bytes (32 bits)
[mjpeg @ 0000029004355d00] marker=db avail_size_in_buf=25174
[mjpeg @ 0000029004355d00] index=0
[mjpeg @ 0000029004355d00] qscale[0]: 11
[mjpeg @ 0000029004355d00] index=1
[mjpeg @ 0000029004355d00] qscale[1]: 21
[mjpeg @ 0000029004355d00] marker parser used 132 bytes (1056 bits)
[mjpeg @ 0000029004355d00] marker=c4 avail_size_in_buf=25040
[mjpeg @ 0000029004355d00] class=0 index=0 nb_codes=12
[mjpeg @ 0000029004355d00] class=0 index=1 nb_codes=12
[mjpeg @ 0000029004355d00] class=1 index=0 nb_codes=251
[mjpeg @ 0000029004355d00] class=1 index=1 nb_codes=251
[mjpeg @ 0000029004355d00] marker parser used 418 bytes (3344 bits)
[mjpeg @ 0000029004355d00] marker=c0 avail_size_in_buf=24620
[mjpeg @ 0000029004355d00] sof0: picture: 640x480
[mjpeg @ 0000029004355d00] component 0 2:2 id: 0 quant:0
[mjpeg @ 0000029004355d00] component 1 1:1 id: 1 quant:1
[mjpeg @ 0000029004355d00] component 2 1:1 id: 2 quant:1
[mjpeg @ 0000029004355d00] pix fmt id 22111100
[mjpeg @ 0000029004355d00] Format yuvj420p chosen by get_format().
[mjpeg @ 0000029004355d00] marker parser used 17 bytes (136 bits)
[mjpeg @ 0000029004355d00] escaping removed 39 bytes
[mjpeg @ 0000029004355d00] marker=da avail_size_in_buf=24601
[mjpeg @ 0000029004355d00] component: 0
[mjpeg @ 0000029004355d00] component: 1
[mjpeg @ 0000029004355d00] component: 2
[mjpeg @ 0000029004355d00] mjpeg_decode_dc: bad vlc: 0:0 (00000290043eb048)
[mjpeg @ 0000029004355d00] error dc
[mjpeg @ 0000029004355d00] error y=1 x=0
[mjpeg @ 0000029004355d00] marker parser used 953 bytes (7620 bits)
[mjpeg @ 0000029004355d00] marker=d0 avail_size_in_buf=23643
[mjpeg @ 0000029004355d00] restart marker: 0
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d1 avail_size_in_buf=22576
[mjpeg @ 0000029004355d00] restart marker: 1
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d2 avail_size_in_buf=21514
[mjpeg @ 0000029004355d00] restart marker: 2
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d3 avail_size_in_buf=20387
[mjpeg @ 0000029004355d00] restart marker: 3
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d4 avail_size_in_buf=19231
[mjpeg @ 0000029004355d00] restart marker: 4
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d5 avail_size_in_buf=18058
[mjpeg @ 0000029004355d00] restart marker: 5
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d6 avail_size_in_buf=16804
[mjpeg @ 0000029004355d00] restart marker: 6
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d7 avail_size_in_buf=15667
[mjpeg @ 0000029004355d00] restart marker: 7
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d0 avail_size_in_buf=14624
[mjpeg @ 0000029004355d00] restart marker: 0
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d1 avail_size_in_buf=13713
[mjpeg @ 0000029004355d00] restart marker: 1
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d2 avail_size_in_buf=12874
[mjpeg @ 0000029004355d00] restart marker: 2
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d3 avail_size_in_buf=12117
[mjpeg @ 0000029004355d00] restart marker: 3
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d4 avail_size_in_buf=11426
[mjpeg @ 0000029004355d00] restart marker: 4
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d5 avail_size_in_buf=10771
[mjpeg @ 0000029004355d00] restart marker: 5
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d6 avail_size_in_buf=10128
[mjpeg @ 0000029004355d00] restart marker: 6
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d7 avail_size_in_buf=9486
[mjpeg @ 0000029004355d00] restart marker: 7
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d0 avail_size_in_buf=8791
[mjpeg @ 0000029004355d00] restart marker: 0
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d1 avail_size_in_buf=8067
[mjpeg @ 0000029004355d00] restart marker: 1
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d2 avail_size_in_buf=7309
[mjpeg @ 0000029004355d00] restart marker: 2
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d3 avail_size_in_buf=6531
[mjpeg @ 0000029004355d00] restart marker: 3
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d4 avail_size_in_buf=5741
[mjpeg @ 0000029004355d00] restart marker: 4
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d5 avail_size_in_buf=4988
[mjpeg @ 0000029004355d00] restart marker: 5
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d6 avail_size_in_buf=4203
[mjpeg @ 0000029004355d00] restart marker: 6
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d7 avail_size_in_buf=3470
[mjpeg @ 0000029004355d00] restart marker: 7
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d0 avail_size_in_buf=2621
[mjpeg @ 0000029004355d00] restart marker: 0
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d1 avail_size_in_buf=1979
[mjpeg @ 0000029004355d00] restart marker: 1
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d2 avail_size_in_buf=1363
[mjpeg @ 0000029004355d00] restart marker: 2
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d3 avail_size_in_buf=836
[mjpeg @ 0000029004355d00] restart marker: 3
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d4 avail_size_in_buf=358
[mjpeg @ 0000029004355d00] restart marker: 4
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=d9 avail_size_in_buf=2
[mjpeg @ 0000029004355d00] decode frame unused 2 bytes
detected 2 logical cores
[graph 0 input from stream 0:0 @ 00000290049fd5c0] Setting 'video_size' to value '640x480'
[graph 0 input from stream 0:0 @ 00000290049fd5c0] Setting 'pix_fmt' to value '12'
[graph 0 input from stream 0:0 @ 00000290049fd5c0] Setting 'time_base' to value '1/90000'
[graph 0 input from stream 0:0 @ 00000290049fd5c0] Setting 'pixel_aspect' to value '1/1'
[graph 0 input from stream 0:0 @ 00000290049fd5c0] Setting 'sws_param' to value 'flags=2'
[graph 0 input from stream 0:0 @ 00000290049fd5c0] Setting 'frame_rate' to value '20/1'
[graph 0 input from stream 0:0 @ 00000290049fd5c0] w:640 h:480 pixfmt:yuvj420p tb:1/90000 fr:20/1 sar:1/1 sws_param:flags=2
[format @ 00000290049d9380] Setting 'pix_fmts' to value 'yuv420p'
[auto_scaler_0 @ 00000290049d97c0] Setting 'flags' to value 'bicubic'
[auto_scaler_0 @ 00000290049d97c0] w:iw h:ih flags:'bicubic' interl:0
[format @ 00000290049d9380] auto-inserting filter 'auto_scaler_0' between the filter 'Parsed_null_0' and the filter 'format'
[AVFilterGraph @ 00000290049fb940] query_formats: 4 queried, 2 merged, 1 already done, 0 delayed
[swscaler @ 000002900488f0c0] deprecated pixel format used, make sure you did set range correctly
[auto_scaler_0 @ 00000290049d97c0] w:640 h:480 fmt:yuvj420p sar:1/1 -> w:640 h:480 fmt:yuv420p sar:1/1 flags:0x4
[mpeg4 @ 0000029004353cc0] intra_quant_bias = 0 inter_quant_bias = -64
[avi @ 00000290043ec000] reserve_index_space:0 master_index_max_size:256
[avi @ 00000290043ec000] duration_est:36000.000, filesize_est:0.9GiB, master_index_max_size:256
Output #0, avi, to 'output.avi':
  Metadata:
    INAM            : Test
    ISFT            : Lavf58.33.100
    Stream #0:0, 0, 1/20: Video: mpeg4, 1 reference frame (FMP4 / 0x34504D46), yuv420p(center), 640x480 [SAR 1:1 DAR 4:3], 0/1, q=2-31, 200 kb/s, 20 fps, 20 tbn, 20 tbc
    Metadata:
      encoder         : Lavc58.59.101 mpeg4
    Side data:
      cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: N/A
Clipping frame in rate conversion by 0.000008
[mjpeg @ 0000029004355d00] marker=d8 avail_size_in_buf=25244
[mjpeg @ 0000029004355d00] marker parser used 0 bytes (0 bits)
[mjpeg @ 0000029004355d00] marker=e0 avail_size_in_buf=25242
[mjpeg @ 0000029004355d00] marker parser used 16 bytes (128 bits)
[mjpeg @ 0000029004355d00] marker=dd avail_size_in_buf=25224
[mjpeg @ 0000029004355d00] restart interval: 939
[mjpeg @ 0000029004355d00] marker parser used 4 bytes (32 bits)
[mjpeg @ 0000029004355d00] marker=db avail_size_in_buf=25218
[mjpeg @ 0000029004355d00] index=0
[mjpeg @ 0000029004355d00] qscale[0]: 11
[mjpeg @ 0000029004355d00] index=1
[mjpeg @ 0000029004355d00] qscale[1]: 21
[mjpeg @ 0000029004355d00] marker parser used 132 bytes (1056 bits)
[mjpeg @ 0000029004355d00] marker=c4 avail_size_in_buf=25084
[mjpeg @ 0000029004355d00] class=0 index=0 nb_codes=12
[mjpeg @ 0000029004355d00] class=0 index=1 nb_codes=12
[mjpeg @ 0000029004355d00] class=1 index=0 nb_codes=251
[mjpeg @ 0000029004355d00] class=1 index=1 nb_codes=251
[mjpeg @ 0000029004355d00] marker parser used 418 bytes (3344 bits)
[mjpeg @ 0000029004355d00] marker=c0 avail_size_in_buf=24664
[mjpeg @ 0000029004355d00] sof0: picture: 640x480
[mjpeg @ 0000029004355d00] component 0 2:2 id: 0 quant:0
[mjpeg @ 0000029004355d00] component 1 1:1 id: 1 quant:1
[mjpeg @ 0000029004355d00] component 2 1:1 id: 2 quant:1
[mjpeg @ 0000029004355d00] pix fmt id 22111100
[mjpeg @ 0000029004355d00] marker parser used 17 bytes (136 bits)
[mjpeg @ 0000029004355d00] escaping removed 52 bytes
[mjpeg @ 0000029004355d00] marker=da avail_size_in_buf=24645
[mjpeg @ 0000029004355d00] component: 0
[mjpeg @ 0000029004355d00] component: 1
[mjpeg @ 0000029004355d00] component: 2
[mjpeg @ 0000029004355d00] mjpeg_decode_dc: bad vlc: 0:0 (00000290043eb048)
[mjpeg @ 0000029004355d00] error dc
[mjpeg @ 0000029004355d00] error y=1 x=0
Last edited 5 years ago by Carl Eugen Hoyos (previous) (diff)

comment:3 by Carl Eugen Hoyos, 5 years ago

Version: unspecified → git-master

Please test if the following allows to save a sample stream that you can attach here:

$ ffmpeg -i rtsp://192.168.1.1:7070/webcam -vcodec copy -map 0:v:0 -f rawvideo -fs 2200K mjpegstream.dump

by Anh, 5 years ago

Attachment: mjpegstream.dump​ added

ffmpeg -i rtsp://192.168.1.1:7070/webcam -vcodec copy -map 0:v:0 -f rawvideo -fs 2200K mjpegstream.dump

comment:4 by Carl Eugen Hoyos, 5 years ago

Does the original rtsp stream work with vlc? With which other software does it work?

comment:5 by Anh, 5 years ago

VLC is plays exactly like ffmpeg/ffplay, i.e. output a green screen with a small strip at the top. The original android soft works correctly (​https://m.vk.com/away.php?to=https%3A%2F%2Fapkpure.com%2Fru%2Fi-spy-mini%2Fcom.leo.jg270.Controler.jgremoter)

comment:6 by Carl Eugen Hoyos, 5 years ago

I have a suspicion that the stream does not conform to the specification and has to be reverse engineered - but I am happy if somebody corrects me!

comment:7 by Carl Eugen Hoyos, 5 years ago

Component: undetermined → avformat
Keywords: rtsp mjpeg added
Priority: normal → wish
Type: defect → enhancement

comment:8 by Carl Eugen Hoyos, 5 years ago

The application uses libavformat to receive the stream, it may make sense to ask them which options are needed / how they patched FFmpeg.

in reply to:  8 ; comment:9 by Anh, 5 years ago

Replying to cehoyos:

it may make sense to ask them

I asked them, no answer yet.
Maybe this is encription of stream, because the original brand maker does protect itself against fake branding

Last edited 5 years ago by Anh (previous) (diff)

in reply to:  9 comment:10 by HappyCow, 4 years ago

Dear friends, the solution may be in the calculation of the buffer size [¿?]
That is the only difference in the whole process.
Comparing one by one the analysis sequence of IjkPlayer on Android (FFmpeg: ff3.3--bw0.8.0--20180323--001-1-geb1575fefe) and FFPLAY on Windows (version 4.3.2-2021-02-27-full_build-www.gyan.dev) they are EXACTLY the same except when arriving at the stage of decoding the JFIF markers (specially the DA marker [Start of Scan]):

IJKMEDIA [IjkPlayer]
marker=da avail_size_in_buf=37009
component: 0
component: 1
component: 2
marker parser used 36932 bytes (295454 bits)

ffplay -loglevel debug -i rtsp://192.168.1.1:7070/webcam
[mjpeg @ 05ff6740]
marker=da avail_size_in_buf=17132
component: 0
component: 1
component: 2
mjpeg_decode_dc: bad vlc: 0:0 (05b1e6a8)
error dc
error y=1 x=0
marker parser used 196 bytes (1568 bits)

As you can see the avail_size_in_buf reserved is consistently more or less half of the required
so the marker=da is just partially processed resulting in the final error

Apparently, this has nothing to do with the available memory as that other lines are more or less equal in both systems:
[udp @ 05af7080] end receive buffer size reported is 65536
[udp @ 05b0cdc0] No default whitelist set
[udp @ 05b0cdc0] 'circular_buffer_size' option was set but it is not supported on this build (pthread support is required)
[udp @ 05b0cdc0] end receive buffer size reported is 65536
[rtsp @ 05af50a0] setting jitter buffer size to 500

However, unfortunately I have not found out how to change that behaviour on the Windows implementation, and the error persists.

Any suggestions are welcome. Best regards.

in reply to:  5 comment:11 by Balling, 4 years ago

Replying to anhsoft:

VLC plays exactly like ffmpeg/ffplay, i.e. is outputting a green screen with a small strip at the top.

No, it does not. There is gray screen and there is also a small strip on the bottom (but that is just because it thinks it is RGB, while ffmpeg thinks it is YCbCr). I am afraid that looks like the same encryption used in multicast IPTV in MGTS provider in Moscow. Nobody cracked it yet.

Last edited 4 years ago by Balling (previous) (diff)

comment:12 by HappyCow, 4 years ago

No, anhsoft is basically right.
More or less the same results are obtained using ffmpeg/ffplay, VLC, GStreamer, OpenCV and its derivatives in Windows and Linux [32 bits and 64 bits] (but not in Android)
The frames are just partially decoded (the main top strip and sometimes other partial strips [when movement happens] either at the middle or at the bottom part of the image.
This is a problem that seems it is plaguing the internet forums... as it happens with a broad range of devices [endoscope camera Ypc99, I-Spy mini tank, quite a few cheap drones, and some devices using v4l2rtspserver, etc]
The IjkPlayer does ok on android [where libijkffmpeg.so is just an specific ffmpeg build] but the other platforms fail to do the job.
However, as far as I have traced it, all the decoding parameters and steps seem exactly identical [Stream #0:0, 21, 1/90000: Video: mjpeg, 1 reference frame, yuvj420p(pc, bt470bg/unknown/unknown, center), 640x480 [SAR 1:1 DAR 4:3], 0/1, 20 fps, 20 tbr, 90k tbn, 90k tbc] except when it comes to the marker=da buffer size estimation.
The reason is unknown to me, but it does not seem to be related to any type of encryption, just some incompatibility with the calculation of buffer sizes (I guess)
Even forcing some other types of codecs as mjpeg_qsv and other parameters you get quite similar results.

comment:13 by HappyCow, 4 years ago

Dear friends, this problem has me stuck and intrigued yet.
Basically the same application (ffmpeg) doing a perfect job in Android and failing in the other platforms.
Probably the difference is subtle and requires and expert eye (what I am absolutely not, due to my lack of knowledge in ffmpeg)
You can tell, following the decoding process in both platforms that everything goes quite similar, except for the estimation of the "avail_size_in_buf" [which I assume is the AVPacket->pkt->size] when parsing the first JFIF D8 marker [SOI, Start of Image], then it also differs when parsing the DD [restart interval], and finally it goes crazy with the DA [start of scan] (my guess is because it got the buffer size wrong) until it finally reaches the D9 [end of image] and the same history repeats again over and over, frame after frame.
I am including the comparative table in both platforms.

IjkPlayer (Android) FFPLAY (Windows)
marker=d8 avail_size_in_buf=37738 marker=d8 avail_size_in_buf=8859
marker parser used 0 bytes (0 bits)marker parser used 0 bytes (0 bits)
marker=e0 avail_size_in_buf=37736marker=e0 avail_size_in_buf=8857
marker parser used 16 bytes (128 bits)marker parser used 16 bytes (128 bits)
marker=dd avail_size_in_buf=8839
restart interval: 1181
marker parser used 4 bytes (32 bits)
marker=db avail_size_in_buf=37718 marker=db avail_size_in_buf=8833
index=0index=0
qscale[0]: 11qscale[0]: 11
index=1index=1
qscale[1]: 21qscale[1]: 21
marker parser used 132 bytes (1056 bits)marker parser used 132 bytes (1056 bits)
marker=dd avail_size_in_buf=37584
restart interval: 40
marker parser used 4 bytes (32 bits)
marker=c4 avail_size_in_buf=37578marker=c4 avail_size_in_buf=8699
class=0 index=0 nb_codes=12class=0 index=0 nb_codes=12
class=0 index=1 nb_codes=12class=0 index=1 nb_codes=12
class=1 index=0 nb_codes=251class=1 index=0 nb_codes=251
class=1 index=1 nb_codes=251class=1 index=1 nb_codes=251
marker parser used 418 bytes (3344 bits)marker parser used 418 bytes (3344 bits)
marker=c0 avail_size_in_buf=37158marker=c0 avail_size_in_buf=8279
sof0: picture: 640x480sof0: picture: 640x480
component 0 2:2 id: 0 quant:0component 0 2:2 id: 0 quant:0
component 1 1:1 id: 1 quant:1component 1 1:1 id: 1 quant:1
component 2 1:1 id: 2 quant:1component 2 1:1 id: 2 quant:1
pix fmt id 22111100pix fmt id 22111100
marker parser used 17 bytes (136 bits)marker parser used 17 bytes (136 bits)
escaping removed 76 bytes escaping removed 15 bytes
marker=da avail_size_in_buf=37139 marker=da avail_size_in_buf=8260
component: 0component: 0
component: 1component: 1
component: 2component: 2
marker parser used 37062 bytes (296490 bits) mjpeg_decode_dc: bad vlc: 0:0 (0000021cc9e39248)
error dc
error y=1 x=0
marker parser used 245 bytes (1955 bits)
marker=d0 avail_size_in_buf=8013
restart marker: 0
marker parser used 0 bytes (0 bits)
marker=d1 avail_size_in_buf=7774
restart marker: 1
marker parser used 0 bytes (0 bits)
marker=d2 avail_size_in_buf=7536
restart marker: 2
marker parser used 0 bytes (0 bits)
marker=d3 avail_size_in_buf=7301
restart marker: 3
marker parser used 0 bytes (0 bits)
marker=d4 avail_size_in_buf=7065
restart marker: 4
marker parser used 0 bytes (0 bits)
marker=d5 avail_size_in_buf=6834
restart marker: 5
marker parser used 0 bytes (0 bits)
marker=d6 avail_size_in_buf=6612
restart marker: 6
marker parser used 0 bytes (0 bits)
marker=d7 avail_size_in_buf=6388
restart marker: 7
marker parser used 0 bytes (0 bits)
marker=d0 avail_size_in_buf=6151
restart marker: 0
marker parser used 0 bytes (0 bits)
marker=d1 avail_size_in_buf=5928
restart marker: 1
marker parser used 0 bytes (0 bits)
marker=d2 avail_size_in_buf=5699
restart marker: 2
marker parser used 0 bytes (0 bits)
marker=d3 avail_size_in_buf=5468
restart marker: 3
marker parser used 0 bytes (0 bits)
marker=d4 avail_size_in_buf=5200
restart marker: 4
marker parser used 0 bytes (0 bits)
marker=d5 avail_size_in_buf=4806
restart marker: 5
marker parser used 0 bytes (0 bits)
marker=d6 avail_size_in_buf=4339
restart marker: 6
marker parser used 0 bytes (0 bits)
marker=d7 avail_size_in_buf=3754
restart marker: 7
marker parser used 0 bytes (0 bits)
marker=d0 avail_size_in_buf=3324
restart marker: 0
marker parser used 0 bytes (0 bits)
marker=d1 avail_size_in_buf=3103
restart marker: 1
marker parser used 0 bytes (0 bits)
marker=d2 avail_size_in_buf=2898
restart marker: 2
marker parser used 0 bytes (0 bits)
marker=d3 avail_size_in_buf=2659
restart marker: 3
marker parser used 0 bytes (0 bits)
marker=d4 avail_size_in_buf=2425
restart marker: 4
marker parser used 0 bytes (0 bits)
marker=d5 avail_size_in_buf=2165
restart marker: 5
marker parser used 0 bytes (0 bits)
marker=d6 avail_size_in_buf=1869
restart marker: 6
marker parser used 0 bytes (0 bits)
marker=d7 avail_size_in_buf=1593
restart marker: 7
marker parser used 0 bytes (0 bits)
marker=d0 avail_size_in_buf=1325
restart marker: 0
marker parser used 0 bytes (0 bits)
marker=d1 avail_size_in_buf=1065
restart marker: 1
marker parser used 0 bytes (0 bits)
marker=d2 avail_size_in_buf=788
restart marker: 2
marker parser used 0 bytes (0 bits)
marker=d3 avail_size_in_buf=515
restart marker: 3
marker parser used 0 bytes (0 bits)
marker=d4 avail_size_in_buf=284
restart marker: 4
marker parser used 0 bytes (0 bits)
marker=d9 avail_size_in_buf=2 marker=d9 avail_size_in_buf=2
decode frame unused 2 bytesdecode frame unused 2 bytes

I would like to explore how an exact build of the Android version would behave in Windows

ijkplayer : b0.4.0-48-g3642e87f
FFmpeg : ff3.3--bw0.8.0--20180323--001-1-geb1575fefe
libavutil : 55.58.100
libavcodec : 57.89.100
libavformat : 57.71.100
libswscale : 4.6.100
libswresample: 2.7.100

--enable asm
--disable audiotoolbox
--enable avcodec
--disable avdevice
--enable avfilter
--enable avformat
--disable avresample
--enable avutil
--disable bsfs
--enable cross-compile
--disable d3d11va
--disable debug
--disable decoders
--enable decoder=aac
--enable decoder=aac_latm
--enable decoder=h264
--enable decoder=mjpeg
--enable decoder=mpeg4
--enable decoder=pcm_s16be
--enable decoder=pcm_s16le
--disable demuxers
--enable demuxer=aac
--enable demuxer=avi
--enable demuxer=h264
--enable demuxer=mjpeg
--enable demuxer=mov
--enable demuxer=pcm_s16be
--enable demuxer=pcm_s16le
--enable demuxer=rtsp
--disable devices
--disable doc
--disable dxva2
--disable encoders
--enable encoder=aac
--enable encoder=libx264
--enable encoder=mjpeg
--enable encoder=mpeg4
--enable encoder=png
--disable ffmpeg
--disable ffplay
--disable ffprobe
--disable ffserver
--disable filters
--enable filter=anullsink
--enable filter=anullsrc
--enable filter=aresample
--enable filter=hflip
--enable filter=nullsink
--enable filter=nullsrc
--enable filter=rotate
--enable filter=transpose
--enable filter=vflip
--disable gpl
--enable gpl
--disable gray
--disable htmlpages
--disable iconv
--enable inline-asm
--enable libx264
--disable manpages
--disable muxers
--enable muxer=avi
--enable muxer=h264
--enable muxer=image2
--enable muxer=mjpeg
--enable muxer=mov
--enable muxer=mp4
--enable network
--disable nonfree
--enable optimizations
--disable parsers
--enable parser=aac
--enable parser=aac_latm
--enable parser=h264
--enable parser=mjpeg
--enable parser=mpeg4video
--enable pic
--disable podpages
--disable postproc
--disable programs
--disable protocols
--enable protocol=async
--enable protocol=file
--enable protocol=rtp
--enable protocol=tcp
--enable protocol=udp
--enable runtime-cpudetect
--enable small
--enable swresample
--enable swscale
--disable swscale-alpha
--disable txtpages
--disable vaapi
--disable vda
--disable vdpau
--disable videotoolbox
--enable yasm

Unfortunately, I am not able to generate a build in Windows with this parameters.
Could any of the experts in this group be so kind to point me to how to get such a binary for Windows, so I could try to find out where the problem arises (I am suspecting of the --enable avcodec)

Best regards. Good luck out there.

comment:14 by Carl Eugen Hoyos, 4 years ago

You seem to misunderstand: A company decided to not only violate the copyright of the FFmpeg developers but to also violate the jpeg standard. It is most likely possible to reverse-engineer what they did but this is not related to the FFmpeg configure options.

in reply to:  14 ; comment:15 by HappyCow, 4 years ago

Replying to cehoyos:

You seem to misunderstand: A company decided to not only violate the copyright of the FFmpeg developers but to also violate the jpeg standard. It is most likely possible to reverse-engineer what they did but this is not related to the FFmpeg configure options.

Wow! Thanks. But how could it be? The IjkPlayer libs are (or claim to be) totally open source ​https://github.com/bilibili/ijkplayer based on FFmpeg n3.4, with MediaCodec, VideoToolbox support, with no changes or whatsoever to that code.
Some people have even recompiled them independently for other versions (even Ffmpeg n4) changing the build parameters slightly according to their needs and (in Android and IOS at least) they still work.
I cannot think they dare to change the source code of such a fine library [not even to mention the JPEG standard, what would also imply that the chips manufacturers also did so]
As you can tell I am not even well versed on that subject but I would rather point to some type of hardware-acceleration issue or some implication of the cross-platform compiling, or...
You are probably right but that really surprises me.

in reply to:  15 ; comment:16 by Balling, 4 years ago

Replying to HappyCow:

Wow! Thanks. But how could it be? The IjkPlayer libs are (or claim to be) totally open source ​https://github.com/bilibili/ijkplayer based on FFmpeg n3.4, with MediaCodec, VideoToolbox support, with no

Wow, 2.6k issues.

in reply to:  16 comment:17 by HappyCow, 4 years ago

Replying to Balling:

Replying to HappyCow:

Wow! Thanks. But how could it be? The IjkPlayer libs are (or claim to be) totally open source ​https://github.com/bilibili/ijkplayer based on FFmpeg n3.4, with MediaCodec, VideoToolbox support, with no

Wow, 2.6k issues.

Thank you very much. 2556 issues are quite a few, but none of them seem (at first sight) to relate to tampering with the standards, but with pointer conversions, technical issues and #4481 and #4439 in particular point to solving similar problems with mjpeg and rtp as the ones analyzed here...
Anyway, you got me convinced! No easy recipe for this problem. Thanks

comment:18 by Carl Eugen Hoyos, 4 years ago

Analyzed by developer: set

Sorry for my bad interpretation of the ticket, I had originally found an Android binary but no source code!

The issue is that the restart interval in the attached dump (and according to the original description also in the rtp header) is 0x3de (990) for the first frame and has similar values between 986 and 1026 for the remaining frames. If I force the restart interval for each frame to 0x28 (40) in the decoder, the stream plays fine.
Looking at RFC 2435 I don't see an obvious bug in libavformat/rtpdec_jpeg.c and to the best of my knowledge there is no bug related to the restart interval in FFmpeg's jpeg decoder indicating that in the end, my interpretation may not have been so far off.
I don't know how this issue can be fixed reliably.

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 20f310fd70..9a4c1b8b2b 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1802,6 +1802,7 @@ static int mjpeg_decode_dri(MJpegDecodeContext *s)
     if (get_bits(&s->gb, 16) != 4)
         return AVERROR_INVALIDDATA;
     s->restart_interval = get_bits(&s->gb, 16);
+s->restart_interval = 40;
     s->restart_count    = 0;
     av_log(s->avctx, AV_LOG_DEBUG, "restart interval: %d\n",
            s->restart_interval);

comment:19 by Carl Eugen Hoyos, 4 years ago

If anybody has access to such a camera, please provide the console output with the following patch:

diff --git a/libavformat/rtpdec_jpeg.c b/libavformat/rtpdec_jpeg.c
index b32d074136..2ebe341236 100644
--- a/libavformat/rtpdec_jpeg.c
+++ b/libavformat/rtpdec_jpeg.c
@@ -242,6 +242,7 @@ static int jpeg_parse_packet(AVFormatContext *ctx, PayloadContext *jpeg,
             return AVERROR_INVALIDDATA;
         }
         dri = AV_RB16(buf);
+        av_log(ctx, AV_LOG_ERROR, "dri: %x F/L/Restart Count: %x \n", dri, AV_RB16(buf + 2));
         buf += 4;
         len -= 4;
         type &= ~0x40;

in reply to:  19 ; comment:20 by HappyCow, 4 years ago

Replying to cehoyos:

If anybody has access to such a camera, please provide the console output with the following patch:

Wow again! Great work and great support. If it works you will become a hero for quite a bunch of people who are longing for this!
I am travelling right now but in six days I will be able to do what you request [I will have to learn how to build the binaries in Windows, which I hope it will not be an impossible task even though I have almost zero experience on that]
Best regards and thank you again.

in reply to:  20 comment:21 by Carl Eugen Hoyos, 4 years ago

Replying to HappyCow:

I will have to learn how to build the binaries in Windows, which I hope it will not be an impossible task even though I have almost zero experience on that

I prefer WSL, others use MSYS.

by HappyCow, 4 years ago

Attachment: ffmpeg_patch.txt​ added

console ouput for patched ffmpeg

in reply to:  19 comment:22 by HappyCow, 4 years ago

Replying to cehoyos:

If anybody has access to such a camera, please provide the console output with the following patch:

Congratulations cehoyos! Your patch went straight to the point. Now it works like a charm.
I am attaching for your information the requested output [ffmpeg_patched.txt], obtained through the command:
ffmpeg -loglevel debug -i rtsp://192.168.1.1:7070/webcam -f matroska - 2> ffmpeg_patch.txt | ffplay -
(ffmpeg.exe is your patched one, and ffplay.exe is the standard version, because I was not able to compile ffplay with your changes)
Thank you very much. Best regards. Let us know if we can help with anything else.

comment:23 by HappyCow, 4 years ago

Hello again everybody!
The patch works very fine for the decoding of the stream [I suppose that one day it will be included in the standard version as a new feature or enhancement], but somehow the device also requires a periodic custom RTCP_RR to keep the connection alive (just 6 bytes of data)
This is achieved by sending a RTCP receiver report.
IjkPlayer library just uses a native SendRtcpRrData(byte[]) that in fact is actually a call to either an standard ffmpeg ff_rtp_check_and_send_back_rr(), ff_rtp_send_rtcp_feedback(), or ff_rtp_send_punch_packets() (I am unsure about that)
So, I will need to send/interleave periodically these tiny custom RR packets. I have searched quite a few places on the internet but have not been able to find a practical example of how to generate/send custom RTCP receiver reports with ffmpeg, either in C++ or any other language.
How could this be achieved in Windows? (I am used the dll's generated with your patch wrapped around the standard python PyAV module)
I would appreciate very much your suggestions or help on this

comment:24 by Balling, 3 years ago

Status: new → open
Summary: ffplay does'nt play mjpeg stream → ffplay doesn't play mjpeg stream

in reply to:  18 comment:25 by Obadiah, 2 years ago

Replying to Carl Eugen Hoyos:

Sorry for my bad interpretation of the ticket, I had originally found an Android binary but no source code!

The issue is that the restart interval in the attached dump (and according to the original description also in the rtp header) is 0x3de (990) for the first frame and has similar values between 986 and 1026 for the remaining frames. If I force the restart interval for each frame to 0x28 (40) in the decoder, the stream plays fine.
Looking at RFC 2435 I don't see an obvious bug in libavformat/rtpdec_jpeg.c and to the best of my knowledge there is no bug related to the restart interval in FFmpeg's jpeg decoder indicating that in the end, my interpretation may not have been so far off.
I don't know how this issue can be fixed reliably.

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 20f310fd70..9a4c1b8b2b 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1802,6 +1802,7 @@ static int mjpeg_decode_dri(MJpegDecodeContext *s)
     if (get_bits(&s->gb, 16) != 4)
         return AVERROR_INVALIDDATA;
     s->restart_interval = get_bits(&s->gb, 16);
+s->restart_interval = 40;
     s->restart_count    = 0;
     av_log(s->avctx, AV_LOG_DEBUG, "restart interval: %d\n",
            s->restart_interval);

I have a similar camera with the same RTSP URL and whose app also uses IjkPlayer. Without the patch applied, FFMPEG throws me "Could not find codec parameters for stream 0". Testing the patch, I got the same error the original poster had without the patch:

mjpeg_decode_dc: bad vlc: 0:0
error dc
error y=1 x=0

I could also get a green screen as a video. Could it be that the interval for my camera is slightly different than the one proposed (40)? Can you explain how did you find that value?

by Obadiah, 2 years ago

Attachment: log.txt​ added

comment:26 by Obadiah, 2 years ago

I've attached the output of the following command as ​https://trac.ffmpeg.org/attachment/ticket/8211/log.txt

ffmpeg -loglevel debug -i rtsp://192.168.1.1:7070/webcam -f matroska - 2> ffmpeg_patch.txt | ffplay -
Version 0, edited 2 years ago by Obadiah (next)
Note: See TracTickets for help on using tickets.