https://bugs.freedesktop.org/show_bug.cgi?id=76564
Christian König changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #87 from adb76 at gmx.de ---
I've retested this evening the playback with OE 3.2 + xvba: 0 missed frames in
45 minutes for 1280x720 at 25 fps. For the same video file with OE 4 beta 7 +
vdpau: 38 missed frames.
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #86 from adb76 at gmx.de ---
Sorry. Here it is:
http://sprunge.us/NhCD
Because of the small dmesg log buffer I can't get all of the output from the
second 0. Hope the necessary information is included.
Regards,
Andr?
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #85 from Christian K?nig ---
(In reply to comment #84)
> Since the dmesg log buffer seems very small, I called "dmesg | pastebinit"
> directly afterwards the missed frame counter increased. I made this three
> times:
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #84 from adb76 at gmx.de ---
Since the dmesg log buffer seems very small, I called "dmesg | pastebinit"
directly afterwards the missed frame counter increased. I made this three
times:
http://sprunge.us/gCRU
http://sprunge.us/EHNG
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #83 from Christian K?nig ---
(In reply to comment #79)
> Created attachment 98406 [details]
> adb76 dmesg output
Please provide a dmesg output generated with drm.debug=0xE.
Thanks,
Christian.
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=76564
adb76 at gmx.de changed:
What|Removed |Added
Attachment #98409|adb76 xbmc-xrandr ouput |adb76 xbmc-xrandr output
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #82 from adb76 at gmx.de ---
Created attachment 98409
--> https://bugs.freedesktop.org/attachment.cgi?id=98409=edit
adb76 xbmc-xrandr ouput
--
You are receiving this mail because:
You are the assignee for the bug.
--
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #81 from adb76 at gmx.de ---
Created attachment 98408
--> https://bugs.freedesktop.org/attachment.cgi?id=98408=edit
adb76 xorg.log
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #80 from adb76 at gmx.de ---
Created attachment 98407
--> https://bugs.freedesktop.org/attachment.cgi?id=98407=edit
adb76 lspci output
--
You are receiving this mail because:
You are the assignee for the bug.
-- next
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #79 from adb76 at gmx.de ---
Created attachment 98406
--> https://bugs.freedesktop.org/attachment.cgi?id=98406=edit
adb76 dmesg output
--
You are receiving this mail because:
You are the assignee for the bug.
-- next
https://bugs.freedesktop.org/show_bug.cgi?id=76564
adb76 at gmx.de changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=76564
Christian K?nig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #76 from jeroen ---
(In reply to comment #74)
> Wait a moment, the last one has changed a bit to support more than R600,
> please use that one: http://sprunge.us/XcQW
I just tested with this patch in combination with OE 4.0 master
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #75 from Garrett ---
(In reply to comment #74)
> Wait a moment, the last one has changed a bit to support more than R600,
> please use that one: http://sprunge.us/XcQW
OK built it and works great! A4-3400 all good, like before.
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #74 from Peter Fr?hberger ---
Wait a moment, the last one has changed a bit to support more than R600, please
use that one: http://sprunge.us/XcQW
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #73 from jeroen ---
(In reply to comment #70)
> @Jereon: Here is the updated patch: http://sprunge.us/DOjf
>
> I am currently building debian packages, so drop me a mail if you test on
> debian based system to save you that work.
>
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #72 from Garrett ---
(In reply to comment #69)
> Hi Peter & Jereon,
>
> please give this commit a try:
> http://cgit.freedesktop.org/~deathsimple/linux/commit/?h=drm-fixes-3.15-
> wip=cebb0b66645d8d18982c160521c164a51d0f1fd9
>
> It
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #71 from Peter Fr?hberger ---
Works perfectly for me.
Test 50hz, 24.0 hz and 23.976 hz. No skips, rock solid fps.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #70 from Peter Fr?hberger ---
@Jereon: Here is the updated patch: http://sprunge.us/DOjf
I am currently building debian packages, so drop me a mail if you test on
debian based system to save you that work.
@Christian: Thx much as
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #69 from Christian K?nig ---
Hi Peter & Jereon,
please give this commit a try:
http://cgit.freedesktop.org/~deathsimple/linux/commit/?h=drm-fixes-3.15-wip=cebb0b66645d8d18982c160521c164a51d0f1fd9
It should now use the pflip irq to
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #68 from jeroen ---
dmesg output with drm debug on: http://sprunge.us/gSWc
I tested it too and have similar results as Peter. When playing 23.976 content
the average framerate is around 21fps and XBMC reports constant 'skipped
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #67 from Garrett ---
Created attachment 97901
--> https://bugs.freedesktop.org/attachment.cgi?id=97901=edit
dmesg xrandr new patch slow 18fps on 24p
I tested this new patch. it plays back very slowly in xbmc (reverting the
kernel
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #66 from Peter Fr?hberger ---
I gave the patches I extracted a try (http://sprunge.us/ZRBT).
It seems to have major issues with fractional modes. When watching 24p content,
it jumps all the way from 0.89 fps to 18fps and 24fps, the
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #65 from Christian K?nig ---
(In reply to comment #64)
> I will see if I can create a patch for OpenElec to pull in all the changes
> made to drm/radeon and test it
Peter already did so, you should contact him to get the merged
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #64 from jeroen ---
(In reply to comment #63)
> Please try
> http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-next-3.16.
>
> This branch might fix the remaining frame drop problems.
Hi Christian,
I see multiple commits,
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #63 from Christian K?nig ---
Please try http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-next-3.16.
This branch might fix the remaining frame drop problems.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #62 from Rackow, Detlev ---
Thanks for your fast reply, it's done.
Regards,
Detlev
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #61 from Christian K?nig ---
Detlev, please attache your logs to this bug instead:
ttps://bugs.freedesktop.org/show_bug.cgi?id=77009
It's essentially a different problem and I want to keep it separated from the
discussion here.
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #60 from Rackow, Detlev ---
Created attachment 96870
--> https://bugs.freedesktop.org/attachment.cgi?id=96870=edit
Xorg.0.log after switching to 25hz and back to 24hz
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #59 from Rackow, Detlev ---
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
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #58 from Rackow, Detlev ---
Created attachment 96869
--> https://bugs.freedesktop.org/attachment.cgi?id=96869=edit
dmesg after switching to 25hz and back to 24hz
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #57 from Rainer Hochecker ---
(In reply to comment #50)
> If the 'sync to display' option is on in XBMC the video pixels clock is
> master and I guess it then uses the vblank interrupt generated by the OSS
> driver. These interrupts
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #56 from Christian K?nig ---
@Garrett:
That looks rather interesting. First of all please open up a new bug report, I
want to separate this problem from the discussion here.
To this new bug report please add the output of "xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #55 from Garrett ---
Created attachment 96820
--> https://bugs.freedesktop.org/attachment.cgi?id=96820=edit
dmesg xrandr old code working 23.98
xrandr prepatch 1920x1080px23.98 OK LCD display.
"xrandr --output HDMI-0 --mode
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #54 from Garrett ---
Created attachment 96819
--> https://bugs.freedesktop.org/attachment.cgi?id=96819=edit
xrandr 1920x1080x23.98 crashed
ok "xrandr --output HDMI-0 --mode 1920x1080 --rate 23.98" crashes the screen.
Same as the
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #53 from Garrett ---
Created attachment 96817
--> https://bugs.freedesktop.org/attachment.cgi?id=96817=edit
xrandr 1920x1080x24p and OE crashed lcd
Sorry. Here you go: dmesg just after- "xrandr --output HDMI-0 --mode 1920x1080
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #52 from jeroen ---
(In reply to comment #51)
> This bugtracker is not about fglrx. Not a single thing will change for the
> radeon oss driver cause of such statements.
>
> At the end - before we dropped support for it (xvba +
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #51 from Peter Fr?hberger ---
This bugtracker is not about fglrx. Not a single thing will change for the
radeon oss driver cause of such statements.
At the end - before we dropped support for it (xvba + fglrx) - it was not even
able
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #50 from jeroen ---
(In reply to comment #47)
> (In reply to comment #41)
> > (In reply to comment #40)
> > > If you set "sync playback to display" in XBMC, an inaccurate clock has no
> > > impact on dropped or skipped frames.
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #48 from Garrett ---
Created attachment 96792
--> https://bugs.freedesktop.org/attachment.cgi?id=96792=edit
logs working and not
This patch appears to have broken my 24P playback which has been fine until
now. My set is a Sony
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #47 from Rainer Hochecker ---
(In reply to comment #41)
> (In reply to comment #40)
> > If you set "sync playback to display" in XBMC, an inaccurate clock has no
> > impact on dropped or skipped frames. Suppose you only have a 24Hz
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #46 from jeroen ---
(In reply to comment #45)
> (In reply to comment #44)
> > (In reply to comment #43)
> > > We could also update the adjusted mode clock to the actual clock set by
> > > the
> > > pll so that
https://bugs.freedesktop.org/show_bug.cgi?id=76564
Christian K?nig changed:
What|Removed |Added
CC||deathsimple at vodafone.de
---
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #44 from jeroen ---
(In reply to comment #43)
> We could also update the adjusted mode clock to the actual clock set by the
> pll so that drm_calc_timestamping_constants() uses the actual clock value on
> the PLL. E.g.,
>
> diff
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #43 from Alex Deucher ---
We could also update the adjusted mode clock to the actual clock set by the pll
so that drm_calc_timestamping_constants() uses the actual clock value on the
PLL. E.g.,
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #42 from Christian K?nig ---
The only other option I'm aware of would be to adjust the modes to have a
doable pixel clock.
On modern displays we could for exampler increase the vertical blanking period
slightly to make the mode hit
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #41 from jeroen ---
(In reply to comment #40)
> If you set "sync playback to display" in XBMC, an inaccurate clock has no
> impact on dropped or skipped frames. Suppose you only have a 24Hz mode and
> play material which is 23.976.
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #40 from Rainer Hochecker ---
If you set "sync playback to display" in XBMC, an inaccurate clock has no
impact on dropped or skipped frames. Suppose you only have a 24Hz mode and play
material which is 23.976. It would slightly speed
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #39 from jeroen ---
(In reply to comment #37)
> Created attachment 96604 [details] [review]
> Possible fix v3
>
> Please try this one, it's a complete rewrite of finding the right PLL
> numbers.
No problem Peter I was already
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #38 from Peter Fr?hberger ---
Here is an OpenELEC image with kernel 3.14-rc8+ with that PLL patch included,
so no need to compile manually:
http://saraev.ca/OpenELEC-Generic.x86_64-devel-20140330151700-r18049-g02739c3.tar
--
You
https://bugs.freedesktop.org/show_bug.cgi?id=76564
Christian K?nig changed:
What|Removed |Added
Attachment #96562|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #36 from Christian K?nig ---
(In reply to comment #35)
> (In reply to comment #34)
> > Why not increase the ref_div? hardware frying? That way you can get the
> > clock exactly right.
> >
> > For example: 148.5 = 100 * 29.7 / 4 * 5
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #35 from jeroen ---
(In reply to comment #34)
> Why not increase the ref_div? hardware frying? That way you can get the
> clock exactly right.
>
> For example: 148.5 = 100 * 29.7 / 4 * 5
> 74.2 = 100 * 37.1 / 5 * 10
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #34 from jeroen ---
Why not increase the ref_div? hardware frying? That way you can get the clock
exactly right.
For example: 148.5 = 100 * 29.7 / 4 * 5
74.2 = 100 * 37.1 / 5 * 10
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #33 from jeroen ---
The PLL struct values are on my system:
pll_in_min=675,
pll_in_max=5000,
pll_out_min=64800,
pll_out_max=12,
lcd_pll_out_min=0,
lcd_pll_out_max=12,
min_ref_div=2,
max_ref_div=1023,
min_post_div=2,
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #32 from jeroen ---
(In reply to comment #31)
> Created attachment 96562 [details] [review]
> Possible fix v2
>
> Sorry just found a stupid typo in the last patch, attached is a new one.
I've tested the patch and it definately
https://bugs.freedesktop.org/show_bug.cgi?id=76564
Christian K?nig changed:
What|Removed |Added
Attachment #96561|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #30 from Christian K?nig ---
Created attachment 96561
--> https://bugs.freedesktop.org/attachment.cgi?id=96561=edit
Possible fix
Please try if the attached patch helps.
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #29 from Christian K?nig ---
(In reply to comment #28)
> Perhaps before somebody is going to modify the algorithm, it is a good idea
> to verify that this is indeed the problem.
> If this is the problem why don't more people have
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #28 from jeroen ---
(In reply to comment #27)
> (In reply to comment #26)
> > (In reply to comment #25)
> > > (In reply to comment #24)
> > > > (In reply to comment #23)
> > > > The problem is that the frequencys are exact enough so
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #27 from Christian K?nig ---
(In reply to comment #26)
> (In reply to comment #25)
> > (In reply to comment #24)
> > > (In reply to comment #23)
> > > The problem is that the frequencys are exact enough so that the display
> > >
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #26 from Alex Deucher ---
(In reply to comment #25)
> (In reply to comment #24)
> > (In reply to comment #23)
> > > (In reply to comment #21)
> > > > (In reply to comment #20)
> > > > >
> > > > > When I look at the xrandr output I
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #25 from jeroen ---
(In reply to comment #24)
> (In reply to comment #23)
> > (In reply to comment #21)
> > > (In reply to comment #20)
> > > >
> > > > When I look at the xrandr output I wonder if the reference frequency is
> > >
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #24 from Christian K?nig ---
(In reply to comment #23)
> (In reply to comment #21)
> > (In reply to comment #20)
> > >
> > > When I look at the xrandr output I wonder if the reference frequency is
> > > not
> > > 75MHz for fgrlx?
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #23 from jeroen ---
(In reply to comment #21)
> (In reply to comment #20)
> >
> > When I look at the xrandr output I wonder if the reference frequency is not
> > 75MHz for fgrlx? Can the reference even change is this not fixed by
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #22 from Christian K?nig ---
(In reply to comment #21)
> One would need to tweak radeon_compute_pll_avivo() in radeon_display.c to
> try and get dividers that are closer to the target clock.
That was some kind of calculus or rather
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #21 from Alex Deucher ---
(In reply to comment #20)
>
> When I look at the xrandr output I wonder if the reference frequency is not
> 75MHz for fgrlx? Can the reference even change is this not fixed by the
> hardware?
As far as I
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #20 from jeroen ---
(In reply to comment #19)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > I got the results with fglrx:
> > > PPLL1 at 50Hz: fb=23.7ref=2post=6
> > > PPLL1 at 23.976Hz: fb=23.7ref=2
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #19 from jeroen ---
(In reply to comment #16)
> (In reply to comment #15)
> > I got the results with fglrx:
> > PPLL1 at 50Hz: fb=23.7ref=2post=6
> > PPLL1 at 23.976Hz: fb=23.7ref=2post=12
> >
> > PPLL2 does seem
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #18 from jeroen ---
Created attachment 96473
--> https://bugs.freedesktop.org/attachment.cgi?id=96473=edit
oss xrandr
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #17 from jeroen ---
Created attachment 96471
--> https://bugs.freedesktop.org/attachment.cgi?id=96471=edit
fgrlx xrandr
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part
https://bugs.freedesktop.org/show_bug.cgi?id=76564
Alex Deucher changed:
What|Removed |Added
Product|Mesa|DRI
Version|10.1
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #16 from Alex Deucher ---
(In reply to comment #15)
> I got the results with fglrx:
> PPLL1 at 50Hz: fb=23.7ref=2post=6
> PPLL1 at 23.976Hz: fb=23.7ref=2post=12
>
> PPLL2 does seem to be used as it does not
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #15 from jeroen ---
(In reply to comment #14)
> (In reply to comment #13)
> > Do the PLL values in the log files I posted indicate a problem, or are they
> > okay?
>
> [drm:radeon_compute_pll_avivo], 14875, pll dividers - fb: 23.8
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #14 from Alex Deucher ---
(In reply to comment #13)
> Do the PLL values in the log files I posted indicate a problem, or are they
> okay?
[drm:radeon_compute_pll_avivo], 14875, pll dividers - fb: 23.8 ref: 2, post 8
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #13 from jeroen ---
Do the PLL values in the log files I posted indicate a problem, or are they
okay?
How can you see the PLL values fglrx is using?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #12 from Christian K?nig ---
(In reply to comment #10)
> (In reply to comment #8)
> > Okay, but doesnt that mean in this case it is a problem with the display
> > (HDMI?) clock, as I am not using HDMI audio?
> >
> > Is there a way I
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #11 from jeroen ---
Created attachment 96380
--> https://bugs.freedesktop.org/attachment.cgi?id=96380=edit
drm debug log with kms and driver level
I found out to see the PLL numbers KMS level debugging needed to be on. So I
redid
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #10 from Alex Deucher ---
(In reply to comment #8)
> Okay, but doesnt that mean in this case it is a problem with the display
> (HDMI?) clock, as I am not using HDMI audio?
>
> Is there a way I could get more detailed logging of
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #9 from jeroen ---
Created attachment 96379
--> https://bugs.freedesktop.org/attachment.cgi?id=96379=edit
drm_debug log
This big drm log was created while starting xbmc with the display set to 50fps,
then playing a 23.976fps test
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #8 from jeroen ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > Probably a duplicate of bug 71753.
> >
> > Yes I read that report. What I don't understand is how the audio clock, uvd
> >
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #7 from Alex Deucher ---
(In reply to comment #6)
> (In reply to comment #5)
> > Probably a duplicate of bug 71753.
>
> Yes I read that report. What I don't understand is how the audio clock, uvd
> clock, hdmi clock, etc relate to
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #6 from jeroen ---
(In reply to comment #5)
> Probably a duplicate of bug 71753.
Yes I read that report. What I don't understand is how the audio clock, uvd
clock, hdmi clock, etc relate to each other.
For audio I use the realtek
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #5 from Alex Deucher ---
Probably a duplicate of bug 71753.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #4 from jeroen ---
Sorry for not providing that information.
OpenELEC uses XBMC to play the videos. XBMC has the option to display stats
(http://wiki.xbmc.org/?title=Codecinfo). One of the stats is the actual video
frame rate. Other
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #3 from Christian K?nig ---
(In reply to comment #0)
> 23.976fps becomes 23.92/23.95 and sometimes goes to 22.93fps
> 25fps becomes 25.02 or 25.05fps
> 29.97 interlaced decodes with around 58fps instead of 59.94fps.
That the refresh
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #2 from Christian K?nig ---
HDMI refresh rate seems to be off, UVD decoding speed is completely unrelated
to this.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An
https://bugs.freedesktop.org/show_bug.cgi?id=76564
Christian K?nig changed:
What|Removed |Added
Summary|[AMD Fusion E-350] Radeon |[AMD Fusion E-350] HDMI
89 matches
Mail list logo
