Posted: 9/20/2013 1:06 PM
(Edited: 11/20/2013 1:25 AM)
Post subject: Opus Encoding & Playback - Switch to Opus Discussion
Quote
Nach
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
The Opus Codec is known to have better quality at a lower size than legacy codecs such as MP3, WMA, Vorbis, Speex, and AAC. See our sound test discussion. Opus within MKV is still missing a few things and not supported everywhere, but support at the moment is still pretty good. Since support is pretty good, we should start switching to it shortly. Opus audio tools: http://www.opus-codec.org/downloads/ MKV creating with Opus can be done using mkvmerge from mkvtoolnix (Windows). Media file information: http://mediaarea.net/en/MediaInfo If you're on Debian Linux, note that Debian takes a while to upgrade some packages, and furthermore, due to licensing, doesn't compile a lot of features into the packages they build. Therefore one of the Debian multimedia maintainers have a separate repository with more up to date and fully featured packages. http://www.deb-multimedia.org/ Some tools can encode audio, video, and mux into a container file all at the same time and support MKV with Opus: FFMPEG (Windows). MEncoder (Windows) (Part of MPlayer). MPV (Windows). File to test Opus in MKV: http://ilari.tasvideos.org/kirbyglitched.opus-10bit444.mkv Players which support Opus in MKV: MPlayer (Windows). MPV (Windows). ffplay from FFMPEG (Windows). Official SMplayer builds. K-Lite Mega Codec Pack for Windows- provides up to date versions of Media Player Classic Homecinema, LAV Video, and ffdshow. I did not test out the individual versions of each of these applications, or the versions floating around on other build sites, but the versions and default settings in this package do the trick. Tools which DO NOT (but should!) support Opus in MKV: Libav (Windows) - The avconv and avplay converter and player. MPlayer2 (Windows). VLC. I tested everything enumerated here using latest versions in Debian repositories, and Windows builds from the various sites for Windows XP. For Debian Linux Encoding+Muxing, there are 3/4 applications. For Windows, 3/4. For Debian Linux playback, there are 4/7 applications. For Windows, 5/8. All in all, it looks like there's enough support that we can move ahead. Encoders, please weigh in. (All information is only up to date at the time of this writing - September 22 2013) Edit: Added MPV for Windows. Thanks you turska. Edit: MPlayer/MEncoder on Debian has been updated, and now supports Opus in MKV.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Posted: 9/20/2013 1:14 PM
Quote
Ilari
Emulator Coder, Skilled player (1141)
Joined: 5/1/2010
Posts: 1217
Rookie of 2010 New systems TASer of 2010 New systems TAS of 2010
Note that libopus 1.1-beta (and 1.1 when it is released) should be used instead of libopus 1.0.X. Use 'opusenc --version' to see what version it is:
opusenc opus-tools 0.1.6-50-g1ba6702 (using libopus 1.1-beta-21-g02fed47)
That's using 1.1-beta.
Posted: 9/20/2013 1:20 PM
Quote
Nach
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Since feos has decided that our downloads should now consist of 512kb MP4s (H.264 with more compatible video settings and AAC) and high quality MKVs (H.264 bleeding edge, Vorbis), I think we should start switching our MKVs to use Opus instead of Vorbis. There's plenty of software here to point people to a compatible player, and otherwise, they can get a more compatible MP4. Ilari: Do you think we should hold off to libopus-1.1 release? Any idea when that will be? Or is the beta fine? Any other thoughts?
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Posted: 9/20/2013 1:22 PM
Quote
natt
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I like this idea. Do we want to Opus up only the 10bit444 encode, or both? Of course, now that we're talking about it, 10 bit should probably be added to regular encodes and the current specialty "10bit444" should be retired, to be replaced by hevc at some point.
Posted: 9/20/2013 1:24 PM
Quote
Nach
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
natt wrote:
Do we want to Opus up only the 10bit444 encode, or both? Of course, now that we're talking about it, 10 bit should probably be added to regular encodes and the current specialty "10bit444" should be retired, to be replaced by hevc at some point.
See Post #354486 and my post above yours. We should rename the 10bit444 to some more appropriate name now, which is the main encode, and marked as cutting edge.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Posted: 9/20/2013 1:26 PM
Quote
Ilari
Emulator Coder, Skilled player (1141)
Joined: 5/1/2010
Posts: 1217
Rookie of 2010 New systems TASer of 2010 New systems TAS of 2010
Nach wrote:
Ilari: Do you think we should hold off to libopus-1.1 release? Any idea when that will be? Or is the beta fine?
Beta is fine (assuming you can get appropriate builds).
Posted: 9/20/2013 1:31 PM
Quote
Nach
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Ilari wrote:
Nach wrote:
Ilari: Do you think we should hold off to libopus-1.1 release? Any idea when that will be? Or is the beta fine?
Beta is fine (assuming you can get appropriate builds).
This seems to be the latest version at the moment: http://downloads.xiph.org/releases/opus/opus-1.1-beta.tar.gz The latest one in Debian at the moment matches yours. Perhaps someone should compile the above tarball for Windows.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Posted: 9/20/2013 1:47 PM
(Edited: 9/20/2013 2:05 PM)
Quote
feos
Site Admin, Skilled player (1235)
Joined: 4/17/2010
Posts: 11264
Location: RU
NES TAS of 2011
If we drop 10bit444 tag for these encodes, it will cause huge confusion between the old encodes without tags that were 8bit420 and the new ones. And yes, since 512kb encode is officially provided for compatibility, it must do it to maximum, avoiding opus until it is supported freaking everywhere. The test video works with the linked K-Lite codecs.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 9/20/2013 1:53 PM
Quote
Nach
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
If we drop 10bit444 tag for these encodes, it will cause huge confusion between the old encodes without tags that were 8bit420 and the new ones.
But we should drop that tag, and replace it with something more fitting. Or drop the tag on this, and add a tag to the other. If both are appropriately labeled, no need for confusion.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Posted: 9/20/2013 1:59 PM
Quote
natt
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
feos wrote:
If we drop 10bit444 tag for these encodes, it will cause huge confusion between the old encodes without tags that were 8bit420 and the new ones. And yes, since 512kb encode is officially provided for compatibility, it must do it to maximum, avoiding opus until it is supported freaking everywhere.
In times gone by, the primary encodes have been all sorts of things that they aren't now, due to changes in technology. I don't see any problem there. I agree on the 512kb; the whole point of it is to run in LOLFLASH. Looking ahead, I'd replace it only with something that would run in all major browsers' html5 video implementations.
Posted: 9/20/2013 2:00 PM
Quote
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
If MKVs are problematic, just use MP4. Is it really needed for high-quality encodes? How much space would be saved e.g. per minute? EDIT: If 128kbits is used instead of 192kbits, that would save 14MB per 30 minutes of video - an amount which would add only ca. 2 minutes to my upload time (uploading at 100KB/s). Not enough to justify the hassle, imo.
Posted: 9/20/2013 2:08 PM
Quote
feos
Site Admin, Skilled player (1235)
Joined: 4/17/2010
Posts: 11264
Location: RU
NES TAS of 2011
Nach wrote:
feos wrote:
If we drop 10bit444 tag for these encodes, it will cause huge confusion between the old encodes without tags that were 8bit420 and the new ones.
But we should drop that tag, and replace it with something more fitting. Or drop the tag on this, and add a tag to the other. If both are appropriately labeled, no need for confusion.
Adding a tag to the other? You mean the encodes that already exist and are 420?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 9/20/2013 2:11 PM
Quote
Nach
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
creaothceann wrote:
If MKVs are problematic, just use MP4.
MP4 does not support Opus.
creaothceann wrote:
Is it really needed for high-quality encodes? How much space would be saved e.g. per minute? EDIT: If 128kbits is used instead of 192kbits
128 is overkill. See the quality testing thread. Most games should sound fine with less than half that. To put it in more quantitative terms. We can probably cut sound size in half in our videos, and raise quality at the same time.
feos wrote:
Nach wrote:
feos wrote:
If we drop 10bit444 tag for these encodes, it will cause huge confusion between the old encodes without tags that were 8bit420 and the new ones.
But we should drop that tag, and replace it with something more fitting. Or drop the tag on this, and add a tag to the other. If both are appropriately labeled, no need for confusion.
Adding a tag to the other? You mean the encodes that already exist and are 420?
Whatever encodes are listed on the movie page should be labeled in a descriptive fashion to indicate that one is very compatible, and the other is modern technology.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.