Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

video: add a default frame latency of 1 frame #2087

Open
wants to merge 1 commit into from

4 participants

@elupus
Collaborator

This is configureable in adancedsettings under video/latency/frames.
The default value should correspond to a A/V delay of -16ms at 60 hz
and -41ms at 24hz

Most video output will be counting it's delay in times of frames, not
in absolute time. Any advanced frame processing on normal TV's will
at least incure a 1 frame delay.

@elupus elupus video: add a default frame latency of 1 frame
This is configureable in adancedsettings under video/latency/frames.
The default value should correspond to a A/V delay of -16ms at 60 hz
and -41ms at 24hz

Most video output will be counting it's delay in times of frames, not
in absolute time. Any advanced frame processing on normal TV's will
at least incure a 1 frame delay.
b59ba8c
@fritsch
Collaborator

I think this is quite confusing for new users now. Most look at the lips moving and estimate the delay roughly and write it to advancedsettings.xml

Your patch uses a "linear" model, meaning 24hz: 1/24 seconds delay and for 60hz 1/60 seconds delay. In theory this could help to only set the latency once - but as real life has prooved: 24hz modes does not linearly compare to 60hz. Most displays "tested" do a lot of more delay when in 24hz or 23.98hz mode.

So the user ends up the same as before - specifying multiple delays, but only the values differ.
So I don't see the advantage in real life environment, only more confusion, cause of an additional setting - how should one measure 2/60 vs. 4/60 delay?

The best way would be to use the hdmi spec to identify the delay that TV and computer communicate within this protocol.

Some tests by users concerning delay and audio / video sync: http://forum.xbmc.org/showthread.php?tid=141646

Collaborator

yes hdmi info would be best. but i doubt that is correct in many cases.

I do understand that for anybody that have set a global delay using this not standard way ( you could have done it in gui ), this changes what they had calibrated, but it does this for EVERYBODY else too -> rather controversial change.

The point here is really that we have been doing this wrong for a long time. We have not taken into account that we have frame delay of at least one frame leading to always being quite off for low HZ modes.

Do note i've not removed the ability to override for a specific frame rates (and this won't take affect if you have set the delay specifically for a frame rate). But i'mho the linear y = kx + m should be enough for most cases.

I'll look through that thread thou.

Collaborator

Right.. it seems about like what i had expected. 200ms is what i have to set as offset on my system at 24hz. Some people don't seem to experience it. Do not there is another MAJOR issue at play there too. The frame delay is technically dynamic.

If we render video with a fps >= HZ we will fill upp all video buffers in the video HW. This could be something like 3 frames (ie a setting of 3). while when we play a videos with fps < HZ, we will have empty HW buffers -> 1 frame delay.

Thus to solve this fully we'd need to take that into account if the video we are playing are causing HW buffers to fill, or remain drained.

Collaborator

Ps.. this is why there is such a big difference between 24 and 23.97 hz modes.

Collaborator

I am completely with you and I read the patch, so I pretty know the old delay method is still there. In my oppinion I would do the 1/refreshrate as default - just remove the advancedsetting. It will improve the situation for the "standard delay" people. The 60hz fraction won't realize any change or can you really see 1/60 seconds delay?

My problem is only with the advancedsettings.xml - If users start to misuse this setting for the global delay. I find it hard to set values in frames, that cannot be measured (in frames), so you start thinking in seconds (ms) again and just calculate in fps.

Collaborator

well if you think in delay and calculate based on current hz you will still set it right :). Advanced settings are not really for users. It's for very advanced users for helping to "debug" out a better new default.

I even think we should have a value of 2 as default. But I'm not sure I can get that accepted :). So it need to be possible to calibrate for now.

We really need sample video's for user to run through on different resolutions, then calculate these values auto.

Collaborator

note: https://github.com/elupus/xbmc/commits/vqueue would likely solve the issues with the 24fps filling up hw buffers. But i've not worked on it for quite some time now.

Collaborator

We build such a measurement system at work to be able to calculate delays. Cause - we were interested in deflecometric analysis, we must be really sure when a pattern we send actually is on screen. For this purpose a Pandaboard was chosen to directly interfer with the LVDS. When you now have to same setups with one external trigger for the same signal you can measure the difference.

The above thread I linked, was created during the OpenELEC 2.0 release, cause a lot of users complained. After evaluating those results, we set a default delay of 175ms for 23< x <= 24. It was not easy to get unflamed measured values.

Collaborator

