[sip-comm-dev] FFMPEG 0.5


#1

Hi,

I was trying to compile ffmpeg for SC using ffmpeg 0.5. I've successfully
built latest x264 using instructions from readme.txt. But when i'd tried to
configure ffmpeg i've got an error (using msys and mingw):

sh-3.1$ ./configure --target-os=mingw32 --disable-mmx --enable-memalign-hack
--enable-static --disable-shared --shlibdir=. --disable-encoders
--disable-decoders --disable-muxers --disable-demuxers --disable-parsers
--disable-bsfs --dis
able-protocols --disable-devices --disable-network --enable-libx264
--enable-gpl --enable-parser=h264 --enable-encoder=libx264
--enable-decoder=h264 --enable-muxer=h264 --enable-demuxer=h264
--extra-ldflags=-L$X264_HOME --extra-cflags=
-I$X264_HOME --disable-debug --disable-ffserver --disable-ffplay
--disable-ffmpeg --disable-pthreads --enable-w32threads
--enable-cross-compile
gcc is unable to create an executable file.
C compiler test failed.

In config.err

/mingw/lib/crt2.o:crt1.c:(.bss+0x4): first defined here
collect2: ld returned 1 exit status
C compiler test failed.

Used latest versions of x264 and ffmpeg.
So, first of all, *is it possible to "migrate" to new version of ffmpeg? How
to solve this error?* I've seen several new features implemented for h264 in
this release. *Does it have any sense? ffmpeg or x264 encode/decode video in
SC?*

