Bug 77009 - 24P playback video signal loss with latest DRI patches
Summary: 24P playback video signal loss with latest DRI patches
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-03 14:56 UTC by Garrett
Modified: 2014-05-08 19:01 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
xrandr verbose and dmesg +/- problem (8.58 KB, application/binary)
2014-04-03 14:56 UTC, Garrett
no flags Details
Possible fix. (1.08 KB, patch)
2014-04-04 11:59 UTC, Christian König
no flags Details | Splinter Review
dmesg after switching to 25hz and back to 24hz (62.42 KB, text/plain)
2014-04-04 17:49 UTC, Rackow, Detlev
no flags Details
Xorg.0.log after switching to 25hz and back to 24hz (90.82 KB, text/plain)
2014-04-04 17:49 UTC, Rackow, Detlev
no flags Details
xrandr 1920x1080x23.98 working 76564 removed (61.87 KB, text/plain)
2014-04-05 22:44 UTC, Garrett
no flags Details
patch that breaks by 23.98 playback (8.58 KB, text/plain)
2014-04-05 22:46 UTC, Garrett
no flags Details
fixed with patch dmesg (61.84 KB, text/plain)
2014-04-06 04:02 UTC, Garrett
no flags Details
the combined full patch needed to fix it (8.63 KB, text/plain)
2014-04-06 04:13 UTC, Garrett
no flags Details
dmesg after switching to 25hz and back to 24hz, 2nd attempt (61.63 KB, text/plain)
2014-04-06 21:00 UTC, Rackow, Detlev
no flags Details
Xorg.0.log after switching to 25hz and back to 24hz, 2nd attempt (69.19 KB, text/plain)
2014-04-06 21:01 UTC, Rackow, Detlev
no flags Details
v3 patch merged with this max patch dmesg (61.93 KB, text/plain)
2014-04-07 00:32 UTC, Garrett
no flags Details
368 and others dmesg (18.21 KB, application/octet-stream)
2014-04-07 15:45 UTC, Garrett
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Garrett 2014-04-03 14:56:03 UTC
Created attachment 96854 [details]
xrandr verbose and dmesg +/- problem

