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 9th December 2011, 11:38   #281  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,494
Quote:
Originally Posted by haruhiko_yamagata View Post
For what kind of video is this useful?
Which profiles of H.264 does this support?
Can this output 10/12-bit formats?
- It supports the same formats as DXVA, so only 8-bit 4:2:0 (MPEG2, H264 and VC1)
- H264 High profile, no 10-bit or 4:2:2/4:4:4
- See above, only 8-bit. Output is always NV12.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 9th December 2011, 14:49   #282  |  Link
egur
QuickSync Decoder author
 
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
Quote:
Originally Posted by haruhiko_yamagata View Post
Thanks a lot for the update.
Can I ask several questions and requests? Please excuse me for not reading all of this thread. I read several pages. I do not have sandy bridge and can not test your decoder.
I would like to ask you to add an entry to our wiki and answer these questions. I think most of my questions are FAQ.
If I have permissions, I'll add the following questions to the Wiki. No prb.

Quote:
Originally Posted by haruhiko_yamagata View Post
Can ffdshow output other color spaces than NV12?
Can ffdshow resize?
If screen is not connected to the Intel GPU, and the renderer is not the WMC full screen, does your decoder work?
Are the strides aligned?
How fast is this?
For what kind of video is this useful?
Which profiles of H.264 does this support?
Can this output 10/12-bit formats?
* HW Decoder only outputs NV12, but ffdshow converts the output to what was agreed with the downstream filter.
* ffdshow can perform all of it's post processing as long as they work well with NV12 input. swscale had issues with NV12->NV12 copies so I changed ffdshow's code to use a nother copy method. Now I didn't see any issues and none where reported to me on the matter.
* With the exception of WMC FS, multi GPU setups are working (I personally have this setup AMD Radeon HD6950). I'm working on fixing WMC FS with multi GPU setup - partial success.
* Strides are always 16 byte aligned.
* How fast? Worst case scenario is ~2x faster than libavcodec (low bitrate clips). Speed difference is greater for high bitrate clips. CPU frequency stays at LFM (800MHz mobile/ 1600MHz Desktop) for the duration of playback. CPU overhead is usually related to image resolution and frame rate and not birate since I copy the frames to system memory.
* Decodes H264 up to and including high profile. MPEG2 - all expect the 4:2:2 profile. VC1 - advanced profile in HW, MP&SP in SW. Future HW will support more video formats.
* Unfortunately, HW only decodes 8 bit 4:2:0 formats ATM . The decoder only outputs only NV12. This might change in the future. I can't commit on this.
__________________
Eric Gur,
Processor Application Engineer for Overclocking and CPU technologies
Intel QuickSync Decoder author
Intel Corp.
egur is offline   Reply With Quote
Old 9th December 2011, 15:19   #283  |  Link
haruhiko_yamagata
Registered User
 
Join Date: Feb 2006
Location: Japan
Posts: 1,560
Thank you very much for reply.
You can register to the wiki here. Please note that the wiki cannot sent any e-mails, even if it says it would. For example, password retrieval through e-mail is not available.
__________________
[ Download ffdshow | Wiki ]
haruhiko_yamagata is offline   Reply With Quote
Old 12th December 2011, 08:48   #284  |  Link
Esperado
Registered User
 
Join Date: Dec 2011
Posts: 22
Hi, Egur.
I have tried last FFdshow with QuickSync in DvbViewer. I wonder why it eats more CPU than CoreAVC, with my Radeon HW acceleration (DXVA) for example.
Don't it is supposed to use only Hardware?
I do not see any difference if i pluga monitor in the intel VGA output or not. And, if not, and if i start DVBViewer by Virtu, it eats more CPU..
Thanks for your sharing and you work, anyway.
I wonder why Intel does not provide codecs using directly the Sandy Bridge acceleration ?
Best regards.
Esperado is offline   Reply With Quote
Old 12th December 2011, 08:57   #285  |  Link
egur
QuickSync Decoder author
 
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
Quote:
Originally Posted by Esperado View Post
Hi, Egur.
I have tried last FFdshow with QuickSync in DvbViewer. I wonder why it eats more CPU than CoreAVC, with my Radeon HW acceleration (DXVA) for example.
Don't it is supposed to use only Hardware?
I do not see any difference if i pluga monitor in the intel VGA output or not. And, if not, and if i start DVBViewer by Virtu, it eats more CPU..
Thanks for your sharing and you work, anyway.
It uses HW for decoding but the frame are copied back to CPU memory for further processing, hence the non zero CPU usage.
Make sure you selected Intel QuickSync as the decoder in ffdshow's codec tab for h264,mpeg2,vc1.

