Jump to content

Playing back opus 5.1/7.1 does not work (center channel is missing)


Tupsi
Go to solution Solved by Tupsi,

Recommended Posts

I convert my stuff to vp9/opus for quite a while now. So far one of the components always had trouble with opus, so the emby server always said "device can not playback audio as transcode reason", so it converted the file and everything was peachy.

 

Then, I do not know exactly what happened, but I guess some update on either your firetv app, firetv itself or even a firmeware upgrade in my reciever (what seems the most unlikely thing) and now I have trouble getting decent sound out of my setup because  my reciever seems to not understand that it is getting a 5.1/7.1 sound and mixes it down (the wrong way) to stereo.

 

As you can see from attachment 01, the result is a screwed up 2.1, resulting in me still hearing background voices (I guess the left, right and surround channels), but not the center one, so basically no conversations.

 

If I press the "i have problem seeing stuff" in the settings, emby switches to transcoding and the sound is back as it should (receiver displaying getting DD+) and all channels light up. Although the subtitles are screwed now, fast forwarding and beeing no longer sync (but I guess thats a different problem and I will make a seperate post for this).

 

 

If I playback the file on another TV setup where I only have stereo I do not get the problem obviously because some clever step realises there are no 6 nor 8 speakers and mixes it down to 2 correctly.

 

What strikes me as odd and totally wrong is the fact on the screenshot, that my reciever thinks it gets a 7.1 STEREO PCM stream (which does not make any sense, I know).

 

Can you make any sense into this?

 

If you need debug logs I would appreciate some pointers as in how to get them off the firetv, as it is quite a while I push/pulled something from an android device and my swiss cheese brain has trouble remembering how to do so :-)

 

 

post-311678-0-62428600-1552567285_thumb.jpg

post-311678-0-47829000-1552567295_thumb.jpg

Edited by Tupsi
Link to comment
Share on other sites

This seems like it has to be a problem with the receiver since it says we're sending the full channel line-up...

Link to comment
Share on other sites

This seems like it has to be a problem with the receiver since it says we're sending the full channel line-up...

 

I thought so too at first. What I do not get is, why the reciever thinks it gets stereo when there are 6 or 8 channels comming its way? I have this thing for some time now and used it together with kodi before I discovered there is magic like emby and plex and it was never a problem to just stream multichannel pcm to it. Sure, getting it to regonize stuff like atmos or DD is a pita, but simple multi channel was never a problem before, so any ideas would be greatly appreciated.

Link to comment
Share on other sites

so I solved at least part of the problem with experimenting a bit more; my own stupidity  :unsure: It turns out that my reciever is well capable of doing "the right thing", IF I do not tell him to do otherwise. The selection of audio actually changes in dependency of the audio stream, so if I playback 5.1 opus it gives me the option for multi-in/PCM or multi-in plus dolby surround/PCM (because of my extra two speakers), and if I change that to a 7.1 source that option is gone and it only says multi-in/PCM. If the reciever gets a direct dd signal this changes to that as well, etc. you get the idea.

 

Now the sad part two part of this is all, that I only managed to get correct audio playback of said opus files when I installed kodi again on my firetv. playing back my files through kodi gives me 5.1/7.1 sound as I expect it. Going back to emby I have the same problem, that the voices/conversations are screwed and I do not hear shit. I would assume, because emby tries to direct feed opus to my reciever instead of putting out multi pcm? The app sadly only has the audio options "Automatic" and "Stereo". 

 

So I would really appreciate if you could think about it again if there might be a problem in the multi-channel playback options of the current emby app on fire tv, as I would rule out my reciever again, now that I made it work in principle by just switching an app and leaving the rest as is.

 

I attached a new image, you can now see, that both input and output sides have 5.1, but still the "c"/center speaker is doing NULL, so my guess is that center channels doesnt make it to the reciever, even though emby app seems to stream 5.1 multi-channel pcm

 

edit: and I just realised that the topic doesn't make any sense longer, so if you want I can stop talking about it here and start a new thread. (edit2: full editor ftw, I changed it)

