DGAVCDec 1.0.9

[Ranguvar]

This I am definitely looking forward to. However, is there a way you can gauge GPU usage? I use FFT3DGPU a lot, and while I'm pretty sure the GPU should do both, I'd like to have an estimate on how much H.264 decoding taxes the GPU :) Though I bet the load off the CPU when encoding will make up for it.

Thanks for all your work :)

[Guest]

My use will be on the VP2 core, which is different from the rest of the GPU. We'll have to wait and see.

[lucassp]

What video card do you own?

I can also test on 8800GT and Vista x64.

[opieant]

Found another minor file name bug. When saving a project, the default output file name is the substring of the file name before the first period character. The name should probably be the substring before the last period so that things like "Dr." and "Mr." are allowed to be part of the file name.

[Ranguvar]

I have XP Pro x64 and a GeForce 9600GT 512MiB if you need testers :)

[bob0r]

I think so.

Waiting for the naysayers to chime in...

Just keep your GPU burning for 24 hours.... then lets see what you think :)
Many have fried.... We need the best of both worlds!

[lucassp]

Just keep your GPU burning for 24 hours.... then lets see what you think :)
Many have fried.... We need the best of both worlds!

The GPU will be as hot as playing a movie with PowerDVD with DXVA on.

[crypto]

What video card do you own?

GeForce 8600 GTS
Bios Information: Version 60.84.50.0.8
Video RAM 256 MB
Shared RAM 766 MB
Total 1022 MB

Diver Version 7.15.11.7783

I have run a CUDA bandwidth check:

Host to Device 2472 MB/s
Devive to Host 2471 MB/s
Device to Device 9727 MB/s

[Renzz]

Just for fun, I benchmarked Nvidia 8500GT versus CoreAVC on E8500 @ 3.8GHz using a 1080P25 AVC video. I forced the frame rate to 120fps using an Avisynth script.

Nvidia GPU: 66 fps (CPU 4%)
CoreAVC: 60 fps (CPU 60%)

Which would you prefer?

How about both? What about using GPU and CPU - 126 fps??:)

[Guest]

Found another minor file name bug. When saving a project, the default output file name is the substring of the file name before the first period character. The name should probably be the substring before the last period so that things like "Dr." and "Mr." are allowed to be part of the file name. Yes, and for the name of the demuxed video too. I'll fix it. Thank you for pointing it out.

[Guest]

Hmm, I just looked at the code and it looked as if it DOES use the right most '.' as you want. I tested it and it works as it should. How do you make it fail?

[squid_80]

The GPU will be as hot as playing a movie with PowerDVD with DXVA on.
No; playing back a movie means frames are processed at the original framerate while DGAVCDecode processes frames as fast as the host application calls for them.

[lucassp]

No; playing back a movie means frames are processed at the original framerate while DGAVCDecode processes frames as fast as the host application calls for them.

Yes, true. But it uses only the VP2. No shaders/ROP involved in this.

[Guest]

And the VP2 is the slowest clock domain at 450MHz. Decoding as fast as I can is not going to overheat the GPU.

Currently the VP2 is clocked the same on all the GPUs, so the low end 8500GT will decode as well as the 280! Nvidia tells me the VP2 clock rate will be increased in forthcoming GPUs.

Progress report: I have just finished abstracting out the libavcodec support into a general decoder interface in DGAVCIndex. I will now implement the CUDA decoder to this interface. To support any new decoder, you just supply a file that implements these functions. This is what the interface looks like:

extern int decoder_open(void);
extern void decoder_close(void);
extern int decoder_reset(void);
extern int decoder_decode_nalu(int *frameFinished, unsigned char *buf, int len);
extern void decoder_copy_frame(unsigned char *y, unsigned char *u, unsigned char *v);
extern unsigned int decoder_get_width(void);
extern unsigned int decoder_get_height(void);
extern int decoder_get_poc();
Later, these will be function pointers to allow for changing the decoder without recompiling.

[CruNcher]