Quote:
Originally Posted by Esperado View Post
I wonder why Intel does not provide codecs using directly the Sandy Bridge acceleration ?
Best regards.
Actually decoders are shipped with the driver.
BTW Microsoft's DVT-DVD decoder also uses HW acceleration - when connected to an EVR renderer but it fails on some types of clips - but will work on most content.
Using a pure DXVA playback pipeline is very restrictive - decoder must connect directly to a special renderer, decoder output can't be modified by the renderer, etc.
My solution of copying the images comes at a price but it's much more versatile.
__________________
Eric Gur,
Processor Application Engineer for Overclocking and CPU technologies
Intel QuickSync Decoder author
Intel Corp.

Last edited by egur; 17th December 2011 at 10:32.
egur is offline   Reply With Quote
Old 12th December 2011, 10:24   #286  |  Link
haruhiko_yamagata
Registered User
 
Join Date: Feb 2006
Location: Japan
Posts: 1,560
Egur, thank you very much for the wiki.
Now we have a good summary for our new decoder.
fastplayer, thank you for the update.
__________________
[ Download ffdshow | Wiki ]
haruhiko_yamagata is offline   Reply With Quote
Old 13th December 2011, 01:04   #287  |  Link
Esperado
Registered User
 
Join Date: Dec 2011
Posts: 22
Quote:
Originally Posted by egur View Post
It uses HW for decoding but the frame are copied back to CPU memory for further processing, hence the non zero CPU usage.
Quote:
Originally Posted by egur View Post
My solution of copying the images comes at a price but it's much more versatile.
As it cost *more* CPU than other ordinary hardware accelerated codecs, and i do not see any much better quality in real time TNT decoding (specially about De-interlacing), i believe i will forget the graphics from my Sandy Bridge to save some power and temp.
The interest, for me -and the reason why i was interested in those Sandy Bridge- was to can watch TNT on my PC with no CPU load. Some kind of TV/Monitor set.
Quote:
Originally Posted by egur View Post
Make sure you selected Intel QuickSync as the decoder in ffdshow's codec tab for h264,mpeg2,vc1.
Of course i did. And tried everything. Monitor connected on motherboard VGA or not (no changes), Virtu or not (It eats more CPU, launching DvbViewer with Virtu, and no noticeable quality change...)


Quote:
Originally Posted by egur View Post
Actually decoders are shipped with the driver but they are not very good. This is something I'm trying to improve behind the scenes.
You made a very nice work. Shame it is unofficial.
In fact, i found no Intel Codecs registered for Direct show on my computer after Install, and i only found your thread after a long research on Google. I'm very disappointed with Intel position, in that matter, marketing announces effects, and nothing usable for real time decoding, apart your personal work in fact ? Unbelievable from such a big company.
Esperado is offline   Reply With Quote
Old 13th December 2011, 08:10   #288  |  Link
egur
QuickSync Decoder author
 
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
Quote:
Originally Posted by Esperado View Post
As it cost *more* CPU than other ordinary hardware accelerated codecs, and i do not see any much better quality in real time TNT decoding (specially about De-interlacing), i believe i will forget the graphics from my Sandy Bridge to save some power and temp.
The interest, for me -and the reason why i was interested in those Sandy Bridge- was to can watch TNT on my PC with no CPU load. Some kind of TV/Monitor set.
Of course i did. And tried everything. Monitor connected on motherboard VGA or not (no changes), Virtu or not (It eats more CPU, launching DvbViewer with Virtu, and no noticeable quality change...)
The frame copying paradigm allows decode flows unavailable to DXVA decoders - avisynth acceleration, multi-GPU setup (decoder on SNB + high-end renderer like MadVR on dGPU). The performance price is small.

