MJPEG streaming issues

[Alex Agranovsky]

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

[Alex Agranovsky]

Example of frame which fails to be decoded by MJPEG decoder

[Alex Agranovsky]

Proposed patch

[Carl Eugen Hoyos]

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?

[Alex Agranovsky]

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

[Alex Agranovsky]

Complete package to reproduce the JPG decoding problem

[Alex Agranovsky]

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.

[Carl Eugen Hoyos]

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

[Alex Agranovsky]

Replying to cehoyos:

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

Yep, all good by now.

[Carl Eugen Hoyos]

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