Great Donald also that you have access to the Deinterlacer and IVTC now we can also compare them in real with the other (software) ones available :)
if you still need someone to test it out im here (8800GT G92 512mb) :)
Can you get access to them without being dependent on the video input @ all (Mpeg-2,VC-1,H.264), so something like nvidiadeint() nvidiaivtc() is possible ?

[opieant]

Hmm, I just looked at the code and it looked as if it DOES use the right most '.' as you want. I tested it and it works as it should. How do you make it fail?

Whoops. It happens when there is a period in the name of a file with no extension, as it should be doing when cutting off at the last period.

Looks like Windows considers a file name with periods to have no extension if any spaces follow the final period. Of course, I could just put extensions back on my files to work around this, but what fun would that be? :)

[CiNcH]

Currently the VP2 is clocked the same on all the GPUs, so the low end 8500GT will decode as well as the 280! Nvidia tells me the VP2 clock rate will be increased in forthcoming GPUs.

Think later GPU's should be clocked higher as they officially support two H.264 streams to be decoded in parallel!? Or do you think that older GPU's are just restricted in an artificial way?

[Guest]

If they are in parallel, why would the clock rate have to be higher? Nvidia told me they all use the same clock rate. But I just found out that the 8500GT has a smaller memory bus size and later chips have a bigger one, so I can gain about 4 fps by upgrading. I've asked them which chip is the lowest end one that has the bigger bus.

BTW, GPU decoding is basically working now in DGAVCDec. I used a non-optimized approach first to expose possible issues. It revealed that once you open the GPU decoder in a thread, that thread must stay alive. But DGAVCDec was architected to kill the decode thread after a play/preview ends and then recreate it for the next play/preview. So I had to change the decode thread to a server thread that stays alive and waits for a wakeup from the GUI. It also revealed the correct way to reset the decoder for seeking is NOT what they first told me. We had to destroy and recreate the video parser. That's OK because it's effectively just a delete and new, so it's fast.

Next I plan to optimize the solution, fix some GUI issues, and roll out something you can play with.

[noee]

neuron2,
I use both DGIndex and DGAVCIndex with regularity, this is very exciting news. However, I'm strictly an ATI guy right now.

Sorry if I missed it before, but do you envision this capability on the ATI GPUs with DGAVCIndex in the future?

[Guest]

I haven't ruled it out, but to be honest, I generally spend my time only on things that I need myself. Now, if you showed that ATI GPU decoders perform better than Nvidia ones, then I would need it. :)

[ToS_Maverick]

slightly OT but, would it be possible to implement your decoding routine in ffdshow? don't know the difference of your decoding approach compared to the one in MPC-HC, which also has GPU-decoding support.

maybe someone other will then implement a decoder for ATI cards, that you could use ;)

[G_M_C]

I haven't ruled it out, but to be honest, I generally spend my time only on things that I need myself. Now, if you showed that ATI GPU decoders perform better than Nvidia ones, then I would need it. :)

Well, aside from the fact that the new HD48xx-GPU support PIP (dual stream decoding), 7.1 High definition audio, resolutions up to QHD, are faster and are considered "more bang for the buck", there is nothing better about them than NVidia's ;)

Actually, i dont really care about GPU-support. The whole thing gives me deja-vu's of the beginning of the MPEG2 / DVD-age. We all wanted GPU support then, and there were special add-in board to help assist decoding and such. See where we ended up; Our modern CPU's handle MPEG2 without so much as warming up, even in HD-resolutions. I think eventually it will be the same with H264.

So all-in-all i care more about software-decoding, and hope that I will have the same functionality when i DONT have an NVidia.

[lexor]