Virtu isn't needed with my decoder. It would be useful with a DXVA decoder.

Quote:
Originally Posted by Esperado View Post
You made a very nice work. Shame it is unofficial.
In fact, i found no Intel Codecs registered for Direct show on my computer after Install, and i only found your thread after a long research on Google. I'm very disappointed with Intel position, in that matter, marketing announces effects, and nothing usable for real time decoding, apart your personal work in fact ? Unbelievable from such a big company.
One can always use Microsoft's DTV-DVD decoder which ships with Win7. But this decoder isn't 100% working on my test suite... But it works on most content.
__________________
Eric Gur,
Processor Application Engineer for Overclocking and CPU technologies
Intel QuickSync Decoder author
Intel Corp.

Last edited by egur; 17th December 2011 at 10:42.
egur is offline   Reply With Quote
Old 14th December 2011, 20:48   #289  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,949
Quote:
Internally I'm pushing for better HW enablement (SW, docs, sample code) - for both end-users and independent developers. My work has created a lot of positive noise within Intel and it's one step forward towards high quality enablement.
Great news hope those responsible @ Intel see the chance like Nvidia did right from the VPx start way back then, it's to sad to see a lot of times such engagement smashing @ the big chairs for whatever stupid reasons, though i have to say Intels Ecosystem around it's hardware is much better from the start compared to how catastrophic it was with AMDs taking themselves years of time and then come up with something that no one really likes to implement
Not that i didn't expected Intels SB support for all classes to be awesome from the start but i was skeptical after the ATI disaster that only Nvidia might have realized the chance about such a strong community Ecosystem from Devs to End users
Though since my move back from AMD to Intel i wasn't yet disappointed (ok the bad B2 stepping thing was a big disaster itself but fast fixed without compromise, personally i decided i don't need the B3 anyways )

Btw Eric are you and Blight related to each other family wise or is the surname match just a coincidence are you maybe brothers would make sense somehow as he also knew something about your past work i wondered ?
__________________
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; 14th December 2011 at 21:25.
CruNcher is offline   Reply With Quote
Old 14th December 2011, 23:51   #290  |  Link
haruhiko_yamagata
Registered User
 
Join Date: Feb 2006
Location: Japan
Posts: 1,560
In ffdshow's codecs configuration page, IntelQuick Sync Decoder is listed for MPEG-1, but is this working? Because it is not listed in TglobalSettingsDecVideo::c_mpeg1, I suspect it is not working. Can I remove MPEG-1 support?
__________________
[ Download ffdshow | Wiki ]
haruhiko_yamagata is offline   Reply With Quote
Old 15th December 2011, 09:18   #291  |  Link
egur
QuickSync Decoder author
 
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
Quote:
Originally Posted by haruhiko_yamagata View Post
In ffdshow's codecs configuration page, IntelQuick Sync Decoder is listed for MPEG-1, but is this working? Because it is not listed in TglobalSettingsDecVideo::c_mpeg1, I suspect it is not working. Can I remove MPEG-1 support?
Yes, my mistake, please remove.
Maybe the decoder supports mpeg1 but for such low resolution clips, there no point to do HW acceleration. FFDShow's support for mpeg1 is already very good.
__________________
Eric Gur,
Processor Application Engineer for Overclocking and CPU technologies
Intel QuickSync Decoder author
Intel Corp.
egur is offline   Reply With Quote
Old 15th December 2011, 09:58   #292  |  Link
egur
QuickSync Decoder author
 
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
Quote:
Originally Posted by CruNcher View Post
...

Btw Eric are you and Blight related to each other family wise or is the surname match just a coincidence are you maybe brothers would make sense somehow as he also knew something about your past work i wondered ?
Yes, we are brothers. Good catch
__________________
Eric Gur,
Processor Application Engineer for Overclocking and CPU technologies
Intel QuickSync Decoder author
Intel Corp.
egur is offline   Reply With Quote
Old 15th December 2011, 20:12   #293  |  Link
egur
QuickSync Decoder author
 
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
New version released 0.20