Also, i've integrated jffmpeg to SC with h263 and h263+ (my goal is to get
video in high resolutions, eg. 960x720).
h263+ requires quite more bandwidth (700-900 kbit with 960x720 15fps), but
it works faster and can encode stream in real time. But jffmpeg is a "dead"
project now, and not all cool features of h263+ were implemented :(. BTW
h263+ is not turned on by default in latest version of jffmpeg. The main
benefit i've got using h263+ is a can use any dimension, but not only
352x288, 704x576 and 1408x1152 which are allowed for h263.
Also, there is a code in in JMF's core which cheks size of video and if
codec is h263 - forcing video to be 352x288. I've turned off registration of
custom h264 in SC (i mean PluginManager.addPlugin(...)) and registered h263
as h264. And replaced all entries of "h263" by "h264". So, after that i've
got 704x576 and 1408x1152 by h263 - it is also quite fast.
jffmpeg uses patch from salyens.com (company, that implemented sjmf and
streaming using h263 and h264, but not free). But this patch is only for
ffmpeg 0.4.7 (seems that it is 2003 year version). Many features wesr
implemented since that year. release 0.5 contains upgrades for h263 and h264

- H.263 OBMC & 4MV support
- H.263 alternative inter vlc support
- H.263 loop filter
- H.263 slice structured mode
- multithreaded/SMP encoding for MPEG-1/MPEG-2/MPEG-4/H.263
- H.263+ custom pcf support
- H.264 custom quantization matrices support
- slice-based parallel H.264 decoding
- H.264 PAFF decoding
- H.264 loop filter support
- H.264 CABAC support

The problem is that rtp for h263 and h263+ is only planned for next release,
and who knows when it will be... *So, how difficult will it be to implement
patch like salyens did?*

I'm Java/Ruby developer and my level of C is very low. May be here is
someone who has a great experience of developing things like that.

Sorry for my english :frowning:
Thanks for any help!

Regards,
Alexandr Kazeko


#2

gcc is unable to create an executable file.
C compiler test failed.

The above gives it out that something in the environment or the
arguments of the configure run of your compiler isn't OK and it
prevents it from compiling. It's something small and prevents your
compiler from compiling simple things as "int main() {return 0;}". You
should try to compile something as dummy as main.c which contains only
the above code. You may also want to make sure that the environment
variable X264_HOME contains a correct path.

Otherwise, I personally moved between a number of ffmpeg and x264
versions so it's totally possible.

···

On Thu, Apr 9, 2009 at 8:30 PM, Alexander Kazeko <alexandr.temp@gmail.com> wrote:

Hi,

I was trying to compile ffmpeg for SC using ffmpeg 0.5. I've successfully
built latest x264 using instructions from readme.txt. But when i'd tried to
configure ffmpeg i've got an error (using msys and mingw):

sh-3.1$ ./configure --target-os=mingw32 --disable-mmx --enable-memalign-hack
--enable-static --disable-shared --shlibdir=. --disable-encoders
--disable-decoders --disable-muxers --disable-demuxers --disable-parsers
--disable-bsfs --dis
able-protocols --disable-devices --disable-network --enable-libx264
--enable-gpl --enable-parser=h264 --enable-encoder=libx264
--enable-decoder=h264 --enable-muxer=h264 --enable-demuxer=h264
--extra-ldflags=-L$X264_HOME --extra-cflags=
-I$X264_HOME --disable-debug --disable-ffserver --disable-ffplay
--disable-ffmpeg --disable-pthreads --enable-w32threads
--enable-cross-compile
gcc is unable to create an executable file.
C compiler test failed.

In config.err

/mingw/lib/crt2.o:crt1.c:(.bss+0x4): first defined here
collect2: ld returned 1 exit status
C compiler test failed.

Used latest versions of x264 and ffmpeg.
So, first of all, is it possible to "migrate" to new version of ffmpeg? How
to solve this error? I've seen several new features implemented for h264 in
this release. Does it have any sense? ffmpeg or x264 encode/decode video in
SC?

Also, i've integrated jffmpeg to SC with h263 and h263+ (my goal is to get
video in high resolutions, eg. 960x720).
h263+ requires quite more bandwidth (700-900 kbit with 960x720 15fps), but
it works faster and can encode stream in real time. But jffmpeg is a "dead"
project now, and not all cool features of h263+ were implemented :(. BTW
h263+ is not turned on by default in latest version of jffmpeg. The main
benefit i've got using h263+ is a can use any dimension, but not only
352x288, 704x576 and 1408x1152 which are allowed for h263.
Also, there is a code in in JMF's core which cheks size of video and if
codec is h263 - forcing video to be 352x288. I've turned off registration of
custom h264 in SC (i mean PluginManager.addPlugin(...)) and registered h263
as h264. And replaced all entries of "h263" by "h264". So, after that i've
got 704x576 and 1408x1152 by h263 - it is also quite fast.
jffmpeg uses patch from salyens.com (company, that implemented sjmf and
streaming using h263 and h264, but not free). But this patch is only for
ffmpeg 0.4.7 (seems that it is 2003 year version). Many features wesr
implemented since that year. release 0.5 contains upgrades for h263 and h264

- H.263 OBMC & 4MV support
- H.263 alternative inter vlc support
- H.263 loop filter
- H.263 slice structured mode
- multithreaded/SMP encoding for MPEG-1/MPEG-2/MPEG-4/H.263
- H.263+ custom pcf support
- H.264 custom quantization matrices support
- slice-based parallel H.264 decoding
- H.264 PAFF decoding
- H.264 loop filter support
- H.264 CABAC support

The problem is that rtp for h263 and h263+ is only planned for next release,
and who knows when it will be... So, how difficult will it be to implement
patch like salyens did?

I'm Java/Ruby developer and my level of C is very low. May be here is
someone who has a great experience of developing things like that.

Sorry for my english :frowning:
Thanks for any help!

Regards,
Alexandr Kazeko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Lubomir,

Thanks. You was right - i forgot to export X264_HOME.

I've built latest x264 and ffmpeg 0.5, edited makefile and...

net_java_sip_communicator_impl_media_codec_video_FFMPEG.c:(.text+0x621):
undefined reference to `img_convert'

Ive found this method in avcodec in ffmpeg 0.4.7, but there is no such
method in ffmpeg 0.5 :frowning:

Have you tried to move to 0.5?

···

2009/4/9 Lubomir Marinov <lubomir.marinov@gmail.com>

> gcc is unable to create an executable file.
> C compiler test failed.

The above gives it out that something in the environment or the
arguments of the configure run of your compiler isn't OK and it
prevents it from compiling. It's something small and prevents your
compiler from compiling simple things as "int main() {return 0;}". You
should try to compile something as dummy as main.c which contains only
the above code. You may also want to make sure that the environment
variable X264_HOME contains a correct path.

Otherwise, I personally moved between a number of ffmpeg and x264
versions so it's totally possible.

On Thu, Apr 9, 2009 at 8:30 PM, Alexander Kazeko > <alexandr.temp@gmail.com> wrote:
> Hi,
>
> I was trying to compile ffmpeg for SC using ffmpeg 0.5. I've successfully
> built latest x264 using instructions from readme.txt. But when i'd tried
to
> configure ffmpeg i've got an error (using msys and mingw):
>
> sh-3.1$ ./configure --target-os=mingw32 --disable-mmx
--enable-memalign-hack
> --enable-static --disable-shared --shlibdir=. --disable-encoders
> --disable-decoders --disable-muxers --disable-demuxers --disable-parsers
> --disable-bsfs --dis
> able-protocols --disable-devices --disable-network --enable-libx264
> --enable-gpl --enable-parser=h264 --enable-encoder=libx264
> --enable-decoder=h264 --enable-muxer=h264 --enable-demuxer=h264
> --extra-ldflags=-L$X264_HOME --extra-cflags=
> -I$X264_HOME --disable-debug --disable-ffserver --disable-ffplay
> --disable-ffmpeg --disable-pthreads --enable-w32threads
> --enable-cross-compile
> gcc is unable to create an executable file.
> C compiler test failed.
>
> In config.err
>
> /mingw/lib/crt2.o:crt1.c:(.bss+0x4): first defined here
> collect2: ld returned 1 exit status
> C compiler test failed.
>
>
> Used latest versions of x264 and ffmpeg.
> So, first of all, is it possible to "migrate" to new version of ffmpeg?
How
> to solve this error? I've seen several new features implemented for h264
in
> this release. Does it have any sense? ffmpeg or x264 encode/decode video
in
> SC?
>
>
> Also, i've integrated jffmpeg to SC with h263 and h263+ (my goal is to
get
> video in high resolutions, eg. 960x720).
> h263+ requires quite more bandwidth (700-900 kbit with 960x720 15fps),
but
> it works faster and can encode stream in real time. But jffmpeg is a
"dead"
> project now, and not all cool features of h263+ were implemented :(. BTW
> h263+ is not turned on by default in latest version of jffmpeg. The main
> benefit i've got using h263+ is a can use any dimension, but not only
> 352x288, 704x576 and 1408x1152 which are allowed for h263.
> Also, there is a code in in JMF's core which cheks size of video and if
> codec is h263 - forcing video to be 352x288. I've turned off registration
of
> custom h264 in SC (i mean PluginManager.addPlugin(...)) and registered
h263
> as h264. And replaced all entries of "h263" by "h264". So, after that
i've
> got 704x576 and 1408x1152 by h263 - it is also quite fast.
> jffmpeg uses patch from salyens.com (company, that implemented sjmf and
> streaming using h263 and h264, but not free). But this patch is only for
> ffmpeg 0.4.7 (seems that it is 2003 year version). Many features wesr
> implemented since that year. release 0.5 contains upgrades for h263 and
h264
>
> - H.263 OBMC & 4MV support
> - H.263 alternative inter vlc support
> - H.263 loop filter
> - H.263 slice structured mode
> - multithreaded/SMP encoding for MPEG-1/MPEG-2/MPEG-4/H.263
> - H.263+ custom pcf support
> - H.264 custom quantization matrices support
> - slice-based parallel H.264 decoding
> - H.264 PAFF decoding
> - H.264 loop filter support
> - H.264 CABAC support
>
> The problem is that rtp for h263 and h263+ is only planned for next
release,
> and who knows when it will be... So, how difficult will it be to
implement
> patch like salyens did?
>
> I'm Java/Ruby developer and my level of C is very low. May be here is
> someone who has a great experience of developing things like that.
>
> Sorry for my english :frowning:
> Thanks for any help!
>
> Regards,
> Alexandr Kazeko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

I didn't try to move to 0.5 but I know img_convert was deprecated and
was to go away. It's necessary to either find a substitute (the
deprecation comment on img_covert used to say what one should use as a
substitute) or if img_convert is still there and only excluded with a
macro, to let it compile in and still use it though it's deprecated.

···

On Fri, Apr 10, 2009 at 9:59 AM, Alexander Kazeko <alexandr.temp@gmail.com> wrote:

Lubomir,

Thanks. You was right - i forgot to export X264_HOME.

I've built latest x264 and ffmpeg 0.5, edited makefile and...

net_java_sip_communicator_impl_media_codec_video_FFMPEG.c:(.text+0x621):
undefined reference to `img_convert'

Ive found this method in avcodec in ffmpeg 0.4.7, but there is no such
method in ffmpeg 0.5 :frowning:

Have you tried to move to 0.5?

2009/4/9 Lubomir Marinov <lubomir.marinov@gmail.com>

> gcc is unable to create an executable file.
> C compiler test failed.

The above gives it out that something in the environment or the
arguments of the configure run of your compiler isn't OK and it
prevents it from compiling. It's something small and prevents your
compiler from compiling simple things as "int main() {return 0;}". You
should try to compile something as dummy as main.c which contains only
the above code. You may also want to make sure that the environment
variable X264_HOME contains a correct path.

Otherwise, I personally moved between a number of ffmpeg and x264
versions so it's totally possible.

On Thu, Apr 9, 2009 at 8:30 PM, Alexander Kazeko >> <alexandr.temp@gmail.com> wrote:
> Hi,
>
> I was trying to compile ffmpeg for SC using ffmpeg 0.5. I've
> successfully
> built latest x264 using instructions from readme.txt. But when i'd tried
> to
> configure ffmpeg i've got an error (using msys and mingw):
>
> sh-3.1$ ./configure --target-os=mingw32 --disable-mmx
> --enable-memalign-hack
> --enable-static --disable-shared --shlibdir=. --disable-encoders
> --disable-decoders --disable-muxers --disable-demuxers --disable-parsers
> --disable-bsfs --dis
> able-protocols --disable-devices --disable-network --enable-libx264
> --enable-gpl --enable-parser=h264 --enable-encoder=libx264
> --enable-decoder=h264 --enable-muxer=h264 --enable-demuxer=h264
> --extra-ldflags=-L$X264_HOME --extra-cflags=
> -I$X264_HOME --disable-debug --disable-ffserver --disable-ffplay
> --disable-ffmpeg --disable-pthreads --enable-w32threads
> --enable-cross-compile
> gcc is unable to create an executable file.
> C compiler test failed.
>
> In config.err
>
> /mingw/lib/crt2.o:crt1.c:(.bss+0x4): first defined here
> collect2: ld returned 1 exit status
> C compiler test failed.
>
>
> Used latest versions of x264 and ffmpeg.
> So, first of all, is it possible to "migrate" to new version of ffmpeg?
> How
> to solve this error? I've seen several new features implemented for h264
> in
> this release. Does it have any sense? ffmpeg or x264 encode/decode video
> in
> SC?
>
>
> Also, i've integrated jffmpeg to SC with h263 and h263+ (my goal is to
> get
> video in high resolutions, eg. 960x720).
> h263+ requires quite more bandwidth (700-900 kbit with 960x720 15fps),
> but
> it works faster and can encode stream in real time. But jffmpeg is a
> "dead"
> project now, and not all cool features of h263+ were implemented :(. BTW
> h263+ is not turned on by default in latest version of jffmpeg. The main
> benefit i've got using h263+ is a can use any dimension, but not only
> 352x288, 704x576 and 1408x1152 which are allowed for h263.
> Also, there is a code in in JMF's core which cheks size of video and if
> codec is h263 - forcing video to be 352x288. I've turned off
> registration of
> custom h264 in SC (i mean PluginManager.addPlugin(...)) and registered
> h263
> as h264. And replaced all entries of "h263" by "h264". So, after that
> i've
> got 704x576 and 1408x1152 by h263 - it is also quite fast.
> jffmpeg uses patch from salyens.com (company, that implemented sjmf and
> streaming using h263 and h264, but not free). But this patch is only for
> ffmpeg 0.4.7 (seems that it is 2003 year version). Many features wesr
> implemented since that year. release 0.5 contains upgrades for h263 and
> h264
>
> - H.263 OBMC & 4MV support
> - H.263 alternative inter vlc support
> - H.263 loop filter
> - H.263 slice structured mode
> - multithreaded/SMP encoding for MPEG-1/MPEG-2/MPEG-4/H.263
> - H.263+ custom pcf support
> - H.264 custom quantization matrices support
> - slice-based parallel H.264 decoding
> - H.264 PAFF decoding
> - H.264 loop filter support
> - H.264 CABAC support
>
> The problem is that rtp for h263 and h263+ is only planned for next
> release,
> and who knows when it will be... So, how difficult will it be to
> implement
> patch like salyens did?
>
> I'm Java/Ruby developer and my level of C is very low. May be here is
> someone who has a great experience of developing things like that.
>
> Sorry for my english :frowning:
> Thanks for any help!
>
> Regards,
> Alexandr Kazeko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net