octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: octave-forge video package


From: Carnë Draug
Subject: Re: octave-forge video package
Date: Mon, 1 Apr 2013 03:18:00 +0100

On 31 March 2013 13:42, Christian Scholz <address@hidden> wrote:
> nitnit wrote:
>>
>> PhilipNienhuis wrote
>>>
>>> What may be of help is the patches Nitzan made to get a collection of OF
>>> packages working, resp. compiled, under MinGW; the video package is among
>>> those:
>>>
>>>
>>> http://octave.1599824.n4.nabble.com/My-patches-for-octaveforge-pkgs-Mingw-build-td4644174.html
>>>
>>> A welcome extension would be a getframe() function (that grabs a screen
>>> window, to be added to a video file later on).
>>>
>>> I'd be very glad if the video package could be made to work smoothly
>>> again.
>>>
>>> Philip
>>
>> While building an octave-3.6.4 mingw binaries, I have tried to build the
>> video package with recent ffmpeg libs and got some errors with both
>> current
>> svn video package and my patched video package, so be aware that my
>> patched
>> video package can be built with the older ffmpeg lib (git-41bf67d from
>> august 2011).
>>
>> Nitzan
>>
>> Nitzan
>>
>>
>>
>> --
>> View this message in context:
>> http://octave.1599824.n4.nabble.com/octave-forge-video-package-tp4651335p4651345.html
>> Sent from the Octave - Maintainers mailing list archive at Nabble.com.
>>
> Well for now I have changed only the aviread.cc function. It's now returning
> a struct array of frames with two fields "cdata" which holds a height x
> width x 3 uint8 array
> containing the three image channels and a "colormap" field which is just
> empty because
> indexed video formats are not yet implemented in the AVHandler.
> Also with help vom #octave I changed the conversion from libav to octave to
> use fortran_vecs
> using uint8NDarray instead of double. This speeds the whole thing up by a
> factor of 3,
> is fully compatible to matlab and makes sense because video formats with
> more than 8bit per channel
> are exotic and the code wasn't intendet for that anyway.
>
> Should I submit it to the patch tracker already? As I'm not really familier
> yet with the right conventions
> the code might require some clean up but I think it's useable.
>
> A problem might be that this is not backwards compatible with the way it
> worked before,
> because I'm returning structs now instead of a single image.

Please upload your patch to https://savannah.gnu.org/patch/?group=octave

If we have to pick between backward and matlab compatibility, we pick
the latest. So should be fine.

Carnë


reply via email to

[Prev in Thread] Current Thread [Next in Thread]