[Live-devel] Live555 with ffmpeg's MJPEG codec

[Silvain Beriault]

>
>>
>> "JPEGVideoRTPSink" (which is used by the RTP sender) doesn't 
>> reconstruct the JPEG header.  (Remember that the JPEG header is not 
>> sent in the RTP packet.)  It's the RTP *receiver* 
>> ("JPEGVideoRTPSource" in our case) that reconstructs a JPEG header 
>> (from the parameters in the RTP payload format header).
> If I don't use live555 it works just fine: i.e. encode to a memory 
> block, decode from a memory block.  I tried comparing the original 
> jpeg compressed data with the received data and it seems that the jpeg 
> header is broken. Could it be that JPEGVideoRTPSink fails to 
> reconstruct the original JPEG header for some reason?
>
>
> JPEGVideoRTPSource is what I meant... Anyhow, I'll continue 
> investigate the problem and if i find the solution, I'll post it to 
> the mailing list.

Ok I have performed additional tests and it seems that not all JPEG 
images can be transferred with RFC 2435 (which is what is implemented in 
the JPEGVideoRTPSink/JPEGVideoRTPSource).

To demonstrate this, I am submitting test1_in.jpg and test2_in.jpg which 
are two valid JPEG image (which can be displayed using any jpeg viewer). 
test1_in.jpg was encoded using ffmpeg's mjpeg encoder (with quantizer = 
4). and test2_in.jpg correspond to the same scene but encoded using 
Microsoft Photo Editor (with quality factor = 74). test1_in.jpg and 
test2_in.jpg are inputs to a JPEGVideoSource derived class. On the other 
hand, test1_out.jpg and test2_out.jpg corresponds to the data received 
and reconstructed by a JPEGVideoRTPSource.

We can see that test2_out.jpg is perfectly reconstructed (even if there 
are minor differences between the jpeg header from test2_in.jpg and 
test2_out.jpg). Howerver, test1_out.jpg is not reconstructed correctly. 
Major differences can be observed between the 623 bytes of JPEG header 
of test1_in.jpg and test1_out.jpg. Visually the test1_out.jpg is shifted 
horizontally and the colors are off. The color/luminance problem may be 
attributed to the conversion from the 0..31 quantizer value (ffmpeg 
mjpeg parameter) to the more conventional JPEG's quality factor. 
However, this does not explain why the image is shifted.

All images can be downloaded here: http://www.larus.com/~sberiault/

Any help on that issue is highly appreciated!

Silvain

PS. I am also including "hex" dump of each jpeg file (need to 
right-click and do a "save-as")