Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: IETF Opus codec now ready for testing (Read 438274 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

IETF Opus codec now ready for testing

Reply #75 –
Quote from: rt87 on
Cannot open output: No such file or directory[/code]


I got a little too aggressive with some error handling I added.  In any case, fixed and zip file updated.

IETF Opus codec now ready for testing

Reply #76 –
Opus, AoTuV and Apple AAC at ~ 128 kbps http://d.hatena.ne.jp/kamedo2/20120603

Also he has tested Opus 0.9.10 (main branch). Newer exp4 branch should do better.

IETF Opus codec now ready for testing

Reply #77 –

I notice the previous blog entry was them testing at 80kbps a couple of months ago:

http://d.hatena.ne.jp/kamedo2/20120315/1331839849


I notice he uses tvbr for that one and cvbr for 128kbps. I originally thought this was hobbling iTunes by forcing it to be closer to the target bitrate. I thought this might be compensating for the lack of tuning for VBR in this version of Opus. But reading the docs it seems to actually put a *lower* limit of 128kbps on the encoder, which could be considered a benefit for iTunes, and perhaps explains why it's average bitrate is the highest of the three in that test (it's the lowest in the 80kbps test).

IETF Opus codec now ready for testing

Reply #78 –
Is somebody working on a foobar decoder plugin for Opus? I'm aware of a CELT plugin but i'm pretty sure that it will not work with the new bitstream. I like to test it longer with more samples but i don't wan't to decode back to WAV or use the command line decoder for playback.

IETF Opus codec now ready for testing

Reply #79 –
not sure if this is a bug or if it's meant to be, but the current opus-tools ("current" meaning the latest downloadable from people.xiph.org) does not accept piped input.  at least, not in foobar2000.  I had to use the %s for temporary file input instead.  and I'm referring specifically to opusenc.exe...

also, I second the motion for a foobar2000 decoder, but I'm sure it will be available when opus is stable anyway.

IETF Opus codec now ready for testing

Reply #80 –
Quote from: greensdrive on
not sure if this is a bug or if it's meant to be, but the current opus-tools ("current" meaning the latest downloadable from people.xiph.org) does not accept piped input.  at least, not in foobar2000.  I had to use the %s for temporary file input instead.  and I'm referring specifically to opusenc.exe...

also, I second the motion for a foobar2000 decoder, but I'm sure it will be available when opus is stable anyway.


It _should_ accept piped input and does when run in wine. It automatically ignores the wav length.  Is it crashing for you or just giving truncated files?

A foobar2000 decoder won't be available no one creates one.  I'm not aware of anyone working on it. I'd be glad to answer questions / review code to help make that happen. Anyone who works on it should make sure it plays the testvectors at http://people.xiph.org/~greg/opus_testvectors/  (will be posted on the opus site when the set of tests are complete)

IETF Opus codec now ready for testing

Reply #81 –
I have a question about setup_resample() function. It has the following code:

Code: [Select]
    opt->skip+=speex_resampler_get_output_latency(rs->resampler);


Maybe it's better to replace it with speex_resampler_skip_zeros(rs->resampler) ?

IETF Opus codec now ready for testing

Reply #82 –
Quote from: lvqcl on
I have a question about setup_resample() function. It has the following code:
Maybe it's better to replace it with speex_resampler_skip_zeros(rs->resampler) ?


I'd rather not. Why do you ask?

IETF Opus codec now ready for testing

Reply #83 –
get_output_latency() returns rounded value...

For example, if filt_len==128, in_rate==44100 and out_rate==48000 (num_rate=147, den_rate=160):

input latency = filt_len / 2 = 64 samples.
output latency = (filt_len/2)*den_rate/num_rate = 64*160/147 = 69,65986... => 70 samples.

Maybe I'm wrong but IMHO this is the reason of this sub-sample shift (upper part: source, lower - after encoding):



not a big problem, but if it can be easily avoided - why not?

IETF Opus codec now ready for testing

Reply #84 –
Quote from: lvqcl on
get_output_latency() returns rounded value...
[...]
not a big problem, but if it can be easily avoided - why not?


