PDA

View Full Version : ReDVD: VB.NET Programmers


Tyris
21st October 2002, 22:39
If there are any VB.NET programmers that are interested in working with me on my DVD to DVD-R program (called ReDVD), please let me know! It's in a closed beta stage at the moment. I don't have the time I need to add new features, fix bugs, go to school, and breathe at the same time. Besides, it's always good to have the opinions of more people. If you'd like me to go into more detail than what this short little message gives, just let me know. Thanks!

int 21h
21st October 2002, 22:51
I'm assuming this is using some sort of commandline processing to another Mpeg2 encoder? What are you using for the encoding duties?

Tyris
22nd October 2002, 00:10
I'm using CCE. I've actually attempted to control all the GUI-based programs you would normally use if you followed the various Doom9 guides. The most interesting part has (certainly) been using the Win32 API to get the programs to do what I need them to do. I'm basically just simulating user input. If you're wondering, this has so far proved more stable than I anticipated. It has some quirks, but I'm sure those will eventually be fixed.

int 21h
22nd October 2002, 15:09
IMHO, you should consider moving to a higher level language (like C++) and consider implementing your own encoder. (tough, but rewarding) because anything based on CCE is severely crippled for mainstream usage (copyright issues, not many people own CCE).

Tyris
22nd October 2002, 15:36
Well, that certainly would be one way to go about it, but I don't currently have the time or the ability... If anyone else is up for this, I'd certainly use it as a CCE replacement in my program.

SansGrip
22nd October 2002, 21:37
int 21h: IMHO, you should consider moving to a higher level language (like C++)

Surely lower level? :)

anything based on CCE is severely crippled for mainstream usage

I agree. TMPGEnc would of course be an option, much simpler than implementing an encoder. Reinventing the wheel and all that :).

stax76
22nd October 2002, 23:19
There is Delphi source code to control CCE, maybe you can translate it to .NET, or you can use some .NET interop classes to use the Delphi DLL (don't know if this is possible)

my GPL project DVX is written in VB .NET and I want to add CCE support, but the problem is I don't know how to deal with the WinAPI, I don't read Delphi and I have no clue of interop

Regards,
Dolemite

Tyris
22nd October 2002, 23:54
Well, I've actually not had any problems controlling CCE. As far as using TMPGEnc, I could add support for that later on for the people who can't use CCE.

stax76
23rd October 2002, 00:19
@Tyris,
I would like to test your prog, can send me a copy to dolemite0711@yahoo.de

nice to see more people coding .NET, I hope one day people will stop bothering me because I code .NET

Regards,
Dolemite

int 21h
23rd October 2002, 04:01
Originally posted by SansGrip
int 21h: IMHO, you should consider moving to a higher level language (like C++)

Surely lower level? :)



Compiled languages are definitely higher level than Interpeted languages.

dragongodz
23rd October 2002, 04:43
sorry int 21h but c/c++ is actually a lower level language than any form of basic. lower level denotes close to the actual code running in hardware. asm of course being lowest usable language. while the higher the level of a language the simpler it is and easier for people to program with.

of course all this really means bugger all to 99.9% of people out there. :)

-h
23rd October 2002, 04:47
I don't like TMPGEnc, too much reliance on PSNR as "the" quality measurement.

I'd donate some time towards coding an MPEG-2 encoder if I had some spare, but I think ffmpeg will get MPEG-2 encoding functionality before long.

-h

int 21h
23rd October 2002, 16:00
Originally posted by dragongodz
sorry int 21h but c/c++ is actually a lower level language than any form of basic. lower level denotes close to the actual code running in hardware. asm of course being lowest usable language. while the higher the level of a language the simpler it is and easier for people to program with.

of course all this really means bugger all to 99.9% of people out there. :)

Ah, the joys of semantics.

When I was refering to higher level, I am in the context of development. (i.e. features, performance, etc) of a particular language.

However, you are correct when you say that C/C++ is a lower level language in terms of closeness to the native x86 most everyone runs these days, and things like Java/VB and such are near the top. But I just meant in features and especially performance.

stax76
23rd October 2002, 18:19
For a good example of how VB is not really suitable to time critical applications

the same as C# and all other .NET languages

Tyris
23rd October 2002, 19:22
Yep, I would think all the .NET languages would be bad for time-critical operations since they're all interpreted. However, I don't think the performance is really that bad... Plus, you can have the programs compile to native code when installed, so that makes it a little better. I'm not saying .NET is the fastest or anything like that (it certainly isn't), but I don't think it's that slow either.

stax76
23rd October 2002, 20:57
I'm not saying .NET is the fastest or anything like that

I'm pretty sure .NET is the fastest :D (and easiest)

Tyris
23rd October 2002, 21:47
Well, if that's the case, then what could be better?? ;) (Just kidding, I don't need to hear "go write it in assembly!")

SansGrip
24th October 2002, 00:49
I'm not saying .NET is the fastest or anything like that (it certainly isn't), but I don't think it's that slow either.

For time-critical components one could compile them into native instructions or simply use a lower-level language, perhaps managed C++.

I find .NET's big advantage is development speed as opposed to runtime speed (though that said, it's no slouch once the DLLs are loaded).

Just my (OT) 2 cents ;).