Hi Ulrich,
On Wed, Mar 4, 2009 at 1:08 PM, Ulrich Hertlein wrote:
> On 4/3/09 11:10 PM, Robert Osfield wrote:
>>
>> Great news. I'll go have a look at the inversion issue.
I've now fixed this problem in osgDB - the --movie parsing code now
honours the Origin of the ImageStream.
>> What happens
On 4/3/09 11:10 PM, Robert Osfield wrote:
Great news. I'll go have a look at the inversion issue.
What happens when you run:
osgmovie -e ffmpeg aliensong.mpg
It's right-side up and playing nicely.
(The aspect ratio isn't always right and lots of 'Using sws_scale' messages but that's not
a p
Hi Ulrich,
On Wed, Mar 4, 2009 at 11:34 AM, Ulrich Hertlein wrote:
> Success!
>
> It compiles! And runs (with "osgviewer --movie -e ffmpeg aliensong.mpg")!!!
> Okay, it's upside down but hey!
Great news. I'll go have a look at the inversion issue.
What happens when you run:
osgmovie -e ffmpe
Hi Robert!
On 4/3/09 10:07 PM, Robert Osfield wrote:
I have just checked in the swscale code path. Could you do an svn
update and let me know how you get on.
Success!
It compiles! And runs (with "osgviewer --movie -e ffmpeg aliensong.mpg")!!!
Okay, it's upside down but hey!
:-D
The #else
Hi Ulrich,
I have just checked in the swscale code path. Could you do an svn
update and let me know how you get on.
Cheers,
Robert.
On Wed, Mar 4, 2009 at 10:51 AM, Ulrich Hertlein wrote:
> Hi Robert,
>
> On 4/3/09 9:23 PM, Robert Osfield wrote:
>>
>> I've just updated to the latest svn/trunk
Hi Robert,
On 4/3/09 9:23 PM, Robert Osfield wrote:
I've just updated to the latest svn/trunk of ffmpeg and it's now
doesn't contain the img_convert at all, but it does build the
libswscale so I'll now implement the swscale code path as well as the
old img_convert path.
Have you comitted? I s
Hi Ulrich,
I've just updated to the latest svn/trunk of ffmpeg and it's now
doesn't contain the img_convert at all, but it does build the
libswscale so I'll now implement the swscale code path as well as the
old img_convert path.
Do you have libswscale installed as part of the DarwinPorts? Is t
Hi Ulrich,
On Wed, Mar 4, 2009 at 9:37 AM, Ulrich Hertlein wrote:
> Tried that but it doesn't make a difference. I am fairly convinced now that
> the symbol is simply not present in the library.
Can you list what symbols it exports?
> I understand that they want people to use swscaler but to d
Hi Robert,
On 4/3/09 7:54 PM, Robert Osfield wrote:
It seems like 'img_convert' (and img_resample and others which also are in a
similar
#if LAVC_VERSION_INT block) is just not in libavcodec... I'm investigating that.
Curious the svn version of ffmpeg has img_convert built in, but not declare
Hi Ulrich,
On Wed, Mar 4, 2009 at 7:59 AM, Ulrich Hertlein wrote:
> The header file contains
>
> #if LIBAVCODEC_VERSION_INT < ((52<<16)+(0<<8)+0)
> attribute_deprecated int img_convert(AVPicture *dst, int dst_pix_fmt,
> const AVPicture *src, int pix_fmt,
> int width,
Hi Uli,
Our ffmpeg plugin already does using extern "C" { .. } when include
the ffmpeg plugin so I don't believe this is the issue.
Robert.
On Tue, Mar 3, 2009 at 10:47 PM, Ulrich von Zadow
wrote:
> Missing
>
> extern "C" {
> #include "foo"
> }
>
> ?
>
> libav* removed some of it's internal ext
Hi Robert,
On 4/3/09 12:37 AM, Robert Osfield wrote:
Undefined symbols:
"_img_convert", referenced from:
osgFFmpeg::FFmpegDecoderVideo::yuva420pToRgba(AVPicture*, AVPicture
const*, int, int)in FFmpegDecoderVideo.cpp.o
Not quite familiar. The code uses img_convert rather than
_img_conv
Missing
extern "C" {
#include "foo"
}
?
libav* removed some of it's internal extern "C" declarations a while
ago, so this might only be necessary with some ffmpeg versions.
Cheers,
Uli
On Mar 3, 2009, at 2:37 PM, Robert Osfield wrote:
Hi Ulrich,
On Tue, Mar 3, 2009 at 12:18 PM, Ulric
Hi Ulrich,
On Tue, Mar 3, 2009 at 12:18 PM, Ulrich Hertlein wrote:
> Okay, the libraries are properly picked up now.
> So now we're back to:
>
> Undefined symbols:
> "_img_convert", referenced from:
> osgFFmpeg::FFmpegDecoderVideo::yuva420pToRgba(AVPicture*, AVPicture
> const*, int, int)in
On 3/3/09 10:53 PM, Robert Osfield wrote:
On Tue, Mar 3, 2009 at 11:38 AM, Ulrich Hertlein wrote:
The libraries (-lavcodec etc) are all there but the library path
(-L/opt/local/lib) is not and I'm struggling to find a way to tell cmake to
use FFMPEG_LIBRARY_DIRS.
I've just added:
LINK_DIR
Hi Ulrich,
On Tue, Mar 3, 2009 at 11:38 AM, Ulrich Hertlein wrote:
> The libraries (-lavcodec etc) are all there but the library path
> (-L/opt/local/lib) is not and I'm struggling to find a way to tell cmake to
> use FFMPEG_LIBRARY_DIRS.
I've just added:
LINK_DIRECTORIES(${FFMPEG_LIBRARY_DIR
Hi Robert,
On 3/3/09 9:58 PM, Robert Osfield wrote:
Thanks for the changes, these are now merged and submitted to svn/trunk.
So with these changes do we have a compiling and working ffmpeg plugin under
OSX?
Not quite, no. Compiling is OK (with a bunch of warnings from the ffmpeg header file
Thanks for spotting J.Pm now fixed and checked into svn/trunk.
On Tue, Mar 3, 2009 at 11:13 AM, J.P. Delport wrote:
> Hi Robert,
>
> Robert Osfield wrote:
>>
>> I've have now added the ffmpeg to the include search paths so the set
>> up code looks like:
>>
>> INCLUDE_DIRECTORIES(
>> ${FFMPEG_L
Hi Robert,
Robert Osfield wrote:
I've have now added the ffmpeg to the include search paths so the set
up code looks like:
INCLUDE_DIRECTORIES(
${FFMPEG_LIBAVFORMAT_INCLUDE_DIRS}
${FFMPEG_LIBAVFORMAT_INCLUDE_DIRS}/libavformat
${FFMPEG_LIBAVFORMAT_INCLUDE_DIRS}/ffmpeg
${FFMPEG_LIBAVDEVIC
Hi Ulrich,
Thanks for the changes, these are now merged and submitted to svn/trunk.
So with these changes do we have a compiling and working ffmpeg plugin
under OSX?
To try it out do:
osgmovie --ffmpeg mymovie.mov
Robert.
On Tue, Mar 3, 2009 at 10:25 AM, Ulrich Hertlein wrote:
> Hi Robert
Hi Robert,
On 3/3/09 8:50 PM, Robert Osfield wrote:
it appears that the required #include (in FFmpegHeaders.hpp) would be:
#include
rather than what it is now:
#include v
Can we change that without breaking compiles on other systems?
This change would break other systems as they don't have
Hi Ulrich,
On Tue, Mar 3, 2009 at 9:25 AM, Ulrich Hertlein wrote:
> So it's not finding "avformat.h". DarwinPorts puts 'avformat.h' in
> /opt/local/include/ffmpeg/avformat.h
> /opt/local/include/libavformat/avformat.h
>
> (ffmpeg/avformat.h is a symlink to ../libavformat/avformat.h)
>
> Since "p
Hi Robert,
On 3/3/09 7:51 PM, Robert Osfield wrote:
The print out of the FFMPEG_INCLUDE_DIRS and FFMPEG_LIBRARIES is a bit
misleading, as
it is actually composed on separate strings like CMake picks up on correctly
when
Thanks for that! (Cmake is still a bit of a black box to me.)
cd src/
Hi Ulrich,
The print out of the FFMPEG_INCLUDE_DIRS and FFMPEG_LIBRARIES is a bit
misleading, as it is actually composed on separate strings like CMake
picks up on correctly when passing it to macros that set up paths, but
when you output these variables to the console they get concatenated
togeth
Hi all,
is anyone else using DarwinPorts ffmpeg/avcodec/avformat and was successful in compiling
the plugin?
Apparently there's a problem between pkg-config and cmake, "cmake" is giving me:
FFMPEG_INCLUDE_DIRS = /opt/local/include/opt/local/include/dirac
FFMPEG_LIBRARIES =
avformatavcodeczbz2
25 matches
Mail list logo
