What language to use?

[tank171]

I need a programming language that I can edit video in rgb. The video format being edited isnt a big deal. Anyone know what to use?

 

[Modelworks]

Just about any of the major languages can do that.
c, c++, c#

 

[slugg]

save your precious development time - go with C#

 

[tank171]

Allright. Can anyone give me a good link to a tutorial to learn how to do that?

 

[Cogman]

Originally posted by: tank171
Allright. Can anyone give me a good link to a tutorial to learn how to do that?

Um, video editing is fairly codec specific. It would really help if you gave us a codec you want to work with or at least a vague idea of what you want to accomplish with this program (edit a video in rgb is a bit TOO vague)

 

[tank171]

It doesnt matter what codec to use. I want to be able to find the exact color of individual pixels and do calculations based upon them. I also want to be able to show only certain layers (red, green, or blue) at certain times.

 

[Crusty]

Unless you uncompressed video frames you will need a codec. Uncompressed video frames are huge, so there's a tradeoff. Compression gives you less space used, but more CPU time while uncompressed is more space used and less CPU time. Most codecs are fairly different too depending on what type of video frame you are using mpeg-4, mpeg-2, DV perhaps. You could force a requirement of having the codec installed for the videos you want to support, and then rely on Windows to do most of the heavy lifting for you.

 

[Modelworks]

Originally posted by: tank171
It doesnt matter what codec to use. I want to be able to find the exact color of individual pixels and do calculations based upon them. I also want to be able to show only certain layers (red, green, or blue) at certain times.

I suggest going here and taking apart the source code.
http://www.gimp.org/

Once you see how to do it with a still image, then all you need is code to take your video and split it into frames.

Also:
http://deinterlace.sourceforge.net/
and look at the source code.

 

[tank171]

Originally posted by: Modelworks

Originally posted by: tank171
It doesnt matter what codec to use. I want to be able to find the exact color of individual pixels and do calculations based upon them. I also want to be able to show only certain layers (red, green, or blue) at certain times.

I suggest going here and taking apart the source code.
http://www.gimp.org/

Once you see how to do it with a still image, then all you need is code to take your video and split it into frames.

Also:
http://deinterlace.sourceforge.net/
and look at the source code.

I dont even know where to start looking for that in the code. I have a pretty basic knowlege of programming.

 

[Cogman]

Originally posted by: tank171
I dont even know where to start looking for that in the code. I have a pretty basic knowlege of programming.

Might I suggest taking on a little more basic of a problem then? Dealing with images is not for the faint of heart, thus you should be fairly comfortable programming before taking on this endeavor.

The first step I would recommend for a project like this is to pick a language you want to learn and stick with it. For a problem like this just about anything will do, it would probably be nice, though, to have a faster language. For that I recommend C, or C++ (probably more C though).

After you are fairly comfortable with your language (Make a calculator, a prime number finder, a Fibonacci number finder, and maybe a basic game). You should probably learn the Windows API, this is because if you are going to deal with video processing you are going to want to be able to display it on the screen. Get comfortable with GDI and GDI+, MSDN will be your friend for this. (you can draw lines, make a ball roll down the hill, whatever)

Once you have gotten to this point, then I would suggest starting to work with still images and getting them to do some of the things you want to do in your video program. First you will want to work with BMPs as they are the easiest to use with the Windows API then start to learn how to work with different compression types (PNG, JPEG, ect..). This should get you well trained in understanding how images are displayed on screen and how to manipulate them.

After this point, I would pick a Codec and dive right into it. You need to realize that there is quit a bit to videos, they aren't just a file that contains flashing pictures, they have several layers. The first you will have to deal with is the container. AVI, MKV, MP4, ect.. All have different nuances and ways to deal with videos. You will need to learn how to extract video from them.

Once you have dealt with the container, then working with the actual video is in order. I would start out using raw video. It will be, by far, the easiest to deal with. The next will probably be Huffyuv, and finally something like MPEG2, or MPEG4. You need to realize that most of these codecs don't use an RGB color space, instead they commonly use a YV12 color space. You will need to learn how to convert between the two.

I hope this helped. there really isn't any one tutorial that will teach you how to deal with videos in a day because it is fairly complicated. But these areas I have pointed out should have a fair amount of tutorials available to them. Hopefully you will be able to make it from there.

 

[Cogman]

Originally posted by: Crusty
Unless you uncompressed video frames you will need a codec. Uncompressed video frames are huge, so there's a tradeoff. Compression gives you less space used, but more CPU time while uncompressed is more space used and less CPU time. Most codecs are fairly different too depending on what type of video frame you are using mpeg-4, mpeg-2, DV perhaps. You could force a requirement of having the codec installed for the videos you want to support, and then rely on Windows to do most of the heavy lifting for you.

Interestingly this (the bolded text) isn't always true. with some compression algorithms it is faster to decompress that and display it then it is to load each bit off the hard-drives and display them. (Ok, so it really isn't true because the cpu is still doing more work, but what I mean is that it can be faster to deal with a compression format then just reading it straight off the hard-drive). Of course, that was true a while ago and may not be true now. (Back in the MPEG-1 days )

 

[IHateMyJob2004]

Originally posted by: tank171

Originally posted by: Modelworks

Originally posted by: tank171
It doesnt matter what codec to use. I want to be able to find the exact color of individual pixels and do calculations based upon them. I also want to be able to show only certain layers (red, green, or blue) at certain times.

I suggest going here and taking apart the source code.
http://www.gimp.org/

Once you see how to do it with a still image, then all you need is code to take your video and split it into frames.

Also:
http://deinterlace.sourceforge.net/
and look at the source code.

I dont even know where to start looking for that in the code. I have a pretty basic knowlege of programming.

Based on that comment, I htink you are in over your head.

 

[IHateMyJob2004]

Originally posted by: Cogman

Originally posted by: Crusty
Unless you uncompressed video frames you will need a codec. Uncompressed video frames are huge, so there's a tradeoff. Compression gives you less space used, but more CPU time while uncompressed is more space used and less CPU time. Most codecs are fairly different too depending on what type of video frame you are using mpeg-4, mpeg-2, DV perhaps. You could force a requirement of having the codec installed for the videos you want to support, and then rely on Windows to do most of the heavy lifting for you.

Interestingly this (the bolded text) isn't always true. with some compression algorithms it is faster to decompress that and display it then it is to load each bit off the hard-drives and display them. (Ok, so it really isn't true because the cpu is still doing more work, but what I mean is that it can be faster to deal with a compression format then just reading it straight off the hard-drive). Of course, that was true a while ago and may not be true now. (Back in the MPEG-1 days )

Dumping uncompressed video into memmory will also eat up more memmory. Once you start swapping, things can get very slow.

 

[George P Burdell]

Look at the source code for paint.net for starters.