2011-06-03, 12:44
That because you are using a nightly build, a pre-Eden with a Dharma skin. Just change the skin with a pre-Eden one. Default Confluence should suffice.
2011-06-03, 15:24
I am using Confluence, is there an older version of it?
I will try to find it, thank you.
I will try to find it, thank you.
2011-06-06, 10:08
hellrider77 Wrote:But now, i am unable to use file-view in videos anymore. It defaults to library mode and the option to disable it is missing.
There have been some changes and file/library mode is now merged. Nevertheless, you will find a "Files" folder in your library which takes you to the good old file mode and you can still browse your sources as in Dharma.
2011-06-06, 10:19
@thespecialist:
You are right in that DXVA deinterlacing is actually performed by the video driver using shaders in most cases. Although it would be possible to do it via dedicated hardware, I don't know about any cards that do it that way.
The "DeinterlaceQueryAvailableModes" method you are referring to is for DXVA1, which is only available through Windows built-in renderers. XBMC does not use Windows renderer surfaces (that's why it requires DXVA2). DXVA2 works somewhat differently.
The CCC options do not force deinterlacing if XBMC requests a progressive DXVA2 video processor. IIRC the video driver always offers all processors for deinterlacers no matter what you select in CCC. CCC seems to control only the maximum and "dumbs down" the deinterlacer algorithm internally (so for the application it is transparent). Also if I select the Bob video processor, then the driver will do bob only, no matter what is checked in CCC.
You are right in that DXVA deinterlacing is actually performed by the video driver using shaders in most cases. Although it would be possible to do it via dedicated hardware, I don't know about any cards that do it that way.
The "DeinterlaceQueryAvailableModes" method you are referring to is for DXVA1, which is only available through Windows built-in renderers. XBMC does not use Windows renderer surfaces (that's why it requires DXVA2). DXVA2 works somewhat differently.
The CCC options do not force deinterlacing if XBMC requests a progressive DXVA2 video processor. IIRC the video driver always offers all processors for deinterlacers no matter what you select in CCC. CCC seems to control only the maximum and "dumbs down" the deinterlacer algorithm internally (so for the application it is transparent). Also if I select the Bob video processor, then the driver will do bob only, no matter what is checked in CCC.
2011-06-06, 15:28
Thank you.
There must be something broken in my settings, using Confluence, i am able to finde the "Files" folder but it is empty.
I have solved the problem by switching to the "Transparency" skin, it is a bit too much for my CPU and tends to be really sluggish but it suits better my taste.
Thanks a lot, you are really helpful guys.
There must be something broken in my settings, using Confluence, i am able to finde the "Files" folder but it is empty.
I have solved the problem by switching to the "Transparency" skin, it is a bit too much for my CPU and tends to be really sluggish but it suits better my taste.
Thanks a lot, you are really helpful guys.
2011-06-07, 01:43
Thanks for the info, very interesting stuff !
I've started to look into DXVA2 myself a bit. Thing is that there's a bug in XBMC/FFMPEG's DXVA2 implementation for WMV9 (it doesn't work). WMP plays WMV9 fine with DXVA2, so I figured, if there's an easy way to hook into the DXVA2 calls, it shouldn't be too hard to compare what WMP does and how FFMPEG tries to decode.
I first started looking at that 'DXVA checker' tool, since that has an option to trace DXVA2 calls, it seemed to be a great start. The guy who wrote it encrypted his exe (probably to keep guys like me out, lol) but since it's an .NET assembly it was a joke to dump the decrypted version from memory
It turns out that he just uses a simple user mode event tracing, supplied by Advapi: http://www.geoffchappell.com/viewer.htm?.../index.htm
So that wasn't what I had hoped for (had hoped for something in kernel mode !), since I can't use that to dump function parameters etc. Then I found that MPC-HC has some code called 'ipinhook.c' that seemed to be exactly what I was looking for (DXVA2 hooking). However it turned out that it just overwrites its own Vtables. Again not something I could use to hook into WMP (although I guess it should be possible to inject code into WMP and then overwrite the vtables the same way, but that's quite a bit of work).
In short, been busy quite a bit on a route that didn't yield a quick/easy result ... Probably should have used that time instead to study videodecoding
Oh, and btw, if anybody is interested: I found by looking at wmvdecod.dll that if you set :
HKCU\Software\Microsoft\Scrunch\WMVideo
DWORD "DXVATRACE" = 1
then wmvdecod.dll (used by WMP to decode WMV/9) writes some event logging to c:\dxva.log. However, again, not really stuff I could use ...
I've started to look into DXVA2 myself a bit. Thing is that there's a bug in XBMC/FFMPEG's DXVA2 implementation for WMV9 (it doesn't work). WMP plays WMV9 fine with DXVA2, so I figured, if there's an easy way to hook into the DXVA2 calls, it shouldn't be too hard to compare what WMP does and how FFMPEG tries to decode.
I first started looking at that 'DXVA checker' tool, since that has an option to trace DXVA2 calls, it seemed to be a great start. The guy who wrote it encrypted his exe (probably to keep guys like me out, lol) but since it's an .NET assembly it was a joke to dump the decrypted version from memory
It turns out that he just uses a simple user mode event tracing, supplied by Advapi: http://www.geoffchappell.com/viewer.htm?.../index.htmSo that wasn't what I had hoped for (had hoped for something in kernel mode !), since I can't use that to dump function parameters etc. Then I found that MPC-HC has some code called 'ipinhook.c' that seemed to be exactly what I was looking for (DXVA2 hooking). However it turned out that it just overwrites its own Vtables. Again not something I could use to hook into WMP (although I guess it should be possible to inject code into WMP and then overwrite the vtables the same way, but that's quite a bit of work).
In short, been busy quite a bit on a route that didn't yield a quick/easy result ... Probably should have used that time instead to study videodecoding
Oh, and btw, if anybody is interested: I found by looking at wmvdecod.dll that if you set :
HKCU\Software\Microsoft\Scrunch\WMVideo
DWORD "DXVATRACE" = 1
then wmvdecod.dll (used by WMP to decode WMV/9) writes some event logging to c:\dxva.log. However, again, not really stuff I could use ...
2011-06-07, 13:01
aa11599, is there any chance for this to be included in the main branch?
Also, do you have a simple explanation for what it's meant by double framerate?
Also, the fact that VC-1 interlaced is still not supported by FFMPEG is really incredible... why is that?
Also, do you have a simple explanation for what it's meant by double framerate?
Also, the fact that VC-1 interlaced is still not supported by FFMPEG is really incredible... why is that?
2011-06-08, 13:03
Hi ashlar,
Yes, the patch has a pretty good chance, especially that I haven't got any negative feedback since the latest version.
About double framerate: 60i footage is made up from 60 fps material by taking the odd/even lines of each odd/even frame. For example, lines 1, 3, 5, etc. are taken from frame 1, while lines 2, 4, 6, etc. are taken from frame 2. These lines (called fields) are then used to construct a different frame at half framerate than the original (so the result is now 30 fps). So if an interlaced material is technically 30 fps, it should be 60 fps after deinterlacing to preserve temporal resolution. Wikipedia has a pretty good explanation on the process (and why it will never be perfect).
I have no idea why ffmpeg does not support interlaced VC-1, but there certainly must be a reason. I think the fact that there is no LGPL compatible open source decoder/encoder definitely doesn't help. Looks like the Microsoft origins pretty much scare off everybody from this format.
Yes, the patch has a pretty good chance, especially that I haven't got any negative feedback since the latest version.
About double framerate: 60i footage is made up from 60 fps material by taking the odd/even lines of each odd/even frame. For example, lines 1, 3, 5, etc. are taken from frame 1, while lines 2, 4, 6, etc. are taken from frame 2. These lines (called fields) are then used to construct a different frame at half framerate than the original (so the result is now 30 fps). So if an interlaced material is technically 30 fps, it should be 60 fps after deinterlacing to preserve temporal resolution. Wikipedia has a pretty good explanation on the process (and why it will never be perfect).
I have no idea why ffmpeg does not support interlaced VC-1, but there certainly must be a reason. I think the fact that there is no LGPL compatible open source decoder/encoder definitely doesn't help. Looks like the Microsoft origins pretty much scare off everybody from this format.
Hi all,
Excellent patch, thanks for all the hard work developing and sharing.
Does anyone happen to have a win32 build of 10.1 with both this patch and the also-awesome Dual Audio Output patch? I've been trying to build such a thing, but with absolutely no previous experience, I've reached a brick wall.
Cheers
Excellent patch, thanks for all the hard work developing and sharing.
Does anyone happen to have a win32 build of 10.1 with both this patch and the also-awesome Dual Audio Output patch? I've been trying to build such a thing, but with absolutely no previous experience, I've reached a brick wall.
Cheers
2011-06-13, 18:03
now this is interesting:
http://trac.xbmc.org/ticket/11635
any experiences yet with this patch? and will it work on DVD decoding through ffmpeg?
http://trac.xbmc.org/ticket/11635
any experiences yet with this patch? and will it work on DVD decoding through ffmpeg?
2011-06-13, 21:22
Voyager-xbmc Wrote:now this is interesting:
http://trac.xbmc.org/ticket/11635
any experiences yet with this patch? and will it work on DVD decoding through ffmpeg?
Hi all,
I'm the creator of the patch.
First of all thanks to a11599 for making such fantastic work in his patch which was the basis for mine.
It works with DVD decoding and any content that ffmpeg decode. I have created a new thread for the patch but is pending for reviewing by moderator. In the meantime if someone wants to try the patch I have compiled an installer here.
2011-06-14, 19:17
Hola, Isidrogar,
Does this Compiled version contains A11599's patches?
Saludos.
Does this Compiled version contains A11599's patches?
Saludos.
2011-06-15, 10:04
watanave Wrote:Hola, Isidrogar,
Does this Compiled version contains A11599's patches?
Saludos.
Hola watanave,
Yes, the compiled version also includes a11599's modifications.
2011-06-15, 23:47
isidrogar Wrote:Hola watanave,
Yes, the compiled version also includes a11599's modifications.
Muchas gracias, Isidrogar.
2011-06-20, 08:43
a11599,
I've tested Margro's last two pre-eden builds of his PVR branch located here - http://www.scintilla.utwente.nl/~marcelg...tml#master
De-interlace is working great
However i noticed an issue that when watching live tv and pushing 'C' to bring up the channel list, the video stutters and drops a lot of frames... I'm not sure if this is a problem with the Confluence skin or your patch.
I realise these are pre-releases and are buggy, but i can confirm that the problem only exists when De-interlacing is enabled, if you changed video de-interlace settings to 'none' the problem goes away... This leads me to believe it's not a skin related issue. So it's worth addressing, maybe you could have a look at this?
Cheers,
Loggio.
I've tested Margro's last two pre-eden builds of his PVR branch located here - http://www.scintilla.utwente.nl/~marcelg...tml#master
De-interlace is working great
However i noticed an issue that when watching live tv and pushing 'C' to bring up the channel list, the video stutters and drops a lot of frames... I'm not sure if this is a problem with the Confluence skin or your patch.
I realise these are pre-releases and are buggy, but i can confirm that the problem only exists when De-interlacing is enabled, if you changed video de-interlace settings to 'none' the problem goes away... This leads me to believe it's not a skin related issue. So it's worth addressing, maybe you could have a look at this?
Cheers,
Loggio.