Well, it can't /generally/ be avoided— because it assumes that the encoder and decoder are using the exact same resampling filter (well, at least one with the matching subsample group delays).  Though indeed, it sounds like making input_latency truncate instead of rounding would make it match in opus-tools.  Have you tried that?  Because it's not possible to avoid a subsample delay in the general case I haven't cared much about it, but I agree if it can be trivially fixed without hurting anything else then why not.

As far as skipping zeros go, I plan on eventually making it so that opusenc can have either reverse extrapolated audio or audio from the prior track in the preskip for improved gapless behavior, and having the preskip differ from file to file is the only way to be sure that people implementing opus playback will bother reading it instead of hard coding some incorrect value.

IETF Opus codec now ready for testing

Reply #85 –
this first one doesn't work (I put --vbr just to make sure).  gives me a 21 kilobyte file.  it plays back in opusdec.exe, but is truncated.

Code: [Select]
--bitrate 512 --music --vbr - %d


this last one works.  plays back the entire file in opusdec.exe...

Code: [Select]
--bitrate 512 --music --vbr %s %d


I don't think it's a fb2k bug, but just in case you're wondering, it's foobar2000 1.1.13.  also, the original file is wavpack, not wav.

IETF Opus codec now ready for testing

Reply #86 –
Quote from: greensdrive on
this first one doesn't work (I put --vbr just to make sure).  gives me a 21 kilobyte file.  it plays back in opusdec.exe, but is truncated.


How long is it?  21kilobytes sounds like it's not being truncated at zero.  If foobar is sending some short but non-zero length that stinks and foobar should be fixed. I will add an option to ignore the length but it really shouldn't be needed.  (I note that oggenc has an ignorelength option which is not actually connected to anything)

IETF Opus codec now ready for testing

Reply #87 –
foobar2000 sends 0xFFFFFFFF for the length fields it cannot predict.

IETF Opus codec now ready for testing

Reply #88 –
Quote from: NullC on
How long is it?


this is the opusinfo.exe output:

Code: [Select]
Processing file "10 love in plaster.opus"...

