Hello,

Actually, you greatly piqued my interest right there. So I have started fooling 
around
with the ports Makefiles of graphics/ffmpeg and multimedia/x264 until i finally 
managed to
pull it off!

Needed some modifications of ffmpegs Makefile to throw out all dependencies on 
libx264 and
also modifications of x264s Makefile, patches etc.

But I got it working, proving that using modified ports you can easily reverse 
the
ffmpeg/x264 linking.

The only thing that remains is the need for a newer GNU assembler to make x264 
work at
proper speeds. You can leave it out, but that'd cripple x264 in any case. Even 
if you
built ffmpeg+x264 from the stock ports, H.264/AVC encoding speed will be 
crippled when
encoding with ffmpeg. Crippled x264 (or libx264) is just no good.

So to make H.264/AVC encoding work properly, the GNU binutils / gas dependency 
remains in
any case. Since there are no x86 binutils packages or ports, I still had to 
build that
from the source code at "ftp://sourceware.org/pub/binutils/snapshots";.

But, cool stuff. I never thought of using modified ports and "reversing" the 
way how x264
and ffmpeg link against each other.

On 03/28/2014 11:04 AM, Dmitrij D. Czarkoff wrote:
Michael Lackner said:
Hello,

And that's why I cannot use ffmpeg directly. Part of what I am doing is 
bringing a certain
x264 benchmark onto a wide variety of systems, and to do that properly, I would 
need to
use the exact same options for comparisons sake. After managing, proper 
documentation is
being provided online.

You may simply copy ffmpeg and x264 ports to "mystuff" directory inside
your ports dir and make the changes you need to these "local" ports.
That would allow you to reuse ports build infrastructure (which does
many things easier) while having your customization.

Reply via email to