[FFmpeg-trac] #8211(avformat:new): ffplay does'nt play mjpeg stream
FFmpeg
trac at avcodec.org
Thu Mar 18 14:39:14 EET 2021
#8211: ffplay does'nt play mjpeg stream
-------------------------------------+------------------------------------
Reporter: anhsoft | Owner:
Type: enhancement | Status: new
Priority: wish | Component: avformat
Version: git-master | Resolution:
Keywords: rtsp mjpeg | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+------------------------------------
Comment (by HappyCow):
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.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/8211#comment:10>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list