(2015-12-24, 19:56)jjslegacy Wrote: 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

(2015-12-24, 19:56)jjslegacy Wrote: 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

(2015-12-24, 20:28)Karnis Wrote:

(2015-12-24, 19:56)jjslegacy Wrote: 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.

(2015-12-24, 20:36)noggin Wrote:

(2015-12-24, 19:56)jjslegacy Wrote: 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.

(2015-12-24, 19:45)the-dreamer Wrote: but to patronize users is not what i have learned to appreciate in kodi.

(2015-12-24, 20:36)noggin Wrote:

(2015-12-24, 19:56)jjslegacy Wrote: 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.

(2015-12-25, 03:29)wizziwig Wrote:

(2015-12-24, 20:36)noggin Wrote:

(2015-12-24, 19:56)jjslegacy Wrote: 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).

(2015-12-25, 03:29)wizziwig Wrote: 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).

(2015-12-24, 17:18)jjslegacy Wrote:

(2015-12-24, 17:09)fritsch Wrote:

(2015-12-24, 17:07)jjslegacy Wrote: 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!

(2015-12-25, 10:54)FernetMenta Wrote:

(2015-12-25, 03:29)wizziwig Wrote: 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.

(2015-12-25, 17:16)fritsch Wrote:

(2015-12-24, 17:18)jjslegacy Wrote:

(2015-12-24, 17:09)fritsch Wrote: 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

(2015-12-24, 12:50)dirtydesaster Wrote: With the newest OE-build, I have a very high cpu usage (>60%) (in the menus), with my Pentium G4400 (Skylake)

Quote:

Code:

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