[FFmpeg-trac] #5023(avformat:reopened): Can no longer read mjpeg from Mobotix camera

[FFmpeg]

#5023: Can no longer read mjpeg from Mobotix camera
-------------------------------------+-------------------------------------
             Reporter:  hackeron     |                    Owner:
                 Type:  defect       |                   Status:  reopened
             Priority:  important    |                Component:  avformat
              Version:  git-master   |               Resolution:
             Keywords:  mjpeg        |               Blocked By:
  mpjpeg regression                  |
             Blocking:               |  Reproduced by developer:  1
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by barsnick):

 Replying to [comment:47 smbz]:
 > At the point when avio_seek() is called, there is not enough data in the
 buffer to seek back by the correct amount, so the call fails.

 I ran across this issue thanks to this question on the ffmpeg-user mailing
 list, which also references a Mobotix camera:
 http://ffmpeg.org/pipermail/ffmpeg-user/2019-May/044412.html

 I found a public stream and could reproduce the behavior.

 I did an independent analysis of the issue, and came to exactly the same
 conclusion: ffmpeg is overreading one of the frames, due to failure to
 seek back.

 This can be confirmed by evaluating the {{{avio_seek()}}} return value and
 adding a warning on failure. The warning will pop up right when ffmpeg
 terminates due to the parsing error.


 > There is a call to ffio_ensure_seekback() which looks like it's meant to
 ensure that it is always possible to seek back by this amount, but from
 what I can tell this will work only at the beginning of the stream (i.e.
 for probing or headers) and not mid-stream.  Is anyone able to confirm
 that?

 My take is that {{{ffio_ensure_seekback(s->pb, read_chunk)}}}, where it's
 currently placed, only makes sure that the first chunk is rewindable. This
 needs to be done for every subsequent chunk fetch as well. I dropped (or
 rather moved) that line and instead changed the while condition:
 {{{
         while ((ret = ffio_ensure_seekback(s->pb, read_chunk - remaining)
 >= 0) && (ret = av_append_packet(s->pb, pkt, read_chunk - remaining)) >=
 0) {
 }}}

 And suddenly, decoding the stream works perfectly (at least as far as I
 expect from any mpjpeg stream).

 I can propose a patch to ffmpeg-devel, but if anyone wants to confirm and
 commit my fix before that, I'll happily take the credit. ;-)

--
Ticket URL: <https://trac.ffmpeg.org/ticket/5023#comment:48>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker