From: Searcher7 on 2 Feb 2010 12:52 On Feb 2, 12:17 pm, dgk <d...(a)somewhere.com> wrote: > On Tue, 02 Feb 2010 09:54:56 -0600, dpb <n...(a)non.net> wrote: > >Searcher7wrote: > >... > > >> To clarify my meaning, when I said simple apps I meant will it be just > >> as easy to grasp Assembly and write a specific app as it was to grasp > >> Assembly and write the same app years ago when Assembly was popular? > > >Depends...what processor? I modern processor isn't anything at all like > >a 6809, 6502 or Z80 and if you're talking about writing for a recent OS > >interacting nicely w/ it isn't the same, either. > > Not to mention targeting a single processor in a dual/quad/etc system. Hmmm. Ok, let me describe the project that inspired me to all this. (Perhaps I can learn enough to get it done one day). I would like to create an app that will allow "simple" edits on full screen video on the fly. Sequential edits initiated via the key board so a GUI would not be needed while it is running. Since video constitutes stationary images shown one right after the next, I want to be able to pick and choose individual images and chain them together to run border-less from a large database of images and also allow the edits, which would be no more complex than lighten and darkening, to carry over from one frame to the next. Since each image is slightly different than the next, I'll need to be able to manipulate at the pixel level. The resulting border-less videos will also sometimes overlap each other and slowly change in size and position on screen. Thanks. Darren Harris Staten Island, New York.
From: dpb on 2 Feb 2010 13:29 Searcher7 wrote: .... > Hmmm. Ok, let me describe the project that inspired me to all this. > (Perhaps I can learn enough to get it done one day). If you were serious in the comments re: assembler I think that day is a long way in the future... :( > I would like to create an app that will allow "simple" edits on full > screen video on the fly. Sequential edits initiated via the key board > so a GUI would not be needed while it is running. > > Since video constitutes stationary images shown one right after the > next, I want to be able to pick and choose individual images and chain > them together to run border-less from a large database of images and > also allow the edits, which would be no more complex than lighten and > darkening, to carry over from one frame to the next. > > Since each image is slightly different than the next, I'll need to be > able to manipulate at the pixel level. > > The resulting border-less videos will also sometimes overlap each > other and slowly change in size and position on screen. .... This is hardly what I would term a "simple edit". I'm not a video processing type but this ain't gonna' be a trivial app no matter what it's written in and to attack it from the ground up as an assembly-coded app is a non-starter to ever getting anything functional in any reasonable amount of time. I'd think there would already be app's that could do this in existence in the open source community which would be where I'd think you ought to start. --
From: Schmidt on 2 Feb 2010 13:37 "dpb" <none(a)non.net> schrieb im Newsbeitrag news:hk9r00$qfh$1(a)news.eternal-september.org... [Video-Processing] > This is hardly what I would term a "simple edit". I'm not a > video processing type but this ain't gonna' be a trivial app > no matter what it's written in and to attack it from the ground > up as an assembly-coded app is a non-starter to ever > getting anything functional in any reasonable amount of time. Exactly - not to mention, that fast decompressing is done nowadays over Codec-Interfaces (which on Windows are DirectShow...COM-Interfaces) ... and the Video-output needs to deal with Color-Spaces efficiently (usually the faster Decoder-Outputs end up in YUV or UYVY/YUY2 Color-spaces when we talk about Video-Codecs) + the then following high performant and high-quality Stretching of such decoded Output-Buffers (+ additional Lightening/ Darkening) is then performt over DirectX or OpenGL directly in the graphics-card hardware, meaning you nead another "HighLevel"-API to address these devices over their appropriate API-Interfaces on your platform of choice. You will "go nuts", if you try all that in plain Assembler. > I'd think there would already be app's that could do this > in existence in the open source community which would > be where I'd think you ought to start. Yep - and the language of choice in most OpenSource- Projects is C (close enough to Assembler IMO), directly followed by C++. Maybe looking at the Sources of VirtualDub (just google for it), is a good start. Olaf
From: Karl E. Peterson on 2 Feb 2010 18:53 Ralph wrote : > Mike Williams wrote: >> "Michel Posseth [MCP]" <msdn(a)posseth.com> wrote in message >> news:7935E388-59ED-4F3C-BB3F-122556F50480(a)microsoft.com... >> >>> No , but i do believe i am one of the few VB6 coders who >>> can code reall VB6 and reall VB.Net code and knows >>> what both can and can`t . >> >> So there are only a very small number of people in the world who can >> code in VB.Net and who have also coded in VB6, and you're one of >> them? That's very clever of you. All those other less able people, >> especially those less able people on the VB.Net group, must be very >> gad you're there to lead them otherwise they would be wandering >> around like headless chickens. They must be so proud of you. >> > > I was a tad offended at first, but then I noticed he qualified his statement > with "reall". > > I'm not sure I have ever written any reall VB6 or reall VB.Net code. so by > my very uncertainity, he is probably correct. That's what they do down in the bayou, right? -- ..NET: It's About Trust! http://vfred.mvps.org
From: Searcher7 on 3 Feb 2010 00:32
On Feb 2, 1:29 pm, dpb <n...(a)non.net> wrote: > Searcher7wrote: > > ... > > > Hmmm. Ok, let me describe the project that inspired me to all this. > > (Perhaps I can learn enough to get it done one day). > > If you were serious in the comments re: assembler I think that day is a > long way in the future... :( > > > I would like to create an app that will allow "simple" edits on full > > screen video on the fly. Sequential edits initiated via the key board > > so a GUI would not be needed while it is running. > > > Since video constitutes stationary images shown one right after the > > next, I want to be able to pick and choose individual images and chain > > them together to run border-less from a large database of images and > > also allow the edits, which would be no more complex than lighten and > > darkening, to carry over from one frame to the next. > > > Since each image is slightly different than the next, I'll need to be > > able to manipulate at the pixel level. > > > The resulting border-less videos will also sometimes overlap each > > other and slowly change in size and position on screen. > > ... > > This is hardly what I would term a "simple edit". I'm not a video > processing type but this ain't gonna' be a trivial app no matter what > it's written in and to attack it from the ground up as an assembly-coded > app is a non-starter to ever getting anything functional in any > reasonable amount of time. > > I'd think there would already be app's that could do this in existence > in the open source community which would be where I'd think you ought to > start. > > -- And it seems so simple on the surface. :-) Perhaps I should just write my own language. :-) Anyway, this project,or the simple explanation of it is definitely not for open source. Darren Harris Staten Island, New York. |