Well actually neuron might not have to do anything, as there are efforts on the way to get CUDA to run on ATI GPUs. ATI is still giving them the silent treatment, but Nvidia now openly supports them (including actual engineers' advice). While there isn't anything in terms of publicly available software/drivers, I wouldn't jump ATI ship just yet, if you invested in an expensive card already.

[Guest]

Well, aside from the fact that the new HD48xx-GPU support PIP (dual stream decoding), 7.1 High definition audio, resolutions up to QHD, are faster and are considered "more bang for the buck", there is nothing better about them than NVidia's ;) I'm concerned only with video decoding. Is there any evidence that it performs better?

Actually, i dont really care about GPU-support. The whole thing gives me deja-vu's of the beginning of the MPEG2 / DVD-age. We all wanted GPU support then, and there were special add-in board to help assist decoding and such. See where we ended up; Our modern CPU's handle MPEG2 without so much as warming up, even in HD-resolutions. I think eventually it will be the same with H264. You haven't been listening! I'll say it one more time and then just ignore further similar posts:

1. Any offloading to the GPU makes more CPU cycles available to an encoder. A video card is not like an additional MPEG2 decoder card. Every system already has a graphics card.

2. I currently do not have a decoder that handles PAFF correctly, and I'm not prepared to wait an eternity for it in libavcodec. The GPU decoder decodes correctly, and does not crash on bad streams as libavcodec does.

3. I get VC1 for nothing.

So all-in-all i care more about software-decoding, and hope that I will have the same functionality when i DONT have an NVidia. Go bug the libavcodec author to fix it, then go bug CoreAVC to release the API/SDK. Good luck!

[G_M_C]

OK OK, calm down ...

I do not have a NVidia, and actually plan to buy me a HD4850; But maybe in the future you be able to implemant GPU-offloading on Ati's too.

[Turtleggjp]

I haven't ruled it out, but to be honest, I generally spend my time only on things that I need myself. Now, if you showed that ATI GPU decoders perform better than Nvidia ones, then I would need it. :)

I tried playing back my video camera's footage with a GeForce 8500GT a while back (May 2008 I think) and the result was pretty good, but somewhat jerky (not wrong field order jerky, just not 100% smooth). I then upgraded to a Radeon 3450 and that works perfectly. This was only for my camera's footage though (PAFF :devil:), I don't think I ever tried it with either Blu Ray AVC video or x264 created video. I still have the 8500GT in its box, so I could try it again. Since you say you have this card, were you able to play my clips ok with it? I had posted one a couple months ago when I asked you to fix a bug that was causing it to detect the stream as 188 byte packets instead of 192 byte. I can provide another sample if you'd like.

Matt

[Guest]

I tried playing back my video camera's footage with a GeForce 8500GT a while back (May 2008 I think) and the result was pretty good, but somewhat jerky (not wrong field order jerky, just not 100% smooth). That points more to the player application's implementation than the underlying decoder. It could be a decoder issue if its sustained decoding rate is less than the display rate of the video, but I have not found this to be the case for any of my test streams.

Since you say you have this card, were you able to play my clips ok with it? I had posted one a couple months ago when I asked you to fix a bug that was causing it to detect the stream as 188 byte packets instead of 192 byte. I can provide another sample if you'd like. Yes, all PAFF streams are decoded correctly.

DGAVCDec is not a player application. If it can decode the stream correctly at a good rate, that is all that is required.

[Turtleggjp]

DGAVCDec is not a player application. If it can decode the stream correctly at a good rate, that is all that is required.

I understand. I was merely trying to provide an example that I have witnessed where a Radeon outperformed an GeForce in H.264 decoding.

If DGAVCDec starts supporting Nvidia decoding, I will probably put that 8500GT into my main system at home and see how well it works. That will be awesome if I can finally use it on my video camera footage, if only there at home. I need to see if I can add a card to my laptop now...

[edit] Darn! Looks like Nvidia doesn't have Windows 2000 drivers for the GeForce 8 series of cards. :mad: I guess I'll have to finally update my main system to XP, unless of course there's any chance this will also work on a 7600GT.

[Deinorius]

CUDA ist just for Geforce8 and newer (and I hope for ATI cards too - there was a guy, who told he could bring CUDA to work on a ATI). But there was a problem with the first Geforce8 cards and their UVD, nowadays it shouldn't exist in new cards.

[Ranguvar]

=Darn! Looks like Nvidia doesn't have Windows 2000 drivers for the GeForce 8 series of cards. :mad: I guess I'll have to finally update my main system to XP, unless of course there's any chance this will also work on a 7600GT.

The XP 32-bit drivers should have a good chance at working, if you're feeling adventurous. Or you might have to use an old XP driver version.

[SpAwN_gUy]

GPU's.... cool :) ...
need any testers? ... 'cause i've recently(this night) got my new sony hdr-sr12.. so i'll get more footage to decode/encode...

my primary encoding/work PC is vista x64 + 8600GT... E8400/4Gb....
and at home i have e6400(i plan to upgrade that) + ATi x3870 ....
and i will get some Intel GPU at the new Notebook...

and.. ofcourse.. i have bunch of agents on x264farm :)))

