[da-anda]

@FernetMenta - I'm also one of the users that need SPDIF passthrough to get anything 5.1 to their AVR and I'm not going to buy a new AVR. So far, I only had "adjust display refresh rate to match video" along with "passthrough" enabled and never "sync playback to display". My experience was good so far, and if frame drops occured, I never noticed them visually. As long as this scenario is still possible, all is good on my end

However, I was wondering when using "sync playback" along with "passthrough", if on supported streams formats we could decode, adjust clock and re-encode into a SPDIF compatible format (DTS, eAC3). We already have support to convert 5.1 FLAC/PCM to AC3 (which is quite nice) so technically it should be possible (given HW is powerful enough I guess). Do you think this would be an option for us SPDIF users? I think we could detect the SPDIF usecase quite easily by the number and type of passthrough formats enabled so that we don't need yet another setting. And as soon as any HD audio format is enabled for passthrough or we know it's a LPCM capable device, we do whatever we do now. Does this make any sense to you?

[FernetMenta]

I did not change the transcoding case. If you play DTS with transcoding enabled, the stream gets decoded and encoded to AC3. Now the same happens for AC3 streams.

[da-anda]

so with "sync playback to display", "passthrough" and "transcoding" enabled, one still get's AC3 output, but with adjusted audio?

[FernetMenta]

so with "sync playback to display", "passthrough" and "transcoding" enabled, one still get's AC3 output, but with adjusted audio?

yes, that's the design. if it does not work, there's a bug somewhere.

[da-anda]

now that is pretty neat, will give it a try

[voochi]

While I agree it can't work perfectly, with some receivers it did work completely usably.
I've had passthrough and sync playback to display enabled together for most of the last two years.
I've never heard an audio glitch from my receiver with normal files.

I understand that dropping or duplicating a passthrough packet may produce an audio glitch, but most receivers make a good job of hiding that.
With mine (Onkyo 609) I couldn't detect it.

There may be other use cases that make the dropping/duplication far more common (live streams or 24fps->25fps speedup) but many users don't rely on those.

I have also used "sync playback to display" with passthrough audio for many years with no issue. I have a pre-HDMI AVR, so I use spdif for multi-channel.

When playing 23.976fps content on my TV in 24p mode, for whatever reason my video clock is 23.971. It's a small sync difference, but enough to cause problems. If we sync to the audio clock then video frames need to be duped periodically and a duped video frame in 24p mode is very noticeable due to the long duration of each frame (41.6ms). For me it's unwatchable.

If we sync to video clock then audio packets need to be dropped periodically. In theory this can cause audio glitches but due to the short length of audio frames (10.67ms for DTS) and the small nature of my sync difference, I have never noticed any audio glitches. So this is very watchable and in fact unnoticeable.

I don't understand why this feature has been removed. For me it's the difference between watchable and unwatchable. Decoding, resample and then encoding to AC3 is not a viable alternative from an audio quality perspective.

[FernetMenta]

When playing 23.976fps content on my TV in 24p mode, for whatever reason my video clock is 23.971.

Crappy NVidia drivers use 23.971 instead of 23.976 but this can be tweaked.

[voochi]

Crappy NVidia drivers use 23.971 instead of 23.976 but this can be tweaked.

Thanks for the suggestion, I used this xorg.conf and I seem to have 23.976 now (or very close). I guess in that case I don't care about sync playback to display any more.

[meccs]

So basically, if your AVR supports LPCM 5.1 then there is no reason to use passthrough? Set Kodi Audio to 5.1 over HDMI and let it do its thing, the result should be the same or better?

[Drag0nFly]

I'm more or less in the same boat as @wsnipex, @popcornmix, @un1versal, et al. – To me having a passthrough option with drop/dupe is an absolute show-stopper to ensure a proper experience. I have been relying on this functionality–which has worked without audible impact or glitches–for years. I can see the rationale for having things done in a more correct/cleaner way, but this is basically removal of functionality which many users have come to rely on.

Transcoding streams to PCM5.1 does indeed work quite well for users on HDMI (although Dolby Atmos and DTS:X streams would lose its metadata in the process); but not so much for users relying on S/PDIF as their primary output, as too much quality, in addition to the abovementioned metadata, is lost in the process. As I'm sure many are aware a DTS track is 1.5 Mbit/s, whereas the re-encoded AC3 streams are 640 kbit/s.

It would be good to at least leave an option, enabled only via expert settings, with a message that this is not the recommended/optimal way of passing the audio.

Indeed, I have had this combo just fine as well with no glitches, not all AVRs and HTPCs combos have this issue like you say.

Smooth video aka "sync playback to display" was designed to change audio speed up to 5%. It was never supposed to work with passthrough audio. The fact that you abused this setting does not make it a valid option. There are many systems like Intel pre-Haswell that can't do refresh rates of 23.976 and on those systems this combo would fail.

I have to address this point, as it seems to be a common misconception with 2nd & 3rd-gen iCPUs. I have been running proper 23.976 on Intel Ivy Bridge / HD4000 ever since the /excellent/ commit which got rid of the rounding magic was applied – certainly one of the better results of a code cleanup. This, together with the fractional refreshrate support which Intel added a bit earlier along with a proper Xorg modeline ensures 23.976 output is sent to my PJ.

This was such a huge improvement when it was added, and made Kodi my player of choice for basically all new material. Blu-ray purchases went straight to the RAID before even playing them on an actual disc-loading device (both of which have remained powered off for quite some time.)

