Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#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 JPEGs 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 Jan.Spurny, 9 years ago

Severity: blockernormal

in reply to:  description comment:2 by cehoyos, 9 years ago

Resolution: needs_more_info
Status: newclosed

Replying to Jan.Spurny:

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.

Please reopen this ticket if you can provide a sample.

comment:3 by Jan.Spurny, 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.

Last edited 9 years ago by Jan.Spurny (previous) (diff)
Note: See TracTickets for help on using tickets.