Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
21st October 2011, 17:08 | #201 | Link | ||
Registered User
Join Date: Sep 2011
Posts: 22
|
Quote:
Quote:
http://www.mediafire.com/?jql2qu8xj22c2ar http://www.mediafire.com/?ye6oudmltypr7ey |
||
21st October 2011, 23:00 | #202 | Link | |
QuickSync Decoder author
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
|
Quote:
The newest version (to be released soon) seems to play them well. They are have constant frame rate of 29.97 which stays well for the entire clip. Other than audio/video sync issues, are there any other problems? BTW, do you know what camera produced these clips? I want to thank all you guys for helping me make this a better product by testing and providing clips
__________________
Eric Gur, Processor Application Engineer for Overclocking and CPU technologies Intel QuickSync Decoder author Intel Corp. |
|
21st October 2011, 23:50 | #203 | Link | |
Registered User
Join Date: Oct 2010
Location: The Netherlands
Posts: 1,083
|
Quote:
Code:
HANDLE SharedHandle = NULL;// uninitialized D3DDevice1->CreateTexture(Width, Height, 1, D3DUSAGE_RENDERTARGET, SurfaceType, D3DPOOL_DEFAULT, &RTTexture1, &SharedHandle);// handle is initialized, texture is created on deivice 1 D3DDevice2->CreateTexture(Width, Height, 1, D3DUSAGE_RENDERTARGET, SurfaceType, D3DPOOL_DEFAULT, &RTTexture2, &SharedHandle);// handle is used, no extra texture is created, the COM pointer RTTexture2 will be usable only to D3DDevice2 The helper function for DXVA on EVR does a similar thing (although usually on the same adapter). Shared handles are also used when you want to access textures from a DirectX 9 to a DirectX 11 device.
__________________
development folder, containing MPC-HC experimental tester builds, pixel shaders and more: http://www.mediafire.com/?xwsoo403c53hv Last edited by JanWillem32; 21st October 2011 at 23:57. |
|
22nd October 2011, 06:54 | #204 | Link | |
Registered User
Join Date: Sep 2011
Posts: 22
|
Quote:
Probably Samsung HMX-S10. (I found it difficult. ) Thanks for the fix! P.S. Not related QuickSync decoder. But can you look at this bug? http://communities.intel.com/thread/24972 Last edited by pulbitz; 22nd October 2011 at 07:16. |
|
22nd October 2011, 08:59 | #205 | Link | |
Registered User
Join Date: Apr 2006
Posts: 299
|
Quote:
|
|
22nd October 2011, 15:59 | #206 | Link | ||
QuickSync Decoder author
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
|
Quote:
Quote:
The video processing pipeline, which I'm very familiar with doesn't care about surface format, what matters is that both are 4:2:0. If different results arise from NV12 and YV12, it looks like a driver bug.
__________________
Eric Gur, Processor Application Engineer for Overclocking and CPU technologies Intel QuickSync Decoder author Intel Corp. |
||
22nd October 2011, 19:17 | #207 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 4,926
|
Wow i just realized (testing ffdshow-quicksync) some vendor DXVA implementations can avoid Ref Frame issues on EVR CoreAVC and Arcsoft are one of them without loosing hardware playback or need to fallback to Software very impressive
__________________
all my compares are riddles so please try to decipher them yourselves :) It is about Time Join the Revolution NOW before it is to Late ! http://forum.doom9.org/showthread.php?t=168004 |
22nd October 2011, 19:29 | #208 | Link | |
QuickSync Decoder author
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
|
Quote:
BTW, my decoder can fallback to SW under certain conditions. WMV3 isn't HW accelerated at all and clips with height OR width larger than 1080p also fallback to SW. This is noticeable by a significant change in CPU usage. In a future version I'll notify the app (ffdshow in this my case) that no HW acceleration is available and the app can choose whether to use Intel's SW implementation or use another SW decoder. Update: CPU usage is very high for Intel SW implementation because I keep using the D3D surfaces as frame buffers. This (of course) is far from optimal but will be addressed in the next release. So head to head benchmarks between Intel's SW implementation and libavcodec/libwmv9 will have to wait till then.
__________________
Eric Gur, Processor Application Engineer for Overclocking and CPU technologies Intel QuickSync Decoder author Intel Corp. Last edited by egur; 25th October 2011 at 19:51. |
|
22nd October 2011, 20:38 | #209 | Link |
/人 ◕ ‿‿ ◕ 人\
Join Date: May 2011
Location: Russia
Posts: 643
|
CoreAVC-dxva (the same applies to the mpc-dxva, ffdshow-dxva and mirillis splash player) + 1080p with 16 ReFrames:
http://2.firepic.org/2/images/2011-1...9yqyb9f86m.png But with your decoder everything is perfect P.s. another one sample with vfr (at least mediaInfo says so), that causes a/v desync: http://www.mediafire.com/?d54fscbebq2p4ag And this one is with real vfr (60/30): http://akross.info/guest/[akross.ru]...stique_alt.mkv Last edited by vivan; 22nd October 2011 at 20:57. |
22nd October 2011, 21:11 | #210 | Link | |
QuickSync Decoder author
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
|
Quote:
CoreCodec are free to use my code as reference or 'as is' if they want to. Hence the BSD license. If they do, another goal has been met at some level - improve SW that use the QuickSync technology. If someone has a clip that demonstrates this failure, please share. Don't be shy.
__________________
Eric Gur, Processor Application Engineer for Overclocking and CPU technologies Intel QuickSync Decoder author Intel Corp. |
|
22nd October 2011, 22:24 | #211 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 4,926
|
egur look @ http://forum.doom9.org/showthread.php?t=159486 i tested with the oceanic samsung x264 encode and CoreAVC 3.0.1 and Arcsofts DXVA2 survive it and i confirmed that they don't fallback to Software decoding either (some implementations do that after a bitstream check)
Vivan strange i tested several over ref frames clips from several x264 builds and it seems CoreCodec at least found a workaround the same as Arcsoft did, its impressive other solutions either switch to Software or error per frame areas egur this though isn't a problem that should interest you as you don't use DXVA your decoder will not suffer from this Cyberlinks DXVA has really to fight with this erroring out every frame with core 56 bitstreams
__________________
all my compares are riddles so please try to decipher them yourselves :) It is about Time Join the Revolution NOW before it is to Late ! http://forum.doom9.org/showthread.php?t=168004 Last edited by CruNcher; 22nd October 2011 at 23:28. |
22nd October 2011, 23:33 | #212 | Link |
QuickSync Decoder author
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
|
Actually, my decoder uses the Intel Media SDK which uses DXVA2. So indirectly I'm using DXVA...
__________________
Eric Gur, Processor Application Engineer for Overclocking and CPU technologies Intel QuickSync Decoder author Intel Corp. |
23rd October 2011, 10:55 | #213 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 4,926
|
yup im not sure but it seems only DXVA1 implementations are affected and Cyberlink seems to be still DXVA1 both Arcsoft and CoreAVC are DXVA2 implementations and don't suffer from it, though CoreAVC even plays some more test bitstreams then Arcsoft does
__________________
all my compares are riddles so please try to decipher them yourselves :) It is about Time Join the Revolution NOW before it is to Late ! http://forum.doom9.org/showthread.php?t=168004 |
23rd October 2011, 11:18 | #214 | Link | ||
/人 ◕ ‿‿ ◕ 人\
Join Date: May 2011
Location: Russia
Posts: 643
|
Quote:
Quote:
E.g. with this sample, coreavc shows mess for about 2/3 of time, mpc-dxva - 9/10, but mirillis splash player have only few artifacts (so ~1/30 of time). At least on my i5-2410M with intel HD 3000. |
||
23rd October 2011, 12:06 | #215 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 4,926
|
thx for the sample going to check, and yes sure fffdshow-quicksync is more robust the same as nvidia cuvid is though also under XP (NT5) that intel doesn't support anymore for valid reasons
But the Ref problem is one of the major issues people change from DXVA to other solutions and the upcoming 10 bit and 4:2:2 wave (though problem on the Hardware support level) obviously at least under NT 6 it's much better in terms of flexibility when mixing different inputs (subbtitles, interactive layers (guis), different content, pp systems(shader,cpu,compute)) also in terms of editing via the copy and transfer between GPU (memory) capabilities though not many make use of this currently My work on my High Efficiency DWM Desktop (DirectX,OpenGL) Capture and Transcode framework leverages all of this (except compute currently) mixing it in near realtime (latency of H.264, still testing different efficiency scenarios because of GPU/CPU dependency) im confident i can do even better then Mirillis with Action http://mirillis.com/en/products/action.html (and their FIC codec) does in the End on supported systems PS: Yep Vivan that bitstream is hardcore (Anime exaggerated Encoding style ) Arcsoft DXVA freezes straight @ the start Cyberlinks goes Hi wire only CoreAVCs DXVA can produce something with your shown errors from here to their though amazing how CoreCodec compensates even this level lower levels seem no problems to fix for them entirely (might be also the reason it's not up to the performance of Cyberlinks DXVA which fails even @ lower levels) Mirillis really pushes the boundary here once again wow as you said ultra low CPU ultra low GPU and only 1 issue their custom Renderer and Decoder is really efficient as hell (these polish guys really fascinate, they are on the super right track) Action is definitely gonna beat Fraps hands down i give you my word for it these guys know what they do Though we should be also true these Bitstreams are rare they exist but they are still rare (mostly old x264 encoder libx264 used via ffmpeg in the commercial space without any idea from the user what he actually does) though it's good to know that somebody cares about efficiency behind specs (Vivan be also advised im no fan of this exaggerated Anime Encoding style as i find it useless in most cases, it's just not worth for every pixel quality to brake specs which will be hardly visible @ all,also in Power Consumption terms and yeah im no fan of Placebo either )
__________________
all my compares are riddles so please try to decipher them yourselves :) It is about Time Join the Revolution NOW before it is to Late ! http://forum.doom9.org/showthread.php?t=168004 Last edited by CruNcher; 23rd October 2011 at 13:30. |
23rd October 2011, 14:12 | #216 | Link |
QuickSync Decoder author
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
|
1440x1080 ts clips
Does anyone have an idea if I should correct 1440x1080 with aspect ratio of 4:3 to an aspect ratio of 16:9?
I've noticed some clips that have this wrong AR and thus displayed wrong. The wrong aspect ratio of 4:3 exists in both the media type as well as the PPS (h264).
__________________
Eric Gur, Processor Application Engineer for Overclocking and CPU technologies Intel QuickSync Decoder author Intel Corp. |
23rd October 2011, 14:49 | #217 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
If the stream is flagged improperly, dont touch it. It could as well be meant to be 4:3, you will never know.
The only correction i do automatically is crop a height of 1088 to 1080, because in 99.99% of all cases, thats correct. (Just missing the cropping flags in the bitstream)
__________________
LAV Filters - open source ffmpeg based media splitter and decoders Last edited by nevcairiel; 23rd October 2011 at 14:54. |
23rd October 2011, 17:21 | #219 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
I have never seen a 1440x1080 that was wrongly flagged and playing as 4:3 eventhough it is 16:9, tbh.
One would imagine that in all this time, someone would've posted such a sample as a bug report.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
23rd October 2011, 20:01 | #220 | Link | |
QuickSync Decoder author
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
|
Quote:
__________________
Eric Gur, Processor Application Engineer for Overclocking and CPU technologies Intel QuickSync Decoder author Intel Corp. |
|
Tags |
ffdshow, h264, intel, mpeg2, quicksync, vc1, zoom player |
Thread Tools | Search this Thread |
Display Modes | |
|
|