post-311678-0-40248400-1552657332_thumb.jpg

Edited by Tupsi
Link to comment
Share on other sites

I'm afraid I'm kinda out of ideas.  Are you positive the center is there in the mix and not being created by some audio processing logic in other scenarios?  Grasping at straws...

 

We are directly feeding the track out:

D/EventLogger(16011):   Renderer:1 [
D/EventLogger(16011):     Group:0, adaptive_supported=N/A [
D/EventLogger(16011):       [X] Track:0, id=2, mimeType=audio/opus, channels=6, sample_rate=48000, language=eng, supported=YES
D/EventLogger(16011):     ]
D/EventLogger(16011):   ]

Can you provide me a sample?

Link to comment
Share on other sites

no clue who that other guy is, but he is not hijacking my problem :-)

 

Jokes aside, I am pretty sure that it has to be the app messing it up. As I said, playback with kodi is fine on the same hardware and once I force a transcode it is fine as well. So we could be pretty sure the center is where it should be, otherwise neither kodi nur the transcode of the emby server would have it right.

sample.zip

Edited by Tupsi
Link to comment
Share on other sites

So I just split that sample.mkv in seperate wav files with

 

ffmpeg.exe -i .\sample.mkv -map_channel 0.1.0 ch0.wav -map_channel 0.1.1 ch1.wav -map_channel 0.1.2 ch2.wav -map_channel 0.1.3 ch3.wav -map_channel 0.1.4 ch4.wav -map_channel 0.1.5 ch5.wav

 

you can hear, that the conversation only takes place in ch2, ch3 seems to be the LFE and rest is hard to distinguish as it only had surround stuff in it. But from what I hear, I would assume that all channels with the exception of ch2 are getting where they are suppose to be, as the L,R, LR, RR and LFE producing in essence what I can playback on the computer in these single wav files. So only ch2 gets somehow "lost in transmission", My center plays back nothing; it is completly dead in this test.

Link to comment
Share on other sites

Just out of curiosity I divided a working .mkv which has DD audio instead of opus. The channel mapping is exactly the same; ch2 has the center and ch3 has the LFE, rest is the L/Rs. So it is not some weird "reciever mixes up the channels because they come in different order" or something. The Center just doesnt make it to the reciever, which btw. I just realised, because when I plugin my headsets the center is still missing. The headpiece is a standard stereo one, so this always forces the reciever to mixdown any input to stereo, regardless what you select. (and needless to say, this has always worked so far).

Link to comment
Share on other sites

When I play your sample, the center and right channel appear to be reversed.  All the dialog is in my right channel and I'm getting music and background in the center.

Link to comment
Share on other sites

When I play your sample, the center and right channel appear to be reversed.  All the dialog is in my right channel and I'm getting music and background in the center.

 

you that get on a 5.1 sound system? Thats even more weird. And does that channel swapping stops when you force a transcode? Because what I still dont get is, that the emby server can handle the file just fine, but not the app.

Edited by Tupsi
Link to comment
Share on other sites

Yes, that's going to my receiver.  When you mix it down to stereo it could be a lot harder to determine where the original layout was but I haven't tried that at this point.

Link to comment
Share on other sites

Yes, that's going to my receiver.  When you mix it down to stereo it could be a lot harder to determine where the original layout was but I haven't tried that at this point.

 

true. My deduction from me stereo experiment is only that my reciever does not recieve the center at all, hence the missing audio when in force stereo playback through the headphones. Although that conclusion might be just bs from my end. At this point I am grasping for straws thats all :-)

 

You saying that you recieve the center but on the wrong speaker; isn't that pointing to something the app is doing wrong?

 

And have you tried the forced transcode in the app to see if the channels are correct then?

 

 

Is there anything you could try to motivate the app to playback that center channel in another way?

Link to comment
Share on other sites

The app isn't in control of the audio at that level.  It really seems like the source mapping is either wrong or, at least, something unexpected by the player.

 

