RTP JPEG Header Creation Invalid Under Certain Circumstances
|Reported by:||Chris||Owned by:|
|Blocking:||Reproduced by developer:||no|
|Analyzed by developer:||no|
Summary of the bug:
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 */