DiAVC decoder, yet another fast H.264 high profile decoder

[schweinsz]

I am happy to anounce that the DiAVC, another high profile decoder is released.

http://www.di-avc.com/

The supported features:
I Slice, P Slice, B Slice
weighted_pred_flag = 0, 1
MBAFF and PAFF
Custom Quantization Matrix
CAVLC and CABAC
Deblocking Filter
Multi-reference frames
Direct_8x8_inference_flag = 1 or 0
IPCM
Constrained_intra_pred_flag = 1 or 0
transform 8x8 and 4x4
weighted_bipred_idc = 0,1,2
Multi-Core supporting

Limitations:
Need CPU with SSE2


The DiAVC alpha version includes DiAVC.ax and a tool named DiAVC Setting.exe to set the default H.264 decoder.

[gswudi]

Where can i get it?

[_xxl]

Multi-Core supporting
Are you using a frame level parallelism?
Open source?

[Guest]

The attachment contained a virus (win32/nsanti) and so was deleted. I give the benefit of the doubt this time. If it occurs again, you'll be banned, schweinsz.

[schweinsz]

The attachment contained a virus (win32/nsanti) and so was deleted. I give the benefit of the doubt this time. If it occurs again, you'll be banned, schweinsz.
What is your anti-virus software? I use the McAfee and it never report virus. I have used some the self-modified code, junk code and code metmorphic to protect the software.

For example,

#define pushSrcDstAssign {__asm push dst __asm push src __asm push ptkn}
#define emitJunkByte4(a, b, c, d) { __asm _emit a __asm _emit b \
__asm _emit c __asm _emit d}

void assign_u32_adjst(PVOID dst, PVOID src)
{
u32 token = 1, *ptkn = &token;

if((unsigned int)dst > 0x100) goto pushdsttEd;
emitJunkByte4(0x80, 0xe8, 0xcc, 0xd4)

pushdsttEd:
pushSrcDstAssign

if((unsigned int)src < 0x80000000)
goto popdsttEd;
emitJunkByte4(0x78, 0x28, 0x34, 0x6e)

popdsttEd:
__asm int 2dh
__asm add esp, 12
}

[schweinsz]

Are you using a frame level parallelism?
Open source?
Yes, I will use the fame level parallelism, but it will be finished after 1.5 week.

[schweinsz]

What is your anti-virus software? I use the McAfee and it never report virus. I have used some the self-modified code, junk code and code metmorphic to protect the software.

For example,

#define pushSrcDstAssign {__asm push dst __asm push src __asm push ptkn}
#define emitJunkByte4(a, b, c, d) { __asm _emit a __asm _emit b \
__asm _emit c __asm _emit d}

void assign_u32_adjst(PVOID dst, PVOID src)
{
u32 token = 1, *ptkn = &token;

if((unsigned int)dst > 0x100) goto pushdsttEd;
emitJunkByte4(0x80, 0xe8, 0xcc, 0xd4)

pushdsttEd:
pushSrcDstAssign

if((unsigned int)src < 0x80000000)
goto popdsttEd;
emitJunkByte4(0x78, 0x28, 0x34, 0x6e)

popdsttEd:
__asm int 2dh
__asm add esp, 12
}

Besides, the self-generated code is generated on the stack and then it is executed.

[Dark Shikari]

Besides, the self-generated code is generated on the stack and then it is executed.Code with an executable stack is inherently dangerous.

Self-modifying code doesn't actually protect the program, since it is trivial (read: takes me less than 5 minutes) to dump a program's memory. But its certainly a great excuse for enabling options that allow one to more easily hide viruses in a program.The throughput is about 19mbps with 50% CPU fullness (single thread on a dual-core CPU). Because the DiAVC's development is in early stage, there are many space to be optimized to get a faster decoder, such as the un-optimized MC, transform8x8 and CABAC decoding.A decoder isn't fast because you say it's fast. It's fast because it is fast. What you described is not fast, it is in fact quite slow. Now, some day, it might be fast, but today it is not.

[schweinsz]

Code with an executable stack is inherently dangerous.

Self-modifying code doesn't actually protect the program, since it is trivial (read: takes me less than 5 minutes) to dump a program's memory. But its certainly a great excuse for enabling options that allow one to more easily hide viruses in a program.A decoder isn't fast because you say it's fast. It's fast because it is fast. What you described is not fast, it is in fact quite slow. Now, some day, it might be fast, but today it is not.

Probably I have a bad core duo cpu, I ever tested the DiAVC on my friend's laptop and found that the DiAVC is faster on a Pentium M 1.73GHz than it is on a core duo CPU of 1.86GHz now. You can try it on your CPU. besides, I use the coreavc to play a movie with H.264 bitstream of 4Mbps, and I found the CPU fullness is more than 70%.

[Dark Shikari]

You can try it on your CPU.How, by magically teleporting it from your computer to mine?

[schweinsz]

Are you using a frame level parallelism?
Open source?
I will open some critical algorithm I use in the DiAVC, but I will not open all source.

[schweinsz]

How, by magically teleporting it from your computer to mine?
I have created a web site for the DiAVC decoder.

[Casshern]

Do i understand you correctly: you say that DiAVC is 5 times faster than coreavc on a single processor machine - 19Mbit/s vs. 4 MBit/s?

That would be impressive.

But i remain sceptical and do not like the code-obfuscation. What are you trying to protect? Optimizations to well known-algorithms?
Are you really sure you did not use any open source? Without insinuating anything: Are you aware that the two major reasons for obfuscation are hiding viruses/trojans and/or hiding open-source origin? There are other and better ways to protect intellectual property.

To me it doesn't make sense and i will not beta test an obfuscated program.

regards,
Casshern

[Dark Shikari]

The only "SSE" I see in this program is unbelievably bad compiler-generated assembly...

1000290d: 66 0f 6f c8 movdqa xmm1,xmm0
10002911: 66 0f 74 c8 pcmpeqb xmm1,xmm010004c00: f3 0f 7e 02 movq xmm0,[edx]
10004c04: f3 0f 7e 08 movq xmm1,[eax]
10004c08: 66 0f e0 c1 pavgb xmm0,xmm1
10004c0c: 49 dec ecx
10004c0d: 66 0f d6 00 movq [eax],xmm0
10004c11: 03 d6 add edx,esi
10004c13: 03 c6 add eax,esi
10004c15: 85 c9 test ecx,ecx
10004c17: 75 e7 jne 0x10004c0010008e71: 66 0f 60 c0 punpcklbw xmm0,xmm0
10008e75: 66 0f 6f d0 movdqa xmm2,xmm0
10008e82: 66 0f 60 d0 punpcklbw xmm2,xmm0
10008e8a: 66 0f 70 c2 00 pshufd xmm0,xmm2,0x0

(Well, OK, so I saw an iDCT that didn't look too awful, but that's about it...)

[schweinsz]

Do i understand you correctly: you say that DiAVC is 5 times faster than coreavc on a single processor machine - 19Mbit/s vs. 4 MBit/s?

That would be impressive.

But i remain sceptical and do not like the code-obfuscation. What are you trying to protect? Optimizations to well known-algorithms?
Are you really sure you did not use any open source? Without insinuating anything: Are you aware that the two major reasons for obfuscation are hiding viruses/trojans and/or hiding open-source origin? There are other and better ways to protect intellectual property.

To me it doesn't make sense and i will not beta test an obfuscated program.

regards,
Casshern

No, I never mean that the DiAVC is 5 times faster than the coreavc. The 19Mbps is tested using the bitstream of resolution 1280x720 generated by JM13.0 using the CABAC and Hierarchical B frames. But the 4Mbps bistream is downloaded from the internet and It is 1920x1088 and I dont know the detail about it. The 70% CPU fullness includes the audio decoding, video decoding and rendering.

I never use any open source in the DiAVC. The code-obfuscation
is to hide the anti-debug "int 2dh". I never insert virus in the DiAVC because I want to sell it online in future.

Now I have deleted any anti-debug code in the DiAVC. You can try it.

[schweinsz]

The only "SSE" I see in this program is unbelievably bad compiler-generated assembly...

1000290d: 66 0f 6f c8 movdqa xmm1,xmm0
10002911: 66 0f 74 c8 pcmpeqb xmm1,xmm010004c00: f3 0f 7e 02 movq xmm0,[edx]
10004c04: f3 0f 7e 08 movq xmm1,[eax]
10004c08: 66 0f e0 c1 pavgb xmm0,xmm1
10004c0c: 49 dec ecx
10004c0d: 66 0f d6 00 movq [eax],xmm0
10004c11: 03 d6 add edx,esi
10004c13: 03 c6 add eax,esi
10004c15: 85 c9 test ecx,ecx
10004c17: 75 e7 jne 0x10004c0010008e71: 66 0f 60 c0 punpcklbw xmm0,xmm0
10008e75: 66 0f 6f d0 movdqa xmm2,xmm0
10008e82: 66 0f 60 d0 punpcklbw xmm2,xmm0
10008e8a: 66 0f 70 c2 00 pshufd xmm0,xmm2,0x0

(Well, OK, so I saw an iDCT that didn't look too awful, but that's about it...)

Yes, you are right. I code the motion compensation, IDCT and the deblocking filter using the intrinsic functions (http://msdn.microsoft.com/en-us/library/kcwz153a(VS.80).aspx) and compile it using the VC 2008. I have found it very bad and I will code it using the pure assembly code in future.

[schweinsz]

The only "SSE" I see in this program is unbelievably bad compiler-generated assembly...

(Well, OK, so I saw an iDCT that didn't look too awful, but that's about it...)

There are many places using SSE2 besides motion compensation, idct and deblocking filter. For example, the MV median prediction uses the SSE2.

[Dark Shikari]

I have found it very bad and I will code it using the pure assembly code in future.And thus another assembly programmer is enlightened ;)

[roozhou]

I believe VC's inline-assembly is as powerful GCC's.

[CruNcher]

I find it funny schweinsz that you know you can't protect your software but still try it and create many interoperability problems (i would understand it though if you would provide that system) with that in the way, why not just give up and accept how it is ?, at least for the current Hardware architecture :)
The energy you invested into that lines for the extra protection are totaly lost in the end anyways and you knew it from the beginning so what did you win where is the sense behind this ?

[LoRd_MuldeR]

"Protecting" your code only makes sense if you either...

(1) plan to sell your software commercially
(2) need to hide your algorithms from your antagonist (e.g. decryption software)
(3) want to hide malware in your software

In case (1) you could simply buy a license for one of the commercial executable protectors/obfuscators (e.g. ASProtect).
That still won't give a "safe" protection, of course. But I'm sure it will be at least as hard to crack as your own protection. And it saves you trouble/work.
Also since many (commercial) applications are protected with such tools, the chance that any A/V software will complain is very low.

Case (2) certainly doesn't apply to a H.264 decoder, so I have to speculate that we have a case (3) here...

[CruNcher]

These "Protection" Software they sell is bogus you can always disassemble the code, it's just money making same for all the other Commercial Protection Systems like Securom ,StarForce and others they just ad another layer of "imaginative Protection" we don't talk about the normal usage scenarios though here that justifies (in the eyes of the creators) these rootkit like systems, we talk about protection added so nobody can RE his code but that is impossible with the current computer hardware, so the competition of him will know how to do it he can't protect it it's not logic. And yes for a guy that does Assembly Coding and a thing like a H.264 Decoder it's strange, though CoreAVC and others do it too and they also know what they do (or don't sometimes i have the feeling it just makes them feel better todo anything than nothing even if it's absolute useless) but i would never pay for this wannabe protection or protect @ all as it makes absolutely no sense if someone wants to RE it he can as long as it's executed it can't be protected on current computer Hardware.

[Guest]

Let's stay on topic, please.

[schweinsz]

"Protecting" your code only makes sense if you either...

(1) plan to sell your software commercially
(2) need to hide your algorithms from your antagonist (e.g. decryption software)
(3) want to hide malware in your software

In case (1) you could simply buy a license for one of the commercial executable protectors/obfuscators (e.g. ASProtect).
That still won't give a "safe" protection, of course. But I'm sure it will be at least as hard to crack as your own protection. And it saves you trouble/work.
Also since many (commercial) applications are protected with such tools, the chance that any A/V software will complain is very low.

Case (2) certainly doesn't apply to a H.264 decoder, so I have to speculate that we have a case (3) here...

IMHO, commercial executable protectors/obfuscators what you recommend is bad. Themida is pretty good, but I have seen many themida-protected examples are cracked. The commercial protectors are researched deeply and a experieced cracker can crack it very easily. I am very familar with many kinds of anti-debug skills, so I do it myself and I can integrated it into the DiAVC closely. Then I protect some critical functions using the VMProtect.

I never hide some malwares in the DiAVC, I have engaged in the software for several months and I want to sell it online in future, I will never risk my business.

[LoRd_MuldeR]

I never hide some malwares in the DiAVC

As long as you keep your codes in private and protect/obfuscate your binaries we can't prove that statement (easily).
But that applies to most commercial software...

I have engaged in the software for several months and I want to sell it online in future, I will never risk my business.

So if your really plan to sell your software commercially, protection makes sense indeed.
But you should check your protected binaries at http://virustotal.com/ to avoid false positives and confusion.
Also I'd recommend to test your binaries with DEP enabled...

[CruNcher]

As long as you keep your codes in private and protect/obfuscate your binaries we can't prove that statement (easily).
But that applies to most commercial software...

So if your really plan to sell your software commercially, protection makes sense indeed.
But you should check your protected binaries at http://virustotal.com/ to avoid false positives and confusion.
Also I'd recommend to test your binaries with DEP enabled...

Imho it makes 0 sense and just highers his costs without any usefulness.
VMProtect is also another of these security layers that's imho useless, but yeah Virtualization the new Buzzword so i need it ;)
Btw there is more then DEP they're lot of 3rd Party behavioral analyzers some of them will also go into alert mode but he's gonna see that from his customers feedback soon enough, you just run after something which can't exist on current hardware and that as a knowledgeable person is highly non logic :)
Though how he writes shows what his main intention is "Business" so good luck vs your competition especially CoreCodec and DivX :) you should have joined ffmpeg and invest your potential energy into there then to waste it like this schweinsz (it's never to late ;) ), of course that's your personal decision, nevertheless i wish you good luck and im out.
Don't want to be responsible if Donald get's a heart attack, sometimes going of topic is unavoidable especially as in this case the thread starter is promoting something so i assumed he's also interested in general ideas and views about his future Software Product (from his Potential Con/Pro Customers) :)

[Atak_Snajpera]

if very efficient Divx h.264 decoder will be released for free I see no reason to pay for DiAVC or coreavc. You won't earn to much money.

[LoRd_MuldeR]

if very efficient Divx h.264 decoder will be released for free I see no reason to pay for DiAVC or coreavc. You won't earn to much money.

And don't forget that ffmpeg-MT and ffdshow-MT are on the way! So hopefully we won't need any commercial ClosedSource H.264 decoder at all ;)

On my system ffdshow-MT already achieves ~80% of the throughput of DivX's H.264 decoder:
http://forum.doom9.org/showpost.php?p=1211080&postcount=34

That's definitely fast enough for smooth real-time 1080p playback with pure software decoding. What do we want more? :D

[Atak_Snajpera]

On my system ffdshow-MT already achieves ~80% of the throughput of DivX's H.264 decoder:
http://forum.doom9.org/showpost.php?...0&postcount=34

That's definitely fast enough for smooth real-time 1080p playback with pure software decoding. What do we want more?
Good news! I always prefer ffdshow :) less decoders in system = less problems

[ChronoCross]

I think I'll pass on a decoder that seems to have no actual benefit other than to possibly hide malware. Besides CoreAVC already works quite well for me, is professionally written, support, has a website that actually contains more than an archive and doesn't send my virus scanning program into a panic attack.

Anyway good luck but your pretty much just wasting your time.

[Shinigami-Sama]

nod32 says its clean but I don't really feel like testing it anyways

[Ranguvar]

Interesting, but no thanks :) I have no need for a closed-source decoder, and I don't think I'm far off in thinking that the only reason many others on this forum do is because they want/need very high speed, which neuron2's GPU decoder offers. That said, I would suggest that you either open-source your filter (why closed-source if you don't plan to sell it? Or do you?), so any improvements you find can be shared among the community and all software is helped by it, or you make going closed-source viable - FAST decoding, even faster than the current fastest, which is neuron2's solution.

[LoRd_MuldeR]

That said, I would suggest that you either open-source your filter (why closed-source if you don't plan to sell it? Or do you?), so any improvements you find can be shared among the community and all software is helped by it, or you make going closed-source viable - FAST decoding, even faster than the current fastest, which is neuron2's solution.

He already made clear that he is planning to sell it. And it's still his decision what to do with his own work!

Sure he will have strong competitors, in the ClosedSource world and in the OpenSource world. But if he wants to take the challenge, why not?

[Ranguvar]

Alright, but still, all I was offering is advice :) He of course does not have to follow my recommendations, they may very well be bad. IMO the only way he can compete in the payware world is to leverage GPU decoding. There are many big-name decoders, with big backing, so he needs to differentiate himself. Offering the _real_ fastest decoding is one way, and I don't think it's possible to do that without leveraging the GPU in some way. CPU fallback, sure, but GPU decoding must be implemented. He could even use libavcodec-MT for the CPU decoding (seems fairly safe legally), since it's LGPL, and contribute if he needs more speed - surely that would be faster than writing a CPU decoder from scratch?

[Sagekilla]

@Ranguvar: Leveraging the GPU for helping decode is already done in a lot of free decoders though. So why should a consumer buy his product if they can get GPU based decoding for free? Yes, having GPU decoding would help improve the product, but the best way to differentiate from all the other decoders is to offer very fast software decoding and GPU based decoding.

[roozhou]

I am looking for a GPU based dshow decoder that is able to put decoded frames back to main memory. DGAVCDecNV has only avisynth interface and cannot work with other demuxers. MPC-HC/Cyberlink only works in DxVA.

[Casshern]

No, I never mean that the DiAVC is 5 times faster than the coreavc. The 19Mbps is tested using the bitstream of resolution 1280x720 generated by JM13.0 using the CABAC and Hierarchical B frames. But the 4Mbps bistream is downloaded from the internet and It is 1920x1088 and I dont know the detail about it. The 70% CPU fullness includes the audio decoding, video decoding and rendering.

I never use any open source in the DiAVC. The code-obfuscation
is to hide the anti-debug "int 2dh". I never insert virus in the DiAVC because I want to sell it online in future.

Now I have deleted any anti-debug code in the DiAVC. You can try it.

Judging from this and other posts, you are pretty open about your code. GOOD! I take some of my reservations back and might actually try it.

regards,

Casshern

[Doom9]

Why is it that even after a moderator asks everybody to get back to topic the next 14 posts are still off topic?

[Sagittaire]

Why is it that even after a moderator asks everybody to get back to topic the next 14 posts are still off topic?

Yes really curious wellcome ... lol
- Virus contamination suspicions
- Open Source hack suspicions with always the same stupid speech on open source (M$ is devil ... blablabla)

It's really secondary question but the decoder work correctly ... lol

[Dark Shikari]

Yes really curious wellcome ... lol
- Virus contamination suspicionsSurely it's reasonable for there to be suspicions of a virus when a nobody posts on the forum with his new tool--a tool which sets off antivirus scans and has an executable stack? It's been confirmed to be fine now, of course--as it was just overzealous attempts at stopping debuggers--but it was surely not an unreasonable worry to begin with.
- Open Source hack suspicions with always the same stupid speech on open sourceYou had a point until...(M$ is devil ... blablabla)Stop it with the strawmen. Nobody, even in the off-topic posts, mentioned "Microsoft," according to a quick grep. You're only getting the thread even further off-topic by bringing up such tangential topics.

[Guest]

Let's draw the line right here and confine further discussion to the technical evaluation of the decoder.

[schweinsz]

The Direct_8x8_inference_flag = 0 has been finished.
I will finish the weighted_bipred_idc in recent days.
After this, I will work about the multi-thread decoding and the DiAVC will work much faster than it is now.

[schweinsz]

weighted_bipred_idc = 0, 1, 2 is supported now. I will work on the improvement of the CABAC and multi-thread decoding.

[popper]

I am happy to anounce that the DiAVC, another high profile decoder is released.

http://sites.google.com/site/diavcdecoder/

The supported features:
I Slice, P Slice, B Slice
Custom Quantization Matrix
CAVLC and CABAC
Deblocking Filter
Multi-reference frames
Direct_8x8_inference_flag = 1 or 0
IPCM
Constrained_intra_pred_flag = 1 or 0
transform 8x8 and 4x4
weighted_bipred_idc = 0, 1, 2
Need CPU with SSE2
Windows XP, Windows Vista and Windows 2000 are supported

On coming features:
weighted_pred_flag
interlaced supporting
Multi-Core supporting

Because the DiAVC's development is in early stage, I only provide the dll and the testbed. I'll add the supports on Direct_8x8_inference_flag = 0, weighted_bipred_idc and Multi-Core supporting, and then the interlaced supporting.

I have tested my DiAVC on my laptop with a Core Duo CPU of 1.86GHz using the CABAC high profile bitstream. The throughput is about 19mbps with 50% CPU fullness (single thread on a dual-core CPU). Because the DiAVC's development is in early stage, there are many space to be optimized to get a faster decoder, such as the un-optimized MC, transform8x8 and CABAC decoding.

Besides, where is some directshow samples I can reference?
I want to code a directshow transform filter for my DiAVC.

its very odd that you state you want to release your app as commercial property today ,however you dont even see fit to put MBAFF and PAFF on the top of your must have list, that IS the most required option for many people around the world that have access to DVB-* MBAFF and PAFF encoded content (the UK, EU, HD cams, etc) right now and want to decode it (better than)realtime for processing.....

will you infact be including these essential MBAFF and PAFF decoder options in your base code/app.

http://en.wikipedia.org/wiki/H.264
"Flexible interlaced-scan video coding features, including:
Macroblock-adaptive frame-field (MBAFF) coding, using a macroblock pair structure for pictures coded as frames, allowing 16×16 macroblocks in field mode (compared with 16×8 half-macroblocks in MPEG-2).

Picture-adaptive frame-field coding (PAFF or PicAFF) allowing a freely-selected mixture of pictures coded as MBAFF frames with pictures coded as individual single fields (half frames) of interlaced video.
"

[Mr VacBob]

I'm not surprised you can make a fast and simple decoder by not supporting interlacing, but it gets harder afterwards.

(didn't you post complaining about "redundant operations" in libavcodec? what part of the decoder was that referring to?)

[schweinsz]

its very odd that you state you want to release your app as commercial property today ,however you dont even see fit to put MBAFF and PAFF on the top of your must have list, that IS the most required option for many people around the world that have access to DVB-* MBAFF and PAFF encoded content (the UK, EU, HD cams, etc) right now and want to decode it (better than)realtime for processing.....

will you infact be including these essential MBAFF and PAFF decoder options in your base code/app.

http://en.wikipedia.org/wiki/H.264
"Flexible interlaced-scan video coding features, including:
Macroblock-adaptive frame-field (MBAFF) coding, using a macroblock pair structure for pictures coded as frames, allowing 16×16 macroblocks in field mode (compared with 16×8 half-macroblocks in MPEG-2).

Picture-adaptive frame-field coding (PAFF or PicAFF) allowing a freely-selected mixture of pictures coded as MBAFF frames with pictures coded as individual single fields (half frames) of interlaced video.
"

I will start to work on the interlaced supporting (including the MBAFF and PAFF) after I finished the multi-thread decoding.

[schweinsz]

I'm not surprised you can make a fast and simple decoder by not supporting interlacing, but it gets harder afterwards.

(didn't you post complaining about "redundant operations" in libavcodec? what part of the decoder was that referring to?)

Adding interlacing will not influence the speed of frame decoding because you can use a totally different slice decoding.

Regarding to the "redundant operations" in liavcodec, for example, the zerosleft decoding can be merged with the dequantization instead of two loop, take another example, the algorithm of cabac decoding and context computation is very un-efficient.

[Dark Shikari]

Adding interlacing will not influence the speed of frame decoding because you can use a totally different slice decoding.

Regarding to the "redundant operations" in liavcodec, for example, the zerosleft decoding can be merged with the dequantization instead of two loopWhat are you talking about with the zerosleft decoding? It is merged with dequantization, and is not two loops (and I don't think this was done recently either).take another example, the algorithm of cabac decoding and context computation is very un-efficient.Would you like to point me to a specific case so I can fix it rather than complaining?

Any suggestion for improved context calculation performance will probably allow me to make x264's RDO faster as well.

Same with the actual CABAC decoding--are you suggesting that there is a better way to organize LUTs/similar that results in better faster arithmetic decoding than what LAVC already has?

[schweinsz]

What are you talking about with the zerosleft decoding? It is merged with dequantization, and is not two loops (and I don't think this was done recently either).Would you like to point me to a specific case so I can fix it rather than complaining?

Any suggestion for improved context calculation performance will probably allow me to make x264's RDO faster as well.

Same with the actual CABAC decoding--are you suggesting that there is a better way to organize LUTs/similar that results in better faster arithmetic decoding than what LAVC already has?

Yes, I have read the latest libavcodec in ffdshow tryouts, It has been merged.

Regarding to the context calculation, take the coded block flag decoding as a example,

const unsigned int iCabac4x4CnxtAdd[8] = {0x9, 0x18, 0x801, 0x810, 0x9, 0x100008, 0x801, 0x100800};

unsigned int contxt = contxt1+contxt2;
for(int i=0; i<16; i++)
{
int contextcurr = contxt&3;
contxt >>= 2;

if(cbp[i>>2])
{
cbf = cabac_dec_symbol(..., contextcurr);
if(cbf)
{
contxt += iCabac4x4CnxtAdd[i&7];
......
}
}
}
update the contxt1 and contxt2 using the contxt;

Yes, I have a faster arithmetic decoding and I have written part of it into the DiAVC.

[Dark Shikari]

Yes, I have read the latest libavcodec in ffdshow tryouts, It has been merged.

Regarding to the context calculation, take the coded block flag decoding as a example,

const unsigned int iCabac4x4CnxtAdd[8] = {0x9, 0x18, 0x801, 0x810, 0x9, 0x100008, 0x801, 0x100800};

unsigned int contxt = contxt1+contxt2;
for(int i=0; i<16; i++)
{
int contextcurr = contxt&3;
contxt >>= 2;

if(cbp[i>>2])
{
cbf = cabac_dec_symbol(..., contextcurr);
if(cbf)
{
contxt += iCabac4x4CnxtAdd[i&7];
......
}
}
}
update the contxt1 and contxt2 using the contxt;You know there is no way in hell that'll work with interlacing, right? ;)Yes, I have a faster arithmetic decoding and I have written part of it into the DiAVC.OK, I'll see what I can take from it then.

[schweinsz]

What are you talking about with the zerosleft decoding? It is merged with dequantization, and is not two loops (and I don't think this was done recently either).Would you like to point me to a specific case so I can fix it rather than complaining?

Any suggestion for improved context calculation performance will probably allow me to make x264's RDO faster as well.

Same with the actual CABAC decoding--are you suggesting that there is a better way to organize LUTs/similar that results in better faster arithmetic decoding than what LAVC already has?

After I finished the DiAVC, I will improve the x264 and it is opensource. I can improve the computational efficiency of the ME&CABAC at least.

[schweinsz]

You know there is no way in hell that'll work with interlacing, right? ;)OK, I'll see what I can take from it then.

Why do you say that the cbf decoding dont work with interlacing? I think the cbf decoding can work with the interlace. It is possible to take a small change to fit into the mbaff. I am not familar with the mbaff.

[Dark Shikari]

After I finished the DiAVC, I will improve the x264 and it is opensource. I can improve the computational efficiency of the ME&CABAC at least.Come to #x264dev on Freenode. We welcome optimizations--even just ideas for optimizations that you don't want/don't have time to implement--plus, you could also help with the upcoming MBAFF patch (currently the code has far too many calls to getNeighborAff() )Why do you say that the cbf decoding dont work with interlacing? I think the cbf decoding can work with the interlace. It is possible to take a small change to fit into the mbaff. I am not familar with the mbaff.MBAFF rules for CBF selection are AFAIK rather messy...

[akupenguin]

Yes, I have read the latest libavcodec in ffdshow tryouts, It has been merged.
Latest?! It was merged in r4617 (http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/h264.c?r1=4607&r2=4617) in 2005.

[schweinsz]

Latest?! It was merged in r4617 (http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/h264.c?r1=4607&r2=4617) in 2005.
I even read a very old livavcodec in this summer. Perhaps a version in 2004.

[schweinsz]

Come to #x264dev on Freenode. We welcome optimizations--even just ideas for optimizations that you don't want/don't have time to implement--plus, you could also help with the upcoming MBAFF patch (currently the code has far too many calls to getNeighborAff() )MBAFF rules for CBF selection are AFAIK rather messy...

I even read the x264. It seems that the SSD in RDO is computed after the reconstraction. But to the best of my knowledge, It can be gotten directly from the transform domain exactly. A scale for coefficients is needed for the transform in H.264. So after de-quantization, the SSD can be gotten. The IDCT and add to mc signal is bypassed. But I have no time now to write it.

[Dark Shikari]

I even read the x264. It seems that the SSD in RDO is computed after the reconstraction. But to the best of my knowledge, It can be gotten directly from the transform domain exactly. A scale for coefficients is needed for the transform in H.264. So after de-quantization, the SSD can be gotten. The IDCT and add to mc signal is bypassed. But I have no time now to write it.We actually just happened to discuss this in #x264dev recently, and we concluded that it isn't very useful.

The reason it isn't useful is:

1. iDCT is really fast.
2. Psy-RD requires iDCT to be done anyways. It isn't really worth optimizing too much for the case of no psy-opts.
3. It would make the code much messier.
4. SSD in transform domain is not *exactly* the same because of rounding.
5. SSD in transform domain would require a new asm function to multiply by the correct DCT weighting values for each coefficient.

(By the way, this is the proper approach: suggest ideas before implementing them so that you don't waste time on something that has been concluded to be a bad idea, or so that we can suggest even better ways of doing it.)

[schweinsz]

I am happy that DiAVC alpha version is released. The diavc.ax and a setting tool is included.
It supports the interlace coding and frame-level parallel.
I have tested the DiAVC and compared to other decoders and found that the DiAVC is faster than the coreavc and divx h.264 decoder on my computer (intel core duo T2350 1.86G, ram 1G, FSB 533MHz, harddisk, 80G, ati mobility radeon x1450).

[Sagekilla]

@Dark: Regarding the change that would bork interlacing: Would it really be that bad if you created two code paths, one designed solely for progressive video, and another for field based?

I'm sure there's a very good reason why not to, and the only reasons I could think of where because of massive code duplication and messy code.

[Dark Shikari]

@Dark: Regarding the change that would bork interlacing: Would it really be that bad if you created two code paths, one designed solely for progressive video, and another for field based?

I'm sure there's a very good reason why not to, and the only reasons I could think of where because of massive code duplication and messy code.CoreAVC already does this. I don't really feel like doing it with x264. It'd be ugly, and hardly worth it for ~1% speed or whatever we'd get.

[Keiyakusha]

Can't get it work under win7. Every app that trying to use it just hangs so I even can't construct any graph... :(

[LoRd_MuldeR]

Can't get it work under win7. Every app that trying to use it just hangs so I even can't construct any graph... :(

Yes, same here. After the "diavc.ax" was registered, TimeCodec.exe didn't even startup. I just hung with 100% CPU load, the window never appeared.

Also GraphStudio froze as soon as I tried to add DiAVC to the graph. So I had to unregister the filter again :(

I don't know what compiler was used to make that binary. But if the Intel C Compiler was used, it may be this (http://forum.doom9.org/showpost.php?p=1328818&postcount=8105) issue showing up on Windows 7.

[jakor]

I think support of H264_VLD_NoFGT in DXVA1/2 killed the industry of PC AVC decoders.

[Astrophizz]

Just a quick test and I got ~72% as fast as DivX and ~84% as fast as CoreAVC in the GraphStudio decoder performance test. I have a Core Duo @ 2.0 GHz - basically the same as your dev system. Also the settings app doesn't seem to properly set it as the default decoder for h.264 for me.

[schweinsz]

Can't get it work under win7. Every app that trying to use it just hangs so I even can't construct any graph... :(

Only WinXP, win2000 and vista are supported now.

[schweinsz]

Just a quick test and I got ~72% as fast as DivX and ~84% as fast as CoreAVC in the GraphStudio decoder performance test. I have a Core Duo @ 2.0 GHz - basically the same as your dev system. Also the settings app doesn't seem to properly set it as the default decoder for h.264 for me.
I uploaded a bad version wrongly. I have uploaded the right version just now. You can use it now.

The following is my test result.
timecodec, null renderer
MissHK2008.mkv, 1920x1080, about 4Mbps, 24fps
DiAVC: User: 9s, kernel: 0s, total: 10s, real: 46s, fps: 293.7, dfps: 64.2
CoreAVC: User: 8s, kernel: 0s, total: 8s, real: 50s, fps: 348.8, dfps: 59.8
DiVX: User: 10s, kernel: 0s, total: 10s, real: 49s, fps: 275.9, dfps: 59.9

goldcurse.mp4, 1920x1080, about 50Mbps, 24fps
DiAVC: User: 7s, kernel: 0s, total: 7s, real: 87s, fps: 306.4, dfps: 27.5
CoreAVC: User: 4s, kernel: 0s, total: 4s, real: 96s, fps: 554.4, dfps: 25.0
DiVX: User: 8s, kernel: 0s, total: 8s, real: 93s, fps: 276.7, dfps: 25.7

After May, 2009, I never profile the DiAVC using the intel vTune, after then I improved the DiAVC very much. I will profile it recently and I believe I can still improve it very much.

Besides, the DiAVC setting only change the merit, what more things do I need to change?
I found the media player classic can select the decoder with biggest merit, but wmp not.

[Astrophizz]

Hm, with this new version nothing happens when I try to connect it in GraphStudio (not frozen... just nothing happens). Timecodec doesn't even see it :(

[buzzqw]

same here...

BHH

[schweinsz]

Hm, with this new version nothing happens when I try to connect it in GraphStudio (not frozen... just nothing happens). Timecodec doesn't even see it :(

Unzip to the same folder, and re-register the DiAVC decoder (Run the DiAVC setting.exe, Press the button "Register DiAVC decoder").
Or you can use the regsvr32.exe to register it.

I am a newcomer to the directshow development. I am only good at algorithms of video coding.

[Keiyakusha]

Only WinXP, win2000 and vista are supported now.

I know this. But knowing this doesn't make things any better for me so I had to try ;)

[Astrophizz]

Even when I register it manually I still can't see it in timecodec or connect it in graphstudio. Maybe it's something on my end.

[Keiyakusha]

I re-downloaded DiAVC and now as far as I can tell I have the same behavior as Astrophizz has. Don't see it in TimeCodec and can't do anything with it in Graphstudio (can't even insert it). But nothing freezes anymore. So maybe this is not really win7-related issue?

[schweinsz]

I re-downloaded DiAVC and now as far as I can tell I have the same behavior as Astrophizz has. Don't see it in TimeCodec and can't do anything with it in Graphstudio (can't even insert it). But nothing freezes anymore. So maybe this is not really win7-related issue?

I am sorry, I will fix the problem as fast as I can and then I release the correct version.

[schweinsz]

I re-downloaded DiAVC and now as far as I can tell I have the same behavior as Astrophizz has. Don't see it in TimeCodec and can't do anything with it in Graphstudio (can't even insert it). But nothing freezes anymore. So maybe this is not really win7-related issue?

I have uploaded a new version of the DiAVC to www.di-avc.com, the new version improve the registration part and add support to other windows platforms. As the google site is down, the two download address is from the www.di-avc.com.
The previous problems are from the registration and the flush the residual frames when bitstream end. I have fixed them.

[VFR maniac]

Hmm...
I registered diavc.ax by regsvr32, but the filter was not connected with any streams, and filename pointed C:\WINDOWS\system32\regsvr32.exe.

OS: Windows XP SP2


Edit: Registration succeeded with DiAVCSetting.exe, but the order of displaying frames is confusion.

[Keiyakusha]

Hi. Just tried new version and it works for me! I don't have much time to play with it now, since I know that results may vary a bit depending on tested file. But I did some quick comparison on small SD sample. On my Core2Duo @ 2.66 ghz it looks something like this:

DivX: 735.6873
DiAVC: 710.6077
CoreAVC: 667.2235
FFDShow/ffmpeg-mt: 541.4999
Microsoft DTV-DVD:476.1
FFDShow/libavcodec: 461.1986

All of these measured in 3 passes using Graphstudio with null renderer, except Microsoft DTV-DVD. It shows astronomical results (http://forum.doom9.org/showthread.php?p=1302394#post1302394) sometimes. So TimeCodec was used for it instead. I like the results so far, will play more with it later. Thanks for the update!

[Astrophizz]

Just did a quick test with timecodec.exe and got this on some 720p content (2.0 GHz CoreDuo):
DiAVC: User: 3s, kernel: 0s, total: 3s, real: 21s, fps: 656.7, dfps: 103.9
DivX: User: 3s, kernel: 0s, total: 3s, real: 19s, fps: 688.9, dfps: 111.4
CoreAVC: User: 8s, kernel: 0s, total: 8s, real: 22s, fps: 261.2, dfps: 95.9

That's pretty impressive.

[Keiyakusha]

With HD video DiAVC is faster for me. Faster than DivX for about 4-8 fps

What I noticed:
- Can't connect DiAVC to Haali video renderer
- Playback in MPC-HC is jumpy. It means I see blinking of almost random frames. Have no idea why this is happening. In graphstudio with the same filter chain all seems to be fine.
- I see decoding artifacts sometimes:
http://img517.imageshack.us/img517/8774/artf.jpg
At 6-8 second with with this sample (http://www.mediafire.com/?2mfnh2mjtiw).
other decoders - no problems.

[schweinsz]

With HD video DiAVC is faster for me. Faster than DivX for about 4-8 fps

Yes, the similar results with me.
(My laptop: intel core duo T2350 1.86G, ram 1G, FSB 533MHz, harddisk, 80G, ati mobility radeon x1450)
timecodec, null renderer

MissHK2008.mkv, 1920x1080, about 4Mbps, 24fps
DiAVC: User: 9s, kernel: 0s, total: 10s, real: 46s, fps: 293.7, dfps: 64.2
CoreAVC: User: 8s, kernel: 0s, total: 8s, real: 50s, fps: 348.8, dfps: 59.8
DiVX: User: 10s, kernel: 0s, total: 10s, real: 49s, fps: 275.9, dfps: 59.9


goldcurse.mp4, 1920x1080, about 50Mbps, 24fps
DiAVC: User: 7s, kernel: 0s, total: 7s, real: 87s, fps: 306.4, dfps: 27.5
CoreAVC: User: 4s, kernel: 0s, total: 4s, real: 96s, fps: 554.4, dfps: 25.0
DiVX: User: 8s, kernel: 0s, total: 8s, real: 93s, fps: 276.7, dfps: 25.7


air.mp4: 1920x1080, 5.2Mbps
DiAVC: User: 7s, kernel: 0s, total: 7s, real: 30s, fps: 279.0, dfps: 73.2
DIVX: User: 9s, kernel: 0s, total: 9s, real: 30s, fps: 245.4, dfps: 72.5
CoreAVC: User: 6s, kernel: 0s, total: 6s, real: 30s, fps: 336.3, dfps: 72.8


assembly.mp4: 1920x832, 5.5Mbps
DiAVC: User: 6s, kernel: 0s, total: 6s, real: 41s, fps: 400.4, dfps: 62.5
DIVX: User: 6s, kernel: 0s, total: 6s, real: 44s, fps: 397.5, dfps: 58.7
CoreAVC: User: 5s, kernel: 0s, total: 5s, real: 46s, fps: 459.2, dfps: 56.2

blue ray.mp4: 1920x1080, 22.9Mbps
DiAVC: User: 3s, kernel: 0s, total: 3s, real: 23s, fps: 304.7, dfps: 44.1
DIVX: User: 3s, kernel: 0s, total: 3s, real: 22s, fps: 287.2, dfps: 44.4
CoreAVC: User: 2s, kernel: 0s, total: 2s, real: 22s, fps: 350.8, dfps: 45.3

deep blue.mp4: 1440x1080, 18.9Mbps
DiAVC: User: 2s, kernel: 0s, total: 2s, real: 20s, fps: 330.3, dfps: 39.0
DIVX: User: 6s, kernel: 0s, total: 6s, real: 23s, fps: 118.0, dfps: 34.2
CoreAVC: User: 1s, kernel: 0s, total: 1s, real: 21s, fps: 512.0, dfps: 37.2

goldcurse2.mkv: 1920x1080, 29.3Mbps
DiAVC: User: 10s, kernel: 0s, total: 10s, real: 84s, fps: 282.8, dfps: 36.6
DIVX: User: 12s, kernel: 0s, total: 12s, real: 86s, fps: 250.2, dfps: 35.8
CoreAVC: User: 7s, kernel: 0s, total: 7s, real: 89s, fps: 421.7, dfps: 34.3

planet earth.mp4: 1920x1080, 11.7Mbps
DiAVC: User: 14s, kernel: 0s, total: 14s, real: 91s, fps: 281.4, dfps: 46.2
DIVX: User: 15s, kernel: 0s, total: 15s, real: 101s, fps: 264.0, dfps: 41.3
CoreAVC: User: 12s, kernel: 0s, total: 12s, real: 105s, fps: 332.2, dfps: 39.7

BillSample.mp4 (interlace): 1440x1080, 5.2Mbps
DiAVC: User: 2s, kernel: 0s, total: 2s, real: 13s, fps: 617.9, dfps: 99.1
DIVX: User: 5s, kernel: 0s, total: 6s, real: 17s, fps: 210.0, dfps: 78.2
CoreAVC: User: 1s, kernel: 0s, total: 1s, real: 12s, fps: 753.4, dfps: 104.1

withyou.mp4 (interlace): 1440x1080, 4.9Mbps
DiAVC: User: 24s, kernel: 1s, total: 26s, real: 103s, fps: 579.2, dfps: 147.1
DIVX: User: 62s, kernel: 9s, total: 72s, real: 143s, fps: 211.3, dfps: 106.0
CoreAVC: User: 19s, kernel: 0s, total: 19s, real: 98s, fps: 795.2, dfps: 154.8

kellylove.mp4 (interlace): 1920x1080, 27.4Mbps
DiAVC: User: 15s, kernel: 0s, total: 15s, real: 113s, fps: 297.5, dfps: 40.9
DIVX: User: 49s, kernel: 6s, total: 55s, real: 142s, fps: 83.2, dfps: 32.8
CoreAVC: User: 13s, kernel: 0s, total: 13s, real: 124s, fps: 341.9, dfps: 37.5

The DiAVC is faster than the coreavc and divx H.264 decoder.
Especially, I found the DIVX decoder is VERY poor on dealing with interlace contents.

Next I will profile the DiAVC using the vtune, then I can improve it more. I believe I can improve it very much still. I never profile it after May, 2009.


What I noticed:
- Can't connect DiAVC to Haali video renderer
- Playback in MPC-HC is jumpy. It means I see blinking of almost random frames. Have no idea why this is happening. In graphstudio with the same filter chain all seems to be fine.
- I see decoding artifacts sometimes:
http://img517.imageshack.us/img517/8774/artf.jpg
At 6-8 second with with this sample (http://www.mediafire.com/?2mfnh2mjtiw).
other decoders - no problems.

Yes, there do remain many problems with the filter. I will fix them recently. About the blinking, I even found that If the DiAVC is connected to the VMR9, and set pProperties->cBuffers>1 in function "HRESULT CDiAVC::DecideBufferSize", there are blinking always, so I must set pProperties->cBuffers==1 when VMR9 in current version. I will investigate it.
btw: I can not get to the picture and the video you post.

[Astrophizz]

I'll try to run some more tests and see if I get better results. For some reason DivX performs a bitter better on my system even though we have the same CPU architecture.

[Keiyakusha]

btw: I can not get to the picture and the video you post.

Sorry, I don't understand. You can't download it?
EDIT: if so - try this (http://www.multiupload.com/RSFQDI2HID)...

By the way, with Haali renderer this is not really a problem. At first I just not realized that DiAVC outputs only YV12. Haali accepts only YUY2, so I just need additional transform filter.

[schweinsz]

Sorry, I don't understand. You can't download it?
EDIT: if so - try this (http://www.multiupload.com/RSFQDI2HID)...

By the way, with Haali renderer this is not really a problem. At first I just not realized that DiAVC outputs only YV12. Haali accepts only YUY2, so I just need additional transform filter.

Yes, I can't download it. I get it now from your new address. Thank you very much.

[Astrophizz]

Good news, I did some test on longer clips (I had been using ~30 second ones before) and DiAVC is the fastest for me! This is really impressive.

I get the blinking too and videos start out green (Haali renderer). Seeking causes the image to freeze also.

[Avish]

64-bit XP is not supported yet, right?? Coz MPC-HC just hangs when I try to play anything with DiAVC.

[Kurtnoise]

Can't get it work under win7. Every app that trying to use it just hangs so I even can't construct any graph... :(
works for me only w/ the madVR or VMR9 as renderer...

[schweinsz]

64-bit XP is not supported yet, right?? Coz MPC-HC just hangs when I try to play anything with DiAVC.

Yes, there is only 32-bit version now. I must re-code all assembly code for 64-bit version in future.

[Kurtnoise]

@schweinsz : any chance to add lossless contents support in diAVC ?

[schweinsz]

@schweinsz : any chance to add lossless contents support in diAVC ?

Adding lossless contents support is not a complex task. But I'll start work on it after all other more important tasks are finished, such as improving the speed, filter bug fix, compatibility, 64-bit version, etc.

[Dark Shikari]

Adding lossless contents support is not a complex task. But I'll start work on it after all other more important tasks are finished, such as improving the speed, filter bug fix, compatibility, 64-bit version, etc.Adding 64-bit assembly is a huge task, especially if you don't intend to do what x264 does and use a 32-bit/64-bit abstraction system. Lossless is a couple hours at most by comparison.

Also, note there are two lossless modes: the old one (profile_idc=144) and the new one (profile_idc=244). Old one is just replacing dct with a direct subtraction, while the new one involves some pixel prediction and thus is slightly trickier.

[schweinsz]

Adding 64-bit assembly is a huge task, especially if you don't intend to do what x264 does and use a 32-bit/64-bit abstraction system. Lossless is a couple hours at most by comparison.

After I finish the DiAVC, I'll do some works to improve the x264.

Also, note there are two lossless modes: the old one (profile_idc=144) and the new one (profile_idc=244). Old one is just replacing dct with a direct subtraction, while the new one involves some pixel prediction and thus is slightly trickier.

I know this, but that only add some intra-prediction function, and replace some function pointer of intra-prediction.

[Dark Shikari]

After I finish the DiAVC, I'll do some works to improve the x264.I was referring to the system for having both types of assembly; if you have to copy/paste all the assembly to get 32-bit and 64-bit versions it gets quite messy.
I know this, but that only add some intra-prediction function, and replace some function pointer of intra-prediction.Yup, it's not too complicated.

[schweinsz]

I was referring to the system for having both types of assembly; if you have to copy/paste all the assembly to get 32-bit and 64-bit versions it gets quite messy.


Yes, I have understanded you. I will code all 64-bit assembly code to get fastest speed. Actually the 64-bit have more things to do because we can take a full use of the 64-bit general register.

[Dark Shikari]

Yes, I have understanded you. I will code all 64-bit assembly code to get fastest speed. Actually the 64-bit have more things to do because we can take a full use of the 64-bit general register.But on WIN64 you have the atrocious API that requires callee-save xmm6-xmm15, which seriously limits what you can do (since if you can get a 10 cycle speedup by using 8 more registers, you've probably lost performance because of the loads/stores...).

[schweinsz]

But on WIN64 you have the atrocious API that requires callee-save xmm5-xmm15, which seriously limits what you can do (since if you can get a 10 cycle speedup by using 8 more registers, you've probably lost performance because of the loads/stores...).

Oh, VERY bad news for me. Thank you very much. I don't know this limitation ever.

[Dark Shikari]

Oh, VERY bad news for me. Thank you very much. I don't know this limitation ever.The Windows 64-bit API is very weird and you should do some research on it before you start writing assembly code.

You should look at common/x86/x86inc.asm in x264; it contains macros for handling of the three calling conventions (32-bit, 64-bit, win64). Win64 is extremely weird and is completely incompatible with all other 64-bit calling conventions (which use the standard one).

In addition to the callee-save XMM registers, it also has a different general-purpose register calling convention, probably just to annoy people.

And the above is a typo, it's xmm6-xmm15 that are callee-save.

[squid_80]

The most annoying thing is the exception handling restrictions - if you touch the stack pointer you are supposed to set up a frame pointer, have properly formed epilogs/prologs and make sure the special exception handling data is included in the binary. (I say "supposed to" because it will still run without it but if an exception/crash happens the app will be immediately terminated, even if an exception handler is meant to catch it.)

MS gets the middle finger for keeping rsi/rdi non-volatile as well.

[schweinsz]

The most annoying thing is the exception handling restrictions - if you touch the stack pointer you are supposed to set up a frame pointer, have properly formed epilogs/prologs and make sure the special exception handling data is included in the binary. (I say "supposed to" because it will still run without it but if an exception/crash happens the app will be immediately terminated, even if an exception handler is meant to catch it.)

MS gets the middle finger for keeping rsi/rdi non-volatile as well.

The DiAVC is designed to prevent from debugging by the use of "exception handle".

[schweinsz]

Which splitter can split the dmb contents in http://samples.mplayerhq.hu/V-codecs/h264/dmb/? I found that those bitstreams crash the haali media splitter.

[slavickas]

you may try MPC-HC splitter, though havent tested those files myself

[schweinsz]

Where can I get some H.264 bitstreams with mbaff and weighted prediction? The jm can't produce the bitstreams.

[Dark Shikari]

Where can I get some H.264 bitstreams with mbaff and weighted prediction? The jm can't produce the bitstreams.Here (http://www.mediafire.com/download.php?mi2zjoynymi) is a huge suite of official bitstreams, containing things like MBAFF, weighted prediction, long-term references, MBAFF/PAFF mixes, and many other nasty things that will break your decoder.

[schweinsz]

Here (http://www.mediafire.com/download.php?mi2zjoynymi) is a huge suite of official bitstreams, containing things like MBAFF, weighted prediction, long-term references, MBAFF/PAFF mixes, and many other nasty things that will break your decoder.
I can't connect to the site. I have downloaded all conformance bitstreams from http://wftp3.itu.int/av-arch/jvt-site/draft_conformance/ and passed most among them.
Are there more bitstreams at the site you give except I have downloaded?

In addition, what do you mean in "duplicating a frame in the reference list with a different weight more than once"?

[Dark Shikari]

I can't connect to the site. I have downloaded all conformance bitstreams from http://wftp3.itu.int/av-arch/jvt-site/draft_conformance/ and passed most among them.
Are there more bitstreams at the site you give except I have downloaded?Don't know. My link includes the FREXT bitstreams if you don't have those.In addition, what do you mean in "duplicating a frame in the reference list with a different weight more than once"?I mean that your reference list looks something like this:

Before reordering: 0 1 2 3 4
After reordering: 0 1 0 2 0 3 0 4

And each reference frame in the latter list has its own weight.

You can generate such a stream with the weightp branch of x264 by using --weightp 2 on a fade.

[schweinsz]

Don't know. My link includes the FREXT bitstreams if you don't have those.I mean that your reference list looks something like this:

Before reordering: 0 1 2 3 4
After reordering: 0 1 0 2 0 3 0 4

And each reference frame in the latter list has its own weight.

You can generate such a stream with the weightp branch of x264 by using --weightp 2 on a fade.

There are frext bitstreams in http://wftp3.itu.int/av-arch/jvt-site/draft_conformance/FRExt/.

[mariush]

I can't connect to the site. I have downloaded all conformance bitstreams from http://wftp3.itu.int/av-arch/jvt-site/draft_conformance/ and passed most among them.
Are there more bitstreams at the site you give except I have downloaded?

In addition, what do you mean in "duplicating a frame in the reference list with a different weight more than once"?

Here's the file Dark Shikari posted, I saved it myself yesterday:

http://www.savedonthe.net/avc_regression.7z

I'll delete it in a couple of days.

[schweinsz]

Here's the file Dark Shikari posted, I saved it myself yesterday:

http://www.savedonthe.net/avc_regression.7z

I'll delete it in a couple of days.

Thank you, I downloaded them just now and found they are same with those in http://wftp3.itu.int/av-arch/jvt-site/draft_conformance/. I will release the new version of the DiAVC recently. I have passed most of them and I have finished most SSSE3 code.

[schweinsz]

The last alpha version is released now.
The download address is http://di-avc.com/DiAVC_alpha.zip.
Main changes are as follows:
weighted_pred_flag = 1 is supported.
MANY bugs including the bugs in the decoder and bugs in the filter are fixed.

The speed is same as the last version. All improvements on speed including the SSSE3 code will be released in the beta version about 20 days later.

[Cyber-Mav]

whats the speed like of this compared to divx or coreavc?

[BetaBoy]

Well..... according to http://www.di-avc.com/ they are the the"World's Fastest H.264 High-Definition Software Decoder".... mmmm I wonder where I've seen that?
http://img21.imageshack.us/img21/1734/clipboard02aj.png

It's all good... but I'd really like to see stats to that as last we checked it was substantially slower.

[LoRd_MuldeR]

Does DiAVC work on Windows 7 now? The last time I tried, I couldn't get it to work...

[Disabled]

Right Betaboy and calling me flaming your thread... Whatever. Last time I checked libavcodec was the fastest h264 decoder*
Here are some benchmarks from this thread:
Just did a quick test with timecodec.exe and got this on some 720p content (2.0 GHz CoreDuo):
DiAVC: User: 3s, kernel: 0s, total: 3s, real: 21s, fps: 656.7, dfps: 103.9
DivX: User: 3s, kernel: 0s, total: 3s, real: 19s, fps: 688.9, dfps: 111.4
CoreAVC: User: 8s, kernel: 0s, total: 8s, real: 22s, fps: 261.2, dfps: 95.9

That's pretty impressive.
... quick comparison on small SD sample. On my Core2Duo @ 2.66 ghz it looks something like this:

DivX: 735.6873
DiAVC: 710.6077
CoreAVC: 667.2235
FFDShow/ffmpeg-mt: 541.4999
Microsoft DTV-DVD:476.1
FFDShow/libavcodec: 461.1986

And one from the author:
goldcurse.mp4, 1920x1080, about 50Mbps, 24fps
DiAVC: User: 7s, kernel: 0s, total: 7s, real: 87s, fps: 306.4, dfps: 27.5
CoreAVC: User: 4s, kernel: 0s, total: 4s, real: 96s, fps: 554.4, dfps: 25.0
DiVX: User: 8s, kernel: 0s, total: 8s, real: 93s, fps: 276.7, dfps: 25.7


(* on powerpc or xbox1 and other hardware not supported by other decoders - "fastest decoder" is always dependent on the hardware, and due to SSEx, DivX is faster than CoreAVC on some processors (until 2.0 arrives))

[BetaBoy]

Diabled... not at all.. note I said "It's all good...".. thx for the stats... looks like it has improved a bit.

[CruNcher]

More impressive is the continuous effort in this since almost 1 year alone with the target to beat something or should we rather say beat another individuals skillset in this case Picards :)
Betaboy any acquisitions planned for this [next] year ;)

[schweinsz]

Well..... according to http://www.di-avc.com/ they are the the"World's Fastest H.264 High-Definition Software Decoder".... mmmm I wonder where I've seen that?
http://img21.imageshack.us/img21/1734/clipboard02aj.png

It's all good... but I'd really like to see stats to that as last we checked it was substantially slower.

I have done some tests about the three decoder (DiAVC, coreavc and divx) on HD contents.
http://forum.doom9.org/showthread.php?p=1334702#post1334702
The DiAVC is fastest and the coreavc is lowest especially for high-bitrate.
All bitstreams are downloaded from internet.
Same results is gotten by other.
http://forum.doom9.org/showthread.php?p=1334870#post1334870
http://forum.doom9.org/showthread.php?p=1334476#post1334476

[schweinsz]

Does DiAVC work on Windows 7 now? The last time I tried, I couldn't get it to work...

I have deleted the restriction that only work on xp, 2000 and vista. The DiAVC should work on win7. You can try it now.

[Astrophizz]

I'm still getting the back-and-forth frame hopping. I tried unregistering it and reregistering and different renderers but had no luck.

[schweinsz]

I'm still getting the back-and-forth frame hopping. I tried unregistering it and reregistering and different renderers but had no luck.

I ever met the problem before. But after I modify the flow of transform, I find it ok on my laptop. I will try to find the problem about the reference time and media time.

[Cyber-Mav]

Right Betaboy and calling me flaming your thread... Whatever. Last time I checked libavcodec was the fastest h264 decoder*
Here are some benchmarks from this thread:



And one from the author:



(* on powerpc or xbox1 and other hardware not supported by other decoders - "fastest decoder" is always dependent on the hardware, and due to SSEx, DivX is faster than CoreAVC on some processors (until 2.0 arrives))

my results also back this up showing that divx is the fastest decoder these days. and infact coreavc seems to be the slowest of the 3. :eek:

[LoRd_MuldeR]

I have deleted the restriction that only work on xp, 2000 and vista. The DiAVC should work on win7. You can try it now.

Okay. Will try and report back...

[schweinsz]

my results also back this up showing that divx is the fastest decoder these days. and infact coreavc seems to be the slowest of the 3. :eek:
You can test some 1080p or 1080i contents, you will get the DiAVC is fastest especially for high-bitrate. I will release the beta version about 20 days later, it will 10% at least faster than the current version.

[LoRd_MuldeR]

I have deleted the restriction that only work on xp, 2000 and vista. The DiAVC should work on win7. You can try it now.

Okay. Will try and report back...

Sorry, same problem as before:
It seems DiAVCSetting.exe doesn't register the DiAVC.ax at all. At least it cannot be found by TimeCodec or by GraphStudio.

I can register it manually by running regsvr32.exe from an Admin console, but then TimeCodec will freeze at startup.
Same goes for GraphStudio, as soon as I insert your filter into the graph. Will have to unregister...

[BetaBoy]

We just found the same thing out.... it breaks TimeCodec.

[LoRd_MuldeR]

We just found the same thing out.... it breaks TimeCodec.

Not only TimeCodec. GraphStudio will hang too (with 100% CPU load), as soon as I try to insert DiAVC :(

Well, it's still "alpha" for a reason. So problems are expected, I guess. Let's wait for the upcoming "Beta" release then.

[Keiyakusha]

Ok I want to elaborate a bit what I said sometimes earlier. For example with this (http://www.mediafire.com/file/odzqiwmftnz/ADST_sample.mkv) 1080p sample, I'm getting following speeds:
DiAVC: 89.1697
DivX: 82.8047
CoreAVC: 79.9550

About win7... works fine on 32bit system, with manual registering and DiAVCSetting.exe, with timecodec and graphstudio. :eek:

As for jumping playback, schweinsz, you really should test MPC-HC (http://forum.doom9.org/showthread.php?t=123537). It seems not every player affected. For example there is no such effect in KMPlayer.

[LoRd_MuldeR]

About win7... works fine on 32bit system, with manual registering and DiAVCSetting.exe, with timecodec and graphstudio. :eek:

I'm on 64-Bit, so maybe that's the reason...

[schweinsz]

I'm on 64-Bit, so maybe that's the reason...
The DiAVC don't support the 64bit system. It will support the 64bit system in future.

[squid_80]

It should still work, there's no reason for it to go into an infinite loop.

[schweinsz]

It should still work, there's no reason for it to go into an infinite loop.
Do you mean that a 32-bit ax or dll can work on a 64-bit win7? On which conditions can the 32bit ax or dll run on a 64bit system? I never tested the DiAVC on 64-bit system. The initialization of the DiAVC use interrupt such as int 02dh or int 3 to prevent user to dubug it. Besides, are there some differences about the system function in kernel32.dll, ntdll.dll or advapi.dll between the 64-bit and the 32-bit windows? I must buy a new computer recently.

[squid_80]

A 32-bit directshow filter should run fine on any 64-bit windows (not just win7), provided a 32-bit player is used.

[schweinsz]

A 32-bit directshow filter should run fine on any 64-bit windows (not just win7), provided a 32-bit player is used.

But how about the system functions in kernel32.dll, ntdll.dll or advapi.dll? The DiAVC have a direct call to some functions in these dll?

[LoRd_MuldeR]

But how about the system functions in kernel32.dll, ntdll.dll or advapi.dll? The DiAVC have a direct call to some functions in these dll?

64-Bit Windows has a 32-Bit Subsystem (WOW64). All the system DLL's exists in two versions, 32-Bit and 64-Bit.

The 64-Bit system folder is "C:\Windows\System32" and the 32-Bit system folder is "C:\Windows\SysWow64". Weird, but that's the way it is.

32-Bit applications (and of course also 32-Bit DLL's) will load the 32-Bit system DLL's and work flawlessly under 64-Bit Windows...

[Cyber-Mav]

You can test some 1080p or 1080i contents, you will get the DiAVC is fastest especially for high-bitrate. I will release the beta version about 20 days later, it will 10% at least faster than the current version.

this is something i will be waiting for. looks like we got an excellent option for a free fast avc decoder comming up.
will the beta version run faster on older hardware such as amd athlonXP?

[sneaker_ger]

In the start post schweinsz says that you'll need a CPU with SSE2 to run it. So an Athlon XP probably won't do.

[Cyber-Mav]

In the start post schweinsz says that you'll need a CPU with SSE2 to run it. So an Athlon XP probably won't do.

ahh i havent tried it on my athlonxp machine. i need to make some time to test these decoders out on the athlonxp and see which one is best for old skool cpus.

[schweinsz]

ahh i havent tried it on my athlonxp machine. i need to make some time to test these decoders out on the athlonxp and see which one is best for old skool cpus.

The DiAVC require SSE2-enable cpu currently. I am trying to make the DiAVC to be the best H.264 decoder for netbooks or some others that have not a hardware decoder firstly. Perhaps I will code some MMX code to replace the current SSE2 code so that the DiAVC support some old cpu in future.

[littleD]

The DiAVC require SSE2-enable cpu currently. I am trying to make the DiAVC to be the best H.264 decoder for netbooks or some others that have not a hardware decoder firstly. Perhaps I will code some MMX code to replace the current SSE2 code so that the DiAVC support some old cpu in future.

Cpus with only mmx arent suitable for anything. If you will support SSE that would be cool.

[nm]

Cpus with only mmx arent suitable for anything. If you will support SSE that would be cool.

Unlike MMX, SSE1 is not really useful for decoding H.264, or pretty much any video format, since it only supports floating-point data. See this thread for some facts: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2005-September/003776.html

[littleD]

Ok, thanks.

[schweinsz]

64-Bit Windows has a 32-Bit Subsystem (WOW64). All the system DLL's exists in two versions, 32-Bit and 64-Bit.

The 64-Bit system folder is "C:\Windows\System32" and the 32-Bit system folder is "C:\Windows\SysWow64". Weird, but that's the way it is.

32-Bit applications (and of course also 32-Bit DLL's) will load the 32-Bit system DLL's and work flawlessly under 64-Bit Windows...

Could you share me some dll in the directory "C:\Windows\SysWow64"? These needed dll are ntdll.dll, kernel32.dll and advapi32.dll. This will help me much. I have not a x64 cpu.

[LoRd_MuldeR]

Well, I think sharing proprietary DLL's from Microsoft Windows, DLL's that aren't explicitly marked as redistributables, would be a rule #6 violation.

Why you can't effort your own copy of 64-Bit Windows? Given that your are working on a commercial project and have "big" plans with it, this should be a relatively small investment ;)

[Astrophizz]

Well he said he doesn't have a 64-bit cpu so 64-bit windows wouldn't help I don't think.

[BetaBoy]

(* on powerpc or xbox1 and other hardware not supported by other decoders - "fastest decoder" is always dependent on the hardware, and due to SSEx, DivX is faster than CoreAVC on some processors (until 2.0 arrives))

Be mindful when using timecodec.exe for it's DFPS output that it is meaningless for multi-threaded codecs, and that the time spent in the main thread is called by the splitter so DFPS is only "relative to a wallclock".

Haali has discussed this several times.

[LoRd_MuldeR]

Well he said he doesn't have a 64-bit cpu so 64-bit windows wouldn't help I don't think.

So how would he run the 64-Bit binaries that he asked for then? And how does he test/debug the software he's developing at all ???

The only CPU that supports SSE2 but not 64-Bit would be a Pentium 4, I think :eek:

Developing and tuning a "performance" software that is intended for a wide audience on such an outdated machine is very counterproductive, isn't it?

[Astrophizz]

Him and I have the same family of cpu, the Intel Core Duo (not core2). It has SSE2 but isn't 64-bit. I mean if he's intending this to be a significant source of profit then yeah, getting a new comp would be a good idea. I just have mine from when I started college and haven't replaced it.

[Astrophizz]

Be mindful when using timecodec.exe for it's DFPS output that it is meaningless for multi-threaded codecs, and that the time spent in the main thread is called by the splitter so DFPS is only "relative to a wallclock".

Haali has discussed this several times.

So comparisons using DFPS are invalid? I was lead to believe that DFPS should be used over FPS. What exactly is DFPS?

[LoRd_MuldeR]

Him and I have the same family of cpu, the Intel Core Duo (not core2). It has SSE2 but isn't 64-bit.

Ah that makes sense. Still it's kind of weird to develop on such a limited machine, if you are running an IT business. Especially if you focus on high performance software ;)

For a regular user or a hobbyist that CPU may be perfectly fine. But as a commercial developer you must assume that many of your (potential) customers are on 64-Bit Windows now...

[schweinsz]

So how would he run the 64-Bit binaries that he asked for then? And how does he test/debug the software he's developing at all ???

The only CPU that supports SSE2 but not 64-Bit would be a Pentium 4, I think :eek:

Developing and tuning a "performance" software that is intended for a wide audience on such an outdated machine is very counterproductive, isn't it?

I have a core duo 1.86GHz. I have said this when I gave a speed comparison. I have a plan to buy a core i7 or amd phenom.

[schweinsz]

So comparisons using DFPS are invalid? I was lead to believe that DFPS should be used over FPS. What exactly is DFPS?

It is still a most significant data for decoder speed. When multi-thread decoder is tested and some other test thread is running, it is very difficult to get the time used by the multi-thread decoder. But the splitter and the null-renderer use very limited time when compared to the decoder especially for HD materials, the decoder-used time gotten timecodec is very accurate.

[schweinsz]

Where can I get a clip with out-of-range MV?

[schweinsz]

I uploaded a new bug-fixed alpha version.
Some changes is as follows:
fixed the playback problem in MPC-HC.
fixed the back-and-forth frame hopping.
fixed the problem in win 64-bit PROBABLY.

The beta version will be released about 15 days later.

[LoRd_MuldeR]

Still doesn't work on 64-Bit Windows 7. But at least it doesn't freeze TimeCodec anymore. Now it doesn't show up on the list at all!

In GraphStudio it is on the list, so the filter is registered. But it can't be instantiated...

[Keiyakusha]

fixed the playback problem in MPC-HC.
fixed the back-and-forth frame hopping.

Thanks! At first look these are fixed for me! Now I can try it in real playback.

And about graphstudio... I don't know much about how 64bit systems works but maybe this is something easy? maybe DiAVC writes the registry keys not in the right place, tries to get access to something 64bit instead of 32bit or something like this...

[VFR maniac]

fixed the playback problem in MPC-HC.
fixed the back-and-forth frame hopping.


Excellent!!

There is another problem, DiAVC won't connect directly with madVR and crashes, while DiAVC->ffdshow(RAW Video)->madVR is successful.

[LoRd_MuldeR]

Mabye this is the reason:

YUY2 support is not planned. Simple reason: Some decoders prefer to output YUY2 and always do that if the renderer accepts it, but they are willing to output YV12 if YUY2 is not accepted. YV12 is better for quality. So madVR does not accept YUY2 to force decoders to output the better quality format.

NV12 could eventually be added later, but you can also use ffdshow to convert YV12 to NV12 right now. So it's not high priority for me.

[VFR maniac]

Oh I see. Thanks.

[Keiyakusha]

Mabye this is the reason:

But as I understand madvr excepts only YV12? Well, DiAVC outputs only YV12...

By the way I can connect DiAVC and madVR directly in graphstudio. In MPC-HC it also works, but It crashes on seeking attempt.

[VFR maniac]

Ah sorry, I brought confusion.
A crashing sample has non-mod 16 width.
Samples which have mod 16 width can connect madVR.
Apparently almost all AVC decoder couldn't connect non-mod 16 with madVR.
So, please don't mind this matter.

In MPC-HC it also works, but It crashes on seeking attempt.
Really?　It doesn't reproduce it in my environment.


BTW, in MPC-HC, DiAVC->ffdshow(RAW Video)->madVR shifts frame-rate position, therefore it cannot play non-mod16 and VFR movie correctly with madVR.
I think this is a bug.

[Keiyakusha]

Really?　It doesn't reproduce it in my environment.
Uhh, all samples that I tested has non-mod16 height :)
With mod16 width and height it works fine, indeed.

[VFR maniac]

Hm, DiAVC+madVR is unstable.
For instance, when you stop playing, it runs through CPU usage rate unless restarting the movie or closing the player.

[LoRd_MuldeR]

But as I understand madvr excepts only YV12? Well, DiAVC outputs only YV12.

If that's really true, then this shouldn't be the problem.

However Madshi said many decoder filters prefer YUY2 output, so I though it may be the case with DiAVC too. And if that was the case, it would at least explain why DiAVC and MadVR can't connect directly, but can connect with ffdshow in between (as ffdshow would be doing the necessary YUY2 -> YV12 conversion). I can't test what DiAVC does output, as I cannot instantiate it here. So I only speculate...

[squid_80]

New version does work on win64, make sure you re-registered it.

[LoRd_MuldeR]

New version does work on win64, make sure you re-registered it.

Yes, of course I did. As said before, it doesn't make TimeCodec freeze anymore, but doesn't show up in the list. Also it doesn't make GraphStudio freeze anymore, but adding the "DiAVC" filter from the list doesn't do anything. The filter cannot be added to the graph, although it appears on the list. So all seems like the filter is registered correctly but connect be instantiated. For detailed system specs, see my sig...

[squid_80]

That just sounds like it's been registered, then the file moved to a different location. Works fine for me.

[LoRd_MuldeR]

That just sounds like it's been registered, then the file moved to a different location. Works fine for me.

No, it didn't move for sure. But I will try again this evening :)

[schweinsz]

Ah sorry, I brought confusion.
A crashing sample has non-mod 16 width.
Samples which have mod 16 width can connect madVR.
Apparently almost all AVC decoder couldn't connect non-mod 16 with madVR.
So, please don't mind this matter.


Really?　It doesn't reproduce it in my environment.


BTW, in MPC-HC, DiAVC->ffdshow(RAW Video)->madVR shifts frame-rate position, therefore it cannot play non-mod16 and VFR movie correctly with madVR.
I think this is a bug.

Ok, I will force the madVR to alloc the buffer with mod 16 width if the bitstream is not mod 16 width.

[VFR maniac]

Incidentally, could you fix jerky-playback on DiAVC+madVR if the stream has non-mod16 height?
Ah, if this is madVR's problem, don't mind this.

[schweinsz]

A new version is available.
change:
Force both the width and the height mod 16 when madVR is used.

[Cyber-Mav]

i think im going to hold off on purchasing coreavc 2.0 and see how the beta is of diavc. so far its progressing very well in deed.

[VFR maniac]

A new version is available.
change:
Force both the width and the height mod 16 when madVR is used.

Thanks! it works.

Uhh, jerky-playback of non-mod16 streams is maybe madVR's problem.

I found other bugs:
1. DiAVC cannot connect stream in WMP11, though DiAVC set as default decoder.
But DiAVC can connect it after changing the merit value into 0xff80000X.
2. When the stream is repeated in any players and renderers, the frame-rate position (or timestamp position) is shifted.
For example:
first time: 0(24) 1(24) 2(24) 3(30) 4(30) 5(30) ...
second time: 0(24) 1(24) 2(24) 3(24) 4(30) 5(30) ...

[schweinsz]

Thanks! it works.

Uhh, jerky-playback of non-mod16 streams is maybe madVR's problem.

I found other bugs:
1. DiAVC cannot connect stream in WMP11, though DiAVC set as default decoder.
But DiAVC can connect it after changing the merit value into 0xff80000X.
2. When the stream is repeated in any players and renderers, the frame-rate position (or timestamp position) is shifted.
For example:
first time: 0(24) 1(24) 2(24) 3(30) 4(30) 5(30) ...
second time: 0(24) 1(24) 2(24) 3(24) 4(30) 5(30) ...

Could you share me such a bitstream?

[turbojet]

Where can I get a clip with out-of-range MV?

right here (http://www.mediafire.com/?mtmymmhgt2h)

[schweinsz]

right here (http://www.mediafire.com/?mtmymmhgt2h)

I am sorry that I can't connect to the mediafire, could you upload it to another site?

[turbojet]

Sure, sendspace (http://www.sendspace.com/file/uukbto)

[schweinsz]

Sure, sendspace (http://www.sendspace.com/file/uukbto)

This is not available also, I don't know what is the problem with my network. I can connect to the http://www.multiupload.com/ and www.megaupload.com.

[turbojet]

http://www.multiupload.com/4VD6462M7L

[schweinsz]

http://www.multiupload.com/4VD6462M7L

Ok, I get it now, thank you very much.

[turbojet]

Your welcome. DiAVC doesn't seem to have a problem with it, the only decoder I know of that does is CoreAVC. I don't know if out of spec mv's is still prominent in Paramount BD's but at one point I ran across 3 within a month of retail, stopped using coreavc after that so I don't know.

[VFR maniac]

Could you share me such a bitstream?

A timestamp shifting sample I encoded with x264.nl's x86 rev1347 and muxed as VFR MP4 is here.
http://www.megaupload.com/?d=CCKL7TY8
pass: bugreport@vfrmaniac
(Sorry, I encrypted the sample because megaupload do not approve file deletion.)

Timestamp shifting stands out remarkably around 00:56.
Other AVC decoders do not reproduce this.
This issue is fatal for VFR videos with deduplication.

[LoRd_MuldeR]

Okay, I finally managed to get the latest DiAVC Alpha working on my system. And the results are quite impressive :eek:

E:\HD_Samples.CRF18.mkv

[ffdshow-MT r3135]
User: 8s, kernel: 0s, total: 8s, real: 40s, fps: 344.1, dfps: 69.7
User: 7s, kernel: 0s, total: 7s, real: 41s, fps: 363.3, dfps: 68.7 <-- 100%
User: 8s, kernel: 0s, total: 8s, real: 41s, fps: 347.4, dfps: 68.0

[CoreAVC v1.9.5, CPU]
User: 5s, kernel: 0s, total: 5s, real: 36s, fps: 532.7, dfps: 78.0
User: 5s, kernel: 0s, total: 5s, real: 36s, fps: 516.1, dfps: 76.6 <-- 111%
User: 5s, kernel: 0s, total: 5s, real: 37s, fps: 532.7, dfps: 76.3

[CoreAVC v1.9.5, CUDA]
User: 7s, kernel: 2s, total: 8s, real: 84s, fps: 293.0, dfps: 33.4
User: 8s, kernel: 2s, total: 9s, real: 84s, fps: 274.0, dfps: 33.4 <-- 49%
User: 8s, kernel: 2s, total: 9s, real: 85s, fps: 274.0, dfps: 33.3

[DivX Decoder v1.1]
User: 5s, kernel: 0s, total: 5s, real: 31s, fps: 481.9, dfps: 88.9
User: 6s, kernel: 0s, total: 6s, real: 31s, fps: 456.4, dfps: 88.6 <-- 129%
User: 7s, kernel: 0s, total: 7s, real: 32s, fps: 387.3, dfps: 88.0

[DiAVC Alpha]
User: 5s, kernel: 0s, total: 5s, real: 29s, fps: 488.3, dfps: 97.1
User: 5s, kernel: 0s, total: 5s, real: 29s, fps: 499.1, dfps: 96.7 <-- 141%
User: 5s, kernel: 0s, total: 5s, real: 29s, fps: 481.9, dfps: 96.4

[M$ DTV-DVD Video Decoder]
User: 0s, kernel: 0s, total: 0s, real: 44s, fps: 45416.4, dfps: 63.7
User: 0s, kernel: 0s, total: 0s, real: 44s, fps: 36333.1, dfps: 63.6 <-- 92%
User: 0s, kernel: 0s, total: 0s, real: 46s, fps: 90832.8, dfps: 60.4

[Cyber-Mav]

my word thats a massive speed advantage going to diavc. lord mulder what system spec was that tested on?

[LoRd_MuldeR]

my word thats a massive speed advantage going to diavc. lord mulder what system spec was that tested on?

You see "My specs" in my sig? ;)

[Cyber-Mav]

yes i saw that the q6600 pc, i just thought you may have run those test on a different computer. is diavc stable in its image output? does it artifact at all or is it ok to use as a primary decoder even though its in alpha stage?

[LoRd_MuldeR]

There are no visible artifacts in my test clip. However I didn't check whether the output is bit-identical to other decoders.

[schweinsz]

yes i saw that the q6600 pc, i just thought you may have run those test on a different computer. is diavc stable in its image output? does it artifact at all or is it ok to use as a primary decoder even though its in alpha stage?

The DiAVC output the bit-by-bit accurate frames with the JM decoder. I encode bitstreams with jm and verified the output using JM when I developed the DiAVC.
I verify all conformance clips in the H.264 official site. There do exists one problem with the DiAVC. When there are multi slices with different slice type (P slice and others) in one picture, the DiAVC has a deblock problem with BS=1, but it influence little (about within[-2,2]), and I believe there exist hardly this bitstream in the world.

[rack04]

Here are my test results:

[ffdshow-MT r3135]
User: 1s, kernel: 0s, total: 1s, real: 54s, fps: 2715.4, dfps: 92.9
User: 1s, kernel: 0s, total: 2s, real: 54s, fps: 2485.7, dfps: 91.8

[DiAVC Alpha]
User: 5s, kernel: 0s, total: 5s, real: 31s, fps: 845.9, dfps: 159.6
User: 5s, kernel: 0s, total: 6s, real: 31s, fps: 822.2, dfps: 160.0


Will ffdshow output settings alter the results of the dfps? The reason I ask is because I have ffdshow video set to "High Quality YV12 to RGB Conversion" which may be effecting the dfps.

[schweinsz]

Okay, I finally managed to get the latest DiAVC Alpha working on my system. And the results are quite impressive :eek:

Great news, the DiAVC will be much faster than it is now especially for new CPU with SSSE3.

[LoRd_MuldeR]

Will ffdshow output settings alter the results of the dfps? The reason I ask is because I have ffdshow video set to "High Quality YV12 to RGB Conversion" which may be effecting the dfps.

I guess the Null renderer accepts everything. But you should allow ffdshow to output YV12, so no colorspace conversion is done inside ffdshow.

Needless to say that any filters inside ffdshow should be disabled as well ;)

[Cyber-Mav]

Great news, the DiAVC will be much faster than it is now especially for new CPU with SSSE3.

this is very impressive, have you looked into supporting older cpus that only have SSE1 such as the athlonxp etc?
thanks

[schweinsz]

this is very impressive, have you looked into supporting older cpus that only have SSE1 such as the athlonxp etc?
thanks
When I finished some more important works (such as speed improment, feature supports, 64-bit and super-resolution for SD contents), I can work on it. If 64-bit is very complex, I perhaps work on support for old cpu.

[Disabled]

I finally was able to get a windows computer to test this thing. Its a CoreDuo T2300 (1.66Ghz), WinXP SP3, 1 GB Ram, Intel GMAsomething. Benches were done using monograms GraphStudio benchmark, with 3-5 runs with null renderer. I also did comparisons with timecodec, while the numbers were a bit different, the trend was the same.
http://gamersyde.com/download_assassin_s_creed_2_missions-13631_en.html
720p, 60fps 10:52 minutes
ffdshow: 124.3667
DivX: 166.9982
CoreAVC: 165.1547
DiAVC: 180.8032

ADST_sample posted earlier
1080p, 23.976fps, 1:31 minutes
ffdshow: 40.2649
DivX: 54.5507
CoreAVC: 54.1513
DiAVC: 56.9768

ImperishableNightExtraStage.mp4 from DarkShikari
640x480, 60fps, 9:35 minutes
ffdshow: 225.7021
DivX: 340.6914
CoreAVC: 345.6809
DiAVC: 312.1756

So nice performance for me, also no artifacts were visible for all samples. I have the impression that the decoder needs a second to startup, that might have decreased the performance, especially for the last test, as that run the fastest.

[LoRd_MuldeR]

this is very impressive, have you looked into supporting older cpus that only have SSE1 such as the athlonxp etc?

http://forum.doom9.org/showpost.php?p=1345155&postcount=135
http://forum.doom9.org/showpost.php?p=1345311&postcount=137

[Stephen R. Savage]

Like Disabled, I noticed a startup delay when opening new videos. Hopefully this minor issue can be fixed. Another issue I noticed was that the filter is incompatible with DirectVobSub (VSFilter) if the video resolution is not mod16. The filter connects, but the video only shows a black frame (tested with MPC-HC/EVR Custom). Maybe this is a bug in DirectVobSub though.

On the bright side, I was able to measure the performance being consistently 10-15% higher than CoreAVC on my Core 2 Duo T7250. If the beta version can fix those issues and increase performance by 20% as schweinsz said, it will be perfect.

[Jaja1]

Very interesting. Your decoder works fine here for an alpha version. Searching is very slow though. I wonder, what does it output? YV12 Rec. 709?

[Keiyakusha]

Another issue I noticed was that the filter is incompatible with DirectVobSub (VSFilter) if the video resolution is not mod16. The filter connects, but the video only shows a black frame (tested with MPC-HC/EVR Custom).
What is exact resolution of the video you tested? Works for me with mod8 height (1920x1080 resolution).
EDIT: Yes with EVR-CP there is some problems with not showing subtitles, but the screen is not black for me. Will test some more too...

I have the impression that the decoder needs a second to startup, that might have decreased the performance, especially for the last test, as that run the fastest.
Ohh, when I tested the speed, my results also showed that DiAVC is not that fast with small SD videos, but I never thought about startup delay... Need to run some more tests.

[Avish]

How do I get it working with Haali Renderer? It works with all other renderers but when I try use it with Haali Renderer, it automatically changes back to just "Video Renderer". I'm on 64bit XP Pro, using 32bit MPC HC.

[Keiyakusha]

How do I get it working with Haali Renderer? It works with all other renderers but when I try use it with Haali Renderer, it automatically changes back to just "Video Renderer". I'm on 64bit XP Pro, using 32bit MPC HC.

You need to put some colorspace conversion filter after DiAVC but before renderer. FFDshow have a nice one.

Another issue I noticed was that the filter is incompatible with DirectVobSub (VSFilter) if the video resolution is not mod16. The filter connects, but the video only shows a black frame (tested with MPC-HC/EVR Custom).
OK, tested this thing a bit more. Yes I can confirm black screen but it shows picture if you do some seeking. What is wierd, if I do some seeking, close the player then when I open it - it works. If I close player and open again - black screen. This is what confused me...

[Stephen R. Savage]

What is exact resolution of the video you tested? Works for me with mod8 height (1920x1080 resolution).
EDIT: Yes with EVR-CP there is some problems with not showing subtitles, but the screen is not black for me. Will test some more too...

I am talking about mod8 width, e.g. 712x480. I am also not talking about the internal subtitle renderer which works just fine but about the standalone DirectVobSub. It produces a black frame when the width is not mod16 and it is receiving input from DiAVC.

[Keiyakusha]

I am also not talking about the internal subtitle renderer which works just fine but about the standalone DirectVobSub. It produces a black frame when the width is not mod16 and it is receiving input from DiAVC.
Yes. I understand this. By the way the post you quoted a bit outdated now. As I say I see black screen with mod8 height too, but it acts somewhat wierd. The sample I tested have some black frames at the beginning so at first I not noticed that player shows black screen and after seeking it starts to show normal image. Maybe i'll test mod8 width sometime later.

[turbojet]

I did some tests with MPC-HC 1351 on windows 7 x64. mkv files everything is ok except the aforementioned slow seeking.

But there's some issues with m2ts files.
Gabest MPEG splitter + DiAVC = double speed playback, crashes on seek
Haali media splitter + DiAVC = playback ok, crashes on seek

[schweinsz]

I am talking about mod8 width, e.g. 712x480. I am also not talking about the internal subtitle renderer which works just fine but about the standalone DirectVobSub. It produces a black frame when the width is not mod16 and it is receiving input from DiAVC.

Do I need force the width and height mod 16 when require memory from the DirectVobSub if the width or height not mod 16?

[schweinsz]

A new version is available at http://di-avc.com/DiAVC_alpha.zip.
Changes:
Faster start and seek
Fix the timestamp position shifting for repeated streams PROBABILY

[hxhxd]

schweinsz, could you post a change log or update date in you website?

[Stephen R. Savage]

Do I need force the width and height mod 16 when require memory from the DirectVobSub if the width or height not mod 16?

I am actually unsure how DirectVobSub works. It is pretty buggy in general, and even if mod8 worked, mod4 surely wouldn't. When you "force the width and height mod 16," does that imply a resize operation? Perhaps you could study how ffdshow connects to DirectVobSub, as I (think) it can deliver a mod8 image to it successfully.

[Shinigami-Sama]

When you "force the width and height mod 16," does that imply a resize operation

how about adding padding?

[VFR maniac]

Fix the timestamp position shifting for repeated streams PROBABILY

Still broken...

[schweinsz]

I am actually unsure how DirectVobSub works. It is pretty buggy in general, and even if mod8 worked, mod4 surely wouldn't. When you "force the width and height mod 16," does that imply a resize operation? Perhaps you could study how ffdshow connects to DirectVobSub, as I (think) it can deliver a mod8 image to it successfully.

I just add padding. I have gotten the black screen if the directvobsub is used even the width and height mod 16. I am finding the reason.

[schweinsz]

A new alpha version is available at http://di-avc.com/DiAVC_alpha.zip.

Change log:
fixed the compability problem with directVOBSUB.
fixed some problems in the filter
Improved supports to VFR samples

[VFR maniac]

Uhh, play->stop->play causes confused presentation, and still broken about repeated VFR.

Edit: When seeking sample, these problems disappear.

[schweinsz]

Uhh, play->stop->play causes confused presentation, and still broken about repeated VFR.

Edit: When seeking sample, these problems disappear.


I can't understand the "repeated VFR", I do find the video you share to me has several frames at about 56' that has a much more long presentation time than others, I fixed the start presentation time and end presentation time for them.
I compared the start presentation time and end presentation time with coreavc, and I found all start presentation time is same, the DiAVC set the end presentation time = start presentation time of next frame, but coreavc use the time gotten from samples. IMHO, I think the DiAVC is better.

[VFR maniac]

Player: WMP11, MediaPlayerClassic HomeCinema rev1369 built by alexins, and graphedit

Graph:
VFR source sample -(video)-> DiAVC -> Video renderer (VMR7 renderless)
　　　　　　　　　　　　　　　-(audio)-> ffdshow audio decoder -> Reclock 1.8.4.8

Snapshots of ffdshow OSD: [Compare_both_timstamps]Sample_of_timestamp_shift_for_DiAVC(VFR_Anime_OP).mp4.rar (http://www.megaupload.com/?d=0NB4HCIG)

[schweinsz]

Uhh, play->stop->play causes confused presentation.
Fixed the problem, a new version is uploaded to http://di-avc.com/DiAVC_alpha.zip. This is a bug in the filter that is introduced when I fixed the directvobsub. Great thanks to you. I will fix the problem related to the VFR bitstreams according to your information.

[VFR maniac]

But I still can't understand your broken VFR frames, do you mean the frames is displayed later than it should be, or earlier than it should be, or it should be displayed repeatly?
I mean the frames is displayed later than it should be in case of this sample.

[schweinsz]

I mean the frames is displayed later than it should be in case of this sample.
Ok, I will fix the problem tomorrow.

[VFR maniac]

Fixed the problem, a new version is uploaded to http://di-avc.com/DiAVC_alpha.zip. This is a bug in the filter that is introduced when I fixed the directvobsub. Great thanks to you. I will fix the problem related to the VFR bitstreams according to your information.
Aha, it seems the new version is fixed about repeated VFR streams.
I'll test more.

Edit: Oh, the new version works fine at many VFR videos I encoded. Apparently, timestamp shifting problem was solved.
It's great work. Thank you.

[schweinsz]

Aha, it seems the new version is fixed about repeated VFR streams.
I'll test more.

Edit: Oh, the new version works fine at many VFR videos I encoded. Apparently, timestamp shifting problem was solved.

Ok, good news, I will try to release the beta version, fixing bugs take up many of my time.

[VFR maniac]

Before releasing the beta version, could you fix this problem?

I found other bugs:
1. DiAVC cannot connect stream in WMP11, though DiAVC set as default decoder with DiAVCSetting.exe.
But DiAVC can connect it after changing the merit value into 0xff80000X with another merit value changer.

And I found a new bug.
Whenever seeking the stream in DiAVC+madVR, the timstamps are shifted from original.
DiAVC+madVR is still unstable. Also the following issue is not fixed.
when you stop playing, it runs through CPU usage rate unless restarting the movie or closing the player.

[turbojet]

Any news on the playback issues/crashes with m2ts/ts files?

m2ts are bluray and ts are used for video captures so people are encountering these a lot unless they are obtaining things illegally or using dvd sources.

[schweinsz]

I did some tests with MPC-HC 1351 on windows 7 x64. mkv files everything is ok except the aforementioned slow seeking.

But there's some issues with m2ts files.
Gabest MPEG splitter + DiAVC = double speed playback, crashes on seek
Haali media splitter + DiAVC = playback ok, crashes on seek

I can't re-produce the issue with my samples (for examples, downloaded from http://x264.nl/h.264.samples/) using MPC-HC 1.3.1249.0. Could you share me some such samples? I am lack of the m2ts samples. You can try the DiAVC now, I fixed some bugs in the filter recently, perhaps the crash-related bug is fixed.

[schweinsz]

Any news on the playback issues/crashes with m2ts/ts files?

m2ts are bluray and ts are used for video captures so people are encountering these a lot unless they are obtaining things illegally or using dvd sources.
Ok, I download some samples at http://www.cccp-project.net/beta/test_files/ and get the crash, I will fix it recently.

[adam777]

First of all, great work, schweinsz, I've used DiAVC for the last 2 weeks or so, and am very happy with it.
One problem, that was already mentioned, I believe, is the decoder doesn't seem to work with EVR custom.
Trying the above combination results in a black screen with only audio playing.
As I normally use madVR, it's not such a big problem, but would probably need to be fixed in future releases.
Thank again for your work, Adam.

[turbojet]

Ok, I download some samples at http://www.cccp-project.net/beta/test_files/ and get the crash, I will fix it recently.

Thanks, maybe whatever is causing it is causing the seek delays too.

First of all, great work, schweinsz, I've used DiAVC for the last 2 weeks or so, and am very happy with it.
One problem, that was already mentioned, I believe, is the decoder doesn't seem to work with EVR custom.
Trying the above combination results in a black screen with only audio playing.
As I normally use madVR, it's not such a big problem, but would probably need to be fixed in future releases.
Thank again for your work, Adam.

It works for me with EVR CP on Windows 7 x64. Are you using Vista or 7 and have the latest directx runtime (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3) installed?


I'm having problems setting DiAVC as preferred decoder on XP x86. It's a Q6600 with ffdshow the only other avc decoder installed and haali. If I disable ffdshow and open an avc m2ts/ts/mkv file in graphstudio a video decoder can't be found. However if I make a graph with haali+diavc it works for avisynth but it refuses to connect to video renderer, I can also set it to prefer in MPC-HC and it works. I've tried setting as preferred decoder in diavcsettings and changing to highest merit with graphstudio. Is anyone else experiencing this with XP or Vista? Any idea on how to set it to preferred?

With windows 7 its working fine.

[schweinsz]

Thanks, maybe whatever is causing it is causing the seek delays too.



It works for me with EVR CP on Windows 7 x64. Are you using Vista or 7 and have the latest directx runtime (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3) installed?


I'm having problems setting DiAVC as preferred decoder on XP x86. It's a Q6600 with ffdshow the only other avc decoder installed and haali. If I disable ffdshow and open an avc m2ts/ts/mkv file in graphstudio a video decoder can't be found. However if I make a graph with haali+diavc it works for avisynth but it refuses to connect to video renderer, I can also set it to prefer in MPC-HC and it works. I've tried setting as preferred decoder in diavcsettings and changing to highest merit with graphstudio. Is anyone else experiencing this with XP or Vista? Any idea on how to set it to preferred?

With windows 7 its working fine.

The current DiAVCSetting.exe works as follows: If the current default decoder is DiAVC, the DiAVCSetting.exe set a highest merit for DiAVC that is greater than 0xff800000.

[adam777]

It works for me with EVR CP on Windows 7 x64. Are you using Vista or 7 and have the latest directx runtime (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3) installed?


Weird, now it seems to be working part of the time.
At times I get black screen, at times the picture freeze and at times everything is normal (all of the above usually alternates when seeking).
I'm on Windows 7 x64 with everything up to date.

[mandarinka]

I recently reported a problem with video corruption using coreavc and attached two samples in this post: http://forum.doom9.org/showpost.php?p=1348040&postcount=5265
I decided I should check your decoder too, as it clearly shows some promise.

The good news is, DiAVC doesn't show the described video corruption and links the mkv segments fine if video width changes...

... the bad news: If height changes, the player will crash. That means that it crashes with the two samples I provided in the linked post. Your decoder however works with other linked videos I have (but didn't upload) that have constant height but changing width.

I don't know whether it's a design limitation or not, but in case it's just something simple to fix, I decided to report it. Also, best luck with the decoder ;)



PS: The videos decode fine individualy, the issues only happen when linking is performed - so for testing, haali splitter is required.

[schweinsz]

I recently reported a problem with video corruption using coreavc and attached two samples in this post: http://forum.doom9.org/showpost.php?p=1348040&postcount=5265
I decided I should check your decoder too, as it clearly shows some promise.

The good news is, DiAVC doesn't show the described video corruption and links the mkv segments fine if video width changes...

... the bad news: If height changes, the player will crash. That means that it crashes with the two samples I provided in the linked post. Your decoder however works with other linked videos I have (but didn't upload) that have constant height but changing width.

I don't know whether it's a design limitation or not, but in case it's just something simple to fix, I decided to report it. Also, best luck with the decoder ;)



PS: The videos decode fine individualy, the issues only happen when linking is performed - so for testing, haali splitter is required.

I am sorry that I can't connect to the mediafire allrough I noticed your report before. I don't know what is the problem with my network. Could you upload them to http://www.multiupload.com/ or www.megaupload.com?

[Disabled]

Here you are:
http://www.multiupload.com/6O2ESAXATD
http://www.multiupload.com/NOBIIIVN3Z

P.s.: Thanks for mentioning multiupload, it seems pretty good.

*edit* I missed his edit in that thread:
[Edit:] PPS: I tried this version of Diavc; it doesn't show the corruptions I was experiencing with coreavc and links fine if width of video changes, while for some reason crashing on height change (so not a complete pass).

[Stephen R. Savage]

Any news on the beta version? Also, I'm pretty sure I'll be waiting a long time for CoreCodec (zzz) to implement weighted prediction support, so I'd like to use DiAVC for most of my decoding. One of the first problems I encountered was that seeking seems to only succeed half the time. The other half, the audio keeps going, but the video freezes. Repeating the seek attempt multiple times eventually succeeds.

Edit: Another problem. When opening a new video while a video is already playing in MPC-HC, DiAVC starts with a blank frame and a seek must be performed before it shows video.

Edit2: I've already complained about it before, but there is still some noticeable initialisation delay.

Edit3: It also seems to me that, although DiAVC achieves a higher framerate and lower CPU usage, playback is choppier than with CoreAVC. When under load, DiAVC seems to drop frames more often than other Core.

Hopefully these problems can be fixed. Keep up the good work.

(Note: I'm using EVR Custom renderer on Intel GMA 3100.)

[schweinsz]

Any news on the beta version? Also, I'm pretty sure I'll be waiting a long time for CoreCodec (zzz) to implement weighted prediction support, so I'd like to use DiAVC for most of my decoding. One of the first problems I encountered was that seeking seems to only succeed half the time. The other half, the audio keeps going, but the video freezes. Repeating the seek attempt multiple times eventually succeeds.
I have fixed the problem and I'll release a bug-gixed alpha version recently.

Edit: Another problem. When opening a new video while a video is already playing in MPC-HC, DiAVC starts with a blank frame and a seek must be performed before it shows video.

Edit2: I've already complained about it before, but there is still some noticeable initialisation delay.

Edit3: It also seems to me that, although DiAVC achieves a higher framerate and lower CPU usage, playback is choppier than with CoreAVC. When under load, DiAVC seems to drop frames more often than other Core.

Hopefully these problems can be fixed. Keep up the good work.

(Note: I'm using EVR Custom renderer on Intel GMA 3100.)
Which player do you use? I will try to fix these problems.
I engaged in fixing bugs recently and the beta version is delayed for many days, the beta version will be released about 12 days later. I am not familar with the directshow and fixing bugs in filter is a hard work for me. It took up more times than I expected.

"Playback is choppier" is because that the coreavc can drop un-referenced frames adaptively while the DiAVC hasn't the feature when the bitstream is hard, I will add the feature in future. As the beta version is faster than alpha version, the problem is easier.

[squid_80]

"Playback is choppier" is because that the coreavc can drop un-referenced frames adaptively
No it doesn't...

[schweinsz]

No it doesn't...
To the best of my knowledge, the renderer chop is due to the late-arrived frames. The current disign of the DiAVC always copy decoded frames to renderers without considering the current time. I believe the problem of chop can be reduced by faster decoder (beta version), dropping non-reference frames and lower playback rate. Is there some other solutions of the problem?

[squid_80]

I don't know about a solution, I'm just pointing out that the CoreAVC filter doesn't ever drop any frames.

[Stephen R. Savage]

@schweinsz: I use MPC-HC v1.3 release. Thank you for looking into these issues.

And I sympathise. From what it looks like, all the bugs so far are in the DirectShow part and not the actual decoder.

[schweinsz]

I don't know about a solution, I'm just pointing out that the CoreAVC filter doesn't ever drop any frames.
The DiAVC achieve 22fps for a certain bitstream of 30mbps, PAFF and 24fps on my laptop while the coreavc achieve 19fps, but I found the DiAVC is choppier, there is no possibility that coreavc never drop frames.

[schweinsz]

@schweinsz: I use MPC-HC v1.3 release. Thank you for looking into these issues.

And I sympathise. From what it looks like, all the bugs so far are in the DirectShow part and not the actual decoder.
I have fixed most among them, I will release a new alpha version tomorrow after I fix another bug.

[tmbt]

Great work schweinsz ... im really impressed how good your codec works and actually i didn't notice any tearing or slow reproduction.


Thanks !!!!

[squid_80]

The DiAVC achieve 22fps for a certain bitstream of 30mbps, PAFF and 24fps on my laptop while the coreavc achieve 19fps, but I found the DiAVC is choppier, there is no possibility that coreavc never drop frames.
So how does DiAVC appear choppy if it can't drop frames? Shouldn't it just play slower than normal?

[Stephen R. Savage]

Some questions about (very) future development of DiAVC:

1) Is support for 4:2:2 or 4:4:4 subsampling, RGB coding, and higher bit depths (10-bit, 14-bit) planned?
2) Will that one bug that causes "maximum variance [-2,2]" in
"bitstream that hardly exist in the world" be fixed?
3) Can conversion to RGB be implemented in the DirectShow decoder? I ask this because only the decoder in DirectShow can know the VUI data and apply the correct color matrices (and color primaries, but that is less important). The same question goes for fullrange content.
4) Does DiAVC set the interlace flag on pictures with field coding? I have no interlaced content so I can not check this.

[schweinsz]

So how does DiAVC appear choppy if it can't drop frames? Shouldn't it just play slower than normal?
The DiAVC always try to copy all frames to the renderer. If the currrent bitstream is hard, when a piece of the bitstream contain high bitrate content, there is some frames arrived lately, this results a sudden delay of the renderer which is choppy.
A hard bitstream is not a uniform-hard bitstream, it is only hard on some piece of it.

[schweinsz]

Some questions about (very) future development of DiAVC:

1) Is support for 4:2:2 or 4:4:4 subsampling, RGB coding, and higher bit depths (10-bit, 14-bit) planned?
This is not in the current plan, the current plans are beta-version, error concealment, 64-bit, MC-based super-resolution and lossless sequently. If there is a big need of the High422, High444, I will work on it.

2) Will that one bug that causes "maximum variance [-2,2]" in
"bitstream that hardly exist in the world" be fixed?
I will fix it after beta version.


3) Can conversion to RGB be implemented in the DirectShow decoder? I ask this because only the decoder in DirectShow can know the VUI data and apply the correct color matrices (and color primaries, but that is less important). The same question goes for fullrange content.
I will add the RGB support after the first realease of the beta version.

4) Does DiAVC set the interlace flag on pictures with field coding? I have no interlaced content so I can not check this.
The current version always set Deinterlace_Bob for bitstreams that use interlace tools.

[squid_80]

The DiAVC always try to copy all frames to the renderer. If the currrent bitstream is hard, when a piece of the bitstream contain high bitrate content, there is some frames arrived lately, this results a sudden delay of the renderer which is choppy.
...And this is exactly what CoreAVC does. All frames from the incoming bitstream are delivered to the renderer.

[VFR maniac]

I may have found a new bug.
DiAVC's YV12 output is not bit-identical with other AVC decoders' except for DivX's.(DivX's AVC decoder still has deblocking issue.)
Here is a sample I encoded with x264.nl's rev1369.
http://www.megaupload.com/?d=Y69QJD0I
pass: bugreport@vfrmaniac

[schweinsz]

A new alpha version is available at http://di-avc.com/DiAVC_alpha.zip.
Changes:
fix the crash bug for some ts/m2ts contents.
Enhanced video/audio synchronization.
add queues for video renderers that are "RecieveCanBlock()==S_OK".

[schweinsz]

I may have found a new bug.
DiAVC's YV12 output is not bit-identical with other AVC decoders' except for DivX's.(DivX's AVC decoder still has deblocking issue.)
Here is a sample I encoded with x264.nl's rev1369.
http://www.megaupload.com/?d=Y69QJD0I
pass: bugreport@vfrmaniac
There do remain some deblock-related bugs for P frames, I will fix it recently.

[Stephen R. Savage]

Good work. Latest alpha version greatly reduces the seeking problem, though it can still fail occasionally (less than 5% here). There seems to be an audio glitch when seeking until the video catches up, but that is tolerable and within expectation. Choppy playback has also been greatly reduced. Tested on 480p60 and 1080p24 samples, and smoothness is now comparable to other decoders.

Still some initialization delay though.

However, there is one question I'd like to ask. Is implementing fully compliant deblocking a difficult or tricky task? I know that in the past, CoreAVC had many deblocking problems for several versions before they were fixed in v1.5.

Edit: It seems that the timestamp can drift by up to 1 frame, causing synchronization issues with subtitles.
Edit2: This seems to relate to seeking, and seeking again can make it drift back into place.

[schweinsz]

However, there is one question I'd like to ask. Is implementing fully compliant deblocking a difficult or tricky task? I know that in the past, CoreAVC had many deblocking problems for several versions before they were fixed in v1.5.
It is not difficult. It is just a history problem when I design the DiAVC in scratch. As VFR Maniac reported it, I will fix it today. As it only influence in some very special cases, so I delay to fix it.

Edit: It seems that the timestamp can drift by up to 1 frame, causing synchronization issues with subtitles.
Edit2: This seems to relate to seeking, and seeking again can make it drift back into place.
I will loop into it.

[chungkid1]

i got some probs with the h264 flv from youtube
http://i221.photobucket.com/albums/dd174/chungkid1/YouTube-Nightwish-Amaranthflv_snaps.jpg

[schweinsz]

i got some probs with the h264 flv from youtube
http://i221.photobucket.com/albums/dd174/chungkid1/YouTube-Nightwish-Amaranthflv_snaps.jpg
Could you provide the sample to me?

[Stephen R. Savage]

Report of possible problem: When using DiAVC as default decoder (set with DiAVCsettings.exe), VirtualDub hangs and stops responding when opening H.264 using the DirectShow input driver.

[Lam3rD]

DiAVC can't work with Winamp, either. It only shows black screen, while with the same decoder configurations it works with MPC-HC, I've only managed to simulate the problem in MPC-HC by changing the renderer to either of the 2 Null options. Switching back to ffdshow and both players work correctly, so I assume it might be a renderer problem.

OS is XP SP3 btw

[schweinsz]

I may have found a new bug.
DiAVC's YV12 output is not bit-identical with other AVC decoders' except for DivX's.(DivX's AVC decoder still has deblocking issue.)
Here is a sample I encoded with x264.nl's rev1369.
http://www.megaupload.com/?d=Y69QJD0I
pass: bugreport@vfrmaniac
I have fixed the all deblocking bugs today and the next alpha version will be correct.

Report of possible problem: When using DiAVC as default decoder (set with DiAVCsettings.exe), VirtualDub hangs and stops responding when opening H.264 using the DirectShow input driver.
DiAVC can't work with Winamp, either. It only shows black screen, while with the same decoder configurations it works with MPC-HC, I've only managed to simulate the problem in MPC-HC by changing the renderer to either of the 2 Null options. Switching back to ffdshow and both players work correctly, so I assume it might be a renderer problem.
OS is XP SP3 btw
The two problems are incured by unsupporting of the "FormatVideoInfo" perhaps, I will add it in the next alpha version.

[chungkid1]

@schweinsz: Here's the sample
http://www.mediafire.com/myfiles.php

[chungkid1]

Ah,sr about that.Here's the link
http://www.mediafire.com/?mznynonmmyl

[Keiyakusha]

Reuploaded chungkid1's sample so debugging can go faster. Since not everyone can access mediafire for some reason...
http://www.multiupload.com/1KFX3QIGLU
Also, this stream works for me. So far this problem appears only when DiAVC connected to MPC-HC's flv splitter.

[Stephen R. Savage]

@Keiyakusha: What other FLV splitters are there? The only one I know of is the Gabest version in MPC and FLVSplitter.ax.

[Selur]

Small question: Has anyone DiAVC running inside MPC-HC 64bit?

[namaiki]

afaik It's not built for 64-bit, so it shouldn't appear there.

[LigH]

Avira Premium Security Suite reports the installer to be the backdoor "BDS/MonoBot.K".

According to VirusTotal (http://www.virustotal.com/de/analisis/69b16db06fa91cb4ef0eb6b878fab2c7116f634221e6a3f11ff8953d4496bfc8-1260712570) (where Avira is reported as "AntiVir"), this happens for several more scanner engines (12/41), like Ikarus, Kaspersky, McAfee-GW, Symantec...

[Keiyakusha]

@Keiyakusha: What other FLV splitters are there?
Have no idea. But this doesn't mean there is no ways to extract the stream from the container ;)

[LoRd_MuldeR]

The problem (probably a FALSE POSITIVE) is in the "DiAVCSetting.exe" file (see Details (http://pastie.org/741282)). The actual AX file definitely is clean:
http://www.virustotal.com/de/analisis/98104ba865a586b3825b7144bfaf4327e9c7c1bdd8de0c84372e1c114235d248-1260713992

[yesgrey]

The problem (probably a FALSE POSITIVE) is in the "DiAVCSetting.exe" file (see Details (http://pastie.org/741282)). The actual AX file definitely is clean
I'm getting the same. Can we use only the AX file and simply delete the "DiAVCSetting.exe" file?

[LoRd_MuldeR]

I'm getting the same. Can we use only the AX file and simply delete the "DiAVCSetting.exe" file?

Sure. You can (un)register the filter manually:

regsvr32 diavc.ax
regsvr32 /u diavc.ax

Note that under Vista/Win7 this requires an elevated console!

[yesgrey]

Thanks.
Note that under Vista/Win7 this requires an elevated console!
Yes, I know that. I learned it the hard way, by searching for the error that appeared the first time I tried to register a file...;)

[Astrophizz]

I think this was discussed earlier in the thread. I think it was some means schweinz was taking to protect his code that can appear malicious... but I'm not sure.

[yesgrey]

I think this was discussed earlier in the thread. I think it was some means schweinz was taking to protect his code that can appear malicious... but I'm not sure.
The problem appears in the "DiAVCSetting.exe" file, and I don't think that he would want to protect the code of a program to register/unregister his filter. The AX file, what is supposed to be protected, does not show anything...

[Astrophizz]

Ah, you're right.

[Mixer73]

The problem appears in the "DiAVCSetting.exe" file, and I don't think that he would want to protect the code of a program to register/unregister his filter. The AX file, what is supposed to be protected, does not show anything...

Could the AV program be dumb enough to see something writing to registry as a threat?

[schweinsz]

I uploaded the source code of the DiAVCSetting.exe to di-avc.com. It is not a important part.
http://di-avc.com/DiAVCSetting_SourceCode.7z
It includes the following operations mainly:
Enum the directshow-based H.264 decoders
Change the merit of the H.264 decoders
Register and unregister the DiAVC
Verify the location of the DiAVC.ax

These is related to some registry modification, I don't know which part can mislead antivirus softwares.
The DiAVCSetting is safe, please use it safely.

[Selur]

@schweinsz: Any plans to make a 64bit build so DiAVC can be used in MPC-HD 64bit ?

[Virtual_ManPL]

The first P picture with poc=4 is almostly same with the preceding I picture with poc=0, if error concealment is done, the P picture will be recovered perfectly. the current DiAVC is without the error concealment and I will add it after beta version is released.

thx, will be nice to see it ;)



in other hand I find that seeking bug (you need to wait to see actual frames about 2-10s, sometimes even more than 20s) still exist in DiAVC decoder with EVR (C/A) in MPC-HC (1.3.1410.0)
other renderers works good (Haali & madVR not tested)

[LoRd_MuldeR]

I just got reply from Avira:

Dear Sir or Madam,

Thank you for your recent inquiry.

We could not find a virus in the attachment you have sent us.
This is a false positive. We will take out the pattern recognition in one
of our next updates.

We thank you for your assistance.

Attachment you sent:
- INFECTED_DIAVC.zip


--
Best regards
Avira GmbH

Tizian Cardinal von Widdern
First Level Support

Avira GmbH
Lindauer Str. 21, D-88069 Tettnang, Germany
Internet: http://www.avira.com

[schweinsz]

A new alpha version is available at http://di-avc.com/DiAVC_alpha.zip.
Changes:
fix all deblocking-ralated bugs (including multi-slice-type in one picture).
Add support for FORMAT_VideoInfo.

[schweinsz]

in other hand I find that seeking bug (you need to wait to see actual frames about 2-10s, sometimes even more than 20s) still exist in DiAVC decoder with EVR (C/A) in MPC-HC (1.3.1410.0)
other renderers works good (Haali & madVR not tested)
When I finished the error concealment, I will repair the problem.

[schweinsz]

@schweinsz: Any plans to make a 64bit build so DiAVC can be used in MPC-HD 64bit ?
After beta version, I will engage in error concealment, then I will consider the 64-bit and Motion-compensation-based super-resolution.

[LoRd_MuldeR]

A new alpha version is available at http://di-avc.com/DiAVC_alpha.zip.

Are you sure? The diavc.ax seems bit-identical to the 2009-12-11 release :confused:

[schweinsz]

Are you sure? The diavc.ax seems bit-identical to the 2009-12-11 release :confused:
I downloaded it and connect it with xvid encoder, and found the FORMAT_VideoInfo is supported, so it is the new version. The last version don't support it. Besides, the new version is 814KB, while I remeber the last version is 811KB.

[LoRd_MuldeR]

I downloaded it and connect it with xvid encoder, and found the FORMAT_VideoInfo is supported, so it is the new version. The last version don't support it. Besides, the new version is 814KB, while I remeber the last version is 811KB.

I cleared my browser chache and re-downloaded. Now I got the new version. Seems my browser made a fool of me. Sorry :o

[Stephen R. Savage]

The new alpha version does not fix the problems with VirtualDub. DiAVC no longer causes a hang, but VirtualDub now returns "file contains no video track" when using the DirectShow input.

[schweinsz]

The new alpha version does not fix the problems with VirtualDub. DiAVC no longer causes a hang, but VirtualDub now returns "file contains no video track" when using the DirectShow input.

I opened a h.264 file using the virtualdub, and found the ffdshow decoder was loaded, I want to watch some detail about it and use the graphstudio to connect to the remote graph but find none. How can I get more details about the filter chain used by virtualdub?

[LoRd_MuldeR]

VirtualDub normally uses VfW, not DirectShow. In order to enable DirectShow input, you need the DirectShow Input Driver plugin.

This is the latest version I found:
http://www.virtualdub.org/beta/DShowInputDriver-0.5.zip

[yesgrey]

The DiAVCSetting is safe, please use it safely.

I just got reply from Avira:

Thank you both.

[Stephen R. Savage]

Out of curiosity, what does the "Di" in "DiAVC" stand for?

[schweinsz]

How to set the DiAVC as the H.264 decoder for winamp? I draged the air.mp4 containing H.264 content to the winamp, and found nothing is out.

[LoRd_MuldeR]

Make sure that Winamp uses it's DirectShow plugin to decode your MP4 file. Not it's own MP4/AAC audio decoder plugin. Look in the preferences...

[Lam3rD]

How to set the DiAVC as the H.264 decoder for winamp? I draged the air.mp4 containing H.264 content to the winamp, and found nothing is out. The bug in DiAVC is not fixed, yet so it can't render in Winamp.

DO NOT use the latest version of winamp (5.57) where they've added their buggy splitters for everything. Use 5.56. Go to Preferences -> Plug-ins->Input. Open Nullsoft DirectShow Decoder, you would have a few file extensions there (MPG;MPEG;M2V;AVI) add MP4, MKV and whatever you like. Make sure you have direct show splitters/decoders for them. Use another AVC decoder until the bug in DiAVC is really fixed.

[Keiyakusha]

DO NOT use the latest version of winamp (5.57) where they've added their buggy splitters for everything. Use 5.56. Go to Preferences -> Plug-ins->Input. Open Nullsoft DirectShow Decoder, you would have a few file extensions there (MPG;MPEG;M2V;AVI) add MP4, MKV and whatever you like. Make sure you have direct show splitters/decoders for them. Use another AVC decoder until the bug in DiAVC is really fixed.

If schweinsz will use another decoder, DiAVC never will be fixed. Did you noticed that schweinsz is a DiAVC developer? :)

[Lam3rD]

Oh damn, my bad. :D

This is the way to go, except for using an alternative. Just make sure you don't use the latest build of Winamp, as their internal splitters break everything (at least with ffdshow) . If you need more info just let me know and I'll PM it to you.

[Mixer73]

This is the way to go, except for using an alternative. Just make sure you don't use the latest build of Winamp, as their internal splitters break everything (at least with ffdshow) . If you need more info just let me know and I'll PM it to you.

Honestly I wouldn't use Winamp for anything other than MP3.

Worst example of feature creep in a program ever, IMO!

[Lam3rD]

Winamp is a shitty player for movie/tv episode DVDs which are longer and require access to subtitles, multiple audio tracks etc, there is no need for 2nd opinion. However if you have a music DVD collection and prefer to keep and watch them on your PC with easy access to every single track you can't find anything better. It's also really fast to switch from video to audio in matter of seconds.

The point was not whether or not Winamp is a good player or not for all kinds of video needs, but that DiAVC doesn't work with Null Renderer which seem to be the one used in Winamp (and probably other programs).

[puffpio]

when i use diavc as my h264 decoder, cpu usage definately goes down, but subtitles no longer show up
I am using media player classic home cinema with the haali renderer and using haali media splitter to load a matroska file with subtitles

if I use mpc-hc's internal h264 decoder, or ffdshow, subtitles work..but w/ di-avc subtitles don't work..

[schweinsz]

when i use diavc as my h264 decoder, cpu usage definately goes down, but subtitles no longer show up
I am using media player classic home cinema with the haali renderer and using haali media splitter to load a matroska file with subtitles

if I use mpc-hc's internal h264 decoder, or ffdshow, subtitles work..but w/ di-avc subtitles don't work..

Some bitstreams will help. I am lack of this bitstream. Could you share me some such mkv files on http://www.megaupload.com/?

[schweinsz]

Winamp is a shitty player for movie/tv episode DVDs which are longer and require access to subtitles, multiple audio tracks etc, there is no need for 2nd opinion. However if you have a music DVD collection and prefer to keep and watch them on your PC with easy access to every single track you can't find anything better. It's also really fast to switch from video to audio in matter of seconds.

The point was not whether or not Winamp is a good player or not for all kinds of video needs, but that DiAVC doesn't work with Null Renderer which seem to be the one used in Winamp (and probably other programs).
Is the null renderer the nullsoft renderer? what is its exact name? I installed the winamp and I can't find some more renderer in graphstudio.

[namaiki]

when i use diavc as my h264 decoder, cpu usage definately goes down, but subtitles no longer show up
I am using media player classic home cinema with the haali renderer and using haali media splitter to load a matroska file with subtitles

if I use mpc-hc's internal h264 decoder, or ffdshow, subtitles work..but w/ di-avc subtitles don't work..

What exactly is supposed to be rendering the subtitles? VSFilter, MPC-HC's internal subtitle renderer?

[namaiki]

Is the null renderer the nullsoft renderer? what is its exact name? I installed the winamp and I can't find some more renderer in graphstudio.

Doesn't Null renderer = no renderer?

[Lam3rD]

Here is what ffdshow reports for the graph (top 2) http://i.imgur.com/u0qom.png . I think that this indicates to null renderer used, which is the name of one of the rendering filters written by Microsoft.
Use this filter when an output pin in the graph requires a downstream connection, but you do not wish to render the data from that pin. By connecting the output pin to the Null Renderer, you complete the connection without rendering the data.

Even though this filter does not render any samples, it does wait for each sample's presentation time before discarding the sample.
http://msdn.microsoft.com/en-us/library/dd390934%28VS.85%29.aspx

MPC-HC also supports this rendering method

[schweinsz]

Here is what ffdshow reports for the graph (top 2) http://i.imgur.com/u0qom.png . I think that this indicates to null renderer used, which is the name of one of the rendering filters written by Microsoft.

http://msdn.microsoft.com/en-us/library/dd390934%28VS.85%29.aspx

MPC-HC also supports this rendering method
But I even connect the DiAVC to the null renderer, it is ok. Actually the speed comparison listed above always uses the null renderer. Perhaps there is some configuration cases the DiAVC can not connect to the null renderer, I will look into it.

[LoRd_MuldeR]

In fact I can't get Winamp to use anything but CoreAVC to play H.264/AVC MKV files. If I runregister CoreAVC, it doesn't play at all...

[Lam3rD]

In fact I can't get Winamp to use anything but CoreAVC to play H.264/AVC MKV files. If I runregister CoreAVC, it doesn't play at all...

Dunno, it works flawless with ffdshow here. It might be caused by the new mixture of features/bugs introduced with version 5.57, but I mainly had audio problems there and for this reason I reverted back to 5.56, which entirely relies on the default directshow filters.

[LoRd_MuldeR]

Sorry, but I have zero interest to investigate this now. We really don't need a player as bloated with useless bling-bling as Winamp to use our DirectShow filters.

Even installing a new/different version of Winamp is pain, as you need to uncheck ~10 adware/agent/toolbar/whatever programs it wants to install and that always are checked by default :rolleyes:

[zn]

linux mplayer not supported?

[schweinsz]

linux mplayer not supported?
The windows application can't run on linux.

[LoRd_MuldeR]

The windows application can't run on linux.

Wine ;)

Also MPlayer has the ability to load certain (proprietary) decoder binaries, such as CoreAVC.

[Astrophizz]

Ok, since it seems that some people have gotten their hands on CoreAVC 2.0 and since BetaBoy doesn't seem to want comparisons with DiAVC in his thread (http://forum.doom9.org/showthread.php?p=1354668#post1354668) - can anyone compare them here? There have been two comparison posts in the CoreAVC thread but neither included DiAVC.

[Dark Shikari]

Ok, since it seems that some people have gotten their hands on CoreAVC 2.0 and since BetaBoy doesn't seem to want comparisons with DiAVC in his thread (http://forum.doom9.org/showthread.php?p=1354668#post1354668) - can anyone compare them here? There have been two comparison posts in the CoreAVC thread but neither included DiAVC.I would have compared with DiAVC but I wasn't able to get it to work at all on my system. It would timecodec, but it wouldn't actually play back any video, so I don't think the results of such a test would be trustworthy, so I didn't include it.

[schweinsz]

I would have compared with DiAVC but I wasn't able to get it to work at all on my system. It would timecodec, but it wouldn't actually play back any video, so I don't think the results of such a test would be trustworthy, so I didn't include it.
Do you use win7 64bit? I must buy a new computer recently.

[ranpha]

I have added the DiAVC results for the two video files in the CoreAVC thread. The result is impressive indeed. DiAVC and DiVX 7.2 can play that demanding vortex scene in Toki wo Kakeru Shoujo, which CoreAVC 1.9.5 and 2.0 software mode can't (that scene is playable in CUDA method) though.

[Dark Shikari]

Do you use win7 64bit? I must buy a new computer recently.Yes, win7 64-bit.

[namaiki]

hmm, I'm running W7 64-bit as well. I have been able to use DiAVC on my computer in MPC-HC 32bit, but I still get that issue where the video is stuck after seeking every so often.

[BetaBoy]

Ok, since it seems that some people have gotten their hands on CoreAVC 2.0 and since BetaBoy doesn't seem to want comparisons with DiAVC in his thread (http://forum.doom9.org/showthread.php?p=1354668#post1354668) - can anyone compare them here? There have been two comparison posts in the CoreAVC thread but neither included DiAVC.
Nope, not that at all. I welcome the comparison of 'fact's' not opinions for something that was not out... ie; schweinsz referenced both CoreAVC 2.0 and his alpha.

[BetaBoy]

schweinsz... on a side note... you do realize that even though you are not selling Diavc, and you are not open source that the MPEGLA AVC license will hold you accountable for 'each' download on your site right?

[schweinsz]

schweinsz... on a side note... you do realize that even though you are not selling Diavc, and you are not open source that the MPEGLA AVC license will hold you accountable for 'each' download on your site right?
That is only a TRIAL version just like you release the coreavc version0.71 on the autumn in 2005. I will sell the DiAVC next month.

[Astrophizz]

Nope, not that at all. I welcome the comparison of 'fact's' not opinions for something that was not out... ie; schweinsz referenced both CoreAVC 2.0 and his alpha.

Oh, my bad, I misinterpreted it.

Thanks, ranpha!

[BetaBoy]

That is only a TRIAL version just like you release the coreavc version0.71 on the autumn in 2005. I will sell the DiAVC next month.
Read the license... you are not distributing a 'trial'. The definition of what constitutes a trial is very clear in the AVC license (Our initial versions we accounted for each download and paid for, as should you) and for what its worth.... My suggestion is to first get legal advise, second contact MPEGLA.

[schweinsz]

Read the license... you are not distributing a 'trial'. The definition of what constitutes a trial is very clear in the AVC license (Our initial versions we accounted for each download and paid for, as should you) and for what its worth.... My suggestion is to first get legal advise, second contact MPEGLA.
Ok, I will fix all patent-related issues. This is not a problem.

[Astrophizz]

The fees only kick in at 100k "units", right?

[Dark Shikari]

The fees only kick in at 100k "units", right?This is correct. However, technically, you have to contact them for a license regardless (even if you don't end up paying anything).

[Astrophizz]

Ah, I suppose that makes sense.
http://coderhump.com/wp-content/uploads/2008/12/the_more_you_know2-300x197.jpg

[Cyber-Mav]

sussed out how to get timecodec to work and here are my results:

cpu = q9650 3.6ghz, 8gb ddr3 ram, vista ultimate 64bits

720x304 SD 1mbit clip

coreavc cuda 1.9.5
null User: 2s, kernel: 1s, total: 3s, real: 16s, fps: 1362.9, dfps: 322.3

divx
null User: 0s, kernel: 0s, total: 0s, real: 4s, fps: 6654.1, dfps: 1112.7

coreavc 1.9.5
null User: 1s, kernel: 0s, total: 1s, real: 4s, fps: 4918.2, dfps: 1073.8

diavc alpha
null User: 1s, kernel: 0s, total: 1s, real: 4s, fps: 3003.2, dfps: 1108.9

720p 2.5mbit
Coreavc 1.9.5
null User: 2s, kernel: 0s, total: 2s, real: 11s, fps: 2177.1, dfps: 542.8

Divx
User: 4s, kernel: 0s, total: 4s, real: 10s, fps: 1443.8, dfps: 606.0

diavc alpha
User: 4s, kernel: 0s, total: 5s, real: 10s, fps: 1243.1, dfps: 633.0

720p 5.7mbit
coreavc 1.9.5
User: 3s, kernel: 0s, total: 3s, real: 14s, fps: 1861.7, dfps: 473.0

divx
User: 4s, kernel: 0s, total: 4s, real: 13s, fps: 1380.1, dfps: 498.3

diavc alpha
User: 4s, kernel: 0s, total: 5s, real: 12s, fps: 1283.0, dfps: 525.2


1080p 4.5mbit
coreavc 1.9.5
User: 10s, kernel: 0s, total: 11s, real: 27s, fps: 741.5, dfps: 297.1

divx
User: 13s, kernel: 0s, total: 13s, real: 27s, fps: 603.8, dfps: 301.9

diavc alpha
User: 13s, kernel: 0s, total: 14s, real: 25s, fps: 574.7, dfps: 315.4

[Cyber-Mav]

this is what people may be interested in the most, results done on my laptops pentium M740 cpu which is a single core 1.73ghz cpu that supports up to sse2. windows 7 professional 32bit 2gig ram.

SD video 1mbit

coreavc 1.9.5
User: 23s, kernel: 0s, total: 23s, real: 23s, fps: 228.0, dfps: 224.7

Divx
User: 21s, kernel: 0s, total: 21s, real: 22s, fps: 241.7, dfps: 236.6

diavc alpha
User: 2s, kernel: 0s, total: 3s, real: 26s, fps: 1711.2, dfps: 201.2

720p 2.5mbit
coreavc 1.9.5
User: 92s, kernel: 0s, total: 92s, real: 92s, fps: 69.6, dfps: 69.3

Divx
User: 91s, kernel: 0s, total: 91s, real: 91s, fps: 70.4, dfps: 70.0

diavc alpha
User: 9s, kernel: 1s, total: 10s, real: 94s, fps: 619.6, dfps: 67.8

720p 5.7mbit
coreavc
User: 111s, kernel: 0s, total: 111s, real: 112s, fps: 61.2, dfps: 60.5

divx
User: 108s, kernel: 0s, total: 108s, real: 109s, fps: 63.0, dfps: 62.5

diavc alpha
User: 9s, kernel: 1s, total: 11s, real: 119s, fps: 619.6, dfps: 57.0

1080p 4.5mbit
coreavc 1.9.5
User: 216s, kernel: 0s, total: 216s, real: 217s, fps: 37.7, dfps: 37.5

divx
User: 223s, kernel: 0s, total: 224s, real: 225s, fps: 36.5, dfps: 36.2

diavc alpha
User: 23s, kernel: 1s, total: 25s, real: 225s, fps: 325.5, dfps: 36.2



Diavc is the slowest decoder on this processor.

[vwpassion]

Does DiAVC support out of spec motion vectors? Am looking for an alternative to CoreAVC since it produces glitches with out of spec MV's. FFDshow works fine, though it's not nearly as fast as CoreAVC or DiAVC.

Forgive me if this question has been answered already.

[Dark Shikari]

Does DiAVC support out of spec motion vectors? Am looking for an alternative to CoreAVC since it produces glitches with out of spec MV's. FFDshow works fine, though it's not nearly as fast as CoreAVC or DiAVC.

Forgive me if this question has been answered already.CoreAVC 2.0 supports out of spec MVs now.

All other software decoders should be fine with out of spec MVs; the only reason CoreAVC pre-2.0 had a problem was because of the utterly insane way that it stored motion vectors. Most hardware decoders seem to be fine too, though with the notable exception of Sigma chips.

[Keiyakusha]

This (http://forum.doom9.org/showthread.php?p=1355267#post1355267) comparison by yesgrey3 looks interesting. Does DiAVC has (S)SSE3 optimizations or they still planned for beta?

[schweinsz]

This (http://forum.doom9.org/showthread.php?p=1355267#post1355267) comparison by yesgrey3 looks interesting. Does DiAVC has (S)SSE3 optimizations or they still planned for beta?
All ssse3 code were finished last month. It include luma and chroma motion compensation and buffer copying. It is never included in current version but will be included in the upcoming beta version.

[schweinsz]

Does DiAVC support out of spec motion vectors? Am looking for an alternative to CoreAVC since it produces glitches with out of spec MV's. FFDshow works fine, though it's not nearly as fast as CoreAVC or DiAVC.

Forgive me if this question has been answered already.
Yes, it is supported.

[the_corona]

Just wanted to say great job so far!

I have tested it for the first time just now on my HTPC and for almost all samples I tested it's usually the fastest, if only by a few percent really.

Only thing a bit annoying is slighly longer initialization time when opening a video.

Can't wait for the beta which I guess will be even faster? Can you estimate how much?

Also, I understand DiAVC will be payware, is that correct? I ask because on your homepage there is a link to the source.

Thnx

[LoRd_MuldeR]

There only are the sources of "DiAVCSettings.exe", a small configuration utility. They were published, because some AntiVirus programs triggered FALSE ALARMS with that file ;)

I don't think that the sources of DiAVC itself will be published. And the "BUY" button on their web-site clearly indicates that DiAVC is supposed to be payware...

[schweinsz]

Can't wait for the beta which I guess will be even faster? Can you estimate how much?

Also, I understand DiAVC will be payware, is that correct? I ask because on your homepage there is a link to the source.
Thnx
The beta version is definitely faster than the alpha. But the gain depends on the cpu. The cpu with ssse3 will be more positive.
The DiAVC will be a payware. But it will be cheap and all following improvements such as super-resolution, 64-bit and new features are free for customers.

[the_corona]

I see, thnx for that.

Luckily my Core Duo (not Core 2 Duo) in the HTPC seems to support SSE3, so that's good.

SuperResolution you say? So...Fancy Resizing? Stuff like FFDShow has?

Looking forward to the Beta...if it's about the price of other decoders it's fine with me :-)

[LoRd_MuldeR]

Usually "SuperResolution" means that instead of one expensive "high resolution" camera we use several cheap "low resolution" cameras. Then we combine several "low resolution" shots to one "high resolution" picture by using a fancy SuperResolution algorithm. The result will (hopefully) be much better than just upscaling a single "low resolution" shot. However in the case of DiAVC I think the "SuperResolution" simply refers to a fancy upscaling method, because we only have one single "shot" of each frame. Maybe something like Edge-Directed Interpolation (http://chiranjivi.tripod.com/EDITut.html) or tritical's NNEDI filter.

[schweinsz]

I see, thnx for that.

Luckily my Core Duo (not Core 2 Duo) in the HTPC seems to support SSE3, so that's good.

SuperResolution you say? So...Fancy Resizing? Stuff like FFDShow has?

Looking forward to the Beta...if it's about the price of other decoders it's fine with me :-)
It is SSSE3 not SSE3. Core Duo not supports SSSE3. SuperResolution is enlarging the current picture to display and motion-compensation-based SuperResolution can improve the picture quality greatly.
I just google it and get the following link, there is some pictures at the end of that paper.
http://graphicon.ru/oldgr/en/publications/text/Video%20Super-Resolution%20Using%20Motion%20Compensation%20and%20Classification-Aided%20Fusion.pdf

[LoRd_MuldeR]

I just google it and get the following link, there is some pictures at the end of that paper.
http://graphicon.ru/oldgr/en/publications/text/Video%20Super-Resolution%20Using%20Motion%20Compensation%20and%20Classification-Aided%20Fusion.pdf

Ah, interesting. So in this scenario several consecutive "low resolution" images are combined to a "high resolution" image by using Motion Compensation.

Do you have any sample clips on how this looks with "real life" footage and in motion?

[schweinsz]

Ah, interesting. So in this scenario several consecutive "low resolution" images are combined to a "high resolution" image by using Motion Compensation.

Do you have any sample clips on how this looks with "real life" footage and in motion?
No, I designed most of the algorithms last month but I have not implemented it.

[canTsTop]

How about DiAVC decoder support for DGAVCDec?

[the_corona]

It is SSSE3 not SSE3. Core Duo not supports SSSE3. SuperResolution is enlarging the current picture to display and motion-compensation-based SuperResolution can improve the picture quality greatly.
I just google it and get the following link, there is some pictures at the end of that paper.
http://graphicon.ru/oldgr/en/publications/text/Video%20Super-Resolution%20Using%20Motion%20Compensation%20and%20Classification-Aided%20Fusion.pdf

Ah, sorry I misread you. In that case....too bad :-( Still, looking forward to it.

Ah, interesting. So in this scenario several consecutive "low resolution" images are combined to a "high resolution" image by using Motion Compensation.

Do you have any sample clips on how this looks with "real life" footage and in motion?

That is highly interesting....but the pessimist in me thinks it wont work nearly as good as the samples for most cases and it'll be just too slow. I'm really hoping u prove otherwise of course! :-)

Edit: BTW, while super resultion might be useful, many people watch mainly HD stuff anyways and since their panel can't display anything higher it's perhaps not that useful. Now Motion-Compensated-Frame-Interpolation on the other hand.....

I know, I'm just dreaming....but I would def. pay a premium for that one :-)

[Blue_MiSfit]

@CanTsTop:

How about DiAVC decoder support for DGAVCDec?


Erm.. I don't think so. DGAVCDec is neuron2's baby, and it uses libavcodec for H.264 decoding. I don't think he would want to use DiAVC, considering it's not open-source, and uses DirectShow. :p

You're a little confused :)

~MiSfit

[LoRd_MuldeR]

Well, it seems Neuron2 isn't very happy with libavcodec!

The latest version of DGAVCDec still used an old outdated version libavcodec (one that is broken with various samples), because all newer versions of libavcodec have frame-accuracy problems.

If I remember correctly, there even were plans to make DGAVCDec use CoreAVC, as soon as CoreAVC exposes a suitable API. But now it seems that this won't happen, as CoreAVC won't offer such an API.

Therefore CanTsTop's question about DiAVC Decoder and DGAVCDec isn't completely absurd ;)

[squid_80]

If I remember correctly, there even were plans to make DGAVCDec use CoreAVC, as soon as CoreAVC exposes a suitable API. But now it seems that this won't happen, as CoreAVC won't offer such an API.
It won't be offered to a closed source project that violates the GPL, no.

[Astrophizz]

squid_80, no need to troll and dig up an old (and resolved) issue. It's OT anyways.

[schweinsz]

this is what people may be interested in the most, results done on my laptops pentium M740 cpu which is a single core 1.73ghz cpu that supports up to sse2. windows 7 professional 32bit 2gig ram.

The possible reason that DiAVC is slow for single-core cpu is due to the use of multi-threading. The current design of DiAVC simplily use threadNum=CoreNum+2, It hurts performance of single-core cpu probabily. I believe that the old cpu has a bad support for the multi-threading. As threadNum=CoreNum+2, I simplily set it and never test if is most efficient.
Besides, the DiAVC never uses any mmx code, it only uses sse2 code. as Dark Shikari said, it hurts performance for old cpu.

[honai]

It won't be offered to a closed source project that violates the GPL, no.

Sales numbers of CoreAVC must be really bad. ;) I for one welcome competition. It benefits the consumer. Period.

[Dark Shikari]

Sales numbers of CoreAVC must be really bad. ;) I for one welcome competition. It benefits the consumer. Period.How is DGAVCDec competition to CoreAVC?

They don't even do the same thing.

[honai]

You misunderstood me. I was refering to the fact that yet another employee of CoreCodec comes into this thread to divert the topic yet another time with FUD.

Or do you think that discussions about alleged GPL violations of some software (oh the irony) are relevant to the discussion of DiAVC's technical merits? If so, please tell.

[Dark Shikari]

You misunderstood me. I was refering to the fact that yet another employee of CoreCodec comes into this thread to divert the topic yet another time with FUD.

Or do you think that discussions about alleged GPL violations of some software (oh the irony) are relevant to the discussion of DiAVC's technical merits? If so, please tell.Erm, did you even read the post?If I remember correctly, there even were plans to make DGAVCDec use CoreAVC, as soon as CoreAVC exposes a suitable API. But now it seems that this won't happen, as CoreAVC won't offer such an API.Someone commented that CoreAVC won't offer an API for DGAVCDec.It won't be offered to a closed source project that violates the GPL, no.And a CoreCodec employee explained why. It should have immediately ended there, but instead you chose to continue it in order to derail this thread.

The only one attempting to derail this thread is you, by continuing this off-topic discussion and making wild accusations towards other forum posters. If you, as you claim, support DiAVC, stop derailing this thread, now.

[LoRd_MuldeR]

It won't be offered to a closed source project that violates the GPL, no.

Sorry for the OT, but this makes no sense to me. Even if there was a GPL violation in DGAVCDec, which apparently is not the case, it would be irrelevant here. If CoreAVC did decide to add an API to their Filter, which allows third-party applications to access their decoder directly (that means: not through the DirectShow interface), then any application (ClosedSource or not!) could built on top of that API. Of course users would need to get both: The third-party application (which may be free software, Freeware, or Payware) plus the CoreAVC Decoder (which is Payware). But in reality we won't see this happen, because CoreAVC said they won't add such an API to their Decoder filter. Instead they license a SDK to software companies, which means that if a company decides to license CoreAVC, they can link it directly into their application.

About the (possible) GPL violation in DGAVCDec: Even if DGAVCDec remains CloseSource, it is still allowed to use libavcodec, because libavcodec is released under the LGPL, which explicitly allows that case. In other words: using a LGPL'd library from a proprietary application is explicitly permitted by the license. And dozens of proprietary application available on the market do it! Furthermore, from all that I know, Neuron2 never refused to publish the (minor) modifications he had made to libavcodec itself. And that's all he'd need to publish. So what exactly are you complaining about? I just can't see the point...

[dwrbudr]

Cannot install this decoder at all. When using regsvr32 it gives me an error message that "the application configuration is incorrect". WinXP SP3, 32bit.

[schweinsz]

Cannot install this decoder at all. When using regsvr32 it gives me an error message that "the application configuration is incorrect". WinXP SP3, 32bit.
Download the Microsoft Visual C++ 2008 Redistributable Package (x86) and install it, then try. It is the reason perhaps.
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en

[Guest]

Sorry for the OT, but this makes no sense to me. Agreed. If they want to withhold an SDK that can only increase their sales it seems like bad business to me. I don't know what their agenda is, but it doesn't appear to hold the interests of the video community very highly. I'm just going to keep doing my thing with the NV tools and ignore these wild GPL accusations and other attacks. It's all rather amusing actually.

I should be the least of their worries given the rapid progress of their competitors.

[dwrbudr]

I've installed it but now I cannot start timecodec or even DiAVCSetting.exe

http://i.imagehost.org/0788/Snap1_2.png (http://i.imagehost.org/view/0788/Snap1_2)
http://i.imagehost.org/0908/Snap2_5.png (http://i.imagehost.org/view/0908/Snap2_5)

[schweinsz]

I've installed it but now I cannot start timecodec or even DiAVCSetting.exe

http://i.imagehost.org/0788/Snap1_2.png (http://i.imagehost.org/view/0788/Snap1_2)
http://i.imagehost.org/0908/Snap2_5.png (http://i.imagehost.org/view/0908/Snap2_5)
This must be incured by false use of dll. I will fix it recently.

[schweinsz]

Agreed. If they want to withhold an SDK that can only increase their sales it seems like bad business to me. I don't know what their agenda is, but it doesn't appear to hold the interests of the video community very highly. I'm just going to keep doing my thing with the NV tools and ignore these wild GPL accusations and other attacks. It's all rather amusing actually.

I should be the least of their worries given the rapid progress of their competitors.
If you are willing to add support to DiAVC, I can export some more functions in the diavc.ax. It is so easy because ax is actually a dll.

[Guest]

If you are willing to add support to DiAVC, I can export some more functions in the diavc.ax. It is so easy because ax is actually a dll. That would be great. I'll get in touch with you by PM. Thanks for the offer.

[Dark Shikari]

What is the reason that DGAVCDec needs special API hooks? Is DirectShow not frame-accurate enough?

[Guest]

Is DirectShow not frame-accurate enough? Bingo. Also, I am then at the mercy of the specific decoder that is used. I can't guarantee proper random access if I can't control which decoder is used. Look at libavcodec these days. There's no way to use it for accurate frame access and there is effectively no support for that idea. I'm not complaining, just pointing out the reality. If schweinsz is willing to support the needed hooks, then it's a win for everybody, except maybe CoreAVC.

[Dark Shikari]

Bingo. Also, I am then at the mercy of the specific decoder that is used. I can't guarantee proper random access if I can't control which decoder is used. Look at libavcodec these days. There's no way to use it for accurate frame access and there is effectively no support for that idea.Have you looked at what FFMS2 does? It (AFAIK) can get reliable random access using libavcodec, albeit at the cost of an indexing pass.

Since DiAVC is going to become payware eventually, it would be preferable to have DGAVCDec work fully properly with the free solution (libavcodec). Obviously DiAVC support would still be great to have for speed purposes.

[Guest]

Since DiAVC is going to become payware eventually, it would be preferable to have DGAVCDec work fully properly with the free solution (libavcodec). Obviously DiAVC support would still be great to have for speed purposes. The problem is that my critical tracker defect (1592) remains unassigned. I can't do anything if libavcodec unpredictably discards frames. There's no support. Again, I'm not complaining. I know the response is "we're very busy; why don't you fix it?". That's what I call "no support".

[Atak_Snajpera]

Have you looked at what FFMS2 does? It (AFAIK) can get reliable random access using libavcodec, albeit at the cost of an indexing pass.
I tried FFMS2 and it failed. I have AVCHD footage (Canon HF200) and I wanted to apply 1/50 shutter emulation with Avisynth MT


SetMTMode(2,0)
video=FFMS2(sorce)
video=yadif(video,mode=0,order=1)

super = MSuper(video)
backward_vec = MAnalyse(super, isb = true)
forward_vec = MAnalyse(super, isb = false)
video=MFlowFps(video, super, backward_vec, forward_vec, num=200, den=1, ml=100)
a = selectevery(video,8, 0)
b = selectevery(video,8, 1)
c = selectevery(video,8, 2)
d = selectevery(video,8, 3)
ab = merge(a,b,0.5)
cd = merge(c,d,0.5)
video = merge(ab,cd,0.5)
return video


Without MT works well but it is slow as hell. I even tried SetMTMode(5,0) before and then SetMTMode(2) after decoder line. In both cases decoder was returning incorrect frames which lead sometimes to crashes. Even tried remuxing .MTS with eac3to to .mkv. The same problem

[Disabled]

I got some new benchmark results from the same processor as my old bench (http://forum.doom9.org/showthread.php?p=1347187#post1347187) with the same processor (CoreDuo 1.66Ghz) and the same samples. Its a different computer, so don't compare them directly, I downloaded the latest DiAVC and compared to CoreAVC2.0:

ac2_review_missions
CoreAVC 2.0: 158.7612
DiAVC 22.12.09: 179.9373

ADST_sample
CoreAVC 2.0: 55.5900
DiAVC 22.12.09: 56.5868

ImperishableNightExtraStage
CoreAVC 2.0: 353.3393
DiAVC 22.12.09: 318.9501

Of course, those are still GraphStudio benchmarks (3 runs each)...

[Blue_MiSfit]

@Atak_Snapjera:

Try using MT(...) instead of SetMTMode. I get much more stable results with it.

~MiSfit

[Atak_Snajpera]

@Blue_Shift
I tried to use MT on Yadif but I got "ghosting" artifacts (!?) :(
I'm not sure if MT with MVFlow is a good idea either.

[Blue_MiSfit]

Hmm... possibly. Did you use more than 2 threads? If so, I'd suggest using an overlap of at least 4 pixels.

~MiSfit

[BetaBoy]

Agreed. If they want to withhold an SDK that can only increase their sales it seems like bad business to me. I don't know what their agenda is, but it doesn't appear to hold the interests of the video community very highly. I'm just going to keep doing my thing with the NV tools and ignore these wild GPL accusations and other attacks. It's all rather amusing actually.

I should be the least of their worries given the rapid progress of their competitors.
You cannot want, what you cannot have. schweinsz better be very careful.... The IP agreement has strict rules the govern third party access and given you dont have an agreement yet with MPEGLA that could hurt your chances for approval.

neuron2... On access... don't point the finger this way as we are just the messengers on those restrictions. What we were trying to do however at one point with CoreAVC was trying to work through the process flow of 'approved access' for applications, but in the end, the legal costs are over the top for an effort that will return very little. But otherwise we have all of those API's is our current SDK but its only for OEM licensee's who then in-turn have a license through MPEGLA for their products or services.

As far as competitors, multimedia is just one aspect of our overall business, with CoreAVC being just one of many products (CorePlayer, Matroska, CoreUI, CoreOS, CoreMAKE, Corenect, CoreLua, etc.), but that's not for this thread.

[hxhxd]

I have same issus on ffms2 while reading xvid source. It really drop or add some frames. the workaround is avisource.

[Cyber-Mav]

I'm just going to keep doing my thing with the NV tools and ignore these wild GPL accusations and other attacks. It's all rather amusing actually.

do you have to pay for a licence and support for nvidia tools to use them in your apps?

[roozhou]

I have same issus on ffms2 while reading xvid source. It really drop or add some frames. the workaround is avisource.

Adding/dropping frame is caused by the limitation of avisynth but not a bug in libavcodec.

[hxhxd]

Adding/dropping frames is not a bug in libavcodec but caused by limitation of avisynth.

I don't think so. Using directshowsource with xvid decoder, I have no problem. But directshowsource + ffdshow, the problem happened again.

So I'm afraid libavcodec does cause the problem.

[Guest]

do you have to pay for a licence and support for nvidia tools to use them in your apps? Each machine needs a license so the end user can worry about that. I would allow distribution of my binaries if certain conditions are met. Follow up to PM please as it is getting OT for this thread.

[Guest]

Adding/dropping frames is not a bug in libavcodec but caused by limitation of avisynth. I beg to differ. What is this limitation you are talking about, please?

[roozhou]

I don't think so. Using directshowsource with xvid decoder, I have no problem. But directshowsource + ffdshow, the problem happened again.

So I'm afraid libavcodec does cause the problem.

This is a bug in DirectShowSource, which is a part of avisynth. ffdshow will never add/drop frames. Some demuxer or decoder may not report correct fps or video length before playing the video. This has no impact on TRUE dshow based application (e.g. a media player). You can change anything during playback including fps, duration, aspect ration and even resolution. However avisynth requires fixed fps, resolution, color space and clip duration reported before playing the video. DSS has to add/drop frames to match the fps and truncate or append dummy frames to match the duration.

[clsid]

ffdshow actually does have an option to drop frames. See options -> decoder options.

[Guest]

This is a bug in DirectShowSource, which is a part of avisynth I don't use DirectShowSource() in my dropped frames scenario. libavcodec is broken. I've confirmed it by tracing the code.

[hxhxd]

This is a bug in DirectShowSource, which is a part of avisynth. ffdshow will never add/drop frames. Some demuxer or decoder may not report correct fps or video length before playing the video. This has no impact on TRUE dshow based application (e.g. a media player). You can change anything during playback including fps, duration, aspect ration and even resolution. However avisynth requires fixed fps, resolution, color space and clip duration reported before playing the video. DSS has to add/drop frames to match the fps and truncate or append dummy frames to match the duration.
I've compared info using info() function between dss+xvid and dss+ffdshow, which both of them have the same variable values (fps, duration, etc). So I'm sure something worng with ffdshow.

[Fadeout]

Finally I can post and report this problem.

Everything seems to work fine on MPC Homecinema, but with DiAVC I get a delay on subtitles of about 375ms. It's especially noticeable on some anime where there are signs on screen whose translation/sub appear before the actual sign shows up but I think the delay applies to all movies.

No problem if the video goes through DXVA or another codec like CoreAVC.

Another request: I'd appreciate if like CoreAVC we got options to set custom brightness, contrast and such.

[Cyber-Mav]

Another request: I'd appreciate if like CoreAVC we got options to set custom brightness, contrast and such.

odd request, i would have thought that everyone on this forum would be at the very least be using a properly calibrated screen so that you never need to faff around with colour and brightness settings etc.

[LoRd_MuldeR]

An option to switch between "PC Levels" and "TV Levels" would be desired, because that's nothing you can achieve by calibrating your screen.

Also more color/brightness adjustment options may be helpful to "correct" certain movies.

Well, we can always insert ffdshow as a post-processing filter, but if the function was built-in, it would be much more convenient ;)

[LigH]

About the "SuperResolution feature":

scharfis_brain programmed something similar in AviSynth to "nicely blow up VCDs for DVD".

German doom9/Gleitz forum thread (http://forum.gleitz.info/showthread.php?t=23060)

An AVC decoder of course has the advantage of already knowing motion vectors.

[schweinsz]

DiAVC beta version 1 is released.

changes:
Improved decoding performance.
Add SSSE3 code.
add support for delta qp>26 in cavlc mode (It is supported all along for cabac mode).

I will fix the bugs related to the seeking and compatibility with other applications next.
There are still some rooms for decoding performance, and I will continue to improve it.

[Virtual_ManPL]

...
I will fix the bugs related to the seeking and compatibility with other applications next.
...
good to hear that ;p



also I find 2 bugs :D

1. Artifacts & sometimes green frames in some files, like this e.g.
http://www.mediafire.com/?emykqthjtj4
http://img691.imageshack.us/img691/923/67191844.th.png (http://img691.imageshack.us/i/67191844.png/)


2. Some files didnt want to start decoding in MPC-HC (1.3.1453.0) with Haali splitter (1.9.355.21) + your decoder (beta v1) (with Gabest internal splitters work good, also with Haali splitters+other h.264 decoder works too)
http://www.megaupload.com/?d=BM2DPIJM


...
Add SSSE3 code.
...
So which CPU optimizations are new having now including these MMX, 3DNow!, SSE, SSE2, SSE3, SSSE3, SSE4, SSE5, AVX, CVT16, FMA3, FMA4, XOP ? :devil:
nice will be what are he having now and which are you want to implant in the future, or course if it will boost up decoding...

[schweinsz]

good to hear that ;p

also I find 2 bugs :D

1. Artifacts & sometimes green frames in some files, like this e.g.
http://www.mediafire.com/?emykqthjtj4
http://img691.imageshack.us/img691/923/67191844.th.png (http://img691.imageshack.us/i/67191844.png/)

So which CPU optimizations are new having now including these MMX, 3DNow!, SSE, SSE2, SSE3, SSSE3, SSE4, SSE5, AVX, CVT16, FMA3, FMA4, XOP ? :devil:
nice will be what are he having now and which are you want to implant in the future, or course if it will boost up decoding...
Sorry that I can't connect to the mediafire, could you upload it to megaupload too?
Only SSE2 and SSSE3 exist now in DiAVC. There will be AVX, MMX in future.
If certain instruction set benefit the decoder, I will inplant it.

[Virtual_ManPL]

Sorry that I can't connect to the mediafire, could you upload it to megaupload too?

what a pain in the ass you got there :p
email MediaFire to unban your IP, or try talking to ISP if they ban some sites to unblock it :)
banning probably the best uploading website... maddens !!!


http://www.megaupload.com/?d=NF44K73H

[Disabled]

*edit* seconds to late... someone delete this post...

[yesgrey]

Here are my test results using an Intel E2160@2.7GHz with 1080p material:
ffdshow
User: 0s, kernel: 0s, total: 0s, real: 4s, fps: 479.6, dfps: 41.2
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 479.6, dfps: 54.2
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 647.4, dfps: 52.4

ffdshow-mt
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 719.4, dfps: 66.8
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 563.0, dfps: 67.4
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 588.6, dfps: 64.4

CoreAVC 1.9.5
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 719.4, dfps: 71.2
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 588.6, dfps: 73.2
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 616.6, dfps: 72.7

CoreAVC 2.0.0
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 498.0, dfps: 81.4
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 404.6, dfps: 81.9
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 462.5, dfps: 80.9

CoreAVC 2.0.0 (CUDA)
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 417.7, dfps: 62.6
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 498.0, dfps: 63.2
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 417.7, dfps: 63.5

DiAVC alfa
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 588.6, dfps: 81.9
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 681.5, dfps: 80.9
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 479.6, dfps: 82.5

DiAVC beta
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 539.5, dfps: 89.3
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 647.4, dfps: 90.5
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 761.7, dfps: 88.7

So the new optimizations give ~10% better performance.

[Fadeout]

Even with the beta there's still the "bug" with subtitles appearing 370ms or so too soon, as if the video is delayed. Same as previous versions.

[leeperry]

Here are my test results using an Intel E2160@2.7GHz with 1080p material:
[..]
So the new optimizations give ~10% better performance.
how much w/ the DivX decoder?

and that'd be interesting to measure the electricity consumption w/ a wattmeter...so we'd see if CUDA really has an edge over software decoding.

[Fadeout]

Is Graphstudio ok to measure performance? View -> Decoder Performance

With a 1080p clip at L5.1 on a Core 2 Duo E8400:
DiAVC beta: 81.3 FPS
DiAVC alpha: 72.6 FPS
CoreAVC 2: 63.0 FPS

Athlon 64 3500+:
DiAVC beta: crashes!
DiAVC alpha: 24.6 FPS
CoreAVC 2: 22.3 FPS

But on the Athlon 64 the actual use shows a very slightly lower CPU usage fore CoreAVC and it seems to behave better overall, so I don't know.

[schweinsz]

Give my speed comparison.
Same sequences with the last comparison.
http://forum.doom9.org/showthread.ph...02#post1334702

My laptop: Core Duo T2350@1.86GHz, 1G RAM, FSB533MHz
DiAVC=DiAVC beta version 1
coreavc=coreavc2.0
timecodec, null renderer

air.mp4: 1920x1080, 5.2Mbps
DiAVC: User: 7s, kernel: 0s, total: 7s, real: 29s, fps: 286.9, dfps: 76.0
DIVX: User: 9s, kernel: 0s, total: 9s, real: 30s, fps: 245.4, dfps: 72.5
CoreAVC: User: 6s, kernel: 0s, total: 6s, real: 29s, fps: 339.5, dfps: 74.6

assembly.mp4: 1920x832, 5.5Mbps
DiAVC: User: 6s, kernel: 0s, total: 6s, real: 39s, fps: 379.3, dfps: 66.0
DIVX: User: 6s, kernel: 0s, total: 6s, real: 44s, fps: 397.5, dfps: 58.7
CoreAVC: User: 5s, kernel: 0s, total: 5s, real: 43s, fps: 450.4, dfps: 59.5

blue ray.mp4: 1920x1080, 22.9Mbps
DiAVC: User: 3s, kernel: 0s, total: 3s, real: 21s, fps: 303.3, dfps: 48.2
DIVX: User: 3s, kernel: 0s, total: 3s, real: 22s, fps: 287.2, dfps: 44.4
CoreAVC: User: 2s, kernel: 0s, total: 2s, real: 21s, fps: 381.7, dfps: 46.2

deep blue.mp4: 1440x1080, 18.9Mbps
DiAVC: User: 2s, kernel: 0s, total: 2s, real: 20s, fps: 353.1, dfps: 38.7
DIVX: User: 6s, kernel: 0s, total: 6s, real: 23s, fps: 118.0, dfps: 34.2
CoreAVC: User: 1s, kernel: 0s, total: 1s, real: 20s, fps: 469.7, dfps: 38.3

goldcurse2.mkv: 1920x1080, 29.3Mbps
DiAVC: User: 10s, kernel: 0s, total: 11s, real: 78s, fps: 278.0, dfps: 39.4
DIVX: User: 12s, kernel: 0s, total: 12s, real: 86s, fps: 250.2, dfps: 35.8
CoreAVC: User: 9s, kernel: 0s, total: 9s, real: 83s, fps: 338.0, dfps: 36.9

planet earth.mp4: 1920x1080, 11.7Mbps
DiAVC: User: 13s, kernel: 0s, total: 14s, real: 84s, fps: 295.3, dfps: 49.5
DIVX: User: 15s, kernel: 0s, total: 15s, real: 101s, fps: 264.0, dfps: 41.3
CoreAVC: User: 12s, kernel: 0s, total: 12s, real: 95s, fps: 330.9, dfps: 44.1

BillSample.mp4 (interlace): 1440x1080, 5.2Mbps
DiAVC: User: 1s, kernel: 0s, total: 1s, real: 12s, fps: 760.1, dfps: 106.7
DIVX: User: 2s, kernel: 0s, total: 2s, real: 12s, fps: 568.8, dfps: 104.6
CoreAVC: User: 1s, kernel: 0s, total: 1s, real: 12s, fps: 842.0, dfps: 110.8

withyou.mp4 (interlace): 1440x1080, 4.9Mbps
DiAVC: User: 25s, kernel: 1s, total: 26s, real: 98s, fps: 575.8, dfps: 155.2
DIVX: User: 30s, kernel: 0s, total: 30s, real: 105s, fps: 493.2, dfps: 145.3
CoreAVC: User: 20s, kernel: 0s, total: 20s, real: 98s, fps: 727.1, dfps: 154.8

kellylove.mp4 (interlace): 1920x1080, 27.4Mbps
DiAVC: User: 15s, kernel: 0s, total: 16s, real: 107s, fps: 289.4, dfps: 43.1
DIVX: User: 20s, kernel: 0s, total: 20s, real: 122s, fps: 228.8, dfps: 38.1
CoreAVC: User: 12s, kernel: 0s, total: 12s, real: 118s, fps: 375.0, dfps: 39.2

[hxhxd]

I have a very strange result:
coreavc 2.0
User: 2s, kernel: 0s, total: 2s, real: 3s, fps: 577.1, dfps: 415.0
User: 2s, kernel: 0s, total: 2s, real: 3s, fps: 563.8, dfps: 413.3

diavc
User: 2s, kernel: 0s, total: 2s, real: 4s, fps: 533.0, dfps: 356.0
User: 2s, kernel: 0s, total: 2s, real: 4s, fps: 573.7, dfps: 358.6

ffmpeg-mt
User: 24s, kernel: 0s, total: 24s, real: 24s, fps: 62.8, dfps: 62.5
User: 24s, kernel: 0s, total: 24s, real: 24s, fps: 63.1, dfps: 62.7

divx
User: 3s, kernel: 0s, total: 3s, real: 4s, fps: 482.9, dfps: 343.4
User: 3s, kernel: 0s, total: 3s, real: 4s, fps: 462.3, dfps: 344.6

Look at the ffmpeg-mt section.
ffdshow is the svn version from xvidvideo.ru. H264 decoder is ffmpeg-mt. Why the performace is so weak?

Edit:
system is hp 380G5, 2003 ent 32bit.

[Dark Shikari]

Maybe multithreading isn't being activated?

Is it an interlaced sample? ffmpeg-mt won't work on PAFF H.264.

[ForceX]

DiAVC still seems to have a lot of problem with lower level (L1.1 Baseline/Main) AVCs. Such videos in FLV give green bars/corrupted videos. But after I extracted the streams and remuxed them in MKV it was fine, however, the extraced elementary H.264 stream run through Elecard Demuxer freezes on DiAVC. DivX doesn't have such issues.

[hxhxd]

Maybe multithreading isn't being activated?

Is it an interlaced sample? ffmpeg-mt won't work on PAFF H.264.

Thanks. FFDshow's default threads is set to 1.

When set it to 8, the result is:
User: 2s, kernel: 0s, total: 2s, real: 4s, fps: 518.8, dfps: 332.9
User: 2s, kernel: 0s, total: 3s, real: 4s, fps: 508.0, dfps: 332.9

FFDshow prevents me to set thread to 0.:eek:

[schweinsz]

Is Graphstudio ok to measure performance? View -> Decoder Performance

With a 1080p clip at L5.1 on a Core 2 Duo E8400:
DiAVC beta: 81.3 FPS
DiAVC alpha: 72.6 FPS
CoreAVC 2: 63.0 FPS

Athlon 64 3500+:
DiAVC beta: crashes!
DiAVC alpha: 24.6 FPS
CoreAVC 2: 22.3 FPS

But on the Athlon 64 the actual use shows a very slightly lower CPU usage fore CoreAVC and it seems to behave better overall, so I don't know.
The crashing on athlon64 is perhaps due to the wrong use for SSSE3.

[ForceX]

The crashing on athlon64 is perhaps due to the wrong use for SSSE3.
No AMD CPUs support SSSE3. Athlon64 3500+ supports upto SSE3. If some function in DiAVC relies strictly on SSSE3 code with no fallback, it'll fail on AMD CPUs.

[schweinsz]

A new beta version is available:
changes:
Fix the bug related to low-resolution videoes
correct code for judge SSSE3
Fix a bug on parsing prefix-length sps

[STaRGaZeR]

The beta in your link (I suppose it's the lastest) is crashing here with a Pentium M and WinXP.

[schweinsz]

The beta in your link (I suppose it's the lastest) is crashing here with a Pentium M and WinXP.
Looks that there is a bug related to the single-thread. I will fix it as soon as possible.

[schweinsz]

The beta in your link (I suppose it's the lastest) is crashing here with a Pentium M and WinXP.

Re-download it now, I added a protection to prevent the pentiumM from using SSSE3.

[Stephen R. Savage]

@schweinsz: Wouldn't the correct way to handle this be to check the CPUFLAGS for the SSSE3 flag and only enable the code if it is present?

[schweinsz]

@schweinsz: Wouldn't the correct way to handle this be to check the CPUFLAGS for the SSSE3 flag and only enable the code if it is present?
Previously I do this at the first release of the DiAVC beta, but two guys reports error, so I changed the code. I am not sure if the old cpu set that bit correctly.

I added a protection as follows:
__cpuid(nBuff, 0);
nHighestFeature = (u32)nBuff[0];
......
__cpuid(CPUInfo, 1);
nLogicalProcessors = ((CPUInfo[1] >> 16) & 0xff);
isSSSE3 = (CPUInfo[2]&0x200);
if(nProcessorType==AMD_CPU || nHighestFeature<=6) isSSSE3 = 0;

[Fadeout]

Redone tests. With a 1080p clip at L5.1 on a Core 2 Duo E8400.

DiAVC beta:
User: 2s, kernel: 0s, total: 2s, real: 18s, fps: 637.4, dfps: 79.7
User: 2s, kernel: 0s, total: 2s, real: 18s, fps: 604.0, dfps: 80.2
User: 2s, kernel: 0s, total: 2s, real: 18s, fps: 655.4, dfps: 79.7

CoreAVC2
User: 1s, kernel: 0s, total: 1s, real: 22s, fps: 770.1, dfps: 63.1
User: 1s, kernel: 0s, total: 1s, real: 23s, fps: 733.5, dfps: 62.7
User: 2s, kernel: 0s, total: 2s, real: 22s, fps: 655.4, dfps: 63.1

Still crashes on Athlon 64. And still problem with subtitles appearing too soon.

[schweinsz]

A new version is uploaded.
The implementation of the single-thread decoding for old cpu is modified.

[STaRGaZeR]

It still crashes here. It's curious though, MPC loads the file, starts playing it and the crash report appears instantaneously. However MPC shows "Playing" and the time counter increases normally until you accept the crash popup. Black screen in the whole process.

[namaiki]

What's the module at fault, if it says?

[STaRGaZeR]

AppName: mplayerc.exe AppVer: 1.3.1293.9018 ModName: diavc.ax
ModVer: 0.0.0.0 Offset: 000453aa

[Fadeout]

A new version is uploaded.
The implementation of the single-thread decoding for old cpu is modified.
Well, on my Athlon 64 I still get a crash, but now I can't even go back to the alpha.

The beta crashes, the alpha says it cannot render (like it misses the codec).

Alpha now doesn't work anymore even on my Core 2 Duo, as if the beta version is now preventing a rollback to work (to switch I simply register the other filter, having alpha and beta in two separate folders).

[schweinsz]

Could someone help me with the debug?
download the following file, unzip it and run the two .bat files.
Feedback the results to me.
http://di-avc.com/test.7z
You must use the single-care cpu because the decoder crashes on it.

[the_corona]

test.bat

first decoder inited!
first decoder inited!
1 decoder inited!
2 decoder inited!
3 decoder inited!
4 decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!
99 frames decoded totally.
4234111 counters used by decoder and 12102 counters used by others.

Decoding speed: 83 fps


test2.bat

first decoder inited!
1 decoder inited!
2 decoder inited!
3 decoder inited!
4 decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!
99 frames decoded totally.
4431532 counters used by decoder and 15220 counters used by others.

Decoding speed: 79 fps


These are on my Athlon64 x2, I assigned only one cpu core to the cmd.exe I usted to start the bat...hope this is what you need. They didnt seem to crash for me either with just double clicking (fps number higher though).

I can test on Athlon64 x2/Sempron/Atom/Core Duo if you need...but not before tonight.

[ForceX]

On a single-core A64:

test.bat
first decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!
99 frames decoded totally.
4107778 counters used by decoder and 11540 counters used by others.

Decoding speed: 86 fps


test2.bat

first decoder inited!
1 decoder inited!
2 decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!
99 frames decoded totally.
4198624 counters used by decoder and 11584 counters used by others.

Decoding speed: 84 fps


Just FYI: Running the batch files produces multiple times produces variable FPS/counters results. Also, that elementary stream is not being decoded properly by DiAVC when using Elecard demuxer (no .h264 file is, really). Not sure if it's the demuxer's fault, but CoreAVC and DivX works fine with Elecard.

[schweinsz]

On a single-core A64:

test.bat
first decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!
99 frames decoded totally.
4107778 counters used by decoder and 11540 counters used by others.

Decoding speed: 86 fps


test2.bat

first decoder inited!
1 decoder inited!
2 decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!
99 frames decoded totally.
4198624 counters used by decoder and 11584 counters used by others.

Decoding speed: 84 fps


Just FYI: Running the batch files produces multiple times produces variable FPS/counters results. Also, that stream is not decoded properly by DiAVC.
The decoder is correct and doesn't crash on the bitstream, that means the filter is with some problems. Thank you very much.
This is a mbaff bitstream and I use it as a conformance verification. I compared the result gotten by my decoder and jm, it is exactly equal. How you get "that stream is not decoded properly by DiAVC"?

[STaRGaZeR]

sgltrd.exe basketball720x576.264
first decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!


Then crash:

AppName: sgltrd.exe AppVer: 0.0.0.0 ModName: sgltrd.exe
ModVer: 0.0.0.0 Offset: 000aa4a7


mttrd.exe basketball720x576.264
first decoder inited!
1 decoder inited!
2 decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!

Then crash:

AppName: mttrd.exe AppVer: 0.0.0.0 ModName: mttrd.exe
ModVer: 0.0.0.0 Offset: 000aa4a7

With a Pentium M 730.

[ForceX]

How you get "that stream is not decoded properly by DiAVC"?
I mean I'm getting this kind of output:
http://i45.tinypic.com/2db8jyc.png

Also the video freezes and stutters. I'm using Elecard demuxer. It may be the demuxer's incompatibility but other AVC decoders give proper output with Elecard.

[schweinsz]

sgltrd.exe basketball720x576.264
first decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!


Then crash:

AppName: sgltrd.exe AppVer: 0.0.0.0 ModName: sgltrd.exe
ModVer: 0.0.0.0 Offset: 000aa4a7


mttrd.exe basketball720x576.264
first decoder inited!
1 decoder inited!
2 decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!

Then crash:

AppName: mttrd.exe AppVer: 0.0.0.0 ModName: mttrd.exe
ModVer: 0.0.0.0 Offset: 000aa4a7

With a Pentium M 730.
Thank you, there BE a bug in the decoder.

[the_corona]

Sempron 1800mhz (1 Core):

first decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!
99 frames decoded totally.
4470703 counters used by decoder and 13453 counters used by others.

Decoding speed: 79 fps


first decoder inited!
1 decoder inited!
2 decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!
99 frames decoded totally.
4661021 counters used by decoder and 13264 counters used by others.

Decoding speed: 76 fps


Atom 1600mhz

first decoder inited!
1 decoder inited!
2 decoder inited!
3 decoder inited!
4 decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!
99 frames decoded totally.
2657842 counters used by decoder and 11391 counters used by others.

Decoding speed: 58 fps


first decoder inited!
1 decoder inited!
2 decoder inited!
3 decoder inited!
4 decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!
99 frames decoded totally.
2482841 counters used by decoder and 10982 counters used by others.

Decoding speed: 62 fps


Core Duo 1800mhz (2 Core...same as A64 gave cmd.exe only one core

first decoder inited!
1 decoder inited!
2 decoder inited!
3 decoder inited!
4 decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!
99 frames decoded totally.
1971485641 counters used by decoder and 8748719 counters used by others.

Decoding speed: 90 fps


first decoder inited!
1 decoder inited!
2 decoder inited!
3 decoder inited!
4 decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!
99 frames decoded totally.
2021019457 counters used by decoder and 9506171 counters used by others.

Decoding speed: 88 fps


PS: A64x2 from before is clocked at 2200mhz

[schweinsz]

Sempron 1800mhz (1 Core):

first decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!
99 frames decoded totally.
4470703 counters used by decoder and 13453 counters used by others.

Decoding speed: 79 fps


first decoder inited!
1 decoder inited!
2 decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!
99 frames decoded totally.
4661021 counters used by decoder and 13264 counters used by others.

Decoding speed: 76 fps


Atom 1600mhz

first decoder inited!
1 decoder inited!
2 decoder inited!
3 decoder inited!
4 decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!
99 frames decoded totally.
2657842 counters used by decoder and 11391 counters used by others.

Decoding speed: 58 fps


first decoder inited!
1 decoder inited!
2 decoder inited!
3 decoder inited!
4 decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!
99 frames decoded totally.
2482841 counters used by decoder and 10982 counters used by others.

Decoding speed: 62 fps


Core Duo 1800mhz (2 Core...same as A64 gave cmd.exe only one core

first decoder inited!
1 decoder inited!
2 decoder inited!
3 decoder inited!
4 decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!
99 frames decoded totally.
1971485641 counters used by decoder and 8748719 counters used by others.

Decoding speed: 90 fps


first decoder inited!
1 decoder inited!
2 decoder inited!
3 decoder inited!
4 decoder inited!
decoder iit post 1!
decoder iit post 2!
decoder iit post 2!
decoder iit post 4!
decoder iit post 5!
99 frames decoded totally.
2021019457 counters used by decoder and 9506171 counters used by others.

Decoding speed: 88 fps


PS: A64x2 from before is clocked at 2200mhz
Thank you very much! I found that only the PentiumM and athlon64 got crashing.

[schweinsz]

To STaRGaZeR:
Another test for more crash information.
http://di-avc.com/test2.7z
Only pentiumM and athlon64 cpu are needed because the decoder only crashes the two cpu.

[Fadeout]

Athlon 64, I get this:

J:\test2>snglthrd.exe paris_cif_24.264
isSSSE3 0
1 decoder inited!
nalu type 7
nalu type 8
nalu type 5
nalu type 5
nalu type 5
nalu type 5
nalu type 5
nalu type 5
nalu type 5
nalu type 5
nalu type 5
nalu type 1
curSLCtype 2 I 1
poc 0 slctype 2 mbx 0 mby 0 mbtype 3 info 0 mb_start
0
mbmode 0 AfterMBtype arth range 14c value 521ec0 btlft 14

Then crash.

[STaRGaZeR]

I get exactly the same. Crash:

AppName: snglthrd.exe AppVer: 0.0.0.0 ModName: snglthrd.exe
ModVer: 0.0.0.0 Offset: 000aa76a

[ForceX]

nalu type 1
curSLCtype 1 I 0
175 frames decoded totally.
49158523 counters used by decoder and 18649 counters used by others.

Decoding speed: 12 fps

On my single-core Athlon64. No crash.

[schweinsz]

Thank you both. Looks there exist some incompatibility of SSE2 code with the two cpu.
Have a more test to sure it.
http://di-avc.com/test3.7z

[STaRGaZeR]

snglthrd.exe paris_cif_24.264
isSSSE3 0
1 decoder inited!
nalu type 7
nalu type 8
nalu type 5
nalu type 5
nalu type 5
nalu type 5
nalu type 5
nalu type 5
nalu type 5
nalu type 5
nalu type 5
nalu type 1
curSLCtype 2 I 1
poc 0 slctype 2 mbx 0 mby 0 mbtype 3 info 0 mb_start
0
mbmode 0 AfterMBtype arth range 14c value 521ec0 btlft 14
iprd mode end!
cbp 47 qp 26
idx 0 isSig 1
dt tok c


Then crash:

AppName: snglthrd.exe AppVer: 0.0.0.0 ModName: snglthrd.exe
ModVer: 0.0.0.0 Offset: 000aa76a

[ForceX]

No crash again on my system. Decode completes successfully like previous test.

[schweinsz]

A new bata version is available.
changes:
fix a bug (a fault use of a sse3 code in sse2 functions).

Great thanks to ForceX, STaRGaZeR, Fadeout and the_corona for their help.

[LoRd_MuldeR]

With the Beta release I have a strange problem: The video is jumping back and forth like crazy :confused:

I went back to the Alpha (2009-12-14) and problem is gone...

[schweinsz]

With the Beta release I have a strange problem: The video is jumping back and forth like crazy :confused:

I went back to the Alpha (2009-12-14) and problem is gone...
No, you are cheated by your cache, delete your cache and re-download the beta-version. The alpha-version is expired.

[LoRd_MuldeR]

No, you are cheated by your cache, delete your cache and re-download the beta-version. The alpha-version is expired.

What cache? I had the Alpha release (2009-12-14) still on my HDD and that version works okay for me - apparently.

However as soon as I update to the latest Beta (file date 2010-01-02) I get the problem described above.

I switched the versions several times (also unregistred and re-registred the filter every time) and clearly the Alpha works, the Beta not :confused:

I'm using MPC-HC with EVR renderer and I tested various H.264 files. They all show the same behavior...

(BTW: I can record the screen output with my digicam, if you want)

MD5 of DiAVC.ax (2009-12-14): b5e002c7ff8e0525bb5fd57bbe0190f4
MD5 of DiAVC.ax (2010-01-02): 96140b5a86b294584bc7fc7f23ad8486

[schweinsz]

What cache? I had the Alpha release (2009-12-14) still on my HDD and that version works okay for me - apparently.

However as soon as I update to the latest Beta (file date 2010-01-02) I get the problem described above.

I switched the versions several times (also unregistred and re-registred the filter every time) and clearly the Alpha works, the Beta not :confused:

I'm using MPC-HC with EVR renderer and I tested various H.264 files. They all show the same behavior...

(BTW: I can record the screen output with my digicam, if you want)

MD5 of DiAVC.ax (2009-12-14): b5e002c7ff8e0525bb5fd57bbe0190f4
MD5 of DiAVC.ax (2010-01-02): 96140b5a86b294584bc7fc7f23ad8486
jumping back and forth is the appearance of a outdated version. The alpha version is expired now. I review my code just now but I can't find any problem. Did you even modify your time to after 20100125 and run the DiAVC?

[LoRd_MuldeR]

jumping back and forth is the appearance of a outdated version. The alpha version is expired now.

Well, it apparently works here, in contrast to the Beta ;)

I review my code just now but I can't find any problem. Did you even modify your time to after 20100125 and run the DiAVC?

You mean the global system time?

Yes, some of the software I'm developing includes "Auto Update" features, so I sometimes have to adjust the global system to some future date for testing/debugging.

I hope you won't tell me that DiAVC prohibits the user to adjust the global system time...

(Note: I always sync my global system time with the Windows timeserver after I had to adjust it for testing purpose, so unless DiAVC installs some "hidden" daemon/driver that contentiously monitors the global system time, it shouldn't have seen any date after 2010-01-01 until now ^^)

[schweinsz]

Well, it apparently works here, in contrast to the Beta ;)



You mean the global system time?

Yes, some of the software I'm developing includes "Auto Update" features, so I sometimes have to adjust the global system to some future date for testing/debugging.

I hope you won't tell me that DiAVC prohibits the user to adjust the global system time...

(Note: I always sync my global system time with the Windows timeserver after I had to adjust it for testing purpose, so unless DiAVC installs some "hidden" daemon/driver that contentiously monitors the global system time, it shouldn't have seen any date after 2010-01-01 until now ^^)

Only reading system time can be skipped by modifying it simplify, so I invented some new method to read more time information.
The DiAVC is a pure ring3 application and have not any "hidden" daemon/driver that contentiously monitors the global system time, and the DiAVC have none access to internet.

[LoRd_MuldeR]

Wait, so DiAVC scans the Event Log for events of "future" date and will expire if it finds such entries?

Anyway, I scanned the local event history and I couldn't find any events that have a later date than 2010-01-01.

Well, most likely DiAVC has more sophisticated methods to find the latest date ever configured on a system and you probably won't tell us too many details ;)

It seems that means I won't be able to use the Beta version then...

[schweinsz]

Wait, so DiAVC scans the Event Log for events of "future" date and will expire if it finds such entries?

Anyway, I scanned the local event history and I couldn't find any events that have a later date than 2010-01-01.

Well, most likely DiAVC has more sophisticated methods to find the latest date ever configured on a system and you probably won't tell us too many details ;)

It seems that means I won't be able to use the Beta version then...
I ever invented more but only these are used.

[LoRd_MuldeR]

D'oh! I indeed found a process that was started at a "future" date. Damn TortoiseSVNCache process again :rolleyes:

Problem is resolved now, thanks :)

BTW: Why that strange behavior when DiAVC expires? Wouldn't a message box that tells the user what is going on be more adequate?

Especially if you want to motivate people to buy the full version :D

[schweinsz]

D'oh! I indeed found a process that was started at a "future" date. Damn TortoiseSVNCache process again :rolleyes:

Problem is resolved now, thanks :)

BTW: Why that strange behavior when DiAVC expires? Wouldn't a message box that tells the user what is going on be more adequate?

Especially if you want to motivate people to buy the full version :D
Ok, I will add a message box.

[STaRGaZeR]

A new bata version is available.
changes:
fix a bug (a fault use of a sse3 code in sse2 functions).

Great thanks to ForceX, STaRGaZeR, Fadeout and the_corona for their help.

Yep, now it works here :)

However it's slower than both ffmpeg-mt and CoreAVC. I have not tested timecodec, but in real world scenarios the CPU usage is higher and videos that are in the verge of stuttering because of not enough CPU power with those decoders do stutter with DiAVC.

[schweinsz]

Yep, now it works here :)

However it's slower than both ffmpeg-mt and CoreAVC. I have not tested timecodec, but in real world scenarios the CPU usage is higher and videos that are in the verge of being unplayable with those decoders are unplayable with DiAVC.

I disable multi-thread for single-core old cpu and I don't know if it help or hurt the performance. You can test it using the timecodec then I can improve it. The current design of the DiAVC never drop any frames except the playbacking start and the start after a seeking. I can do some trick to improve the performance when hard.

[Disabled]

With all those protections I wonder, what protections will there be on the final version? I hope you don't add stupid things like online activation to it. The date checks are only for the beta versions and will be removed in the final (paid) version I guess? Is the anti debug code gone for good? Anything else we should know?

[STaRGaZeR]

DiAVC:

User: 13s, kernel: 0s, total: 13s, real: 132s, fps: 303.4, dfps: 31.8

CoreAVC 1.9.5:

User: 99s, kernel: 0s, total: 99s, real: 104s, fps: 42.3, dfps: 40.3

ffmpeg-mt, 1 thread:

User: 116s, kernel: 0s, total: 117s, real: 121s, fps: 36.0, dfps: 34.6

ffmpeg-mt, 4 threads:

User: 12s, kernel: 0s, total: 12s, real: 139s, fps: 343.2, dfps: 30.3

libavcodec:

User: 115s, kernel: 0s, total: 115s, real: 121s, fps: 36.6, dfps: 34.8

Apple trailer, 1080p24. With DiAVC I can't do anything else, Windows is sloooow. Even closing MPC-HC takes at least 5 seconds. And all of them stutter with some parts of the video, CoreAVC may look faster and enough here but in reality it isn't.

[yesgrey]

I tested it and the results are exactly the same as with the previous beta.

[Fadeout]

Latest beta works. The problem with subtitles still there.

1080p clip at L5.1 on a Core 2 Duo E8400.

DiAVC beta:
User: 2s, kernel: 0s, total: 2s, real: 18s, fps: 637.4, dfps: 79.7
User: 2s, kernel: 0s, total: 2s, real: 18s, fps: 604.0, dfps: 80.2
User: 2s, kernel: 0s, total: 2s, real: 18s, fps: 655.4, dfps: 79.7

CoreAVC2:
User: 1s, kernel: 0s, total: 1s, real: 22s, fps: 770.1, dfps: 63.1
User: 1s, kernel: 0s, total: 1s, real: 23s, fps: 733.5, dfps: 62.7
User: 2s, kernel: 0s, total: 2s, real: 22s, fps: 655.4, dfps: 63.1

Same clip, Athlon 64 3500+.

DiAVC beta:
User: 2s, kernel: 0s, total: 2s, real: 56s, fps: 532.1, dfps: 25.5
User: 2s, kernel: 0s, total: 2s, real: 56s, fps: 536.0, dfps: 25.6
User: 2s, kernel: 0s, total: 2s, real: 56s, fps: 530.1, dfps: 25.6

CoreAVC2:
User: 64s, kernel: 0s, total: 64s, real: 64s, fps: 22.5, dfps: 22.4
User: 64s, kernel: 0s, total: 64s, real: 64s, fps: 22.4, dfps: 22.3
User: 64s, kernel: 0s, total: 64s, real: 64s, fps: 22.4, dfps: 22.3

The real CPU usage on the Athlon is very similar to CoreAVC, I only had problems making subtitles works since DirectVobSub gets loaded before DiAVC and I only see the first frame of a video and nothing else (time moves but the video is freezed). CoreAVC works and the problem with DiAVC clears if I block DirectVobSub.

On the Core 2 Duo subtitles load correctly, but there's the problem with them being delayed in respect to the video/audio.

[STaRGaZeR]

Possible explanation of the low perfomance of DiAVC with PentiumM: http://forum.doom9.org/showpost.php?p=1355637&postcount=5508

[schweinsz]

With all those protections I wonder, what protections will there be on the final version? I hope you don't add stupid things like online activation to it. The date checks are only for the beta versions and will be removed in the final (paid) version I guess? Is the anti debug code gone for good? Anything else we should know?
The final version will add registration according your machine feature without any online activation, and the DiAVC will never have any access to internet. The date checks will be deleted in the final version.

[schweinsz]

Possible explanation of the low perfomance of DiAVC with PentiumM: http://forum.doom9.org/showpost.php?p=1355637&postcount=5508

The slower SSE2 can't give such a big degration. I suspend that the pentiumM has a super bad thread function support.

[dZeus]

Will non-SSE2 capable CPUs be supported in future? I'd love to be able to play back higher res/bitrate AVC on my Pentium3-1400S HTPC.

[schweinsz]

Will non-SSE2 capable CPUs be supported in future? I'd love to be able to play back higher res/bitrate AVC on my Pentium3-1400S HTPC.
It is in plan, but currently I am working on others.

[LigH]

Then I can even check it on an AMD Duron-800... :D

[CruNcher]

I hope it doesn't get compiled with Intels Compiler as this is still causing performance issues on AMD CPUs (going less efficient compilation paths) ? the issue is very well known
but i guess for those parts that create the speed for a Video Decoder case (the hand optimized ASM) it makes not such a big difference on the pure communication level between Windows and the Decoder that are non hand optimized ?

[schweinsz]

I hope it doesn't get compiled with Intels Compiler as this is still causing performance issues on AMD CPUs (going less efficient compilation paths) ? the issue is very well known
but i guess for those parts that create the speed for a Video Decoder case (the hand optimized ASM) it makes not such a big difference on the pure communication level between Windows and the Decoder that are non hand optimized ?
The DiAVC is compiled by vc2008, and the icl is never used.
But I plan to use it for speed on intel cpu.

some performance-critical parts are optimized by asm such as motion-compensation, idct, deblock, cabac, while the pure communication level between Windows and the Decoder use the functions in run-time library, for example, _beginthreadex.

[kemuri-_9]

I hope it doesn't get compiled with Intels Compiler as this is still causing performance issues on AMD CPUs (going less efficient compilation paths) ? the issue is very well known
but i guess for those parts that create the speed for a Video Decoder case (the hand optimized ASM) it makes not such a big difference on the pure communication level between Windows and the Decoder that are non hand optimized ?

what?
Intel's compiler is faster than MSVC which is faster than gcc when targeting x86 or x86_64, even on my AMD.

ICL defaults to general SSE2 generation,
you have to specifically specify an option to optimize for intel cpus, and that would only cause it to crash on AMD cpus which don't have the corresponding instruction set.
doing something like
/arch:sse /QaxSSSE3 would have it use sse and then make a special SSSE3 cpu path.

[LoRd_MuldeR]

It should be noted that builds compiled with "/arch:see" or "/arch:see2" (default) won't run on non-SSE2 capable CPU's. So people will complain ;)

As "/Qax" can be used more than once, the combination "/arch:ia32 /QaxSSE /QaxSSE2 /QaxSSSE3" should produce a build that runs on any CPU and still uses optimized SSE/SSE2/SSSE3 code, if supported.

Also it seems the fastest builds for Intel CPU's can only be achieved with "/QxSSE2" or "/QxSSSE3", but that is only feasible if you want to offer special "Intel only" builds.

[schweinsz]

what?
Intel's compiler is faster than MSVC which is faster than gcc when targeting x86 or x86_64, even on my AMD.

ICL defaults to general SSE2 generation,
you have to specifically specify an option to optimize for intel cpus, and that would only cause it to crash on AMD cpus which don't have the corresponding instruction set.
doing something like
/arch:sse /QaxSSSE3 would have it use sse and then make a special SSSE3 cpu path.
Good news for me! The DiAVC will be free of two version for amd and intel. I recently plan to use icl, but is it feasible that some files use msvc while others use icl? Is it consistant about the link-time code generation between msvc and icl?
The current DiAVC requires SSE2.

[LoRd_MuldeR]

There is an explicit warning to NOT link code with Intel-specific optimizations ("/Qx") against code that doesn't use those optimizations.

I think that's because it would bypass Intel's CPU check they add to the main() function. So the binary would run Non-Intel CPU's although it contains Intel-only code.

This can lead to "undefined" behavior. Normally a binary with Intel-specific optimizations will exit with error message on Non-Intel CPU's.

[CruNcher]

http://www.brightsideofnews.com/news/2009/12/17/why-the-ftc-lawsuit-against-intel-has-substance.aspx <- im referring to this lawsuit

[roozhou]

http://www.brightsideofnews.com/news/2009/12/17/why-the-ftc-lawsuit-against-intel-has-substance.aspx <- im referring to this lawsuit

And a good article about this:

Intel's "cripple AMD" function (http://www.agner.org/optimize/blog/read.php?i=49)

[LoRd_MuldeR]

Sounds nice, but the truth is that the CPU dispatcher didn't support SSE or SSE2 or any higher SSE in AMD processors

Which probably was intentional and perfectly legitimate, because of:

The Athlon 64's SSE unit is so slow that it's generally worse than MMX. Most operations are done by splitting the instruction in half and sending them off to the MMX unit, making the whole thing a complete waste of time.

And who still claims ICC doesn't support SSE2 for Non-Intel CPU's probably used "/QxSSE2", which indeed won't work for AMD CPU's, instead of "/arch:SSE2" :rolleyes:

However the latter is the default in the current ICC version, so I assume such claim would date back to an old outdated version...

See also:
http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/cpp/win/compiler_c/copts/common_options/option_arch.htm#option_arch

[clsid]

ICL can be patched to skip the GenuineIntel checks so that it also uses SSE/SSE2/etc on AMD CPUs.

I suggest not to worry about compilers. Just make one generic build with your own assembly optimizations for all performance critical parts. This also allows making your own choices about which function implementations get used on which processors.

[schweinsz]

Could somebody help me the test on single-core old cpu such as PentiumM, athlon64?
http://di-avc.com/testd.7z.
Download the file and uppack it, run the run.bat and feedback the results.

Recently I have finished all yuv scaling and yuv2rgb functions and am working on the bug about the seeking and timestamp.

[the_corona]

nothrd.exe basketball720x576.264
99 frames decoded totally.
3928067 counters used by decoder and 13161 counters used by others.

Decoding speed: 90 fps

sglthrd.exe basketball720x576.264
99 frames decoded totally.
4263451 counters used by decoder and 14818 counters used by others.

Decoding speed: 83 fps

nothrd.exe basketball720x576.264
99 frames decoded totally.
3918364 counters used by decoder and 13008 counters used by others.

Decoding speed: 90 fps

sglthrd.exe basketball720x576.264
99 frames decoded totally.
4124521 counters used by decoder and 12798 counters used by others.

Decoding speed: 85 fps

pause

AMD Sempron 3000+ (Single Core 1800mhz)

[ForceX]

Single thread Athlon64
nothrd.exe basketball720x576.264
99 frames decoded totally.
3684944 counters used by decoder and 12321 counters used by others.

Decoding speed: 96 fps

sglthrd.exe basketball720x576.264
99 frames decoded totally.
3545769 counters used by decoder and 12152 counters used by others.

Decoding speed: 99 fps

nothrd.exe basketball720x576.264
99 frames decoded totally.
3406643 counters used by decoder and 12143 counters used by others.

Decoding speed: 104 fps

sglthrd.exe basketball720x576.264
99 frames decoded totally.
3523578 counters used by decoder and 12225 counters used by others.

Decoding speed: 100 fps

pause

[clsid]

The test fails (with Illegal Instruction error) on an old AMD Athlon Thunderbird (1.33 Ghz). That CPU only has MMX and MMXext, but no SSE1.

[schweinsz]

The test fails (with Illegal Instruction error) on an old AMD Athlon Thunderbird (1.33 Ghz). That CPU only has MMX and MMXext, but no SSE1.
The DiAVC requires SSE2.

[horvathd]

d:\Letöltések\testd>nothrd.exe basketball720x576.264
99 frames decoded totally.
5409485 counters used by decoder and 18457 counters used by others.

Decoding speed: 65 fps

d:\Letöltések\testd>sglthrd.exe basketball720x576.264
99 frames decoded totally.
5520247 counters used by decoder and 16373 counters used by others.

Decoding speed: 64 fps

d:\Letöltések\testd>nothrd.exe basketball720x576.264
99 frames decoded totally.
5454162 counters used by decoder and 16909 counters used by others.

Decoding speed: 64 fps

d:\Letöltések\testd>sglthrd.exe basketball720x576.264
99 frames decoded totally.
5669338 counters used by decoder and 16629 counters used by others.

Decoding speed: 62 fps

On Intel Celeron M 330

[CruNcher]

Athlon 64 X2 (Toledo) SSE (1,2,3) 3DNOW(+) MMX(+)


C:\testd\testd>nothrd.exe basketball720x576.264
99 frames decoded totally.
3066867 counters used by decoder and 8285 counters used by others.

Decoding speed: 115 fps

C:\testd\testd>sglthrd.exe basketball720x576.264
99 frames decoded totally.
2034767 counters used by decoder and 7709 counters used by others.

Decoding speed: 174 fps

C:\testd\testd>nothrd.exe basketball720x576.264
99 frames decoded totally.
3203470 counters used by decoder and 7944 counters used by others.

Decoding speed: 110 fps

C:\testd\testd>sglthrd.exe basketball720x576.264
99 frames decoded totally.
1995043 counters used by decoder and 7543 counters used by others.

Decoding speed: 177 fps

[dZeus]

nothrd.exe basketball720x576.264
99 frames decoded totally.
3754152 counters used by decoder and 17488 counters used by others.

Decoding speed: 94 fps

sglthrd.exe basketball720x576.264
99 frames decoded totally.
3986075 counters used by decoder and 17523 counters used by others.

Decoding speed: 88 fps

nothrd.exe basketball720x576.264
99 frames decoded totally.
3927613 counters used by decoder and 17756 counters used by others.

Decoding speed: 90 fps

sglthrd.exe basketball720x576.264
99 frames decoded totally.
3995219 counters used by decoder and 17091 counters used by others.

Decoding speed: 88 fps

Pentium M dothan 2GHz (single core)

[schweinsz]

A new beta version is available.
Changes:
20100112
fix two bugs on timestampt.
Only using the main thread for old intel cpu.

The functions about scaling and yuv2rgb are finished for some days, but I must firstly add a propertypage before I integrate them.

I heard that using the same thread in frame parallel instead of creating new thread for every frame can improve performance, I will try it.

As regarding to the compatibility with the elecard splitter, I found that the elecard splitter sends half-baked nalu to the decoder. Fixing it is easy, but a buffer is needed to buffer the nalues. As the bug influences raw 264 bitstreams only, I don't fix it in this release.

[CruNcher]

realtime performance playback test with 1080p 60 fps

MPC-HC (CUDA) = 60 fps
CoreAVC 2.0 = 42 fps
CoreAVC 2.0 (CUDA) = 38
DivX 1.1 = 34 fps
ffdshow (ffmpeg-mt) = 30 fps
ffdshow (dxva) = 30 fps
DiAVC Beta 2 = 14 fps

[schweinsz]

wow this is crazy i made a performance test with 1080p 60 fps on the same machine as seen above and CoreAVC beats DIAVC so heavily 14 fps vs 42 fps
Cuda via CoreAVC in that usage is also hit hard with only 38 fps (guess due to the frame back copy) direct Cuda has no problems via MPC-HC reaching 60 fps

I watch no performance loss when compared to the last version of DiAVC on my laptop. Could you test the last release of the DiAVC? Perhaps it is due to the false use of single thread. Is there some thing wrong?

[Keiyakusha]

realtime performance playback test with 1080p 60 fps

MPC-HC (CUDA) = 60 fps
CoreAVC 2.0 = 42 fps
CoreAVC 2.0 (CUDA) = 38
DivX 1.1 = 34 fps
ffdshow (ffmpeg-mt) = 30 fps
ffdshow (dxva) = 30 fps
DiAVC Beta 2 = 14 fps

MPC-HC CUDA? Did you mean DXVA?
FFDShow DXVA is a port of MPC-HC's DXVA. It really twice slower? :eek:

[CruNcher]

I watch no performance loss when compared to the last version of DiAVC on my laptop. Could you test the last release of the DiAVC? Perhaps it is due to the false use of single thread. Is there some thing wrong?

Both cores are not fully utilized with DiAVC yet guess it's still a performance issue :)
Athlon 64 X2 Toledo
I used the last DiAVC i named it Beta 2 because the filename says so ;)

MPC-HC CUDA? Did you mean DXVA?
FFDShow DXVA is a port of MPC-HC's DXVA. It really twice slower? :eek:

no MPC-HC uses Bitstreaming just streams the file to the VPx and it does the Decode it's not DXVA in the sense of acceleration it's pure Hardware Decoding (CoreAVC CUDA does the same only difference it copies the frames back so they can be manipulated and so in this extreme case the performance is hit heavily)
FFDshows DXVA seems to not work @ all for my configuration :(

[Dark Shikari]

MPC-HC CUDA? Did you mean DXVA?
FFDShow DXVA is a port of MPC-HC's DXVA. It really twice slower? :eek:It's probably impossible for decoder-side DXVA to be as fast as player-side DXVA, because decoder-side DXVA requires the decoded video data to be sent to memory before it's sent to the display.

I'm surprised the disparity is that large though.

[clsid]

The internal decoder of MPC-HC is an embedded DirectShow filter.

[schweinsz]

to Cruncher: download the following file, and run the run.bat, then I can find why it is slow on your computer.
http://di-avc.com/test2.7z

[nm]

no MPC-HC uses Bitstreaming just streams the file to the VPx and it does the Decode it's not DXVA in the sense of acceleration it's pure Hardware Decoding (CoreAVC CUDA does the same only difference it copies the frames back so they can be manipulated and so in this extreme case the performance is hit heavily)

Both MPC-HC and ffdshow DXVA do use the DXVA API, not CUDA/NVCUVID. It's the hardware (and driver) that defines which DXVA "mode" must be used: partial or full hardware decoding. MPC-HC and ffdshow only support latter, as you said.

[Fadeout]

I found out that the 350ms delay on subtitles only appears with MPC-HC internal sub render. With external DirectVobSub it's synced well.

The beta 2 gave me a few FPS more compared to beta 1.

[schweinsz]

Does the newest-downloadable ffdshow-tryouts use the slice-level-parallel H.264 decoder (ffmpeg-mt)?
http://downloads.sourceforge.net/ffdshow-tryout/ffdshow_beta6_rev2527_20081219.exe

[Dark Shikari]

Does the newest-downloadable ffdshow-tryouts use the slice-level-parallel H.264 decoder (ffmpeg-mt)?
http://downloads.sourceforge.net/ffdshow-tryout/ffdshow_beta6_rev2527_20081219.exeffmpeg-mt is frame-parallel, not slice-parallel.

Regular ffmpeg (non-mt) is limited to slice-parallel only.

[schweinsz]

ffmpeg-mt is frame-parallel, not slice-parallel.

Regular ffmpeg (non-mt) is limited to slice-parallel only.
Where can I get the fastest ffdshow-mt build with sse2 optimization?
I downloaded the following two version, hope it is fastest.
http://sourceforge.net/projects/ffdshow-tryout/files/SVN%20builds%20by%20xxl/win32%20generic%20builds/ffdshow_rev3200_20100112_xxl.exe/download
http://sourceforge.net/projects/ffdshow-tryout/files/SVN%20builds%20by%20clsid/icl10%20builds/ffdshow_rev3200_20100112_clsid_icl10.exe/download

[fastplayer]

^They're equally fast.

[ForceX]

Latest FFDshow builds are frequently updated on http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/

[LoRd_MuldeR]

Even with the "ICL" builds of ffdshow only the "core" filter is compiled with ICL. The libavcodec DLL, which contains the H.264 decoder, is always compiled by GCC.

AFAIK the ICL builds are only faster for some of the filters, the pure decoding speed shouldn't be effected. Also any up-to-date build should offer "ffmpge-mt" as H.264 decoder option.

[CruNcher]

to Cruncher: download the following file, and run the run.bat, then I can find why it is slow on your computer.
http://di-avc.com/test2.7z

intelcpu 0 corenum 2 multithrd 1 decoders 5 inited!
99 frames decoded totally.
2131572 counters used by decoder and 7507 counters used by others.

Decoding speed: 166 fps

[schweinsz]

intelcpu 0 corenum 2 multithrd 1 decoders 5 inited!
99 frames decoded totally.
2131572 counters used by decoder and 7507 counters used by others.

Decoding speed: 166 fps

I get the reason. This is due to the lack of dropping late-arrived frames in DiAVC. while the ffmpeg-mt has the function and I believe the CoreAVC has similar feature. Following is some piece of the code:

// Now that we have noticed any format changes on the input sample, it's OK to discard it.
REFERENCE_TIME rtStart,rtStop;
if (pSample->GetTime(&rtStart,&rtStop)==S_OK) // memo: If VFW_S_NO_STOP_TIME is returned, rtStart is supoosed to be valid.
{
late-=ff_abs(rtStart-lastrtStart);
lastrtStart=rtStart;
insample_rtStart = rtStart;
insample_rtStop = rtStop;
}
else
{
late -= inpin->avgTimePerFrame;
insample_rtStart = REFTIME_INVALID;
insample_rtStop = REFTIME_INVALID;
}

if (m_bSampleSkipped && late>0) return S_OK;
int codecId = inpin->getInCodecId2();
if (presetSettings->dropOnDelay && !mpeg12_codec(codecId) && !vc1_codec(codecId) && late>presetSettings->dropDelayTime*10000)
{
//MSR_NOTE(m_idSkip);
setSampleSkipped(true);
DPRINTF_SAMPLE_TIME(pSample);
//late=0;
waitForKeyframe=1000;
count_decoded_frames_for_framerate_calculation = 0;
return S_OK;
}

I'll add the feature in recent days.

[Alante]

Today, HD.264 High Definition is a standard even for Entry Level Video Cards. Do you think you can top this potential: http://forum.doom9.org/showpost.php?p=1363356&postcount=28 ? The Decoding options are free, only some extra features are commercial, but competing with software rendering done by CPU vs. Hardware Rendering done by VGA - for which video is a basic element... it's hard to see any chance... CoreAVC also counts on HA, but it's just nVidia + Cuda based. Since HD is a standard now, free alternatives will cover most needs, but then again if you think you can offer a similar potential, like let's say HD decoding by CPU with 5% CPU resources then, good luck...

[schweinsz]

Today, HD.264 High Definition is a standard even for Entry Level Video Cards. Do you think you can top this potential: http://forum.doom9.org/showpost.php?p=1363356&postcount=28 ? The Decoding options are free, only some extra features are commercial, but competing with software rendering done by CPU vs. Hardware Rendering done by VGA - for which video is a basic element... it's hard to see any chance... CoreAVC also counts on HA, but it's just nVidia + Cuda based. Since HD is a standard now, free alternatives will cover most needs, but then again if you think you can offer a similar potential, like let's say HD decoding by CPU with 5% CPU resources then, good luck...
Same worrying with me, but I must finish it because I spent much time on it. Perhaps I should code the H.264 encoder firstly, GPU is without hardware H.264 encoder. I ever read the code of x264, there is many unefficient code in it, I can beat it very much easily by my ability. and there is more flexity in an encoder. Actually optimizing a decoder for speed is much more difficult than an encoder because of less flexity such as interpolation filter and deblock filter that occupying great time for a decoder, while finding a more efficient algorithm for them is very difficult than open-source ones (I invented some for the DiAVC).

[Dark Shikari]

Same worrying with me, but I must finish it because I spent much time on it. Perhaps I should code the H.264 encoder firstly, GPU is without hardware H.264 encoder. I ever read the code of x264, there is many unefficient code in it, I can beat it very much easily by my ability.Beating x264 in terms of raw speed is easy, but x264 doesn't exist to be the world's fastest encoder, it exists to be a fast good encoder. If someone wanted a super-fast encoder they could just use ffmpeg's MPEG-4, Badaboom, or something equally barebones. There's no point to creating an alternative encoder unless it serves some sort of useful niche, and I don't think that most users care about absurd speed at the cost of all quality. Obviously this problem doesn't exist with decoders: they either work or they don't, and as long as DiAVC works, the faster you can make it, the better for everyone.

If you want to make a faster x264 as opposed to a new fast-but-crappy encoder, patches are welcome--even just ideas can be sufficient to help me write a patch. But forking the entire encoder because you don't like a bit of the code is rather obnoxious and a waste of everyone's time.

[squid_80]

This is due to the lack of dropping late-arrived frames in DiAVC. while the ffmpeg-mt has the function and I believe the CoreAVC has similar feature.
I'll tell you again, CoreAVC has no such code...

Today, HD.264 High Definition is a standard even for Entry Level Video Cards. Do you think you can top this potential: http://forum.doom9.org/showpost.php?...6&postcount=28 ? The Decoding options are free, only some extra features are commercial, but competing with software rendering done by CPU vs. Hardware Rendering done by VGA - for which video is a basic element... it's hard to see any chance... CoreAVC also counts on HA, but it's just nVidia + Cuda based. Since HD is a standard now, free alternatives will cover most needs, but then again if you think you can offer a similar potential, like let's say HD decoding by CPU with 5% CPU resources then, good luck...
Good luck trying to decode anything above HD resolution with your video card.

[schweinsz]

Beating x264 in terms of raw speed is easy, but x264 doesn't exist to be the world's fastest encoder, it exists to be a fast good encoder. If someone wanted a super-fast encoder they could just use ffmpeg's MPEG-4, Badaboom, or something equally barebones. There's no point to creating an alternative encoder unless it serves some sort of useful niche, and I don't think that most users care about absurd speed at the cost of all quality. Obviously this problem doesn't exist with decoders: they either work or they don't, and as long as DiAVC works, the faster you can make it, the better for everyone.

If you want to make a faster x264 as opposed to a new fast-but-crappy encoder, patches are welcome--even just ideas can be sufficient to help me write a patch. But forking the entire encoder because you don't like a bit of the code is rather obnoxious and a waste of everyone's time.
What I mean is that I can improve the x264 by 20-30% on speed without any compromise on quality.

[Dark Shikari]

What I mean is that I can improve the x264 by 20-30% on speed without any compromise on quality.If that's the case, drop by #x264dev on Freenode and feel free to contribute :cool:

[Cyber-Mav]

What I mean is that I can improve the x264 by 20-30% on speed without any compromise on quality.

im assuming that you mean you can improve the decoding speed of videos encoded in h264 by 20-30%

if however you can inscrease ENCODING speed by 20-30% without loosing quality then you probably put dark shikari to work at mcdonalds.

[schweinsz]

im assuming that you mean you can improve the decoding speed of videos encoded in h264 by 20-30%

if however you can inscrease ENCODING speed by 20-30% without loosing quality then you probably put dark shikari to work at mcdonalds.
Isn't DS a student? He is a talent just like me. I do mean I can improve the encoding speed by 20-30% without loosing quality.
Is there some companies that pay for the development of x264?
Actually it is more difficult to improve the decoding by 20-30% than to improve the encoding by 20-30%.

[Mixer73]

Isn't DS a student? He is a talent just like me. I do mean I can improve the encoding speed by 20-30% without loosing quality.

I regard DS very highly, and his record speaks for itself.

If you really believe you can make these improvements then adding them to the already well supported and commonly used x264 is a much better path than creating your own, IMO. If you could increase the speed of x264 without affecting quality then I know it would make my life better!

Well I guess that's presuming you want to contribute to an open-source project, if you want to create your own encoder and sell it on a commercial basis good luck to you. I think people have been skeptical about you but I have been very impressed with DiAVC development so keep it up.

[cogman]

What I mean is that I can improve the x264 by 20-30% on speed without any compromise on quality.

I would be very impressed if you could manage that. What kind of changes would you make to gain that speed increase?

[ChronoCross]

I would be very impressed if you could manage that. What kind of changes would you make to gain that speed increase?

Add another 4 Core CPU to his machine! :devil:

[Stephen R. Savage]

Well, technically, using more threads in x264 will marginally degrade quality.

Here are some test results on DiAVC beta 2 (animu, varying bitrates from 700k/s to 7M/s, decreasing order of complexity).

5 Centimeters Per Second Extra 1080p (BluRay rip)
=================================================
CoreAVC 2.0 (64.1348) = 100%
63.5516
64.5684
64.2931

DiAVC (71.8320) = 112%
71.2716
72.8452
71.4003

ffdshow (46.7246) = 72.9%
46.0793
47.0294
46.7246

Tokyo Marble Chocolate Ep01 1080p (BluRay rip)
==============================================
CoreAVC 2.0 (76.3160) = 100%
76.5588
77.0836
75.3270

DiAVC (83.5244) = 109%
83:5612
83.2876
83.7257

ffdshow (56.78999) = 74.4%
56.3272
56.6554
57.3977

Spice and Wolf OP 720p (BluRay rip)
===================================
CoreAVC 2.0 (139.5559) = 100%
140.3886
136.1467
142.2745

DiAVC (165.6420) = 119%
165.6403
165.7074
165.5785

ffdshow (97.5935) = 69.9%
96.6443
97.7885
98.3634

Ouran High School Host Club OP 480p (DVD rip)
=============================================
CoreAVC 2.0 (240.4225) = 100%
239.3994
241.5735
240.3045

DiAVC (274.6729) = 114%
279.1259
272.2296
272.7693

ffdshow (185.9762) = 77.4%
186.0935
186.3009
185.5357

Time of Eve Ep03 480p (DVD rip)
===============================
CoreAVC 2.0 (371.0522) = 100%
369.9309
372.2578
370.9752

DiAVC (378.1465) = 102%
380.0609
377.2871
377.1059

ffdshow (267.2392) = 72.0%
257.7283
270.5493
273.9981

Digital Juice: In the Evening of A Moonlit Night 360p (DVD rip, cropped)
========================================================================
CoreAVC 2.0 (472.2654) = 100%
474.4486
472.0129
470.3526

DiAVC (494.2979) = 105%
498.8704
489.8467
494.2590

ffdshow (324.6804) = 68.7%
329.0582
322.6528
322.4171

As usual, DiAVC wins. However, it seems that the performance advantage of DiAVC is limited in the low bitrate SD scenario. More remarkable is how consistently poor ffdshow performance is. I remember reading somewhere that libavcodec had actually overtaken CoreAVC in efficiency, but that doesn't seem to be the case.

[Dark Shikari]

As usual, DiAVC wins. However, it seems that the performance advantage of DiAVC is limited in the low bitrate SD scenario. More remarkable is how consistently poor ffdshow performance is. I remember reading somewhere that libavcodec had actually overtaken CoreAVC in efficiency, but that doesn't seem to be the case.I recall those benches of libavcodec beating CoreAVC came from tests using CoreAVC-for-mplayer, which always seemed to go a lot slower than native CoreAVC for some reason.

Tests on ARM using identical assembly code for CoreAVC and libavcodec and the exact same compiler put CoreAVC 2.0 a full 50% faster. libavcodec is pretty damn slow, and improving it would require a lot of re-architecting, unfortunately.

[schweinsz]

As usual, DiAVC wins. However, it seems that the performance advantage of DiAVC is limited in the low bitrate SD scenario. More remarkable is how consistently poor ffdshow performance is. I remember reading somewhere that libavcodec had actually overtaken CoreAVC in efficiency, but that doesn't seem to be the case.
Totally wrong, the DiAVC is more efficient on high bitrate, 7mbps is not a high bitrate for 1080p, you can try 30mbps, 50mbps. Internally, the DiAVC has a more efficient cabac module.

[schweinsz]

I would be very impressed if you could manage that. What kind of changes would you make to gain that speed increase?
Could somebody give me a complexity list by function in x264? I will improve it one by one!

[avivahl]

Could somebody give me a complexity list by function in x264? I will improve it one by one!http://forum.doom9.org/showpost.php?p=1363693&postcount=483

[weasel_]

can`t wait to see 20-30% improve in speed without lose quality ...

[Dark Shikari]

Could somebody give me a complexity list by function in x264? I will improve it one by one!Here is the most recent profile on Akuvian.org (http://akuvian.org/src/x264/x264_prof_r1239.tar.bz2).

I recommend you use oprofile to do your own profiling and bench.h (http://pastebin.com/m26375e4c) to test code snippets. How to use bench.h:

#include "bench.h"

somefunction()
{
...
START_TIMER;
<lots of stuff>
STOP_TIMER("my stuff");
...
}

It will automatically calculate the number of clocks taken by the intermediate code on runtime and compensate for context switches.

Do note that it's highly recommended you calibrate it for your system first: simply run it with nothing in between START and STOP timer, and tune NOP_CYCLES until it reports 0 clocks for an "empty" timer.

To bench assembly code:

make checkasm;./checkasm --bench=functionname

To test assembly code for accuracy:

make checkasm;./checkasm

Finally, get on #x264dev IRC on Freenode so we can work with you directly!

[schweinsz]

Firstly I can give some advices on ME, only a first appearance.

about the x264_pixel_sad
Before sad computation, copy the current part16x16 or all 8x8 block to xmm0-xmmx, then each a sad is needed, the current block is not to be loaded into the sse2 register. Only 4 sse2 registers is needed for a 8x8 block, and for 16x16 block, only part of it can be pre-loaded into registers.

about x264_pixel_avg2
sum (abs(a-((c+d+1)>>1))), assume the a is current pel, c is best half pel, d is searched.
A fast algorithm: e=(2a-c+1) or (2a-c-1) is computed firstly, then compute f = sum (abs(e-d)) >>1;
most of the average operation is abbreviated by a pre-computation. The rounding need to be adjusted carefully.

I am curious that the x264_me_search_ref and refine_subpel use a comparible time with the sad computation. Why?
Perhaps sse2 code is needed for them.

The optimazation of satd is really hard. But the 128bit register can treat two 4x4 block satd. Which file are there the x264_pixel_satd_8x8_internal_ssse3 and x264_pixel_satd_16x4_internal_ssse3 in?

Recently I have no time to code for x264 because the DiAVC is not finished.

[Dark Shikari]

Firstly I can give some advices on ME, only a first appearance.

about the x264_pixel_sad
Before sad computation, copy the current part16x16 or all 8x8 block to xmm0-xmmx, then each a sad is needed, the current block is not to be loaded into the sse2 register. Only 4 sse2 registers is needed for a 8x8 block, and for 16x16 block, only part of it can be pre-loaded into registers.Already considered this. Impossible for p16x16, reasonable for p8x16/p16x8 on 64-bit and p8x8 on 32-bit. For p8x8, however, this would probably only be feasible on the Nehalem/Phenom, because the penalty for the time spent loading 8-byte sections (the reference frame data) and packing them into 16-byte registers for comparison is probably too high on any other CPU.

Do note that the vast majority of time in me.c is spent doing SAD_X3 and SAD_X4 on unaligned data, so saving redundant fast aligned accesses in this manner will probably have a very small benefit. It might also break autovectorizing compilers like ICC.about x264_pixel_avg2
sum (abs(a-((c+d+1)>>1))), assume the a is current pel, c is best half pel, d is searched.
A fast algorithm: e=(2a-c+1) or (2a-c-1) is computed firstly, then compute f = sum (abs(e-d)) >>1;
most of the average operation is abbreviated by a pre-computation. The rounding need to be adjusted carefully.I doubt this will help; SAD is only used in hpel, not qpel, and hpel takes a shortcut that allows it to halve the amount of interpolation necessary. It might be useful in predictor checking.

Also, do note that having too many special-purpose SAD functions and similar is potentially bad: putting a large amount of pressure on the code cache for the benefit of a small part of x264 may have negative consequences overall.

Furthermore, calculating 2a-c+1 may require some hacky bit math in order to avoid unpacking to 16-bit.I am curious that the x264_me_search_ref and refine_subpel use a comparible time with the sad computation. Why?
Perhaps sse2 code is needed for them.SAD is extremely fast, especially with the merged SADs. Despite very heavy work on optimizing me.c's C code, there's still a lot of overhead, in large part because the asm code is simply so fast. If you use UMH, you'll notice the ratio of SAD to C code goes way up, since a whole lot more SADs are called.

We've experimented with SIMD for things like the COPY_IF_LT sections (phminposuw) and have generally concluded that an appropriately-constructed cmov sequence is more efficient. That's why DIA/HEX/UMH use that nigh-incomprehensible bitmasking method: to make cmov sequences more efficient.The optimazation of satd is really hard. But the 128bit register can treat two 4x4 block satd. Which file are there the x264_pixel_satd_8x8_internal_ssse3 and x264_pixel_satd_16x4_internal_ssse3 in?I strongly doubt you will be able to optimize SATD significantly further; Holger literally made his thesis on these functions and was able to gain enormous benefits. I don't think there's much more to squeeze out of it. The code is in common/x86/pixel-a.asm.Recently I have no time to code for x264 because the DiAVC is not finished. Nothing wrong with that--don't want to rush you. Having a good decoder is just as important as having a good encoder.

But when you do want to work on x264, please drop by #x264dev on Freenode ;)

[schweinsz]

The ssd_ssse3 computation is not clever.

movdqa c, b
psubusb c, a
psubusb a, b
paddb a, c
movdqa c, a
pand a, 0x7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f
pmaddubsw a, a
pand c, 0x80808080808080808080808080808080
pshrw c, 1
pmaddubsw c, c
pshlw c, 2
paddw a,c

[schweinsz]

Already considered this. Impossible for p16x16, reasonable for p8x16/p16x8 on 64-bit and p8x8 on 32-bit. For p8x8, however, this would probably only be feasible on the Nehalem/Phenom, because the penalty for the time spent loading 8-byte sections (the reference frame data) and packing them into 16-byte registers for comparison is probably too high on any other CPU.
Do note that the vast majority of time in me.c is spent doing SAD_X3 and SAD_X4 on unaligned data, so saving redundant fast aligned accesses in this manner will probably have a very small benefit.
Why is this feasible for p8x8 only on Nehalem/Phenom? movlps and movhps will help and there is no packing.
From the profiling result, the sad16x16 is comparible with the SAD_X3 and SAD_X4. This is out my expection actually.

I doubt this will help; SAD is only used in hpel, not qpel, and hpel takes a shortcut that allows it to halve the amount of interpolation necessary. It might be useful in predictor checking.
Also, do note that having too many special-purpose SAD functions and similar is potentially bad: putting a large amount of pressure on the code cache for the benefit of a small part of x264 may have negative consequences overall.

Furthermore, calculating 2a-c+1 may require some hacky bit math in order to avoid unpacking to 16-bit.SAD is extremely fast, especially with the merged SADs. Despite very heavy work on optimizing me.c's C code, there's still a lot of overhead, in large part because the asm code is simply so fast. If you use UMH, you'll notice the ratio of SAD to C code goes way up, since a whole lot more SADs are called.
Computing 2a-c+1 is really easy.
movdqa c, b
movdqa d, a
psubusb c, a
psubusb a, b
paddusb d,a
psubusb d, c
In my opinion, it is useful. I know the avg_func is used for qpel search. the computation (2a-c+1) is needed once, while the qpel check is needed several times. Avery time the average+sad is substituded by sad. note that a block is not to be loaded. The method can be combined with pre-loading current block to gain more. The avg_func is totally not needed.
Actually the needed code is reduced.




We've experimented with SIMD for things like the COPY_IF_LT sections (phminposuw) and have generally concluded that an appropriately-constructed cmov sequence is more efficient. That's why DIA/HEX/UMH use that nigh-incomprehensible bitmasking method: to make cmov sequences more efficient.I strongly
I will look into it more to find some optimization.

doubt you will be able to optimize SATD significantly further; Holger literally made his thesis on these functions and was able to gain enormous benefits. I don't think there's much more to squeeze out of it. The code is in common/x86/pixel-a.asm.Nothing wrong with that--don't want to rush you. Having a good decoder is just as important as having a good encoder.

But when you do want to work on x264, please drop by #x264dev on Freenode ;)
As regarding to SATD, if the value is very small, you can compute it using 8bit, but this is often impossible.

[Dark Shikari]

Why is this feasible for p8x8 only on Nehalem/Phenom? movlps and movhps will help and there is no packing.Look at the SAD 8x16 SSE functions. They use movhps to do width-8 SADs in SSE and are slower on many CPUs. Don't ask me why, but it is. I suspect merging penalties and/or slower-than-expected SSE units.

Computing 2a-c+1 is really easy.
movdqa c, b
movdqa d, a
psubusb c, a
psubusb a, b
paddusb d,a
psubusb d, c
In my opinion, it is useful. I know the avg_func is used for qpel search. the computation (2a-c+1) is needed once, while the qpel check is needed several times. Avery time the average+sad is substituded by sad. note that a block is not to be loaded. The method can be combined with pre-loading current block to gain more. The avg_func is totally not needed.
Actually the needed code is reduced.Are you proposing caching this data for every possible qpel position? This would increase memory usage by a factor of 4 and cause a catastrophic penalty due to cache thrashing.As regarding to SATD, if the value is very small, you can compute it using 8bit, but this is often impossible.Yeah, we considered that, but as you said, it's generally not possible.The ssd_ssse3 computation is not clever.

movdqa c, b
psubusb c, a
psubusb a, b
paddb a, c
movdqa c, a
pand a, 0x7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f
pmaddubsw a, a
pand c, 0x80808080808080808080808080808080
pshrw c, 1
pmaddubsw c, c
pshlw c, 2
paddw a,c(From IRC, where you should be: )
03:31 < holger_> nehalem isn't going to like the shifts. might help on conroe once you rearrange the code to pipeline the pmadd
03:33 < holger_> because on nehalem they're p1 only (IIRC)
03:34 < holger_> otoh, it might just work out. those are 12 insns with 4 going to p1 only

[schweinsz]

Are you proposing caching this data for every possible qpel position? This would increase memory usage by a factor of 4 and cause a catastrophic penalty due to cache thrashing.
No, I propose to cache the data every best half-pel position.
After a half-pel search a best half-pel position b is gotten. compute the (2a-b+1), search around the best half-pel position b.
Now the avg is not needed, only sad is needed.

[schweinsz]

03:31 < holger_> nehalem isn't going to like the shifts. might help on conroe once you rearrange the code to pipeline the pmadd
03:33 < holger_> because on nehalem they're p1 only (IIRC)
03:34 < holger_> otoh, it might just work out. those are 12 insns with 4 going to p1 only
But is nehalem like punpck? There is only 2 shift. To the best of my knowledge, punpck is slow for almost all cpu.

[Dark Shikari]

No, I propose to cache the data every best half-pel position.
After a half-pel search a best half-pel position b is gotten. compute the (2a-b+1), search around the best half-pel position b. Now the avg is not needed, only sad is needed.One thing you should be cautious of: "hpel search" in refine_subpel does not only search hpel positions. "bmx/bmy" may begin at a qpel position. Rather, it searches in hpel intervals.But is nehalem like punpck? There is only 2 shift. To the best of my knowledge, punpck is slow for almost all cpu.Nehalem can do 2 unpacks per cycle, but only 1 shift.

Of course, that's no reason to not try it, since even if it's faster on just one CPU, it's worth keeping.

I'll try it later if you don't have time to submit a patch. Working right now on eliminating some redundant predict_mv calls.

[schweinsz]

One thing you should be cautious of: "hpel search" in refine_subpel does not only search hpel positions. "bmx/bmy" may begin at a qpel position. Rather, it searches in hpel intervals.
This is not a problem. if it is started from a qpel position, round it to hpel and start, perhaps there is more computation of (2a-b+1), but this is not a problem because the avg is always more than the center. There is some design in architecture.
Oh, this method can be used in bi-direction search. It is sure to accelerate it very much.

[schweinsz]

Nehalem can do 2 unpacks per cycle, but only 1 shift.

Of course, that's no reason to not try it, since even if it's faster on just one CPU, it's worth keeping.

I'll try it later if you don't have time to submit a patch. Working right now on eliminating some redundant predict_mv calls.
Oh, I get a new idea. Eliminate the shift.
as the c is 0 or 128, so
pmaddubsw c, c
pand c, 0x80008000800080008000800080008000
because 0x80*0x80 = 0x8000 = 0x80*-0x80=0xc000&0x8000

[schweinsz]

#define COST_MV_X3_DIR( m0x, m0y, m1x, m1y, m2x, m2y, costs )\
{\
uint8_t *pix_base = p_fref_w + bmx + bmy*stride;\
h->pixf.fpelcmp_x3[i_pixel]( p_fenc,\
pix_base + (m0x) + (m0y)*stride,\
pix_base + (m1x) + (m1y)*stride,\
pix_base + (m2x) + (m2y)*stride,\
stride, costs );\
(costs)[0] += BITS_MVD( bmx+(m0x), bmy+(m0y) );\
(costs)[1] += BITS_MVD( bmx+(m1x), bmy+(m1y) );\
(costs)[2] += BITS_MVD( bmx+(m2x), bmy+(m2y) );\
}

COST_MV_X3_DIR( hex2[dir+0][0], hex2[dir+0][1],
hex2[dir+1][0], hex2[dir+1][1],
hex2[dir+2][0], hex2[dir+2][1],
costs );
bcost &= ~7;
COPY1_IF_LT( bcost, (costs[0]<<3)+1 );
COPY1_IF_LT( bcost, (costs[1]<<3)+2 );
COPY1_IF_LT( bcost, (costs[2]<<3)+3 );
if( !(bcost&7) )
break;
dir += (bcost&7)-2;
dir = mod6m1[dir+1];
bmx += hex2[dir+1][0];
bmy += hex2[dir+1][1];

Some constant values such as (m0x) + (m0y)*stride, (m1x) + (m1y)*stride can be computed and stored in a table before a picture is coded, when use it, load it by movq and compute the pix_base + (m0x) + (m0y)*stride, pix_base + (m1x) + (m1y)*stride in parallel.
Optimization of (costs)[0] += BITS_MVD( bmx+(m0x), bmy+(m0y) ) is probabily difficult.
But It can be gotten before h->pixf.fpelcmp_x3[i_pixel] and stored into a buffer, the sad is loaded by movq or movdqa and add the mvd, then process the COPY1_IF_LT in parallel. This is my thought.

[Dark Shikari]

Oh, I get a new idea. Eliminate the shift.
as the c is 0 or 128, so
pmaddubsw c, c
pand c, 0x80008000800080008000800080008000
because 0x80*0x80 = 0x8000 = 0x80*-0x80=0xc000&0x800007:21 < holger_> Dark_Shikari: i now see the problem with that approach. we end up with words that we still need to sum to doubles. he conveniently forgot to add the instructions needed for that.
07:22 < holger_> it's probably going to be another round of pmaddwd with (1,1,1...)
07:22 < Dark_Shikari> and what about the second approach I linked?
07:23 < holger_> same problem. still words.
07:23 < Dark_Shikari> is it any faster?
07:24 < holger_> haven't tried anything yet, won't till sunday at the earliest. feel free to experiment ;)

You should come on IRC ;)

[bob0r]

...

You should come on IRC ;)

And rename DiAVC.ax to x264.ax :)

[grv575]

as opposed to a new fast-but-crappy encoder,
...
is rather obnoxious and a waste of everyone's time.

Ahem.

[Dark Shikari]

Ahem.Ahem what? Were the previous threads not enough--have you come to troll this thread too? :rolleyes:

[schweinsz]

07:21 < holger_> Dark_Shikari: i now see the problem with that approach. we end up with words that we still need to sum to doubles. he conveniently forgot to add the instructions needed for that.
07:22 < holger_> it's probably going to be another round of pmaddwd with (1,1,1...)
07:22 < Dark_Shikari> and what about the second approach I linked?
07:23 < holger_> same problem. still words.
07:23 < Dark_Shikari> is it any faster?
07:24 < holger_> haven't tried anything yet, won't till sunday at the earliest. feel free to experiment ;)

You should come on IRC ;)
Yes, there BE some problems in my ssd algorithm, I re-calculate the needed cycles, it is not efficient, give up it.
In other aspect, the ssd_func is not a time-comsuming function from the profiling data.

[Dark Shikari]

Yes, there BE some problems in my ssd algorithm, I re-calculate the needed cycles, it is not efficient, give up it.No point in ruling it out until it's tested. I wrote up your function, but it doesn't give correct results:

INIT_XMM
cglobal x264_pixel_ssd_16x16_ssse3, 4,5
mov r4, 16
pxor xmm7, xmm7
.loop:
movdqa xmm0, [r0]
movdqa xmm1, [r2]
movdqa xmm2, xmm1
psubusb xmm2, xmm0
psubusb xmm0, xmm1
paddb xmm0, xmm2
movdqa xmm2, xmm0
pand xmm0, [pb_127 GLOBAL]
pmaddubsw xmm0, xmm0
pand xmm2, [pb_128 GLOBAL]
psrlw xmm2, 1
pmaddubsw xmm2, xmm2
psrlw xmm2, 2
paddw xmm0, xmm2
pmaddwd xmm0, [pw_1]
paddw xmm7, xmm0
add r0, r1
add r2, r3
dec r4
jg .loop
HADDD xmm7, xmm1
movd eax, xmm7
RET

[schweinsz]

No point in ruling it out until it's tested. I wrote up your function, but it doesn't give correct results:

INIT_XMM
cglobal x264_pixel_ssd_16x16_ssse3, 4,5
mov r4, 16
pxor xmm7, xmm7
.loop:
movdqa xmm0, [r0]
movdqa xmm1, [r2]
movdqa xmm2, xmm1
psubusb xmm2, xmm0
psubusb xmm0, xmm1
paddb xmm0, xmm2
movdqa xmm2, xmm0
pand xmm0, [pb_127 GLOBAL]
pmaddubsw xmm0, xmm0
pand xmm2, [pb_128 GLOBAL]
psrlw xmm2, 1
pmaddubsw xmm2, xmm2
psrlw xmm2, 2
paddw xmm0, xmm2
pmaddwd xmm0, [pw_1]
paddw xmm7, xmm0
add r0, r1
add r2, r3
dec r4
jg .loop
HADDD xmm7, xmm1
movd eax, xmm7
RET
There is a mistake I made, because I get the algorithm at a glance.
(a+b)*(a+b) !=a*a+b*b
but it can be computed as a*(a+b)+b(a+b)
So modify it to:
INIT_XMM
cglobal x264_pixel_ssd_16x16_ssse3, 4,5
mov r4, 16
pxor xmm7, xmm7
pxor xmm3, xmm3
.loop:
movdqa xmm0, [r0]
movdqa xmm1, [r2]
movdqa xmm2, xmm1
psubusb xmm2, xmm0
psubusb xmm0, xmm1
paddb xmm0, xmm2
movdqa xmm2, xmm0
movdqa xmm1, xmm0
pavgb xmm1, [pb_0 GLOBAL]
pand xmm2, [pb_1 GLOBAL]
pmaddubsw xmm2, xmm0
pmaddubsw xmm0, xmm1
paddw xmm3, xmm2
pmaddwd xmm0, [pw_1]
paddw xmm7, xmm0
add r0, r1
add r2, r3
dec r4
jg .loop
pmaddwd xmm3, [pw_1]
pslld xmm7, 1
psubd xmm7, xmm3
HADDD xmm7, xmm1
movd eax, xmm7
RET
Hope this is correct, there remains an optimization, pre-load the constant number [pb_0 GLOBAL], [pb_1 GLOBAL] and [pw_1] to xmm4, xmm5, xmm6.

[Dark Shikari]

Hope this is correct, there remains an optimization, pre-load the constant number [pb_0 GLOBAL], [pb_1 GLOBAL] and [pw_1] to xmm4, xmm5, xmm6.Of course, I was leaving those open so I could unroll the loop though.

[schweinsz]

DiAVC:

User: 13s, kernel: 0s, total: 13s, real: 132s, fps: 303.4, dfps: 31.8

CoreAVC 1.9.5:

User: 99s, kernel: 0s, total: 99s, real: 104s, fps: 42.3, dfps: 40.3

ffmpeg-mt, 1 thread:

User: 116s, kernel: 0s, total: 117s, real: 121s, fps: 36.0, dfps: 34.6

ffmpeg-mt, 4 threads:

User: 12s, kernel: 0s, total: 12s, real: 139s, fps: 343.2, dfps: 30.3

libavcodec:

User: 115s, kernel: 0s, total: 115s, real: 121s, fps: 36.6, dfps: 34.8

Apple trailer, 1080p24. With DiAVC I can't do anything else, Windows is sloooow. Even closing MPC-HC takes at least 5 seconds. And all of them stutter with some parts of the video, CoreAVC may look faster and enough here but in reality it isn't.
I get the reason finally. Recently I downloaded some 720p and 1080p movie trailers on internet. All of them are with cavlc while the cavlc module in DiAVC is slow and it is under optimization. I will optimize it recently. You can try some cabac materials on your PentiumM. It is not due to the slow sse2 and unefficient threading support in PentiumM mainly.

[STaRGaZeR]

I get the reason finally. Recently I downloaded some 720p and 1080p movie trailers on internet. All of them are with cavlc while the cavlc module in DiAVC is slow and it is under optimization. I will optimize it recently. You can try some cabac materials on your PentiumM. It is not due to the slow sse2 and unefficient threading support in PentiumM mainly.

Any special sample you want me to test?

[schweinsz]

Any special sample you want me to test?
After I release the cavlc-enhanced version, you can test it with the movie trialers.

[LigH]

A lot of x264 encoding optimization here in this thread about the DiAVC decoder... :rolleyes:

Useful, nevertheless. But - why here? Could this be cut off to an own thread?

[schweinsz]

Tomorrow I will release the DiAVC rc version. It is the last msvc build version. I have changed to the intel compiler, but it gives fault mbaff decoding. I will fix the problem and release the intel compiled version.
By the end of the month, the DiAVC 1.0 will be out.

[Selur]

By the end of the month, the DiAVC 1.0 will be out.
Nice! (hoping for a 64bit version :))

Cu Selur

[sneaker_ger]

Will the final version support non-SSE2 CPUs?

[schweinsz]

Will the final version support non-SSE2 CPUs?
No, I will code mmx version in next month.

[the_corona]

Is the final payware then? Any pricing infos yet? What about upgrades to the other features you mentioned (superresolution etc)?

[schweinsz]

Is the final payware then? Any pricing infos yet? What about upgrades to the other features you mentioned (superresolution etc)?
It is very cheap (similar price with CoreAVC). And all upgrades such as super-resolution and some other feature or processing in future are free for DiAVC users.

[Stephen R. Savage]

I know you've posted it a few times, but I thought I'd ask you to clarify future plans for DiAVC one last time.

What feature set is planned for inclusion in the final version? Are any further enhancements planned for releases after the final version? Do you think there is any room left for further decoder optimisation? Are there plans to separate the decoder core from the DShow filter and license it separately?

[schweinsz]

A new version is available.
changes:
Repeatly using threads.
More SSE2 codes (4% faster than the last version).

I will add the rgb24 and rgb32 support tomorrow perhaps.

[schweinsz]

I know you've posted it a few times, but I thought I'd ask you to clarify future plans for DiAVC one last time.

What feature set is planned for inclusion in the final version? Are any further enhancements planned for releases after the final version? Do you think there is any room left for further decoder optimisation? Are there plans to separate the decoder core from the DShow filter and license it separately?

The final version 1.0 will include improved cavlc, more colorspace (NV12, rgb32, rgb24) and scaling of level (TV or PC level) adaptively, and I will improve the DiAVC after the release 1.0 continuitily, such as mmx code, super-resolution, 64bit, post-processing, etc.
There remains many room for further decoder optimization, such as switching to intel compiler, improvment on function call, more efficient data structure and optimization using advanced instruction set, etc.
I am very glad to seperate the decoder and license it separately. Actually there has being a sdk on the site. Selling the source code directly is considerable, if somebody or company can give an approximate $, I can sell the source code and my maintainment of the source code to them.

[IgorC]

Wonder what % of non-SSE2 CPUs are still around.

Poll:What instruction set has your CPU up to? (http://forum.doom9.org/showthread.php?t=152330)

[canTsTop]

Video cut with VideoReDo 4 have problem, playback is not smooth http://www.mediafire.com/?zzkzyjgmihu
and if i seek in mpc-hc there is no video for 5 or more seconds

[schweinsz]

Video cut with VideoReDo 4 have problem, playback is not smooth http://www.mediafire.com/?zzkzyjgmihu
and if i seek in mpc-hc there is no video for 5 or more seconds
I am sorry that I can't get to the mediafire, could you upload it to multiupload.com?

[canTsTop]

here it is http://www.multiupload.com/6SV0WZM91Q

[schweinsz]

here it is http://www.multiupload.com/6SV0WZM91Q

Ok, I will look into it tomorrow, I will go to bed today.

[kolak]

Kaspersky is reporting some trojan in the exe settings file.
False alarm?

Andrew

[Stephen R. Savage]

kolak, the source code of the settings file is available on the DiAVC website, so you can see for yourself if it has a virus. I believe this is an issue with Kaspersky, and Lord_Mulder claimed that it was fixed upstream a few pages back.

Edit: Seems it was Avira that got fixed. Also, congratulations on the RC release, schweinsz. I can comment that I have seen a 15% performance increase in low-bitrate SD samples (as well as the 4% on medium-high bitrate).

Edit2: Is lossless support planned for 1.0 or a future release? For me, support of lossless streams is critical.

[LoRd_MuldeR]

False alarm?

YES !!!

You should report the FALSE POSITIVE to Kaspersky, so they can fix it. The same way Avira did, after my report...

http://forum.doom9.org/showpost.php?p=1352801&postcount=270

[schweinsz]

Edit2: Is lossless support planned for 1.0 or a future release? For me, support of lossless streams is critical.
It is in plan after 1.0 release. Lossless supporting is easy because only few functions is needed.

[kolak]

YES !!!

You should report the FALSE POSITIVE to Kaspersky, so they can fix it. The same way Avira did, after my report...

http://forum.doom9.org/showpost.php?p=1352801&postcount=270

OK :)


Andrew

[stax76]

You should report the FALSE POSITIVE to Kaspersky

Or alternatively uninstall the software, I'm using computers since 15 years and never used any security software and never had a single infection, at least not one that I noticed.

[Keiyakusha]

What about DGAVCIndex with DiAVC support... any news?

[Guest]

What about DGAVCIndex with DiAVC support... any news? I had started working on it but got distracted by some needed work to DGDecNV. I hope to come back to it soon, maybe as early as this evening!

[audyovydeo]

I had started working on it ... I hope to come back to it soon, maybe as early as this evening!


Applause !
I for one am still bleeding from the loss of DGAVCDec ... especially since I bought an AVCHD camera the day it was killed !


cheers
audyovydeo

[tommy_vercetti]

Applause !
I for one am still bleeding from the loss of DGAVCDec ... especially since I bought an AVCHD camera the day it was killed !


cheers
audyovydeo

You could look into DGNV Tools I think they perform a similar role

[audyovydeo]

You could look into DGNV Tools I think they perform a similar role

I CUDA looked into it had my card allowed it ...

(sorry it was an irresistible impulse ! ;-)

cheers
a/v

[schweinsz]

I have finished all colorspace-related works yesterday including nv12, yuy2, uyvy, rgb32, rgb24 and level scaling. I will work on a property page.
I finished a function about cavlc just now. All works about improved cavlc is more time-consuming than I estimated. Perhaps the DiAVC 1.0 will not include the improved cavlc and it will be available in one week after the release of DiAVC 1.0.

[Stephen R. Savage]

I don't mean to second-guess you, but I just hope you would reassure us on some issues that seem endemic to colorspace conversion implementations:

1) What method will you use for interpolation of chroma when converting to YUY2 or to RGB? Will you implement a linear or cubic chroma interpolation instead of nearest-neighbor?

2) Have you implemented correct reading of colormatrix (and fullrange) flag from AVC stream and the appropriate Rec601 and Rec709 coefficients?

[schweinsz]

1) What method will you use for interpolation of chroma when converting to YUY2 or to RGB? Will you implement a linear or cubic chroma interpolation instead of nearest-neighbor?
The current inplementation uses nearest-neighbor. If peoples like more accurate one, I can implement it.

2) Have you implemented correct reading of colormatrix (and fullrange) flag from AVC stream and the appropriate Rec601 and Rec709 coefficients?
Yes, the DiAVC read the vui for colormatrix and fullrange information.

[Asmodian]

The current inplementation uses nearest-neighbor. If peoples like more accurate one, I can implement it.


Yes, the DiAVC read the vui for colormatrix and fullrange information.

Here at doom9 there are people that always like a more accurate one, spline64 should be sufficient though. ;)

Thanks for the great work. :)

[Keiyakusha]

spline64 should be sufficient though. ;)

meh... thats too slow. after bicubic you won't notice any improvements unless you making screenshots and comparing them under 400% NN zoom. And even then its hard to see something.

[Asmodian]

meh... thats too slow. after bicubic you won't notice any improvements unless you making screenshots and comparing them under 400% NN zoom. And even then its hard to see something.

hehe yes, sorry I was joking - bicubic would be great. I was just pointing out that if you ask the doom9 community if we want a more accurate resize we will say yes, and lots of options too please. :)

[Stephen R. Savage]

Imo, nearest-neighbor interpolation for chroma is unacceptable, as it creates heavy aliasing near red/blue transitions. I think linear or cubic interpolation would be the best compromise between speed and quality for chroma.

[schweinsz]

Imo, nearest-neighbor interpolation for chroma is unacceptable, as it creates heavy aliasing near red/blue transitions. I think linear or cubic interpolation would be the best compromise between speed and quality for chroma.
Ok, I will consider it just after 1.0 release.

[Keiyakusha]

Hi. I'm using win7 32bit. I have mkv file with 2 AVC streams. One is 1280x720 and another is 720x480(16x9 DAR). I'm using latest haali splitter to split it and MPC-HC (EVR-CP) for playback.
Depending on which stream is set to be default in container, If I'll switch from 720p to 480p I'm getting this kind of screen (http://imgur.com/kcyYW.jpg).
If 480p is set to be default, and i'll go to 720p, I'm getting some emergency shutdown which is probably some equivalent to BSOD on win7.

With FFDShow (not DXVA) works perfect.
If second stream is not AVC, all works fine but the stream I switching to has problems with aspect ratio. Which is also fine with ffdshow.

EDIT: this is with DiAVC RC1

[IgorC]

schweinsz,

Do you plan to support ARM? This year there will be a lot of new ARM based mobile devices. Corecodec and x264 have already prepared for this. No need to mention how Corecodec dominates with its CorePlayer in area of smart phones.

What a big deal around of non-SSE2 CPU support?
I mean I have an old PC with Prescott 3.06 GHZ+HT which I don't run anymore but even this dinosaur has SSE3 and plays 1080p 10-12 Mbits videos. And DiAVC is the fastest decoder on it. Ok, some people have an old CPUs but the poll (http://forum.doom9.org/showthread.php?t=152330) shows with a good estimation that there are enough few of them. ~10-15%. This percentage will shrink quickly in 1-2 years.
While there are a lot of new CPUs especially (ultra) low voltage wich aren't enough fast. (mobile dual core i3/i5 <2 Ghz even w/Turbo).

[schweinsz]

Hi. I'm using win7 32bit. I have mkv file with 2 AVC streams. One is 1280x720 and another is 720x480(16x9 DAR). I'm using latest haali splitter to split it and MPC-HC (EVR-CP) for playback.
Depending on which stream is set to be default in container, If I'll switch from 720p to 480p I'm getting this kind of screen (http://imgur.com/kcyYW.jpg).
If 480p is set to be default, and i'll go to 720p, I'm getting some emergency shutdown which is probably some equivalent to BSOD on win7.

With FFDShow (not DXVA) works perfect.
If second stream is not AVC, all works fine but the stream I switching to has problems with aspect ratio. Which is also fine with ffdshow.

EDIT: this is with DiAVC RC1
I am sorry that the current DiAVC doesn't support the dynamic format change.

[schweinsz]

schweinsz,

Do you plan to support ARM? This year there will be a lot of new ARM based mobile devices. Corecodec and x264 have already prepared for this. No need to mention how Corecodec dominates with its CorePlayer in area of smart phones.

What a big deal around of non-SSE2 CPU support?
I mean I have an old PC with Prescott 3.06 GHZ+HT which I don't run anymore but even this dinosaur has SSE3 and plays 1080p 10-12 Mbits videos. And DiAVC is the fastest decoder on it. Ok, some people have an old CPUs but the poll (http://forum.doom9.org/showthread.php?t=152330) shows with a good estimation that there are enough few of them. ~10-15%. This percentage will shrink quickly in 1-2 years.
While there are a lot of new CPUs especially (ultra) low voltage wich aren't enough fast. (mobile dual core i3/i5 <2 Ghz even w/Turbo).
I will consider the arm platform. Actually I am more skilled with the arm platform even than x86 platform. But I must be sure the main platform that need a fast H.264 decoder.
CPU with wMMX, CPU with NEON or some old arm9 and arm11?
Windows mobile or android?

[IgorC]

I will consider the arm platform.
CPU with wMMX, CPU with NEON or some old arm9 and arm11?
Windows mobile or android?
Cortex A8/9 all the way.
And maybe ARM11. There are plenty of the devices which still based on it.
Not sure about OSs.

Some related info.
http://x264dev.multimedia.cx/?p=142

[schweinsz]

I uploaded a new DiAVCSetting version and the source code.
Some useless code is deleted.
I am very curious that two never-used functions related characters conversion mislead so many anti-virus to false positive.
Now only the norton reports Suspicious.Insight to the DiAVCSetting. How can I submit a report about the false positive to symantec?

[the_corona]

here: https://submit.symantec.com/dispute/false_positive/

[Virtual_ManPL]

...in other hand I find that seeking bug (you need to wait to see actual frames about 2-10s, sometimes even more than 20s) still exist in DiAVC decoder with EVR (C/A) in MPC-HC...

bug not fixed in RC1, will be nice to see it fixed in next release or at least in final ;)

[Stephen R. Savage]

I may have found a serious bug in DiAVC. When seeking backwards in video, sometimes the stream can degenerate into blocking artifacts. When this happens, these artifacts get progressively worse until an IDR is encountered. After being refreshed at the IDR, the video quickly breaks back down into blocks, and the only way to return to normal operation is to reopen the file. I have encountered this on two different streams now, but have unfortunately not been able to find a deterministic way of replicating it.

[schweinsz]

I may have found a serious bug in DiAVC. When seeking backwards in video, sometimes the stream can degenerate into blocking artifacts. When this happens, these artifacts get progressively worse until an IDR is encountered. After being refreshed at the IDR, the video quickly breaks back down into blocks, and the only way to return to normal operation is to reopen the file. I have encountered this on two different streams now, but have unfortunately not been able to find a deterministic way of replicating it.
Could you share the two bitstreams with me?

[Stephen R. Savage]

Unfortunately, I can not, for copyright reasons. Aside from that, I have not yet managed to replicate the problem, nor isolate any part of the bitstream that causes the issue, so I suspect it is random. The two bitstreams that I encountered this on were encoded with x264, but with much different settings/formats (480p, L3.1, weightp and 720p, L4.1, no weightp).

[Rumbah]

I have a problem with a x264 encoded video, I cut out a part with mp4box and sent a link via PM. The problem is that DiAVC freezes some frames, it looks smooth with ffdshow, CoreAVC and in VLC. Because of the freezes the video goes out of sync. (MPC-HC Win7)

[Astrophizz]

FYI, the trial period on RC1 is over.

[Virtual_ManPL]

FYI, the trial period on RC1 is over.

you can always change February to January in clock settings ;p

[LoRd_MuldeR]

you can always change February to January in clock settings ;p

It's not that easy :p

http://forum.doom9.org/showpost.php?p=1358861&postcount=425

[hajj_3]

this looks like an interesting h264 decoder:) Is there a native 64bit version? would be nice for MPC-HC 64bit build working with it. Also i'm assuming this uses CUDA? Will you be supporting ATI's STREAM? Keep up the good work, hope you can work with neuron as it seems coreavc don't want to.

[slavickas]

this looks like an interesting h264 decoder:) Is there a native 64bit version? would be nice for MPC-HC 64bit build working with it. Also i'm assuming this uses CUDA? Will you be supporting ATI's STREAM? Keep up the good work, hope you can work with neuron as it seems coreavc don't want to.

it doesnt use buzzwords like CUDA and STREAM

[hajj_3]

i'm not sure if your trying to be funny or not but CUDA and STREAM aren't buzzwords, they let the gpu do alot of the decoding, does this software allow the gpu to do some of the decoding?

[nm]

does this software allow the gpu to do some of the decoding?

No. It's purely CPU-based software decoder.

[schweinsz]

DiAVC 1.0.0 is released. It is on sale with $9.9. I am sorry that it is released so late. I met some problems with the property page and some others.
change logs:
20100213
DiAVC 1.0.0 is released.
Add a property page.
Add supports for PC and TV input/output level.
Add supports for settings of brightness offset, contrast, saturation and hue.
Add supports for NV12, YUY2, UYVY, RGB32 and RGB24.
Add the display of input level and colorspace in VUI on property page (click on it to update).
Add an installer.
Faster startup.
Slightly faster than rc version.
Fix a bug on bitstreams with fault reference frame re-ordering.

DiAVC1.0.0 Setup (http://di-avc.com/DiAVC1.0.0_Setup.zip)
I added the Microsoft_VC90_CRT_x86.msm and Microsoft_VC90_MFC_x86.msm to the setup package, so it is 10M bytes big.

You can try an alternative. It is small.
DiAVC1.0.0pack (http://di-avc.com/DiAVC1.0.0_pack.zip)

[Stephen R. Savage]

I am unable to understand how to install your software.

1) I downloaded DiAVC1.0.0_Setup.zip, but there were two files named "setup," one in MSI and the other in EXE.
2) The EXE tries to install .NET 3.5 on my system, which fails because Windows Server 2008 R2 does not allow .NET to be installed separately from the server role manager.
3) The MSI installs a folder named "DiAVCSetup," but when I try to run "DiAVC Registration.exe" it only reports diavc intialization failed."
4) I tried to open the .ZIP independently and run the included "DiAVC Registration.exe" but it shows a blank field for "RegisterCode."

schweinsz, could you please give more information on how to install your software.

[schweinsz]

Video cut with VideoReDo 4 have problem, playback is not smooth http://www.mediafire.com/?zzkzyjgmihu
and if i seek in mpc-hc there is no video for 5 or more seconds
In the DiAVC version 1.0 the problem is fixed. It is related to fault reference reordering.

[schweinsz]

I am unable to understand how to install your software.

1) I downloaded DiAVC1.0.0_Setup.zip, but there were two files named "setup," one in MSI and the other in EXE.
2) The EXE tries to install .NET 3.5 on my system, which fails because Windows Server 2008 R2 does not allow .NET to be installed separately from the server role manager.
3) The MSI installs a folder named "DiAVCSetup," but when I try to run "DiAVC Registration.exe" it only reports "could not initialize diavc."
4) I tried to open the .ZIP independently and run the included "DiAVC Registration.exe" but it shows a blank field for "RegisterCode."

schweinsz, could you please give more information on how to install your software.
From your info I get there is some problems with the setup program.
Running the "DiAVC Registration.exe" requires administrator domain because the DiAVC read the harddisk serial number using DeviceIoControl to compute the register code using some hash algorithm.

[Stephen R. Savage]

I have tried running "DiAVC Registration.exe" as administrator, but it does not change the results. I still get "DiAVC Initialization failed!"

Edit: Does your software require .NET 3.5 to be installed?

[schweinsz]

I have tried running "DiAVC Registration.exe" as administrator, but it does not change the results. I still get "DiAVC Initialization failed!"
Ok, open the graphstudio, load the DiAVC decoder and get its property page. Hope you have good luck.
Or, delete the registry key "HKEY_CLASSES_ROOT\CLSID\{083863F1-70DE-11d0-BD40-00A0C911CE86}\Instance\{5DFA20A4-C343-45DF-A46E-EC1711E4EE32}\rgtcode", and re-run the "DiAVC Registration.exe".

Download the diskid32.exe (http://www.winsim.com/diskid32/diskid32.exe) and run it, I can see if it is ok for smart getting harddisk serial number.
diskid32 is a tool that can get the harddisk info.
http://www.winsim.com/diskid32/diskid32.html
I use its SMART drive to get harddisk serial number. But I can't be sure if it is ok for all platforms.

[Stephen R. Savage]

I opened the property page using GraphStudio, but the "RegisterCode" field is blank. I could not locate the key "HKEY_CLASSES_ROOT\CLSID\{083863F1-70DE-11d0-BD40-00A0C911CE86}\Instance\{5DFA20A4-C343-45DF-A46E-EC1711E4EE32}\rgtcode" on my system.

The diskid.exe program reports the following:

To get all details use "diskid32 /d"

Trying to read the drive IDs using physical access with admin rights

Trying to read the drive IDs using the SCSI back door

Trying to read the drive IDs using physical access with zero rights

**** STORAGE_DEVICE_DESCRIPTOR for drive 0 ****
Vendor Id = [WDC WD80]
Product Id = [0BEVS-08RST2]
Product Revision = [08.0]
Serial Number = [WD-WXC608C18305]

**** DISK_GEOMETRY_EX for drive 0 ****
Disk is fixed
DiskSize = 80026361856

**** STORAGE_DEVICE_DESCRIPTOR for drive 1 ****
Vendor Id = [DMI]
Product Id = [External HDD]
Product Revision = []
Serial Number = [51D202230900]

**** DISK_GEOMETRY_EX for drive 1 ****
Disk is fixed
DiskSize = 320072933376

Trying to read the drive IDs using Smart

Hard Drive Serial Number__________: WD-WXC608C18305

Hard Drive Model Number___________: 0BEVS-08RST2

Computer ID_______________________: 609218305

MAC Address: 00-1F-3C-92-A4-BF

MAC Address: 00-21-86-5A-27-0C

Again, does your software have any new dependencies as of the v1.0 release.

[schweinsz]

I opened the property page using GraphStudio, but the "RegisterCode" field is blank. I could not locate the key "HKEY_CLASSES_ROOT\CLSID\{083863F1-70DE-11d0-BD40-00A0C911CE86}\Instance\{5DFA20A4-C343-45DF-A46E-EC1711E4EE32}\rgtcode" on my system.

The diskid.exe program reports the following:

Again, does your software have any new dependencies as of the v1.0 release.
The 1.0 release changes to dynamic link to dll, so it depends on mfc90u.dll and msvcr90.dll. While the old release all static link to run-time library and has no use of mfc.

Ok, I get the reason. The smart drive can't read your serial number.
Edit: Only the zero rights method managed to get the harddisk serial number correctly.

Very badly, I will fix the problem tomorrow.

[Stephen R. Savage]

I was looking in the wrong place. On Windows 64, the key was in HKCR\Wow6432Node. I have not applied any special permissions or configurations and I have mfc/msvcrt 9.0 installed.

[schweinsz]

I was looking in the wrong place. On Windows 64, the key was in HKCR\Wow6432Node. I have not applied any special permissions or configurations and I have mfc/msvcrt 9.0 installed.
Great thanks to your help. I have not enough different computers to test the decoder. So I meet some trouble inevitably. I will fix it as soon as possible.

[Stephen R. Savage]

On a related note, I would like to note my objection to hardware-tied licenses. I do not know when or if I will upgrade to install new hardware, but I know for certain that I would not be willing to buy a new license for each machine.

If possible, could you clarify on the terms of your DiAVC licensing, as there is no included information regarding such.

[Disabled]

Yep, I also want to know about the license and what I can expect from the future. If my license is tied to the hardware, I will not buy it. If you want me to buy a new license once I upgrade my main drive, forget it. If you would hand out new licenses in that case, forget it too. It already happened often enough, that companies shut down their registration servers and I was unable to use my legally bought software. Even CoreCodec had to learn that users don't want this crap.
Another question: Does the decoder support the full Main Profile? If not, what features are missing and what are your plans about not supported features?

[Fadeout]

I'm waiting for the e-mail with the password.

In the meantime I'll also complain about hardware-tied licenses. For example I was able to install CoreAVC 2 even on the other PC. More flexibility is desired.

[bob0r]

schweinsz, how much money would it take to change diavc.ax into x264.ax?

[Fadeout]

Nope, no mail here...

[Keiyakusha]

schweinsz, how much money would it take to change diavc.ax into x264.ax?

bob0r wants to buy DiAVC and make it opensource? :eek:

[Keiyakusha]

Actually don't know if it was joke, or not but I thought...
[dream_mode_ON]
If somewhere on x264.nl or somewhere else will be announcement like:
"Hey guys, do you want to see fastest opensource h264 decoder? If so - please make a donation NOW!"
Then many peoples will donate. Maybe this will be not enough, but also it is possible to find a sponsor.
If some companies will be able to use it just like they use x264, they maybe consider to donate!
[dream_mode_OFF]

[Stephen R. Savage]

Heh, yeah, can only wish ;)

[schweinsz]

I'm waiting for the e-mail with the password.

In the meantime I'll also complain about hardware-tied licenses. For example I was able to install CoreAVC 2 even on the other PC. More flexibility is desired.
I am sleeping when you pay. Now I send the password mail to you. Thank you very much.

[schweinsz]

On a related note, I would like to note my objection to hardware-tied licenses. I do not know when or if I will upgrade to install new hardware, but I know for certain that I would not be willing to buy a new license for each machine.

If possible, could you clarify on the terms of your DiAVC licensing, as there is no included information regarding such.
The current DiAVC design about registration is related to the harddisk0 and the cpu.

[schweinsz]

schweinsz, how much money would it take to change diavc.ax into x264.ax?
If somebody or some company can give me 200000USD, I can give them all the source.

[dwrbudr]

I think you should make your decoder not dependant on MFC and VS redistributables. Otherwise a lot of your time as support will be wasted, trust me :)

[Fadeout]

Using the same 1080 high bitrate clip (http://dl.getdropbox.com/u/132004/Planet_Earth_From%20Pole_to_Pole_1080p_sample_16ref.mkv) I get similar results I got with Beta 2:

DiAVC 1: 83.5
CoreAVC2: 63.5

Can't test on the other pc since the license doesn't allow me...

[bob0r]

If somebody or some company can give me 200000USD, I can give them all the source.

Hmm that's about 20 Euros. (or slightly more, 146875 Euros)

Joking aside, that seems about a fair price.
Giving the source is one thing, keep help developing is another. Would you still help with the development?

[Disabled]

The current DiAVC design about registration is related to the harddisk0 and the cpu.

And what if I change my processor or my harddrive? Do I have to pay again? And how does that work?
As I said, If I have to ask you if I want to change my harddrive, its a no go for me. DivX is not that much worse, so is CoreAVC and they don't have a stupid registration scheme.

[schweinsz]

Hmm that's about 20 Euros. (or slightly more, 146875 Euros)

Joking aside, that seems about a fair price.
Giving the source is one thing, keep help developing is another. Would you still help with the development?
If I get 200000USD, I can try my best to help developing the DiAVC H.264 decoder and x264 encoder. I ever said that I can improve it very much. I am a very poor man so I decide to develop software and sell it online, if I get the money, I can do my best to help all H.264 codec for open-source society.

[schweinsz]

And what if I change my processor or my harddrive? Do I have to pay again? And how does that work?
As I said, If I have to ask you if I want to change my harddrive, its a no go for me. DivX is not that much worse, so is CoreAVC and they don't have a stupid registration scheme.

According to the feedback, I decide to associate the serial number to e-mail. If you change your harddrive or cpu, notify me by the email you pay, I can send the new password to you.

[schweinsz]

I think you should make your decoder not dependant on MFC and VS redistributables. Otherwise a lot of your time as support will be wasted, trust me :)
Yes, I decide to do this. Thank you very much.

[Disabled]

According to the feedback, I decide to associate the serial number to e-mail. If you change your harddrive or cpu, notify me by the email you pay, I can send the new password to you.
Ok thanks, but thats still a no go for me. Like I said, no one can guarantee you still do that in two years. And I'll not buy a software I can't use because the developer doesn't trust the ones who gave him money. I wonder how long your protection won't be cracked...

[Selur]

If you change your harddrive or cpu,..
I hope only the main system hdd counts here,.. (switching my other hard drives on daily basis)
(+ will buy a copy once a 64bit version is out)

Cu Selur

[schweinsz]

I hope only the main system hdd counts here,.. (switching my other hard drives on daily basis)
(+ will buy a copy once a 64bit version is out)

Cu Selur
The DiAVC only read the physics drive0 and has non business with other drives.

[Stephen R. Savage]

I'm afraid I would have to agree with Disabled. I would be willing to pay double price for a copy not tied to hardware, but a restriction to HDD/CPU worries me greatly. I'm sure it will work fine in the short term, but I am concerned about the viability of my purchase once you have moved on to other projects, been bought out, etc, and no promise can ease that concern. Even having to repurchase a copy is not that big a deal, but the possibility that you will disappear a few years later and leave me stuck is, I hate to say, not completely unlikely.

Personally, I do not think piracy will cost you as many purchases as restrictive licensing.

Edit: On an unrelated note, are the issues regarding registration from last page fixed?

Edit2: I think the best chance of making a significant amount of money from DiAVC is to get some company to buy a site license or something similar, and I don't think a per-machine license would be received very well in such a case. Perhaps you could look into offering alternative licensing schemes.

[hajj_3]

are you really rich bob0r?

If you could buy it and release the sourcecode presumably it could be included in vlc and MPC-HC as the default decoder, how cool would be, millions of people would benefit.

I'm sure someone could create a mac version and integrate it into vlc too.

Lets hope this can happen as i'd hate for DivX to buy the sourcecode, open source would allow others to improve it and add it to vlc/mpc-hc.

[schweinsz]

I'm afraid I would have to agree with Disabled. I would be willing to pay double price for a copy not tied to hardware, but a restriction to HDD/CPU worries me greatly. I'm sure it will work fine in the short term, but I am concerned about the viability of my purchase once you have moved on to other projects, been bought out, etc, and no promise can ease that concern. Even having to repurchase a copy is not that big a deal, but the possibility that you will disappear a few years later and leave me stuck is, I hate to say, not completely unlikely.

Personally, I do not think piracy will cost you as many purchases as restrictive licensing.

Edit: On an unrelated note, are the issues regarding registration from last page fixed?

Edit2: I think the best chance of making a significant amount of money from DiAVC is to get some company to buy a site license or something similar, and I don't think a per-machine license would be received very well in such a case. Perhaps you could look into offering alternative licensing schemes.
If you buy one for a certain computer, it will work for you all along. Before I leave the project (perhaps this can't give me much money, or I am employed by some company so that I has no time with DiAVC (this is with vvvvvvvvvvery low probability)), I will release a last version with no restriction to HDD/CPU to all my customers.

edit: There is no reason to give up an earning-money project. If there are peoples who buy the software, why do I give up the business?

[Stephen R. Savage]

Well, to be honest, though I admit that DiAVC is a great piece of software, I am not entirely convinced that there is a large market for software AVC decoders. However, I will take your word for it and purchase a copy if the HDD detection/RegisterCode issue has been fixed. On another note, if I possess multiple computers, do I have to purchase a separate license for each?

Edit: Registration still broken. Fadeout, what kind of system are you using?

[schweinsz]

On another note, if I possess multiple computers, do I have to purchase a separate license for each?
You can request a serial number by email to me using the email you pay ever.

[schweinsz]

Edit: Registration still broken. Fadeout, what kind of system are you using?
Tomorrow I will delete all dependences on mfc/msvcr in the DiAVC and start to fix the registration problem.

[Stephen R. Savage]

Thank you for the clarification. I look forward to the updated version.

[Virtual_ManPL]

IMO for starter project high antipiracy protection method is very good... cause it lower greatly illegal copying of program (getting cracked CoreAVC is clicking on second link in google, dunno why google or even CoreCodec makes this possible...)...
also dev will have detailed info how many ppl using his software... and of course more money



@ schweinsz - is this bug fixed in final release ? http://forum.doom9.org/showthread.php?p=1370924#post1370924
cause its hell annoying

also update your first post with nice info like changelog, settings, some SSs etc... ;)

and in some time try making article on Wikipedia about your decoder, cause many ppl learn about sth new form it
nice will be changing this horrible web style from Win98 times on homepage to some nice looking (if you dont have time, you can e.g. use WordPress with nice skin)



also some GUI minor mistakes
http://i47.tinypic.com/nlpds4.png

and "H.264" text can be deleted or changed to "H.264/AVC"



In the near future we will be seeing options like input colorspace (Auto/BT.601/BT.709), deblocking (strength) and deinterlacing (modes) ?
Also waiting for Super-resolution support, will be nice to see first decoder supporting this



P.S. I will also buy your decoder but now Im poor student...:p

[Disabled]

IMO for starter project high antipiracy protection method is very good... cause it lower greatly illegal copying of program (getting cracked CoreAVC is clicking on second link in google, dunno why google or even CoreCodec makes this possible...)...

The thing is, you can't stop the pirates. CoreCodec "makes it possible" because they figured even after introducing some advanced activation scheme the software was cracked in no time and people don't like buying software they can't use anymore if the developers feel like it. I think especially for unknown projects its essential to not scare away the early adopters. I gave the DiAVC Beta to a few people but won't convince them to buy it, because I don't want to be the person responsible for them not being able to use paid software. And especially if there are free alternatives, you better make sure your customers get the absolutely best version out there - ie no need to activate.

[Stephen R. Savage]

@ schweinsz - is this bug fixed in final release ? http://forum.doom9.org/showthread.ph...24#post1370924
cause its hell annoying

In the near future we will be seeing options like input colorspace (Auto/BT.601/BT.709), deblocking (strength) and deinterlacing (modes) ?
Also waiting for Super-resolution support, will be nice to see first decoder supporting this

I actually haven't seen that seeking bug since one of the earlier betas, but I'm using EVR/Sync instead of EVR/Custom now. If it's still there, I hope it gets fixed.

A manual switch to toggle BT.601/BT.709 would be nice, as many streams don't have the colormatrix flag set. Actually, would it be possible to automatically select a matrix based on whether the stream is HD or SD? This could allow a semi-intelligent decision when the flags aren't set.

Imo, a switch for deblocking is kind of pointless nowadays, since the most difficult streams to decode are the high-bitrate ones, and those don't really have anything left to deblock.

[Virtual_ManPL]

@ Disabled - but you know, no1 will (IMO of course) wasting time cracking DiAVC, when you have cracked CoreAVC with CUDA support or even free decoders like DivX or ffdshow/MPC-HC with DxVA support in early DiAVC development
when decoder will be better know, you are right, cracking will be matter of time, but schweinsz for this time will probably remove this antipiracy protection method to easier his life for answering emails and lower his time on support

@ Stephen R. Savage - this bug exist mostly in EVR/Custom, but I can see it sometimes in EVR and EVR/Sync
try e.g. fast mouse clicking on seek bar in MPC-HC :p

[Fadeout]

Edit: Registration still broken. Fadeout, what kind of system are you using?
CPU or what?

I'm on Windows XP here. E8400.

[hajj_3]

@Schweinsz: do you have any Plans to use CUDA or ati's STREAM in a future version to reduce the cpu usage even further?

[LoRd_MuldeR]

@Schweinsz: do you have any Plans to use CUDA or ati's STREAM in a future version to reduce the cpu usage even further?

I don't think there's much point for that. Whatever decoder filter offers "hardware H.264 decoding" will always be a wrapper around the very same H.264 decoder chip on the graphics board.

So performance-wise and feature-wise it doesn't (or at least shouldn't) matter which decoder filter you use to access the H.264 decoder chip. The decoder chip that does the actual work is always the same.

Therefore it would be a waste of resources to develop a damn fast software-only H.264 decoder, such as DiAVC, and then offload all the work to the hardware decoder ;)

And most important: There already are free DXVA solutions, namely ffdshow-DXVA and MPC-HC. If you need H.264 hardware decoding for Avisynth, you can buy DGAVCIndexNV for a similar price...

[hajj_3]

true, i was just thinking off offloading SOME of the work to the gpu, i believe coreavc 2.0 does this with CUDA enabled cards.

[stax76]

Small correction, the package is called DGDecNV, the index app DGIndexNV and the filters DGSource and DGMultiSource, most GUIs cannot use DGMultiSource.

[Disabled]

true, i was just thinking off offloading SOME of the work to the gpu, i believe coreavc 2.0 does this with CUDA enabled cards.
No they don't CoreAVC with Cuda only sends the bitstream to the card and let it decode it. It is not an intelligent hybrid method. As Mulder implied, every Cuda decoder does it that way.

[schweinsz]

@Schweinsz: do you have any Plans to use CUDA or ati's STREAM in a future version to reduce the cpu usage even further?
No, I have no plan to use CUDA or ati's STREAM for offloading the cpu decoding, but I have a big plan to use the CUDA or ati's STREAM to post-process the frames, including super-resolution, sharpen, denoise, etc. I plan to code a video renderer to do this. I am learning the cuda.

[hajj_3]

nice :)

[Fadeout]

Well, my copy already stopped functioning.

I have replaced an old drive, definitely not the two SATA drives that come first and that I use for everything. Now DiAVC doesn't work and it is showing me a different code.

[schweinsz]

DiAVC 1.0.1 is released.
20100219
DiAVC 1.0.1 is released.
Get rid of the dependency on MFC.
Improved registration (less dependency on hardware features).
Improved compatibility with hardwares and windows.

The hardware serial number is read for only one time when it is firstly run.
The restriction on hardware is loosed greatly. If you have registered the software, it will work ok when hardware is changed unless you re-install your windows. If it is, e-mail to me for a new password using the e-mail you pay.

[schweinsz]

Well, my copy already stopped functioning.

I have replaced an old drive, definitely not the two SATA drives that come first and that I use for everything. Now DiAVC doesn't work and it is showing me a different code.
I have sent the new password to you. The old version 1.0.0 uses the DeviceIOcontrol to read serial number of "physicsdrive0", perhaps it is due to your winxp set the "physicsdrive0" with your new harddisk.
Use the DiAVC version 1.0.1, it is un-sensitive to the hardware changes.

[Fr4nz]

No, I have no plan to use CUDA or ati's STREAM for offloading the cpu decoding, but I have a big plan to use the CUDA or ati's STREAM to post-process the frames, including super-resolution, sharpen, denoise, etc. I plan to code a video renderer to do this. I am learning the cuda.

Why not OpenCL? It is a new standard, it is cross-platform, API is similar to CUDA and gives you nice performance with current drivers on both Nvidias and ATIs...

[hajj_3]

You'd be better off removing any restrictions and just have a serial number as crackers will likely crack it within a few days so you are just harming your legit customers who are paying you by adding such things. You could blacklist serials that appear at more than 2 ip's as most people would only use software in their own home or at work, i think this would be much more effective than any hardware id based protection.

Hope to see more added functionality in 1.0.2 :)

lets hope that bob0r buys the sourcecode and makes it an opensource project :)

Why not OpenCL? It is a new standard, it is cross-platform, API is similar to CUDA and gives you nice performance with current drivers on both Nvidias and ATIs...

isn't CUDA better at performing than OpenCL? I'd just add CUDA for the time being, STREAM is very new, i'd wait for it to mature imo before adding that. People buy nvidia cards for CUDA acceleration, ati people don't buy cards for acceleration as CUDA has been around for a long time.

[Fr4nz]

isn't CUDA better at performing than OpenCL? I'd just add CUDA for the time being, STREAM is very new, i'd wait for it to mature imo before adding that. People buy nvidia cards for CUDA acceleration, ati people don't buy cards for acceleration as CUDA has been around for a long time.

At the moment *maybe* CUDA is slightly better than OpenCL, but this has to do with driver issues/bugs and the fact that OpenCL is a rather new standard, not because OpenCL is "inferior" to CUDA. Moreover, I repeat that OpenCL API is very similar to CUDA API...

Therefore, I don't think that CUDA is a wise choice for the future...

[schweinsz]

You'd be better off removing any restrictions and just have a serial number as crackers will likely crack it within a few days so you are just harming your legit customers who are paying you by adding such things. You could blacklist serials that appear at more than 2 ip's as most people would only use software in their own home or at work, i think this would be much more effective than any hardware id based protection.

Hope to see more added functionality in 1.0.2 :)

lets hope that bob0r buys the sourcecode and makes it an opensource project :)



isn't CUDA better at performing than OpenCL? I'd just add CUDA for the time being, STREAM is very new, i'd wait for it to mature imo before adding that. People buy nvidia cards for CUDA acceleration, ati people don't buy cards for acceleration as CUDA has been around for a long time.
I invented some new software protection method so I used it to make it hard to crack my software. the current restriction is very loose so that only re-installation windows with modified-hardware need new password. The DiAVC has no access to internet so I can't blacklist cracked serial number. If I delete the code computing registercode using hardware feature, it will be cracked in one second.

The 1.0.2 will include the improved CAVLC.

[Disabled]

If you don't trust me, I don't trust you. Simple as that.

[schweinsz]

If you don't trust me, I don't trust you. Simple as that.
But if there is one who open the serial number, all people will get it. I can't take the risk.

[Disabled]

Thats your decision. CoreCodec does take that risk. You can ban released serials with future updates you know - and it seems to me you have big plans.
*edit* And I wonder what makes you think you are better at protecting your software than every single other company in the world*). Your software won't be cracked in the short term, because there is no interest yet. But once there are enough people who want it illegally, there will be a way.

*edit2* *) Not that I think you are not skilled or something like that, but the statistics speak against you.

[schweinsz]

Thats your decision. CoreCodec does take that risk. You can ban released serials with future updates you know - and it seems to me you have big plans.
All updates is free for DiAVC customers. In my plan, if the registercode is not changed, the password will be same all along. And I believe the computation of register code will not be changed in future, this means if the hardware is not changed, the register code will no be changed. If there is a valid register code, the DiAVC 1.0.1 will always use it rather than compute a new one using the current hardware configuration. I have no plan to change the procedure.
I DO have big plan on development. I have invented some great ideas to accelerate the video playback and process video. I will inplement it in future.

[Astrophizz]

I think schweinsz is making the right decision. He's dealing with the reality of the market, not some idealized world where all users can be entrusted with a string of characters and be expected not to leak it. Schweinz isn't every single other company in the world, he's a one person operation trying to get his foot in the door. CoreCodec bans serials but I don't think that has done anything to stop to stop people from pirating it at all. Of course they operate on a much larger scale and have corporate partners so they're less at risk from it.

[schweinsz]

*edit* And I wonder what makes you think you are better at protecting your software than every single other company in the world*). Your software won't be cracked in the short term, because there is no interest yet. But once there are enough people who want it illegally, there will be a way.

*edit2* *) Not that I think you are not skilled or something like that, but the statistics speak against you.
I believe so, if crackers code some drives to cheat the pure ring3 program DiAVC, but that will give you risk on your system.

[Disabled]

He's dealing with the reality of the market
The reality of the market is that every software that gains a specific level of interest is available illegal on the internet.
Its not like the activation scheme CoreCodec once implemented stopped people from pirating it. I don't know why they stopped using the activation, if there were to many customers complaining, or if thought its pointless since it was cracked anyway, but its gone for good.
I believe so, if crackers code some drives to cheat the pure ring3 program DiAVC, but that will give you risk on your system.
Or they manage to rip the serial generation code from the filter or they patch the code to not even ask or they find a hole you didn't think of...

[hajj_3]

is the installer .msi file a trial? I wouldn't mind trying it, wanna see if i can play 4000 bitrate 720p x264 .mkv on my sisters single core 1.78ghz celeron laptop. 3000 JUST plays with coreavc, it uses 100% cpu tho. 4000 has audio sync problems and glitches every few secs, hoping this might be able to play them smoothly.

P.S is the .ax file on your website the codec for us to select in MPC-HC? If so what does the .msi installer do?

you should improve your website too, the text on the left side is tiny and the links at the top are hard to read in their current colour, font and font size.

[schweinsz]

is the installer .msi file a trial? I wouldn't mind trying it, wanna see if i can play 4000 bitrate 720p x264 .mkv on my sisters single core 1.78ghz celeron laptop. 3000 JUST plays with coreavc, it uses 100% cpu tho. 4000 has audio sync problems and glitches every few secs, hoping this might be able to play them smoothly.

It is not a trial, it is a normal version. The DiAVC is faster than coreavc on almost all cpu by about 10%-25% in favor to new cpu for example, core 2 duo. The DiAVC has a more efficient cabac module so it is faster for high-bitrate contents. If your contents is cavlc, you can wait for DiAVC 1.0.2. I can't guarantee your problem IMHO.

P.S is the .ax file on your website the codec for us to select in MPC-HC? If so what does the .msi installer do?
Yes.
The msi install the .ax and the DiAVC registration.exe to a same folder. The DiAVC registration.exe can register the diavc.ax and read the register code and input the password. In my opinion, the .msi is prefered.

[schweinsz]

Or they manage to rip the serial generation code
There is no such code in the filter to generate a password from a register code.

[hajj_3]

so i can't download a trial from anywhere? As there's no chance i'd buy something i can't try. She has an intel celeron m 430 1.73ghz cpu and 2gb ddr2 ram running win 7 32bit ultimate.

cpu: http://ark.intel.com/Product.aspx?id=27150

[rack04]

I ask that all those complaining about schweinsz's business model please post what business you're in so I can complain about how you run it. :devil:

[Fadeout]

The old version 1.0.0 uses the DeviceIOcontrol to read serial number of "physicsdrive0", perhaps it is due to your winxp set the "physicsdrive0" with your new harddisk.
Maybe it was because the drive I removed was an IDE, while the disks I normally use are SATA.

[Stephen R. Savage]

Using the latest version on your website, I STILL get "DiAVC initialization failed." I am very disappointed that activation has prevented me from purchasing what would otherwise be a very good product.

[ChronoCross]

It is not a trial, it is a normal version. The DiAVC is faster than coreavc on almost all cpu by about 10%-25% in favor to new cpu for example, core 2 duo. The DiAVC has a more efficient cabac module so it is faster for high-bitrate contents. If your contents is cavlc, you can wait for DiAVC 1.0.2. I can't guarantee your problem IMHO.


do you have any real statistics to back up this statement? I've tried out your codec on an Athlon 64 4000+ and it's slower than CoreAVC on all content.

Additionally it sounds like this product is far from being ready to be sold as the registration system is buggy, you've got it hardware locked, you basically just told everyone who use cavlc to suck it, it has all kinds of cosmetic problems, you have limited time to do customer support. It seems scary to think of what happens if more than 20 people buy your product.

[Fr4nz]

do you have any real statistics to back up this statement? I've tried out your codec on an Athlon 64 4000+ and it's slower than CoreAVC on all content.

Additionally it sounds like this product is far from being ready to be sold as the registration system is buggy, you've got it hardware locked, you basically just told everyone who use cavlc to suck it, it has all kinds of cosmetic problems, you have limited time to do customer support. It seems scary to think of what happens if more than 20 people buy your product.

Luckily we have ffdshow tryouts and DivX 7 HD-decoders for free :D

[hajj_3]

he hasn't really told ppl with CAVLC to suck it, he said it will be in v1.02, he adds new features within 2 weeks usually so thats not fair to say that. I agree the registration system and website are poor. I am unable to test it as there's no trial so i can't comment on the performance unfortunately, i'd like to test it with 4000 bitrate 720p as already stated. A 10day trial would be good if he could make that happen, then people could really evaluate how good it is compared to coreavc. There are statistics a few pages back btw using older versions of DiAVC, which version did u try chronocross?

[ChronoCross]

he hasn't really told ppl with CAVLC to suck it, he said it will be in v1.02, he adds new features within 2 weeks usually so thats not fair to say that. I agree the registration system and website are poor. I am unable to test it as there's no trial so i can't comment on the performance unfortunately, i'd like to test it with 4000 bitrate 720p as already stated. A 10day trial would be good if he could make that happen, then people could really evaluate how good it is compared to coreavc. There are statistics a few pages back btw using older versions of DiAVC, which version did u try chronocross?

Some version from a couple of weeks ago. I don't have it anymore and have no plans on purchasing it because well....it's not a product worth spending money on.

[hajj_3]

right now you're probably right but give it 3 months i'm sure there will be alot more features and have better performance inc hardware de-interlacing, sharpening etc using CUDA. Hopefully there will be a cpu list with speed comparisons with coreavc and diavc in a few months once features are added then we could really compare them and evaluate which to buy. bob0r mentioned a possible buyout a few pages back which would be very cool, guess we'll have to wait and see if that materialises.

[Disabled]

do you have any real statistics to back up this statement?
Just read the thread. It was faster for most people. Some beta version was faster for most content I tried on a CoreDuo and a Core2Duo E6400. I didn't try Cavalc, but as he suggested it will be added*). Funny fact: Missing features and crappy sales system with CoreAVC wasn't a problem for you...
You are right though, the sales system is not up to par with CoreAVC ... until they change the account system again.
*edit* *) I actually thought it was already functional but would receive a speed boost, but I might have gotten that wrong as I have no real interest in cavalc.

[ChronoCross]

Just read the thread. It was faster for most people. Some beta version was faster for most content I tried on a CoreDuo and a Core2Duo E6400. I didn't try Cavalc, but as he suggested it will be added*). Funny fact: Missing features and crappy sales system with CoreAVC wasn't a problem for you...
You are right though, the sales system is not up to par with CoreAVC ... until they change the account system again.
*edit* *) I actually thought it was already functional but would receive a speed boost, but I might have gotten that wrong as I have no real interest in cavalc.

I never had any problems using coreavc or it's registration/activation system. The only problems people had with it were related to the fact they were trying to install it on 400 different machines after purchasing it once rather than problems with singular systems.

As for the speed boosts I could give a rats a** about Core2Duo systems. I already know he spent all his time optimizing for those CPU's, however he claims 25% increase in speed on ALL CPU's whereas this is clearly not the case. His codec is optimized for a very specific subset of CPU's mainly newer core2duo's/quads/i3/i7/i5.

[Fadeout]

I never had any problems using coreavc or it's registration/activation system. The only problems people had with it were related to the fact they were trying to install it on 400 different machines after purchasing it once rather than problems with singular systems.

As for the speed boosts I could give a rats a** about Core2Duo systems. I already know he spent all his time optimizing for those CPU's, however he claims 25% increase in speed on ALL CPU's whereas this is clearly not the case. His codec is optimized for a very specific subset of CPU's mainly newer core2duo's/quads/i3/i7/i5.
CoreeAVC is more viable but things should be seen from a different perspective.

I decided to buy DiAVC simply because it is cheap and I wanted to *support* the guy considering how talented he has demonstrated to be. In just a couple of months he outclassed CoreAVC without a problem. There were more measurable performance improvements between each beta version he released week after week than what CoreAVC achieved with 2.0 in almost a full year without updates/fixes.

DiAVC doesn't perform better than CoreAVC with older CPUs, neither CoreAVC 2.0 is performing better than CoreAVC 1.9.5. After a year.

That's why I'm more glad of giving that money to DiAVC than giving it to CoreAVC. CoreAVC was LUCKY that the weight-p support/feature popped up because without it there would be absolutely no reason to upgrade. And that's all that happened in a whole year.

So, DiAVC is very new, updated frequently up to this day, and already outclassing CoreAVC. Where it doesn't outclass it, it is comparable.

The downside is the protection he decided to use on the software, but I still think he deserved my money because alone he demonstrated that he can do a much better work than everyone else. So he already earned my money more than CoreAVC.

[Disabled]

DiAVC is faster than coreavc on almost all cpu

Limitations:
Need CPU with SSE2
Core2 and Core from Intel, Athlon64 3500+:
http://forum.doom9.org/showthread.php?p=1358916#post1358916
I don't know about Atom and Pentium4 and some more AMD (and Via C7,...), what CPU do you have and what were the speeds for you? Or do you also discredit all benchmarks like Betaboy without suggesting a better way how to benchmark codecs?
Also I was also refering to Corecodec changing there "super Coreaccount system" every other release having to reregister and support tickets from the old system not being replied to.

And @Fadeout, I absolutely agree with you, that one should support upcoming developers and I am absolutely amazed at what schweinz achieved in little time. Thats why I bought CoreAVC the moment I could, they looked equally promising (looked...). Still I don't like activation and try to argue against it where I can. I just want to have to control over what I bought and especially when there is only one guy, handing out (re-)activation codes per email. Then I want to reinstall and he is on vacation - perfect.

[yesgrey]

There is no such code in the filter to generate a password from a register code.
I think it would be a lot better for you if you stop giving hints about your protection scheme. Use whatever you feel necessary for protecting your work, you deserve it.;)
If someone does not like it, that his problem, not yours.
If someone cracks your protection scheme, then it's your problem, not theirs... so, do yourself a favor, and keep it for yourself.
If someone feels that $10 is too much money to trust you when you say that you will not let them down, why would you have to trust them with an easily crackable protection scheme?

PS: Sorry for the off-topic.

[Disabled]

I think it would be a lot better for you if you stop giving hints about your protection scheme.

I don't understand why he has the installation file openly on his webspace. That just increases the number of bad guys that can get it and try to crack it. (And it confuses people into thinking this might be some kind of trial version.) Just hand out a (probably personalized) download link per Email...

[ChronoCross]

Core2 and Core from Intel, Athlon64 3500+:
http://forum.doom9.org/showthread.php?p=1358916#post1358916
I don't know about Atom and Pentium4 and some more AMD (and Via C7,...), what CPU do you have and what were the speeds for you? Or do you also discredit all benchmarks like Betaboy without suggesting a better way how to benchmark codecs?
Also I was also refering to Corecodec changing there "super Coreaccount system" every other release having to reregister and support tickets from the old system not being replied to.

And @Fadeout, I absolutely agree with you, that one should support upcoming developers and I am absolutely amazed at what schweinz achieved in little time. Thats why I bought CoreAVC the moment I could, they looked equally promising (looked...). Still I don't like activation and try to argue against it where I can. I just want to have to control over what I bought and especially when there is only one guy, handing out (re-)activation codes per email. Then I want to reinstall and he is on vacation - perfect.

I don't trust those because look at the fps column on the second test. I can't trust any results timecodec is popping out if it's generating one column in which it has decided to put a random number. I measure with my own eyes and what CPU utilization and CPU utilization. My tests indicate that the speed of coreavc is slightly better and performs proper playback all the time.

As for DiAVC's support/purchasing system he'll either have to take the single serial route or you guys are all screwed. He's certainly not going to sell enough of his product to provide a support structure for generating new keys everytime you change a stick of ram.

[Fadeout]

I measure with my own eyes and what CPU utilization and CPU utilization.
CPU usage is much better with DiAVC here, same as Timecodec.

In particular it seems to use better both cores.

[Stephen R. Savage]

I'm almost amused. All these CoreCodec shills troll their own thread, accusing anyone who complains about any of their numerous failings of "shitting on the release"... and then they come here and spread FUD! It's almost pathetic that, instead of improving their own work, they come here to attempt to discredit their competitors.

This includes not only the current blog by CHRONO CROSS, but also BETABOY himself trying to spread patent FUD a few pages before this one! Of course, this is not at all surprising, since "CoreCodec" isn't even a real company! They are nothing more than a couple of well-known pirates who hang around and troll IRC channels!

Edit: Also, CAVLC is supported just fine. It just happens to be slightly slower than the competition, which is not a terribly big deal since CAVLC content is incredibly easy to decode.

Edit2: It will also be a great shame if DRM issues betray my enthusiasm. The way things are going, it may come out such that RC1 was the best version.

[Disabled]

AFAIK the "real" time is the wall time, ie how long it took. That number is used to calculate dfps. For whatever reason (idk) timecodec sometimes does not measure the user time (which would probably be more accurate, because it wouldn't measure other programs hogging the cpu or HDD limitings), that value(or the total value derived from User time) is used to calculate the fps, so fps can be severely wrong. My test showed that timecodec dfps shows the same trends as the benchmark in Graphstudio, which showed the same trends as comparing the time taken by a process in the task manager, which showed the same results as comparing the cpu-usage graphs. Trust what you think, but I have yet to see a sound explanation why dfps shouldn't be used for comparison (given you do nothing else and use null renderer).
*edit* And I still wonder what CPU you use...

[schweinsz]

Core2 and Core from Intel, Athlon64 3500+:
http://forum.doom9.org/showthread.php?p=1358916#post1358916
I don't know about Atom and Pentium4 and some more AMD (and Via C7,...), what CPU do you have and what were the speeds for you? Or do you also discredit all benchmarks like Betaboy without suggesting a better way how to benchmark codecs?
I will give some detailed results on core duo T2350 and core 2 duo T6600 on my site. I have not other cpu so I can't give more detailed results. But there are some results about other cpu in this thread.
http://forum.doom9.org/showthread.php?p=1354676#post1354676

The core duo I work on is an old cpu with similar architecture to pentium M. I never try to optimize to a special cpu, I just code general algorithm.

[ChronoCross]

I'm almost amused. All these CoreCodec shills troll their own thread, accusing anyone who complains about any of their numerous failings of "shitting on the release"... and then they come here and spread FUD! It's almost pathetic that, instead of improving their own work, they come here to attempt to discredit their competitors.

This includes not only the current blog by CHRONO CROSS, but also BETABOY himself trying to spread patent FUD a few pages before this one! Of course, this is not at all surprising, since "CoreCodec" isn't even a real company! They are nothing more than a couple of well-known pirates who hang around and troll IRC channels!

Edit: Also, CAVLC is supported just fine. It just happens to be slightly slower than the competition, which is not a terribly big deal since CAVLC content is incredibly easy to decode.

Edit2: It will also be a great shame if DRM issues betray my enthusiasm. The way things are going, it may come out such that RC1 was the best version.

That's funny coming from a coreavc troll. Guess it's not very fun when your on the other end of the bitching about shortcomings. See how your now calling me a troll for your precious DiAVC. At least coreavc doesn't have you locked into specific hardware, reliably decodes streams, uses proper English in it's configuration dialog, it's fast a all CPU's rather than just being optimized for intel's newer CPU's, supports hardware acceleration, and has actually development plans aside from "I'm going to magically make h264 decoding and encoding 50% faster. I find it funny that your willing to pay the SAME PRICE for something is obviously nowhere near the quality of coreavc.

Also...hate to tell you this but CoreCodec Inc is a registered company...

P.S. This is a forum post not a blog. Just in case you forgot where you were.


AFAIK the "real" time is the wall time, ie how long it took. That number is used to calculate dfps. For whatever reason (idk) timecodec sometimes does not measure the user time (which would probably be more accurate, because it wouldn't measure other programs hogging the cpu or HDD limitings), that value(or the total value derived from User time) is used to calculate the fps, so fps can be severely wrong. My test showed that timecodec dfps shows the same trends as the benchmark in Graphstudio, which showed the same trends as comparing the time taken by a process in the task manager, which showed the same results as comparing the cpu-usage graphs. Trust what you think, but I have yet to see a sound explanation why dfps shouldn't be used for comparison (given you do nothing else and use null renderer).
*edit* And I still wonder what CPU you use...

A program which does not report the correct results all the time is not a reliable metric by which to base any claims.

As for my CPU please read the thread as I stated it about 6 posts ago.

http://forum.doom9.org/showpost.php?p=1375625&postcount=642

[schweinsz]

it's fast a all CPU's rather than just being optimized for intel's newer CPU's, supports hardware acceleration, and has actually development plans aside from "I'm going to magically make h264 decoding and encoding 50% faster. I find it funny that your willing to pay the SAME PRICE for something is obviously nowhere near the quality of coreavc.

A program which does not report the correct results all the time is not a reliable metric by which to base any claims.
corecodec have not qualified engineers in their company actually, so they must hire DS to code for them temporarily. The so-called development plans is a blank paper actually. While I have invented some excellent algorithms and I will implement them in future.
The CoreAVC 2.0 is slower than DiAVC and is comparable to DiVX on my core duo T2350, and much slower than DiAVC on core 2duo T6600.
When multi-threading is used, it is very difficult to measure the actual time the decoder use, but as the time is small that is used by null renderer and splitter, the results gotten by timecodec or graphstudio is very accurate to measure the decoder performance.

[Stephen R. Savage]

That's funny coming from a coreavc troll. Guess it's not very fun when your on the other end of the bitching about shortcomings. See how your now calling me a troll for your precious DiAVC.

I believe this is what they refer to as "projecting." See, you are locked into your narrow troll-view notion of the world and feel threatened when others point that out to you. Also, I hate to inform you, but it is well established that CoreCodec is just a front for a couple of notorious scene pirates.

I find it funny that your willing to pay the SAME PRICE for something is obviously nowhere near the quality of coreavc.

Also, nobody mentioned paying anywhere. I think, again, you are projecting to compensate for your own deficiencies. Not only that, I find your inability to grasp the usage of the personal pronoun shocking!

Edit: Also, note that, unlike you who blogs useless garbage, I support DiAVC because I strongly believe that nobody should ever be forced to purchase software from pirates. Personally, I have no real need for DiAVC, and even less for CoreAVC. I only post here because I find the notion of someone who actually writes software instead of blogging about pretending to write software somewhat refreshing.

Edit2: I also find it amusing that you complain about grammatical errors in the software when you have demonstrated in your over 1000 useless posts that basic comprehension of English is beyond your abilities.

Edit3: While we're ranting, I would like to point out that up until release version 1.5, CoreAVC couldn't even decode compliantly. Not only that, until 2.0, the fastest version of CoreAVC was the initial alpha, and in fact every progressive release made it slower.

[Fadeout]

At least coreavc doesn't have you locked into specific hardware,
True. At the moment it's the only advantage CoreAVC has on the competition.


reliably decodes streams,
In my experience DiAVC can decode everything CoreAVC can.

uses proper English in it's configuration dialog,
Big deal.

it's fast a all CPU's rather than just being optimized for intel's newer CPU's,
DiAVC is as fast on all CPU and faster on newer ones.

supports hardware acceleration,
True, but in those cases one could easily use DXVA.

and has actually development plans aside from "I'm going to magically make h264 decoding and encoding 50% faster.
In one year we saw zero from CoreAVC. In a few weeks we saw everything from DiAVC. If we have to judge from experience I expect a lot more from DiAVC and expect nothing at all if not 8 months of delay for a new version (that you have to pay) from CoreAVC.

I find it funny that your willing to pay the SAME PRICE for something is obviously nowhere near the quality of coreavc.
It is above the quality of CoreAVC in its current state. The package isn't on par due to distribution issues. If one has to make a choice CoreAVC is still the better one since you know you'll be able to use it whenever you need it, but DiAVC has already outclassed CoreAVC and has a lot more planned if the author continues to develop it.

[ChronoCross]

I believe this is what they refer to as "projecting." See, you are locked into your narrow troll-view notion of the world and feel threatened when others point that out to you. Also, I hate to inform you, but it is well established that CoreCodec is just a front for a couple of notorious scene pirates.



Any evidence of this? Or is this something that you've just made up in an attempt to smear the employees of corecodec.


Also, nobody mentioned paying anywhere. I think, again, you are projecting to compensate for your own deficiencies. Not only that, I find your inability to grasp the usage of the personal pronoun shocking!


The last 4 pages are pretty much about people paying for DiAVC. It's now a paid codec. Guess you must have missed that.


Edit: Also, note that, unlike you who blogs useless garbage, I support DiAVC because I strongly believe that nobody should ever be forced to purchase software from pirates. Personally, I have no real need for DiAVC, and even less for CoreAVC. I only post here because I find the notion of someone who actually writes software instead of blogging about pretending to write software somewhat refreshing.


Again....this is a forum...not a blog. Learn the difference between the two concepts.


Edit2: I also find it amusing that you complain about grammatical errors in the software when you have demonstrated in your over 1000 useless posts that basic comprehension of English is beyond your abilities.


Nice try. Obvious troll is being obvious.


Edit3: While we're ranting, I would like to point out that up until release version 1.5, CoreAVC couldn't even decode compliantly. Not only that, until 2.0, the fastest version of CoreAVC was the initial alpha, and in fact every progressive release made it slower.

Shows you pretty much have never used CoreAVC 2. It is most certainly faster than the 1.x versions.

[Stephen R. Savage]

edit2: I also find it amusing that you complain about grammatical errors in the software when you have demonstrated in your over 1000 useless posts that basic comprehension of english is beyond your abilities. nice try. Obvious troll is being obvious.

edit3: While we're ranting, i would like to point out that up until release version 1.5, coreavc couldn't even decode compliantly. Not only that, until 2.0, the fastest version of coreavc was the initial alpha, and in fact every progressive release made it slower.
shows you pretty much have never used coreavc 2. It is most certainly faster than the 1.x versions.

Case in point. Q.E.D.

[ChronoCross]

True. At the moment it's the only advantage CoreAVC has on the competition.

In my experience DiAVC can decode everything CoreAVC can.


I'm sure I can find some stuff it won't play. Considering the limited amount of samples that are used in DiAVC's QA it's highly probable that it won't properly play things that CoreAVC can.


Big deal.


Shows professionalism of the product. Current which is lacking in pretty much every respect.


DiAVC is as fast on all CPU and faster on newer ones.


Again I've already noted this is untrue in my case....so to say this as a general statement is false.


True, but in those cases one could easily use DXVA.


Sure if the file fits within the much smaller limitations of DXVA.


In one year we saw zero from CoreAVC. In a few weeks we saw everything from DiAVC. If we have to judge from experience I expect a lot more from DiAVC and expect nothing at all if not 8 months of delay for a new version (that you have to pay) from CoreAVC.


Of course you saw a lot......he was building the entire codec from scratch....you saw the same type of activity when coreavc was initially building their codec.


It is above the quality of CoreAVC in its current state. The package isn't on par due to distribution issues. If one has to make a choice CoreAVC is still the better one since you know you'll be able to use it whenever you need it, but DiAVC has already outclassed CoreAVC and has a lot more planned if the author continues to develop it.

Again I beg to differ. But we are probably going to have to agree to disagree.

[ChronoCross]

Case in point. Q.E.D.

*claps* To note the alpha is slower than the 1.x versions and it did not get slower with each release.

[schweinsz]

I'm sure I can find some stuff it won't play. Considering the limited amount of samples that are used in DiAVC's QA it's highly probable that it won't properly play things that CoreAVC can.
The DiAVC is a full-featured H.264 decoder. I do a full tests on standard bitstreams. DS has listed some features that divx and lavc do not support, but there are not these problem in DiAVC.

Shows professionalism of the product. Current which is lacking in pretty much every respect.
I can improve it continuilly. I always invent new algorithms.



Again I've already noted this is untrue in my case....so to say this as a general statement is false.
I will give some results on this. Once I get some more cpu, I will give out it. I never optimize to special cpu, I just code general code.


Of course you saw a lot......he was building the entire codec from scratch....you saw the same type of activity when coreavc was initially building their codec.
But the DiAVC is the fastest decoder now, and I can improve it still.

[Stephen R. Savage]

All this talk of updating is nice, but could you look into addressing the registration issue I encountered? You said that the 1.0.1 update you released should have solved the issue.

[ChronoCross]

The DiAVC is a full-featured H.264 decoder. I do a full tests on standard bitstreams. DS has listed some features that divx and lavc do not support, but there are not these problem in DiAVC.


Does it support all features of the H2654 Spec? If it doesn't you should retract your statement before they call you out for false advertising.


I can improve it continuilly. I always invent new algorithms.


We'll see.


I will give some results on this. Once I get some more cpu, I will give out it. I never optimize to special cpu, I just code general code.


If your not testing your code on multiple CPU's then your writing specialized code. You have no idea if it's just as fast on a different CPU.


But the DiAVC is the fastest decoder now, and I can improve it still.

Again....there is nothing that indicates that your generalized statement is true.

[schweinsz]

All this talk of updating is nice, but could you look into addressing the registration issue I encountered? You said that the 1.0.1 update you released should have solved the issue.
I will take out the registration-related code to test on your machine.

[Mixer73]

I will give some results on this. Once I get some more cpu, I will give out it. I never optimize to special cpu, I just code general code.

This point here is I believe the root of Chronocross problems.

Specific optimisations are known to have negative effects on Athlon processors due to their terrible implementations. Dark Shikari commented on this at various times, that for these CPU you need to specifically turn off some optimisations to achieve best performance.

Its not the fault of the program or compiler, but poor CPU design which can be catered for specifically.

I believe DS did exactly this with his work on CoreAVC 2.0, and these 'special case' switches might have been in 1.9.5 too.

[schweinsz]

Does it support all features of the H2654 Spec? If it doesn't you should retract your statement before they call you out for false advertising.
There no decoder except the jm that support all features. The DiAVC supports all needed features. So is coreavc 2.0.
There are so many benchmarks in the thread that show the DiAVC is superior to the CoreAVC on many cpu including the core duo, core 2 duo, athlon and pentium 4 perhaps. Because the pentium has a similar architecture with the core duo, the statement is probabily true for it. But you ignore them. It is difficult to do a benchmark on all cpu.

[schweinsz]

I believe DS did exactly this with his work on CoreAVC 2.0, and these 'special case' switches might have been in 1.9.5 too.
DS coded SSE2 and SSSE3 code for CoreAVC 2.0. I estimate that he is not responsible on such "special case".

[lych_necross]

There no decoder except the jm that support all features.
Whats the jm decoder? :confused:

[Stephen R. Savage]

JM is the reference software included in the H.264 specification. It also has an encoder. Afaik, it is the only feature-complete implementation (14-bit, 4:4:4, weird streaming and other stuff, etc).

[Underground78]

JM is the reference software included in the H.264 specification. It also has an encoder. Afaik, it is the only feature-complete implementation (14-bit, 4:4:4, weird streaming and other stuff, etc).

You should probably add that it's slow as hell before everybody ask where they can get it ... :p

[hajj_3]

i have a computer with a p4 3.0ghz 800fsb 1mb cache if you want me to run benchmarks on it, i also have a core2 2.0ghz laptop, a intel celeron 1.73ghz single core 32bit laptop, a 1.66ghz atom netbook too with 1gb ram in it and a core2quad @ 3.5ghz desktop, i would happily do benchmarks for you, i'd need a 10trial or something to do this though and instructions to carry out the benchmarks, i also have coreavc 2.0 to compare it with. These aren't all my own, they are my family members' but i can run benchmarks on each of them if u want.

[Disabled]

JM is the reference software included in the H.264 specification. [...] Afaik, it is the only feature-complete implementation (14-bit, 4:4:4, weird streaming and other stuff, etc).
But 14-bit and 4:4:4 aren't part of the Main profile, they have extra profiles. I think the same applies to weird streaming stuff, the question is, what else is missing in Diavc that is in the normal Main profile?
*edit* I wanted to apologize to CronoCross for not reading his post properly about his CPU. Thanks for answering anyways.

[schweinsz]

But 14-bit and 4:4:4 aren't part of the Main profile, they have extra profiles. I think the same applies to weird streaming stuff, the question is, what else is missing in Diavc that is in the normal Main profile?
A.2.2 Main profile
Bitstreams conforming to the Main profile shall obey the following constraints:
– Only I, P, and B slice types may be present.
– NAL unit streams shall not contain nal_unit_type values in the range of 2 to 4, inclusive.
– Arbitrary slice order is not allowed.
– The syntax elements chroma_format_idc, bit_depth_luma_minus8, bit_depth_chroma_minus8,
qpprime_y_zero_transform_bypass_flag, and seq_scaling_matrix_present_flag shall not be present in sequence
parameter sets.
– Picture parameter sets shall have num_slice_groups_minus1 equal to 0 only.
– Picture parameter sets shall have redundant_pic_cnt_present_flag equal to 0 only.
– The syntax elements transform_8x8_mode_flag, pic_scaling_matrix_present_flag, and
second_chroma_qp_index_offset shall not be present in picture parameter sets.
– The syntax element level_prefix shall not be greater than 15 (when present).
– The syntax elements pcm_sample_luma[ i ], with i = 0..255, and pcm_sample_chroma[ i ], with
i = 0..2 * MbWidthC * MbHeightC − 1, shall not be equal to 0 (when present).
– The level constraints specified for the Main profile in subclause A.3 shall be fulfilled.
Conformance of a bitstream to the Main profile is specified by profile_idc being equal to 77.
Decoders conforming to the Main profile at a specified level shall be capable of decoding all bitstreams in which
profile_idc is equal to 77 or constraint_set1_flag is equal to 1 and in which level_idc and constraint_set3_flag represent a
level less than or equal to the specified level.

I can not find some missed main-profile features in DiAVC.

[schweinsz]

I added a detailed comparison at di-avc.com between DiAVC, CoreAVC 2.0 and DiVX H.264 decoder on core duo T2350 and core 2 duo T6600.
http://di-avc.com/compare/compare.html
By the way, is it true that many peoples have not a paypal account?

[hajj_3]

yes, quite alot of people don't have paypal accounts but your too small of a business to start up credit/debit card acceptance as you have to pay to set that up with a bank so i wouldn't worry about that if i were you.

Will you be making a 10day trial or something available soon?

[Disabled]

I can not find some missed main-profile features in DiAVC.

The problem I have reading the specs is, they have a million pages on h264 and to describe Main profile is, they only state the limitations. So I had to read the whole specs to know if there is anything missing. What you posted are those constraints, but not what else is in there.
Do you know of any spec related feature missing in x264?

[schweinsz]

yes, quite alot of people don't have paypal accounts but your too small of a business to start up credit/debit card acceptance as you have to pay to set that up with a bank so i wouldn't worry about that if i were you.

Will you be making a 10day trial or something available soon?
Take out a 10-day trial is easy for me. I can give out one tomorrow.

[yesgrey]

schweinsz,
Are you from Europe? I'm asking this because I would like to buy DiAVC but you only have a US$ price. In case you are from Europe, it would be preferable for us Europeans to pay you directly in Eur, it would avoid any conversion ratios...

[hajj_3]

he accepts paypal so you should be able to pay him fine.

Thanks schweinsz, a 10day trial would be great:)

You should make a list of things that DiAVC can't do yet like CAVLC etc and write a list of things that will be added in v1.1, 1.2 etc

[schweinsz]

The problem I have reading the specs is, they have a million pages on h264 and to describe Main profile is, they only state the limitations. So I had to read the whole specs to know if there is anything missing. What you posted are those constraints, but not what else is in there.
Do you know of any spec related feature missing in x264?
I can list all possible features in main profile.
1: poc type 0,1,2,
2: field coding, frame coding and mbaff
3: gaps_in_frame_num_value_allowed_flag = 0, 1
4: direct_8x8_inference_flag = 0,1
5: cabac and cavlc
6: chroma_qp_index_offset
7: constrained_intra_pred_flag = 0,1
8: slice_type = I, P, B
9: direct_spatial_mv_pred_flag = 0,1
10: ref_pic_list_reordering
11: deblock_alpha_beta_offset
12: multi-sps and multi-pps
13: long_term_reference_picture
14: IPCM support
15: MB_Partition including 16x16, 16x8, 8x16, 8x8, 8x4, 4x8, 4x4

There is no some special feature that current decoder will not implement, so is DiAVC. In other word, DiAVC supports all above features.

As regard to x264, I am not familar with the all parts of x264, does it have the support with one special pps for one picture with a special quantization? Does it have the support of adaptive spatial/temporal direct prediction mode?

[schweinsz]

he accepts paypal so you should be able to pay him fine.

Thanks schweinsz, a 10day trial would be great:)

You should make a list of things that DiAVC can't do yet like CAVLC etc and write a list of things that will be added in v1.1, 1.2 etc
The DiAVC supports CAVLC currently. But I will improve it in recent some days.

[schweinsz]

schweinsz,
Are you from Europe? I'm asking this because I would like to buy DiAVC but you only have a US$ price. In case you are from Europe, it would be preferable for us Europeans to pay you directly in Eur, it would avoid any conversion ratios...
But I am not from europe. I live in east.

[yesgrey]

But I am not from europe. I live in east.
Ok, it will be in US$ then. Thanks.

[Disabled]

I can list all possible features in main profile
Thanks for the list, and after a little research about the things you missed, I realize I wrote Main Profile, what I meant was High profile. If you had a list on those features too, that would be awesome (and a comment on support in DiAVC). And sorry for being a little OT here.

[Virtual_ManPL]

I find some nice detailed decoder test, but probably its using old DiAVC decoder version :)
H.264 decoder test (http://translate.google.com/translate?js=y&prev=_t&hl=pl&ie=UTF-8&layout=1&eotf=1&u=http%3A%2F%2Fwww.divxhouse.com%2Ftest-decoders-h264%2F&sl=auto&tl=en)

Also schweinsz read this post fully http://forum.doom9.org/showthread.php?p=1374153#post1374153, cause contain some advice and bugs :p



P.S. Stop spamming this thread with DiAVC vs CoreAVC bullshit and changing anti-piracy protection method (for your wicked intentions)... :devil:

[Mixer73]

DS coded SSE2 and SSSE3 code for CoreAVC 2.0. I estimate that he is not responsible on such "special case".

I think you will find that he is. Certain of these optimisations need to be left off in certain CPUs to maintain best performance, its counter intuitive but its what's needed. He has made quite a few posts in this thread and others about it.

[BetaBoy]

There no decoder except the jm that support all features. The DiAVC supports all needed features. So is coreavc 2.0.
There are so many benchmarks in the thread that show the DiAVC is superior to the CoreAVC on many cpu including the core duo, core 2 duo, athlon and pentium 4 perhaps. Because the pentium has a similar architecture with the core duo, the statement is probabily true for it. But you ignore them. It is difficult to do a benchmark on all cpu.

I beg to differ on results as many are swayed and not properly done in this thread as I have already said... For you to state that it's better is a matter of opinion and you should leave that up to your customers to state or post real world results on.

[BetaBoy]

Any evidence of this? Or is this something that you've just made up in an attempt to smear the employees of corecodec.

That was the troll statement of the year he made.... Thx CC... We work hard here on our products, technologies and support and such outlandish statements only brings out his true intentions here on D9.

[JimmyZ]

I guess u r from China? I saw the serif font in your screenshot which is default in Chinese version of windows :P

[Fadeout]

I ran a different test, same CPU (Core 2 Duo 8400) but with a clip encoded at high L5.1 but with lower res: 712x480
CoreAVC 2: 301.0
DivX 7: 312.5
DiAVC 1.0.1: 367.6 (22.1%)

Another clip, 720p L4.1 7000 Kbps:
CoreAVC 2: 195.5
DivX 7: 204
DiAVC 1.0.1: 232 (18.6%)

1080p L4.1 13.3 Mbps:
CoreAVC 2: 88.9
DivX 7: 92.8
DiAVC 1.0.1: 112 (26%)

1080p L5.1 18.9Mbps (Planet Earth clip):
CoreAVC 2: 64.5
DivX 7: 68
DiAVC 1.0.1: 84.8 (31.5%)

So at least on this CPU class DiAVC seems reliably faster of about 15/25% depending on streams, but sensibly faster nonetheless.

Edit: I think I calculated the % all wrong, redone them.

Edit2: Added the DivX 7. Quite great results considering these are free. Are there any bugs or reasons why not using them by default in place of CoreAVC?

[lnatan25]

I beg to differ on results as many are swayed and not properly done in this thread as I have already said... For you to state that it's better is a matter of opinion and you should leave that up to your customers to state or post real world results on.
Oh? And for you to put "Fastest Software Decoder" in your site isn't? I don't see any disclaimer on your site that states this is only your opinion. :rolleyes:

BTW, all your posts in this thread are all off topic, trolling, "should post in your own topic", etc. Isn't this how you categorize any non-favorable post in your product's thread?

[schweinsz]

Thanks for the list, and after a little research about the things you missed, I realize I wrote Main Profile, what I meant was High profile. If you had a list on those features too, that would be awesome (and a comment on support in DiAVC). And sorry for being a little OT here.
All features in high profile:
1: poc type 0,1,2,
2: field coding, frame coding and mbaff
3: gaps_in_frame_num_value_allowed_flag = 0, 1
4: direct_8x8_inference_flag = 0,1
5: cabac and cavlc
6: chroma_qp_index_offset
7: constrained_intra_pred_flag = 0,1
8: slice_type = I, P, B
9: direct_spatial_mv_pred_flag = 0,1
10: ref_pic_list_reordering
11: deblock_alpha_beta_offset
12: multi-sps and multi-pps
13: long_term_reference_picture
14: IPCM support
15: MB_Partition including 16x16, 16x8, 8x16, 8x8, 8x4, 4x8, 4x4
16: custom quantization matrix
17: transform 8x8 and 4x4
18: explicit weighted pred for P slice and implicit and explicit weighted pred for B slice
19: second_chroma_qp_offset
20: multi-reference frames
21: chroma_format_idc=0,1

Monochrome video (chroma_format_idc=0) is not supported by DiAVC.

[schweinsz]

I guess u r from China? I saw the serif font in your screenshot which is default in Chinese version of windows :P
You are right, I am in China.

[hajj_3]

For you to state that it's better is a matter of opinion and you should leave that up to your customers to state or post real world results on.

We will be able to post our real world results within the next few days as he's making a trial version available that will last around 10days.

I'll be testing it on 4 different systems so that should give some good informative results.

[JimmyZ]

You are right, I am in China.

great, do you accept alipay?

[schweinsz]

DiAVC 1.0.2 is available.
changelog:
Fix a bug related to the reading harddisk serial number.

Hope this version can fix the machine code problem.

A 14 days trial version is also available now, and I update the DiAVC sdk to use the 14 days trial version.
http://di-avc.com/diavc_14day_trialversion.zip

The improved CAVLC will be available in DiAVC 1.0.3 about 5 days later.

[hajj_3]

what tool can i use to benchmark diavc with divx and coreavc?

[canTsTop]

In the DiAVC version 1.0 the problem is fixed. It is related to fault reference reordering.
seeking not fixed, after seek video is not moving for about 3-5 seconds. tested with diavc_14day_trialversion.zip

[schweinsz]

what tool can i use to benchmark diavc with divx and coreavc?
timecodec (http://haali.cs.msu.ru/mkv/timeCodec.exe)
Select the null renderer to test.

[bob0r]

schweinsz,


Please update the screenshot on your website, with the spelling fixed. (the typos were already pointed out in this thread.)
We, the people of doom9, can help you with the spelling and grammer errors, just fix them right away! :)

Also, get rid of the useless protection. You are only annoying the people who want to support you. And even missing some sales as some have said they won't buy (try) your product because of the hardware linking.
Your protection can be removed in under five minutes anyway.

Some protection is ok, but make it user friendly.
The best way would be username/serial and activation i guess.
But then you need to get a server running + a promise that it stays online X years.
When you buy it, you can activate it let's say 50 times.
That should be enough for people to test and use it, and yes some will share it with their friends, but mouth to mouth is still the best way to get noticed.

People who buy it now, should have a serial for life.
If you plan to expand your product, just ask more money for new customers, just be clear about that upfront.

Also keep developing your product. People usually want the latest version, piracy groups hate small useless updates, so if you keep active, more poeple will probably buy it.

Focus on an userfriendly product, rather than making it hard for everyone, including yourself.

What also puts me off: "World's Fastest H.264 High-Definition Software Decoder" I truely don't care about that. When i buy something, i care about a nicely developed product with active developement.

You can make your product better than any other by staying active and helpful to the people who have issues.

I hope your product will do well, and you can make some nice fair profit of it. I will not help in any way financial.


Stay honest and keep doing your best!!

[Episodio1]

I haven't downloaded DiAVCD, but I've just paid for his work, for working alone and for all the people repeatadly asking him to make it opensourced or change its protection.

Please, stay on topic. :(

[buzzqw]

i prefer license tied to mail
1 mail = 1 license

register with one mail -> got the activation
and use it for 3 pc (check on line for numbers of pc)

every 6 month set the number of pc to 0

with this kind of registration i will bought it

BHH

[hajj_3]

whats the command to register diavc.ax in windows7 x64 ultimate? I've put it in C:\Windows\System32\, i've tried doing "regsvr32 diavc.ax" in command prompt but i get this error message:

http://i49.tinypic.com/4sb0y8.jpg

also i can't seem to get divx h264 decode to appear in the timeCodec.exe dropdown list, ffdshow and coreavc are in the list, i've just installed the latest divx release but it isn't listed in the dropdown box. I obviously can't see diavc in the list either as the register command wont work.

[Disabled]

register with one mail -> got the activation
and use it for 3 pc (check on line for numbers of pc)

Thats never gonna be legal, because he only sells licenses to be installed on one computer. He has to pay the MPEG LA fees for every decoder he sells, so if you want to install it more than once you at least would need to pay that extra fee the MPEG LA charges. Thats a point where I like those Office Home packs from Microsoft you are allowed to install three times. Don't get me wrong, I'd also prefere an email tied license not hardware, but I'd prefere if he'd trust us over that.

[hajj_3]

i've copied it to syswow64 now, what command in command prompt do i need as the 1 i was using still doesn't work.

[hajj_3]

hmm, i had it in the list before as i installed the retail a few days ago thinking it was a trial, when i tried to benchmark it i got an error, i thought by registering the trial .ax file it would make it work but it removed it from the list, i've tried several times and it won't re-add to the list:(

Lets hope he creates a trial installer that removes any registry entries from previous versions and automatically registers the codec too.

[Episodio1]

STEPHEN, I did that and it worked: it tooked me to my paypal account.

[Stephen R. Savage]

Huh. Maybe I'm doing something wrong.

Edit: Apparently, it was this issue - http://community.contractwebdevelopment.com/paypal-sorry-your-last-action-could-not-be-completed

[Disabled]

What country are you from? And do you have Paypal there? Or are you surfing through some kind of proxy? Or somehow can't connect to https pages?

[txporter]

Huh. Maybe I'm doing something wrong.

Might be a browser thing. I believe that I have seen issues with Paypal and Chrome. Not sure what browser you are using, but try another and see if you have the same problem.

[schweinsz]

i prefer license tied to mail
1 mail = 1 license

register with one mail -> got the activation
and use it for 3 pc (check on line for numbers of pc)

every 6 month set the number of pc to 0

with this kind of registration i will bought it

BHH
Currently, If you buy it, you can require more password for different computers by your e-mail tied to your paypal you pay for me using. I am not an expert on web page, I will make it automatically in future.

[schweinsz]

hmm, i had it in the list before as i installed the retail a few days ago thinking it was a trial, when i tried to benchmark it i got an error, i thought by registering the trial .ax file it would make it work but it removed it from the list, i've tried several times and it won't re-add to the list:(

Lets hope he creates a trial installer that removes any registry entries from previous versions and automatically registers the codec too.
Delete all keys in the following positions, and re-try it.
The DiAVC has a dependency on msvcr90.dll, I believe the installer of the DiAVC 1.0.2 has installed it.
The positions of key is different from the following positions for 64bit windows.

"HKEY_CLASSES_ROOT\\CLSID\\{5DFA20A4-C343-45DF-A46E-EC1711E4EE32}\\InprocServer32"
"HKEY_CLASSES_ROOT\\CLSID\\{083863F1-70DE-11d0-BD40-00A0C911CE86}\\instance\\{5DFA20A4-C343-45DF-A46E-EC1711E4EE32}"

[hajj_3]

can't find those, please make a trial installer for v1.03 and make sure it removes all traces of previous versions.

[buzzqw]

Currently, If you buy it, you can require more password for different computers by your e-mail tied to your paypal you pay for me using. I am not an expert on web page, I will make it automatically in future.

you got my mail

thanks for your software

BHH

[Stephen R. Savage]

@hajj3: If you use Windows64, you need to look under HKCR\Wow6432Node\CLSID instead of HKCR\CLSID.

@schweinsz: Please fix the GUI typos. They just look unprofessional. Also, I believe the "prefered (sic) decoder" checkbox does not actually do anything. It always remains checked upon re-opening the property page, and it does not change the merit of the filter. Also, please read http://community.contractwebdevelopment.com/paypal-sorry-your-last-action-could-not-be-completed - a PayPal bug could be costing you customers.

Quick test:
720p, ~2000 kbps, Core 2 "Merom" T7250
DiAVC 1.0.2 - 172.3 fps
CoreAVC 2.0 - 144.9 fps
Relative performance - 118.9%

[mariush]

I've installed the codec using the setup package on the download page but it's not possible to use it...

In MPC-HC, I disabled both internal filters (dxva and ffmpeg), added DiAVC in the External Filters tab and in the same tab I've set CoreAVC to Block so that it won't start. The codec is just not used, MPC-HC says it can't find any codecs this way. Removing the bloc on CoreAVC makes it run and display the video.

Oh, and the filter does not appear in the list in MPC-HC, when I click on Add filter, I had to use Browse to find it.

The OS is Windows 2003 if that could be the problem.

[mariush]

Ok... unregistered the filter, copied over the 14 day trial .ax file and registered it and it works and it also appears in the Filters list in MPC-HC... pretty dumb to not work if it's unregistered especially as you don't say anything about it on the main page

[hajj_3]

Managed to find 1 of the keys and deleted it, still no use, i give up, i'll wait for an installer to remove the reg keys and install and register it properly, hopefully that won't be too far from now.

[Stephen R. Savage]

I just tried to actually play something with DiAVC. I can not get it to load at all in MPC-HC unless I set it to administrator mode ("DiAVC initialization failed"). However, it loads fine in limited mode in Avisynth/DirectShowSource or in GraphEdit. Please fix this, as it makes DiAVC essentially useless for my purposes.

schweinsz, I seriously think that you should go back and repolish your software. To be frank, this is not something I could call a finished product with a straight face.

[schweinsz]

I've installed the codec using the setup package on the download page but it's not possible to use it...

In MPC-HC, I disabled both internal filters (dxva and ffmpeg), added DiAVC in the External Filters tab and in the same tab I've set CoreAVC to Block so that it won't start. The codec is just not used, MPC-HC says it can't find any codecs this way. Removing the bloc on CoreAVC makes it run and display the video.

Oh, and the filter does not appear in the list in MPC-HC, when I click on Add filter, I had to use Browse to find it.

The OS is Windows 2003 if that could be the problem.
The DiAVC installer package comprises of the retail version, when it is registered, it will work.

[schweinsz]

Managed to find 1 of the keys and deleted it, still no use, i give up, i'll wait for an installer to remove the reg keys and install and register it properly, hopefully that won't be too far from now.
download the DiAVC rc1 (http://di-avc.com/DiAVC_rc1.zip), unpack it and copy the DiAVCSetting.exe to the position where there is your DiAVC trial version, run the DiAVCSetting.exe and register and unregister the DiAVC, perhaps it will help.

[schweinsz]

I just tried to actually play something with DiAVC. I can not get it to load at all in MPC-HC unless I set it to administrator mode ("DiAVC initialization failed"). However, it loads fine in limited mode in Avisynth/DirectShowSource or in GraphEdit. Please fix this, as it makes DiAVC essentially useless for my purposes.

schweinsz, I seriously think that you should go back and repolish your software. To be frank, this is not something I could call a finished product with a straight face.
I will immediately share a bug-finding version with you.

[schweinsz]

I just tried to actually play something with DiAVC. I can not get it to load at all in MPC-HC unless I set it to administrator mode ("DiAVC initialization failed"). However, it loads fine in limited mode in Avisynth/DirectShowSource or in GraphEdit. Please fix this, as it makes DiAVC essentially useless for my purposes.

schweinsz, I seriously think that you should go back and repolish your software. To be frank, this is not something I could call a finished product with a straight face.

Help me with the following test to find the problem.
Download the bug-finding diavc (http://di-avc.com/temp/diavc.7z), backup the current one and replace it with the downloaded one, playback H.264 video using the MPC-HC without the administrator right, report the result to me.

Another test, run the DiAVC Registration.exe, verify if the machine code and the password exist correctly.

[hajj_3]

DiAVCSetting.exe worked in registering it:) I can now see DiAVC in timeCodec.exe dropdown list, i just need divx to appear in that list now somehow:( Divx appears in DiAVCSetting.exe but just not in timeCodec.

4GB Ram, Win7 x64, Core 2 Quad Q6700 @ 3.44GHZ:

720p .mkv file L4.1, Renderer was "Null":

DiAVC: User: 54s, kernel: 0s, total: 54s, real: 135s, fps: 1331.9, dfps: 537.8 - 109%
FfdShow v3274 32bit: User: 526s, kernel: 0s, total: 526s, real: 529s, fps: 138.2, dfps: 137.6 - 11.4%
CoreAVC 2.0: User: 47s, kernel: 12s, total: 60s, real: 889s, fps: 1211.4, dfps: 81.9 - 100%
Divx:



720x400 .mkv file L4.1, Renderer was "Null":

DiAVC: User: 72s, kernel: 1s, total: 74s, real: 127s, fps: 2448.7, dfps: 1424.4 - 106.95%
FfdShow v3274 32bit: User: 432s, kernel: 0s, total: 433s, real: 435s, fps: 418.3, dfps: 416.3 - 18.35%
CoreAVC 2.0: User: 61s, kernel: 18s, total: 79s, real: 965s, fps: 2278.5, dfps: 187.9 - 100%
Divx:



1080p .mkv file L4.1, Renderer was "Null":

DiAVC: User: 207s, kernel: 1s, total: 209s, real: 722s, fps: 838.4, dfps: 242.6 - 110.52%
FfdShow v3274 32bit: User: 2857s, kernel: 1s, total: 2858s, real: 2871s, fps: 61.3, dfps: 61.0 - 8.17%
CoreAVC 2.0: User: 200s, kernel: 33s, total: 233s, real: 2687s, fps: 750.2, dfps: 65.2 - 100%
Divx:

so 7-10.5% faster for me on my core2 quad 3.44ghz cpu than CoreAVC 2.0

[Stephen R. Savage]

@hajj3, there is something wrong with your testing methodology. I am fairly certain that ffmpeg is not 10x slower than CoreAVC. 1000+ fps on 720p also seems unrealistically high.

@schweinsz, running "DiAVC Registration.exe" as non-administrator brings up a blank window. As administrator, it prints my serial key and hardware code. The test version of DiAVC presents a "DiAVC OpenKey Error", then a "DiAVC OpenFile Error", and finally the initialization error. However, no errors occur when using DiAVC as non-administrator in GraphStudio.

Edit: Be advised that the Start Menu item that your installer adds for "DiAVC Registration" does not run as administrator by default. Also, for some reason, it does not have "Run as Administrator" in the context menu. For usability reasons, I suggest you update your installer to change this.

[Keiyakusha]

@hajj3, there is something wrong with your testing methodology. I am fairly certain that ffmpeg is not 10x slower than CoreAVC. 1000+ fps on 720p also seems unrealistically high.

I guess its possible if non-mt decoder was used... If so, test indeed is wrong.

[Disabled]

I still wonder what he did while benchmarking CoreAVC. Usually you compare dfps and thats really catastrophic. Did you do nothing else during benchmarking? Because that destroys every result. Did the CoreAVC decoder need 7 times as long to benchmark as Diavc as the real time suggests?

[Warpman]

just did a quick test myself

diavc trial User: 83s, kernel: 0s, total: 84s, real: 152s, fps: 420.5, dfps: 232.1
core avc 2.0 User: 78s, kernel: 0s, total: 79s, real: 169s, fps: 447.6, dfps: 208.9
ffdshow r3274 User: 69s, kernel: 0s, total: 69s, real: 212s, fps: 507.1, dfps: 166.5
divx 1.1 User: 86s, kernel: 0s, total: 87s, real: 180s, fps: 404.6, dfps: 196.6

similar setup: q6600 @3,2Ghz 4GB RAM winXP 32bit
file used: 35264frames 1080P level unrestricted
output yv12

Don't know but my results look a bit more sane to me ;)

[schweinsz]

@schweinsz, running "DiAVC Registration.exe" as non-administrator brings up a blank window. As administrator, it prints my serial key and hardware code. The test version of DiAVC presents a "DiAVC OpenKey Error", then a "DiAVC OpenFile Error", and finally the initialization error. However, no errors occur when using DiAVC as non-administrator in GraphStudio.
This is due to the DiAVC.ax has not the right to read the registry key or open the file "harddrive0". You should give it the right. While the graphstudio give the right to DiAVC.ax to read the registry key. You should give the DiAVC.ax the right to read/write the registry key.

[Stephen R. Savage]

I refuse. I refuse absolutely. I will never change any permissions on my system because a program is badly written. Using reg.exe, I can read both rgtcode and password from HKCR without administrator rights. GraphStudio has no ability to grant access to resources that any other user process would not have. The problem lies entirely with DiAVC. DiAVC has no need to open my system registry in R/W mode, nor to query my hardware if a valid activation code is present.

PS C:\Windows\System32> reg query "HKCR\Wow6432Node\CLSID\{083863F1-70DE-11d0-BD
40-00A0C911CE86}\Instance\{5DFA20A4-C343-45DF-A46E-EC1711E4EE32}\password"

HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{083863F1-70DE-11d0-BD40-00A0C911CE86}\Insta
nce\{5DFA20A4-C343-45DF-A46E-EC1711E4EE32}\password
(Default) REG_BINARY [password]

PS C:\Windows\System32> reg query "HKCR\Wow6432Node\CLSID\{083863F1-70DE-11d0-BD
40-00A0C911CE86}\Instance\{5DFA20A4-C343-45DF-A46E-EC1711E4EE32}\rgtcode"

HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{083863F1-70DE-11d0-BD40-00A0C911CE86}\Insta
nce\{5DFA20A4-C343-45DF-A46E-EC1711E4EE32}\rgtcode
(Default) REG_BINARY [key]

Moreover, it is entirely your responsibility as the developer to find and fix bugs. You should not be asking your customers to help you do your job.

[schweinsz]

I refuse. I refuse absolutely. I will never change any permissions on my system because a program is badly written. Using reg.exe, I can read both rgtcode and password from HKCR without administrator rights. DiAVC has no need to open my system registry in R/W mode, nor to query my hardware if a valid activation code is present.

PS C:\Windows\System32> reg query "HKCR\Wow6432Node\CLSID\{083863F1-70DE-11d0-BD
40-00A0C911CE86}\Instance\{5DFA20A4-C343-45DF-A46E-EC1711E4EE32}\password"

HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{083863F1-70DE-11d0-BD40-00A0C911CE86}\Insta
nce\{5DFA20A4-C343-45DF-A46E-EC1711E4EE32}\password
(Default) REG_BINARY [password]

PS C:\Windows\System32> reg query "HKCR\Wow6432Node\CLSID\{083863F1-70DE-11d0-BD
40-00A0C911CE86}\Instance\{5DFA20A4-C343-45DF-A46E-EC1711E4EE32}\rgtcode"

HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{083863F1-70DE-11d0-BD40-00A0C911CE86}\Insta
nce\{5DFA20A4-C343-45DF-A46E-EC1711E4EE32}\rgtcode
(Default) REG_BINARY [key]
I am seeking to solve the problem. but the DiAVC must has the right to read the registry key to know if it is registered, and the the data in property page is stored in the registry key, so the DiAVC must read/write the property page data.
When valid activation code exists, the DiAVC will not query your hardware unless reading valid activation code failed.
I believe the reg.exe has the part that promote its right to read/write registry key.

[Stephen R. Savage]

There can not possibly be any autoelevation occurring. I have attempted this as well from a non-administrator account that has no ability to elevate at all, and I could still open the key. From Process Monitor, I see that there is an attempt to open rgtcode and password in R/W mode that returns ACCESS DENIED in MPC-HC but SUCCESS in all other applications tested.

Edit: schweinsz, I believe the problem lies in the attempt to use R/W access. MPC-HC uses the Vista+ UAC framework to set itself to the lowest possible user level, which prevents this from succeeding. I believe that you may be able to fix this by setting the filter to open the keys in READ mode on initialization and switch to WRITE mode only when the "input password" button is pressed.

Edit2: For example, I used Process Explorer to start GraphStudio in the lowest access ("Run as Limited User") which is completely sandboxed and is the same mode that MPC-HC uses. I then get the "DiAVC initialization failed." error. DiAVC must not make any assumptions about the availability of R/W access.

[schweinsz]

There can not possibly be any autoelevation occurring. I have attempted this as well from a non-administrator account that has no ability to elevate at all, and I could still open the key. From Process Monitor, I see that there is an attempt to open rgtcode and password in R/W mode that returns ACCESS DENIED in MPC-HC but SUCCESS in all other applications tested.

Edit: schweinsz, I believe the problem lies in the attempt to use R/W access. MPC-HC uses the Vista+ UAC framework to set itself to the lowest possible user level, which prevents this from succeeding. I believe that you may be able to fix this by setting the filter to open the keys in READ mode on initialization and switch to WRITE mode only when the "input password" button is pressed.

Edit2: For example, I used Process Explorer to start GraphStudio in the lowest access ("Run as Limited User") which is completely sandboxed and is the same mode that MPC-HC uses. I then get the "DiAVC initialization failed." error. DiAVC must not make any assumptions about the availability of R/W access.
Ok, I will fix the problem in the next release (1.0.3) at this night or tomorrow.

[lych_necross]

The above is why I am leery to try this decoder out. It doesn't seem like it is ready for primetime yet.

[Stephen R. Savage]

Well, it's all fun and games till someone gets their eyes poked out. In retrospect, this doesn't seem to have been the best use of $10 though.

[Jiffy]

I tried the trial version last night and it worked really well, I'm really impressed!

I'll definately get the release version tonight.

[schweinsz]

Well, it's all fun and games till someone gets their eyes poked out. In retrospect, this doesn't seem to have been the best use of $10 though.
Don't fell dispointed, I am improving the DiAVC everyday. I will try my best to make customers satisfied.

[lych_necross]

I admire your dedication schweinsz. Other avc decoder companies could learn from your example.

[schweinsz]

DiAVC 1.0.3 is available.
Change Logs 20100226
Improved CAVLC.
Fix a compatibility problem about reading/writing registry key.

The DiAVC Registration.exe is built on "UAC Execution Level=requireAdministrator" while the diavc.ax is on "UAC Execution Level=asInvoker". Tomorrow I will provide an diavc.ax with "UAC Execution Level=requireAdministrator".

Next I will work on error concealment, then web page and install package.

[hajj_3]

Nice to see this quick progress!

[clsid]

The DirectShow filter requires administrator privileges? That is just plain wrong.

[Stephen R. Savage]

Thank you. Filter now works in MPC-HC and other limited-elevation applications. Like CLSID, I am confused by this statement:

Tomorrow I will provide an diavc.ax with "UAC Execution Level=requireAdministrator".

Why would you change DiAVC to require administrator permissions?

Edit: Some tests with CAVLC performance on DiAVC 1.0.3.

Twilight, Teaser #1
Apple HD Trailers, CAVLC, 9549 kbps
===================================
CoreAVC 2.0 x86: 90.5970 fps
(89.7436, 91.1141, 90.9457)

CoreAVC 2.0 x64: 84.7417 fps
(85.2306, 84.9775, 84.0267)

DiAVC 1.0.3 x86: 89.5522 fps
(90.1306, 88.5779, 89.9645)

The performance difference to CoreAVC is now negligible in this case. I am a bit surprised to see that CoreAVC is slower in 64-bit.

Edit2: Since we've all seen the same old FPS tests over and over, I thought I'd do something a bit different. CPU performance graphs captured in Windows Performance Monitor (sample resolution 1s, 100 = 1 CPU used).

CoreAVC 2.0
http://img408.imageshack.us/i/coreavc.png/

DiAVC 1.0.3
http://img43.imageshack.us/i/diavc.png/

[hajj_3]

I can't figure out how to do a graph like that on Win7 showing the cpu usage with the percentage values and averages etc:( Are you using performance monitors built into windows or a 3rd party application?

[schweinsz]

The DirectShow filter requires administrator privileges? That is just plain wrong.
The reason I said that is to get feedback from others. Thank you.

[Stephen R. Savage]

I can't figure out how to do a graph like that on Win7 showing the cpu usage with the percentage values and averages etc:( Are you using performance monitors built into windows or a 3rd party application?

http://technet.microsoft.com/en-us/library/cc749154.aspx

[Jiffy]

The reason I said that is to get feedback from others. Thank you.

I think most people are going to want to be able to run it from non-administrator accounts. E.g. if someone has a PC on their TV then they'll probably want the kids/friends/family to be able to play movies but not have access to change the machine.

It's a good idea to protect it from piracy somehow but there must be something you can read to identify the machine that doesn't need administrator privileges.

[Cyber-Mav]

I think most people are going to want to be able to run it from non-administrator accounts. E.g. if someone has a PC on their TV then they'll probably want the kids/friends/family to be able to play movies but not have access to change the machine.

It's a good idea to protect it from piracy somehow but there must be something you can read to identify the machine that doesn't need administrator privileges.

all the more reason for the codec to require admin rights to install. would you want an app to run that requires low level access to hardware information without requiring elevated account privlages? if the app is going to install files into the windows folder or program files folder i sure as hell dont want the installation being done by limited user accounts.

[Jiffy]

all the more reason for the codec to require admin rights to install. would you want an app to run that requires low level access to hardware information without requiring elevated account privlages? if the app is going to install files into the windows folder or program files folder i sure as hell dont want the installation being done by limited user accounts.

Nobody's saying install can't require administrator rights. (edit: not that a a package can just deicde to be installable as a normal user anyway, it's up to you what normal users can do on your machine).

Playing movies doesn't require low level access to hardware information, so normal users should be able to do that.

[clsid]

It is normal that the installer and registration tool require administrator privileges. A directShow filter should works as a standard user. Thus it may only read keys from HKLM and write settings to HKCU.

[Stephen R. Savage]

Oh. I see that the property page writes its settings to HKCR. That is not correct. schweinsz, please change the filter to write user settings to HKCU.

[schweinsz]

Oh. I see that the property page writes its settings to HKCR. That is not correct. schweinsz, please change the filter to write user settings to HKCU.
Ok, I will fix the problem in the next release 1.0.4.

[sherpya]

Hi, I'm developing a wrapper dll for dshow filter, for now it's used in mplayer/mencoder

I would try to use diavc, but I wasn't able to make it works in graphstudio or using mpc, I've tested some old trial and the 1.0.3 that needs to be registered ?, the codec says nothing, just does not connects the pin

My OS is Windows XP x64 SP2 English, codec supported matrix on my page

my project page is:
http://oss.netfarm.it/dsnative/

while by mplayer/mencoder binaries are here:
http://oss.netfarm.it/mplayer-win32.php

I think you may be interested to have potential future mplayer/mencoder customers :)

[roozhou]

Hi, I'm developing a wrapper dll for dshow filter, for now it's used in mplayer/mencoder

I would try to use diavc, but I wasn't able to make it works in graphstudio or using mpc, I've tested some old trial and the 1.0.3 that needs to be registered ?, the codec says nothing, just does not connects the pin

My OS is Windows XP x64 SP2 English, codec supported matrix on my page

my project page is:
http://oss.netfarm.it/dsnative/

while by mplayer/mencoder binaries are here:
http://oss.netfarm.it/mplayer-win32.php

I think you may be interested to have potential future mplayer/mencoder customers :)
IMO you don't have to use a dshow wrapper to call diAVC.

[Stephen R. Savage]

@sherpya: The old testing versions are time-limited and expired now. The 1.0.3 filter on the website is payware and requires a serial before it accepts pins. Perhaps you can try the 14-day trial version instead? I know this is confusing, but the website is apparently very low on schweinsz's priorities.

[schweinsz]

Hi, I'm developing a wrapper dll for dshow filter, for now it's used in mplayer/mencoder

I would try to use diavc, but I wasn't able to make it works in graphstudio or using mpc, I've tested some old trial and the 1.0.3 that needs to be registered ?, the codec says nothing, just does not connects the pin

My OS is Windows XP x64 SP2 English, codec supported matrix on my page

my project page is:
http://oss.netfarm.it/dsnative/

while by mplayer/mencoder binaries are here:
http://oss.netfarm.it/mplayer-win32.php

I think you may be interested to have potential future mplayer/mencoder customers :)
You can try the trial version (http://di-avc.com/diavc_14day_trialversion.zip).
I can provide another trial version to you before it expires.
Besides, you can try the DiAVC sdk (http://di-avc.com/diavc_sdk1.0.2.zip). It is more flexible than a directshow-based filter.

[sherpya]

the wrapper is generic for multiple codecs, I don't think it would be useful for me to have a codec specific only wrapper.
I'll try again the trial

[LigH]

I believe the wanted meaning was that the DirectShow filter API itself is already rather generic, therefore it should be possible to use any e.g. "AVC decoder as DirectShow filter" in the same way, as long as it is installed in Windows and registered as available DirectShow decoder filter.

[sherpya]

yes, the wrapper works also without registering the filter in the system

[sherpya]

ok the trial worked, I'll add the codec to compatibilty matrix

the current entry is:

videocodec diavc
info "DiAVC H.264 Decoder (DiAVC)"
status working
fourcc H264,h264
fourcc X264,x264
fourcc avc1 AVC1,AVC1
fourcc davc,DAVC
fourcc VSSH
format 0x10000005
driver dsnative
dll "diavc.ax"
guid 0x5dfa20a4, 0xc343, 0x45df, 0xa4, 0x6e, 0xec, 0x17, 0x11, 0xe4, 0xee, 0x32
out YV12,IYUV,I420,YUY2


does it look correct?

[roozhou]

the wrapper is generic for multiple codecs, I don't think it would be useful for me to have a codec specific only wrapper.
I'll try again the trial
The problem is you need a dll wrapper outside mplayer.exe. While with diAVC SDK, you can code something like libmpcodecs/vd_diavc.c and put it inside mplayer build system.

[schweinsz]

ok the trial worked, I'll add the codec to compatibilty matrix

the current entry is:

videocodec diavc
info "DiAVC H.264 Decoder (DiAVC)"
status working
fourcc H264,h264
fourcc X264,x264
fourcc avc1 AVC1,AVC1
fourcc davc,DAVC
fourcc VSSH
format 0x10000005
driver dsnative
dll "diavc.ax"
guid 0x5dfa20a4, 0xc343, 0x45df, 0xa4, 0x6e, 0xec, 0x17, 0x11, 0xe4, 0xee, 0x32
out YV12,IYUV,I420,YUY2


does it look correct?
correct basicly. But the out includes RGB32, RGB24, UYVY, NV12 also.

[sherpya]

yes I've seen config page, but preferred is still YV12, right?
RGB24 gives me wrong image colors, but I think I should check some params

[schweinsz]

yes I've seen config page, but preferred is still YV12, right?
Right

[ExSport]

seeking not fixed, after seek video is not moving for about 3-5 seconds. tested with diavc_14day_trialversion.zip
Reproduced the problem.
Root cause is "EVR custom" output in MPC-HC :rolleyes:
When you choose VMRx or pure EVR, seeking works OK.:cool:
Tested with 14day trial and "timehack" due to expired time:)
timehack=no crack but open mind and reading between lines...

[Episodio1]

"Root cause is "EVR custom" output in MPC-HC"

Is something worng with "EVR custom"? I got problems with non-avc videos and "EVR custom" as well. :(

[Fadeout]

I have a shader in mpc-hc to increase the brightness a bit, and it behaves the same way if I increase the brightness option in CoreAVC:

sampler s0 : register(s0);

#define const_1 (16.0/255.0)
#define const_2 (255.0/255.0)

float4 main(float2 tex : TEXCOORD0) : COLOR
{
// original pixel
float4 c0 = tex2D(s0,tex);

return (c0 * const_2) + const_1;
}


But why the brightness option in DiAVC gives a completely different output? As if the colors change a bit, not just the brightness. (this because I'm trying to use MadVR, but can't use shaders with it, any other solution?)

[schweinsz]

I have a shader in mpc-hc to increase the brightness a bit, and it behaves the same way if I increase the brightness option in CoreAVC:

sampler s0 : register(s0);

#define const_1 (16.0/255.0)
#define const_2 (255.0/255.0)

float4 main(float2 tex : TEXCOORD0) : COLOR
{
// original pixel
float4 c0 = tex2D(s0,tex);

return (c0 * const_2) + const_1;
}


But why the brightness option in DiAVC gives a completely different output? As if the colors change a bit, not just the brightness. (this because I'm trying to use MadVR, but can't use shaders with it, any other solution?)

The option "Brightness Offset" in DiAVC changes the brightness using the following expression:
luma = ClipTo0_255(luma+offset);
the offset is gotten from the property page.
The option "Contrast" in DiAVC changes the brightness using the following expression:
luma = ClipTo0_255(factor*(luma-128)+128);

[Fadeout]

Can someone tech-savvy figure the difference between the two?

I know that the shader I use mimics exactly the output of CoreAVC option. So if I set my shader to 16 (const_1) I get the same output if I set the Brightness option to 16 in CoreAVC panel.

Instead if I set the brightness to 16 in DiAVC there's something weird happening to the colors.

[Keiyakusha]

well, don't know about brightness in CoreAVC, never tried it but shader in mpc-hc - levels, not brightness. there should be difference. also if you using EVR-CP/Sync - don't see the reason why you need that shader... there is separate switch for that.

[schweinsz]

sampler s0 : register(s0);

#define const_1 (16.0/255.0)
#define const_2 (255.0/255.0)

float4 main(float2 tex : TEXCOORD0) : COLOR
{
// original pixel
float4 c0 = tex2D(s0,tex);

return (c0 * const_2) + const_1;


If you want to change const_2, change the "Contrast" in DiAVC. If you want to change const_1, change the "Brightness Offset" in DiAVC.
luma = Clipto0_255(luma*(128+contrast)/128 - contrast + brightnessoffset);

The "Contrast" and "Brightness Offset" have no influence on chroma components, if you meet something wrong, report to me.

[LigH]

Little typo in the decoder filter user interface:

Brightness offset: Black ... Write / White

[bob0r]

Little typo in the decoder filter user interface:

Brightness offset: Black ... Write / White

http://www.fallen-legion.eu/news/data/upimages/DoubleFacePalm.jpg

[yesgrey]

How can I use the trial version?
I've downloaded it and registered it with regsvr32 but it doesn't work...

[schweinsz]

Little typo in the decoder filter user interface:

Brightness offset: Black ... Write / White
I am sorry, I will fix it in the next release in about 10 days.

[schweinsz]

How can I use the trial version?
I've downloaded it and registered it with regsvr32 but it doesn't work...
It is outdated. Try this (http://di-avc.com/diavc1.0.3trial.7z). It will be outdated four days later. The trial version has a slower startup than the normal version.

[Fadeout]

I made a low quality gif to explain that weird brightness problem. Quality is low but I can confirm that the difference is what I see in full quality.

The first darker frame is the original. The second is if I tweak brightness with shader or CoreAVC, third is the brightness in DiAVC. If you notice the skin tone in DiAVC seem to go yellow.

http://www.makeagif.com/media/3-14-2010/15Aprh.gif

[schweinsz]

I made a low quality gif to explain that weird brightness problem. Quality is low but I can confirm that the difference is what I see in full quality.

The first darker frame is the original. The second is if I tweak brightness with shader or CoreAVC, third is the brightness in DiAVC. If you notice the skin tone in DiAVC seem to go yellow.

http://www.makeagif.com/media/3-14-2010/15Aprh.gif
I can't get to http://www.makeagif.com/media/3-14-2010/15Aprh.gif.
Could you upload it to multiupload or mail to me at sales@di-avc.com?

[schweinsz]

I made a low quality gif to explain that weird brightness problem. Quality is low but I can confirm that the difference is what I see in full quality.

The first darker frame is the original. The second is if I tweak brightness with shader or CoreAVC, third is the brightness in DiAVC. If you notice the skin tone in DiAVC seem to go yellow.

http://www.makeagif.com/media/3-14-2010/15Aprh.gif
I don't know if your shader treat all three components. If it is, you should change the saturation to same position with the contrast. The contrast only changes the luma component, while the saturation only changes the chroma component using the same method with contrast.

[yesgrey]

It is outdated. Try this.
Thanks, it's working.

Here are my benchmark results with Intel E2160@2.52GHz:
ffdshow 3316
User: 4s, kernel: 0s, total: 4s, real: 4s, fps: 45.4, dfps: 43.2
User: 4s, kernel: 0s, total: 4s, real: 4s, fps: 44.1, dfps: 43.2
User: 4s, kernel: 0s, total: 4s, real: 4s, fps: 44.1, dfps: 43.2

ffdshow-mt 3316
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 760.5, dfps: 74.3
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 808.0, dfps: 73.9
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 680.4, dfps: 74.3

ffdshow-mt 3316 DXVA
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 4309.3, dfps: 65.0
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 4309.3, dfps: 65.0
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 4309.3, dfps: 64.6

CoreAVC 2.0.0
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 562.1, dfps: 79.3
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 478.8, dfps: 78.8
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 404.0, dfps: 78.8

CoreAVC 2.0.0 (CUDA)
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 445.8, dfps: 64.0
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 538.7, dfps: 64.6
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 380.2, dfps: 64.0

DiAVC 1.0.3
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 923.4, dfps: 88.6
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 680.4, dfps: 88.6
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 1077.3, dfps: 89.8

[yesgrey]

The trial version has a slower startup than the normal version.
I don't know if it's the slowing down that you have referred, but my experience with it in mpc-hc when using madVR as the video renderer was not good. Whenever I tried to right click to go into and to leave from fullscreen it had a big lag, very unresponsive. Even a simple pause did not work well.
It might be something within madVR, because with other video renderers it worked fine, but the other AVC decoders work fine with madVR, so it might be something on DiAVC side too...
Can you take a look into it? Not using madVR is not an option to me...

[cyberlolo]

Hi. Sorry for the newbie question, but what does this decoder do that makes it better than CoreAVC? I mean, will it give better PQ than CoreAVC does? If not, what's the benefits of using it?

Thanks in advance!

[buzzqw]

every decoder MUST give the same output quality. a decoded frames must be the same (rounding error permitting) regardless of decoder.

DiAVC is simply FASTER on decoding.

BHH

[hajj_3]

This is faster at decoding so less of your cpu will be used to play a 720p x264 .mkv file for example. This will allow older less powerful cpu's to be able to play 720p compared to coreavc 2.0.

[cyberlolo]

Ok, thank you for explaining. I've got a new CPU (i7) so I think I'm fine with CoreAVC then.

:thanks:

[ExSport]

Ok, thank you for explaining. I've got a new CPU (i7) so I think I'm fine with CoreAVC then.

:thanks:
In this case also you don't need CoreAVC:cool:
Anyway it is also useful for powerful CPU when encoding with e.g. MEncoder. Faster decoding makes encoding also faster and will leave more CPU cycles to encoding part because decoding with DiAVC is less expensive on CPU.
My tests say that on 5:54 min sample(1920x800/x264):
- encoding to MPEG2 takes 6:52 with DiAvc
- encoding to MPEG2 takes 8:22 with builtin FFMPEG in MEncoder
- encoding to MPEG2 takes 7:59 with CoreAvc without CUDA
- encoding to MPEG2 takes 6:59 with CoreAvc and CUDA enabled
If somebody will ask why to encode to mpeg2....
Answer is PS3MediaServer and realtime encoding to DLNA client with subtitle support = faster and less CPU expensive decoder is a must for realtime transcoding:rolleyes:
But I have to say that DiAVC output is buggy with MEncoder(from Sherpya) right now(but output with other decoders are OK)...

[madshi]

Does DiAVC properly decode h264 streams which exceed Blu-Ray specs? CoreAVC shows artifacts with several of my Blu-Rays, so if DiAVC has no such problems, that would be a huge benefit over CoreAVC from my point of view.

(I don't care if these Blu-Rays are out of spec or not. They are what they are and I want them to be played back without artifacts.)

[shon3i]

Does DiAVC properly decode h264 streams which exceed Blu-Ray specs? CoreAVC shows artifacts with several of my Blu-Rays, so if DiAVC has no such problems, that would be a huge benefit over CoreAVC from my point of view.

(I don't care if these Blu-Rays are out of spec or not. They are what they are and I want them to be played back without artifacts.)
if mean something like L4.1 and >4 ref frames that is not even by H264 standard. If you mean 5 and 5.1 profile, then i think coreavc decode it perfectly, i don't see why not DiAVC aslo.

[sneaker_ger]

Maybe he's talking about the out of spec motion vectors used in some Blu-Rays.

[madshi]

I don't really know which part of the bitstream CoreAVC doesn't like. But I've had more than 5 different Blu-Rays (e.g. Chocolate (2008), Chinese Ghost Story, IIRC) where CoreAVC showed artifacts, while DivX didn't. According to BetaBoy these Blu-Rays are out of spec (not sure if out of Blu-Ray spec or out of h264 spec) and BetaBoy also said that Core is not likely to do anything about it, except trying to convince encoding houses to stick to the standard.

Edit: Yes, it's out of spec motion vectors. See BetaBoy's post here:

http://forum.doom9.org/showthread.php?p=1345508#post1345508

So is DiAVC able to decode out of spec motion vectors "properly"? CoreAVC is not able to. DivX is.

[nm]

I don't really know which part of the bitstream CoreAVC doesn't like. But I've had more than 5 different Blu-Rays (e.g. Chocolate (2008), Chinese Ghost Story, IIRC) where CoreAVC showed artifacts, while DivX didn't. According to BetaBoy these Blu-Rays are out of spec (not sure if out of Blu-Ray spec or out of h264 spec) and BetaBoy also said that Core is not likely to do anything about it, except trying to convince encoding houses to stick to the standard.

CoreAVC 2 doesn't have problems with non-compliant motion vectors anymore. (http://forum.doom9.org/showthread.php?p=1351646#post1351646) Are you using that or an earlier version?

[madshi]

CoreAVC 2 doesn't have problems with non-compliant motion vectors anymore.
Ooooh - thanks for the heads up! I didn't know that. BetaBoy was so firm in his older posts that it never occured to me that they'd change their mind just a couple of weeks later...

[Astrophizz]

CoreAVC does that haha

[schweinsz]

Edit: Yes, it's out of spec motion vectors. See BetaBoy's post here:

http://forum.doom9.org/showthread.php?p=1345508#post1345508

So is DiAVC able to decode out of spec motion vectors "properly"? CoreAVC is not able to. DivX is.
DiAVC has not the problem all along.

[madshi]

DiAVC has not the problem all along.
Great - thanks!

[ExSport]

Hi, I'm developing a wrapper dll for dshow filter, for now it's used in mplayer/mencoder

I would try to use diavc, but I wasn't able to make it works in graphstudio or using mpc, I've tested some old trial and the 1.0.3 that needs to be registered ?, the codec says nothing, just does not connects the pin

My OS is Windows XP x64 SP2 English, codec supported matrix on my page

my project page is:
http://oss.netfarm.it/dsnative/

while by mplayer/mencoder binaries are here:
http://oss.netfarm.it/mplayer-win32.php

I think you may be interested to have potential future mplayer/mencoder customers :)

Hello schweinsz.
Please can you help with finding where is the problem when using DiAVC decoder in MEncoder?
When coreavc, ffdshow, Divx or internal ffmpeg is used, encoded video is OK but when DiAVC used, video has something like badly ordered frames,it shutters like on this sample: http://www.mediafire.com/?oty1dqqm2on
Sherpya's dsnative wrapper has no problems with other decoders so I am asking, do your DiAVC something in other way than "other" decoders?
When this problem will be solved, you can expect money from me:cool:
I use MEncoder in PS3MediaServer DLNA server so encoding full HD source in realtime is necessary so every additional frame in decoding speed is big deal for realtime streaming/encoding.
Many thanks:thanks:
ExSport

[schweinsz]

Hello schweinsz.
Please can you help with finding where is the problem when using DiAVC decoder in MEncoder?
When coreavc, ffdshow, Divx or internal ffmpeg is used, encoded video is OK but when DiAVC used, video has something like badly ordered frames,it shutters like on this sample: http://www.mediafire.com/?oty1dqqm2on
Sherpya's dsnative wrapper has no problems with other decoders so I am asking, do your DiAVC something in other way than "other" decoders?
When this problem will be solved, you can expect money from me:cool:
I use MEncoder in PS3MediaServer DLNA server so encoding full HD source in realtime is necessary so every additional frame in decoding speed is big deal for realtime streaming/encoding.
Many thanks:thanks:
ExSport
I am sorry that I can't connect to the mediafire. Could you upload it to multiupload (http://www.multiupload.com/)?
Note that the output of badly ordered frames is an appearance of an expired trial version.

[ExSport]

Hello
Ok, uploaded here: http://www.multiupload.com/RJ5LER1JT7
Badly ordered frames in sample is not due to expired DiAVC:cool:
Sample shows "light" shutter, not "huge one" when DiAVC is expired. You can see on example.
All other external decoders works, only DiAVC not so it seems your decoder do something in other way than others:cool:
I tested it with older not-expired version posted by you in forum...it was latest 1.0.3
Many thanks

[schweinsz]

Hello
Ok, uploaded here: http://www.multiupload.com/RJ5LER1JT7
Badly ordered frames in sample is not due to expired DiAVC:cool:
Sample shows "light" shutter, not "huge one" when DiAVC is expired. You can see on example.
All other external decoders works, only DiAVC not so it seems your decoder do something in other way than others:cool:
I tested it with older not-expired version posted by you in forum...it was latest 1.0.3
Many thanks
The latest trial version 1.0.3 is expired about 5 days ago.

Edit1: Could you provide me the original H.264 bitstream? That will help me with the problem.

[hajj_3]

any eta on a new version and new website?

[schweinsz]

any eta on a new version and new website?
I have finished the error concealment, add the self-setting of threads number and colorspace in property page.
I am coding for mmx version tonight.

[Cyber-Mav]

i have a pentium 133mhz computer that doesnt have mmx support. can you make diavc work on non mmx cpus too?

[mp3dom]

Seriously, is it a joke? That CPU is 14 years old, and I highly doubt that it could even try to play an AVC file (the iPhone is an ARM at 600+MHz). I doubt that it could also have WinXP installed (maybe the 'Foundamental for Legacy PC' version)

[jethro]

Seriously, is it a joke? That CPU is 14 years old, and I highly doubt that it could even try to play an AVC file (the iPhone is an ARM at 600+MHz). I doubt that it could also have WinXP installed (maybe the 'Foundamental for Legacy PC' version)

You're clearly mistaken. I bet with the power of this oldie-but-goodie CPU all his 64x32 movies would play pefectly without skipping a single frame!:D

[LoRd_MuldeR]

I doubt that it could also have WinXP installed (maybe the 'Foundamental for Legacy PC' version)

You are right, it doesn't. Setup aborted immediately on my old Pentium 133 MHz machine. I think 233 MHz is the minimum requirement.

[roozhou]

You are right, it doesn't. Setup aborted immediately on my old Pentium 133 MHz machine. I think 233 MHz is the minimum requirement.

WinXP requires MMX.

[Cyber-Mav]

its running win98 se

[LoRd_MuldeR]

its running win98 se

You really can't expect any software developer to care about Windows 98 nowadays. Also many up-to-date software won't run without MMX.

[eddman]

Could someone post the CPU usage graphs of diavc compared to coreavc instead of these useless fps benchmarks?

[namaiki]

CPU usage graphs are even less reliable.

[eddman]

CPU usage graphs are even less reliable.

What's the most reliable method?

[LoRd_MuldeR]

Could someone post the CPU usage graphs of diavc compared to coreavc instead of these useless fps benchmarks?

Yeah, CPU usage is the worst performance measure of all. What matters is average throughput (frames per second), maybe also the minimum throughput would be interesting.

Example: I can easily add dummy threats that do nothing, but keep the CPU usage at 100% all the time. Does that improve performance? Certainly not...

What's the most reliable method?

http://haali.cs.msu.ru/mkv/timeCodec.exe

Either look at "dfps" (more is better) or at "real" time (lower is better). And you should use the "Null" renderer, because we wan't to benchmark the decoder, not the renderer.

(For timeCodec.exe to work, Haali Media Splitter is needed)

[schweinsz]

Need test on old cpu without sse2, such as pentium 3, athlon 32.
Download the package (http://di-avc.com/mmxtest.7z) and unpack it, run the now1.bat, if it finishes finely, it is correct.

I coded 46 functions with mmx, so take so long times, now it is finished. I tested on my cpu and it is correct. But I can't sure that it is correct on real old cpu.

[sneaker_ger]

"Init decoder failed" on all samples on an Athlon XP.

[clsid]

I get "Init decoder failed" on all four samples.

[LigH]

I could provide a Duron, but not before weekend...

[AnonCrow]

Ditto, init decoder failed, on Intel P-III (Coppermine).

[juGGaKNot]

I have a sempron to test ...

[Firebird]

Unit decoder failed on Athlon XP.

[schweinsz]

Ok, I made a mistake. Try the new one (http://di-avc.com/mmxtest2.7z) now.

[sneaker_ger]

Crashes on Athlon XP, producing 0 byte files on the first three samples. "Tempete" produces a 888 byte file.

[horvathd]

Running without any problem on Intel Celeron M (Banias), but it supports sse2.


d:\Letöltések\mmxtest>win32.exe mobilecalendar_720x576.264 mobilecalendar_720x576.yuv
99 frames decoded totally.
4827292 counters used by decoder and 8436200 counters used by others.

Decoding speed: 73 fps

d:\Letöltések\mmxtest>win32.exe husky_704x576.264 husky_704x576.yuv
99 frames decoded totally.
5592124 counters used by decoder and 10880964 counters used by others.

Decoding speed: 63 fps

d:\Letöltések\mmxtest>win32.exe foreman_cif_24.264 foreman_cif_24.yuv
175 frames decoded totally.
2685747 counters used by decoder and 1648374 counters used by others.

Decoding speed: 233 fps

d:\Letöltések\mmxtest>win32.exe tempete_cif_24.264 tempete_cif_24.yuv
175 frames decoded totally.
5605009 counters used by decoder and 1451401 counters used by others.

Decoding speed: 111 fps

d:\Letöltések\mmxtest>pause
A folytatáshoz nyomjon meg egy billentyűt . . .

[Selur]

Just wondering: Any news on 64bit support?

Cu Selur

[littleD]

Crashes on Athlon XP, producing 0 byte files on the first three samples. "Tempete" produces a 888 byte file.

Same on sempron

[AnonCrow]

On P-III , a 0 byte file produced by all; mobilecalendar and foreman without crashing, but zero output.
husky and tempete crash (command at address 0x55575653 tried to access memory at address 0x55575653 - couldn't be read)

[clsid]

On P-III , a 0 byte file produced by all; mobilecalendar and foreman without crashing, but zero output.
husky and tempete crash (command at address 0x55575653 tried to access memory at address 0x55575653 - couldn't be read)Same here on AMD Athlon Thunderbird, same addresses as well. Just tempete_cif_24.yuv has 888 byte size.

[schweinsz]

Just wondering: Any news on 64bit support?
Cu Selur
It is in plan, but after the end of the month I will start to work on it.

[schweinsz]

Fix another error, try this new one (www.di-avc.com/mmxtest3.7z) now.

[sneaker_ger]

Working fine on Athlon XP.

[AnonCrow]

Works on the P-III (850 MHz) as well.

win32.exe mobilecalendar_720x576.264 mobilecalendar_720x576.yuv
99 frames decoded totally.
10309900 counters used by decoder and 26493441 counters used by others.

Decoding speed: 34 fps


win32.exe husky_704x576.264 husky_704x576.yuv
99 frames decoded totally.
11193810 counters used by decoder and 17650245 counters used by others.

Decoding speed: 31 fps


win32.exe foreman_cif_24.264 foreman_cif_24.yuv
175 frames decoded totally.
5722239 counters used by decoder and 7101862 counters used by others.

Decoding speed: 109 fps


win32.exe tempete_cif_24.264 tempete_cif_24.yuv
175 frames decoded totally.
10072194 counters used by decoder and 2839728 counters used by others.

Decoding speed: 62 fps

[schweinsz]

Works on the P-III (850 MHz) as well.

win32.exe mobilecalendar_720x576.264 mobilecalendar_720x576.yuv
99 frames decoded totally.
10309900 counters used by decoder and 26493441 counters used by others.

Decoding speed: 34 fps


win32.exe husky_704x576.264 husky_704x576.yuv
99 frames decoded totally.
11193810 counters used by decoder and 17650245 counters used by others.

Decoding speed: 31 fps


win32.exe foreman_cif_24.264 foreman_cif_24.yuv
175 frames decoded totally.
5722239 counters used by decoder and 7101862 counters used by others.

Decoding speed: 109 fps


win32.exe tempete_cif_24.264 tempete_cif_24.yuv
175 frames decoded totally.
10072194 counters used by decoder and 2839728 counters used by others.

Decoding speed: 62 fps


Greatly! I managed to finish the mmx version.

[travolter]

@schweinsz

Do you have plans to create a Di(VC-1) decoder?

support for wmv(VC-1).

The porn industry has implemented this codec as default to release HD videos.. and these VC-1 videos need lot of cpu to move in comparison to videos with AVC codec

Probably people will think that Im crazy... that porn videos in bluray are encodec into AVC.. and yes .. they are right but think that there are two porn industries:

.- the one that release porn in bluray (AVC format)
.- the one that release videos in websites using VC-1 format

People consume more VC-1 than AVC bluray (cause its more private download a video instantly from a site to your HD than buy a bluray and wait it to arrive... maybe your wife is on the door to take the package ;) so.. thats the cause VC-1 is becoming so popular in HD videos

[clsid]

Does it use pure MMX or also MMXext?

[schweinsz]

Does it use pure MMX or also MMXext?
It should be MMXExt, I have no plan to support very old cpu. I modify the original SSE2 assembly code to MMX code, the instructions used are same for most cases.

[schweinsz]

@schweinsz

Do you have plans to create a Di(VC-1) decoder?

support for wmv(VC-1).

The porn industry has implemented this codec as default to release HD videos.. and these VC-1 videos need lot of cpu to move in comparison to videos with AVC codec

Probably people will think that Im crazy... that porn videos in bluray are encodec into AVC.. and yes .. they are right but think that there are two porn industries:

.- the one that release porn in bluray (AVC format)
.- the one that release videos in websites using VC-1 format

People consume more VC-1 than AVC bluray (cause its more private download a video instantly from a site to your HD than buy a bluray and wait it to arrive... maybe your wife is on the door to take the package ;) so.. thats the cause VC-1 is becoming so popular in HD videos
After I finished all works about DiAVC including 64-bit, all post-processing, etc, I perhaps consider of it.

[elguaxo]

Greatly! I managed to finish the mmx version.

Does the trial version already have the MMX code?

[schweinsz]

Does the trial version already have the MMX code?
Yes, the trial version has no SSE2 code but MMX code.

EDIT: I believe I mis-understand you. The downloadable trial version at this (http://www.di-avc.com/diavc_14day_trialversion.zip) is outdated and only includes SSE2 version. The win32.exe in mmxtest3.7z is built using trial version configuration that includes MMX code.

[sneaker_ger]

Where to get the trial? The link " http://www.di-avc.com/diavc_14day_trialversion.zip " does not work.

[schweinsz]

Where to get the trial? The link " http://www.di-avc.com/diavc_14day_trialversion.zip " does not work.
It is outdated. What I mean by trial is the win32.exe in mmxtest3.7z. If you need a trial version, send me a e-mail at sales@di-avc.com, I can give you one tomorrow.

[dwrbudr]

AMD Ahtlon XP Thoroughbred 1700+


D:\DVD2\mmxtest>win32.exe mobilecalendar_720x576.264 mobilecalendar_720x576.yuv
99 frames decoded totally.
3896871 counters used by decoder and 7631584 counters used by others.

Decoding speed: 90 fps

D:\DVD2\mmxtest>win32.exe husky_704x576.264 husky_704x576.yuv
99 frames decoded totally.
3902181 counters used by decoder and 22869307 counters used by others.

Decoding speed: 90 fps

D:\DVD2\mmxtest>win32.exe foreman_cif_24.264 foreman_cif_24.yuv
175 frames decoded totally.
2141193 counters used by decoder and 8831732 counters used by others.

Decoding speed: 292 fps

D:\DVD2\mmxtest>win32.exe tempete_cif_24.264 tempete_cif_24.yuv
175 frames decoded totally.
4140727 counters used by decoder and 4473014 counters used by others.

Decoding speed: 151 fps


AMD Barton 2500+

E:\mmxtest>win32.exe mobilecalendar_720x576.264 mobilecalendar_720x576.yuv
99 frames decoded totally.
4297466 counters used by decoder and 2293462 counters used by others.

Decoding speed: 82 fps

E:\mmxtest>win32.exe husky_704x576.264 husky_704x576.yuv
99 frames decoded totally.
4538562 counters used by decoder and 3597021 counters used by others.

Decoding speed: 78 fps

E:\mmxtest>win32.exe foreman_cif_24.264 foreman_cif_24.yuv
175 frames decoded totally.
2494702 counters used by decoder and 962194 counters used by others.

Decoding speed: 251 fps

E:\mmxtest>win32.exe tempete_cif_24.264 tempete_cif_24.yuv
175 frames decoded totally.
4425833 counters used by decoder and 834466 counters used by others.

Decoding speed: 141 fps


Very strange stuff, the faster Barton decodes the files slower...

[Episodio1]

Clock speed doesnt tell you which CPU is faster, but how fast executes the necessary steps to achieve an operation result. It depends on the inner architecture.

If a 1Ghz CPU executes an operation in 3 steps and a 2Ghz CPU executes same operation in 6 steps, both CPU execute at same speed. :)


edit: Anyways, I've seen barton 2500+ doesnt mean 2500 Mhz, but 1833 MHz. "2500+" symbol was used by AMD to 'cheat' users who thought "more Mhz >> more performance". AMD used "2500+" symbology to tell you that your CPU was equal to an Intel 2500 Mhz in that time.

[schweinsz]

Very strange stuff, the faster Barton decodes the files slower...
As the win32.exe includes the module that output the YUV sequences, the time it get is super unreliable. If you want to get a reliable speed, delete the .yuv in the now1.bat and run it.

[moozooh]

Clock speed doesnt tell you which CPU is faster, but how fast executes the necessary steps to achieve an operation result. It depends on the inner architecture.

If a 1Ghz CPU executes an operation in 3 steps and a 2Ghz CPU executes same operation in 6 steps, both CPU execute at same speed. :)


edit: Anyways, I've seen barton 2500+ doesnt mean 2500 Mhz, but 1833 MHz. "2500+" symbol was used by AMD to 'cheat' users who thought "more Mhz >> more performance". AMD used "2500+" symbology to tell you that your CPU was equal to an Intel 2500 Mhz in that time.
Barton is merely the next iteration of the same architecture as Thoroughbred (upped L2 cache size and bus speed), and if I remember correctly the 2500+ model does have a higher clock rate compared to 1700+ (a rating of 1700+ can't have over 1700 MHz on the chip going by logic alone) regardless, so it should have decoded faster anyway, all things considered.

[littleD]

Sempron 2600+ (1.8Gh):
1 about 100 fps
2 about 100 fps
3 varies from 250 to 350
4 varies from 160 to 190

Without .yuv in .bat file fps increase 10 fps average

[onomatopellan]

AMD Athlon XP 2800+

K:\mmxtest>win32.exe mobilecalendar_720x576.264 mobilecalendar_720x576.yuv

99 frames decoded totally.
3378366 counters used by decoder and 2313778 counters used by others.

Decoding speed: 104 fps

K:\mmxtest>win32.exe husky_704x576.264 husky_704x576.yuv
99 frames decoded totally.
3409566 counters used by decoder and 1880182 counters used by others.

Decoding speed: 103 fps

K:\mmxtest>win32.exe foreman_cif_24.264 foreman_cif_24.yuv

175 frames decoded totally.
1668308 counters used by decoder and 824815 counters used by others.

Decoding speed: 375 fps

K:\mmxtest>win32.exe tempete_cif_24.264 tempete_cif_24.yuv
175 frames decoded totally.
3710107 counters used by decoder and 970284 counters used by others.

Decoding speed: 168 fps

K:\mmxtest>pause

[LigH]

mmxtest3 works well on:

AMD Duron A2 "Spitfire", 800 MHz (8 x 100) - supports: x86, MMX, 3Dnow!

J:\TEMP\mmxtest>win32.exe mobilecalendar_720x576.264 mobilecalendar_720x576.yuv
99 frames decoded totally.
2835602 counters used by decoder and 1298800 counters used by others.

Decoding speed: 41 fps

J:\TEMP\mmxtest>win32.exe husky_704x576.264 husky_704x576.yuv
99 frames decoded totally.
2887829 counters used by decoder and 1309122 counters used by others.

Decoding speed: 40 fps

J:\TEMP\mmxtest>win32.exe foreman_cif_24.264 foreman_cif_24.yuv
175 frames decoded totally.
1577716 counters used by decoder and 532812 counters used by others.

Decoding speed: 132 fps

J:\TEMP\mmxtest>win32.exe tempete_cif_24.264 tempete_cif_24.yuv
175 frames decoded totally.
2874848 counters used by decoder and 527142 counters used by others.

Decoding speed: 72 fps

[turbojet]

+1 user/buyer for an optimized VC-1 decoder if you plan on developing one. Besides online porn according to blu-raystats.com 30% of Region A blu-rays are VC-1. Warner uses VC-1 pretty much exclusively and a majority of Universal is VC-1.

Windows decoder is the fastest of the software decoders but there's a lot of room for improvement considering DGNV decoding is about twice as fast. Linux/Mac users are left with libavcodec which can't decode some interlaced VC-1.

[buzzqw]

+1 user/buyer for an optimized vc-1 decoder if you plan on developing one. Besides online porn according to blu-raystats.com 30% of region a blu-rays are vc-1. Warner uses vc-1 pretty much exclusively and a majority of universal is vc-1

+2 :)

bhh

[Virtual_ManPL]

Underclocked AMD Athlon XP 1800+ (1.533MHz=> 1.150MHz)

http://img99.imageshack.us/img99/6840/cpuzwg.png (http://img99.imageshack.us/i/cpuzwg.png/)

C:\Documents and Settings\Administrator\Pulpit\mmxtest3\mmxtest>win32.exe mobil
ecalendar_720x576.264 mobilecalendar_720x576.yuv
99 frames decoded totally.
8122127 counters used by decoder and 47747871 counters used by others.

Decoding speed: 43 fps

C:\Documents and Settings\Administrator\Pulpit\mmxtest3\mmxtest>win32.exe husky
_704x576.264 husky_704x576.yuv
99 frames decoded totally.
8761155 counters used by decoder and 34003240 counters used by others.

Decoding speed: 40 fps

C:\Documents and Settings\Administrator\Pulpit\mmxtest3\mmxtest>win32.exe forem
an_cif_24.264 foreman_cif_24.yuv
175 frames decoded totally.
6106618 counters used by decoder and 2613568 counters used by others.

Decoding speed: 102 fps

C:\Documents and Settings\Administrator\Pulpit\mmxtest3\mmxtest>win32.exe tempe
te_cif_24.264 tempete_cif_24.yuv
175 frames decoded totally.
7932323 counters used by decoder and 35972491 counters used by others.

Decoding speed: 78 fps

C:\Documents and Settings\Administrator\Pulpit\mmxtest3\mmxtest>pause

[hajj_3]

schweinsz: any news on a new version? What features/bugs will be in it and any eta?

[BetaBoy]

I recently reported a problem with video corruption using coreavc and attached two samples in this post: http://forum.doom9.org/showpost.php?p=1348040&postcount=5265
I decided I should check your decoder too, as it clearly shows some promise.


We have fixed resolution changing in our internal version and it is to be included when we release v2.1.

[Stephen R. Savage]

Since it has been several months since the initial release of v1.0, I would like to point out some things that are still lacking, just in case schweinsz has forgotten any:

1) Support for decoding of lossless streams
2) Implementation of linear or cubic chroma upsampling
3) Support for 10-bit or higher precision, as well as 4:2:2 and 4:4:4 colorspaces (I believe x264 may be implementing these features this summer, and I hope to be able to use them when they are released)
4) Automatic request form for new machine ID/password -_-

Edit @schweinsz: In case I need a new password, should I contact sales@diavc.com or some other address?

[madshi]

2) Implementation of linear or cubic chroma upsampling
IMHO the decoder should be limited to only ever output 4:2:0, to avoid any compromises in image quality. Chroma upsampling should better be left to the video renderer. There are better methods available than cubic chroma upsampling, which a decoder will probably never implement. Just my personal opinion, of course...

[Stephen R. Savage]

IMHO the decoder should be limited to only ever output 4:2:0, to avoid any compromises in image quality. Chroma upsampling should better be left to the video renderer. There are better methods available than cubic chroma upsampling, which a decoder will probably never implement. Just my personal opinion, of course...

The problem is that future elements in the filter graph will never know about the VUI information, because DirectShow does not understand these concepts. Therefore, correct conversion to RGB can ONLY occur in the decoder.

[madshi]

The problem is that future elements in the filter graph will never know about the VUI information, because DirectShow does not understand these concepts. Therefore, correct conversion to RGB can ONLY occur in the decoder.
I disagree. There are many ways to do correct RGB conversion later. E.g. the decoder could officially inform the renderer about the bitstream information (via an interface exported by the renderer). Or the renderer could hook into the decoder's input pin. Or the renderer could insert a transform filter between splitter and decoder to grab the bitstream. Or maybe the codec private information block already contains the needed information. As I said, there are many possible solutions. Most streams are either Rec709 or Rec601, anyway, so even guessing the right color specification based on the video resolution works just fine most of the time. If you do color space conversion in the decoder, you introduce banding artifacts, because 8bit RGB is not enough - unless you dither the RGB data down to 8bit. And I don't think any DirectShow decoder does that...

If you're anal about correct colors, things become even more complicated: If your display is calibrated to Rec709, but the source format has a different white point, using the correct color conversion matrix alone is not good enough. You also need to do chromacity conversion (using Bradford transform). Do you want to do this in the decoder, too? ;)

[Stephen R. Savage]

If you do color space conversion in the decoder, you introduce banding artifacts, because 8bit RGB is not enough - unless you dither the RGB data down to 8bit.

I don't believe this is correct. Rather, the problem is that the YUV was insufficient to store the original RGB data.

[madshi]

I don't believe this is correct. Rather, the problem is that the YUV was insufficient to store the original RGB data.
<sigh> I've already been going through battles with different people about this. I know for a fact that I am right. Let me explain:

Yes, the number of available colors in YCbCr is smaller than the number of available colors in RGB. But that doesn't matter. Why? Because the YCbCr -> RGB conversion is a multiplication with a floating point number, which means that after YCbCr -> RGB conversion you end up with floating point RGB data. Now if you convert floating point RGB back to 8bit, without using dithering, you have the option to either truncate the floating point data, or you can round it. In either case you're doing damage to the data, you're losing precision. That's a mathematical fact. If you don't use dithering, you get quantization noise, which is visible as banding.

The same principle applies in audio processing: If you change volume of 16bit audio data, you're multiplying the audio data with a floating point number. Once again you end up with floating point data. If you convert that back to 16bit without dithering, once again you get quantization noise, which is measurable and also (with good equipment) audible.

It is a *law* in digital processing that whenever you reduce bitdepth (which includes going from floating point data to integer data), you have to use dithering, or else you'll get quantization noise.

If you don't believe in digital processing laws, you can play yourself with the madVR test patterns. They prove that even with 8bit YCbCr source material, dithering makes a visible difference.

[yesgrey]

I don't believe this is correct. Rather, the problem is that the YUV was insufficient to store the original RGB data.
But it is correct.
What you're saying is also correct, but it's just the first part of the problem.
We cannot do anything with the first part, because it's performed by the Studios, but we can avoid the second, like madshi has done in madVR, and Haruhiko in ffdshow, by using dithering.

[schweinsz]

Since it has been several months since the initial release of v1.0, I would like to point out some things that are still lacking, just in case schweinsz has forgotten any:

1) Support for decoding of lossless streams
3) Support for 10-bit or higher precision, as well as 4:2:2 and 4:4:4 colorspaces (I believe x264 may be implementing these features this summer, and I hope to be able to use them when they are released)
Ok, I will consider of it. But currently I will work on compability problems and then post-processing.

2) Implementation of linear or cubic chroma upsampling
As Madshi explained, this will be left to renderer.


4) Automatic request form for new machine ID/password -_-
Edit @schweinsz: In case I need a new password, should I contact sales@diavc.com or some other address?
Ok, you can contact me at sales@diavc.com.

[SeeMoreDigital]

<sigh> I've already been going through battles with different people about this. I know for a fact that I am right. Let me explain:Very well presented explanation. Nice one :)

[schweinsz]

Where is the contact information of the author of the DVBViewer? I want to contact with him.

[LoRd_MuldeR]

Where is the contact information of the author of the DVBViewer? I want to contact with him.

bhackbart@cmuv.de

[schweinsz]

yes I've seen config page, but preferred is still YV12, right?
RGB24 gives me wrong image colors, but I think I should check some params
Hi Sherpya:
Is there some difference between normal directshow playback and your dsnative? For example, is there some functions that are not called in dsnative while called in normal directshow playback.
I found that different results are gotten for every run of the mencoder with DiAVC, there are many skiped frames.

[schweinsz]

DiAVC 1.1.0 is released.
Change log:
Add MMX version.
Improved seeking speed.
Add error concealment.
Change the storage location of property page from HKEY_LOCAL_MACHINE to HKEY_CURRENT_USER.
Add the setting of threads number .
Add the setting of input colorspace.
Add the option of "drop non-reference frames when hard".
Fixed the bug related to the "Brightness Offset".

Notes that the "drop non-reference frames when hard" only works on old VMR, VMR9, Overlay Mixer, EVR, madVR and haali video renderer.
As to the Brightness Offset, I modified it so that it output the similar output with CoreAVC or DiVX.
As to the Contrast, I found that the CoreAVC is different from the DiVX, the DiAVC is same with DiVX.

I have tried to fix the compatibility problem with the DVBViewer, but it is not finished. I saw that the DiAVC output frames to renderer but nothing appear and after a while the DVBViewer crashes.

Besides, I will release the 64bit version of the DiAVC at the end of the month or the begin of the next month in my plan.

[kieranrk]

Are you going to sort out your webpage like I told you to?

[sneaker_ger]

I can't run the registration. I installed the full version, started registration once, then installed the trial while waiting for my key to arrive. Now that the key has arrived I can't start the registration anymore, it crashes on startup immediately. :confused:

[Episodio1]

kieranrk, I think his current website is enough. It shows some information about product, and how to buy it.

[schweinsz]

I can't run the registration. I installed the full version, started registration once, then installed the trial while waiting for my key to arrive. Now that the key has arrived I can't start the registration anymore, it crashes on startup immediately. :confused:
The DiAVC Registration.exe requires the administrator account, what is your system?
Besides, you can find the correct normal version diavc.ax/diavc_mmx.ax, register it by "regsvr32.exe diavc.ax/diavc_mmx.ax". Then open the graphstudio, insert the DiAVC, query its property page, input the password (require the administrator account).

[sneaker_ger]

The DiAVC Registration.exe requires the administrator account, what is your system?
Besides, you can find the correct normal version diavc.ax/diavc_mmx.ax, register it by "regsvr32.exe diavc.ax/diavc_mmx.ax". Then open the graphstudio, insert the DiAVC, query its property page, input the password (require the administrator account).

The filter crashes on insertion. :confused:
The only filter I can use is the trial, but it doesn't generate any machine code, so I can't enter my key.
I'm on Windows XP (as Administrator).

[schweinsz]

The filter crashes on insertion. :confused:
The only filter I can use is the trial, but it doesn't generate any machine code, so I can't enter my key.
I'm on Windows XP (as Administrator).

Download the file (http://di-avc.com/bin.7z) and unpack it, run the now1.bat and feedback the result to me.
Besides, you can un-register the diavc.ax using the graphstudio, and re-register it using the "regsvr32.exe diavc.ax", or you can delete all registry keys related to the diavc.ax, and re-run the DiAVC Registration.exe to get the machine code. Actually I suspend that you feedback me the wrong machine code or you manually change the keys related to the DiAVC, never do that.

[sneaker_ger]

The now1.bat crashes, the result is a 0 byte file. What I don't get is that the registration started just fine the other day, I played around with it until I got my key per mail. In between I tested the trial and it also worked just fine. After I received the key I un-registered the trial and started the registration again, only to see it crash. I tried re-/unregistering the trial and also de-/installing the full version several times, but I just can't get to get the full version to run anymore (both inserting graph or starting registration result in a crash). The trial version always works.

[schweinsz]

The now1.bat crashes, the result is a 0 byte file. What I don't get is that the registration started just fine the other day, I played around with it until I got my key per mail. In between I tested the trial and it also worked just fine. After I received the key I un-registered the trial and started the registration again, only to see it crash. I tried re-/unregistering the trial and also de-/installing the full version several times, but I just can't get to get the full version to run anymore (both inserting graph or starting registration result in a crash). The trial version always works.

Delete all keys at "CLSID\\{083863F1-70DE-11d0-BD40-00A0C911CE86}\\instance\\{5DFA20A4-C343-45DF-A46E-EC1711E4EE32}". Copy the diavc.ax full version to the same folder with the DiAVC Registration.exe, run the DiAVC Registration.exe, check the machine code if it is same with that you sent me, and input the password.

There should be some results on the cmd screen for the now1.bat.

[sneaker_ger]

okay, I did the following:
1.) Deleted the key you mentioned
2.) made sure that the full version of diavc_mmx.ax, diavc.ax and registration are in the same folder
3.) started "DiAVC Registration.exe". It still crashes immedietly on startup. I don't get to the point to view my machine code or enter my key anymore. (It seems to recreate the keys in the registry, 1. an empty "password" and 2. a non-empty "rgtcode")

What can I do to remove everything, so I can start again from scratch? This "DiAVC Registration.exe" worked the first time I used it yesterday so if I could remove everything it might work again.

I'm on a non-sse2-cpu, if it matters.

[schweinsz]

okay, I did the following:
1.) Deleted the key you mentioned
2.) made sure that the full version of diavc_mmx.ax, diavc.ax and registration are in the same folder
3.) started "DiAVC Registration.exe". It still crashes immedietly on startup. I don't get to the point to view my machine code or enter my key anymore. (It seems to recreate the keys in the registry, 1. an empty "password" and 2. a non-empty "rgtcode")

What can I do to remove everything, so I can start again from scratch? This "DiAVC Registration.exe" worked the first time I used it yesterday so if I could remove everything it might work again.

I'm on a non-sse2-cpu, if it matters.
Unregister the DiAVC.ax using the graphstudio, then register the diavc_mmx.ax using "regsvr32.exe diavc_mmx.ax", start it in graphstudio, does it crash now? If you use non-sse2-cpu, delete the diavc.ax or diavc_sse2.ax, they are sse2 version.

[sneaker_ger]

I manually unregistered diavc and manually registered (regsvr32...) the mmx version, but it still crashes.

[schweinsz]

I manually unregistered diavc and manually registered (regsvr32...) the mmx version, but it still crashes.

I uploaded a new bin.7z (http://di-avc.com/bin.7z), download it and unpack it, run the now1.bat, there will be a trace.txt generated by the now1.bat regardless if it crashes. Report the context in the trace.txt to me, this will help me to fix the problem.

[ExSport]

Hi Sherpya:
Is there some difference between normal directshow playback and your dsnative? For example, is there some functions that are not called in dsnative while called in normal directshow playback.
I found that different results are gotten for every run of the mencoder with DiAVC, there are many skiped frames.
schweinsz: You can check it here: http://oss.netfarm.it/dsnative/
There is a link to source....
I am waiting for fix to this problem before buying a license for me:thanks:

[sherpya]

Hi Sherpya:
Is there some difference between normal directshow playback and your dsnative? For example, is there some functions that are not called in dsnative while called in normal directshow playback.
I found that different results are gotten for every run of the mencoder with DiAVC, there are many skiped frames.

Hi,
unfortunately I had no much time to work to dsnative, also I still miss knowledge about directshow
(for this reason I've decided to use it in a non traditional way :D)
The code is ispired to current mplayer dshow driver but instead of using full emulated dshow, I've
decided to reduce my code by reusing all reusable code from baseclasses.
There are 2 way I use this wrapper, one with a real graphbuilder, the other using a fake graphbuilder
at the moment all calls should be same of a normal directshow graph, but as I said, it's not the canonical way to use directshow.

I make a sender and a receiver, then adapt pins in/out and call connect (I also call joinfiltergraph, ffdshow will crash otherwise)

I think the problem is not in the direct show chain (the pins look ok),
I suspect there is something about sync and/or handling dropped frames that is not correct.
From mplayer/mencoder I have a call for each frame to decode, a pts that I convert to reference time by multipling by 1e7,
stoptime is calculated from startime + frametime (1E7 / fps), if the frame is a keyframe I set SetSyncPoint(1).
SetPreroll is true when the ptr is null (from mplayer view non-keyframe to skip), then I pick back the pts (but this seems ininfluent).

Also I still don't known how and if update the pts of mplayer after the frame is decoded, I think your codec itself does not change
start or stop time while decoding, since a single frame is decoded and the frame duration is already known.

I think the only relevant stuff on your side is in function:
dsnerror_t Decode(const BYTE *src, int size, double pts, double *newpts, BYTE *pImage, int keyframe)
but looks correct to me. I've noticed different codecs are handling in different way frame drop situations
I've also looked at mpc-hc sources but the chain is a bit different

[Fadeout]

Good thing: the program still accepted the same key when I moved from XP to Windows 7. So at least swapping SO doesn't require getting a new code.

Working well now, But media player classic 64bit doesn't accept 32bit codecs, so waiting the end of the month for the new version.

[sneaker_ger]

I uploaded a new bin.7z (http://di-avc.com/bin.7z), download it and unpack it, run the now1.bat, there will be a trace.txt generated by the now1.bat regardless if it crashes. Report the context in the trace.txt to me, this will help me to fix the problem.

nLogicalProcessors 0
good0
good1
intelcpu 0 corenum 0 multithrd 0 decoders 3 inited!
1 decoder inited!
2 decoder inited!
gooda
goodp0
goodp1
goodp2
goodp3
goodp
goodq
Init decoder failed

[sneaker_ger]

The new version you sent over mail works, thank you!

[Episodio1]

Please, next time talk through private messages. :( :(

[hajj_3]

please, next time tell people next time to talk through privates messages through private messages :( :(

[sneaker_ger]

I will continue such discussions in public threads as others might run into the same problems. No need to keep it private.

[schweinsz]

DiAVC 1.1.1 is released.
Change logs:
Fixed the bug in the un-registered DiAVC filter.
Fixed the bug on "drop non-reference frames when hard".

Besides, I disable the "drop non-reference frames when hard" in default. If somebody playback some hard videos, they can enable it.

Edit: I will try to fix the compatibility problem with the mencoder next.

[bob0r]

http://di-avc.com/download.html: (Outdate in May 20, 2010). >> (Expires on May 20, 2010).

http://di-avc.com/home1.html: screenshot: Current Input Level: TV level >> Current Input Level: TV Level

http://di-avc.com/home1.html: screenshot: threads num of decoder >> Threads num of decoder
or change all together: Decoder threads

http://di-avc.com/home1.html: screenshot: Drop non-reference frames when hard >> Drop hard non-reference frames
(Whatever that means)

[ImmortAlex]

Drop non-reference frames when hard
"Drop frame on delay" in ffdshow settings.
Native speakers, where are you? :)

[schweinsz]

http://di-avc.com/home1.html: screenshot: Drop non-reference frames when hard >> Drop hard non-reference frames
(Whatever that means)

The "Drop non-reference frames when hard" means that the DiAVC will drop non-reference frames when the current bitstream is too complex to playback realtime.
Thank you for your help. My english is so poor.

[schweinsz]

I uploaded a new version of the DiAVC SDK (http://di-avc.com/diavc_sdk_v1.1.2.zip) to the site.

[CruNcher]

@schweinsz

The null rendering performance is very good Athlon X2 Toledo
CoreAVC 2.0 = 88 FPS
DiAVC = 82 FPS (sse2)
DivX = 76 FPS
DiAVC = 73 FPS (mmx)
FFdshow (ffmpeg-mt) = 67 FPS
ArcSoft = 54 FPS
Elecard = 48 FPS

but your Decoder fails with VMR7 compared to others it seems to lose multithreading entirely when rendering with VMR7, that's a pretty major bug and you didn't get to the full ASM optimization state that Picard currently reached on that platform yet (not far away though), but anyways impressive in the timeframe you work on it :).

[KERNEL32]

DiAVC Associate with DGAVCindex ? , I can not use DGAVCDecNV :( :( :(

I have a nvidia 8800GTS card and the first generation so I is not cuda version , search solution

[Guest]

I have a nvidia 8800GTS card and the first generation so I is not cuda version , search solution Sell yours on ebay and buy a low-end card NVCUVID-capable card for about $50.

Follow up elsewhere as it is off topic for this thread.

[schweinsz]

Is there a timecodec x64? I need a tool to benchmark the speed for x64.

[Stephen R. Savage]

Timecodec only exists for x86, but you can use GraphStudio to measure performance ("Measure decoder performance"), as it uses the same method (connect to renderer and dump frames).

[Fadeout]

Latest news on the 64bit version?

[schweinsz]

Latest news on the 64bit version?
Only the CABAC x64 module is not finished.

[ExSport]

Any news about MEncoder support?
I am still waiting:rolleyes:
Many thanks!

[schweinsz]

Any news about MEncoder support?
I am still waiting:rolleyes:
Many thanks!
I will try to fix it after I finish the x64 version, it is hard to fix it for me.

[madshi]

Do you plan to add support for 3D Blu-Ray (h264 MVC) decoding?

[schweinsz]

Do you plan to add support for 3D Blu-Ray (h264 MVC) decoding?
I believe it is not complex to add the code to support MVC, but my problem is I have not a 3D display to test it.

[madshi]

I believe it is not complex to add the code to support MVC, but my problem is I have not a 3D display to test it.
Well, you can watch the left eye and right eye streams separately on your 2D display. If both look fine and both are different, then probably you did things correctly... :) If you want a 3D sample, you can PM me.

[hajj_3]

3d is hardly a priority, only a few titles out and i don't think any commercially available tv's or monitors yet, no point adding support for atleast 6 months.

[kieranrk]

3d is hardly a priority, only a few titles out and i don't think any commercially available tv's or monitors yet, no point adding support for atleast 6 months.

There are many TVs and monitors available.

[LoRd_MuldeR]

3d is hardly a priority, only a few titles out and i don't think any commercially available tv's or monitors yet, no point adding support for atleast 6 months.

There currently is a huge 3D hype going on. It certainly would make sense to jump on that train.

Offering one of the first "3D capable" H.264 decoders would be a good argument for people to buy DiAVC, don't you think?

[madshi]

Offering one of the first "3D capable" H.264 decoders would be a good argument for people to buy DiAVC, don't you think?
Exactly my thoughts. *However*, a decoder alone is not enough. We'd also need a splitter and a renderer. And I'm not sure if NVidia/ATI are willing to share the information needed to do 3D playback. So it's not sure yet if (and how fast) a full 3D chain would be doable for HTPCs...

[LoRd_MuldeR]

Exactly my thoughts. *However*, a decoder alone is not enough. We'd also need a splitter and a renderer. And I'm not sure if NVidia/ATI are willing to share the information needed to do 3D playback. So it's not sure yet if (and how fast) a full 3D chain would be doable for HTPCs...

AFAIK there already are "official" standards how 3D data needs to be packaged to "Megaframes" when transferred over a HDMI connection.

All the rest (e.g. shutter -vs- polarization filter) should be up to the screen/projector, right?

[madshi]

AFAIK there already are "official" standards how 3D data needs to be packaged to "Megaframes" when transferred over a HDMI connection.
Yeah, there are several formats defined, like side-by-side, checkerboard, top-to-bottom etc etc. I guess the renderer could just manually draw the images this way. That would probably work just fine with a display which can manually be switched to a specific 3D format. With HDMI 1.4 it would be easier, there the source device can signal to the display which 3D method the data is formatted in. Don't know if current ATI/NVidia cards can signal that. If they can, there is no API for that available yet.

[kieranrk]

Yeah, there are several formats defined, like side-by-side, checkerboard, top-to-bottom etc etc. I guess the renderer could just manually draw the images this way. That would probably work just fine with a display which can manually be switched to a specific 3D format. With HDMI 1.4 it would be easier, there the source device can signal to the display which 3D method the data is formatted in. Don't know if current ATI/NVidia cards can signal that. If they can, there is no API for that available yet.

Stereoscopic player supports Nvidia's 3d mode. There are probably others which support ATI's mode. The API calls could easily be reverse engineered.

[madshi]

Stereoscopic player supports Nvidia's 3d mode.
I think NVidia's 3d mode works only with NVidia's own shutter glasses, but does not properly output stereo signals via HDMI 1.3/1.4, or does it?

[kieranrk]

I think NVidia's 3d mode works only with NVidia's own shutter glasses, but does not properly output stereo signals via HDMI 1.3/1.4, or does it?

I'm not sure about HDMI output. I was referring to Nvidia's own 3d glasses mode.

[ranpha]

I think NVidia's 3d mode works only with NVidia's own shutter glasses, but does not properly output stereo signals via HDMI 1.3/1.4, or does it?

Stereo signals needed for 3D Blu-rays can also be sent properly via dual-link DVI cables. Obviously, there will be no audio. Those 3D 120Hz monitors without HDMI 1.4 are not obselete yet.

[vsv]

I believe it is not complex to add the code to support MVC, but my problem is I have not a 3D display to test it.

Side-by-side cross-eyes on any display :)

[Stephen R. Savage]

@schweinsz: I have found a video that crashes DiAVC: http://tracker.tasvideos.org/pokemonyellow-tas-gia.avi.torrent (legal, video game capture).

At 1:27, DiAVC (20100512) causes a crash in MPC-HC (r2051, xvidvideo.ru). CoreAVC does not crash. The crash still occurs after bitstream has been remuxed to MKV.

Edit: I have uploaded the original file to http://www.multiupload.com/GL8RCCCLKP

[schweinsz]

@schweinsz: I have found a video that crashes DiAVC: http://tracker.tasvideos.org/pokemonyellow-tas-gia.avi.torrent (legal, video game capture).

At 1:27, DiAVC (20100512) causes a crash in MPC-HC (r2051, xvidvideo.ru). CoreAVC does not crash. The crash still occurs after bitstream has been remuxed to MKV.

Edit: I have uploaded the original file to http://www.multiupload.com/GL8RCCCLKP

Ok, I will fix the problem in the next release.
I am watching the World Cup 2010 at home so the next release of the DiAVC is delayed for many days. I will finish it in recent days.

[Stephen R. Savage]

x264 has just added support for 9-bit and 10-bit video encoding (High10). Perhaps DiAVC could be the first consumer decoder to support it? Maybe in v2.0? :devil:

[LigH]

Uuhm ... I doubt that. Because DiAVC is a decoder only. ;)

[Stephen R. Savage]

Oh, oops. Typo. The guys at CoreCodec are supposedly working on this too, so perhaps we'll see support for this in a few years. :devil:

[schweinsz]

Oh, oops. Typo. The guys at CoreCodec are supposedly working on this too, so perhaps we'll see support for this in a few years. :devil:
After I finish the x64 version, I will concentrate on post-processing, 422, 444, and 9-bit, 10-bit.

[kieranrk]

After I finish the x64 version, I will concentrate on post-processing, 422, 444, and 9-bit, 10-bit.

Please put sorting out your website before all of these things...I would speculate you'd could have at least doubled your sales with a few hours work.

[madshi]

After I finish the x64 version, I will concentrate on post-processing, 422, 444, and 9-bit, 10-bit.
And 3D (MVC) ? :)

FWIW, here are the FOURCC you'll need for 10-bit output:

http://msdn.microsoft.com/en-us/library/bb970578%28VS.85%29.aspx#fourcc_codes

[Guest]

@schweinsz

Sorry for posting here, but I try to reach you by PM without success. Shall I assume you are intentionally not replying and are uninterested in my proposals? I need to reply to NetFlix. Thank you.

[schweinsz]

@schweinsz

Sorry for posting here, but I try to reach you by PM without success. Shall I assume you are intentionally not replying and are uninterested in my proposals? I need to reply to NetFlix. Thank you.
I am sorry that I engaged in watching the world cup 2010 at home and take little care of the info. in doom9. I will provide the new trial version recently. I am glad to provide the support to NetFlix.

[Guest]

Thanks. I hope to hear from you further by PM. There are $$$ to be made. But one must strike while the iron is hot.

[schweinsz]

And 3D (MVC) ? :)

FWIW, here are the FOURCC you'll need for 10-bit output:

http://msdn.microsoft.com/en-us/library/bb970578%28VS.85%29.aspx#fourcc_codes

The biggest problem I face for 3D (MVC) is that I have not a 3D display so that I can't test the result.
Supporting the 3D in code is simply, only some interpolating algorithms of pictures are enough.

[schweinsz]

Thanks. I hope to hear from you further by PM. There are $$$ to be made. But one must strike while the iron is hot.
You are very right. I am lazy. I must be more active.

[madshi]

The biggest problem I face for 3D (MVC) is that I have not a 3D display so that I can't test the result.
That's not a problem at all. Just switch the video renderer to "side by side" mode and then you can check if your decoder's output is correct without needing a 3D display. You will then see something like this on your media player:

http://www.wikinoticia.com/images/hiperdef/hiperdef.com.files.2010.03.3d_SidebySide.jpg

The problem right now is that splitters and renderers don't support 3D playback yet. But that's something that can easily be worked on, if there's hope for a 3D decoder.

[Guest]

You are very right. I am lazy. I must be more active. LOL. Given that response and that you still do not respond to my PMs, even after you obviously now know about them, I have to conclude you are uninterested. I have informed NetFlix that their proposal (which we could have satisfied by combining DGDec and DiAVC) is not possible. Ciao.

[schweinsz]

LOL. Given that response and that you still do not respond to my PMs, even after you obviously now know about them, I have to conclude you are uninterested. I have informed NetFlix that their proposal (which we could have satisfied by combining DGDec and DiAVC) is not possible. Ciao.
I am coding just then and I want to reply to you after I finished the trial version. I believe that there is some misunderstanding between us. I notice your this post when I meet some trouble and search for a solution on internet.
EDIT1:I have finished to build it but I find that it depends on the msvcrt100.dll, I must get rid of it.

[jethro]

. I believe that there is some misunderstanding between us.
Yes, and it is probably 'culture gap'. You see, Americans want their business partners to be "professional", as they say. When you say you are lazy, that is very bad in their eyes. I understood your 'lazy' as 'not diligent enough'. Americans are lazy too, they just don't say it:)
NetFlix is a video company in USA. American companies pay (usually) BIG money. If it is still possible to do anything for them, I suggest you stop doing any other things, and focus on working for this NetFlix company, as money can easily be 10x more than from selling H.264 decoder.

[hajj_3]

I wonder what Netflix wants with DiAVC and DGNVdec! I hope someone rich buys DiAVC and makes it open source, would be great to see it included in MPC-HC and VLC etc

[schweinsz]

A new trial version is available on di-avc.com. The new trial version will expire at the end of the month.

[Guest]

I now have the decoder working in a little test bed for DGAVCIndex, thanks to the kind assistance of schweinsz. I don't currently see any looming obstacles to complete a full implementation of DGAVCDec based on DiAVC. PAFF streams are working just fine. I expect to release the DG part free for noncommercial use but you'll need to purchase a license for DiAVC (currently only $9.99).

If you are wondering whether DGNV-only functionality (MKV, TS trim, autocrop, MPLS support, multiple files, etc.) will be added, the answer is that I am considering having a free and a "pro" version, similar to Muxman.

[Stephen R. Savage]

After I finish the x64 version, I will concentrate on post-processing, 422, 444, and 9-bit, 10-bit.

According to information I have heard from the developer of x264, additional bit depths require the entire assembly code to be redesigned, separately for each bit depth. Is this true, and do you think it will be a problem for DiAVC (I believe the spec allows up to 16-bit)?

[lych_necross]

Does DiAVC support those 4K youtube videos?

[Underground78]

I now have the decoder working in a little test bed for DGAVCIndex, thanks to the kind assistance of schweinsz. I don't currently see any looming obstacles to complete a full implementation of DGAVCDec based on DiAVC. PAFF streams are working just fine. I expect to release the DG part free for noncommercial use but you'll need to purchase a license for DiAVC (currently only $9.99).

If you are wondering whether DGNV-only functionality (TS trim, autocrop, MPLS support, multiple files, etc.) will be added, the answer is that I am considering having a free and a "pro" version, similar to Muxman.

Great ! :)

[schweinsz]

According to information I have heard from the developer of x264, additional bit depths require the entire assembly code to be redesigned, separately for each bit depth. Is this true, and do you think it will be a problem for DiAVC (I believe the spec allows up to 16-bit)?

Yes, it means very heavy work load. It is not hard but very time-consuming and boring.

[schweinsz]

Does DiAVC support those 4K youtube videos?
I believe the DiAVC could do it. Where is some download of the 4K video? I can test it now.

[Underground78]

I believe the DiAVC could do it. Where is some download of the 4K video? I can test it now.

You can find a sample here (http://forum.doom9.org/showthread.php?p=1417233#post1417233).

[schweinsz]

You can find a sample here (http://forum.doom9.org/showthread.php?p=1417233#post1417233).

I can't connect to the mediafire or youtube, could you move it to the megaupload.com?

[Guest]

I have put it here for you:

http://neuron2.net/misc/Life_in_the_Garden_4k_resolution.mp4

[lych_necross]

I've tested the sample neuron2 linked to with the latest trial version and it seems to play just fine (a little slow on my system, but it did not crash).

[LoRd_MuldeR]

I installed the the DiAVC trial version (expires on July 31, 2010), but all I get in DVBViewer is that:
http://i27.tinypic.com/30lp7pf.jpg

Is it a known problem that DiAVC doesn't work with DVB-S2 broadcast?

(Just for the notes: Both, CoreAVC 1.9.5 and DivX H.264 Decoder 1.2.1, work perfectly fine in that scenario for me)

[schweinsz]

I installed the the DiAVC trial version (expires on July 31, 2010), but all I get in DVBViewer is that:
http://i27.tinypic.com/30lp7pf.jpg

Is it a known problem that DiAVC doesn't work with DVB-S2 broadcast?

(Just for the notes: Both, CoreAVC 1.9.5 and DivX H.264 Decoder 1.2.1, work perfectly fine in that scenario for me)
I ever tried to fix the compability problem with the DVBViewer but I can't, I observed that the DiAVC sent decoded frames to the the renderer but nothing appeared and after a while it crashed.
I am working on the x64 version now.

[ExSport]

Is there some change in MEnocoder compatibility?
I can't test new version now...
Many :thanks:

[iwod]

I am getting flickering issues, my files is 1.4GB larger... anyway i could send in for testing.

[schweinsz]

Recently I will release a bug-fixed version. I fixed some bugs recently.

[sneaker_ger]

I'm having problems running DiAVC on my new system. It either shows a black screen or a still of one of the first frames (not necessarily the first frame). I'm using MPC-HC 2121, DiAVC 1.1.1 and tried different renderers. Any ideas?

Core i7-860
Windows 7 Pro x64

P.S.: Please look up the word "recently" in a dictionary.

[schweinsz]

I'm having problems running DiAVC on my new system. It either shows a black screen or a still of one of the first frames (not necessarily the first frame). I'm using MPC-HC 2121, DiAVC 1.1.1 and tried different renderers. Any ideas?

Core i7-860
Windows 7 Pro x64

P.S.: Please look up the word "recently" in a dictionary.
When you change to a new version, e-mail to me the new machine code then I will send you the new password.

[Guest]

@schweinz

Just to help with the word quibble...

"Recently" refers to the past, so saying you will do something recently is incoherent. You want the word "Soon".

Soon I will deliver...

Thanks for your work on DiAVC. It is a project with really great potential.

[sneaker_ger]

I already received the new code from you and registered it. The codes do not show up in the actual filter dialog, though. Is that a problem?
http://www.abload.de/img/diav_registration_dial7wzf.png
http://www.abload.de/img/diav_settings_dialogj7rt.jpg

[schweinsz]

I already received the new code from you and registered it. The codes do not show up in the actual filter dialog, though. Is that a problem?
This must be a problem but I don't know the reason. Could you check your registry key "CLSID\\{083863F1-70DE-11d0-BD40-00A0C911CE86}\\instance\\{5DFA20A4-C343-45DF-A46E-EC1711E4EE32}\\rgtcode" and "CLSID\\{083863F1-70DE-11d0-BD40-00A0C911CE86}\\instance\\{5DFA20A4-C343-45DF-A46E-EC1711E4EE32}\\password"?
Besides, you can try the new trial version.

[sneaker_ger]

The trial version crashes the player immediately.

These are my reg keys:
[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{083863F1-70DE-11D0-BD40-00A0C911CE86}\Instance\{5DFA20A4-C343-45DF-A46E-EC1711E4EE32}\rgtcode]
@=hex:3f,74,46,56,ea,58,50,34,a5,6a,28,aa,b4,62,88,62,6a,b9,d5,6d

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{083863F1-70DE-11D0-BD40-00A0C911CE86}\Instance\{5DFA20A4-C343-45DF-A46E-EC1711E4EE32}\password]
@=hex:c9,14,5a,98,6f,d6,6d,6d,ae,78,72,1c,b0,82,b3,96

[Stephen R. Savage]

sneaker_ger, MPC-HC is run in reduced privileges mode, so it can not gain write access to the registry keys that store the machine code and password. You can read about this a few pages back when I described my difficulties with the DRM. The display field in the filter properties is independent of the code that validates the activation, so you should not have any problems using DiAVC.

Edit: Actually, this may not apply to Windows XP (developer response needed). However, since there is no built-in trial mechanism, I would assume that if it works, it works.

[LigH]

Once I installed DiAVC, I cannot make it not the preferred H.264 decoder while playing a video in MPC-HC (uncheck, apply, OK; call again: checked again); may that be a similar reason? Would I have to uncheck the checkbox outside of MPC-HC? (Windows XP SP3) -- I really would not like to uninstall it just for testing and comparing with other decoders.

[yesgrey]

Once I installed DiAVC, I cannot make it not the preferred H.264 decoder while playing a video in MPC-HC (uncheck, apply, OK; call again: checked again); may that be a similar reason?
In the external filters tab check it and set is as "blocked", and set as "preferred" the other filter you want to use.

[LigH]

That's a workaround based on MPC-HC; but there might be a bug in DiAVC (except there is a proof that MPC-HC is the reason).

I believe there is a way to call the DiAVC configuration dialog via RunDLL32?
__

Same reaction in GSpot 2.70a (System - List Codecs and Other Filters - DSH | AVC1 | DiAVC; rightclick: Property Sheet) and Monogram GraphStudio (Graph - Insert Filter - DiAVC; Property page):

- open Properties
- uncheck the checkbox "Preferred H.264 Decoder"
- (Apply or not)
- OK
- open Properties: Checkbox is checked again

- Change Merit with the used tool to e.g. MERIT_NORMAL
- open Properties: Checkbox is not checked anymore

So I suppose that just the DiAVC Properties are unable to really set the Merit back lower.

[sneaker_ger]

sneaker_ger, MPC-HC is run in reduced privileges mode, so it can not gain write access to the registry keys that store the machine code and password. You can read about this a few pages back when I described my difficulties with the DRM. The display field in the filter properties is independent of the code that validates the activation, so you should not have any problems using DiAVC.

Edit: Actually, this may not apply to Windows XP (developer response needed). However, since there is no built-in trial mechanism, I would assume that if it works, it works.

Ok, thank you. I'm new to Windows 7 (didn't even use Vista before) so I've still got a lot of stuff to learn as some things just aren't as easy as on Windows 2003/2000/XP or they work different. Even took me some googling to figure out how to register a simple filter....
But I think that the registration isn't the cause of my problem anyways, as the filter actually tries to play back the file.

[Episodio1]

hehe, sneaker_ger. I have same config as yours and same problem since beginning (1 month ago). Once I registered with "graphstudio" I get same black screen.

I only tried with MPC-HC :(

[LoRd_MuldeR]

I ever tried to fix the compability problem with the DVBViewer but I can't, I observed that the DiAVC sent decoded frames to the the renderer but nothing appeared and after a while it crashed.

Too bad. As long as DiAVC cannot work with DVBViwer it won't be an option for me :o

However it should be noted that the problem I'm observing is different from what you describe:
I do get output and the output is constantly updated, the only problem is that the output looks completely "scrambled". Also it doesn't crash here.

[uncholowapo]

So is the 64 bit version ready? The world cup has been over for a while now :p

[schweinsz]

So is the 64 bit version ready? The world cup has been over for a while now :p
At the end of the month. I am delayed by something recently.

[hajj_3]

any new ETA on the 64bit build?

[Guest]

schweinsz has been busy on this:

http://forum.doom9.org/showthread.php?p=1426910#post1426910

Perhaps now he will find time for the 64-bit support.

:)

[sneaker_ger]

It tried the diavc.ax included in neuron's new package but it still does not work for me (tested in MPC-HC). Simply crashes.

[schweinsz]

It tried the diavc.ax included in neuron's new package but it still does not work for me (tested in MPC-HC). Simply crashes.
Delete the registry key "CLSID\\{083863F1-70DE-11d0-BD40-00A0C911CE86}\\instance\\{5DFA20A
> 4-C 343-45DF-A46E-EC1711E4EE32}\\rgtcode" and "CLSID\\{083863F1-70DE-11d0-BD40-00A0C911CE86}\\instance\\{5DFA20A4
> -C3 43-45DF-A46E-EC1711E4EE32}\\password", then run the DiAVC Registration.exe to generate the machine code and input the password, then try it in the MPC-HC.

[sneaker_ger]

No, still crashes.
With the previous version it would not instantly crash but instead show a few of the first frames. As it seems to attempt to play the file I'm not sure if the activation is the right spot to look at in finding a solution.

[schweinsz]

No, still crashes.
With the previous version it would not instantly crash but instead show a few of the first frames. As it seems to attempt to play the file I'm not sure if the activation is the right spot to look at in finding a solution.
Ok, download this (http://di-avc.com/Archive.7z),
unzip it and run the now1.bat, check that if it crashes.

[madshi]

@schweinsz, if you want to participate in defining the new "Open Media Type" format, please check your PMs.

[Underground78]

@schweinsz, if you want to participate in defining the new "Open Media Type" format, please check your PMs.

Just curious, what is "Open Media Type" format ? :o

[sneaker_ger]

Ok, download this (http://di-avc.com/Archive.7z),
unzip it and run the now1.bat, check that if it crashes.

Does not crash and decodes the video correctly. (Meaning that the activation might be the cause after all? :confused:)

[schweinsz]

Does not crash and decodes the video correctly. (Meaning that the activation might be the cause after all? :confused:)
No, the activation is in the decoder. your information means that the problem is within the filter.

[sneaker_ger]

Ok, I did something different: instead of installing "for all users", I only installed "for me". Now MPC-HC doesn't instantly crash but instead shows a black screen and playback does not start.
Could it have something to do with any rights? If I start MPC-HC "normally" and open the filter settings it does not list the registration data. If I open as administrator it does list the registration data - but it does not play nonetheless.
I'm on Windows 7 x64 with UAC enabled.

[madshi]

Just curious, what is "Open Media Type" format ? :o
http://forum.doom9.org/showthread.php?t=156051

[Underground78]

Thank you ! :)

[audyovydeo]

Hello schweinsz.

How do I access the DiAVC properties page ?
I have got it working from DGAVCdecDI and MPC-HC, but I can't get to configure DiAVC itself.

thanks
audyovydeo

>>> UPDATE : forget it - just found it from MPC-HC !!!

cheers
a/v

[lych_necross]

I've noticed that while DiAVC plays H.264 files properly, using it makes MPC-HC sluggish. During playback, MPC's menus' respond to clicks very slowly and sometimes not at all. I checked my system's cpu usage during playback, at it is below 12%. My cpu is an Intel Core2 6400 btw. It should be noted that videos play just fine (no dropped or delayed frames). Is this normal?

[schweinsz]

I've noticed that while DiAVC plays H.264 files properly, using it makes MPC-HC sluggish. During playback, MPC's menus' respond to clicks very slowly and sometimes not at all. I checked my system's cpu usage during playback, at it is below 12%. My cpu is an Intel Core2 6400 btw. It should be noted that videos play just fine (no dropped or delayed frames). Is this normal?

Set the "decoder threads" to 2 in the property page, perhaps it helps.

[lych_necross]

Set the "decoder threads" to 2 in the property page, perhaps it helps.
That helped a lot. Thanks. Ideally, what should "decoder threads" be set to?

[yesgrey]

I've noticed that while DiAVC plays H.264 files properly, using it makes MPC-HC sluggish.
This also happens to me, but only on Windows 7. On XP it works fine.

[schweinsz]

That helped a lot. Thanks. Ideally, what should "decoder threads" be set to?

It depends on your CPU.

[lych_necross]

It depends on your CPU.
I was wondering how the decoder determines the # of threads in auto mode. Some like (# of cpu cores) + 1 == (# of threads) ?

[schweinsz]

No, still crashes.
With the previous version it would not instantly crash but instead show a few of the first frames. As it seems to attempt to play the file I'm not sure if the activation is the right spot to look at in finding a solution.
Download the new built DiAVC filter (http://di-avc.com/diavc.7z), try it with the UAC opening. I built the new version with the "UAC Execution Level"==RequireAdministrator. Perhaps it helps.

[schweinsz]

I have finished all of the code related to the DiAVC x64 version. Here is a cmd version (http://di-avc.com/diavcx64.7z) of it, everyone can test it. Unzip it and run the now1.bat, the raw YUV sequence will be generated.
I will release the trial version of the DiAVC x64 directshow filter recently.

[Firebird]

Tested, works fine. But for some reason i get different decoding speed each time i run this .bat, is it ok?

[schweinsz]

Tested, works fine. But for some reason i get different decoding speed each time i run this .bat, is it ok?
When the raw YUV is outputed, the speed is not correct because the multi-threading.
If you want to get the speed, change content of the now1.bat from "win32.exe tempete_704x480.264 tempete_704x480.yuv" to "win32.exe tempete_704x480.264".

[Underground78]

What improvement on speed can we expect ?

[sneaker_ger]

Download the new built DiAVC filter (http://di-avc.com/diavc.7z), try it with the UAC opening. I built the new version with the "UAC Execution Level"==RequireAdministrator. Perhaps it helps.

No. MPC-HC crashes.

I have finished all of the code related to the DiAVC x64 version. Here is a cmd version (http://di-avc.com/diavcx64.7z) of it, everyone can test it. Unzip it and run the now1.bat, the raw YUV sequence will be generated.
I will release the trial version of the DiAVC x64 directshow filter recently.

Test works fine.

[schweinsz]

What improvement on speed can we expect ?
I tested it against the DiAVC x86 version and found that the x64 version is slightly faster than the x86 version by 5%. But I only test one sequence.

[schweinsz]

No. MPC-HC crashes.
What user account do you use? The administrator or guest?
Does the DGAVCDecDI work?

[sneaker_ger]

What user account do you use? The administrator or guest?

I'm logged into Windows as an administrator. I tried starting MPC-HC using admin rights (right click->start with admin rights) and without (just double click).

Does the DGAVCDecDI work?

I don't have a license so I can't test.

[schweinsz]

I'm logged into Windows as an administrator. I tried starting MPC-HC using admin rights (right click->start with admin rights) and without (just double click).

Ok, download the new test version (http://di-avc.com/diavc1.7z), decode H.264 bitstreams using the MPC-HC or graphstudio until it crashes. Report me the result.

[schweinsz]

I have gotten a report that the DiAVC x64 cmd version crashes on windows XP x64, So I provide a new version (http://di-avc.com/diavcx64v1.7z), download it and unzip it, run the now1.bat, feedback the result to me.

[sneaker_ger]

Ok, download the new test version (http://di-avc.com/diavc1.7z), decode H.264 bitstreams using the MPC-HC or graphstudio until it crashes. Report me the result.

stage0
stage1
DiAVC init successed
start receive
start receive
start receive ... ("start receive" loops forever)

no crash

I have gotten a report that the DiAVC x64 cmd version crashes on windows XP x64, So I provide a new version (http://di-avc.com/diavcx64v1.7z), download it and unzip it, run the now1.bat, feedback the result to me.

While the first x64 test already ran fine on my Windows 7 machine I noticed the following:
nHighestFeature 11
nLogicalProcessors 16
intelcpu 1 corenum 16 multithrd 1 decoders 16 inited!

Don't know if this is intended or if it should be 8 threads instead.

/edit: on my Core i7-860

[xv]

I have gotten a report that the DiAVC x64 cmd version crashes on windows XP x64, So I provide a new version (http://di-avc.com/diavcx64v1.7z), download it and unzip it, run the now1.bat, feedback the result to me.
For me it didn´t crash (on Windows XP x64, Athlon 64 X2). I also checked the output file, seems ok, only the frame order doesn´t seem to be ok on the file you provided. I also tested some other files, no problem with them. The new version makes no difference for me, only more verbose output.

May I ask when you fix the comptability problem of DiAVC with DVBViewer?

[Fadeout]

Ok, download the new test version (http://di-avc.com/diavc1.7z), decode H.264 bitstreams using the MPC-HC or graphstudio until it crashes. Report me the result.
This thing has its own exe, so how can one use it in MPC-HC?

[Guest]

It's for testing and debugging. The final version will be a filter.