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

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]

Originally Posted by 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.

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]

Originally Posted by squid_80

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]

Originally Posted by 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.

Download the Microsoft Visual C++ 2008 Redistributable Package (x86) and install it, then try. It is the reason perhaps.
http://www.microsoft.com/downloads/d...displaylang=en

[Guest]

Originally Posted by LoRd_MuldeR

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

[schweinsz]

Originally Posted by dwrbudr

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

This must be incured by false use of dll. I will fix it recently.

[schweinsz]

Originally Posted by neuron2

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]

Originally Posted by schweinsz

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]

Originally Posted by Dark Shikari

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]

Originally Posted by neuron2

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 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]

Originally Posted by neuron2

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.