[MPlayer-users] Looking for a software to clip a movie camera to size

[Reimar Döffinger]

On 23.09.2013, at 14:06, Gene Heskett <gheskett at wdtv.com> wrote:

> On Monday 23 September 2013 07:30:57 Reimar Döffinger did opine:
> 
>> On 22.09.2013, at 20:47, Gene Heskett <gheskett at wdtv.com> wrote:
>>> Is there such a video processing module in our 'bag of tricks'?
>> 
>> That was a bit long, but sure there is vf crop. But if that's all you'd
>> want MPlayer for that is overkill.
>> Cropping is one pointer add (to reflect the new top-left point) and then
>> setting new width and height. At least as long as there is stride
>> support it doesn't involve any data processing at all.
> 
> Sorry about the length, but I wanted to make it clear what my thinking was.  
> I also think the available bandwidth thru a USB port on an intel atom 
> motherboard is a speed limitation.  As is the fact that the cnc application 
> demands one of the cpu cores, using isolcpus for that, which keeps the 
> remaining one busier than a one armed paper hanger doing this too.
> 
> But you make this sound like a dead simple thing to do, but my one time 
> familiarity with C was 25 years ago when it was straight K&R & CPU's were 
> Motorola's & 8 bits wide, so I fear I'm at the mercy of todays coders to do 
> this. The software being used now is camunits, which can control the v4L2 
> device, but cannot do cropping.  But it uses a rather useless flip module 
> that can reverse in either direction, but the ideal camera mounting 
> position on the mill would need a 90 degree rotation to make the image 
> correlate with what the eye sees, and the flip can't fix that.  That flip 
> is at least a frames delay that as a retired television engineer, can't be 
> gotten around, only bypassed, which I will try to do.  So in the *nix way 
> of doing things with pipes, what would be the name of a video processing 
> module that could do this crop in real time?

With MPlayer, read the documentation of he "crop" video filter.
In addition, the "rotate" filter would probably be interesting.
Since MPlayer can read via v4l (at least for many cameras, though not all) you should be able to test these directly, it should also give you an idea what kind of CPU load to expect and if USB really is an issue.
That still leaves how to get it from MPlayer to some other application?
I think there used to be some loopback v4l device where you could provide to output from one program to another via a virtual v4l device, but I think that isn't maintained any more and might not be working anymore nowadays...