Hi,
I am making good progress on understanding, documenting, and
re-implementing VP3. I have found some more deadwood in the decoder code
and I just wanted to verify that it really has no place:
* Version 3.3 tables: There are 2 sets of VLCs: One for v3.1 and one for
v3.3. The v3.1 set is always selected. Are the v3.3 tables in production,
or will they ever be?
* DC Search Points: VP3 seems determined to predict DC from *something*.
To that end, DCT_decode.c:ReconRefFrames() has code to search through
surrounding fragments in a last ditch effort to find valid fragments from
which to predict DC. While the code is there, DCSearchPointCount is set to
0 (while a legitimate calculation was commented out) which effectively
short-circuits the DC search code. So, no DC searching in this version?
Will it be back in another version?
Thanks...
--
-Mike Melanson
<p><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.
hi mike --> -----Original Message----- > From: Mike Melanson [mailto:melanson@pcisys.net]...> * Version 3.3 tables: There are 2 sets of VLCs: One for v3.1 > and one for > v3.3. The v3.1 set is always selected. Are the v3.3 tables in > production, > or will they ever be?Here's what's happening with that part of the code. This is the one substantial change we've already committed to. The following six tables: QThreshTableV1 DcScaleFactorTableV1 Y_coeffsV1 UV_coeffsV1 Inter_coeffsV1 FrequencyCounts_VP3 (used to be FrequencyCounts_VP31) are now written into and read from the stream header. I think recent CVS reflects this change (I sent Monty a patch a while ago). Monty may change the way these headers work, but in any case these values are now all 'soft' in the sense that the encoder may write any values it wants and the decoder will load & use them. This is in line with the 'make the decoder flexible' philosophy as seen in vorbis. I left the alternate tables in the encoder as a way to roughly test the functionality. This should also be in CVS. If it's there, you should see these lines of code in quant.c: /// dbm -- defined some alternative tables to test header packing: #define NEW_QTABLES 0 #if NEW_QTABLES and similar elsewhere. Hopefully sometime in the future we can redesign the encoder to utilize this functionality to optimize these tables for the particular stream. Note however that if we do that, new streams will no longer be transcodable back to VP3. That's why I've been saying that VP3 is convertible into Theora, but not necessarily vice versa.> > * DC Search Points: VP3 seems determined to predict DC from > *something*.I haven't looked at this part of the code yet. I'll let you know when I do. - dan> To that end, DCT_decode.c:ReconRefFrames() has code to search through > surrounding fragments in a last ditch effort to find valid > fragments from > which to predict DC. While the code is there, > DCSearchPointCount is set to > 0 (while a legitimate calculation was commented out) which effectively > short-circuits the DC search code. So, no DC searching in > this version? > Will it be back in another version? > > Thanks... > -- > -Mike Melanson > > > > --- >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. >--- >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.
It's about 6Kbytes. A typical video keyframe is bigger. It's a similar issue to Vorbis, with the global code tables. I suppose we could put in a "VP3-compat" flag, but it seemed easier to just shove the VP3 tables in if you want them -- among other things, you could remove these tables from the binaries. <p><p>> -----Original Message-----> From: Mike Melanson [mailto:melanson@pcisys.net] > Sent: Monday, February 24, 2003 12:37 PM > To: theora-dev@xiph.org > Subject: RE: [theora-dev] More Missing Pieces > > > On Mon, 24 Feb 2003, Dan Miller wrote: > > > Here's what's happening with that part of the code. This > is the one substantial change we've already committed to. > The following six tables: > > [snip] > > > are now written into and read from the stream header. > > Wow, that seems like a lot of information to stuff into > the stream > header. Will there be a few bits to select legacy VP3 tables > or will the > VP3 tables just have to be transported? A combo VP3/Theora > decoder (like I > will probably end up writing) will have to have the VP3 tables anyway, > > -- > -Mike Melanson > > > --- >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. >--- >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.
> From: Mike Melanson [mailto:melanson@pcisys.net]...> Will the token tables be transported as frequency > histograms as is > done in the current source? That means: > > 80 tables * 32 freqs/table * 2 bytes/freq = 5120 bytes >yes, that's how it's being done. If it isn't checked in, I can send the patch to you.> Okay, I guess I see where you're coming from. If someone were > to try to > encapsulate this data in an AVI, ASF, or MOV file (just in case Ogg > adoption doesn't take off right away), I guess it would need > to go inside > the video header?umm, that's a good question. I guess it's the same problem as with Vorbis; I hadn't really thought about this. I think all these formats have some sort of codec-specific stream header data, don't they?> > > I suppose we could put in a "VP3-compat" flag, but it > seemed easier to just shove the VP3 tables in if you want > them -- among other things, you could remove these tables > from the binaries. > > But there is still the minor issue of compatibility with VP3 > streams which necessitates the inclusion of the classic tables.Only if you want a binary that does both. The cases I'm envisioning would be embedded apps where that probably wouldn't be an issue. -dan> > Thanks... > -- > -Mike Melanson > > --- >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. >--- >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.
structure for Theora data. Something like:> > 2560 signed 16-bit numbers for the 80 histograms (which byte order?) > 64 QThresh table values (8- or 16-bits?) > etc... >This is the code -- functions are called in this order: (again, you should get this from CVS) void write_Qtables(oggpack_buffer* opb) { int x; for(x=0; x<64; x++) { oggpackB_write(opb, QThreshTableV1[x],16); } for(x=0; x<64; x++) { oggpackB_write(opb, DcScaleFactorTableV1[x],16); } for(x=0; x<64; x++) { oggpackB_write(opb, Y_coeffsV1[x],8); } for(x=0; x<64; x++) { oggpackB_write(opb, UV_coeffsV1[x],8); } for(x=0; x<64; x++) { oggpackB_write(opb, Inter_coeffsV1[x],8); } } void write_FrequencyCounts(oggpack_buffer* opb) { int x, y; for(x=0; x<NUM_HUFF_TABLES; x++) { for(y=0; y<MAX_ENTROPY_TOKENS; y++) { oggpackB_write(opb, FrequencyCounts_VP3[x][y], 16); } } }> As an aside, does anyone know how to decode Vorbis audio data > encapsulated within a Quicktime file? Do I need to pull some > information > out of the audio stsd atom? I have a few Vorbis/QT samples > made from the > Heroine Warriors' programs but I have never heard audio from them.not I.> > Thanks... > -- > -Mike Melanson > > > > > --- >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. >--- >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.
hmm... I'm confused. I thought this had been checked in. I'll send a
patch around today.
-----Original Message-----
From: Ralph Giles [mailto:giles@xiph.org]
Sent: Tue 2/25/2003 8:00 AM
To: theora-dev@xiph.org
Cc:
Subject: Re: [theora-dev] More Missing Pieces
On Tuesday, February 25, 2003, at 08:56 am, Arc wrote:
> I think a better question is, why isnt alpha a tarball somewhere and
> CVS
> used for public development, as it's suppost to be.
Well, the alpha tarball should certainly be separate from the cvs
nightly (and tagged in cvs) but my impression was more that there
hasn't been any new work on the theora code. Monty usually checks in
work-in-progress, as he has been on the libogg2-zerocopy branch of the
ogg library. According to the faq this was the part of theora scheduled
for the fall.
-r
--- >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: 4358 bytes
Desc: winmail.dat
Url :
http://lists.xiph.org/pipermail/theora-dev/attachments/20030225/dcccb1ca/winmail-0001.bin
can you describe the playback problem? note you have to recompress, it's not compatible with test streams encoded with alpha 1.0 - dan -----Original Message----- From: Ralph Giles [mailto:giles@xiph.org] Sent: Tuesday, February 25, 2003 7:58 PM To: theora-dev@xiph.org Subject: Re: [theora-dev] More Missing Pieces <p><p>On Tuesday, February 25, 2003, at 03:50 pm, Dan Miller wrote:> hmm... I'm confused. I thought this had been checked in. I'll send a > patch around today.I offered to check this in for Dan, but there turned out to be a playback problem after our discussion on irc, so I want to hold off until I understand the problem. Attached if anyone else wants to play with it. -r --- >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.