View Full Version : CoreCodec/H.264 Codec "CoreAVC"
leeperry
8th January 2009, 04:09
leeperry.... that's a misleading statement on DivX7, it maybe as you state with some content and with 'your' configuration but for others as reported in this thread and in other threads it is not. That's why we feel the compare site is important, to inform.
oh ok sure, sorry...didn't mean to troll in your topic :rolleyes:
my results were on an o/c Q6600...they might very well differ on a dualcore/amd/p4 and so on :o
still hoping to see the bugs in CoreAVC CUDA I told you about fixed http://forum.slysoft.com/images/smilies/agreed.gif
laserfan
8th January 2009, 06:04
How can I try CoreAVC Pro as input to x264? It works fine with Media Player Classic, showing on my system that Sonic HD Demuxer is feeding it, but I can't seem to make an Avisynth script that x264 (or e.g. VirtualDub) will work with.
I've tried the simple
DirectShowSource("d:\video.h264")
since CoreAVC is set to Preferred but no dice. I've tried building a graph and opening IT:
First I tried Haali Media Splitter and it says "not a recognized format" (the h264 is demuxed from a BD disc). Using Sonic HD Demuxer lets the graph play with a Video Renderer but it won't open in an .avs.
How can I try CoreAVC as input to x264?
Guest
8th January 2009, 06:10
Start with the working graph. Remove the renderer. Save it. Then open the graph using DirectShowSource("video.grf", audio=false).
laserfan
8th January 2009, 06:36
Thanks but no go here. Seems simple, I dragged the video.264 onto GraphEdit and it makes a nice
video.264 --> Sonic HD Demuxer --> CoreAVC Video Decoder --> VMRinput Video Renderer
graph and this plays out of GE in an ActiveMovie window. I delete the Video Renderer, save the graph and then make a 'try.avs' that's simply:
DirectShowSource("d:\video.grf", audio=false)
but this .avs causes the x264 cmd to yield
avis [error]: unsupported input format (DIB)
x264 [error]: could not open input file 'try.avs'
BTW I do see an instance of CoreAVC's icon in the tray appear when I launch my x264.cmd which lingers there after the cmd is done. Then I mouse over it and it disappears, so SOMETHING got CoreAVC's attention, but it hangs. Any ideas???
rebkell
8th January 2009, 06:54
Try moving the YV12 Output format to the top of the list in Output formats: in the config for CoreAVC.
Guest
8th January 2009, 06:56
Does the AVS open in VirtualDub?
Snowknight26
8th January 2009, 08:24
Try moving the YV12 Output format to the top of the list in Output formats: in the config for CoreAVC.
Or just add ConvertToYV12() to your avs file.
laserfan
8th January 2009, 15:11
Try moving the YV12 Output format to the top of the list in Output formats: in the config for CoreAVC.
Or just add ConvertToYV12() to your avs file.YV12 Output is already on top for CoreAVC.
Does the AVS open in VirtualDub?No, neither VDub nor VDubMod would open it. This morning I've tried instead demuxing to an .mkv instead of .h264 and the resultant .grf is very simple:
video.mkv --> CoreAVC Video Decoder --> VMR Video Renderer
Delete the Renderer and this works! The (simple) DSSource .avs is liked by x264 and Vdub both. But I'd like to know why .mkv works but .h264 doesn't? GraphEdit inserts/wants Sonic HD Demuxer between the source and the CoreAVC for 264 (which doesn't work with .avs/x264/Vdub) but .mkv is so simple Input --> CoreAVC? I don't get it. Both types of files are created by eac3to v2.87.
I did btw spend a bunch of time trying to get my DS to Prefer a different intermediate than Sonic HD Demuxer but nothing other than Cyberlink PDVD would insert there. I thought CoreAVC needed Haali. :confused:
Thanks guys, at least now I know how I can try CoreAVC as input to my x264.cmd--if anyone knows why I seem only to be able to use .mkv tho please advise!? I don't like these mysteries and I've spent hours on this...
Guest
8th January 2009, 15:48
No, neither VDub nor VDubMod would open it. What is the error message?
It works just fine for me.
BetaBoy
8th January 2009, 15:58
I thought CoreAVC needed Haali. :confused:
Not required but recommended (we love Haali's work and he is an asset to CoreCodec and the D9 community).
Sagekilla
8th January 2009, 15:58
@laserfan: If you're using DSS to open a graphedit file, your flow is supposed to be only Source --> Video Decoder. No renderer, that's only when you're displaying the video ;)
laserfan
8th January 2009, 16:10
What is the error message? It works just fine for me.After some long seconds, I get a "DirectShowSource: timeout waiting for graph to start". :(
I tried another .264 file, same problem. neuron2 (or anyone) if you simply drag a .264 file onto GraphEdit, what if anything does your system insert between the Input and the CoreAVC? On mine it insists on Sonic HD Demuxer and when I try to force Haali that doesn't work at all i.e. won't "connect".
Guest
8th January 2009, 16:17
http://neuron2.net/misc/grf.jpg
laserfan
8th January 2009, 16:20
Argh! Looks just like mine. Damn.
Thanks neuron2. Just doesn't work for me, and only CoreAVC exhibits a problem, and only with .264s. The only thing I can think is I'm using newest Avisynth & maybe I should revert to 2.5.7 or something?
madshi
8th January 2009, 17:41
we love Haali's work and he is an asset to [...] the D9 community
He was, when he was still active. There is a really bad bug in his current TS/m2ts splitter version (try playing m2ts with a 5.1 or 7.1 LPCM track) and he didn't care to fix it for 9.5 months now... :(
Guest
8th January 2009, 18:22
Is the source code available?
STaRGaZeR
8th January 2009, 19:36
He was, when he was still active. There is a really bad bug in his current TS/m2ts splitter version (try playing m2ts with a 5.1 or 7.1 LPCM track) and he didn't care to fix it for 9.5 months now... :(
Stereo LPCM won't play either :scared:
Neuron, if you're refering to Haali's splitter, no it's not open source.
laserfan
8th January 2009, 22:17
@laserfan: If you're using DSS to open a graphedit file, your flow is supposed to be only Source --> Video Decoder. No renderer, that's only when you're displaying the videoYep, my graphs look just like the one neuron2 posted, and play fine either out of GE or with MPC, but when I delete the Video Renderer and attempt an open it fails with a timeout.
I've uninstalled Avisynth 2.5.8 and installed 2.5.7 and then reinstalled 2.5.8, rebooting the PC and checking DirectShowSource.dll every time, to no avail. Note .mkvs work but not .h264s. CoreAVC is the only problem I'm having w/this--can anyone imagine what might be wrong? :scared:
Sagekilla
8th January 2009, 23:21
Personally, I've never tried doing a .264 Source --> CoreAVC --> Output to DSS. I've always done m2ts source / mkv source --> CoreAVC --> Output to DSS.
Shouldn't be an issue though, since CoreAVC -should- handle the file the same regardless.
Snowknight26
8th January 2009, 23:59
BetaBoy, any word on the release of a new Haali Media Splitter?
Cyber-Mav
9th January 2009, 00:25
I have yet to imagine any possible use of SSE4 for decoding, though maybe there might be something creative with pblend or pinsrd.
It will be used for some upcoming x264 optimizations, but those are only encoder-side.A lot. This by the way is the reason why CoreAVC has such a huge advantage on older CPUs--on newer ones, competing encoders making heavy use of SSE close the performance gap, but on older CPUs where SSE isn't available or isn't very fast, CoreAVC has a large advantage.
does that mean that performance could get a bit better for older amd athlon xp cpus? (barton core specifically)
Sagekilla
9th January 2009, 02:07
If the CPU supports SSE (and isn't terribly slow at it), then yes. I don't know if the very first CPUs to have SSE (P3 and Athlon I believe?) have the fastest SSE engines though, so it might not net much of a benefit.
Dark Shikari
9th January 2009, 02:28
does that mean that performance could get a bit better for older amd athlon xp cpus? (barton core specifically)Athlon XPs don't even have SSE2.
roozhou
9th January 2009, 09:41
Argh! Looks just like mine. Damn.
Thanks neuron2. Just doesn't work for me, and only CoreAVC exhibits a problem, and only with .264s. The only thing I can think is I'm using newest Avisynth & maybe I should revert to 2.5.7 or something?
Try this. Just specify your input file as paff.264 and you don't need an avisynth script.
http://forum.doom9.org/showthread.php?t=141441
If you can also input .grf files, and remember NOT TO delete video renderer.
popper
9th January 2009, 12:39
Currently CoreAVC handles up to 2048x2048; besides Crowdrun, does anyone have any proper streams (i.e. that they haven't encoded themselves for testing) that exceed these limits?
the only Original higher test sets than 1080P i know of are the big bunny/ED and these grabs from 2004, but i dont know if they are also in encoded streams or just 3840x2160p/50 .sgi pics etc, just one pic is a massive 47.4MB (49.766.912 bytes) so your going to need a fast BB and lots of spare HD space though to make even a small test .TS/MKV
ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/SVT_MultiFormat_v10.pdf
ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/
perhaps other people know other CC test sets too, perhaps we should have a list made up for people to use!
Mottodj
9th January 2009, 12:57
Hi everyone. I have a question about switching color output formats in CoreAVC. I'm using mpc-hc with VMR9 and CoreAVC ver. 1.7, and while switch output format from YV12 to RGB32 picture changes colors(it looks like change colorimetry from bt601 to bt709). Is that decoder thing or it source problem?(original source(avc1 also) don't produce such issue, but x264 encode of this source produce such noticeble color change.)
squid_80
9th January 2009, 12:59
It's easy enough to make high res. H264 streams yourself, but I'm asking if anyone is having problems playing streams obtained from other (legitimate) sources. Otherwise I think people are making the issue seem bigger than it actually is.
popper
9th January 2009, 13:15
easy to upscale your content yes, but your going to loose details, capturing in these native res is another matter all together...even for the video Pros and their kit here id imagine, so perhaps a super HD list is still a good idea.
if you happened to have access to the "DVB-S2 Enables 140 Mbps Super Hi-Vision By Satellite At IBC 2008" stream then while its not a problem right now it might be one day....
something for the video devs to aspire to at least i guess.
http://www.dvb.org/news_events/dvbscene_magazine/DVB-SCENE27.pdf
page 4 of 16
"One of the highlights of this year’s IBC in Amsterdam is the first broadcast, live by satellite, of Super Hi-Vision (SHV) using DVB-S2, from the RAI Research up-link station in Turin.
SHV, the 4000 line x 8000 pixels/line television system under development by NHK, the Japanese public broadcaster, offers an astonishing user experience, thanks to a picture resolution sixteen times that of what we presently call ‘High Definition’.
There are 60 progressively scanned frames a second, and for audio,...
...
Since the native SHV signal bit rate is a massive 24 Gbit/s, the major part of the challenge has been in developing technical ways of delivering the service to the final user. SHV is in our case compressed using MPEG-4 AVC at a final bit-rate of around 140 Mbit/s and delivered to IBC in Amsterdam from the up-link station of the research headquarters of Italian public
broadcaster RAI in Turin, over Ku-band satellite capacity provided by Eutelsat.
For this first public demonstration of SHV by satellite, it will come as no surprise to discover that DVB-S2 technology has been selected by RAI, which led the development of this ‘father’ of second generation DVB systems in 2003....
"
http://www.dvb.org/news_events/dvbscene_magazine/index.xml
TheShadowRunner
9th January 2009, 15:39
In the latest nVidia drivers 181.20 release notes i see:
Added support for the new NVIDIA CUDA Video Encoder with H.264 optimization
Anyone has a clue what Encoder they're talking about? Any relation to CoreAVC? (the developer, not codec)
Later,
TSR
TheResidentEvil
9th January 2009, 17:48
I dont know what encoder they are talking about specifically however, I found this encoder which does support CUDA and I have never used
http://www.badaboomit.com/?q=node/4
Sharktooth
9th January 2009, 18:09
In the latest nVidia drivers 181.20 release notes i see:
Anyone has a clue what Encoder they're talking about? Any relation to CoreAVC? (the developer, not codec)
Later,
TSR
nope. i guess they're talking about their own encoder...
I dont know what encoder they are talking about specifically however, I found this encoder which does support CUDA and I have never used
http://www.badaboomit.com/?q=node/4
blah... badaboom still sux. on actual computers x264 is faster and produces better quality.
i guess they need some more months to actually produce a good encoder...
deekey777
9th January 2009, 20:09
In the latest nVidia drivers 181.20 release notes i see:
Anyone has a clue what Encoder they're talking about? Any relation to CoreAVC? (the developer, not codec)
Later,
TSR
CyberLink Launches the New PowerDirector 7 Optimized for NVIDIA CUDA Technology (http://www.cyberlink.com/eng/press_room/view_1994.html)
CyberLink PowerDirector 7 designed with NVIDIA CUDA Encoder technology achieves up to 274% performance gain when transcoding H.264 videos. By leveraging the multi-core parallel power of the GPU, PowerDirector 7 provides consumers with an accelerated video editing experience resulting in faster rendering of H.264 HD videos to AVCHD, M2T format and for viewing on iPod® and PSP®. PowerDirector 7 supports CUDA-enabled NVIDIA GeForce® processors with NVIDIA graphics drivers version 181.20 or higher.
Maybe it's Nvidia's answer to ATI's AVT.
popper
9th January 2009, 21:45
Isn't the solution simple? Implement the MV related functions twice. The current implementation, and a slower one that works with out-of-spec MVs. Add an option to the GUI called "Support out-of-spec motion vectors" with a tooltip like "Warning: this will reduce decoding performance". During initialization, just set the appropriate function pointer in the code based on the option. Users can then choose between speed and compatibility with non-standard video streams.
Result: All your customers are happy.
you missed out the most vital option, a BIG fat onscreen warning
"THIS IS AN OUT OF SPEC ENCODING,Please speak to the vendor"
you could also include the out of spec vecture OC to make it easy to report/fix etc....
that way, its clear that theres a problem somewere that people might not be aware of otherwise, and the master houses cant help but see this warning every time they play their wrong encodes in testing, its assumed they will be using CoreAVC in their chain at some time in their inhouse end user simulation tests, and so they get the chance to fix it BEFORE its released publicly...
that would do far more to help eradicate this problem in the future, as they wont want their encodes to be publicly broadcasting these Pro house Encoder errors to all their potential viewers/customers...
laserfan
9th January 2009, 22:13
http://neuron2.net/misc/grf.jpgI tried ArcSoft MPEG Demux instead of Sonic HD Demuxer and it finally works! My Sonic v4.3.0.89 must be broken somehow, and still dunno why Haali Splitter doesn't even like my 264 files, but glad I found that AS MPEG Demux works for h264 (nice name, no wonder I couldn't find it).
Thanks to neuron2 & all who responded. Man that was painful.
Guest
9th January 2009, 22:16
Mine is 4.2.00.0064.
popper
10th January 2009, 03:38
CyberLink Launches the New PowerDirector 7 Optimized for NVIDIA CUDA Technology (http://www.cyberlink.com/eng/press_room/view_1994.html)
Maybe it's Nvidia's answer to ATI's AVT.
AVT ?, perhaps you meant the ATI UVD ASIC Logic ! ,the equ of the NV VP2 Logic but better as its got more options!
it appears theres going to be a potentially long wait (at least months) for open source coders docs to access that UVD Logic if Ever OC, unless OC someone manages to persuade them to put the internal bean counters on ice as regards this UVD , rapidly shift gears, and put open UVD Logic docs and Dev errata support at the top of their list of things to do....
people like BetaBoy might stand a better chance to get access to UVD Logic docs and Dev support sooner though perhaps.. only if he and other Devs here asks them OC....
Bridgman said:""we are going to look into opening up UVD, I just can't make any commitments until we have actually gone through the investigation and it won't be quick. We have 6xx/7xx 3d code out now, so IMO the next priority should be basic power management. "
http://www.phoronix.com/forums/showthread.php?t=14641&page=9
"Quote:
Originally Posted by popper
thats a shame, we are looking at months at the very least then!
Bridgman said:For open source, yes, but I expect fglrx will have it sooner."
http://www.phoronix.com/forums/forumdisplay.php?f=43
popper
10th January 2009, 07:01
I hope you guys will support OpenCL instead of CUDA when NV and ATI drivers introduce support for it so that CoreAVC can make use of both ATI and NV :)
by the looks of it i wouldnt go getting any hopes up any time soon, NV VP2 Logic and potentially a lot later ATI UVD ASIC Logic if the review goes through and passes the OK are currently probably the chosen easy 3rd party dev path it seems, i dont know what you might use on Intel Gfx though ! ,do they also have an equivalent video streaming FIFO ASIC onboard? and a matching sub-set API you can easily use! to make it do stuff.
http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=104649&highlight_key=y&keyword1=openCL
it doesnt seem hopeful of any real alpha/beta progress until at least Q2 2009, and even then "The OpenCL spec puts the language at a higher level than CAL but not at as high a level as Brook+. "
the
Topic Title: Project on GPU accelerated applications
Topic Summary: Looking for ATI Stream programs
Created On: 01/04/2009 10:04 PM
posted 6 days ago
http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=106226&enterthread=y
only mentions one test app so far, not good....for the official site you would expect to see some early activity and test code in this generic ATI Stream programs subject
shader decoding test code "Generic GPU-Accelerated Video Decoding"
http://www.bitblit.org/gsoc/g3dvl/
says he made a somewhat working code thats super slow but kind of functions for HD, however thats working on NV only not ATI, so your going to have to add that ATI part and improve the speed a LOT, probably re-write it from scratch infact...using CAL and/or Brook+. http://forums.amd.com/devforum/categories.cfm?catid=328
http://www.phoronix.com/forums/showthread.php?p=57896#post57896
to the question of shader decoding , Bridgeman says
"....In terms of hardware required, quick answer is "nobody knows for sure until the code is written".
I doubt that the 40-ALU parts (HD2400, HD34xx, 780) will have enough power since the 3D engine is also being used for render accel (colour space conversion, scaling, deinterlacing etc..).
I have always suggested that anyone wanting to run the open source drivers go with at least a 120-ALU part (2600, 3650 etc..) to have some shader power left over for decode work.
Again, this is all hypothetical right now anyways. I am just trying to give everyone an idea of what the likely scenarios are -- "
that about covered the basic i think, were do we go from here on all platforms with your average ATI X1550,HD3650,HD4xxx card or two!
perhaps BetaBoy could be convinced to play a better Divx7 game ;) and have these produced as a plug in and go HW En/DE code portable device, linked together with a good FPGA for processing LOTS of related datasets and unthought of HW assisted apps today on a cheap USB2 stick, you WOULD have to finally write that PPC (thats a real powerPC remember BB) app to use it ON PPC (PS3 etc) linux etc though....BetaBoy ;)
if not Core, perhaps some readers with access to far easten contacts could have them run something like this up and we could get away from all this messy HD Encoding/Decoding, perhaps x264 could be refactored into a basic FPGA and put on USB2 too? and we could give X264 etc some money too for all the great work already done to bring us this far.
"just a very quick search brings you this mobile/handheld chipset/SOC (OC you could also use it in USB stick and the like , anyone doing that today), not as flexable as FPGA OC and not a PPC SOC but its cheap and flexible, and Ohh look...
"Each chip is a real-time H.264/MPEG4-AVC High Definition (level 4.1) Encoder/Decoder (Codec) that provides the ideal mix of flexibility and power efficiency for consumer electronics
applications....."
"full HD (1920x1080). Qpixel
is also raising the power-performance bar by being the first to offer
full HD H.264 encoding at less than 275 mW of power,"
http://www.reuters.com/article/pressRelease/idUS10020+02-Jun-2008+BW20080602
Industry's Lowest-Power Full HD H.264 Codecs With the Broadest Feature Set Unveiled...
Sun Jun 1, 2008 8:00pm EDT"
"
http://www.videsignline.com/products/212501012;jsessionid=BAZHTTSN1ARPSQSNDLPCKH0CJUNN2JVN
true its a large chip but its billed as "... are claimed to offer the industry's largest density, highest performance, highest system bandwidth, and lowest power among high-end FPGA solutions. "
you could even activate its gigaE ports and use it on your LAN and make an HD encoder multicast tunneled end to end mesh for multi PIP TS feeding out of them ;) got to think bigger and turnkey USB3 to make real long term money OC...
popper
10th January 2009, 10:32
I have yet to imagine any possible use of SSE4 for decoding, though maybe there might be something creative with pblend or pinsrd.
It will be used for some upcoming x264 optimizations, but those are only encoder-side.A lot. This by the way is the reason why CoreAVC has such a huge advantage on older CPUs--on newer ones, competing encoders making heavy use of SSE close the performance gap, but on older CPUs where SSE isn't available or isn't very fast, CoreAVC has a large advantage.
just go and ask Luca Barbato, markos (freevec) http://www.freevec.org/ and the other Altivec boys, they have been bit shifting 128-bit Altivec SIMD vector code for a long time, and will probably give you some idea's for all sorts of interesting things to try and match Altivec now that SSE4.1 has finally almost got there. after all these years ;)
Dark Shikari
10th January 2009, 15:09
just go and ask Luca Barbato, markos (freevec) http://www.freevec.org/ and the other Altivec boys, they have been bit shifting 128-bit Altivec SIMD vector code for a long time, and will probably give you some idea's for all sorts of interesting things to try and match Altivec now that SSE4.1 has finally almost got there. after all these years ;)Altivec has been behind SSE for years--it still doesn't have pmovmskb ;)
(Or for that matter, any way to emulate it at all)
Cyber-Mav
13th January 2009, 05:04
Athlon XPs don't even have SSE2.
true but they do have SSE1, would that be of any benefit? or is sse2 needed as a minimum for speed increase?
BetaBoy
13th January 2009, 05:12
All... just getting back from CES tonight. I want to thank the CES staff from NVIDIA for demo'ing CoreAVC Professional Edition w/CUDA support. We have received a lot of feedback and comments but it was nice to see someone at CES mention that the other CUDA enabled product demo's shown had to show a video of the CUDA statistics (before / after) in use, while CoreAVC was 'live' and you could seen the difference in realtime!
Now that the show is over and we have had some more feedback. We have a new punchlist of small changes and are going to schedule a release of v1.9 by the end of the month.
Dark Shikari
13th January 2009, 05:37
true but they do have SSE1, would that be of any benefit? or is sse2 needed as a minimum for speed increase?Only integer operations are useful for video decoding, so SSE1 isn't useful.
leeperry
13th January 2009, 15:20
Now that the show is over and we have had some more feedback. We have a new punchlist of small changes and are going to schedule a release of v1.9 by the end of the month.
any chance to see the 2 CUDA bugs I told you about fixed ?
the pulp fiction sample that's missing colors, and the seeking problem in KMPlayer that doesn't wait for keyframes and sends garbled video instead..
they still both occur even w/ the 185.20 beta drivers. :thanks:
BetaBoy
13th January 2009, 17:30
lee... sure.... but atm we are waiting to hear back from NVIDIA on a library distribution question and how to best handle it so we don't conflict with their efforts.
leeperry
13th January 2009, 20:12
awesome http://forum.slysoft.com/images/smilies/cool2.gif
and do you still have plans to release CoreWMV? I could personally use some fast WMV3/VC1 decoder.
in case you got some beta version ready, I'm willing to try it and give feedback too :D
madshi
14th January 2009, 10:17
and do you still have plans to release CoreWMV? I could personally use some fast WMV3/VC1 decoder.
Me, too. BTW, BetaBoy, you talked earlier about CoreAAC. All I can find is a rather old version for download. Will there be a new CoreAAC release, too? And will it be free or cost something? If you really do create CoreWMV and CoreAAC, maybe you want to consider a "CoreCodec" package for purchase which would combine all codecs you currently offer and will offer in the future?
tommy_vercetti
15th January 2009, 02:38
Me, too. BTW, BetaBoy, you talked earlier about CoreAAC. All I can find is a rather old version for download. Will there be a new CoreAAC release, too? And will it be free or cost something? If you really do create CoreWMV and CoreAAC, maybe you want to consider a "CoreCodec" package for purchase which would combine all codecs you currently offer and will offer in the future?
That would be great !
frank
16th January 2009, 14:28
laserfan wrote:
I've uninstalled Avisynth 2.5.8 and installed 2.5.7 and then reinstalled 2.5.8, rebooting the PC and checking DirectShowSource.dll every time, to no avail. Note .mkvs work but not .h264s. CoreAVC is the only problem I'm having w/this--can anyone imagine what might be wrong? Nothing wrong.
I never could stream .h264 from DirectShowSource. And MPC HC can't play it too. That's the reason why I encode to mkv.
I use XPpro, HaaliSplitter and ffdshow. No Sonic or other filters.
Daiz
16th January 2009, 21:42
I've just always used DSS2("source.mkv") when I want to input H.264 video using CoreAVC as the decoder.
BetaBoy
18th January 2009, 19:23
A small heads up.... work is almost done on the 64 bit version of Haali's splitter so we are talking about releasing CoreAVC Pro 64 either in 1.9 or with 2.0. Also this will mean we will be releasing CoreAVC Pro 64 with CUDA support as well since CUDA supports 64bits. Although the QA is gonna be tight with that, we'll see... but an FYI for all none-the-less.
On CoreWMV.... technically supports VC-1 as well as all WMV based video (we wrote it from scratch). But we stopped working on it more to work on CUDA w/CoreAVC. I'll spring it on the guys here to see if we can pickup on it.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.