This patch [https://bugs.freedesktop.org/show_bug.cgi?id=76564] appears to have broken my 24P playback which has been fine until now.  My set is a Sony KDL 40NX711 NTSC set, PC A4-3400 - HDMI to set for vid/audio stereo out speakers.  Using Openelec- gotham nightlies (this patch is now comitted to OE-nightlies):
Playing 29.97i/59.94 plays fine enough (a few skips- why I am testing this patch), 23.976 playback breaks the TV display- it starts to buzz then says "no signal", I press stop and the menu/screen resumes at ~30P like normal.

"xrandr --output HDMI-0 --mode 1920x1080 --rate 23.98" - does the same thing, lcd loses video signal and buzzes.

I am attaching the dmesg/xrandr --verbose logs w/ drm.debug=0xe both working w/o patch and broken w/patch.
Comment 1 Christian König 2014-04-03 16:03:19 UTC
Good:
  1920x1080 (0x59)   74.2MHz +HSync +VSync
        h: width  1920 start 2558 end 2602 total 2750 skew    0 clock   27.0KHz
        v: height 1080 start 1084 end 1089 total 1125           clock   24.0Hz

Bad:
  1920x1080 (0x59) 74.176MHz +HSync +VSync
        h: width  1920 start 2558 end 2602 total 2750 skew    0 clock  26.97KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  23.98Hz

It actually looks like the 23.98 fps mode was rounded to 24fps before and never really worked correctly.

Are you sure my patch is the only difference in the system? Cause my patch shouldn't have that effect.

Can you build a kernel separately and check that this is really the root cause of it?

Thanks in advance,
Christian.
Comment 2 Garrett 2014-04-03 21:06:25 UTC
Hi Christian. Thanks for your help.  They are not 100% the same.  I hope that I am not misleading you.  My, aplogies in advance, if it works out to be so.

xorg3.15, Kernel 3.13.7 vs. 3.14

Precompiled Openelec builds:

working:
xorg 3.15, Kernel 3.13.7, no patch
http://xbmcnightlybuilds.com/openelec-generic-x86_64-r18022-g4473271-download/

Not working:
xorg 3.15, Kernel 3.14, patch
http://saraev.ca/OpenELEC-Generic.x86_64-devel-20140330151700-r18049-g02739c3.tar

Tonight I will make a new build environment to test PURELY the patch/un-patch.  I am a bit new to building kernel Dri/Drm modules.  But I should be able to figure it out.

HUMM:   
clock   24.0Hz  good
clock  23.98Hz  bad

It might be that my LCD does not like 23.98?  Thanks.  I will post back with the results.
Comment 3 Christian König 2014-04-04 11:59:27 UTC
Created attachment 96900 [details] [review]
Possible fix.
Comment 4 Christian König 2014-04-04 12:06:30 UTC
(In reply to comment #2)
> Hi Christian. Thanks for your help.  They are not 100% the same.  I hope
> that I am not misleading you.  My, aplogies in advance, if it works out to
> be so.

No problem at all. It's still quite likely that my patch is the source of the problem.

> xorg3.15, Kernel 3.13.7 vs. 3.14

We should just make sure that it is indeed the only change in the system and we don't have an issue like two patches affecting each other or something like that.

Beeing based on kernel 3.13.7 vs. 3.14 for the two versions sounds like we should make that sure first.

> Tonight I will make a new build environment to test PURELY the
> patch/un-patch.  I am a bit new to building kernel Dri/Drm modules.  But I
> should be able to figure it out.

Let me know if you need any help.

> It might be that my LCD does not like 23.98?  Thanks.  I will post back with
> the results.
Might be, but I would rather guess that the PLL isn't stable enough any more with my changes.

When the values get higher you usually get better matching results, but the electrical signal also gets more unstable. Your LCD is probably just a bit picky what signal it gets as input.

I've attached a patch that artifically limits the dividers and so might produce better results. Please try it and report back if that changes anything.
Comment 5 Garrett 2014-04-04 14:18:39 UTC
Thanks for the patch.  As of this am, I now have local Openelec 4.0 code that builds now and is affected.  Building it took overnight on an i5- full OS/OE/XMBC/Kernel...  It will take some build time, so over this weekend I will try to collect all of the data.  +/- patches.
Comment 6 Rackow, Detlev 2014-04-04 17:45:28 UTC
Hi, I also have issues with OE 3.95.x and Radeon 6320 (AMD E-450). On my device, issues happened with all fractional frequencies (23.9x, 29.9x, 59.9x hz)

The test-version which Peter Fruehberger posted and which contains your preliminary patch changed the behaviour.

With that new patch fractionalmodes (23.976, ... , ... ) are now working
fine, but with 25hz I have a problem. (Peter supposes that it's actually 50i and I believe this too, but I'm just a user and I can only report the frequency that I select in the XBMC-settings)

When I set the rate to 25Hz, the picture begins to shiver up and down a few millimeters. When I don't acknowledge the new rate, XBMC switches back to the old rate, and the picture is immediately stable as ever. 

This effect used to happen with all fractional rates in OE 3.95.x, while 25Hz worked fine. With the mentioned test-version it is gone on the fractional rates, but now it happens on 25Hz (or 50i, as Peter says).

As instructed, I booted OE with the kernel-parameter drm.debug=0xe and took dmesg and Xorg.0.log immediately after switching to 25hz and falling back.

This is my first post on this site, I hope I don't mess it ;)
Comment 7 Rackow, Detlev 2014-04-04 17:49:07 UTC
Created attachment 96914 [details]
dmesg after switching to 25hz and back to 24hz
Comment 8 Rackow, Detlev 2014-04-04 17:49:40 UTC
Created attachment 96915 [details]
Xorg.0.log after switching to 25hz and back to 24hz
Comment 9 Christian König 2014-04-04 18:10:29 UTC
(In reply to comment #7)
> Created attachment 96914 [details]
> dmesg after switching to 25hz and back to 24hz

Those logs doesn't contain a mode switch, are you sure you actually grabed the right log?

Please also try changing the mode directly from the command line with xrandr.
Comment 10 Garrett 2014-04-05 22:44:13 UTC
Created attachment 96962 [details]
xrandr 1920x1080x23.98 working 76564 removed

OK.  I finally got the patch removed and rebuilt (thanks to Peter's tips).  Xrandr 23.98 now works as expected.  No blank screen:
[   99.956862] [drm:radeon_compute_pll_avivo], 14818, pll dividers - fb: 32.6 ref: 2, post 11

With the patch "linux-996-drm-radeon-rework-finding-display-PLL-numbers.patch" it failed.  I will upload this patch, that I removed from the source folder.  I tried the 3 line patch x2, when it was present but I am not sure it took (built to fast to see on the screen).  So I will add the 3 changes to non-working patch and rebuild, next. and dmesg it for pll vals.
Comment 11 Garrett 2014-04-05 22:46:44 UTC
Created attachment 96963 [details]
patch that breaks by 23.98 playback

file removed -> built then ok.
Comment 12 Garrett 2014-04-06 04:02:01 UTC
Created attachment 96966 [details]
fixed with patch dmesg

It works really great, now.  No 23.976 skips, no blank screen any more.  Also 29.97ix1080 has 50% less skips (there were few anyhow)!  So the patch is an improvement (vdpau 1080i deinterlacing has some skips that I have been trying to kill).  It is really hard/impossible to see any more.

Thanks so much.  Garrett

[  122.397869] [drm:radeon_compute_pll_avivo], 148340 - 14830, pll dividers - fb: 148.3 ref: 10, post 10

I will try this new OE build on my new Zotac AQ01.  It was skippy on 23.976 before.
Comment 13 Garrett 2014-04-06 04:13:00 UTC
Created attachment 96968 [details]
the combined full patch needed to fix it

This final patch works well on my system.

I added your "max patch" to the original 76564 patch, OE kept skipping it on build if 2 patches for that file existed..
Editing patches/diff files is tricky stuff (fixing @@ hunk counters really had me for a bit there).

Let me know if you need anything else.
Comment 14 Rackow, Detlev 2014-04-06 20:59:32 UTC
I have enclosed a new Xorg.0.log and dmesg - their timestamp on the system matches the time when I changed the rate in xbmc. When it comes to changing on the command-line, I am not sure if I do this correctly - is

xrandr -s 1920x1080 -r 25 

correct? If I try this in putty, I see a black screen for a moment, then xbmc reappears and asks me if I want to keep the changed rate.

The output from xrandr for 1920x1080 is as follows:

HDMI-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 160mm x 90mm
   1920x1080     60.00 +  50.00    59.94    30.00    25.00    24.00*   29.97    23.98

Garrett wrote that he managed to include both your fixes in his build. I'm not that big into modifying the source, but I saw that fritsch has just included radeon-fixes into the current master of OE, and I am just building from scratch. I will report when the build is finished and I had the possibility to test.

Regards,

Detlev
Comment 15 Rackow, Detlev 2014-04-06 21:00:23 UTC
Created attachment 97003 [details]
dmesg after switching to 25hz and back to 24hz, 2nd attempt
Comment 16 Rackow, Detlev 2014-04-06 21:01:12 UTC
Created attachment 97004 [details]
Xorg.0.log after switching to 25hz and back to 24hz, 2nd attempt
Comment 17 Garrett 2014-04-07 00:32:42 UTC
Created attachment 97006 [details]
v3 patch merged with this max patch dmesg

I realized that the last patch I uploaded was v2 modded.  Here is dmesg with the newer v3 patch and this max patch (merged/applied as one patch). It works fine thus far, no blank screen.  

Test condition:

xrandr --output HDMI-0 --mode 1920x1080 --rate 23.98
dmesg > /var/log/dmesg

[   31.834325] [drm:radeon_compute_pll_avivo] *ERROR* 14830, pll dividers - fb: 148.3 ref: 10, post 10
Comment 18 Garrett 2014-04-07 00:37:04 UTC
*ERROR* Uuuu..O  but it played fine.  I missed that.  ?  back to v2?  I guess.
Comment 19 Christian König 2014-04-07 07:28:11 UTC
(In reply to comment #15)
> Created attachment 97003 [details]
> dmesg after switching to 25hz and back to 24hz, 2nd attempt

Please take a look at the logs before you upload them. This log again only contains unrelated page flip messages.

Not sure what's going wrong here, but without a mode set in the log I can't really help here.
Comment 20 Christian König 2014-04-07 07:39:53 UTC
(In reply to comment #17)
> Created attachment 97006 [details]
> v3 patch merged with this max patch dmesg
> 
> I realized that the last patch I uploaded was v2 modded.  Here is dmesg with
> the newer v3 patch and this max patch (merged/applied as one patch). It
> works fine thus far, no blank screen.  

Garrett, please stop trying to merge the patches. Since the initial change is already upsteram we are going to need to fix it in a separate patch anyway.

> 
> Test condition:
> 
> xrandr --output HDMI-0 --mode 1920x1080 --rate 23.98
> dmesg > /var/log/dmesg
> 
> [   31.834325] [drm:radeon_compute_pll_avivo] *ERROR* 14830, pll dividers -
> fb: 148.3 ref: 10, post 10

My fix limited the reference divider so that "post_div * ref_div <= 100". Could you try to raise the 100 to see at which point your TV says the signal isn't valid any more?

With a limit of 500 you should be at the same point as before, so I suggest to try values of 200, 300, 400 first. Then if 200 works but 300 doesn't (for example) try 250, and so on...
Comment 21 Garrett 2014-04-07 15:45:17 UTC
Created attachment 97043 [details]
368 and others dmesg

>Garrett, please stop trying to merge the patches. Since the initial change is >already upsteram we are going to need to fix it in a separate patch anyway.

Sorry.  New to this FOSS stuff.  OE is a complete OS download with local code not pulling from mainline kernels (from what I can tell).  It was tricky for me to patch it.  I am trying to be transparent so others can reproduce my results easily.


>My fix limited the reference divider so that "post_div * ref_div <= 100". Could >you try to raise the 100 to see at which point your TV says the signal isn't >valid any more?

>With a limit of 500 you should be at the same point as before, so I suggest to >try values of 200, 300, 400 first. Then if 200 works but 300 doesn't (for >example) try 250, and so on...

Thanks for the tips.

OK- I built many.  368 is the closest I got.  I have to head to the office.  I uploaded all dmesg, tests.  What I don't understand is the pll numbers go up and down, despite having the higher max vals.  This concerns me..

Hope it helps.  I assume you do not want to run all pc's at max.  Else tolerances at the hardware/silica/chipset level may result in similar results to my sys.  But at least now I can tune my sys.  :)  

368 is much higher than 100.  LMK if you need more. TIA.
Comment 22 Garrett 2014-04-08 05:01:44 UTC
Christian,
I managed to add only your patch solo:
https://bugs.freedesktop.org/attachment.cgi?id=96900&action=edit
It works great.  The mistake I made was ctrl-c/v from browser.  Bad chars I assume.  White-space chrs?  

I am trying to understand the plls.  I read the org. bug report 76564.  I assumed increasing the max would allow higher pll vals.  But it does go down with some.  Does that make sense?  

from this patch applied to v2:

[   38.548302] [drm:drm_mode_debug_printmodeline], Modeline 32:"" 0 74176 1920 2558 2602 2750 1080 1084 1089 1125 0x0 0x5

  38.568903] [drm:radeon_compute_pll_avivo], 148340 - 14830, pll dividers - fb: 148.3 ref: 10, post 10
[   38.581485] [drm:drm_crtc_helper_set_mode], [ENCODER:17:TMDS-17] set [MODE:32:]
[   38.581490] [drm:radeon_atom_encoder_dpms], encoder dpms 33 to mode 3, devices 00000008, active_devices 00000008

Is this correct?
 from Modeline 32:  74176 * 2 = 148352 (LCD wants?) ~= 148300 (GPU makes?).  
Ideally we need 148350 (GPU)? 

Your patch does wonders for this A4-3400.  I am trying to understand it better.

Here your max is 100.  ref: 10, post 10  >>>> 10 * 10 = 100 max.
Comment 23 Christian König 2014-04-08 13:29:35 UTC
(In reply to comment #21)
> Created attachment 97043 [details]
> 368 and others dmesg
> 
> >Garrett, please stop trying to merge the patches. Since the initial change is >already upsteram we are going to need to fix it in a separate patch anyway.
> 
> Sorry.  New to this FOSS stuff.  OE is a complete OS download with local
> code not pulling from mainline kernels (from what I can tell).  It was
> tricky for me to patch it.  I am trying to be transparent so others can
> reproduce my results easily.

No problem at all and keeping it reproducible is indeed a good intention. I just wanted to avoid that you spend time on unnecessary stuff.

> What I don't understand is the pll numbers go
> up and down, despite having the higher max vals.  This concerns me..

Well that is simple to explain. Assum that you have a feedback to ref divider ratio of 100/11. This ratio can't be reduced any more without lossing precission.

Now we also assume to the ref divider maximum is 10, so after limiting the ref divider to 10 we end up with a ratio of 90/10. Now 90 to 10 can be reduced easily to 9/1. So in the end we end up with a far lower ration because of the reference divider limit.

> Hope it helps.

Yeah, your numbers indeed helped a bit, thanks.
Comment 24 Christian König 2014-04-08 14:00:36 UTC
(In reply to comment #22)
> I am trying to understand the plls.

Well how deep are you interested in getting into this? PLLs can be complicated, but are also one of the very basic building blocks of electronics.

> I read the org. bug report 76564.  I
> assumed increasing the max would allow higher pll vals.  But it does go down
> with some.  Does that make sense?  

More or less yes. See your numbers for example, without the limit patch you had the params like this:

148340 - 14834, pll dividers - fb: 741.7 ref: 50, post 10

This means with a feedback divider of 741.7, a referenz divider of 50 and a post divider of 10 you have an exact match for the frequency.

There is just the little problem that as the divider numbers get higher the signal gets more unstable. So in reality you don't get 148.340 MHz, but instead something that fluctuates between 148.339 MHz and 148.341 MHz (for example).

The overall match for the average frequency is still better than with lower numbers, but your TV/Monitor can't deal with such high fluctuations in it.

> Your patch does wonders for this A4-3400.  I am trying to understand it
> better.
> 
> Here your max is 100.  ref: 10, post 10  >>>> 10 * 10 = 100 max.

Yes correct.
Comment 25 Manp 2014-04-08 14:15:58 UTC
(In reply to comment #0)

i seem to be facing the issue described here:

software setup is openelec r18117

using the GPU integrated inside my A8-3870K the video play fine, TV reports 24p, xbmc-xrandr reports 23,976
http://sprunge.us/cGOc
http://sprunge.us/VMjU

same setup but with GPU integrated in the APU disabled and using a discrete HD6450, TV shows no signal
http://sprunge.us/JBgc
http://sprunge.us/UXMV
Comment 26 Peter Frühberger 2014-04-08 14:31:00 UTC
Both your logs are of April 1st, so don't contain the possible fix.

The fix (to keep the divs low) was commited two days ago into OpenELEC git. Since then no official builds have been made. 

Furthermore the logs are useless without drm.debug=0xe

I think you got your builds from xbmcnightly.com and they did not do full rebuilds.
Comment 27 Garrett 2014-04-09 02:23:16 UTC
(In reply to comment #24)
> (In reply to comment #22)
> > I am trying to understand the plls.
> 
> Well how deep are you interested in getting into this? PLLs can be
> complicated, but are also one of the very basic building blocks of
> electronics.
> 

No need to dig too deep.  I work with embedded firmware.  PLL clocks/timing are fine (I understand basics).  In reference to video this is new stuff.  I sincerely appreciate your time educating me.

> > I read the org. bug report 76564.  I
> > assumed increasing the max would allow higher pll vals.  But it does go down
> > with some.  Does that make sense?  
> 
> More or less yes. See your numbers for example, without the limit patch you
> had the params like this:
> 
> 148340 - 14834, pll dividers - fb: 741.7 ref: 50, post 10
> 
> This means with a feedback divider of 741.7, a referenz divider of 50 and a
> post divider of 10 you have an exact match for the frequency.
> 
> There is just the little problem that as the divider numbers get higher the
> signal gets more unstable. So in reality you don't get 148.340 MHz, but
> instead something that fluctuates between 148.339 MHz and 148.341 MHz (for
> example).

"the signal gets more unstable"

So it is the gpu that varies its freq. at higher divs (multipliers) and my set is not tolerant of signal freq. fluctuations to keep data in sync? 

If I understand this correctly- This is like in a micro-controller where deviations in baud rate (a pll generated clock) leads to serial transmission errors when > 5% deviation, for example. In micro-controllers: high multipliers * internal pll = less stable freq >> less stable baud rate.

> 
> The overall match for the average frequency is still better than with lower
> numbers, but your TV/Monitor can't deal with such high fluctuations in it.
> 
> > Your patch does wonders for this A4-3400.  I am trying to understand it
> > better.
> > 
> > Here your max is 100.  ref: 10, post 10  >>>> 10 * 10 = 100 max.
> 
> Yes correct.

Thanks for explaining this so clearly.  
Garrett
Comment 28 Christian König 2014-04-09 12:17:21 UTC
(In reply to comment #27)
> "the signal gets more unstable"
> 
> So it is the gpu that varies its freq. at higher divs (multipliers) and my
> set is not tolerant of signal freq. fluctuations to keep data in sync? 

Yes.

> If I understand this correctly- This is like in a micro-controller where
> deviations in baud rate (a pll generated clock) leads to serial transmission
> errors when > 5% deviation, for example. In micro-controllers: high
> multipliers * internal pll = less stable freq >> less stable baud rate.

Yes that's exactly the same problem just a completely different use case.

Depending on the details of their electrical implementation all PLLs behave more or less like this. The trick is to know how to find the right numbers without violating the contrains.
Comment 29 Garrett 2014-04-10 14:00:45 UTC
(In reply to comment #28)

> Depending on the details of their electrical implementation all PLLs behave
> more or less like this. The trick is to know how to find the right numbers
> without violating the contrains.

yup..  This is a fun one to deal with in the embedded environment (love that scope.).  I consider this bug fixed.  I am not sure if I am supposed to mark it ok or something.  Else I will leave it.

I thought about the pll thing.  I don't know the HDMI message layer at all.  I am not sure it is public knowledge anyhow.

To get higher divs, I was thinking a potential algo could go (MUCH easier said than done, I know):

1) Run a setup program each time a hardware change is detected. (EDID or GPU)
2) Test LCD/Panel at various popular refresh rates.
    a) crank up the pll with your new algo. 
         >>  *test* if tv accepted it. (requires a knowledge of protocol to check display state, or have user answer ok with a timeout in case it is not readable)
         >> save the new div setting (maybe the 10% lower ones to be safe) to a config with a table for that hardware/refresh.
3) on reboot load new optimized saved PLL dividers from the table.  And on each refresh rate change use the table.

But that said.  It does not really matter for me to make it closer.  Your new algo with your "arbitrary" 100 limit works well on my hardware.  I tested 368 and it looked great, too.  368 vs 100 on 24P made vary little difference too me.
Comment 30 Christian König 2014-04-11 13:41:58 UTC
(In reply to comment #29)
> (In reply to comment #28)
> 1) Run a setup program each time a hardware change is detected. (EDID or GPU)
> 2) Test LCD/Panel at various popular refresh rates.
>     a) crank up the pll with your new algo. 
>          >>  *test* if tv accepted it. (requires a knowledge of protocol to
> check display state, or have user answer ok with a timeout in case it is not
> readable)

Well, that's way to much user interaction for this topic cause there is no way to ask a TV if the picture looks ok other than asking the user.

I'm going to supmit the patch to drm-fixes (with a bit higher limit) so it should end up in 3.15 together with the patch that created the problem in the first place.
Comment 31 Manp 2014-05-08 19:01:25 UTC
(In reply to comment #26)
> Both your logs are of April 1st, so don't contain the possible fix.
> 
> The fix (to keep the divs low) was commited two days ago into OpenELEC git.
> Since then no official builds have been made. 
> 
> Furthermore the logs are useless without drm.debug=0xe
> 
> I think you got your builds from xbmcnightly.com and they did not do full
> rebuilds.

thanks for your answer and please forgive me for providing improper logs. 


i'm using Openelec 4.0 final right now and the issue appear to be somewhat different.

using the HD6450 i now get video signal but i get severe jerkiness with any 23.98 content. xbmc-xrandr reports 23.97608 but the video stutters heavily at what appears to be regular times.

exactly the same thing used to happen with the SUMO GPU integrated inside the A8-3870K APU.
as of OpenELEC r18022 any 23.98 content played on the SUMO GPU resulted in exactly the same stutters while xbmc-xradr still report 23.97608. r18117 fixed the stutters on the APU and video played perfectly smooth.
right now Openelec r18022 is the last version out of the ones i tested that gives me perfectly smooth 23.98 content playback on the HD6450.


using Openelec 4.0 final on the integrated SUMO GPU inside the A8-3870k result in perfectly smooth video playback of the same files white xbmc-xrandr report 23.97608.

basically between Openelec r18022 and 4.0 final i get exactly the opposite behavior between the HD6450 and the SUMO GPU. 


i'll try to provide (hopefully useful) logs (if you could point me in the right direction in this regard it will be much appreciated) in the near future if you think what i tried to explain above makes any sense.


thanks


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.