Opened 13 years ago
Closed 5 years ago
#10113 closed Bug Report - General (Abandoned)
Picture dimensions mixed up using VAAPI
Reported by: | Owned by: | Mark Kendall | |
---|---|---|---|
Priority: | minor | Milestone: | 31.0 |
Component: | MythTV - Video/OSD Rendering | Version: | Master Head |
Severity: | medium | Keywords: | VAAPI dimensions |
Cc: | Ticket locked: | yes |
Description
I'm running mythbuntu (32 bit) 11.10 using the .25 nightly repo.
I've given VAAPI a try on my ATI HD4350
When playing HD video, the video does not fit on the screen. It is as if a 1920×1080 picture is put on a 1280×720 area. Sometimes the picture appears to be adjusted in width, but without regarding aspect ratio (still to high, bottom part of the video falling of the screen).
I've tested this in the modes 720p and 1080i (my TV does not support 1080p).
On a side note (may be important, may be not): HUE setting is incorrect by default but can be properly adjusted using the picture controls.
$ vainfo libva: libva version 0.32.0 Xlib: extension "XFree86-DRI" missing on display ":0.0". libva: va_getDriverName() returns 0 libva: Trying to open /usr/lib/dri/fglrx_drv_video.so libva: va_openDriver() returns 0 vainfo: VA API version: 0.32 vainfo: Driver version: Splitted-Desktop Systems XvBA backend for VA-API - 0.7.8 vainfo: Supported profile and entrypoints
VAProfileH264High : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD
$ lspci
01:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 4350] (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Device 02a8 Control: I/O+ Mem+ BusMaster?+ SpecCycle?- MemWINV- VGASnoop- ParErr?- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr?- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 44 Region 0: Memory at e0000000 (64-bit, prefetchable) [size=256M] Region 2: Memory at f0500000 (64-bit, non-prefetchable) [size=64K] Region 4: I/O ports at 1100 [size=256] [virtual] Expansion ROM at f0000000 [disabled] [size=128K] Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent?=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst?- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
DevCap?: MaxPayload? 128 bytes, PhantFunc? 0, Latency L0s <4us, L1 unlimited
DevCtl?: Report errors: Correctable- Non-Fatal- Fatal+ Unsupported-
RlxdOrd?+ ExtTag?+ PhantFunc?- AuxPwr?- NoSnoop?+ MaxPayload? 128 bytes, MaxReadReq? 128 bytes
DevSta?: CorrErr?- UncorrErr?- FatalErr?- UnsuppReq?- AuxPwr?- TransPend?- LnkCap?: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot?-
LnkCtl?: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk?+
ExtSynch?- ClockPM- AutWidDis?- BWInt- AutBWInt-
LnkSta?: Speed 2.5GT/s, Width x16, TrErr?- Train- SlotClk?+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Not Supported, TimeoutDis?- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis?- LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance?- SpeedDis?-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance?- ComplianceSOS- Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0300c Data: 41a1
Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Kernel driver in use: fglrx_pci Kernel modules: fglrx, radeon
Attachments (1)
Change History (18)
comment:1 Changed 13 years ago by
comment:2 Changed 13 years ago by
Damn Mark, you're fast!
Hope you can fix those dimensions as well :P
comment:3 Changed 13 years ago by
The picture dimensions issue is not new - I've seen this before when testing with the VDPAU backend as well. See http://code.mythtv.org/trac/ticket/8593#comment:4 (the original VAAPI tracking ticket - which has workarounds in code). There is inconsistent behaviour between the Intel driver and the XvBA and VDPAU backends produced by Splitted Desktop. This will never be an issue for VLC as they do not use the GLX functionality but I can't quite see how XBMC deal with it. Not so sure if mplayer uses the GLX code either.
Anyway, I've got a box with a freshly installed ubuntu 11.04 and a radeon hd 4550 to test with. The hue issues looks fixed - but the whole system is pretty unstable (not just a mythtv/vaapi issue). VAAPI looks to be working well as long as the box doesn't lock up - I'll try updating to the x-swat or xorg-edgers ppa's tomorrow to see if it's stable long enough to actually test with...
comment:4 Changed 13 years ago by
I've read the original tracking ticket but did not see a clear reference to this issue and because the heavy development I was unsure about the status of the problems you mentioned there.
Do I understand correctly you're saying: "install the splitted desktop backend and you're good to go!"?
The current trunk of mythtv is pretty unstable for me while my system appears to be very stable over all. The mythtv crashes never relate to video playback whatsoever. It tends to happen when changing settings, plugin in removable storage, all that kind of stuff.
I've got some info for you regarding mythv+linux+ati+fglrx, since it's a pain in the ass. Some stuff you will already know, others might be new and help save you some time.
- The fglrx drivers continue to appear to be hack. Video will tear unless you enable "Tear Free" in amdcccle. Enabling this option locks up the GPU on certain HD4XXX chips. Login remotely and run "aticonfig
--del-pcs-key=DDX,EnableTearFreeDesktop?" to disable this option again.
- fglrx has an issue with paint order when using OpenGL. The UI will be painted over video playback. You've fixed this in your VAAPI implementation (yay!). However, setup menus and wizards are still inaccessible. ATI users are adviced to use "export LIBGL_ALWAYS_INDIRECT=true" which degrades performance but makes menus visible again. With this option on the UI will be painted over the video when using VAAPI.
comment:5 Changed 13 years ago by
Eric - to be clear, the splitted desktop backends (both XvBA and VDPAU) are the backends that have the scaling issue. There is an ugly fix (which also introduces some extra scaling) but I first want to confirm it's not something I've done wrong in the existing VAAPI/OpenGL code.
With respect to the other ati comments - the paint order problem is an old one which I've been trying to eliminate. I'm hoping it will be resolved by removing the old, non-libmythui rendered settings pages and wizards. A better short term solution is probably just to run mythfrontend -O UIPainter=qt while changing settings.
comment:6 Changed 13 years ago by
Milestone: | unknown → 0.25 |
---|---|
Status: | new → accepted |
comment:7 Changed 13 years ago by
Owner: | markk deleted |
---|---|
Status: | accepted → assigned |
comment:8 Changed 13 years ago by
Milestone: | 0.25 → unknown |
---|---|
Status: | assigned → new |
Changed 12 years ago by
Attachment: | mythfrontend.20120711172643.2234.log added |
---|
mythfrontend log with hue channel mixup
comment:9 Changed 12 years ago by
Don't know if this bug is related, so posting here. Owner can spawn a new bug if it is unrelated. I mentioned it on the mailing list, but with no response.
Using the 0.26(head) branch on my gentoo box, I have hue mix ups on the main player. R and B are swapped. I also have a ATI onboard card that works perfectly with 0.25 with the opensource driver. The mythfrontend log is in the attachment. Errors can be seen on the vaapi part.
comment:10 Changed 12 years ago by
Hi, I'm new to this mythtv community. I'm trying to use mythtv 0.25 with vaapi and the fglrx driver (on a HD4350). I have the same problem reported in this ticket... since the last update is 9 months old, I would like to know if the problem is being worked on. Also markk told that "There is an ugly fix (which also introduces some extra scaling)". Can you post/link/tell something about that? Thanks
comment:11 Changed 12 years ago by
Hello, I can confirm this particular bug (scaling) on .26 as well. I have an E350 with onboard ATI card. The colours are okay, as is the decoding performance (CPU < 10%), but the picture dimensions are wrong as described in this ticket. As a workaround, I use the vaapi-enabled mplayer for HD videos in the media library. But to use this for recordings, I have to transcode or at least move them to the appropriate folders. The mplayer build works very well and the picture dimensions are also correct. A short hint at the "ugly fix" would be much appreciated.
comment:12 Changed 12 years ago by
I too have seen this issue. I'm using mythtv 0.25 and a Radeon 64xxM. I would love to see a fix to get vaapi working for these cards. The symptoms seem to be that the image is taller than it should be, and narrower. I'm not even convinced that the image isn't cropped as well.
I'd be happy to provide any logs that may be useful in tracking down the cause of this issue - please just let me know what you would need.
comment:13 Changed 12 years ago by
Hello, I am trying to setup a new mythtv-box with a E450, mythtv 0.25 and the Catalyst 12.8 driver. I am experiencing problems with wrong scaling for h264 content, issues with Opengl/gt settings and sudden freezing. Is the Splitted-Desktop Systems XvBA backend still needed for vaapi?
Same as mdoxer: I'd be happy to provide any logs that may be useful in tracking down the cause of this issue - please just let me know what you would need.
comment:14 Changed 12 years ago by
Hi, any news on this? Mythfrontend is a pain on my E-350. Also are there any chances for more / better VA deinterlacers in future?
comment:16 Changed 5 years ago by
Owner: | set to Mark Kendall |
---|---|
Status: | new → accepted |
comment:17 Changed 5 years ago by
Milestone: | unknown → 31.0 |
---|---|
Resolution: | → Abandoned |
Status: | accepted → closed |
All of the code referenced in this ticket is now long gone - both within the drivers, FFmpeg and MythTV.
Everything appears to be working in master (soon to be 0.31)
VAAPI: Fix Hue for ATI drivers.
Entirely untested but consistent with the existing XVideo approach.
Ref #10113