Do you have other Opus items?  Do they all have this problem?  How were they created?

Link to comment
Share on other sites

yes, I have that with every opus audio track I have with either 5.1 or 7.1 sound. Well of course I havent tried them all, but rather given up after testing maybe a dozend. And my encoding settings havent changed much over time.

 

I use ffmpeg, usually with a rather recent built compiled directly from the git sources. Currently it is:

ffmpeg.exe -h encoder=libopus
ffmpeg version N-93431-g6dc1da416e Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 8.3.0 (Rev2, Built by MSYS2 project)
  configuration:  --disable-autodetect --enable-amf --enable-bzlib --enable-cuda --enable-cuvid --enable-d3d11va --enable-dxva2 --enable-iconv --enable-lzma --enable-nvenc --enable-zlib --enable-sdl2 --disable-debug --enable-ffnvcodec --enable-nvdec --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libdav1d --enable-fontconfig --enable-libass --enable-libbluray --enable-libfreetype --enable-libmfx --enable-libmysofa --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libwavpack --enable-libwebp --enable-libxml2 --enable-libzimg --enable-libshine --enable-gpl --enable-avisynth --enable-libxvid --enable-libaom --enable-version3 --enable-chromaprint --enable-decklink --enable-frei0r --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libfdk-aac --enable-libflite --enable-libfribidi --enable-libgme --enable-libgsm --enable-libilbc --enable-libkvazaar --enable-libmodplug --enable-libopenh264 --enable-libopenmpt --enable-librtmp --enable-librubberband --enable-libssh --enable-libtesseract --enable-libxavs --enable-libzmq --enable-libzvbi --enable-opencl --enable-opengl --enable-libvmaf --enable-libcodec2 --enable-libsrt --enable-ladspa --enable-openssl --extra-cflags=-fopenmp --extra-libs=-lgomp --extra-cflags=-DLIBTWOLAME_STATIC --extra-libs=-lstdc++ --extra-cflags=-DLIBSSH_STATIC --extra-ldflags='-Wl,--allow-multiple-definition' --extra-cflags=-DCACA_STATIC --extra-cflags=-DMODPLUG_STATIC --extra-cflags=-DCHROMAPRINT_NODLL --extra-libs=-lstdc++ --extra-cflags=-DZMQ_STATIC --extra-libs=-lpsapi --extra-cflags=-DLIBXML_STATIC --extra-libs=-liconv --disable-w32threads --extra-cflags=-DKVZ_STATIC_LIB --enable-nonfree
  libavutil      56. 26.100 / 56. 26.100
  libavcodec     58. 47.105 / 58. 47.105
  libavformat    58. 26.101 / 58. 26.101
  libavdevice    58.  7.100 / 58.  7.100
  libavfilter     7. 48.100 /  7. 48.100
  libswscale      5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
  libpostproc    55.  4.100 / 55.  4.100
Encoder libopus [libopus Opus]:
    General capabilities: delay small
    Threading capabilities: none
    Supported sample rates: 48000 24000 16000 12000 8000
    Supported sample formats: s16 flt
libopus AVOptions:
  -application       <int>        E...A.... Intended application type (from 2048 to 2051) (default audio)
     voip                         E...A.... Favor improved speech intelligibility
     audio                        E...A.... Favor faithfulness to the input
     lowdelay                     E...A.... Restrict to only the lowest delay modes
  -frame_duration    <float>      E...A.... Duration of a frame in milliseconds (from 2.5 to 120) (default 20)
  -packet_loss       <int>        E...A.... Expected packet loss percentage (from 0 to 100) (default 0)
  -vbr               <int>        E...A.... Variable bit rate mode (from 0 to 2) (default on)
     off                          E...A.... Use constant bit rate
     on                           E...A.... Use variable bit rate
     constrained                  E...A.... Use constrained VBR
  -mapping_family    <int>        E...A.... Channel Mapping Family (from -1 to 255) (default -1)
  -apply_phase_inv   <boolean>    E...A.... Apply intensity stereo phase inversion (default true)

