[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: octave-forge video package
From: |
Christian |
Subject: |
Re: octave-forge video package |
Date: |
Sun, 31 Mar 2013 14:32:15 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 |
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.
Christian