Ogg issueshttps://gitlab.xiph.org/xiph/ogg/-/issues2017-08-26T14:29:54Zhttps://gitlab.xiph.org/xiph/ogg/-/issues/1484[libogg] _os_body_expand uses realloc2017-08-26T14:29:54Zps790809[libogg] _os_body_expand uses reallocrealloc takes too much time when os->body_data is big, because of copying memory.
static void _os_body_expand(ogg_stream_state *os,int needed){
if(os->body_storage<=os-...realloc takes too much time when os->body_data is big, because of copying memory.
static void _os_body_expand(ogg_stream_state *os,int needed){
if(os->body_storage<=os->body_fill+needed){
os->body_storage+=(needed+1024);
os->body_data=_ogg_realloc(os->body_data,os->body_storage*sizeof(*os->body_data));
}
}
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1311Ogg Container Format Wastes Memory2017-08-26T14:29:55Zjoe_somebodyOgg Container Format Wastes MemoryCurrently the maximum page size is 65307 determined by a limit of 255 page segments, times 255 bytes ...
I propose that the page_segments/segment table is replaced by a 16 bit unsigned integer, which won't be any larger in the case of s...Currently the maximum page size is 65307 determined by a limit of 255 page segments, times 255 bytes ...
I propose that the page_segments/segment table is replaced by a 16 bit unsigned integer, which won't be any larger in the case of small pages, but will be smaller in all cases where a page size exceeds 254 bytes. It will also allow a page size of up to 65535 bytes. Maybe this could be internally identified as ogg2?
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1120calling _clear functions with already cleared structures results in crash2017-08-26T14:29:55ZGitlab Botcalling _clear functions with already cleared structures results in crashWhen _clear functions (from all ogg libraries, not just libogg) are called with already cleared ogg structures they crash.
It would be very good if i could call, for example, theora_info_clear() with an already cleared theora_info struc...When _clear functions (from all ogg libraries, not just libogg) are called with already cleared ogg structures they crash.
It would be very good if i could call, for example, theora_info_clear() with an already cleared theora_info structure. It simplifies the creation of code paths for error handling, presence or not of certain logic bitstreams and probably other reasons.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/545start-time granulepos2010-10-27T13:35:26ZArc Rileystart-time granulepos```
libogg2 lacks ability to handle start-time granulepos, as is used by
discontinuous codecs. the library needs a way to be told that a stream is
discontinuous for ogg_stream_state to handle the proper packet<->page mapping
of these...```
libogg2 lacks ability to handle start-time granulepos, as is used by
discontinuous codecs. the library needs a way to be told that a stream is
discontinuous for ogg_stream_state to handle the proper packet<->page mapping
of these fields.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/544ogg_buffer_create missing from ogg2/ogg.h2010-10-27T13:35:06ZArc Rileyogg_buffer_create missing from ogg2/ogg.h```
ogg_buffer_create is needed to pass new buffers to the bitpacker.
ogg_buffer_state *ogg_buffer_create(void);
``````
ogg_buffer_create is needed to pass new buffers to the bitpacker.
ogg_buffer_state *ogg_buffer_create(void);
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/489libogg2 threading doesn't work on FreeBSD2010-10-27T13:32:37ZArc Rileylibogg2 threading doesn't work on FreeBSD```
On FreeBSD there is no -lpthread, we use -pthread instead. libogg2 does not work with -pthread, which means threading needs to be disabled on BSD* platforms for it to compile.
``````
On FreeBSD there is no -lpthread, we use -pthread instead. libogg2 does not work with -pthread, which means threading needs to be disabled on BSD* platforms for it to compile.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/485libogg2: direct access to change page header fields2010-10-27T13:31:16ZArc Rileylibogg2: direct access to change page header fields```
Alot of the uses I've found for libogg1 (py-ogg1) have been repairing Ogg streams, extracting
one logical bitstream from an Icecast archive, or other things which could take place entirely
within ogg_sync_state (to get ogg_page obj...```
Alot of the uses I've found for libogg1 (py-ogg1) have been repairing Ogg streams, extracting
one logical bitstream from an Icecast archive, or other things which could take place entirely
within ogg_sync_state (to get ogg_page objects), then editing the header fields of the pages to
change the CONT/BOS/EOS flags, granulepos, serialno, etc.
In one case, the Indymedia global radio stream at http://liveradio.indymedia.org/ is mixed on
the server using Python code that takes several different sources (live, playlist, etc) and mixes
them based on a schedule. This uses py-ogg1 to make the stream being sent to Icecast legal
and sequential serialno's, especially when the source streams get chopped off midway.
This is also useful for intentionally creating mangled test streams for testing codec software,
Icecast, etc.
With libogg2 moving to ogg_references instead of character buffers for the ogg_page header
and body fields, this is no longer possible. ogg_reference is not currently exposed, nor are
there functions for editing these values, so the only way to edit this data would be to send the
ogg_page objects into a second ogg_sync_state buffer then use ogg_sync_bufferout before
editing the fields, then into a third ogg_sync_state buffer to turn it back into an ogg_page.
Bug 484 ( http://bugs.xiph.org/show_bug.cgi?id=484 ), the declaired but not defined
ogg_page_getbuffer, may make this easier. But it would still involve re-importing the edited
data into another ogg_sync_state buffer.
It should be noted that, without the ability to edit the ogg_page header/body contents, having
ogg_page_checksum_set exposed serves no purpose.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/343[RFE] Use ISO C99 types if available2006-06-12T11:04:43Zbero[RFE] Use ISO C99 types if available```
Your configure scripts go through great lengths to figure out the proper variable
types for 8, 16, 32 and 64 bit signed and unsigned; ISO C99 compilers (e.g. gcc
3.x) are required to define them in <stdint.h>, saving quite a lot of...```
Your configure scripts go through great lengths to figure out the proper variable
types for 8, 16, 32 and 64 bit signed and unsigned; ISO C99 compilers (e.g. gcc
3.x) are required to define them in <stdint.h>, saving quite a lot of trouble.
Attaching a patch that uses stdint.h if available and falls back to the old way of
doing things if the compiler is too old.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/26'win32/*.bat' do not handle SRCROOT long path names with spaces correctly2006-06-12T10:56:22Ztom'win32/*.bat' do not handle SRCROOT long path names with spaces correctly```
as an example:
set SRCROOT=e:\Xiph CVS\
call build_vorbis_static.bat
produces the error:
cvs==. was unexpected at this time.
and does *not* set %SRCROOT% to any value
resolution:
replace the line:
if .%SRCROOT%==. set SRC...```
as an example:
set SRCROOT=e:\Xiph CVS\
call build_vorbis_static.bat
produces the error:
cvs==. was unexpected at this time.
and does *not* set %SRCROOT% to any value
resolution:
replace the line:
if .%SRCROOT%==. set SRCROOT=c:\src
with the line:
if ".%SRCROOT%"=="." set SRCROOT=c:\src
```starclassstarclasshttps://gitlab.xiph.org/xiph/ogg/-/issues/25'win32/*.bat', harcoded path to 'vcvars32.bat' might be a bad idea2009-04-19T20:39:35Ztom'win32/*.bat', harcoded path to 'vcvars32.bat' might be a bad idea```
'win32/*.bat' all contain:
call "c:\program files\microsoft visual studio\vc98\bin\vcvars32.bat"
maybe this should be replaced with:
call "%MSDevDir%\..\..\vc98\bin\vcvars32.bat"
or (if we assume it is pathed, since later on we s...```
'win32/*.bat' all contain:
call "c:\program files\microsoft visual studio\vc98\bin\vcvars32.bat"
maybe this should be replaced with:
call "%MSDevDir%\..\..\vc98\bin\vcvars32.bat"
or (if we assume it is pathed, since later on we see just 'msdev' without a
path):
call vcvars32.bat
```starclassstarclass