the command line part of the audio is like this:

 

for 5.1:

-c:a libopus -b:a 256000 -af aformat=channel_layouts=5.1

for 7.1:

-c:a libopus -b:a 450000 -af aformat=channel_layouts=7.1

 

 

Link to comment
Share on other sites

so while I wrote that last reply for you I noticed the -mapping_family option and googled that as I have never changed that. Turns out that it could/should be used in order to enable proper surround mapping between channels (whatever that means). So I encoded a file again in the hops it solves the problem and in fear that I have to reencode tons of stuff, but sadly this doesnt help neither: :-(

 

The discussion on the ffmpeg dev mailing list about the patch who created the -mapping_family option back in 2016 can be found here:

 

https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195178.html

# Use the old behavior. Header contains layout, but no masking
$ ./ffmpeg -y -i in.wav -c:a opus -mapping_family -1 out.ogg

# Use libopus surround mode. Masking + automatic channel coupling
$ ./ffmpeg -y -i in.wav -c:a opus -mapping_family 1 out.ogg

# Use libopus with independent channels. No header info, no masking, no
coupling
$ ./ffmpeg -y -i in.wav -c:a opus -mapping_family 255 out.ogg

but as I said, it doenst change anything changing this from -1 (the default) to 1. As the -1 option states it contains the channel layout anyway and I have no real clue what "channel coupling" even means.

Link to comment
Share on other sites

found this in the ffmpeg docu about mapping_family. According to this, it doesnt matter if I use it or not, as it defaults to 1 for channels >2.

mapping_family (mapping_family)
Set channel mapping family to be used by the encoder. The default value of -1 uses mapping family 0 for mono and stereo inputs, and mapping family 1 otherwise. The default also disables the surround masking and LFE bandwidth optimzations in libopus, and requires that the input contains 8 channels or fewer.

Other values include 0 for mono and stereo, 1 for surround sound with masking and LFE bandwidth optimizations, and 255 for independent streams with an unspecified channel layout.

Although I do get two different files if I encode with and without it, so that must be the mentioned "surround masking and LFE optimization". In both cases I end up with 6 channels though, so we are still stuck at why I do not hear anything out of my center speaker.

Link to comment
Share on other sites

ok tried it with ffmpegs -loglevel debug to get a few more lines while encoding. To me it seems like the initial mapping is correct:

[Parsed_aformat_0 @ 000001d76536ee80] Setting 'channel_layouts' to value '5.1'
[graph_0_in_0_1 @ 000001d76536e8c0] Setting 'time_base' to value '1/48000'
[graph_0_in_0_1 @ 000001d76536e8c0] Setting 'sample_rate' to value '48000'
[graph_0_in_0_1 @ 000001d76536e8c0] Setting 'sample_fmt' to value 'fltp'
[graph_0_in_0_1 @ 000001d76536e8c0] Setting 'channel_layout' to value '0x60f'
[graph_0_in_0_1 @ 000001d76536e8c0] tb:1/48000 samplefmt:fltp samplerate:48000 chlayout:0x60f
[format_out_0_0 @ 000001d7653b0bc0] Setting 'sample_fmts' to value 's16|flt'
[format_out_0_0 @ 000001d7653b0bc0] Setting 'sample_rates' to value '48000|24000|16000|12000|8000'
[Parsed_aformat_0 @ 000001d76536ee80] auto-inserting filter 'auto_resampler_0' between the filter 'graph_0_in_0_1' and the filter 'Parsed_aformat_0'
[AVFilterGraph @ 000001d765370b00] query_formats: 4 queried, 7 merged, 3 already done, 0 delayed
[auto_resampler_0 @ 000001d7653b2040] picking flt out of 2 ref:fltp
[auto_resampler_0 @ 000001d7653b2040] [SWR @ 000001d7653b2140] Using fltp internally between filters
[auto_resampler_0 @ 000001d7653b2040] [SWR @ 000001d7653b2140] Matrix coefficients:
[auto_resampler_0 @ 000001d7653b2040] [SWR @ 000001d7653b2140] FL: FL:1.000000 FR:0.000000 FC:0.000000 LFE:0.000000 SL:0.000000 SR:0.000000
[auto_resampler_0 @ 000001d7653b2040] [SWR @ 000001d7653b2140] FR: FL:0.000000 FR:1.000000 FC:0.000000 LFE:0.000000 SL:0.000000 SR:0.000000
[auto_resampler_0 @ 000001d7653b2040] [SWR @ 000001d7653b2140] FC: FL:0.000000 FR:0.000000 FC:1.000000 LFE:0.000000 SL:0.000000 SR:0.000000
[auto_resampler_0 @ 000001d7653b2040] [SWR @ 000001d7653b2140] LFE: FL:0.000000 FR:0.000000 FC:0.000000 LFE:1.000000 SL:0.000000 SR:0.000000
[auto_resampler_0 @ 000001d7653b2040] [SWR @ 000001d7653b2140] BL: FL:0.000000 FR:0.000000 FC:0.000000 LFE:0.000000 SL:1.000000 SR:0.000000
[auto_resampler_0 @ 000001d7653b2040] [SWR @ 000001d7653b2140] BR: FL:0.000000 FR:0.000000 FC:0.000000 LFE:0.000000 SL:0.000000 SR:1.000000
[auto_resampler_0 @ 000001d7653b2040] ch:6 chl:5.1(side) fmt:fltp r:48000Hz -> ch:6 chl:5.1 fmt:flt r:48000Hz
Link to comment
Share on other sites

And why are you encoding these as Opus...?

 

because it is currently the best audio codec on the planet in the regards what you get in audio quality for file size. Same reason I use vp9 as video codec. Well at least to my subjective eyes and ears. :-)

 

