[the-dreamer]

please don't understand me wrong. i respect your work. but it is too easy to say it was not meant to be so it will be removed. Humans are not meant to fly. but we do it. even when there are crashes. we do this anyways.

if somebody has problems with passthrough. he has to disable it. but to patronize users is not what i have learned to appreciate in kodi. Most of the time since your passthrough fix, sync was okay. problems occures mostly on ARD/ZDF i cant't remember to have problems on sky channels. but even then i rezapp and it was okay over hours.

[jjslegacy]

I am still curious on this PCM vs passthrough debate and why everyone thinks they "need" passthrough so their AVR blinky lights look good. From my reading there literally is no difference so why is everyone always passthrough paasthrough passthrough? Just curious what I don't know

[Karnis]

I am still curious on this PCM vs passthrough debate and why everyone thinks they "need" passthrough so their AVR blinky lights look good. From my reading there literally is no difference so why is everyone always passthrough paasthrough passthrough? Just curious what I don't know

I can only speak for myself, but the only reason left for me to use passthru....since apparently these new Kodi builds can decode DTS HD & True HD to multi-channel PCM...is because I have a collection of old DTS 5.1 CD's and so far thru my testing Kodi only decodes them to 2-channel PCM instead of 5.1.

I'm going to take a wild guess and say my situation ranks low, lower and lowest on the priority list...and understandably so, I get it.

So I stick with 15.2 EGL, it works for me. Very solid & does what I ask of it. Reliable passthru, solid frame rate switching, Intel HW HEVC decoding.

[noggin]

I am still curious on this PCM vs passthrough debate and why everyone thinks they "need" passthrough so their AVR blinky lights look good. From my reading there literally is no difference so why is everyone always passthrough paasthrough passthrough? Just curious what I don't know

There is metadata in the bitstreamed audio (Dialog Normalisation) etc. that allows receivers to do post processing (like loudness reduction etc.) that you can't do if you decode to PCM in Kodi, but in the main I agree with you.

[noggin]

I am still curious on this PCM vs passthrough debate and why everyone thinks they "need" passthrough so their AVR blinky lights look good. From my reading there literally is no difference so why is everyone always passthrough paasthrough passthrough? Just curious what I don't know

I can only speak for myself, but the only reason left for me to use passthru....since apparently these new Kodi builds can decode DTS HD & True HD to multi-channel PCM...is because I have a collection of old DTS 5.1 CD's and so far thru my testing Kodi only decodes them to 2-channel PCM instead of 5.1.

I'm going to take a wild guess and say my situation ranks low, lower and lowest on the priority list...and understandably so, I get it.

So I stick with 15.2 EGL, it works for me. Very solid & does what I ask of it. Reliable passthru, solid frame rate switching, Intel HW HEVC decoding.

Think DTS CDs work by effectively fooling various bits in the chain that they are CDs and DTS respectively. If you ripped them to a DTS stream in an MKV (or possibly MKA?) wrapper I suspect they'd work fine, as there would be no 'fooling' going on, though I may be wrong.

[jjslegacy]

I am still curious on this PCM vs passthrough debate and why everyone thinks they "need" passthrough so their AVR blinky lights look good. From my reading there literally is no difference so why is everyone always passthrough paasthrough passthrough? Just curious what I don't know

There is metadata in the bitstreamed audio (Dialog Normalisation) etc. that allows receivers to do post processing (like loudness reduction etc.) that you can't do if you decode to PCM in Kodi, but in the main I agree with you.

Good info - thanks appreciate it! I had always just used passthrough because it worked but have stopped since it seemed to be inconsistent between builds - just was always curious if I was missing anything.

[FernetMenta]

but to patronize users is not what i have learned to appreciate in kodi.

I certainly don't patronize you. Actually I don't even care if you use the application or not. Go and compile your own version of Kodi. It is open source. You can take the code and do whatever you think it's best for you.

[wizziwig]

I am still curious on this PCM vs passthrough debate and why everyone thinks they "need" passthrough so their AVR blinky lights look good. From my reading there literally is no difference so why is everyone always passthrough paasthrough passthrough? Just curious what I don't know

There is metadata in the bitstreamed audio (Dialog Normalisation) etc. that allows receivers to do post processing (like loudness reduction etc.) that you can't do if you decode to PCM in Kodi, but in the main I agree with you.

While I have a receiver with HDMI, I'm sure there are still plenty of users with older receivers that are limited to optical/coax surround. If you eliminate passthrough, you're forcing them to PCM stereo or reducing their quality (and increasing CPU usage) but having to decode AC3/DTS to multi-channel PCM and then re-encode back to AC3. Dropping or repeating video frames or AC3/DTS audio frames as was done on the older versions seems preferable if it doesn't happen very frequently (as is the case on Haswell or never Intel hardware that have very accurate a/v clocks).

[fritsch]

I am still curious on this PCM vs passthrough debate and why everyone thinks they "need" passthrough so their AVR blinky lights look good. From my reading there literally is no difference so why is everyone always passthrough paasthrough passthrough? Just curious what I don't know

There is metadata in the bitstreamed audio (Dialog Normalisation) etc. that allows receivers to do post processing (like loudness reduction etc.) that you can't do if you decode to PCM in Kodi, but in the main I agree with you.

