Christian, I will give 64kbit/s a try and post the figures. My own project is voice only and requires low bitrate so was hoping that it was just the way I was compiling and not an actual regression in speed for SILK. The raspberry PI is quite a cheap and handy reference platform though the ARM side is fairly underpowered but has a great GPU. It also has no audio in which is a pain for playing with codecs but it does support USB soundcards. I was wondering if a microcontroller like the Cortex-M range might be able to encode and that seemed possible extrapolating from the Pi results but this speed regression if it is real would kill that hope. I should also probably try and compile the same version from the Raspbian repos myself and if I also see a big slowdown then it is something wrong with the way I am compiling. I am not a deb expert but it seemed like the only optimisation they were using was -O2 but perhaps there is something else set. Do not want to claim a regression when it may be my own fault. Thanks for your response. Best Regards, Stuart Marsden On 17 December 2013 11:04, Christian Hoene <christian.hoene at symonics.com>wrote:> Hi Stuart, > > > > you are compressing it at 6kbit/s. Then, then SILK mode is probability > used and the Silk mode is much faster than CELT. Do you also some figures > at 64kbit/s? > > > > It is strange that Opus 1.1 got slower in the Silk mode ? may the > speech/voice selection adds some overhead. I would be interested in seeing > the performance of the 64 kbit/s in both Opus 1.0 and Opus 1.1. > > > > With best regards, > > > > Christian Hoene > > > > PS: > I also though on using Raspberry PI as a reference platform for testing > the speech of Opus on a ARM processor. For measuring the speech > of Opus on Intel CPUs, the MARSS86.org simulator might be appropriate. > > > > > > > > > > > > *Von:* opus-bounces at xiph.org [mailto:opus-bounces at xiph.org] *Im Auftrag > von *Stuart Marsden > *Gesendet:* Montag, 16. Dezember 2013 14:03 > *An:* opus at xiph.org > *Betreff:* [opus] 1.1 Much slower on Raspberry Pi > > > > I have just started trying Opus with a view to using it in a project. I am > interested in embedded hardware and tried it on the Raspberry Pi using the > raspbian distro. > > > > The version of libopus in the repos is 0.9.14. I installed this and tried > encoding 2 minutes of speech from a librevox recording. It managed this at > a respectable pace for complexity 10: > > > > Skipping chunk of type "LIST", length 76 > > Encoding using libopus 0.9.14 (audio) > > ----------------------------------------------------- > > Input: 44.1kHz 1 channel > > Output: 1 channel (1 uncoupled) > > 20ms packets, 6kbit/sec VBR > > Preskip: 356 > > > > Encoding complete > > ----------------------------------------------------- > > Encoded: 2 minutes and 0.02 seconds > > Runtime: 50.9 seconds > > (2.358x realtime) > > Wrote: 111194 bytes, 6001 packets, 123 pages > > Bitrate: 6.78414kbit/s (without overhead) > > Rate range: 2.8kbit/s to 12kbit/s > > (7 to 30 bytes per packet) > > Overhead: 8.47% (container+metadata) > > > > And even faster on complexity 0: > > > > Skipping chunk of type "LIST", length 76 > > Encoding using libopus 0.9.14 (audio) > > ----------------------------------------------------- > > Input: 44.1kHz 1 channel > > Output: 1 channel (1 uncoupled) > > 20ms packets, 6kbit/sec VBR > > Preskip: 316 > > > > Encoding complete > > ----------------------------------------------------- > > Encoded: 2 minutes and 0.02 seconds > > Runtime: 23.72 seconds > > (5.059x realtime) > > Wrote: 106598 bytes, 6001 packets, 123 pages > > Bitrate: 6.47779kbit/s (without overhead) > > Rate range: 2.4kbit/s to 13.6kbit/s > > (6 to 34 bytes per packet) > > Overhead: 8.83% (container+metadata) > > > > I saw the 1.1 release notes and it said speed improvements on ARM so > thought I would try. I downloaded from opus-codec.org and compiled > directly on the Pi. It has however turned out a lot slower. Complexity 10 > barely can encode in realtime: > > > > Skipping chunk of type "LIST", length 76 > > Encoding using libopus 1.1 (audio) > > ----------------------------------------------------- > > Input: 44.1kHz 1 channel > > Output: 1 channel (1 uncoupled) > > 20ms packets, 6kbit/sec VBR > > Preskip: 356 > > > > Encoding complete > > > ----------------------------------------------------- > > Encoded: 2 minutes and 0.02 seconds > > Runtime: 1 minute and 53 seconds > > (1.062x realtime) > > Wrote: 110743 bytes, 6001 packets, 123 pages > > Bitrate: 6.70782kbit/s (without overhead) > > Instant rates: 2.8kbit/s to 11.6kbit/s > > (7 to 29 bytes per packet) > > Overhead: 9.13% (container+metadata) > > > > And is also much slower at complexity 0: > > > > Skipping chunk of type "LIST", length 76 > > Notice: Using resampling with complexity<10. > > Opusenc is fastest with 48, 24, 16, 12, or 8kHz input. > > > > Encoding using libopus 1.1 (audio) > > ----------------------------------------------------- > > Input: 44.1kHz 1 channel > > Output: 1 channel (1 uncoupled) > > 20ms packets, 6kbit/sec VBR > > Preskip: 316 > > > > Encoding complete > > > ----------------------------------------------------- > > Encoded: 2 minutes and 0.02 seconds > > Runtime: 36 seconds > > (3.334x realtime) > > Wrote: 106945 bytes, 6001 packets, 123 pages > > Bitrate: 6.45466kbit/s (without overhead) > > Instant rates: 2.4kbit/s to 12.8kbit/s > > (6 to 32 bytes per packet) > > Overhead: 9.45% (container+metadata) > > > > I tried compiling it as fixed point and it is slightly faster but no where > near the older version. At complexity 10: > > > > Skipping chunk of type "LIST", length 76 > > Encoding using libopus 1.1-fixed (audio) > > ----------------------------------------------------- > > Input: 44.1kHz 1 channel > > Output: 1 channel (1 uncoupled) > > 20ms packets, 6kbit/sec VBR > > Preskip: 356 > > > > Encoding complete > > > ----------------------------------------------------- > > Encoded: 2 minutes and 0.02 seconds > > Runtime: 1 minute and 42 seconds > > (1.177x realtime) > > Wrote: 110686 bytes, 6001 packets, 123 pages > > Bitrate: 6.70402kbit/s (without overhead) > > Instant rates: 2.4kbit/s to 11.2kbit/s > > (6 to 28 bytes per packet) > > Overhead: 9.13% (container+metadata) > > > > > > I have tried different compiler options but nothing has brought the speed > back up. > > > > Any advice on the compiler flags or why I should be seeing such a big > speed regression? > > > > Stuart Marsden > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20131217/2f2f9775/attachment-0001.htm
I have compiled myself the previous version of libopus to find out if it was a regression or something I was doing wrong in compiling. It looks like it has got slower since 0.9.14. I have recompiled everything with these CFLAGS natively on the Pi: "-O2 -pipe -march=armv6j -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard". These seem to be the recommended settings. I had assumed that opusenc would not be taking that much CPU but having re-compiled I have made up some of the loss but not all. So on the same file with complexity 10 at bitrate 6kbps (floating point), I see the following speeds (x realtime): libopus 0.9.14 opus-tools 0.1.2 Speed 2.289 libopus 1.1 opus-tools 0.1.2 Speed 1.887 libopus 1.1 opus-tools 0.1.8 Speed 1.667 Same file with complexity 10 at bitrate 64kbps (floating point), I see the following speeds: libopus 0.9.14 opus-tools 0.1.2 Speed 2.639 libopus 1.1 opus-tools 0.1.2 Speed 2.193 libopus 1.1 opus-tools 0.1.8 Speed 2.069 So it seems both libopus and opus-tools have become slower on the Raspberry PI somewhere between 0.9.14 and 1.1. This seems to be for both SILK and CELT or at least 6 and 64kbps. Opus-tools is also contributing to the slowdown. I would be hitting the library direct when I implement so that is off less interest to me but still worth looking at. I did not run lots of repeats of each test but when I did they only varied by about 0.05 so natural variation does not account for it. Maybe the advertised speed ups were only for more modern ARM targets but it is still a shame to see it get slower on this target. Stuart Marsden Best Regards, Stuart Marsden Tactical Communications Consultant FinMars Consulting Ltd UK: +441865589833 Finland: +358453046287 On 17 December 2013 12:48, Stuart Marsden <stuartmarsden at finmars.co.uk>wrote:> Christian, > > I will give 64kbit/s a try and post the figures. My own project is voice > only and requires low bitrate so was hoping that it was just the way I was > compiling and not an actual regression in speed for SILK. The raspberry PI > is quite a cheap and handy reference platform though the ARM side is fairly > underpowered but has a great GPU. It also has no audio in which is a pain > for playing with codecs but it does support USB soundcards. I was wondering > if a microcontroller like the Cortex-M range might be able to encode and > that seemed possible extrapolating from the Pi results but this speed > regression if it is real would kill that hope. > > I should also probably try and compile the same version from the Raspbian > repos myself and if I also see a big slowdown then it is something wrong > with the way I am compiling. I am not a deb expert but it seemed like the > only optimisation they were using was -O2 but perhaps there is something > else set. Do not want to claim a regression when it may be my own fault. > > Thanks for your response. > > > Best Regards, > > Stuart Marsden > > > On 17 December 2013 11:04, Christian Hoene <christian.hoene at symonics.com>wrote: > >> Hi Stuart, >> >> >> >> you are compressing it at 6kbit/s. Then, then SILK mode is probability >> used and the Silk mode is much faster than CELT. Do you also some figures >> at 64kbit/s? >> >> >> >> It is strange that Opus 1.1 got slower in the Silk mode ? may the >> speech/voice selection adds some overhead. I would be interested in seeing >> the performance of the 64 kbit/s in both Opus 1.0 and Opus 1.1. >> >> >> >> With best regards, >> >> >> >> Christian Hoene >> >> >> >> PS: >> I also though on using Raspberry PI as a reference platform for testing >> the speech of Opus on a ARM processor. For measuring the speech >> of Opus on Intel CPUs, the MARSS86.org simulator might be appropriate. >> >> >> >> >> >> >> >> >> >> >> >> *Von:* opus-bounces at xiph.org [mailto:opus-bounces at xiph.org] *Im Auftrag >> von *Stuart Marsden >> *Gesendet:* Montag, 16. Dezember 2013 14:03 >> *An:* opus at xiph.org >> *Betreff:* [opus] 1.1 Much slower on Raspberry Pi >> >> >> >> I have just started trying Opus with a view to using it in a project. I >> am interested in embedded hardware and tried it on the Raspberry Pi using >> the raspbian distro. >> >> >> >> The version of libopus in the repos is 0.9.14. I installed this and tried >> encoding 2 minutes of speech from a librevox recording. It managed this at >> a respectable pace for complexity 10: >> >> >> >> Skipping chunk of type "LIST", length 76 >> >> Encoding using libopus 0.9.14 (audio) >> >> ----------------------------------------------------- >> >> Input: 44.1kHz 1 channel >> >> Output: 1 channel (1 uncoupled) >> >> 20ms packets, 6kbit/sec VBR >> >> Preskip: 356 >> >> >> >> Encoding complete >> >> ----------------------------------------------------- >> >> Encoded: 2 minutes and 0.02 seconds >> >> Runtime: 50.9 seconds >> >> (2.358x realtime) >> >> Wrote: 111194 bytes, 6001 packets, 123 pages >> >> Bitrate: 6.78414kbit/s (without overhead) >> >> Rate range: 2.8kbit/s to 12kbit/s >> >> (7 to 30 bytes per packet) >> >> Overhead: 8.47% (container+metadata) >> >> >> >> And even faster on complexity 0: >> >> >> >> Skipping chunk of type "LIST", length 76 >> >> Encoding using libopus 0.9.14 (audio) >> >> ----------------------------------------------------- >> >> Input: 44.1kHz 1 channel >> >> Output: 1 channel (1 uncoupled) >> >> 20ms packets, 6kbit/sec VBR >> >> Preskip: 316 >> >> >> >> Encoding complete >> >> ----------------------------------------------------- >> >> Encoded: 2 minutes and 0.02 seconds >> >> Runtime: 23.72 seconds >> >> (5.059x realtime) >> >> Wrote: 106598 bytes, 6001 packets, 123 pages >> >> Bitrate: 6.47779kbit/s (without overhead) >> >> Rate range: 2.4kbit/s to 13.6kbit/s >> >> (6 to 34 bytes per packet) >> >> Overhead: 8.83% (container+metadata) >> >> >> >> I saw the 1.1 release notes and it said speed improvements on ARM so >> thought I would try. I downloaded from opus-codec.org and compiled >> directly on the Pi. It has however turned out a lot slower. Complexity 10 >> barely can encode in realtime: >> >> >> >> Skipping chunk of type "LIST", length 76 >> >> Encoding using libopus 1.1 (audio) >> >> ----------------------------------------------------- >> >> Input: 44.1kHz 1 channel >> >> Output: 1 channel (1 uncoupled) >> >> 20ms packets, 6kbit/sec VBR >> >> Preskip: 356 >> >> >> >> Encoding complete >> >> >> ----------------------------------------------------- >> >> Encoded: 2 minutes and 0.02 seconds >> >> Runtime: 1 minute and 53 seconds >> >> (1.062x realtime) >> >> Wrote: 110743 bytes, 6001 packets, 123 pages >> >> Bitrate: 6.70782kbit/s (without overhead) >> >> Instant rates: 2.8kbit/s to 11.6kbit/s >> >> (7 to 29 bytes per packet) >> >> Overhead: 9.13% (container+metadata) >> >> >> >> And is also much slower at complexity 0: >> >> >> >> Skipping chunk of type "LIST", length 76 >> >> Notice: Using resampling with complexity<10. >> >> Opusenc is fastest with 48, 24, 16, 12, or 8kHz input. >> >> >> >> Encoding using libopus 1.1 (audio) >> >> ----------------------------------------------------- >> >> Input: 44.1kHz 1 channel >> >> Output: 1 channel (1 uncoupled) >> >> 20ms packets, 6kbit/sec VBR >> >> Preskip: 316 >> >> >> >> Encoding complete >> >> >> ----------------------------------------------------- >> >> Encoded: 2 minutes and 0.02 seconds >> >> Runtime: 36 seconds >> >> (3.334x realtime) >> >> Wrote: 106945 bytes, 6001 packets, 123 pages >> >> Bitrate: 6.45466kbit/s (without overhead) >> >> Instant rates: 2.4kbit/s to 12.8kbit/s >> >> (6 to 32 bytes per packet) >> >> Overhead: 9.45% (container+metadata) >> >> >> >> I tried compiling it as fixed point and it is slightly faster but no >> where near the older version. At complexity 10: >> >> >> >> Skipping chunk of type "LIST", length 76 >> >> Encoding using libopus 1.1-fixed (audio) >> >> ----------------------------------------------------- >> >> Input: 44.1kHz 1 channel >> >> Output: 1 channel (1 uncoupled) >> >> 20ms packets, 6kbit/sec VBR >> >> Preskip: 356 >> >> >> >> Encoding complete >> >> >> ----------------------------------------------------- >> >> Encoded: 2 minutes and 0.02 seconds >> >> Runtime: 1 minute and 42 seconds >> >> (1.177x realtime) >> >> Wrote: 110686 bytes, 6001 packets, 123 pages >> >> Bitrate: 6.70402kbit/s (without overhead) >> >> Instant rates: 2.4kbit/s to 11.2kbit/s >> >> (6 to 28 bytes per packet) >> >> Overhead: 9.13% (container+metadata) >> >> >> >> >> >> I have tried different compiler options but nothing has brought the speed >> back up. >> >> >> >> Any advice on the compiler flags or why I should be seeing such a big >> speed regression? >> >> >> >> Stuart Marsden >> >> >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20131217/1211a25b/attachment-0001.htm
Resampling to 48khz speeds them both up but the disparity is about the same: 2.609 to 3.69. Best Regards, Stuart Marsden On 17 December 2013 17:04, Stuart Marsden <stuartmarsden at finmars.co.uk>wrote:> Christian, > > Complexity 0, 6kbps: > > 0.9.14 Speed 5.204 > 1.1 Speed 5.218 > > A slight win on that run but they vary enough to say about the same. At > 64kbps > > 0.9.14 Speed 6.35 > 1.1 Speed 6.001 > > I get more variation on these so I would say they are quite close and the > difference may not be statistically significant. > > I notice my sample is 44.1khz which is not optimal so it may be the > re-sampling which is contributing. I will adjust in audacity and try the > comparison again. > > Stuart > > Best Regards, > > Stuart Marsden > > Tactical Communications Consultant > FinMars Consulting Ltd > UK: +441865589833 > Finland: +358453046287 > > > On 17 December 2013 16:53, Christian Hoene <christian.hoene at symonics.com>wrote: > >> Hi Stuart, >> >> >> >> what happens if you do the tests with complexity 0? >> >> >> >> With best regards, >> >> >> >> Christian >> >> >> >> >> >> *Von:* opus-bounces at xiph.org [mailto:opus-bounces at xiph.org] *Im Auftrag >> von *Stuart Marsden >> *Gesendet:* Dienstag, 17. Dezember 2013 15:40 >> *An:* opus at xiph.org >> *Betreff:* Re: [opus] 1.1 Much slower on Raspberry Pi >> >> >> >> I have compiled myself the previous version of libopus to find out if it >> was a regression or something I was doing wrong in compiling. It looks like >> it has got slower since 0.9.14. I have recompiled everything with these >> CFLAGS natively on the Pi: "-O2 -pipe -march=armv6j -mtune=arm1176jzf-s >> -mfpu=vfp -mfloat-abi=hard". These seem to be the recommended settings. I >> had assumed that opusenc would not be taking that much CPU but having >> re-compiled I have made up some of the loss but not all. >> >> >> >> So on the same file with complexity 10 at bitrate 6kbps (floating point), >> I see the following speeds (x realtime): >> >> >> >> libopus 0.9.14 opus-tools 0.1.2 Speed 2.289 >> >> libopus 1.1 opus-tools 0.1.2 Speed 1.887 >> >> libopus 1.1 opus-tools 0.1.8 Speed 1.667 >> >> >> >> Same file with complexity 10 at bitrate 64kbps (floating point), I see >> the following speeds: >> >> >> >> libopus 0.9.14 opus-tools 0.1.2 Speed 2.639 >> >> libopus 1.1 opus-tools 0.1.2 Speed 2.193 >> >> libopus 1.1 opus-tools 0.1.8 Speed 2.069 >> >> >> >> So it seems both libopus and opus-tools have become slower on the >> Raspberry PI somewhere between 0.9.14 and 1.1. This seems to be for both >> SILK and CELT or at least 6 and 64kbps. Opus-tools is also contributing to >> the slowdown. I would be hitting the library direct when I implement so >> that is off less interest to me but still worth looking at. I did not run >> lots of repeats of each test but when I did they only varied by about 0.05 >> so natural variation does not account for it. >> >> >> >> Maybe the advertised speed ups were only for more modern ARM targets but >> it is still a shame to see it get slower on this target. >> >> >> >> Stuart Marsden >> >> >> >> >> Best Regards, >> >> >> >> Stuart Marsden >> >> >> >> Tactical Communications Consultant >> >> FinMars Consulting Ltd >> >> UK: +441865589833 >> >> Finland: +358453046287 >> >> >> >> On 17 December 2013 12:48, Stuart Marsden <stuartmarsden at finmars.co.uk> >> wrote: >> >> Christian, >> >> >> >> I will give 64kbit/s a try and post the figures. My own project is voice >> only and requires low bitrate so was hoping that it was just the way I was >> compiling and not an actual regression in speed for SILK. The raspberry PI >> is quite a cheap and handy reference platform though the ARM side is fairly >> underpowered but has a great GPU. It also has no audio in which is a pain >> for playing with codecs but it does support USB soundcards. I was wondering >> if a microcontroller like the Cortex-M range might be able to encode and >> that seemed possible extrapolating from the Pi results but this speed >> regression if it is real would kill that hope. >> >> >> >> I should also probably try and compile the same version from the Raspbian >> repos myself and if I also see a big slowdown then it is something wrong >> with the way I am compiling. I am not a deb expert but it seemed like the >> only optimisation they were using was -O2 but perhaps there is something >> else set. Do not want to claim a regression when it may be my own fault. >> >> >> >> Thanks for your response. >> >> >> >> >> Best Regards, >> >> >> >> Stuart Marsden >> >> >> >> >> >> On 17 December 2013 11:04, Christian Hoene <christian.hoene at symonics.com> >> wrote: >> >> Hi Stuart, >> >> >> >> you are compressing it at 6kbit/s. Then, then SILK mode is probability >> used and the Silk mode is much faster than CELT. Do you also some figures >> at 64kbit/s? >> >> >> >> It is strange that Opus 1.1 got slower in the Silk mode ? may the >> speech/voice selection adds some overhead. I would be interested in seeing >> the performance of the 64 kbit/s in both Opus 1.0 and Opus 1.1. >> >> >> >> With best regards, >> >> >> >> Christian Hoene >> >> >> >> PS: >> I also though on using Raspberry PI as a reference platform for testing >> the speech of Opus on a ARM processor. For measuring the speech >> of Opus on Intel CPUs, the MARSS86.org simulator might be appropriate. >> >> >> >> >> >> >> >> >> >> >> >> *Von:* opus-bounces at xiph.org [mailto:opus-bounces at xiph.org] *Im Auftrag >> von *Stuart Marsden >> *Gesendet:* Montag, 16. Dezember 2013 14:03 >> *An:* opus at xiph.org >> *Betreff:* [opus] 1.1 Much slower on Raspberry Pi >> >> >> >> I have just started trying Opus with a view to using it in a project. I >> am interested in embedded hardware and tried it on the Raspberry Pi using >> the raspbian distro. >> >> >> >> The version of libopus in the repos is 0.9.14. I installed this and tried >> encoding 2 minutes of speech from a librevox recording. It managed this at >> a respectable pace for complexity 10: >> >> >> >> Skipping chunk of type "LIST", length 76 >> >> Encoding using libopus 0.9.14 (audio) >> >> ----------------------------------------------------- >> >> Input: 44.1kHz 1 channel >> >> Output: 1 channel (1 uncoupled) >> >> 20ms packets, 6kbit/sec VBR >> >> Preskip: 356 >> >> >> >> Encoding complete >> >> ----------------------------------------------------- >> >> Encoded: 2 minutes and 0.02 seconds >> >> Runtime: 50.9 seconds >> >> (2.358x realtime) >> >> Wrote: 111194 bytes, 6001 packets, 123 pages >> >> Bitrate: 6.78414kbit/s (without overhead) >> >> Rate range: 2.8kbit/s to 12kbit/s >> >> (7 to 30 bytes per packet) >> >> Overhead: 8.47% (container+metadata) >> >> >> >> And even faster on complexity 0: >> >> >> >> Skipping chunk of type "LIST", length 76 >> >> Encoding using libopus 0.9.14 (audio) >> >> ----------------------------------------------------- >> >> Input: 44.1kHz 1 channel >> >> Output: 1 channel (1 uncoupled) >> >> 20ms packets, 6kbit/sec VBR >> >> Preskip: 316 >> >> >> >> Encoding complete >> >> ----------------------------------------------------- >> >> Encoded: 2 minutes and 0.02 seconds >> >> Runtime: 23.72 seconds >> >> (5.059x realtime) >> >> Wrote: 106598 bytes, 6001 packets, 123 pages >> >> Bitrate: 6.47779kbit/s (without overhead) >> >> Rate range: 2.4kbit/s to 13.6kbit/s >> >> (6 to 34 bytes per packet) >> >> Overhead: 8.83% (container+metadata) >> >> >> >> I saw the 1.1 release notes and it said speed improvements on ARM so >> thought I would try. I downloaded from opus-codec.org and compiled >> directly on the Pi. It has however turned out a lot slower. Complexity 10 >> barely can encode in realtime: >> >> >> >> Skipping chunk of type "LIST", length 76 >> >> Encoding using libopus 1.1 (audio) >> >> ----------------------------------------------------- >> >> Input: 44.1kHz 1 channel >> >> Output: 1 channel (1 uncoupled) >> >> 20ms packets, 6kbit/sec VBR >> >> Preskip: 356 >> >> >> >> Encoding complete >> >> >> ----------------------------------------------------- >> >> Encoded: 2 minutes and 0.02 seconds >> >> Runtime: 1 minute and 53 seconds >> >> (1.062x realtime) >> >> Wrote: 110743 bytes, 6001 packets, 123 pages >> >> Bitrate: 6.70782kbit/s (without overhead) >> >> Instant rates: 2.8kbit/s to 11.6kbit/s >> >> (7 to 29 bytes per packet) >> >> Overhead: 9.13% (container+metadata) >> >> >> >> And is also much slower at complexity 0: >> >> >> >> Skipping chunk of type "LIST", length 76 >> >> Notice: Using resampling with complexity<10. >> >> Opusenc is fastest with 48, 24, 16, 12, or 8kHz input. >> >> >> >> Encoding using libopus 1.1 (audio) >> >> ----------------------------------------------------- >> >> Input: 44.1kHz 1 channel >> >> Output: 1 channel (1 uncoupled) >> >> 20ms packets, 6kbit/sec VBR >> >> Preskip: 316 >> >> >> >> Encoding complete >> >> >> ----------------------------------------------------- >> >> Encoded: 2 minutes and 0.02 seconds >> >> Runtime: 36 seconds >> >> (3.334x realtime) >> >> Wrote: 106945 bytes, 6001 packets, 123 pages >> >> Bitrate: 6.45466kbit/s (without overhead) >> >> Instant rates: 2.4kbit/s to 12.8kbit/s >> >> (6 to 32 bytes per packet) >> >> Overhead: 9.45% (container+metadata) >> >> >> >> I tried compiling it as fixed point and it is slightly faster but no >> where near the older version. At complexity 10: >> >> >> >> Skipping chunk of type "LIST", length 76 >> >> Encoding using libopus 1.1-fixed (audio) >> >> ----------------------------------------------------- >> >> Input: 44.1kHz 1 channel >> >> Output: 1 channel (1 uncoupled) >> >> 20ms packets, 6kbit/sec VBR >> >> Preskip: 356 >> >> >> >> Encoding complete >> >> >> ----------------------------------------------------- >> >> Encoded: 2 minutes and 0.02 seconds >> >> Runtime: 1 minute and 42 seconds >> >> (1.177x realtime) >> >> Wrote: 110686 bytes, 6001 packets, 123 pages >> >> Bitrate: 6.70402kbit/s (without overhead) >> >> Instant rates: 2.4kbit/s to 11.2kbit/s >> >> (6 to 28 bytes per packet) >> >> Overhead: 9.13% (container+metadata) >> >> >> >> >> >> I have tried different compiler options but nothing has brought the speed >> back up. >> >> >> >> Any advice on the compiler flags or why I should be seeing such a big >> speed regression? >> >> >> >> Stuart Marsden >> >> >> >> >> >> >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20131217/0a75dae4/attachment-0001.htm