[vorbis-dev] vorbis.dll; bug in vorbis_dsp_clear?;mc support

[Michael Smith]

At 04:03 PM 2/15/02 +0100, you wrote:
>Hi,
>
>
>| However, if you call the various vorbis_*_clear() functions incorrectly
>| (in the wrong order, for example) various things can happen - usually
>| just memory leaks, but other things might be possible. 
>
>This is the order in the vorbis.dll:
>
> ogg_stream_clear( &pStream->os );
> vorbis_block_clear( &pStream->vb );
> vorbis_dsp_clear( &pStream->vd );
> vorbis_comment_clear(&pStream->vc);
> vorbis_info_clear(&pStream->vi);

This looks ok. Not sure what your problem is, then.

>| If you can show us your code (the bits using libvorbis, that is), we
>| may be able to help you further. 
>
>Well, it is on CVS (CDEXOS project), but I could also send you the modified version of the vorbis.dll, though my mods shouldn't touch anything critical. I just thought people won't like it if I attach anything here. [file is vorbisdll.c] I merged that CVS file with libvorbis RC3 code and getting this trouble. I also sent A.Faber my sources of the modded files (not latest, but there is not much change). Nevertheless I didn't get much replies from him.
>
>HeadAC3he doesn't use libvorbis, as it is much too complicated for me. I use the vorbis.dll which has a lame_enc.dll like interface, which uses the libvorbis. So in fact you don't need sources from HeadAC3he to debug. (BTW, I tried to run just vbencopen and vbenclose, *without* actually doing any encoding and got that error).

Ok, if you can point me towards those sources (for the vorbis dll you're
using), I'll take a look when I can.

>
>BTW, could you by chance tell me what dwInfoMode is good for (in VB_CONFIG sturct)? You can set it to
>#define VB_MODE_A 100
>#define VB_MODE_B 200
>#define VB_MODE_C 300
>#define VB_MODE_D 400
>#define VB_MODE_E 500
>
>and I can't actually see where it is used.

Well, we didn't write your vorbis.dll (whatever that is), but this is
probably something from several releases back, when we only had hard-
coded modes, rather than flexible vbr mode generation as is done now.

>
>| There are a couple of major things here - first is defining channel
>| mappings. Right now, there's nothing to say "channel 0 is front-left, 
>| 1 is front-right, 2 is centre", etc. So for useful multi-channel support,
>| that has to be defined somehow - but we haven't decided exactly how
>| to do that. 
>
>I just wanted to ask for this, as esp for decoding purposes it it critical to know which channel belongs to which speaker.

We know - but it hasn't been done yet. 

>
>| The second is making the encoder use the channel coupling features 
>| intelligently for these mappings - right now, it only knows about
>| stereo files (anything else is treated as a set of independent 
>| channels) - this doesn't break anything, it just means that the bitrate
>| is higher than it needs to be.
>
>Gosh, I hoped it tried to at least use stereo coupling on 6ch files. Would it help if for the time being the possibility would be there to say, eg. use stereo coupling for L and R and for SL and SR, so that C and LFE are treated as independant channels? This is of course far from optimal, but I guess better then current situation.

Well, it could be done - but without the channel mapping stuff I mentioned
above, how do we know which channel is which? We don't - really we need
to define that stuff first, THEN make the encoder intelligently use
channel coupling. It WILL get done...

Michael

<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 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.