Well, I've been slamming my head against this all night, so it's time to ask for help... Having gotten together a reasonably decent port of what I thought was the whole API to the Ogg Way, complete with Ogg mem management and bitpacking, I started digging deeper in the code... only to find that it looks like I only have a middle stream handler. The encode and decode code both assume that everything is magically initialized; encode writes no header or codec-specifics setup, and decode seems to want everything preparsed and setup so that it can launch into the first video packet. I can't find anything that does header parsing, format identification, initial stream setup, etc... every time I think I found what I was looking for... nope, it sucks in a prepopulated stream specification of some sort. Can Dan or someone else point me to where the very first stages of writing out the stream / reading in the stream really are? [Too fried to continue tonight; this was the brick that finally did me in. I can barely focus on the text] Monty --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'theora-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
I have been working with the vp32 code for a couple of months, so I can try to answer. Hope I am not wrong and I understood your question, but parsing of the header and stream identification is probably not done at the codec level. I think it is up to the VFW or QT playback engines, and they call the codec to query its capabilities and ask for compressed/decompressed bags of bytes in a format that was agreed upon during the codec initialization phase. It is my understanding that data flow is more or less like this during an AVI playback session: 1) AVI engine/libraries opens the file. 2) AVI engine parses the file, finds the video and audio streams 3) It finds a video stream with the vp31 FOURCC code, tries to find a registered codec in the system to handle the stream 4) Now the codec is loaded by the AVI engine, which also queries the codecs for its capabilities, request a given output format, etc. 5) The AVI engine starts passing compressed bags of bytes to the codec (with some extra information to aid the decompression), and receives decompressed data in response. Seeking in the stream is handled by the AVI engine. I believe a similar sequence takes place during a compression sequence, so the AVI engine (or the QT engine, depending on which codec you are building) is actually the responsible for writing the final stream, including headers and indexing information. Not sure if this helps. How does it work in Ogg? Regards, Mauricio Piacentini Tabuleiro <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'theora-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
This is an accurate assessment of the situation wrt the VFW and QT VP3 codecs.
There is no file format or stream handling code per se in the codecs themselves;
they simply take a bunch of pixels and return a bucket of bits, or vice versa.
It is the calling application's responsibility to open the file, parse the
headers, etc.
This harks back to our discussion of toolchains. Do you want to convert an AVI
file into OGG format? If so, we will need to get you AVI parsing code, which
you won't find in the codec source. However, if you just want to add VP3
compression support to an existing encoding tool, you should be able to call the
compress code directly, put the bits in your OGG file, and reverse the process
on playback.
-----Original Message-----
From: Tabuleiro [mailto:beta@tabuleiro.com]
Sent: Mon 9/16/2002 10:11 AM
To: theora-dev@xiph.org
Cc:
Subject: Re: [theora-dev] Can't find the setup code
I have been working with the vp32 code for a couple of months, so I can
try
to answer. Hope I am not wrong and I understood your question, but
parsing
of the header and stream identification is probably not done at the
codec
level. I think it is up to the VFW or QT playback engines, and they call
the
codec to query its capabilities and ask for compressed/decompressed bags
of
bytes in a format that was agreed upon during the codec initialization
phase. It is my understanding that data flow is more or less like this
during an AVI playback session:
1) AVI engine/libraries opens the file.
2) AVI engine parses the file, finds the video and audio streams
3) It finds a video stream with the vp31 FOURCC code, tries to find a
registered codec in the system to handle the stream
4) Now the codec is loaded by the AVI engine, which also queries the
codecs
for its capabilities, request a given output format, etc.
5) The AVI engine starts passing compressed bags of bytes to the codec
(with
some extra information to aid the decompression), and receives
decompressed
data in response. Seeking in the stream is handled by the AVI engine.
I believe a similar sequence takes place during a compression sequence,
so
the AVI engine (or the QT engine, depending on which codec you are
building)
is actually the responsible for writing the final stream, including
headers
and indexing information.
Not sure if this helps. How does it work in Ogg?
Regards,
Mauricio Piacentini
Tabuleiro
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'theora-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject
is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 5710 bytes
Desc: winmail.dat
Url :
http://lists.xiph.org/pipermail/theora-dev/attachments/20020916/a67b836e/winmail-0001.bin