Thanks for the quick response Ross,
>
> Note that the existing "JPEGVideoRTPSink" code already does this. You should
> not have to reinvent the wheel here.
I think I should explained this better. I don't know how to obtain the qFactor
from one MJPEG image so I'm copying all the values from the original image to
the new header. And then TestJPEGVideoSource::qFactor() returns 255. Maybe
this part is wrong and I need to calculate the Q, but how? is there an example
of this somewhere?.
>
> The JPEG transmitting code ("JPEGVideoSource" and "JPEGVideoRTPSink")
> currently don't support "Restart Marker Headers" (see RFC 2435, section
> 3.1.7). You will need to update the (definition and implementation) of these
> two classes to support them.
Ok, I have been thinking on other possibility. Do you know if is possible to
decode de MJPEG image to get a simpler version and remove the restart marker
headers?
--
Francisco Feijoo
Software Engineer
J2K Video Limited
W: www.j2kvideo.com
El 27/10/2010, a las 02:39, Ross Finlayson escribió:
>> I'm trying to create a rtsp server to stream MJPEG images.
>
> Ugh. JPEG is a *terrible* codec for video streaming.
>
>
>> I have implemented a new TestJPEGFileServerMediaSubsession that creates a
>> TestJPEGVideoRTPSink.
>>
>> In TestJPEGVideoRTPSink::doSpecialFrameHandling I'm adding the quantization
>> tables of the image into the header using setSpecialHeaderBytes
>
> Note that the existing "JPEGVideoRTPSink" code already does this. You should
> not have to reinvent the wheel here.
>
>
>> This is working fine using some JPEG images, but fails with others.
>>
>> I'm testing one image that has the marker 0xFF, 0xDD ( Define Restart
>> Interval) and I think I have to do something else seeing this comment in the
>> code
>>
>> // Note: We assume that there are no 'restart markers'
>>
>> So, what should I do with images containing restart markers and macroblocks?
>
> The JPEG transmitting code ("JPEGVideoSource" and "JPEGVideoRTPSink")
> currently don't support "Restart Marker Headers" (see RFC 2435, section
> 3.1.7). You will need to update the (definition and implementation) of these
> two classes to support them.
> --
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> _______________________________________________
> live-devel mailing list
> live-devel@lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
