Smoothvideo branch

Hitcher Wrote:Thanks, I'll try it out later and report back.

What V-Sync option do I need to choose?

I have it on 'Always Enabled', the debug log shows it to be enabled in that case. Haven't tried the other modes.

alanwww1 Wrote:@Bobo1on1:

For me the branch is pretty stable and works ok most of the time. When do you think it will be merged to main trunk ?

What issues are you working on currently ?

I think what could be improved is the way sound "catches" up with the video so that when i start, pause, skip the video the pitch gets funny low of high for about 10 secs. On win Reclock it is solved so that until the sound gets in sync with video, the player plays the original sound in the original speed. Than it switches to the sound with the adjusted speed. But this is only until it detects all things in the beginning.

What i don't understand is why it needs to catch up again when i pause or skip the video. I mean until that time, the player could know the refresh rates, framerates, video clock rates.

Anyway, thanks for the great work. Now i don't have to watch at panning screens whether i loose frames or not. I see all the frames all the time. It is really great.

That has to do with syncing the dvdclock, normally that's synced to the audio but I'm syncing it to the video, the code is a bit complicated so I didn't get around to fixing that. It's usually synced in a few seconds so it's not a big issue.

A bigger problem is that dvd's don't have good timestamps, so the Goa`ulds might pay a visit from time to time. Mpeg4 plays fine.
What I've noticed on linux with nvidia is sometimes a flip is missed, turning on triple buffering helps a lot with that as you're allowed to catch up again, sadly that causes tearing when not using smoothvideo.

Still only runs at the XBMC start up refresh rate.

I just try a recent build of smoothvideo branch. First of all I'm impressed as everything worked out of the box (linux with nvidia hardware). Videos were adapted when I set my TV to accept 24Hz and 50Hz. Nice!

A couple of problems note reporting:

1. As previously commented, sound was funny until it catched up with the new framerate (around 5-10 secs). It might be better to use the original sound until matched and then do the switch

2. When playing 23.976fps videos at 24Hz refreshrate audio was out of sync with video (around 200ms). This also happens with trunk (see this post http://forum.xbmc.org/showthread.php?tid=41185 or this trac ticket http://trac.xbmc.org/ticket/5755). I just thought that the way smoothvideo changes both framerate and audio sampling I was going to finally get rid of that sync problems

In any case, Keep the good work!

I submitted a small and ugly patch for smoothing the audio/video sync thing a little bit:

http://trac.xbmc.org/ticket/6125

It's tested only with PAL DVD-Video (that's what I'm using it for) but maybe it's useful for somebody else.

Given your familiarity with secret rabbit code (SRC)...

Quote:1. Can you add settings that allow xbmc to upsample audio (in both music and video) to a user defined value? For example, if my DACs support 192 KHz in stereo and 96 Khz in 7.1, then it would be nice to utilize that capability. It is far preferable to handle this on a relatively powerful CPU (with a good algorithm like SRC) vs. having a sound card resample with a much slower DSP! Even most receivers (<$1k) would lag far behind secret rabbit code upsampling on a modern CPU.

2. Of course, upsampling is most appropriate when also able to utilize a user selected quality level. As libsamplerate can be highly CPU intensive for 'audiophile' levels, it would be good if XBMC offered different user selectable quality levels for Music and Video playback (defaults could be Music = higher quality [bestsinc] and Video = lower quality to allow software video decode).

3. Slightly off topic, but if Xbmc was able to load the entire audio file (or a substantial portion for video) into RAM then jitter could be minimized. Beyond eliminating jitter in audio and video, the HDD could spin down during music/movie playback to eliminate noise and heat. Given the move towards 64 bit Core i7 systems with up to 24 GB RAM on MicroATX (Asus, DFI), the user could select the amount of RAM that XBMC should utilize, or a suggested amount could be part of a setup routine at install.

4. With a near perfect waveform and noisefloor using the above methods, XBMC must then avoid windows XP meddling with perfection. When windows mixer muddles the noise, it does so with a dynamic range of 92 db. In contrast, secret rabbit code has an SNR of 143 db at highest quality levels! XBMC needs to play well with WSAPI (vista/windows7) and Kernel Streaming (XP) to avoid having poor drivers resample/remix to a khz and bit level supported by an HDMI connection or sound card DAC (96/192 khz 24 bit).

The above 4 enhancements combined with xbmc's great GUI would make for an audio/videophile level system. As it is now, XBMC holds back even the best hardware in terms of sound and video quality. With the right combination of code (like libsamplerate) and hardware, the PC can be a much better AV platform than dedicated machines. A $1000 PC will rival $20k 'audio/videophile' gear - and the GUI will be leagues ahead.

The 'audible click' found during non-libsamplerate processing that only utilizes drop/repeat packet methodology (ie when passing through to DTS/AC3 receiver) is a perfect example of why processing should take place within a system that processes both video and audio.

In any scenario, bitrate passthrough (where audio is processed separately on a receiver) is severely compromised compared to an SRC approach that corrects video in an intelligent manner (knowing monitor refresh rates, etc). Furthermore, if using anything like the ATI 3xxx series graphics cards, 'bitperfect' only gets worse as the HDMI driver mangles 96/192 khz 20/24 bit multichannel material to 48 khz/16 bit stereo! In that scenario, it's far better to have the option of downsampling with libsamplerate which has far superior algorithms than widows/linux HDMI drivers.

Given the potential upside of libsamplerate and the downside of 'passing the buck' (see ATI 3xxx series), upsampling rather than bit streaming should be advertised as the better feature in 9.04.

Edit:
The Holy Grail is to implement something like Audyssey Room Correction in XBMC - either on a dynamic real-time basis or with P2P shared movie/music file profiles that are muxed with a room profile. That's where the benefit of multicore systems would make Xbmc a system without peer!

I see the branch is cleaned and reopened by Spiff

"branch for re-development of smoothvideo"

Is it because vdpau baranch was merged into the main branch ?

That would really be awsome if vdpau could work with smoothvideo.

bobo wanted to start over. no other reason (but yes, it also brings vdpau into there)

spiff Wrote:bobo wanted to start over. no other reason (but yes, it also brings vdpau into there)

Great news. Thanks. We're here to test.

Yes I started over, the forced flip thing wasn't going to get any better and I've tried some other things that look very promising.

dmidi Wrote:Given your familiarity with secret rabbit code (SRC)...
The above 4 enhancements combined with xbmc's great GUI would make for an audio/videophile level system. As it is now, XBMC holds back even the best hardware in terms of sound and video quality. With the right combination of code (like libsamplerate) and hardware, the PC can be a much better AV platform than dedicated machines. A $1000 PC will rival $20k 'audio/videophile' gear - and the GUI will be leagues ahead.

That's not really my department, but masteraudio will possibly get a resampler based on libsamplerate so eventually I'll have to use that to prevent resampling twice.