[Guest]

I am now running my alpha DGAVCIndexGPU here successfully. There are some issues I want to resolve before releasing it for testing, but things are going well. The support from Nvidia is unbelievably competent and responsive! It's the best support I've ever had from any company, including my own employer.

[Yoshiyuki Blade]

This is certainly great news! I have and ol' 8800 GTX ready for some testing. What exactly does the GPU version speed up? Does it require CUDA-enabled drivers?

EDIT: I think I got the gist of it a few pages back. It seems there has been a lot of discussion on this topic last I checked. What will DGAVCIndexGPU utilize in the video card? Just CUDA? Because I recall that after the first generation of 8 series cards (8800GTX and GTS 640/320) Nvidia added something else related to video decoding (I think Purevideo HD) to the lower-end 8400-8600 cards, which don't work with the 8800 cards.

[Guest]

It uses the VP2 decoding engine. I can also expose the deinterlacer and 3:2 pulldown processing, but I haven't tested that yet. Those are referred to as PureVideo. There are several generations of it, PureVideo 1, 2, and 3. The 8800GT has PureVideo 2, same as my 8500GT.

The PureVideo HD label just means that HDCP is supported. Your card should be PureVideo HD.

I think you may be referring to PureVideo 3, which was added later and increases the acceleration for VC-1.

[hajj_3]

neuron, in next alpha please could you add an option like in dgmpgdec's .ini so that we can choose to bring window to foreground and beep once creating the .dga is complete as currently that doesnt happen.

keep up the great work!:)

[lexor]

Just a suggestion for when you do release the new decoder. It might be a good idea to include a list of cards and their capabilities as they pertain to this new decoder. For instance you said that all cards have the same clock, but not same memory bandwidth. So a short list of recommended cards and the cheapest option that has everything needed would be a good idea for those who don't really know much about their GPUs, aside from the fact that they run games.

[Guest]

Don't you know I always write thorough documentation? :)

Thank you for your suggestion.

[Yoshiyuki Blade]

It uses the VP2 decoding engine. I can also expose the deinterlacer and 3:2 pulldown processing, but I haven't tested that yet. Those are referred to as PureVideo. There are several generations of it, PureVideo 1, 2, and 3. The 8800GT has PureVideo 2, same as my 8500GT.

The PureVideo HD label just means that HDCP is supported. Your card should be PureVideo HD.

I think you may be referring to PureVideo 3, which was added later and increases the acceleration for VC-1.

Nvidia just had to make things confusing didn't they? :D

The FAQ I mentioned was answered here: http://www.nvidia.com/object/purevideo_hd_faq.html#1Q4 but I had no idea there were more than 2 versions of PureVideo (just thought there was the vanilla and HD). But after reading the FAQ again, it does imply that there was an earlier version of PureVideo HD.

[kemuri-_9]

lol @ that FAQ.
I have a Phenom 9850 with a 8600GT, guess they don't take account for the people that have 'power processors' but not powerful video cards:
I don't game on here so don't need a powerful video card

I've tried using DXVA in MPC-HC, but it's resulted in studdering video when turned on.
From what i've read from previous posts in here, it seems that DXVA on XP is lacking? (using 177.83 drivers)
is that actually true?

[rack04]

lol @ that FAQ.
I have a Phenom 9850 with a 8600GT, guess they don't take account for the people that have 'power processors' but not powerful video cards:
I don't game on here so don't need a powerful video card

