#2270 closed defect (needs_more_info)
unable to play certain MJPEG files - file format detection
Reported by: | Jan.Spurny | Owned by: | beastd |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | 1.2 | Severity: | normal |
Keywords: | mjpeg | Cc: | |
Blocked By: | Blocking: | ||
Reproduced by developer: | no | Analyzed by developer: | no |
Description
Summary of the bug:
I have a lot of MJPEG
files which I play using mplayer
and convert using mplayer
from my program. Today I've encountered a strange bug - one file won't play in mplayer
, but avplay
can play it without problems and when I cut it into JPEG
files, they all looked just fine.
Those MJPEG
files have following "format":
--myboundary Content-Type: image/jpeg Timestamp: 2016-01-18T00:10:49.088262 Content-Length: 17243 ......JFIF. ... --myboundary Content-Type: image/jpeg ...
When I try to play it in mplayer
, nothing happens and no error (i.e. nonzero return code) is produced, so not only it won't play, but also I can't detect this failure from my program:
$ mplayer raw.mjpeg; echo "return code: $?" MPlayer 1.2-4.9.2 (C) 2000-2015 MPlayer Team Playing raw.mjpeg. libavformat version 56.40.101 (internal) Exiting... (End of file) return code: 0
When I forced the lavf
demuxer, then I got an error:
$ mplayer -demuxer +lavf raw.mjpeg; echo "return code: $?" MPlayer 1.2-4.9.2 (C) 2000-2015 MPlayer Team Playing raw.mjpeg. libavformat version 56.40.101 (internal) libavformat file format detected. MPlayer interrupted by signal 11 in module: demux_open - MPlayer crashed by bad usage of CPU/FPU/RAM. Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash. - MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and won't help unless you provide this information when reporting a possible bug. return code: 1
I run it again with debugging and this is what I think is relevant:
$ mplayer -msglevel all=9 -demuxer +lavf raw.mjpeg ... Playing raw.mjpeg. get_path('sub/') -> '/home/someuser/.mplayer/sub/' [file] File size is 6248059 bytes STREAM: [file] raw.mjpeg STREAM: Description: File STREAM: Author: Albeu STREAM: Comment: based on the code from ??? (probably Arpi) libavformat version 56.40.101 (internal) Configuration: --enable-gpl --enable-postproc Probing mpjpeg score:-541478725 size:2048 Probing mpjpeg score:-541478725 size:6144 Probing mpjpeg score:-541478725 size:14336 Probing mpjpeg score:-541478725 size:30720 Probing mjpeg score:25 size:63488 Probing mpjpeg score:-541478725 size:63488 Probing mjpeg score:25 size:129024 Probing mpjpeg score:-541478725 size:129024 Probing mjpeg score:25 size:260096 Probing mpjpeg score:-541478725 size:260096 Probing mjpeg score:25 size:522240 Probing mpjpeg score:-541478725 size:522240 Probing mjpeg score:25 size:1046528 Probing mpjpeg score:-541478725 size:1046528 Probing mjpeg score:25 size:2095104 Probing mpeg score:25 size:2095104 Probing mpjpeg score:-541478725 size:2095104 Probing mjpeg score:25 size:2097152 Probing mpeg score:25 size:2097152 Probing mpjpeg score:-541478725 size:2097152 LAVF_check: no clue about this gibberish! libavformat file format detected. s->pos=200000 newpos=0 new_bufpos=0 buflen=0 MPlayer interrupted by signal 11 in module: demux_open ...
It seems to me mplayer
can't decide it it's a MPEG
or MJPEG
(both have score 25).
The error is the same when I force the codec too:
$ mplayer -msglevel all=9 -demuxer +lavf -vc +ffmjpeg raw.mjpeg ...
All those commands (even with forced lavf
demuxer and ffmjpeg
codec) works without any problems with most of my others MJPEG
files. Probably some JPEG
s inside that problematic MJPEG
may look like MPEG
data and "format-detecting" algorithm gets confused..
How to reproduce:
Unfortunately, I can't reproduce it. Most MJPEG
files plays without any problems and I don't see anything special about files which don't (I have only one so far).
Furthermore, the files are from security cameras and unfortunately, I'm not permitted to show them here.
But I would be glad to try and test anything anyone would suggest or provide any additional information which would help to clarify the problem here.
Mplayer version: 1.2-4.9.2
Change History (3)
comment:1 by , 9 years ago
Severity: | blocker → normal |
---|
comment:2 by , 9 years ago
Resolution: | → needs_more_info |
---|---|
Status: | new → closed |
comment:3 by , 9 years ago
Since any MJPEG sample with this problem would likely come from the same
security camera, I don't think I'll ever be able to provide a sample, so
I tried a different approach - I opened that MJPEG file in vim and started
to chop off JPEG segments until it played - and I think I found the problem - the problematic JPEG segment started with headers:
--myboundary Content-Type: image/jpeg Timestamp: 2016-01-18T00:10:55.329643 Content-Length: 17300
but when I exported the JPEG data segment, it was 25806 bytes long - which
is quite different from given Content-Length
of 17300 and it can't be opened
with any tool I tried.
In my original report, I wrote that all jpegs looked fine - and that's
clearly not the case - at that time, I checked only the first few hundreds of
JPEGS.. so I missed this one, which was almost at the end of the file..
Therefore I think it really isn't a mplayer bug, since there is an invalid
JPEG segment..
I wondered however, if this could be viewed as "one invalid frame" in a long
video, which should probably just throw some error or warning, but should
be played anyway - so I tried to fabricate a simple MJPEG with
one faulty frame, but no matter what I did with the faulty JPEG frame,
the result was still playable, even if it glitched or stopped and
printed an error on faulty frame.
Anyway, it doesn't seem to be relevant to mplayer so I won't reopen.
Replying to Jan.Spurny:
Please reopen this ticket if you can provide a sample.