Version 0.20 is out with the following changes:
* Fixed support for WMC full screen exclusive mode:
- Works with multi-GPU setups. Video decoding is HW accelerated using QuickSync. Renderer can be on a different GPU.
- WMC's background thumbnail creation is done in SW
* FFDShow rev4149

Download from SourceForge home page:
http://sourceforge.net/p/qsdecoder
__________________
Eric Gur,
Processor Application Engineer for Overclocking and CPU technologies
Intel QuickSync Decoder author
Intel Corp.
egur is offline   Reply With Quote
Old 16th December 2011, 23:01   #294  |  Link
Blight
Software Developer
 
Blight's Avatar
 
Join Date: Oct 2001
Location: Israel
Posts: 994
CruNcher:
Yes, we're bros :P
Eric's wanted to do something like this for years, but now he's in a good position to do so and I've been helping here and there to move things along.
Hopefully, the good people @Intel are watching... He's doing them a heck of a service, both technical and promotional.
__________________
Yaron Gur
Zoom Player . Lead Developer
Blight is offline   Reply With Quote
Old 17th December 2011, 14:46   #295  |  Link
hhb97b
Registered User
 
Join Date: Dec 2009
Posts: 6
performance

Hi

I have been so lucky to borrow a acer aspire 7750g for a day, which has an i7 2670QM cpu and a amd radeon HD6650m gpu.
This was my opportunity to try out your decoder. It worked without a problem, but there is one thing I don't understand.
I had choosen quick sync decoder in the decoder tab and choose resize, sharpen, blur and a avs script as the configuration to test. The reason for all
the post processing was to generate as much processing instructions as possible. I used version 0.20 for intel quicksync decoder and mpc hc 1.5 as testbed.

My expectations was that quicksync decoder would handle this load better than the with the libavcodec decoder, but this is not what I saw.
My experience was that I couldn't playback a 1080P video with a bitrate of 10500 kbps at normale speed. The pikes was around 52ms/127 % for "Time on ffdshow", which means it decode slow that the movies FPS.
However when I used the same configuration with libavcodec the results was 38ms/90%. Was my expectation wrong or what could cause this experience?
hhb97b is offline   Reply With Quote
Old 17th December 2011, 20:25   #296  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,949
the latency issue most probably comes from the memory path (main memory gpu memory copy + post processing stress on the CPU)though it's faster then with a discrete card or @ least should be dynamic frequency switching and so latency changes of the main memory can also have a impact you shuffling quiet a lot of data around @ 1080p with the additional post processing though my tests with my Quicksync recording Framework showed that it's really application dependent of what in the current task is more efficient to use a good rule of thumb i guess is the more GPU resource the main application needs the better it is to use the CPU for any other task and vice versa (trying to keep both in balance is the key to the optimum, especially with DWM and Aero it becomes more complex handling this) the more CPU resources a application uses the better it is to use the GPU finding the right balance and a dynamic way to distribute it (efficient resource scheduling) though isn't easy and very Framework dependent, though the major culprit here is the OS and the Driver itself something very rare persons have the possibility todo major changes on (see preemptive changes in WDDM 1.2 Win8)

Another rule of thumb If you really need time critical performance that beats Software in most cases their is no way around native DXVA Microsoft did a excellent job on it, or you need a very strong overall system so it doesn't surprise in your case try to disable power saving and see how that impacts the latency

