01-02-2009, 11:16 PM
sure, in the Uk DVB-T is still using Mpeg2 in their SD TS (transport streams, but....
Originally Posted by Uber
4: Did you forget that Sky use HD AVC (Mpeg4 part10/aka Mpeg4-AVC)
5: Did you forget that todays HD cams use primarily AVCHD inside a TS.
6: Did you forget that BBC HD use MBAFF and PAFF decoder options on their HD AVC TS streams and ATI hardware can decode that fine, were FFMPEG software cant (very well or fast).
7:linux HD Editing software such as http://www.kdenlive.org/ are activly tying to support the new AVCHD, lossless AVC Intra
in their transcoding.
8: Did you forget that AVC intra, is now supported by the cross platform x264 software encoder, and that the CoreAVC decoder codec supported that decoding, linux software decoding of Intra is very limited and in desperate need of ATI to openly support it better than NV are doing now....
9:did you forget about the recent "http://www.dvb.org/news_events/dvbsc...VB-SCENE27.pdf
page 4 of 16
"DVB-S2 Enables 140 Mbps Super Hi-Vision By Satellite At IBC 2008
Dr Alberto Morello,
Director of RAI Research and Technology Innovation Centre, Turin, Italy & Chairman of DVB TM-S2 Group
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,"
perhaps you might like to have a read of these Mpeg4-part10 aka AVC papers to get to to speed of were the current spec is today and in the near future the world DVB AVC inside TS is going.
01-02-2009, 11:32 PM
01-02-2009, 11:50 PM
The GPU-dependent code for motion comp isn't really much different from the Xv code we have already pushed into radeon and radeonhd. The actual processing is different (you're dealing at a block level rather than a frame level) but that is largely hardware-independent.
I just think that developer time would be better spent working on an implementation which could also support H.264 and VC-1 rather than putting time into something that only handles MPEG2 and needs a rewrite to support anything else.
Last edited by bridgman; 01-03-2009 at 12:13 AM.
01-03-2009, 12:56 AM
indeed, the old antiquates Mpeg2 doesnt concern me, what does concern me OC is the fact NV have make a simplistic libray that the windows part time coders and GUI video app writers are taking advantage of.
Originally Posted by bridgman
wereas the ATI/AMD librays while lower level and apparently fuller are not being used , infact are being ignored on the likes of doom9 were all the windows freeware AVC,vc1,transcoding etc apps happen...
they just dont want to try and use the raw framewave library
all they need to begin with to finally start using the AMD/ATI open librays is a basic libary that suits their basic needs.
that need is simply AVC Encoding,MBAFF and PAFF ,AVCHD decoder options and perhaps AVC intra lossless processing,and vc1.
it doesnt even need to be fancy,for ATI to catch up all that would be required would be for ATI/AMD to write the hardware assisted decoding and DIFF against the current FFMPEG/libavcodec codebase and people can finally have good reason to buy and use the X1xxx/HD3650/HD4xxx
put simply until someone preferably ATI give linux the only real option for Hardware decoding AVC,MBAFF and PAFF ,inside FFMPEG at the very least port and post the diff at
http://lists.mplayerhq.hu/pipermail/...ry/thread.html we as ATI advocates are going nowere.
01-03-2009, 01:00 AM
Mpeg2 isnt the problem OC , ,MBAFF and PAFF ,AVC decoding in linux is, porting any ATI code to libavcodec
Originally Posted by bridgman
is the only real option go kickstart the uptake today...
id advisable that someone writes some basic working HW ATO decoding code and posts the diff at http://lists.mplayerhq.hu/pipermail/...ry/thread.html
01-03-2009, 01:09 AM
sure ,but AVC MBAFF and PAFF decoder options coded to the libavcodec/FFMPEG codebase is the only real option to linux users today.
and as you know , thats not great in software right now, only the current NV library everyone in doom9's useing and writing for right now, or perhaps something the ATI/AMD team might write ASAP and diff against the current libavcodec/FFMPEG codebase and post on the http://lists.mplayerhq.hu/pipermail/...ry/thread.html
for all to see and talk about (theres major good PR in doing that simple thing OC) that might finally get the http://forum.doom9.org/forumdisplay.php?f=77 sections porting the free HD AVC video apps back to linux again....
and any improvement in libavcodec/FFMPEG HW assisted ati code might even be a very good thing for the likes of
http://www.kdenlive.org/kdenlive-nvi...u-ffmpeg-patch, the only linux video editor thats trying to promote lossless AVCHD cam file editing today it seems.
its apparent the doom9 video app coders and GUI creaters like the NV libray as it caters to their simple needs at a high level, one of the doom9 devs said the http://sourceforge.net/forum/forum.php?forum_id=764939 framewave libray
is to low level,and to much work for part time HD app coders that dont currently own ATI HD cards,and see no reason to buy them right now as the NV libray works for them, whatever that means!
Last edited by popper; 01-03-2009 at 01:42 AM.
01-03-2009, 01:41 AM
sure, but WE'RE NOT THE ONLY ONES WHO CAN WRITE OPEN SOURCE DRIVERS
(y'know, that smiley should be called "rant", not "eek" )
Our commitment is to get enough technical information and sample code into the development community to enable the development of well featured, decently performing, and reliable drivers, and to provide support to developers to help fill any gaps. We also figure out how the new chips work and either write sample code for the community or just add the new GPU support ourselves.
For years the development community said "give us the specs, we'll write the drivers". We are providing the specs, and in fairness the development community is working on drivers. We also help write the drivers when time permits; Alex added both EXA Render and Xv support to the current driver stack. We also partnered with Novell to get the initial driver support for 5xx/6xx written, as well as the sample 3D code for 6xx/7xx. But please don't wait for us -- the code is there and the information is there -- anyone can add to or enhance the drivers.
Last edited by bridgman; 01-03-2009 at 01:51 AM.
01-03-2009, 01:54 AM
sure, but seeding your better ATI codebase for AVC MBAFF and PAFF decoder options coded to the libavcodec/FFMPEG codebase can only be a very good thing for all concerned.
its all about prioritys OC, and these Open source coders are advocating NV right now, and thats a very bad thing as all the popular apps dont currently use any ATI HW assistance, and is stopping people buying the far better ATI HW decoding GFX for mass market home HD video work.
thats a crying shame and id like to see that change as i have several X1/HD GFX cards that could take off but for some working sample libavcodec/FFMPEG code to match or better NVs current libavcodec/FFMPEG diff....
01-03-2009, 02:00 AM
OK, I'm confused. Are you talking about open source or proprietary NVidia drivers here ?
I looked all through the links and didn't see any reference to the "NV library" you mentioned.
You linked to both Framewave (which is a CPU math lib) and Stream (which is a GPU programming environment); which were you talking about ?
The other thing I don't understand is how we got onto AVC/H.264 and VC-1 in the first place. The only discussion in the thread was about whether it was worth implementing XvMC, which is currently MPEG2-only, and whether MPEG2 decoding placed enough load on the system to justify implementing XvMC.
I think we all agree that support is meeded for the more demanding formats, particularly H.264. The question *there* is whether that is a higher priority than 3D support, which is what we are working on now. I would argue that 3D support should remain the top priority, and after that we should look at H.264 support if someone has not already done it.
I'm still not clear whether you were talking about the open or proprietary NVidia drivers, though, or what that "NV library" referred to. If you're talking about transcoding apps accelerated through CUDA or Stream, that's all going to end up running over OpenCL soon on all platforms, ie ffmpeg would code to the OpenCL standard not to anything vendor-specific.
Last edited by bridgman; 01-03-2009 at 02:20 AM.
01-03-2009, 02:23 AM
i know its rather confusing LOL, i dont mean to make you rant, but in HD AVC,VC1,etc video work its clear both CPU and GPU library improvements are a good thing to advocate (PPC linux doesnt use the altivec SIMD for anything for instance, such a waste, PS3 PPC linux could make very good use of SIMD for instance).
my real concern right now is that NV have got the HW assist mindshare in the home video coder market right now, and ATi are nowere to be seen in that space,but perhaps you dont see it!
the simple option and masses of good PR is for some devs to take what your current offering in both better CPU and especialy GPU assisted Encoding/Decoding and trancoding and work with the libavcodec/FFMPEG codebase .
that gives every single app that currently uses libavcodec/FFMPEG codebase a boost, gets ATI some needed PR outside the specialist news outlets and gives the home devs some good working base code to take, learn and expand for eveyone long term good,.
its pritty simple, if you are using linux your using some libavcodec/FFMPEG codebase in at least one of your main apps, as are many other OS's including windows OC....
id prefer if that dev team were your ATI team as leads, as its in your long term interests to do so, and so far no other devs seem that interested right now even though the end user demand would love the ATI HW assited video procesing to help them process their AVC HD video better than real time preferably....
Last edited by popper; 01-03-2009 at 02:26 AM.