But getting down a truehd 7.1 stream from something like 15GB to 500MB does the trick for me.

 

Oh and I don't want to start a war about codecs here, so just stating again that I am talking about my own experience here only.

Link to comment
Share on other sites

  • 8 months later...

ok, warming this up, because in the latest App Version its still an issue for me. In the meantime I found a solution which works for me, but it brings more evidence to the table that the emby app is doing something wrong instead of the rest of my setup.

 

I found this nice little thing here on the forum, which connects Kodi with Emby (think its called EmbyCon), which uses Kodi for playback and emby for the backend server stuff.

 

I made a new clip with lots of audio codecs in it to be able to switch on the fly between them, namely aac, eac, dts, opus, vorbis.

 

The following observations can be made when I hear the clip through my stereo headphones connected to my reciever (forcing a 2.0 downmix at the receiver).

 

1) The incoming streams are all show correctly, mostly pcm direct input for aac, opus and vorbis and direct output of eac and dts stream, so reciever shows that info in his info window)

2) aac, eac and dts always let hear the conversation in the clip fine in stereo, so I would assume that is working as intended

3) vorbis only outputs the conversation to the RIGHT side of my headphone, so I would assume the center channel does not get converted/mixed correctly

4) opus has the old issue, being that the center seems totally not there, so I hear the conversation only in fragments from what was originaly mixed into the side channels (not much)

 

Now when I unplug my headphones the above symptons are basically the same with the exception that I can not really "hear" the 3) issue as the conversation can be heared at the center

 

Second setup is playing the tracks with various audio via the Kodi/EmbyCon way and there, I always have a conversation on the center or in my headphones (kodi is configured to pass through audio, so nothing gets mixed/recoded there).

 

So my conclusion is still the same as in march that something is still odd in how the emby app is disecting opus (and even vorbis) streams it seems.

 

Please let me know if I can help debug in any way possible, as I would really like to just use the emby app in my "cinema setup".

 

Edit: just noticed the "Release Notes" sticky and have to correct that I am using version 1.7.53a which does not seem the latest, but my FireTV seems unaware of the fact that there is a newer version out somewhere.

Edited by ebr
corrected name of component
Link to comment
Share on other sites

  • 2 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...