| >Could you send us (or make available) a copy of the program and
>the file you generated.
You can copy over the following files:
http://www.zk3.dec.com/~june/camera (camera executable)
http://www.zk3.dec.com/~june/camera.c (camera source code)
http://www.zk3.dec.com/~june/temp.jpg (sample output)
http://www.zk3.dec.com/~june/snapx (snapper executable)
You can reproduce the problem by running "camera -snapshot",
or by running "camera" and then running snapx and clicking
on the camera button, or by running "camera" and then
sending a SIGUSR1 signal to the camera process by using the
kill command. All of these will cause a snapshot of the
current frame to be captured and saved to a still JPEG file,
temp.jpg by default. Passing that JPEG file to xv or djpeg
will cause those programs to complain of extraneous bytes in
the JPEG file.
Thanks for the help, please let me know if you need more info.
Rich
|
| The AV321 and associated software return the data in a format which
is easy to stuff directly into a Motion JPEG AVI file and isn't very
much like the JFIF format that XV et al want. I'm actually surprised
that it's decoding at all without some additional work.
One big difference is that for AVI file usage, the Huffman tables
are fixed and implicit in the file, whereas for still image applications,
the tables are typically included at the beginning of the file.
0xffd9 is actually the EOI (End of Image) marker, so it sounds like
there's trailing junk after the end of the compressed data. If true,
this would be a bad thing because it's wasted bandwidth (which adds
up pretty quickly at 30 fps).
Below is an outline of the data format for an individual frame from
the Microsoft doc which describes the format. We restrict the color
space to YCbCR and the chroma subsampling to 2H x 1V. The quantization
tables (DQT) get sent with each frame, but you don't see any
DHT segments for the Huffman tables like you typically would.
X'FF', SOI
X'FF', APP0' 12, "AVI1", 0, 0, 0, 0, 0, 0, 0, 0
X'FF', DRI, length, restart interval
length Lq = 65 for JPEG_Y or
130 for JPEG_YCbCr or JPEG_RGB
Precision, Table ID, Pq = 0, Tq = 0
DQT data [64]
[If 3 components
Precision, Table ID, Pq = 0, Tq = 1
DQT data [64]
]
X'FF', SOF0, length,
Sample Precision P = 8
Number of lines Y = biHeight
Sample per line X = biWidth
Number of components Nc = 1 or 3
YCbCr RGB
1st Component parameters C1= 1 =Y 4 =R
2nd Component parameters C2= 2 =Cb 5 =G
3rd Component parameters C3= 3 =Cr 6 =B
X'FF', SOS, length,
Number of components Ns = 1 or 3
YCbCr RGB
1st Component parameters C1= 1 =Y 4 =R
2nd Component parameters C2= 2 =Cb 5 =G
3rd Component parameters C3= 3 =Cr 6 =B
*
*
*
X'FF', EOI
|
| Thanks for the info!
>The AV321 and associated software return the data in a format which
>is easy to stuff directly into a Motion JPEG AVI file and isn't very
>much like the JFIF format that XV et al want. I'm actually surprised
>that it's decoding at all without some additional work.
>
>One big difference is that for AVI file usage, the Huffman tables
>are fixed and implicit in the file, whereas for still image applications,
>the tables are typically included at the beginning of the file.
Is that true even if JPEG_DIB compression is used instead of MJPG_DIB?
If I use MJPG_DIB and write out the frame, xv does complain about the
Huffman table being missing, but using JPEG_DIB the resulting image
seems to work correctly with the exception of the extraneaous bytes
message.
>0xffd9 is actually the EOI (End of Image) marker, so it sounds like
>there's trailing junk after the end of the compressed data. If true,
>this would be a bad thing because it's wasted bandwidth (which adds
>up pretty quickly at 30 fps).
Actually, the error message says that there are extraneous bytes
*before* the EOI, not after it. Any ideas?
Rich
|