If you really need the last drop of Performance (Power Saving) on those regards in Playback with a good post pro try Mirillis Splash Player it's really excellent in Performance (very well usage of what Microsoft supplies to ISVs in the Directx API on really every level UI, Renderer (own Direct 3d based one, supporting deinterlacing and subtitles), Subbtitle Renderer (own) + very efficient usage of their own decoders DXVA + Shaders in that combination
It was absolutely designed with 1 goal in mind drawing and manipulating (post pro) videos on the screen as fast as possible without a lot of resources (power efficient,sheduling GPU/CPU as good as possible for the tasks) utilizing what Microsofts Provides ( i havent seen any better yet and i know a lot maybe only 1 player currently comes near that from Asia though still misses features and relies partly on other peoples code (ffmpeg vobsub lot from mpc-hc) that would be Potplayer )
__________________
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; 17th December 2011 at 21:17.
CruNcher is offline   Reply With Quote
Old 20th December 2011, 23:29   #297  |  Link
egur
QuickSync Decoder author
 
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
Quote:
Originally Posted by hhb97b View Post
Hi

I have been so lucky to borrow a acer aspire 7750g for a day, which has an i7 2670QM cpu and a amd radeon HD6650m gpu.
This was my opportunity to try out your decoder. It worked without a problem, but there is one thing I don't understand.
I had choosen quick sync decoder in the decoder tab and choose resize, sharpen, blur and a avs script as the configuration to test. The reason for all
the post processing was to generate as much processing instructions as possible. I used version 0.20 for intel quicksync decoder and mpc hc 1.5 as testbed.

My expectations was that quicksync decoder would handle this load better than the with the libavcodec decoder, but this is not what I saw.
My experience was that I couldn't playback a 1080P video with a bitrate of 10500 kbps at normale speed. The pikes was around 52ms/127 % for "Time on ffdshow", which means it decode slow that the movies FPS.
However when I used the same configuration with libavcodec the results was 38ms/90%. Was my expectation wrong or what could cause this experience?
I managed to reproduce similar results but I haven't root caused the problem.
Several options exist:
* Memory bus is saturated like Cruncher said.
* FFDshow's video processing algorithms are not optimized for NV12 surfaces (don't know need to check).
* Maybe there's a color space conversion to YV12.

I'll need to run a profiler among other things to get to the bottom of this, but it it looks interesting. I'll report back.

With pure DXVA you get the best performance + power savings but video processing becomes tricky usually done in the renderer. The frames outputted by the decoder are used by it as reference frames and mustn't be modified. Copying the frames is an option, but that's very similar to what I do. Writing video processing (like FFDshow have) using shader language (or CUDA) isn't easy at all as can be seen by their rarity. Although I think it's possible to create a DXVA video processor filter, I'm not aware of one existing.
__________________
Eric Gur,
Processor Application Engineer for Overclocking and CPU technologies
Intel QuickSync Decoder author
Intel Corp.
egur is offline   Reply With Quote
Old 21st December 2011, 14:52   #298  |  Link
hhb97b
Registered User
 
Join Date: Dec 2009
Posts: 6
I believe that you are both correct

* Memory bus is saturated like Cruncher said.
I think this is the case in some situation because I couldn't use all of the cpu power even when I only used libavcodec. The cpu usage was only at 50% before the "time on ffdshow" was over 41 ms

* Maybe there's a color space conversion to YV12
I have set the "input colorspace" to yv12 under the avscript tab . I'm using the script rgb3dlut/t3dlut from tritical as colour management system. The input colorspace for the script are yuy2, rgb24, and rgb32. This means that in test-setup there would have been a colorspace-convertion like this

? -> nv12(decoder) -> yv12(avs tab) -> yuy2(script) -> rgb(script) -> output

Will the QuickSync decoder support other colorspace than nv12 or is this a limitation of the hardware?
hhb97b is offline   Reply With Quote
Old 21st December 2011, 15:14   #299  |  Link
egur
QuickSync Decoder author
 
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
Quote:
Originally Posted by hhb97b View Post
I believe that you are both correct

* Memory bus is saturated like Cruncher said.
I think this is the case in some situation because I couldn't use all of the cpu power even when I only used libavcodec. The cpu usage was only at 50% before the "time on ffdshow" was over 41 ms

* Maybe there's a color space conversion to YV12
I have set the "input colorspace" to yv12 under the avscript tab . I'm using the script rgb3dlut/t3dlut from tritical as colour management system. The input colorspace for the script are yuy2, rgb24, and rgb32. This means that in test-setup there would have been a colorspace-convertion like this