I've tried using DXVA in MPC-HC, but it's resulted in studdering video when turned on.
From what i've read from previous posts in here, it seems that DXVA on XP is lacking? (using 177.83 drivers)
is that actually true?

Topic is probably better in the MPC-HC thread but I have no problems with DXVA on my 8800GT using XP.

[Yoshiyuki Blade]

Hmm... FAQ above the one I mentioned in my last post has me a bit concerned:

Q. What is new in GeForce 8400, GeForce 8500 and GeForce 8600 GPU video processors?
These GPUs feature a new video engine that includes a bitstream processor (BSP) and an improved programmable video processor (VP).

Are they referring to VP2? If so, the early generation 8 series cards won't be capable of this technology. :eek:

[nm]

Are they referring to VP2? If so, the early generation 8 series cards won't be capable of this technology. :eek:
Yes. See this table for GeForce 8 cards that have/don't have VP2: http://en.wikipedia.org/wiki/Comparison_of_Nvidia_Graphics_Processing_Units#Features_3

[Guest]

I think the decode will still work on VP1, though not as efficiently.

[squid_80]

Doesn't the CUDA video decoder need compute capability 1.1?

[canTsTop]

4. Can be done something for preventing audio/video synchronization lost and DGAVCDecode crash for TS recordings with errors? Here is sample http://www.mediafire.com/?7wohntw2ijw
When i play it with MPC+ffdshow it shows corrupted frames (i don't mind it) but wont crash and audio/video synchronization is back after errors.

The crashing I can mitigate with a try/except block. I'll put that on the to-do list. The sync issues are more difficult. The reason MPC can do it is because MPC still has the timestamps in the stream. But when you demux you lose them. It's better I think to preprocess the stream with a tool such as ProjectX. I may write one.

Crazy idea. Is it possible to add future then saving project to decode audio to wav with correct time stamps so it matches video?

[Guest]

Sorry, but I can't follow your point, as your English appears malformed.

[canTsTop]

Sorry for bad English... I meant: is it possible to decode audio using timestamps in TS file so audio and video be in sync. Like MPC synchronize audio after errors, to decode this synchronized version of audio. Probably its crazy idea...

[Guest]

I'm not thrilled about the idea of doing audio decoding in DGAVCIndex. I have on my to-do list insertion/deletion of audio to demux a zero-delay stream, but it's not high on my priority list. And it would be for the start of the stream only. I think error correction for corrupted streams belongs in a separate application.

[Schmendrick]

@canTsTop: What ProjectX does with Mpeg2Ts-streams is that it fills up missing or faulty video and audio frames, shifts the audio relative to the video to keep synchronity when both streams are demuxed, thus loose their time stamps and then are remuxed again. If at random frames in the original streams are missing or faulty then the desynchonization becomes unrepairable. If you keep the time stamps a proper decoder can resynchronize video and audio.

As long as you have faulty clips the streams should always be retained at least within their Programme Elementary Stream container.

Another problem is that the video frames in e.g. satellite H.264-streams are not transmitted in the order as the clip has been made, but rather in the order how the stream has been encoded. According to the time stamps I have found e.g. the following frame order within such a video stream: 7, 8, 3, 4, 1, 2, 5, 6, 15, 16, 11, 12, 9, 10, 13, 14, 23, 24, 19, 20, 17, 18, 21, 22,..... The audio stream is usually laging behind the video by up to one second.
To be able to properly synchronously cut such streams even if they are error free you would have to reorder the frames and shift the audio packets relatively to the video packets to be able to do a cut properly. The begining in front of an I-frame and the end after an I-frame or a P-frame.

Schmendrick

[LOGiC]

@all,

are there any known problems with the Indexing of bigger AVC/H264 files ? I tried to index a 1080p 8GB file, but when trying to load the indexed file into meGUI, it just gave me a green screen and no picture, but it works fine with i.e. 4,5GB 720 files. Any ideas ?

Thanks in advance.