Opened 2 years ago

Closed 2 years ago

#4840 closed defect (fixed)

MJPEG streaming issues

Reported by: w3sip 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 w3sip 2 years ago.
Example of frame which fails to be decoded by MJPEG decoder
patch.diff (3.1 KB) - added by w3sip 2 years ago.
Proposed patch
ffmpegTest.zip (8.2 KB) - added by w3sip 2 years ago.
Complete package to reproduce the JPG decoding problem

Download all attachments as: .zip

Change History (9)

Changed 2 years ago by w3sip

Example of frame which fails to be decoded by MJPEG decoder

Changed 2 years ago by w3sip

Proposed patch

comment:1 in reply to: ↑ description Changed 2 years ago by cehoyos

  • Keywords mpjpeg added
  • Version changed from 2.7 to unspecified

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 Changed 2 years ago by w3sip

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

Changed 2 years ago by w3sip

Complete package to reproduce the JPG decoding problem

comment:3 Changed 2 years ago by w3sip

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 follow-up: Changed 2 years ago by cehoyos

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

comment:5 in reply to: ↑ 4 Changed 2 years ago by w3sip

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 Changed 2 years ago by cehoyos

  • Component changed from undetermined to avformat
  • Resolution set to fixed
  • Status changed from new to closed
  • Version changed from unspecified to git-master

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

Note: See TracTickets for help on using tickets.