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.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 21st October 2011, 17:08   #201  |  Link
pulbitz
Registered User
 
Join Date: Sep 2011
Posts: 22
Quote:
Originally Posted by pulbitz View Post
I'm sorry. I don't speak English very well.

audio/video unsync (with Gabest Splitter) sample files.

(2011.09.28) Hyun Young 조현영 _A_ @ Gachon University Festival Celebration Fancam(720p_H.264-AAC).mp4
http://o-o.preferred.fra02s05.v5.lsc...89491d982d9386

(2011.10.06) Hyun Young 조현영 _Mach_ @ Gyeonggi University of S&T Festival Fancam(720p_H.264-AAC).mp4
http://o-o.preferred.fra02s05.v7.lsc...30d6979f680c4c

QuickSync = 30.303fps
libavcodec = 29.97xfps

please improve your timestamp code more.
Quote:
Originally Posted by egur View Post
I know I need to improve the time stamps. Fixed a few things in the v0.16 but there's still more work to do...

The links you've posted are not working - "access denied" for both. You can share very quickly on http://www.multiupload.com
I upload files. Please try again.

http://www.mediafire.com/?jql2qu8xj22c2ar
http://www.mediafire.com/?ye6oudmltypr7ey
pulbitz is offline   Reply With Quote
Old 21st October 2011, 23:00   #202  |  Link
egur
QuickSync Decoder author
 
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
Quote:
Originally Posted by pulbitz View Post
Got the files.
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.
egur is offline   Reply With Quote
Old 21st October 2011, 23:50   #203  |  Link
JanWillem32
Registered User
 
JanWillem32's Avatar
 
Join Date: Oct 2010
Location: The Netherlands
Posts: 1,084
Quote:
Originally Posted by egur View Post
I haven't seen anything like this - two DXVA devices from different GPUs passing surfaces from one to the other?

I can take your word for it but it's probably extremely complicated to accomplish.

In the Intel GPU, I don't think there's any DMA going on when copying surfaces back and forth to the CPU. It's the same memory sitting on the same memory controller. A special SSE4 instruction was introduced in Penryn to address the complex mapping to solve the speed issues.
DMA just means getting valid pointers to memory outside of regular system memory. It's just a matter of pointer logic between two DirectX 9 devices and giving direct access, without invoking a copy operation on an entire texture. As far as I know, DXVA uses rather normal render targets. Sharing a texture would look like this:
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
This way device 2 will have read/write access to that texture hosted in device's 1 memory. Ownership will stay with device 1, so when quitting, release RTTexture2 before it becomes invalid by releasing RTTexture1. (The same old story as with "new" and "delete", get rid of additional pointers first before destroying the object itself.)
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.
JanWillem32 is offline   Reply With Quote
Old 22nd October 2011, 06:54   #204  |  Link
pulbitz
Registered User
 
Join Date: Sep 2011
Posts: 22
Quote:
Originally Posted by egur View Post
Got the files.
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
No other problems.

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.
pulbitz is offline   Reply With Quote
Old 22nd October 2011, 08:59   #205  |  Link
markanini
Registered User
 
Join Date: Apr 2006
Posts: 293
Quote:
Originally Posted by pulbitz View Post
P.S. Not related QuickSync decoder. But can you look at this bug? http://communities.intel.com/thread/24972
Not sure if related but I'm seeing similar poor chroma upsampling on flash video.
markanini is offline   Reply With Quote
Old 22nd October 2011, 15:59   #206  |  Link
egur
QuickSync Decoder author
 
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
Quote:
Originally Posted by pulbitz View Post
P.S. Not related QuickSync decoder. But can you look at this bug? http://communities.intel.com/thread/24972
Quote:
Originally Posted by markanini View Post
Not sure if related but I'm seeing similar poor chroma upsampling on flash video.
I only use the decoder part of QuickSync ATM. The post processing comes from the renderer.

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.
egur is offline   Reply With Quote
Old 22nd October 2011, 19:17   #207  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,927
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
CruNcher is offline   Reply With Quote
Old 22nd October 2011, 19:29   #208  |  Link
egur
QuickSync Decoder author
 
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
Quote:
Originally Posted by CruNcher View Post
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
Can you explain, what's the Ref Frame issue with EVR? And what I did better then the others?

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.
egur is offline   Reply With Quote
Old 22nd October 2011, 20:38   #209  |  Link
vivan
/人 ◕ ‿‿ ◕ 人\
 
Join Date: May 2011
Location: Russia
Posts: 644
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.
vivan is offline   Reply With Quote
Old 22nd October 2011, 21:11   #210  |  Link
egur
QuickSync Decoder author
 
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
Quote:
Originally Posted by vivan View Post
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
Thanks for the clip, I'll check it out.
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.
egur is offline   Reply With Quote
Old 22nd October 2011, 22:24   #211  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,927
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.
CruNcher is offline   Reply With Quote
Old 22nd October 2011, 23:33   #212  |  Link
egur
QuickSync Decoder author
 
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
Quote:
Originally Posted by CruNcher View Post
egur this though isn't a problem that should interest you as you don't use DXVA your decoder will not suffer from this
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.
egur is offline   Reply With Quote
Old 23rd October 2011, 10:55   #213  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,927
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
CruNcher is offline   Reply With Quote
Old 23rd October 2011, 11:18   #214  |  Link
vivan
/人 ◕ ‿‿ ◕ 人\
 
Join Date: May 2011
Location: Russia
Posts: 644
Quote:
Originally Posted by CruNcher View Post
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)
even mpc-dxva plays it well, I guess it just doesn't use so much reframes.

Quote:
Originally Posted by CruNcher View Post
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
Maybe their implementations are a bit better, but they still are far from this decoder.
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.
vivan is offline   Reply With Quote
Old 23rd October 2011, 12:06   #215  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,927
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.
CruNcher is offline   Reply With Quote
Old 23rd October 2011, 14:12   #216  |  Link
egur
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.
egur is offline   Reply With Quote
Old 23rd October 2011, 14:49   #217  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 8,739
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.
nevcairiel is offline   Reply With Quote
Old 23rd October 2011, 16:53   #218  |  Link
Blight
Software Developer
 
Blight's Avatar
 
Join Date: Oct 2001
Location: Israel
Posts: 991
I would add an optional check-box.
I've seen quite a few 1440x1080 clips and they were all 16:9.
I have never seen one at 4:3.
__________________
Yaron Gur
Zoom Player . Lead Developer
Blight is offline   Reply With Quote
Old 23rd October 2011, 17:21   #219  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 8,739
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
nevcairiel is offline   Reply With Quote
Old 23rd October 2011, 20:01   #220  |  Link
egur
QuickSync Decoder author
 
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
Quote:
Originally Posted by nevcairiel View Post
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)
Quote:
Originally Posted by nevcairiel View Post
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.
Totally right, it tuned out to be bug in the splitter (Haali). With LAV splitter AR is correct. The clip was test.ts posted by CruNcher a while back on this thread.
__________________
Eric Gur,
Processor Application Engineer for Overclocking and CPU technologies
Intel QuickSync Decoder author
Intel Corp.
egur is offline   Reply With Quote
Reply

Tags
ffdshow, h264, intel, mpeg2, quicksync, vc1, zoom player

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 00:08.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.