[FFmpeg-trac] #5975(avformat:new): RTP JPEG Header Creation Invalid Under Certain Circumstances

[FFmpeg]

#5975: RTP JPEG Header Creation Invalid Under Certain Circumstances
-------------------------------------+-------------------------------------
             Reporter:               |                     Type:  defect
  ChrisWard9000                      |                 Priority:  normal
               Status:  new          |                  Version:
            Component:  avformat     |  unspecified
             Keywords:  RTP JPEG     |               Blocked By:
  RTSP                               |  Reproduced by developer:  0
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 Summary of the bug:

 Referencing https://tools.ietf.org/html/rfc2435

 When creating JPEG headers over RTP from a source which includes restart
 markers in the JPEG data, jpeg type 0 and 64 should be treated the
 same(section 3.1.3 "Types 64-127 are the same as types 0-63").
 rtpdec_jpeg.c only treats type 0 correctly. Please note, the example
 code(page 19, MakeHeaders function), contradicts the alterations as
 discussed on page 25, appendix D from rfc2035 and should be ignored!).

 I have many devices from difference manufacturers which have worked fine
 with ffmpeg rtsp streaming, but have recently been working with an encoder
 which produces restart markers within the jpeg data and requires the
 restart marker header(type 64-127) to work as the RFC says and not how
 ffmpeg currently operates.

 How to reproduce:
 {{{
 First a source must be created which requires the restart marker
 header(using jpeg type 64). I am unsure how to create this, as I have a
 device which does this for me. Once this has been created, then attempt to
 stream the RTSP/RTP source with ffplay. The jpeg headers will then be
 invalid with hsamp = 2 and vsamp = 2 causing a failure to fully decode,
 when they should be hsamp = 2 and vsamp = 1.
 }}}

 The change to fix this issue is a one line change, which should treat type
 values 0 and 64 the same on this line(currently line 165 at commit
 b96a6e2024fa2b52d6a2473a7cf16ee20a8ab5c8 in rtpdec_jpeg.c.) I have locally
 made this change and used the resulting libavcodec, and rebuilt VLC and it
 works fine.

 bytestream2_put_byte(&pbc, (2 << 4) | (type ? 2 : 1)); /* hsample/vsample
 */

--
Ticket URL: <https://trac.ffmpeg.org/ticket/5975>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker