Now I'm extracting the tables starting with FFDB and adding them in
doSpecialFrameHandling(). What Q value should I use? I have used 255 to
indicate that each frame could have different tables.
2010/10/27 Cristiano Belloni <bell...@imavis.com>
> Il 27/10/2010 09:32, Francisco Feijoo ha scritto:
>
> 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?.
>
>
> Q factor is 255 if the quantization tables are dynamic. You got to extract
> the quantization tables parsing the JPEG header and looking for the "DQT"
> marker(s), [0xFF 0xDB as far as I remember]
>
>
>
>
> 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
> listlive-de...@lists.live555.comhttp://lists.live555.com/mailman/listinfo/live-devel
>
>
>
> --
> Belloni Cristiano
> Imavis Srl.
> www.imavis.com
> bell...@imavis.com <//bell...@imavis.com>
>
> _______________________________________________
> live-devel mailing list
> live-devel@lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
--
Francisco Feijoo
Software Engineer
J2K Video Limited
T: +34 654967246
E: franci...@j2kvideo.com
W: www.j2kvideo.com
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
