At 12:09 AM 5/1/00 -0700, you wrote:>There was a bug in the new ov_open_callbacks where it would
>not zero out some member variables of the file info struct,
>and if a file was not successfully opened this would cause
>a crash at destruct time. Fixed.
This fixes an unrelated bug, I think (Not a bug I've actually seen, though
- I haven't done any real testing with chained bitstreams) - looks like it
wasn't allocating enough memory for cases where there's more than a
single
logical bitstream here. This also initialises the memory - obviously, this
isn't doing any HARM, but I can't see why it would help. As far as I can
see, the code initialises this memory to 0 in vorbis_comment_init() and
vorbis_info_init() in every possible path, so this just initialises it
twice - not exactly the most efficient method.
Hmm... Potentially, if _get_next_page() in _fetch_headers fails, this might
not be true - I think this would be the correct place to fix this problem,
if that IS where you're seeing failures. Care to give more details?
>
>I've also made some changes so that vorbis will compile
>cleanly under win32 without one having to muck around with it.
>
>I have added a "vorbis_vc6" directory which contains project
>and workspace files for Visual C++ 6. os.h, lpc.c and
>codec.h were changed in minor ways. I am doing a lot of
>development under win32 so I will be maintaining this.
>
>In order to get everything compiling cleanly across both win32
>and linux, I had to add a new file "os_types.h" into the public
>include directory. This contains the defintions of types such
>as int64_t. It was necessary to put that there because
>some of the other public include files use these types.
>
>I could have moved os.h into the public include directory but
>it seemed that os.h includes some things that the user really
>does not need to see, and this will only become more so over
>time. So I made the choice of splitting it into 2 files.
>I am of course open to suggestions if anybody has a better
>solution.
I discussed all this with Monty several weeks ago when we were getting the
original round of win32 fixes in. It was decided that for platforms where
these types weren't defined correctly, the definitions should be made in
that platform's project file/makefile/etc. My win32 build here (VC++ 5)
does this, defining these types within the project file.
It does make the code messier, but it makes the project files simpler -
guess we can wait for Monty to make a decision here.
>
>
>Also in vorbisfile.c, I added that optimization I was
>discussing where a faster sample-conversion loop is used if
>an endian-switch is not needed.
Cool - I was going to do this, but didn't get around to it after some brief
(and far from comprehensive) tests showed that it didn't really make all
that much difference to the speed (surprisingly).
Those loops could be further optimised for more special cases, but I don't
think it's worth doing (again, no noticable speed difference) unless
it's
going to make a real difference. Probably this could be done MUCH faster
with some pretty simple assembly - that's outside the scope of vorbisfile
right now, but it wouldn't be difficult to copy the relevent bits of
ov_read() and write a seperate optimised function to do this inside your
program. I guess doing REAL optimisations on the library internals would be
more useful, though.
Michael
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/