[FFmpeg-trac] #5023(avformat:open): Can no longer read mjpeg from Mobotix camera
FFmpeg
trac at avcodec.org
Sat Nov 21 23:53:40 CET 2015
#5023: Can no longer read mjpeg from Mobotix camera
-------------------------------------+-------------------------------------
Reporter: hackeron | Owner:
Type: defect | Status: open
Priority: important | Component: avformat
Version: git-master | Resolution:
Keywords: mjpeg | Blocked By:
mpjpeg regression | Reproduced by developer: 1
Blocking: |
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by w3sip):
I wouldn't call it a regression -- a far-end bug had been previously
masked by a bug in demux selection.
Without seeing full HTTP response, I can only guess why this stream worked
before, but it’s an invalid mpjpeg stream. The code (both original, and
following the patch) requires each body part to be accompanied by Content-
Type and Content-Length, and the attached dump shows Content-Length
available on the first part, but not on the subsequent ones.
My best guess is this: prior to the patch, for a variety of reasons (all
of which had been patched), mjpeg demux could be selected instead of
mpjpeg (the old version logs confirm it is being the case). MJPEG demux is
more tolerant — it pretty much looks for jpeg header, consumes the jpeg
and generates logs noise for the following unconsumed data (such as
multipart headers), until it finds next jpeg in the stream. After the
patch, the stream uses mpjpeg demux, based on HTTP response's Content-Type
and the first correct frame headers, but later on breaks due to missing
Content-Length.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/5023#comment:6>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list