Opened 9 years ago

Closed 9 years ago

#4840 closed defect (fixed)

MJPEG streaming issues

Reported by: Alex Agranovsky Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: mpjpeg
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Symptom:

  • mpjpeg demux is not selected, resulting in multipart MIME headers to be read as part of the frame
  • when selected, it fails to parse the headers in some cases
  • when it provides a jpg frame, the frame fails to be decoded

Scenario:

  • test environment consists of ffserver serving 2 jpg files over HTTP
  • client code reads the input via HTTP URI and reads compressed frames using av_read_frame (no decoding is performed at that stage)
  • frame data is passed further down the pipeline, where it is decoded using avcodec_decode_video2
  • version of the library used: 2.8

My take on what is going on:
1) When matching based on MIME type occurs in libavformat/format.c, two strings are compared literally. So, if MIME type is provided as 'multipart/x-mixed-replace;boundary=ffserver', it will never match the 'multipart/x-mixed-replace;boundary', which is part of MPJPEG demux configuration.
2) Multipart header parsing will fail for a few reasons:

  • trailing/leading space within HTTP header will throw the parser off
  • empty line following the MIME headers will be parsed as a header, and cause a failure

3) decoding seems to fail because of how EOI (d9) marker is handled. I have little knowledge of JPG structure, but the attached change makes a difference between failure and success. Doesn't make the change correct, but at least it pinpoints the cause.

I'm attaching two files:
1) Proposed patch -- if needed, can be submitted via pull request.
2) x.jpg -- saved JPG frame which fails to decode

Attachments (3)

x.jpg (4.4 KB ) - added by Alex Agranovsky 9 years ago.
Example of frame which fails to be decoded by MJPEG decoder
patch.diff (3.1 KB ) - added by Alex Agranovsky 9 years ago.
Proposed patch
ffmpegTest.zip (8.2 KB ) - added by Alex Agranovsky 9 years ago.
Complete package to reproduce the JPG decoding problem

Download all attachments as: .zip

Change History (9)

by Alex Agranovsky, 9 years ago

Attachment: x.jpg added

Example of frame which fails to be decoded by MJPEG decoder

by Alex Agranovsky, 9 years ago

Attachment: patch.diff added

Proposed patch

in reply to:  description comment:1 by Carl Eugen Hoyos, 9 years ago

Keywords: mpjpeg added
Version: 2.7unspecified

Replying to w3sip:

1) Proposed patch -- if needed, can be submitted via pull request.

Unfortunately, patches are ignored on this bug tracker, please either:

  • send your patches to the FFmpeg development mailing list where they can be reviewed

or

  • explain here on the bug tracker how the issue you see can be reproduced, this should include the failing command line including the complete, uncut console output tested with current FFmpeg git head. If the issue is not reproducible with the command line tools, please provide source code that allows to reproduce it.

2) x.jpg -- saved JPG frame which fails to decode

Sorry if I misunderstand but the attached jpg decodes fine with current FFmpeg git head, do I miss something?

comment:2 by Alex Agranovsky, 9 years ago

1) Regarding reproducing the demux issue: too much code to show it here. I'll submit the patch on the mailing list.
2) Regarding the decoding of the attached frame: I'm attaching a package that can reproduce the issue on trunk, 2.8, 2.7.2, using the following steps:

  • use buildFFMPEGMac.sh to build ffmpeg (as attached it builds master)
  • use Makefile to build test.cpp
  • run 'test x.jpg'

I'm seeing the following output with the above three versions:

Starting up
[mjpeg @ 0x1004800] No JPEG data found in image
Decode result: -1094995529

by Alex Agranovsky, 9 years ago

Attachment: ffmpegTest.zip added

Complete package to reproduce the JPG decoding problem

comment:3 by Alex Agranovsky, 9 years ago

Okay -- figured out the decoding problem ... seems like I've had some leftover code in codec context initialization, which set width/height to invalid values. Without these lines, the frame seems to decode fine.

The demux still needs to be looked at, but that can be discussed on the mailing list.

comment:4 by Carl Eugen Hoyos, 9 years ago

Is there still an issue reproducible concerning this ticket or have all patches been applied?

in reply to:  4 comment:5 by Alex Agranovsky, 9 years ago

Replying to cehoyos:

Is there still an issue reproducible concerning this ticket or have all patches been applied?

Yep, all good by now.

comment:6 by Carl Eugen Hoyos, 9 years ago

Component: undeterminedavformat
Resolution: fixed
Status: newclosed
Version: unspecifiedgit-master

Thank you for the report and the patches!
Applied as 53e8bef25a78457e4339e353568004f03b8a2396 and earlier commits.

Note: See TracTickets for help on using tickets.