[OpenWrt-Devel] [PATCH] Allow for more configurable FFmpeg build options (#7837, #8465)
This patch allows broad control over FFmpeg's libav* build configuration and fixes a typo in ffprobe's install section. The patch resolves #7837 as the choice of building a full libav* is available. This should also resolve #8465 as input devices such as cameras can be enabled. The files created by a full libav* build will be large (several megabytes) and not recommended for end users. Its use could help debugging other issues to learn whether the problem is the openwrt build configuration or another cause. Signed-off-by: Ian Leonard --- Index: packages/multimedia/ffmpeg/Config.in === --- packages/multimedia/ffmpeg/Config.in(revision 28090) +++ packages/multimedia/ffmpeg/Config.in(working copy) @@ -1,18 +1,60 @@ menu "Configuration" depends PACKAGE_libffmpeg -config FFMPEG_ENCODE - bool "Big Toggle for FFmpeg's encoder/muxer support" +comment "Libav* build options ---" + +config FFMPEG_LIBAV_FULL + bool "Toggle for full libav* support" + select FFMPEG_BSFS + select FFMPEG_DECODE + select FFMPEG_ENCODE + select FFMPEG_FILTERS + select FFMPEG_INDEVS + select FFMPEG_OUTDEVS + select FFMPEG_HWACCELS + select FFMPEG_PARSERS + select FFMPEG_PROTOCOLS depends FFMPEG_PATENTED + help + This options selects each of the FFmpeg's toggles to create a full build + of the libav* libraries. Note: This is a large binary and not suitable + for most users. +config FFMPEG_BSFS + bool "Toggle for FFmpeg's bitstream filter support" + config FFMPEG_DECODE - bool "Big Toggle for FFmpeg's decoder/demuxer support" + bool "Toggle for FFmpeg's decoder/demuxer support" depends FFMPEG_PATENTED +config FFMPEG_ENCODE + bool "Toggle for FFmpeg's encoder/muxer support" + depends FFMPEG_PATENTED + +config FFMPEG_FILTERS + bool "Toggle for FFmpeg's video processing filter support" + +config FFMPEG_INDEVS + bool "Toggle for FFmpeg's input device (camera, etc) support" + +config FFMPEG_OUTDEVS + bool "Toggle for FFmpeg's output device support" + +config FFMPEG_HWACCELS + bool "Toggle for FFmpeg's video hardware acceleration support" + +config FFMPEG_PARSERS + bool "Toggle for FFmpeg's stream parsing support" + +config FFMPEG_PROTOCOLS + bool "Toggle for FFmpeg's protocol support" + config FFMPEG_PATENTED bool "Include patented codecs and technologies" default BUILD_PATENTED +comment "Package Profiles ---" + config FFMPEG_FFSERVER_SUPPORT bool "Include support for ffserver (FFmpeg streaming server)" select FFMPEG_MUXER_ffm Index: packages/multimedia/ffmpeg/Makefile === --- packages/multimedia/ffmpeg/Makefile (revision 28090) +++ packages/multimedia/ffmpeg/Makefile (working copy) @@ -9,7 +9,7 @@ PKG_NAME:=ffmpeg PKG_VERSION:=0.8.2 -PKG_RELEASE:=1 +PKG_RELEASE:=2 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 PKG_SOURCE_URL:=http://ffmpeg.org/releases/ @@ -239,12 +239,13 @@ --enable-postproc \ --enable-swscale \ \ - --disable-bsfs \ - --disable-devices \ - --disable-filters \ - --disable-hwaccels \ - --disable-parsers \ - --disable-protocols \ + $(if $(CONFIG_FFMPEG_BSFS),,--disable-bsfs) \ + $(if $(CONFIG_FFMPEG_OUTDEVS),,--disable-outdevs) \ + $(if $(CONFIG_FFMPEG_INDEVS),,--disable-indevs) \ + $(if $(CONFIG_FFMPEG_FILTERS),,--disable-filters) \ + $(if $(CONFIG_FFMPEG_HWACCELS),,--disable-hwaccels) \ + $(if $(CONFIG_FFMPEG_PARSERS),,--disable-parsers) \ + $(if $(CONFIG_FFMPEG_PROTOCOLS),,--disable-protocols) \ $(if $(CONFIG_FFMPEG_ENCODE),,--disable-encoders --disable-muxers) \ $(if $(CONFIG_FFMPEG_DECODE),,--disable-decoders --disable-demuxers) \ $(FFMPEG_CONFIGURE_ENCODERS) \ @@ -288,7 +289,7 @@ endef define Package/ffprobe/install - $(INSTALL_DIR_ $(1)/usr/bin + $(INSTALL_DIR) $(1)/usr/bin $(CP) $(PKG_INSTALL_DIR)/usr/bin/ffprobe $(1)/usr/bin/ endef ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Image command line hack question
Hello, On Saturday 27 August 2011 15:14:51 Andrew wrote: > Hello again, > I looked through the patches, and think of rebasing my current work on top > of them. > Still, one question persists: > Is your work on RT856X abandoned? Why wasn't it included in the OpenWRT > trunk. At the time it was written, it was not tested on enough hardware to be included. > I'll try to forward-port your RT856X work, some things look similar. But > since I do not have any RT865X board, it might be buggy. I have some RTL865x boards that I can test on. > > And what conserns those realtek's imgtools (cvimg and mgbin), will it be > OK if I make a script that either downloads the official GPL sources from, > say TRENDnet's site and rips the reuired stuff from it (or asks the user to > do that manually). (I have a strange feeling it isn't worth the effort > asking realtek for license clarification) Since the sourcecode was published, let's just say that we can use the version as-is, but a rewrite by someone else and with proper license would be better. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Image command line hack question
Hello again, I looked through the patches, and think of rebasing my current work on top of them. Still, one question persists: Is your work on RT856X abandoned? Why wasn't it included in the OpenWRT trunk. I'll try to forward-port your RT856X work, some things look similar. But since I do not have any RT865X board, it might be buggy. And what conserns those realtek's imgtools (cvimg and mgbin), will it be OK if I make a script that either downloads the official GPL sources from, say TRENDnet's site and rips the reuired stuff from it (or asks the user to do that manually). (I have a strange feeling it isn't worth the effort asking realtek for license clarification) Regards, Andrew ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Image command line hack question
On Sat, 27 Aug 2011 13:02:14 +0200, Florian Fainelli wrote: > Hello, > > On Saturday 27 August 2011 12:45:41 Andrew wrote: >> Hello all, >> I'm currently working on rtl8196 port, and those weird guys from realtek >> implemented there a different architecture rlx in kernel. >> Basically, much is borrowed from mips, but small differences here and >> there are present. I applied openwrt command hack to rlx, however, that >> didn't work out of the box. >> To get patch-cmdline actually patch rlx's vmlinux I had to widen the >> SEARCH_SPACE ( >> http://invyl.ath.cx/cgit/cgit.cgi/openwrt/commit/?id=38a13e566f179a12803a39 >> 1ca941cad1f806db08 ). The next thing was, that despite the image gets >> patched, and I see the correct text hexdump'ing the image, the kernel >> command line stays the same. Looks like some other place needs to get >> patched, but I just can't firure where to look. Any ideas? > > The bootloader most likely overrides the command-line as well, so make > sure > your prom code concatenates both command-line. Got it, I'll try to investigate. >> Thanks in advance. >> >> I have now fixed the image packing for initial support for different >> boards, and, hopefully I'll get spi flash up&running next week. What >> should >> the state of the port be, before it's ok to send in the patches to the >> trunk? :) > > I had a quick look at the files in your repository: > > - please merge support for rtl8196c and rtl8196b, they do not differ that > much This is just the original realtek's code. If you're talking about stuff in mips/ it looks like dead code, since it doesn't even get compiled. > - please use the patches that I posted on the mailing-list as much as you > can, > the code is much cleaner and integrates better into the existing mips > architecture (special checksum, memcpy functions etc ...) > - remove all the dead code ifdefed'out with #if 0 I see. I'll try to diff rsdk gcc with the original and see if they have some useful optimisations there I can use as well. Cleanup is subject of the future work, since there's a lot of redundant and dead code. (I have a strange feeling the whole arch/mips part is dead in realtek's tree) > - port your patches to 2.6.39 at least, 3.0 would be even better One really big question here: should I try go on with their RLX architecture in kernel, or should I try to go off with plain mips? It does look diffing rlx and mips that they DO have some differences. Mostly commented mips code here and there. > - remove all the unnecessary hacks introduced by patches-2.6.30, they are > not > required > > - clarify the license of the tools located in image/imgtools, they do not > seem > to be open source (they have no license at all) This is the worst part of it. All the files I have are from TRENDnet TEW622-BRP GPL release (Should the GPL cover the tools, or not?), but I've got no idea how should I clarify those (other then rewriting from scratch which is pain) Regards, Andrew ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Image command line hack question
Hello, On Saturday 27 August 2011 12:45:41 Andrew wrote: > Hello all, > I'm currently working on rtl8196 port, and those weird guys from realtek > implemented there a different architecture rlx in kernel. > Basically, much is borrowed from mips, but small differences here and > there are present. I applied openwrt command hack to rlx, however, that > didn't work out of the box. > To get patch-cmdline actually patch rlx's vmlinux I had to widen the > SEARCH_SPACE ( > http://invyl.ath.cx/cgit/cgit.cgi/openwrt/commit/?id=38a13e566f179a12803a39 > 1ca941cad1f806db08 ). The next thing was, that despite the image gets > patched, and I see the correct text hexdump'ing the image, the kernel > command line stays the same. Looks like some other place needs to get > patched, but I just can't firure where to look. Any ideas? The bootloader most likely overrides the command-line as well, so make sure your prom code concatenates both command-line. > Thanks in advance. > > I have now fixed the image packing for initial support for different > boards, and, hopefully I'll get spi flash up&running next week. What should > the state of the port be, before it's ok to send in the patches to the > trunk? :) I had a quick look at the files in your repository: - please merge support for rtl8196c and rtl8196b, they do not differ that much - please use the patches that I posted on the mailing-list as much as you can, the code is much cleaner and integrates better into the existing mips architecture (special checksum, memcpy functions etc ...) - remove all the dead code ifdefed'out with #if 0 - port your patches to 2.6.39 at least, 3.0 would be even better - remove all the unnecessary hacks introduced by patches-2.6.30, they are not required - clarify the license of the tools located in image/imgtools, they do not seem to be open source (they have no license at all) Thank you very much. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Image command line hack question
Hello all, I'm currently working on rtl8196 port, and those weird guys from realtek implemented there a different architecture rlx in kernel. Basically, much is borrowed from mips, but small differences here and there are present. I applied openwrt command hack to rlx, however, that didn't work out of the box. To get patch-cmdline actually patch rlx's vmlinux I had to widen the SEARCH_SPACE ( http://invyl.ath.cx/cgit/cgit.cgi/openwrt/commit/?id=38a13e566f179a12803a391ca941cad1f806db08 ). The next thing was, that despite the image gets patched, and I see the correct text hexdump'ing the image, the kernel command line stays the same. Looks like some other place needs to get patched, but I just can't firure where to look. Any ideas? Thanks in advance. I have now fixed the image packing for initial support for different boards, and, hopefully I'll get spi flash up&running next week. What should the state of the port be, before it's ok to send in the patches to the trunk? :) Regards, Andrew ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
