Now, i want to get set of jpegs in callback(I use BufferCB), how can i do it
and how to save callback data to jpeg files?It is possible?
Yes, the samples should be plain JPEGs, so all you should have to do is
just save the whole sample to disk as a file.
--
New to newsgroups? Read: http://dev.6581.com/newsgroups.html
> On Wed, 6 Apr 2005 22:45:01 -0700, "Artem Omelianchuk"
> <ArtemOme...@discussions.microsoft.com> wrote:
>
>>Hello,
>>I build graph: Capture Filter->MJPEG Compressor Filter->Sample Graber
>>Filter-> Null Filter.
>>
>>Now, i want to get set of jpegs in callback(I use BufferCB), how can i do it
>>and how to save callback data to jpeg files?It is possible?
>
> Yes, the samples should be plain JPEGs, so all you should have to do is
> just save the whole sample to disk as a file.
Isn't there an extra JPG "file header" that needs to be written? Sorry,
just having flashbacks of MJPEG IP cameras.
>>>Hello,
>>>I build graph: Capture Filter->MJPEG Compressor Filter->Sample Graber
>>>Filter-> Null Filter.
>>>
>>>Now, i want to get set of jpegs in callback(I use BufferCB), how can i do it
>>>and how to save callback data to jpeg files?It is possible?
>> Yes, the samples should be plain JPEGs, so all you should have to do is
>> just save the whole sample to disk as a file.
>Isn't there an extra JPG "file header" that needs to be written? Sorry,
>just having flashbacks of MJPEG IP cameras.
I haven't used the MS MJPEG compressor specifically, but what I've seen,
and what I do personally, is just use regular JPEGs for the samples.
I.e., those samples can be written directly to a file. The MS MJPEG
decompressor certainly accepts that, so I assume that's what the MS
MJPEG compressor spits out as well.
> Isn't there an extra JPG "file header" that needs to be
> written?
Maybe you are referring to the JFIF header usually present
in JPEG image files? That header is not required to decode a
JPEG stream, so a good JPEG/MJPEG decoder should be able to
do without and, if present and not required, a
JPEG-compliant decoder should skip it as if it weren't there
because of the syntax it uses.
--
// Alessandro Angeli
// MVP :: Digital Media
// a dot angeli at psynet dot net
> Chris P. [MVP] wrote:
>
>> Isn't there an extra JPG "file header" that needs to be
>> written?
>
> Maybe you are referring to the JFIF header usually present
> in JPEG image files? That header is not required to decode a
> JPEG stream, so a good JPEG/MJPEG decoder should be able to
> do without and, if present and not required, a
> JPEG-compliant decoder should skip it as if it weren't there
> because of the syntax it uses.
Right, that's the one. I realize it isn't there for a JPEG stream, but
thought it would be good practice to add it when writing an individual
image file, like a still capture. It sounded like the OP wanted to create
a set of jpeg files like image001.jpg, image002.jpg etc.
>> Maybe you are referring to the JFIF header usually
>> present in JPEG image files? That header is not required
>> to decode a JPEG stream, so a good JPEG/MJPEG decoder
>> should be able to do without and, if present and not
>> required, a JPEG-compliant decoder should skip it as if
>> it weren't there because of the syntax it uses.
>
> Right, that's the one. I realize it isn't there for a
> JPEG stream, but thought it would be good practice to add
> it when writing an individual image file, like a still
> capture. It sounded like the OP wanted to create a set
> of jpeg files like image001.jpg, image002.jpg etc.
Adding the JFIF header requires writing a few fixed bytes
before the actual JPEG:
http://netghost.narod.ru/gff/graphics/summary/jfif.htm
http://www.w3.org/Graphics/JPEG/
where the values for { Units, Xdensity, Ydensity,
XThumbnail, YThumbnail } can just be set to { 1, 72, 72, 0,
0 }.
I also think so,but it's not. When i try to open file it's fail. Photoshop
writes:"Can't open because SOFn,DQT or DHT JPEGs markers is missing before a
JPEG SOS marker".
I compare this file with real jpeg and notice that instead of JFIF there is
AVI1. And other differents. If you want I can send file to you.
Any ideas?
> I also think so,but it's not. When i try to open file
> it's fail. Photoshop writes:"Can't open because SOFn,DQT
> or DHT JPEGs markers is missing before a JPEG SOS marker".
>
> I compare this file with real jpeg and notice that
> instead of JFIF there is AVI1. And other differents. If
> you want I can send file to you.
If you send one of those extracted JPEGs over, I can take a
look and see what doesn't make them compliant JPEGs.
Then I can only assume that the MS MJPEG decompressor accepts inputs
other than what the MS MJPEG compressor spits out, because I'm just
using whole JPEGs. However, as far as I know there is no MJPEG standard,
and I'm not sure if the specifics of the MS MJPEG compressor is
documented anywhere.
> Then I can only assume that the MS MJPEG decompressor
> accepts inputs other than what the MS MJPEG compressor
> spits out, because I'm just using whole JPEGs. However,
> as far as I know there is no MJPEG standard, and I'm not
> sure if the specifics of the MS MJPEG compressor is
> documented anywhere.
http://www.nomadelectronics.com/VidCap/capture%20using%20vfw/ODMLFF2.DOC
page 26
To extract valid JPEGS, it looks like you need to
(optionally) prefix each JPEG frame with the JFIF header and
then (mandatory) the byte string MJPGDHTSeg from mmreg.h and
only then the actual sample data.
> I also think so,but it's not. When i try to open file
> it's fail. Photoshop writes:"Can't open because SOFn,DQT
> or DHT JPEGs markers is missing before a JPEG SOS marker".
>
> I compare this file with real jpeg and notice that
> instead of JFIF there is AVI1. And other differents. If
> you want I can send file to you.
That's the least of your worries since 'AVI1' is the APP0
marker which replaces the APP0 'JFIF' and APPn markers are
optional.
The big difference is that the DHT marker that contains the
Huffman table for decoding is missing. This table is fixed
for MJPEG and defined in mmreg.h, according to the OpenDML
specs.
Some reading on the subject:
- JPEG standard (markers are listed in section B.1.1.3):
http://www.w3.org/Graphics/JPEG/itu-t81.pdf
- JFIF standard (JFIF marker at page 5):
http://www.w3.org/Graphics/JPEG/jfif3.pdf
- JFIF, old AVI1 and new AVI1 markers:
http://sourceforge.net/mailarchive/message.php?msg_id=7062286
- ODML standard (MJPEG DIB described at page 26):
http://www.nomadelectronics.com/VidCap/capture using
vfw/ODMLFF2.DOC
So, in the end, you need to find the 0xFF,0xDA SOS marker in
your sample (that's where the image data starts) then write
averything up to that point to the JPEG output stream, then
write the DHT, then write the rest of the sample. The DHT is
exactly the content of the MJPGDHTSeg byte array defined
near the end of mmreg.h.
Let's assume pb points to the sample data and cb is the
sample length in bytes:
int k = 0; while(pb[k] != (char)0xFF || pb[k+1] !=
(char)0xDA) k++;
output(&pb[0],k);
output(MJPGDHTSeg,sizeof(MJPGDHTSeg));
output(&pb[k],cb-k);
If you want, you can also replace the 'AVI1' APP0 with a
'JFIF' APP0, but it is not required (APP0 = 0xFF,0xE0).
>> Then I can only assume that the MS MJPEG decompressor
>> accepts inputs other than what the MS MJPEG compressor
>> spits out, because I'm just using whole JPEGs. However,
>> as far as I know there is no MJPEG standard, and I'm not
>> sure if the specifics of the MS MJPEG compressor is
>> documented anywhere.
>http://www.nomadelectronics.com/VidCap/capture%20using%20vfw/ODMLFF2.DOC
>
>page 26
>
>To extract valid JPEGS, it looks like you need to
>(optionally) prefix each JPEG frame with the JFIF header and
>then (mandatory) the byte string MJPGDHTSeg from mmreg.h and
>only then the actual sample data.
Thanks, I'll have to look through this document.
> Thanks, I'll have to look through this document.
My latest reply to Artem tells the whole story with more
documentation references and detailed instructions, if
you're interested.
>> Thanks, I'll have to look through this document.
>My latest reply to Artem tells the whole story with more
>documentation references and detailed instructions, if
>you're interested.
Yes I am, thank you very much. :) I wrote my own MJPEG compressor and
decompressor, so I haven't looked much into what the MS ones do, except
to check if the MS decompressor handles what I spit out. (Which it does,
so I guess it ignores the header that I don't have.)
> Yes I am, thank you very much. :) I wrote my own MJPEG
> compressor and decompressor, so I haven't looked much
> into what the MS ones do, except to check if the MS
> decompressor handles what I spit out. (Which it does, so
> I guess it ignores the header that I don't have.)
Go figure... it would be interesting to see what samples the
other MJPEG codecs spit out like Morgan-Multimedia.com's,
JPG.com's or MainConcept.com's or the h/w ones like
Matrox.com's...