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

[Guest]

Originally Posted by schweinsz

I don't know what I changed in detail. I only know that the interface functions are not changed.

If you have two versions of DiAVC and one has the problem and one doesn't, it is a simple matter to determine the source code changes and isolate which one caused the problem. But without your source code, there's no way anyone other than you can do that. You're a really smart guy, why isn't this obvious to you? Maybe because you don't care? I certainly hope it is not because you have no source code control!

I only add some more features into the DiAVC.
"I notice the same problem; perhaps it is because that I change some compiler options of the DiAVC."
You should notice the "perhaps".

The point is you knew about the problem but weren't willing to do anything about it. You just silently broke other apps depending on continued backward compatibility.

For example, I fix a problem in the GetMachineCode.exe for some computers that it is hard to get their harddisk serial number in recent days.

OK, great. But you have no time to figure out how you broke backward compatibility? As it stands, I can't make your SDK and current decoder version work together, whereas things were fine with a previous decoder version. This should be a nightmare for someone distributing a decoding library, but you appear totally unconcerned.

[schweinsz]

Originally Posted by neuron2

If you have two versions of DiAVC and one has the problem and one doesn't, it is a simple matter to determine the source code changes and isolate which one caused the problem. But without your source code, there's no way anyone other than you can do that. You're a really smart guy, why isn't this obvious to you? Maybe because you don't care? I certainly hope it is not because you have no source code control!

I DO have no strict source code control for the DiAVC source code. Before each release, I test all hundreds bitstreams for correctness and I assume everything is OK. As I don't change the interface, I assume that DG tools work fine.
I often compress the source code to a .7z file and store it to another place, but not in every release. I have limited experiences on the project management. This is a lesson for me.

[LoRd_MuldeR]

Originally Posted by schweinsz

I DO have no strict source code control for the DiAVC source code. Before each release, I test all hundreds bitstreams for correctness and I assume everything is OK. As I don't change the interface, I assume that DG tools work fine.
I often compress the source code to a .7z file and store it to another place, but not in every release. I have limited experiences on the project management. This is a lesson for me.

Sounds like you should definitely do yourself (and your business partners) a favor and have a look at Git!
http://git-scm.com/book

Developing a non-trivial software without a proper version control system can get really messy, even if you work alone. But as soon as a team/collaboration is involved, it becomes pretty much impossible to handle.

Regression tests are extremely helpful too. But what if a test fails (one that used to work) and you need to figure out what change exactly broke it? Without fine-grained version control you're doomed...

[Guest]

Originally Posted by schweinsz

I DO have no strict source code control for the DiAVC source code.

Ouch. That's pretty shocking.

Before each release, I test all hundreds bitstreams for correctness and I assume everything is OK. As I don't change the interface, I assume that DG tools work fine.

But do you actually test the interface by running an application? It should be very simple to make sure your SDK interface is still working. Just because the interface doesn't change that doesn't mean it still functions correctly given other changes to the decoder. It also confuses me a little because you say you were aware of the problem.

I often compress the source code to a .7z file and store it to another place, but not in every release.

Even copying every release would have served you well here. Why wouldn't you copy every release? Disk size is not a concern these days.

[dukey]

I think it's a real shame because this codec is very fast, I think has a _lot_ of potential. But it feels unfinished. The directshow part probably works more by accident than design I think. Seeing the source for the directshow part that schweinsz sent me it's no surprise. It's really a crazy mess full of Messagebox debugging and other insanities.

[schweinsz]

Originally Posted by neuron2

Ouch. That's pretty shocking.
But do you actually test the interface by running an application? It should be very simple to make sure your SDK interface is still working. Just because the interface doesn't change that doesn't mean it still functions correctly given other changes to the decoder. It also confuses me a little because you say you were aware of the problem.
Even copying every release would have served you well here. Why wouldn't you copy every release? Disk size is not a concern these days.

I have a diavc.exe that is the build version of the DiAVC SDK.
After each building, I will run the diavc.exe to verify if the interface works fine. It is always fine.
I have many .7z backups that is only labeled by date, for example, 20100719_1.7z.

[schweinsz]

Originally Posted by dukey

