Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2020-02-27T04:36:19Zhttps://gitlab.xiph.org/xiph/theora/-/issues/1465fix configure.ac to work with cross scenario for libvorbis2020-02-27T04:36:19ZRobert Schwebelfix configure.ac to work with cross scenario for libvorbisThe current test in configure.ac mixes up two different methods (hand
written plus pkg-config). This patch changes the mechanics towards
proper pkg-config usage. In return, we get a cleaned up cross scenario
with no build-system leakage....The current test in configure.ac mixes up two different methods (hand
written plus pkg-config). This patch changes the mechanics towards
proper pkg-config usage. In return, we get a cleaned up cross scenario
with no build-system leakage.
This patch fixes the vorbis test.https://gitlab.xiph.org/xiph/theora/-/issues/1081Add user-lockable frame memory to theora2017-08-20T01:57:18ZGitlab BotAdd user-lockable frame memory to theora
## SUMMARY
Currently it is not generally possible to display ('play') theora content without
copying decoded frames at least twice - once from libtheora memory to user memory, and once from user memory to display memory.
This proposal...
## SUMMARY
Currently it is not generally possible to display ('play') theora content without
copying decoded frames at least twice - once from libtheora memory to user memory, and once from user memory to display memory.
This proposal suggests the addition of two API calls that add the concept of a "shared" buffer, allocated and freed by the user but lockable by libtheora. With such a buffer, one of these copies can be eliminated.
## THE PROBLEM
libtheora provides decoded frames in memory allocated and owned by libtheora (through the theora_yuv_out function call). libtheora does not guarantee that this memory is valid following subsequent theora_packet_in calls. Hence, the player application must either copy the decoded frame directly to the screen, or copy it to a buffer for later display.
However, it is undesirable to copy the frame directly to the screen, as this will lead either to unpredictable display times or an inefficient use of available time (the player must either display the frame as soon as it is ready or wait until the display time of the frame arrives). Hence, players must in general incur the cost of copying the frame to a temporary buffer owned by the player application.
## THREE PROPOSED SOLUTIONS
(1) One solution would be to add a single API call to libtheora:
```
theora_unlock_yuv_buffer(theora *, buffer *)
```
libtheora would then avoid freeing frames that have not been explicitly unlocked by the user. This approach has disadvantages:
* the behaviour of the library changes (legacy applications will stop working due to memory leaks)
* an additional function call per frame is required for normal operation of the library
(2) These disadvantages can be mitigated by requiring the user to lock buffers
first:
```
theora_lock_yuv_buffer(theora_state *, yuv_buffer *)
theora_unlock_yuv_buffer(theora_state *, yuv_buffer *)
```
libtheora would exhibit the same behaviour in the absence of these functions being
called, but would not free frames that have been locked by the user until subsequently unlocked.
(3) Another approach is to allow user-allocation of buffers:
```
theora_user_yuv_out(theora_state *, yuv_buffer *)
int theora_user_buffer_is_freeable(theora_state *, yuv_buffer *)
```
In this case, the user can provide user-allocated memory into which theora decodes the frame, and theora can indicate that a user-allocated frame should not be freed (for example, if the frame is a reference frame). Normal operation of the library is unchanged.
This approach has the additional advantage that the user can tailor memory use to the application and environment - restricted-memory embedded systems can avoid malloc and free, while directX-based systems can provide memory already allocated as a directX texture.
## RECOMMENDATION
Given that this problem exists, and is fixable with minimal API modification and no perceived change for existing applications, I would suggest that we consider fixing it. I currently favour approach 3, as it is more flexible, however this approach also means more work for the application designer that wishes to use the new feature.
https://gitlab.xiph.org/xiph/py-ogg2/-/issues/892[PATCH] vorbis-python memory leak2017-08-12T12:58:23Ztony[PATCH] vorbis-python memory leakThere's a memory leak in the python-vorbis destructor. Also, vcedit.c is much older than the version in vorbis-tools/vorbiscomment.There's a memory leak in the python-vorbis destructor. Also, vcedit.c is much older than the version in vorbis-tools/vorbiscomment.Arc RileyArc Rileyhttps://gitlab.xiph.org/xiph/opus/-/issues/2026Opus DTX issue report2017-10-21T19:37:03ZgmarianoOpus DTX issue reportHello:
We noticed that opus reconstructed noise is pulsing with a 400ms pattern when dtx is enabled in silk mode. This is independent of the background noise level and is found with speech + non-speech period test files, as well as vari...Hello:
We noticed that opus reconstructed noise is pulsing with a 400ms pattern when dtx is enabled in silk mode. This is independent of the background noise level and is found with speech + non-speech period test files, as well as variable level noise-only test files. This issue can be easirly reproduced with opus v1.1 using this command:
./opus_demo voip 16000 1 25000 –dtx input.bin output.bin
We have attached a .wav file with the first channel as the input reference noise signal and the second channel as the opus codec output using the opus_demo application. It does not look like this has been reported already. We would like your feedback.
Thank you,
Gonzalo Mariano and Pascal Huart
Cisco Systems
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/2001Opus encoder produces 40/60ms CBR packets with excess padding2017-10-21T19:37:03ZMark HarrisOpus encoder produces 40/60ms CBR packets with excess paddingThe packets produced by `opus_multistream_encode()` when encoding 40ms or 60ms CELT or Hybrid packets for a single stream contain 4 to 6 bytes of padding, which could have been used to add 1 or 2 bytes to each frame.
For example:
```
$ ...The packets produced by `opus_multistream_encode()` when encoding 40ms or 60ms CELT or Hybrid packets for a single stream contain 4 to 6 bytes of padding, which could have been used to add 1 or 2 bytes to each frame.
For example:
```
$ opusenc --hard-cbr --bitrate 31.5 --framesize 60 comp48s.wav out.opus
Encoding using libopus 1.1-42-ge1f8462 (audio)
-----------------------------------------------------
Input: 48kHz 2 channels
Output: 2 channels (2 coupled)
60ms packets, 31.5kbit/sec CBR
Preskip: 312
Encoding complete
-----------------------------------------------------
Encoded: 1 minute and 30.84 seconds
Runtime: 2 seconds
(45.42x realtime)
Wrote: 362224 bytes, 1514 packets, 97 pages
Bitrate: 31.4667kbit/s (without overhead)
Instant rates: 31.4667kbit/s to 31.4667kbit/s
(236 to 236 bytes per packet)
Overhead: 1.36% (container+metadata)
$
```
The above command produces 236-byte packets (31.467 kb/s), each containing the 2 bytes required for a code 3 packet, three 76-byte frames, and 6 bytes of padding (including the padding length byte). Instead of the 6 bytes of padding, each frame could have contained 78 bytes of data.
If the multistream API is not used, `opus_encode()` does produce packets containing three 78-byte frames for this same bitrate and frame size. However, for some reason it also adds 1 byte of padding to each packet, which causes it to slightly exceed the target bitrate.
```
$ opus_demo audio 48000 2 31500 -cbr -framesize 60 comp48s.pcm out.pcm
libopus 1.1-42-ge1f8462
Encoding 48000 Hz input at 31.500 kb/s in auto mode with 2880-sample frames.
average bitrate: 31.613 kb/s
maximum bitrate: 31.600 kb/s
active bitrate: 31.600 kb/s
bitrate standard deviation: 0.000 kb/s
$
```Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/ogg/-/issues/2228vorbisfile.c function ov_pcm_total add const to OggVorbis_File *2017-08-26T14:29:54Zirov13vorbisfile.c function ov_pcm_total add const to OggVorbis_File *subjsubjMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1917ogg.m4 sets OGG_LIBS to incorrect path on some 64-bit distros2017-08-26T14:29:54ZAdam Spiersogg.m4 sets OGG_LIBS to incorrect path on some 64-bit distrosSome distros such as openSUSE use /usr/lib64 rather than /usr/lib, but ogg.m4 does not allow for this. I notice that whoever packaged ogg.m4 for openSUSE opted for hacking a patch into the spec file which is only applied on x86_64:
htt...Some distros such as openSUSE use /usr/lib64 rather than /usr/lib, but ogg.m4 does not allow for this. I notice that whoever packaged ogg.m4 for openSUSE opted for hacking a patch into the spec file which is only applied on x86_64:
https://build.opensuse.org/package/view_file?expand=1&file=libogg.spec&package=libogg&project=openSUSE%3AFactory
https://build.opensuse.org/package/view_file?expand=1&file=lib64.dif&package=libogg&project=openSUSE%3AFactory
Personally it's better if ogg.m4 itself is fixed, because then it works even when not building rpms. I'll attach a suggested patch ...
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1850Inconsistent types for bitstream serial number2017-08-26T14:29:54ZAndrew ChurchInconsistent types for bitstream serial numberDifferent types are used in different places to store an Ogg bitstream serial number: at least int, long, and ogg_uint32_t. The use of int may cause incorrect behavior in environments where int is 16 bits, and the mix of signed and unsi...Different types are used in different places to store an Ogg bitstream serial number: at least int, long, and ogg_uint32_t. The use of int may cause incorrect behavior in environments where int is 16 bits, and the mix of signed and unsigned types is the root cause of issue 1838.
I can see a couple of approaches here:
- Unify everything to "long", and replace the hack in Tremor that mixed 32-bit and 64-bit values with a separate flag variable (which IMHO would be a good idea in any case).
- Unify everything to "ogg_int32_t". This would probably be significantly more invasive, and would break binary compatibility for the ogg_stream_state structure in environments with 64-bit longs. I don't currently know enough about the Ogg/Vorbis code to say whether the latter point is a problem in practice.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1674OGG RFCs in libogg package don't meet Debian DFSG2017-08-26T14:29:54ZMonty MontgomeryOGG RFCs in libogg package don't meet Debian DFSGDebian strips the Ogg RFCs out of the Deb packages due to the RFCs not meeting DFSG.
relevant info:
http://wiki.debian.org/NonFreeIETFDocuments
Debian strips the Ogg RFCs out of the Deb packages due to the RFCs not meeting DFSG.
relevant info:
http://wiki.debian.org/NonFreeIETFDocuments
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/1891fix autoconf so configure --enable/--disable-foo is tri-state2017-11-05T22:14:58ZThomas B. Rückerfix autoconf so configure --enable/--disable-foo is tri-stateCurrently you can --enable-foo, but if foo headers are not there it will just switch off 'foo', instead of failing due to 'foo headers missing'.Currently you can --enable-foo, but if foo headers are not there it will just switch off 'foo', instead of failing due to 'foo headers missing'.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/cortado/-/issues/1911Cortado doesn't work on Mac with Oracle JRE7 update 92017-08-21T19:26:29ZAndre KlapperCortado doesn't work on Mac with Oracle JRE7 update 9[ Upstreamed from https://bugzilla.wikimedia.org/show_bug.cgi?id=41274 ]
Playback never starts and the Cortado reports:
ERROR, Not allowed
https://upload.wikimedia.org/wikipedia/commons/3/36/Mirror-Induced-Behavior-in-the-Magpie-%28Pic...[ Upstreamed from https://bugzilla.wikimedia.org/show_bug.cgi?id=41274 ]
Playback never starts and the Cortado reports:
ERROR, Not allowed
https://upload.wikimedia.org/wikipedia/commons/3/36/Mirror-Induced-Behavior-in-the-Magpie-%28Pica-pica%29-Evidence-of-Self-Recognition-pbio.0060202.sv009.ogv...
Full Cortado play log:
http://bug-attachment.wikimedia.org/attachment.cgi?id=11217
(The stacktrace has to do with a cache file being in Mac OS X quarantine (mistake in the Oracle installer it seems))
(The oracle java plugin doesn't work with Chrome for Mac btw, since Chrome is 32bit only and JRE7 for mac is 64 bit only.)https://gitlab.xiph.org/xiph/cortado/-/issues/1756Potential lack of corresponding source code for Cortado 0.6.0 official binaries2017-08-21T19:26:29ZGitlab BotPotential lack of corresponding source code for Cortado 0.6.0 official binariesFor the cortado-ov-stripped-0.6.0.jar binary, which is dated March 19, 2010 and which is available at the http://downloads.xiph.org/releases/cortado/ URL, it is not clear as to whether one can easily obtain the corresponding source code ...For the cortado-ov-stripped-0.6.0.jar binary, which is dated March 19, 2010 and which is available at the http://downloads.xiph.org/releases/cortado/ URL, it is not clear as to whether one can easily obtain the corresponding source code for the binary (such as would be required for license compliance when redistributing the binary on physical media.)
Although there is a cortado-0.6.0.tar.gz archive which is also dated March 19, 2010 and which is available at the http://downloads.xiph.org/releases/cortado/ URL, the contents of this archive do not seem to mention the Proguard software, even though the official cortado binary was supposedly processed with the Proguard software after the binary was built. As such, it seems unclear as to whether this archive file would constitute the complete corresponding source code for the official cortado-ov-stripped-0.6.0.jar binary.
At the http://git.xiph.org/?p=cortado.git;a=commit;h=d8611fc913f69fe8f25a7276c9a08c9fd4a6e726 URL, there is a "snapshot" option which, from what it appears, will download the source code in the source repository up to and including the "0.6.0" tag. Although the downloaded source includes a "cortado.proguard" file, there does not seem to be any other mention of the Proguard software, and trying to compile the source produced Cortado binaries that did not appear to have been processed with the Proguard software. (In addition, the latest entry in the "Changelog" file dated back to May 28, 2007.)
At the http://git.xiph.org/?p=cortado.git;a=commit;h=21fc8dd2cc0dc558ed44422044d3d055fe7e0114 URL, it appears than one can download a more up-to-date snapshot of the source code. As of December 1, 2010, however, the snapshot of the code does not seem to mention the Proguard software outside of the "cortado.proguard" file. (On a side note, with this soure code on the Ubuntu Linux platform with Apache Ant version 1.7.1 and javac version 1.6.0_18, it appeared that the "ant stripped" option failed to build the applets when invoked for the first time, though it worked when invoked a second time. From what one remembers, though, the binaries had not been processed with the Proguard software.)
Possible recommendations:
1. With the source code, the "README" and "HACKING" files should mention the use of the Proguard software, as well as any additional post-processing that should be done in order to regenerate the official binaries.
2. If possible, the build scripts would automatically process the binaries with the Proguard software, or at the very least would mention the Proguard software (as well as any additional post-processing that should be done.)
3. Files that contain version histories or which refer to a date on which something was done should be updated if necessary.
4. It might not hurt to include copies of the GPLv2 and LGPLv2 license files in the Cortado source collection.https://gitlab.xiph.org/xiph/cortado/-/issues/1722readme and websites should suggest <object> rather than <applet>2017-08-21T19:26:29Zleighmanreadme and websites should suggest <object> rather than <applet><applet> is now deprecated.
The readme in particular should demonstrate ways of embedding the applet using the <object> tag.<applet> is now deprecated.
The readme in particular should demonstrate ways of embedding the applet using the <object> tag.https://gitlab.xiph.org/xiph/cortado/-/issues/1714Cortado doesn't allow playback actions, says "Not Allowed"2017-08-21T19:26:29ZNilson MoraisCortado doesn't allow playback actions, says "Not Allowed"When I load my page at first time Cortado loads stream fine, but if I call functions like doPlay or restart it says "Not Allowed", I'm using the same stream. All of it are in the same domain.
Ubuntu 10.04
Chrome 5.0.375.125 and Firefox ...When I load my page at first time Cortado loads stream fine, but if I call functions like doPlay or restart it says "Not Allowed", I'm using the same stream. All of it are in the same domain.
Ubuntu 10.04
Chrome 5.0.375.125 and Firefox 3.6.8
Java Sun 1.6.0_20
Cortado 0.6.0
My Applet:
<applet code='com.fluendo.player.Cortado.class' archive='http://theora.org/cortado.jar' width='400' height='300'>
<param name='url' value='http://myserver:8000/stream.ogv' />
<param name='bufferSize' value='100' />
</applet>
Js code:
document.applets[0].restart();
and doPlay.
https://gitlab.xiph.org/xiph/cortado/-/issues/1708WebM/VP8 support in Cortado2017-08-21T19:26:29ZPhilip HeronWebM/VP8 support in CortadoAny thoughts on adding VP8 support to Cortado? There are already Java Matroska demuxers in the wild, but I'd imagine it would be a fairly big job porting the decoder itself.Any thoughts on adding VP8 support to Cortado? There are already Java Matroska demuxers in the wild, but I'd imagine it would be a fairly big job porting the decoder itself.https://gitlab.xiph.org/xiph/cortado/-/issues/1664Cortado getPlayPosition() fails2017-08-21T19:26:29ZPaulCortado getPlayPosition() failsVersion: cortado_latest.jar at 2010/03/21, 10:00 am EST
Browser: Firefox 3.5.8
HTML: See below
Result:
Video (Big Buck Bunny) starts, can be RESTART-ed, SEEK(0.5)-ed, but SHOW fails, as "player.getPlayPosition()" is not recognized a...Version: cortado_latest.jar at 2010/03/21, 10:00 am EST
Browser: Firefox 3.5.8
HTML: See below
Result:
Video (Big Buck Bunny) starts, can be RESTART-ed, SEEK(0.5)-ed, but SHOW fails, as "player.getPlayPosition()" is not recognized as a function.
HTML follows...
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
<meta http-equiv="pragma" content="no-cache">
<title>Test.html</title>
<script language="javascript">
function restart() {
player = document.getElementById("ogv") ;
player.restart() ;
}
function seek() {
player = document.getElementById("ogv") ;
player.doSeek(0.5) ;
}
function show() {
player = document.getElementById("ogv") ;
pos = player.getPlayPosition() ;
alert("pos = " + pos) ;
}
</script>
</head>
<BODY bgcolor="#ffffcc">
CORTADO 2010/03/21 -
<button onClick="restart()">Restart</button> OK
<button onClick="seek()">Seek(0.5)</button> OK
<button onClick="show()">Show</button> NG!
<br>
<br>
<center>
<applet id="ogv" code="com.fluendo.player.Cortado.class" MAYSCRIPT
archive="cortado_latest.jar"
width="854" height="480" >
<param name="url" value="test.ogv"/>
<param name="keepAspect" value="true"/>
<param name="autoPlay" value="true"/>
<param name="statusheight" value="20"/>
<param name="seekable" value="true"/>
<param name="debug" value="3"/>
</applet>
</center>
</body>
</html>
...
Please help!https://gitlab.xiph.org/xiph/cortado/-/issues/1647no plackback for cortado 0.5.12017-08-21T19:26:29ZRandall Smith no plackback for cortado 0.5.1cortado 0.5.1 shows only a still image or sometimes a few frames of a video.
Code tested with:
```
<html><body>
<applet code="com.fluendo.player.Cortado.class" archive="http://theora.org/cortado.jar" width="320" height="240">
<p...cortado 0.5.1 shows only a still image or sometimes a few frames of a video.
Code tested with:
```
<html><body>
<applet code="com.fluendo.player.Cortado.class" archive="http://theora.org/cortado.jar" width="320" height="240">
<param name="url" value="http://upload.wikimedia.org/wikipedia/commons/c/c9/Varanus_komodoensis1.ogg"/>
</applet>
</body></html>
```
Output from "About"
This is Cortado 0.5.1.
Brought to you by Wim Taymans.
(C) Copyright 2004,2005,2006 Fluendo
Built on 2009-11-05 20:59:19 GMT
Built in stripped mode.
Built from git branch Xiph, revision 0.5.1
Running on Java VM 1.6.0_16 from Sun Microsystems Inc.
Using the javax.sound backend.https://gitlab.xiph.org/xiph/cortado/-/issues/1628Cortado should save volume setting2017-08-21T19:26:29Zrigo_lsCortado should save volume settingWhen choosing a volume setting on a video and later open another OGG video, the
volume goes back to maximum volume.
Steps to reproduce:
1. go to http://tinyvid.tv/
2. Open a video
3. Lower volume setting
4. Open a new video
What happen...When choosing a volume setting on a video and later open another OGG video, the
volume goes back to maximum volume.
Steps to reproduce:
1. go to http://tinyvid.tv/
2. Open a video
3. Lower volume setting
4. Open a new video
What happens: video has maximum volume again
What should happen: The volume setting should stay the same as it was set the
first time when the video player was used.
Version used:
Firefox 3.6 Beta 5
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b5) Gecko/20091204
Firefox/3.6b5
Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2300Write album art to encoded .ogg file2024-01-18T19:54:06ZtmpltWrite album art to encoded .ogg fileI use oggenc to create Ogg Vorbis files to save space on my mobile devices. While oggenc seems to write most metadata to the created .ogg file, the album art isn't copied. Could this be implemented?
CheersI use oggenc to create Ogg Vorbis files to save space on my mobile devices. While oggenc seems to write most metadata to the created .ogg file, the album art isn't copied. Could this be implemented?
CheersMichael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2295oggdec error - seems to be endianness problem2018-01-22T04:18:25ZMikeoggdec error - seems to be endianness problemI am trying to use ezstream to send a vorbis ogg music file to icecast. The error simplifies down to this - when I use the following two commands to manually decode and then encode an ogg file, the resulting test.ogg file plays correctl...I am trying to use ezstream to send a vorbis ogg music file to icecast. The error simplifies down to this - when I use the following two commands to manually decode and then encode an ogg file, the resulting test.ogg file plays correctly
oggdec -R -b 16 -e 0 -s 1 -o file.raw file.ogg
oggenc -r -B 16 -C 2 -R 44100 --raw-endianness 0 -q 5 -o test.ogg file.raw
But if I try to pipe the output of oggdec into the input of offenc as ezstream would do, the resulting file is only static. The defective pipe command is
oggdec -R -b 16 -e 0 -s 1 -o - file.ogg | oggenc -r -B 16 -C 2 \
-R 44100 --raw-endianness 0 -q 5 -o test.ogg -
However if I reverse the endianness in the pipe command of oggdec to -e 1 the resulting test.ogg plays properly. Somewhere in the handling of stdout the endianness is being reversed. This only happens when piping.
Version info:
linux 4.6.2
vorbis-tools-1.4.0
libvorbis-1.3.5
libogg-1.3.2
icecast-2.4.3
ezstream-0.6
Hardware is an intel i5 based system.
Michael SmithMichael Smith