? -> nv12(decoder) -> yv12(avs tab) -> yuy2(script) -> rgb(script) -> output

Will the QuickSync decoder support other colorspace than nv12 or is this a limitation of the hardware?
I ran a profiler to find the problem and here's what I've found:
* ffdshow's internal video processing code runs at about the same speed.
* No color space conversion occurs (I didn't use avisynth) but your use case "enjoys" the extra conversion.
* The CPU time spent within the HW decoder + driver is extremely small. But wall-time may pass - I don't know how much. Wall time doesn't register anywhere but it adds to the decode latency.
* ffdshow doesn't use threads to do video processing (seems that way anyway) so it's not using the 8 threads my i7-2600 has. At most i got it to use <2 cores (up to 15% utilization in task manager).
* Time is spent locking the D3D surface within my decoder. I don't know how to optimize this operation.

As a quick conclusion, I see that I need to perform the frame copying on another thread (simple fix) maybe even the decode itself (not so simple).
This will cut down the wall time the decode thread stays within my decoder and as a result - cut down ffdshow's latency allowing more code to run.

This is especially useful for full speed decoding (e.g. transcoding use case).

If no horrible bugs were introduced in the last version, I'll start working on it.

Regarding HW support, NV12 is the only supported format. There's no point in adding support for surface conversions in my decoder. NV12 is the most HW friendly format and I think all GPUs use it. NV12 use only 2 "pointers" - one for Y and one for UV. Usually color operations work on both U and V so cache hits are much better. This is actually true for SW as well. Y is separated because many operations work on Y alone. It's also the format recommend by Microsoft. Although not supporting 4:2:2/4:4:4 or bit depth greater than 8bit, 99.99% of the video content can be represented as NV12.

The modern renderer which uses HW acceleration also like this format as it saves another format conversion.
__________________
Eric Gur,
Processor Application Engineer for Overclocking and CPU technologies
Intel QuickSync Decoder author
Intel Corp.

Last edited by egur; 21st December 2011 at 15:31.
egur is offline   Reply With Quote
Old 21st December 2011, 17:44   #300  |  Link
hhb97b
Registered User
 
Join Date: Dec 2009
Posts: 6
Quote:
Originally Posted by egur View Post
I ran a profiler to find the problem and here's what I've found:
* ffdshow's internal video processing code runs at about the same speed.
* No color space conversion occurs (I didn't use avisynth) but your use case "enjoys" the extra conversion.
* The CPU time spent within the HW decoder + driver is extremely small. But wall-time may pass - I don't know how much. Wall time doesn't register anywhere but it adds to the decode latency.
* ffdshow doesn't use threads to do video processing (seems that way anyway) so it's not using the 8 threads my i7-2600 has. At most i got it to use <2 cores (up to 15% utilization in task manager).
* Time is spent locking the D3D surface within my decoder. I don't know how to optimize this operation.

As a quick conclusion, I see that I need to perform the frame copying on another thread (simple fix) maybe even the decode itself (not so simple).
This will cut down the wall time the decode thread stays within my decoder and as a result - cut down ffdshow's latency allowing more code to run.

This is especially useful for full speed decoding (e.g. transcoding use case).

If no horrible bugs were introduced in the last version, I'll start working on it.

Regarding HW support, NV12 is the only supported format. There's no point in adding support for surface conversions in my decoder. NV12 is the most HW friendly format and I think all GPUs use it. NV12 use only 2 "pointers" - one for Y and one for UV. Usually color operations work on both U and V so cache hits are much better. This is actually true for SW as well. Y is separated because many operations work on Y alone. It's also the format recommend by Microsoft. Although not supporting 4:2:2/4:4:4 or bit depth greater than 8bit, 99.99% of the video content can be represented as NV12.

The modern renderer which uses HW acceleration also like this format as it saves another format conversion.
Well this was also my expectation regarding the colorspace question, but I just wanted you to confirm it. Thanks for the detailed post to your both.

Last edited by hhb97b; 21st December 2011 at 18:58.
hhb97b 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 02:15.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.