Right.. but as you can see from the reports. at 24hz with a 23.9.. movie, you don't get a delay that large. That is the major problem really, we always get several extra frames delay when fps is same as hz. Also there is no guarantee that the hz you ask the video hw to render at is what you actually exactly get, thus we can't really rely on fps of movie and configured hz of display.

The only real solution is to know how much is queued up for display.

Collaborator

Looking at your patches, really shortly only: I would trust the hpet, yes - but I would not trust the VBlank. So better using the hpet, to actually measure if the vlank is done correctly (Triple Buffering and such stuff are also a pain on Linux).

Collaborator

@FernetMenta has done a lot of stuff into this direction. From verifying the "swapBuffers" to video buffers for the player - to be able to get images on screen in sync and being able to have enough in the queue to get the images out quite fine.

Been looking forward on you two if you do this great improving stuff alltogether after the frodo release. Watching the queue + having a buffer + watching the output - should be a great new world and a new level of xbmc experience.

@FernetMenta
Collaborator

I would avoid setting default delays as long as we have not fixed other issues like wrong calculation of audio delay. For pass through audio is LATE approx 30-50 ms at 50 Hz on my system. I am quite sure that this is not caused by decoding (DAC) because I lose 1-2 secs of audio when config changes e.g. from 5.1 to 2.0. (commercial breaks)

@elupus
Collaborator
@FernetMenta
Collaborator

This is SoftAE (ALSA) with AC3 (no transcoding). When using pass through config changes are smooth but audio is way too late (sometimes > 100ms). When using no pass through audio is in sync but on most commercial breaks the last 2 secs of audio are cut off. Seems that draining does not work properly.

@FernetMenta
Collaborator

@elupus I asked someone with almost identical setup than mine for his observations and he does not notice this huge audio lag when using pass through.
We both have NVidia GT520M, the difference is that my Samsung TV only reports 2 channel audio and 48khz.
His LG is capable of 6 channels and hbr.

@elupus
Collaborator
@FernetMenta
Collaborator

Yes we do.

@MartijnKaijser

@elupus / @FernetMenta
still needed? i want to cleanup up the long lasting PRs

@elupus
Collaborator
@FernetMenta
Collaborator

setting it to 0 is a good idea until we better understand those a/v sync issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jan 16, 2013
  1. @elupus

    video: add a default frame latency of 1 frame

    elupus authored
    This is configureable in adancedsettings under video/latency/frames.
    The default value should correspond to a A/V delay of -16ms at 60 hz
    and -41ms at 24hz
    
    Most video output will be counting it's delay in times of frames, not
    in absolute time. Any advanced frame processing on normal TV's will
    at least incure a 1 frame delay.
This page is out of date. Refresh to see the latest.
View
4 xbmc/settings/AdvancedSettings.cpp
@@ -112,6 +112,7 @@ void CAdvancedSettings::Initialize()
m_DXVANoDeintProcForProgressive = false;
m_videoFpsDetect = 1;
m_videoDefaultLatency = 0.0;
+ m_videoFrameLatency = 1;
m_musicUseTimeSeeking = true;
m_musicTimeSeekForward = 10;
@@ -625,6 +626,7 @@ void CAdvancedSettings::ParseSettingsFile(const CStdString &file)
// Get default global display latency
XMLUtils::GetFloat(pVideoLatency, "delay", m_videoDefaultLatency, -600.0f, 600.0f);
+ XMLUtils::GetInt(pVideoLatency, "frames", m_videoFrameLatency, -60, 60);
}
}
@@ -1195,6 +1197,8 @@ void CAdvancedSettings::AddSettingsFile(const CStdString &filename)
float CAdvancedSettings::GetDisplayLatency(float refreshrate)
{
float delay = m_videoDefaultLatency / 1000.0f;
+ if(refreshrate)
+ delay += m_videoFrameLatency / refreshrate;
for (int i = 0; i < (int) m_videoRefreshLatency.size(); i++)
{
RefreshVideoLatency& videolatency = m_videoRefreshLatency[i];
View
1  xbmc/settings/AdvancedSettings.h
@@ -157,6 +157,7 @@ class CAdvancedSettings
std::vector<RefreshOverride> m_videoAdjustRefreshOverrides;
std::vector<RefreshVideoLatency> m_videoRefreshLatency;
float m_videoDefaultLatency;
+ int m_videoFrameLatency;
bool m_videoDisableBackgroundDeinterlace;
int m_videoCaptureUseOcclusionQuery;
bool m_DXVACheckCompatibility;
Something went wrong with that request. Please try again.