However, even with the proper Xorg modeline and the correct drivers there is still need for a small sync adjustment; in my case a 10ms packet drop approx. every ~20 secs. Again, this has not been noticeable in my setup, and I am quite picky when it comes to audio glitches/video judder and the like.

Removing passthrough would diminish this experience significantly, even if the solution as it stands now is suboptimal from a coding perspective.

I feel it is unfortunate the direction that Kodi now appears to be taking. The objective should be to make it both better and more inclusive at the same time, rather than to assume too much and remove functionality that is appreciated by many.

This is not to say I feel the efforts of the Kodi devs are unappreciated – I have had several bugs in the past which have been resolved expeditiously and where my concerns have been met with understanding, many of which were handled by @FernetMenta, so don't take this as undue criticism. Kodi is still a solid piece of quality sw, and I just hope it remains that way (and doesn't take too much inspiration from systemd when it comes to unnecessary & enforced core behavioral changes.

[FernetMenta]

I say it again very clear. I won't re-add crap that I took out for some reason. It won't happen no matter how long and frequently you may post here (without having read: http://forum.kodi.tv/showthread.php?tid=245680)

On the other hand I mentioned quite some times what the alternatives are to crappy drop/dupe. Stop whining and try to be constructive. VideoPlayer gets transformed into something better. This can't be done in a single iteration. Feel free to stay with pre v17 as long as you want.

And again: This is the development section of the forum. Read my sticky post and refrain from writing things like " I want to have my crappy feature back". I am tired reading those. If you want to post here, start discussing architecture and design. Discuss how things can be improved.

[furii]

Transcoding streams to PCM5.1 does indeed work quite well for users on HDMI (although Dolby Atmos and DTS:X streams would lose its metadata in the process); but not so much for users relying on S/PDIF as their primary output, as too much quality, in addition to the abovementioned metadata, is lost in the process. As I'm sure many are aware a DTS track is 1.5 Mbit/s, whereas the re-encoded AC3 streams are 640 kbit/s

a) if you're on spdif you're not getting the metadata regardless
b) there is no perceptible difference between 1.5mbit dts and 640kbps ac3

[lmyllari]

If you want to post here, start discussing architecture and design. Discuss how things can be improved.

I suggest framerate conversion by blending frames. That way users that can not match the video framerate exactly can use the highest available refresh rate (and passthrough if desired).

My interest in this is 25/50fps video playback on American TVs which usually don't support 50/100Hz refresh rate (or even accept a 50fps input signal). It would also help those with PC monitors.

I have been thinking about adding a new pass to video rendering, so with all the features (colorspace conversion, hq scaling, frame blending, 3dlut, dithering) in use it would look like this:

1. yuv to rgb conversion, output to fbo
   
2. scaling, output to fbo (and keep the fbo for future blending)
   
3. blending with fbo from previous frame, 3dlut and rgb level conversion, dithering, output to display
   

The potentially expensive scaling is done only once per video frame, but blending is not done in display colors. For more accuracy, yuv2rgb could decode gamma and output linear rgb, and gamma encoding could be done after blending. Using linear rgb for scaling might improve scaling quality too.

I think I know how to do the gl renderer changes, but not yet how to modify the player. I'd need to find out when the next video frame should be output between the next two vsyncs and have the renderer output a blended frame.

The refresh rate should be selected to minimize the time blended frames are displayed between untouched frames.

@FernetMenta, how would you feel about this? I think the interface between player and renderer can be made clean, but I don't know how the player would be affected - especially the a/v sync.

[Jdiesel]

If you want to post here, start discussing architecture and design. Discuss how things can be improved.

I suggest framerate conversion by blending frames. That way users that can not match the video framerate exactly can use the highest available refresh rate (and passthrough if desired).

My interest in this is 25/50fps video playback on American TVs which usually don't support 50/100Hz refresh rate (or even accept a 50fps input signal). It would also help those with PC monitors.

I have been thinking about adding a new pass to video rendering, so with all the features (colorspace conversion, hq scaling, frame blending, 3dlut, dithering) in use it would look like this:

1. yuv to rgb conversion, output to fbo
   
2. scaling, output to fbo (and keep the fbo for future blending)
   
3. blending with fbo from previous frame, 3dlut and rgb level conversion, dithering, output to display
   

The potentially expensive scaling is done only once per video frame, but blending is not done in display colors. For more accuracy, yuv2rgb could decode gamma and output linear rgb, and gamma encoding could be done after blending. Using linear rgb for scaling might improve scaling quality too.

I think I know how to do the gl renderer changes, but not yet how to modify the player. I'd need to find out when the next video frame should be output between the next two vsyncs and have the renderer output a blended frame.

The refresh rate should be selected to minimize the time blended frames are displayed between untouched frames.

@FernetMenta, how would you feel about this? I think the interface between player and renderer can be made clean, but I don't know how the player would be affected - especially the a/v sync.

I personally would use this feature. I am sick of dealing with 23.976/24p sync issues and can never seem to nail down the right amount of delay with my equipment. Outputting everything to 50/60Hz with frame blending really works well, based on my experience with madVR's smooth motion implementation, with only a very slight reduction in picture sharpness but a huge reduction in 3:2 pulldown judder. Not having to wait for refreshrate switching is an added bonus, especially for those with displays that are slow to switch. I don't have any technical knowledge to provide but think that this could be a very good feature if implemented properly.

[FernetMenta]

@lmyllari excellent idea. please open a new thread for this topic.