New logical stream (#1, serial: 000063ed): type opus
Encoded with libopus 0.9.11-75-gc64f4a4
User comments section follows...
        ENCODER=opusenc from opus-tools 0.1.0-9-gac7490c

Opus stream 1:
        Pre-skip: 356
        Playback gain: 0dB
        Channels: 2
        Original sample rate: 44100Hz
        Packet duration:   20.0ms (max),   20.0ms (avg),   20.0ms (min)
        Page duration:    360.0ms (max),  360.0ms (avg),  360.0ms (min)
        Total data length: 21536 bytes (overhead: 1.37%)
        Playback length: 0m:00.348s
        Average bitrate: 494.6 kb/s, w/o overhead: 487.9 kb/s
Logical stream 1 ended


please note that the encoder version string may not have been updated with the recent release, as well as any other version string.  I am pretty sure that the README says something different as far as what git revision it was built from.

IETF Opus codec now ready for testing

Reply #89 –
Quote from: greensdrive on
Playback length: 0m:00.348s
please note that the encoder version string may not have been updated with the recent release, as well as any other version string.  I am pretty sure that the README says something different as far as what git revision it was built from.


The only explanation I can come up with for that length is that Windows is returning a length of 16384 on a pipe. Weird.  I added an --ignorelength before it was pointed out what foobar sends, didn't bother mentioning it because since foobar is sending  0xFFFFFFFF it won't do anything. I'll make it also avoid trying to ftell to get the length and we'll see if that fixes it.

As far as the versions— they're automatically generated from the SCM and don't need to be updated, so they're always correct.

Here is an updated opus-tools that might(?!) fix that behavior if you provide the --ignorelength argument:  https://people.xiph.org/~greg/opus-tools.zip

IETF Opus codec now ready for testing

Reply #90 –
--ignorelength works like a charm.

IETF Opus codec now ready for testing

Reply #91 –
Quote from: greensdrive on
--ignorelength works like a charm.


With this information in hand I went and googled a bit harder— apparently fseek() on Windows returns 0 on pipes (it looks successful).  I've added an additional test on Windows to check for pipes and ignorelength shouldn't be needed in these cases anymore.  It's still available for use just in case the wav header is wrong in a way opusenc doesn't detect.

https://people.xiph.org/~greg/opus-tools.zip

IETF Opus codec now ready for testing

Reply #92 –
wow.  no --ignorelength.  no %s.  opusenc.exe now works with piped input.

IETF Opus codec now ready for testing

Reply #93 –
Just a minor update:  The win32 builds of opus-tools are now available at http://opus-codec.org/downloads/

Thanks to everyone here in helping it to a maturity level high enough to justify putting it on the site.

I also have some silly live streams running at

http://ec2-50-112-77-171.us-west-2.compute...poralfugue.opus
and
http://ec2-50-112-77-171.us-west-2.compute...8000/clock.opus

If you have curl you can play them using curl URL | opusdec -  or with Firefox nightly  (after going to about:config and enabling opus).

IETF Opus codec now ready for testing

Reply #94 –
NullC:

not directly related to opus, but it seems the links for the man pages are wrong.

encode goes to opusenc.html
inspect goes to opusdec.html
decode goes to opusinfo.html

those links are part of the sentence: "Opus-tools provides command-line utilities to encode, inspect, and decode .opus files."

figured I'd post it here since I've heard no one can create a Trac account for posting bugs on xiph.org.

IETF Opus codec now ready for testing

Reply #95 –
Quote from: greensdrive on
NullC:

not directly related to opus, but it seems the links for the man pages are wrong.
figured I'd post it here since I've heard no one can create a Trac account for posting bugs on xiph.org.


Doh. Thanks. Fixed.

We'll have a proper bug-tracker and such up at least in time for the 1.0 release.

IETF Opus codec now ready for testing

Reply #96 –
Before I run anything, can you explain me why the encoder and decoder have gained about 1MB between the latest test version and the v0.1.2 within few hours ?


Code: [Select]
File        Date/Time           Size

opusenc     12/06/2012 10:58    329 728
opusdec     12/06/2012 10:58    310 784

opusenc     12/06/2012 14:24    1 348 000
opusdec     12/06/2012 14:24    1 282 881

IETF Opus codec now ready for testing

Reply #97 –
Quote from: Brazil2 on
Before I run anything, can you explain me why the encoder and decoder have gained about 1MB between the latest test version and the v0.1.2 within few hours ?


The Mozilla folks apparently didn't strip the binaries (and they're big to begin with because they're statically linked), stripping removes debugging information and other not terribly essential stuff.

[gmaxwell@helmholtz tmp]$ wget https://ftp.mozilla.org/pub/mozilla.org/opu...tools-0.1.2.zip
[gmaxwell@helmholtz tmp]$ unzip opus-tools-0.1.2.zip
[gmaxwell@helmholtz tmp]$ cd opus-tools-0.1.2/
[gmaxwell@helmholtz opus-tools-0.1.2]$ mingw-strip *.exe
[gmaxwell@helmholtz opus-tools-0.1.2]$ ls -l *.exe
-rwxr-xr-x. 1 gmaxwell gmaxwell 287744 Jun 15 16:10 opusdec.exe
-rwxr-xr-x. 1 gmaxwell gmaxwell 327680 Jun 15 16:10 opusenc.exe
-rwxr-xr-x. 1 gmaxwell gmaxwell  34304 Jun 15 16:10 opusinfo.exe

IETF Opus codec now ready for testing

Reply #98 –
Quote from: NullC on
The Mozilla folks apparently didn't strip the binaries (and they're big to begin with because they're statically linked), stripping removes debugging information and other not terribly essential stuff.

[gmaxwell@helmholtz opus-tools-0.1.2]$ mingw-strip *.exe
[gmaxwell@helmholtz opus-tools-0.1.2]$ ls -l *.exe
-rwxr-xr-x. 1 gmaxwell gmaxwell 287744 Jun 15 16:10 opusdec.exe
-rwxr-xr-x. 1 gmaxwell gmaxwell 327680 Jun 15 16:10 opusenc.exe
-rwxr-xr-x. 1 gmaxwell gmaxwell  34304 Jun 15 16:10 opusinfo.exe

Works like a charm, thanks for the tip

IETF Opus codec now ready for testing

Reply #99 –
Opus has received the IETF's approval to become a standard.  There will be some weeks of publication / pure-editorial delay and it will receive and RFC number and we'll make the big public announcements.

Now is really the time to get support into applications (well, this was also true for some time, but doubly so now).  If there is an application you think should have Opus support that doesn't, especially open source ones, please post about it here and I'll do what I can to coordinate with their authors.