I think it's a real shame because this codec is very fast, I think has a _lot_ of potential. But it feels unfinished. The directshow part probably works more by accident than design I think. Seeing the source for the directshow part that schweinsz sent me it's no surprise. It's really a crazy mess full of Messagebox debugging and other insanities.

But the directshow filter works fine. There is only one issue that I can't fix. As I code the directshow filter, I have very limited knowledge on this, so it is started from scratch.
Anyway, I am not with good code style.
As seldom peoples use the DiAVC, I stopped its development and concentrate on the next generation video coding algorithm development. I try to finish a private codec that is comparable with or better than the HEVC.

[dukey]

Every time I paused video playback became unplayable. I would love to use this codec, but it was kind of a deal breaker. You might find that a lot more people would use diavc if it was a bit more stable, and you had a nicer website. As I pointed out, people can't even buy it unless they go directly to the link. Paypal refuses to work in frames.

You should open source the directshow part of your filter.

[schweinsz]

Originally Posted by dukey

Every time I paused video playback became unplayable. I would love to use this codec, but it was kind of a deal breaker. You might find that a lot more people would use diavc if it was a bit more stable, and you had a nicer website. As I pointed out, people can't even buy it unless they go directly to the link. Paypal refuses to work in frames.

You should open source the directshow part of your filter.

OK, you can get the source code of the DiAVC transform filter source code here.

[schweinsz]

Originally Posted by dukey

Every time I paused video playback became unplayable. I would love to use this codec, but it was kind of a deal breaker. You might find that a lot more people would use diavc if it was a bit more stable, and you had a nicer website. As I pointed out, people can't even buy it unless they go directly to the link. Paypal refuses to work in frames.

You should open source the directshow part of your filter.

Does paypal work in a div? I plan to change the frames to div.

[Disabled]

Probably not. Why not do it like everyone else, send them directly to paypal? I'd assume paypal also has a guide on how to implement their service into your website.

[ChibiBoi]

Did schweinsz go on vacation? I ordered DiAVC three days ago and I haven't gotten a password yet :-/ I anxious to test this out!

[LoRd_MuldeR]

Originally Posted by ChibiBoi

Did schweinsz go on vacation? I ordered DiAVC three days ago and I haven't gotten a password yet :-/ I anxious to test this out!

Well, he said that he now concentrates "on a new video coding project".

[ChibiBoi]

Originally Posted by LoRd_MuldeR

Well, he said that he now concentrates "on a new video coding project".

Yeah, I read that :-/ well I wanted to use DiAVC 1.2.2 with DG tools, but then I read the forums that he and neuron2 were having a disagreement with some things. But schweinsz hasn't been on doom9 since 2 weeks ago, so I'm hoping he's just gone on vacation and he'll get back to me soon LOL

[schweinsz]

Originally Posted by ChibiBoi

Did schweinsz go on vacation? I ordered DiAVC three days ago and I haven't gotten a password yet :-/ I anxious to test this out!

OK, you will get it tonight.

[schweinsz]

Originally Posted by LoRd_MuldeR

Well, he said that he now concentrates "on a new video coding project".

Yes, the intra-coding related program is finished. I will open it recently. All critical algorithms are invented basically before this march. I just implement it one part by one part.

[hajj_3]

Originally Posted by schweinsz

Yes, the intra-coding related program is finished. I will open it recently. All critical algorithms are invented basically before this march. I just implement it one part by one part.

We already have VP9 now though, i don't see much point in your codec being created as google's codec is going to be great and will have hardware decoding built into chips.

[schweinsz]

Originally Posted by hajj_3

We already have VP9 now though, i don't see much point in your codec being created as google's codec is going to be great and will have hardware decoding built into chips.

Do you mean that a new codec is useless? I can do better than VP9, perhaps better than HEVC.

[LigH]

I'm looking forward to your proof. You certainly chose a respectable challenge.

[war59312]

schweinsz, I for one, hope you kick Google's ass! Good lucky buddy!

Though it would be wise to get a better website already. Frames suck!!

And you need to update your COMPARISON page quickly. Should test with a modern i7 CPU and against CoreAVC 3.0 and LAV Filter.