Re: [Mediapipe-devel] Custom de-interlacer results!

[Viperman <vip...@us...>]

On Tuesday, October 8, 2002, at 10:05  PM, Gaspard Petit wrote:
> I'm very glad that you worked it out =) (sorry for not responding, I 
> was away for the last few days).  BTW, if you want me to have a look 
> at your code to make sure everything is alright, feel free to send me 
> a copy... But what I have seen looked great! If there is anything that 
> I can do to further help you, just ask =)

I'm pretty sure I got most of it now... I just had to do a lot of 
digging in the .h files to get to all the nitty gritty of what certain 
functions were returning. The last little piece of the puzzle came 
together today, but I had one question left.

To make a pipe, you first make a base class, called YourPipe, then a 
YourPipeInstance : YourPipe. Does YourPipe's variables remain constant? 
Or is this class created new for every frame? I'm pretty sure it 
remains, since that's where I put my framecounter, but my pix maps I 
was holding over till the next iteration kept ending up black. Chances 
are, that was when I had bad loop variables (the whole width * 4 thing 
threw me for a loop till I figured out it was pulling 8 bits of a 32 
bit color at a time). Oh! Also, what's the method general for handling 
12-bit color? or is there a way to specify that the color must be at at 
least 24-bit in a stream derived pipe? can I just use a uint8, and then 
4 bools? *lol* I forget if there's a nibble size type in C++...

Thanks for the comments on the de-interlacer. believe me, there's worse 
horizontal pans in that Anime....  They look horrible with the jerking, 
due to the extra frame.

>
> Congrats on your first pipe! (it wasn't that hard, was it? ;-) )

Nope, and I hope you include my deinterlacer in the release when I get 
it finished (there will be Drop, Dupe, Blend, Weave and PALConvert in 
it). I'm going to put the watermaker on the back burner, how about a 
pipe that moves to a certain point of the stream? I can write that with 
that member function of the stream class I believe.

Anyway, the pipes so far that I would like to work on are the following:

The Deinterlacer which is about 60% done

A watermaker which I need to learn how to do Bitmap reads to get the 
file IN the watermarker.... I can read the bitmap, it's the header I 
don't have a layout for.

Wanted to change the FrameRateConverter to also accept standard 
framerates and convert the Scale.

>
> Oh! and if you have comments about what is good and what sucks about 
> the interface, make sure you tell me (I am in the process of 
> redesigning the SDK for 0.9, so all comments are very appreciated)

The SDK interface or the interface of the program?

Well, the SDK was just fine, I think that you should include a blank 
project for streams and frames with some of the required member 
functions laid out, I can do that if you want, but other than that, it 
just needs a little explanation, especially a warning about ALWAYS 
watching your color depth for loops. Also, I think your base classes 
need flags to specify what color depth it can accept, to improve system 
stability. For example, if MyPipe can only accept 24 and 32 bit color, 
it shouldn't be available in YU12 mode, simply because it's a stream 
pipe. (or maybe there's a way to do that that I don't know about...., 
if there is, then they need to be required for at least stream pipes)

The interface of the program is OK, but I believe that it should 
function more like VirtualDub. Most video editing/conversion utilities 
have two windows, so you can see what you are doing. Lining up the 
deinterlace lines sucked, because I was running at about 35 FPS, and I 
couldn't pause fast enough to see individual frames, so a framestepper 
from original to piped is a "must" for my kind of work. I think it 
would be neat if you showed how the pipes affected it on a frame by 
frame basis if someone was debugging thier pipe as well. Just a debug 
button that would show a preview for each pipe, scaled down to fit on 
the screen in an orderly fashion, or maybe a window with a step button 
to move to the next pipe, and it would change the display depending on 
what the next pipe was. Just a handy tool for debugging. Also, while I 
really REALLY like Drawers, I think you got it backwards.... the video 
needs to be the window, and the pipes need to be in the Drawer. this 
way, when pipes are completed, you should be able to easily switch 
between pipes with a dropdown menu somewhere on the main, and only open 
the drawer when you need to modify the pipe.

OH, and this is a BIG one for me, the File opener and File Streamer... 
I really think those need to be integrated into the program, and not be 
pipes. It makes the concept of making pipes data dependent, and I want 
to use my pipes over and over again. I think the input stream should be 
asked of the user before start can be depressed. I see MediaPipe as a 
library of scripts of different pipes to run on the video, so, 
everytime I rip a DVD for example, there's a set of actions I want to 
do for each DVD, and that needs to never change, except for the 
filename.

I can see how this program evolved, I bet there wasn't even a preview 
drawer for a long time. lol, it's just how I would write it: make the 
pipes work, then make the interface user friendly. I really like the 
program, and even if these things didn't happen, I would use it, and 
program for it, but every video editing software I have ever used has a 
before and after picture, the filters (or pipes in this case) are 
scripts that are loaded and not modified and are not data dependent. I 
can see this program evolving to being much better than VDub ever was, 
especially since YOUR CODEC library isn't dependent on what's 
"installed" on the system. Just load up the pipe and go. BTW: If you 
can convince SOMEONE to write a Divx ;-) 3.11 Audio Decoder for Media 
Pipe, that would be SO awesome to fix bad Divx AVI's for QuickTime 
export.

I'll draw up the interface I would like to see in InterfaceBuilder and 
email it to you so you can look at it, altho, I know absolutly NOTHING 
about interface programming. Just a suggestion in living color to look 
at.


Hope that helps!

Doku