While I have a receiver with HDMI, I'm sure there are still plenty of users with older receivers that are limited to optical/coax surround. If you eliminate passthrough, you're forcing them to PCM stereo or reducing their quality (and increasing CPU usage) but having to decode AC3/DTS to multi-channel PCM and then re-encode back to AC3. Dropping or repeating video frames or AC3/DTS audio frames as was done on the older versions seems preferable if it doesn't happen very frequently (as is the case on Haswell or never Intel hardware that have very accurate a/v clocks).

Guys, it's quite easy. Sync was redone completely, it is working perfectly now for PCM now. For Passthrough such a method is missing (be it IEC burstpackages) or more advanced things. You are all welcome to implement it ... Concerning the drop / dupe - this was never a solution, not for an audiophile ... dropping means "psssssst", duplicating means sending same package number twice and a high percentage (> 20) of AVRs loosing the signal.

Until the code you are running hits the streets it is > 12 months to go. So there are no excuses like "I cannot code" or "I am too lazy". If you want it perfect, exactly now is the time to stand up and contribute a feature you (!) are using ...

[scf2k]

You have a whole year to implement it. Start with learning BASIC

[FernetMenta]

While I have a receiver with HDMI, I'm sure there are still plenty of users with older receivers that are limited to optical/coax surround. If you eliminate passthrough, you're forcing them to PCM stereo or reducing their quality (and increasing CPU usage) but having to decode AC3/DTS to multi-channel PCM and then re-encode back to AC3. Dropping or repeating video frames or AC3/DTS audio frames as was done on the older versions seems preferable if it doesn't happen very frequently (as is the case on Haswell or never Intel hardware that have very accurate a/v clocks).

You did not understand the problem. Until 16.0 PVR needed pre-buffering of streams which did not work well. Buffer level was set to a default that was too small for many systems. Increasing that value made others complain because channel switching times increased as well. The problem with real-time streams is that (as the name real-time implies) they come in with the same speed as they play. Means that buffers won't fill once playback was stated. This resulted quite often in a stalled audio stream, buffering, etc. I don't call this good quality.
Now VideoPlayer starts a realtime stream as early as possible and observes buffers levels. If the stream is about to run dry, it changes playspeed slightly and buffers will fill again. This is not possible when doing passthrough.

[fritsch]

Thanks Fritsch - I will test out today.


I tried to use ffmpeg with -vf yadif=1,format=yuv420p
The resulting file was about 7x smaller so not sure this is ideal. I was hoping to maintain as close as possible an exact replica of the bluray rip.

Easily possible. I used crf 22 x264 for testing + yadif and for testing w3fdif.

I sadly don't speak ffmpeg and all of its options - what would be an example command of converting while maintaining the best quality I can? I don't care how long it runs for the most part

Thanks!

Code:

ffmpeg -i Life\ \(Mini-Series\ 2009\)part1\ \(1\)-002.mkv -c:v libx264 -preset slow -crf 20 -vf w3fdif -c:a copy output.mkv

[psysfaction]

While I have a receiver with HDMI, I'm sure there are still plenty of users with older receivers that are limited to optical/coax surround. If you eliminate passthrough, you're forcing them to PCM stereo or reducing their quality (and increasing CPU usage) but having to decode AC3/DTS to multi-channel PCM and then re-encode back to AC3. Dropping or repeating video frames or AC3/DTS audio frames as was done on the older versions seems preferable if it doesn't happen very frequently (as is the case on Haswell or never Intel hardware that have very accurate a/v clocks).

You did not understand the problem. Until 16.0 PVR needed pre-buffering of streams which did not work well. Buffer level was set to a default that was too small for many systems. Increasing that value made others complain because channel switching times increased as well. The problem with real-time streams is that (as the name real-time implies) they come in with the same speed as they play. Means that buffers won't fill once playback was stated. This resulted quite often in a stalled audio stream, buffering, etc. I don't call this good quality.
Now VideoPlayer starts a realtime stream as early as possible and observes buffers levels. If the stream is about to run dry, it changes playspeed slightly and buffers will fill again. This is not possible when doing passthrough.

This I find a very ingenious solution since I often have problems with live streams since internet in Indonesia is not very constant. I can get decent speeds when I download form my abroad server but for live streams I mostly get problems. This new way of changing play speed could solve the issue.

As long as passthrough still works for all my ripped blurays then I'm more then happy.
I am currently building a new home cinema with Atmos and would think it would be a pity to not have passthrough since it is the only way to send the metadata for Atmos to the AVR.

[jjslegacy]

Easily possible. I used crf 22 x264 for testing + yadif and for testing w3fdif.

I sadly don't speak ffmpeg and all of its options - what would be an example command of converting while maintaining the best quality I can? I don't care how long it runs for the most part

Thanks!

Code:

ffmpeg -i Life\ \(Mini-Series\ 2009\)part1\ \(1\)-002.mkv -c:v libx264 -preset slow -crf 20 -vf w3fdif -c:a copy output.mkv

Will try that today - thank you!

[redbiro]

With the newest OE-build, I have a very high cpu usage (>60%) (in the menus), with my Pentium G4400 (Skylake)

i have the same problem on my n3150, kodi-bin always stays between 40% and 60% on idle.

which logs should i have to save?
everything from the first post?

Code:

dpkg -l |grep mesa | pastebinit
DISPLAY=:0 vainfo | pastebinit
cat ~/.kodi/temp/kodi.log | pastebinit
dmesg | pastebinit