Yes, thanks qyot27.
Re-compile x264 again after FFmpeg.
I understand now.
Yes, thanks qyot27.
Re-compile x264 again after FFmpeg.
I understand now.
I updated the guide on step 7 with a link to qyot27's explanation. You can give it a try with the most simple of examples:
Some advantages of using this method:Code:x264 input.foo -o output.mkv
- avoids a layer of complexity and potential bugs by encoding directly with x264 instead of through ffmpeg
- access to specific x264 options that may be missing in ffmpeg
- no more named pipes to feed input to x264
Disadvantages:
- slightly more compiling
- have to deal with audio and subsequent muxing separately (ignoring stuff like L-SMASH)
- lacks many of the filters that are included in ffmpeg
I guess someone could ppa this, though to do so properly they'd need to test current apps that depend on the shared libs & if there are any issues then provide new builds of those apps.
Can't see ubuntu/debian offering anymore than 1 or the other - the last I checked they both use the same names for the libs which if so would be problematic
(I've somewhat stopped paying attention to who uses what, be it a how-to, mplayer, mplayer2 ect. ect.
An interesting conversation may be between a ffmpeg (real) dev and Reinhard Tartler as to the reasons to use libav
(what I did find a pita was that when searching ffmpeg in synaptic no shared libs are found
This is because while libav still uses the 'ffmpeg' name, ffmpeg is not ever mentioned in the lib descriptions
Hi
Just a little note for anyone interested, my little install / update script, that handily automates fakeoutdoorsman's awesomeness here is finally getting a major update, so it follows the current guide.
It also combines the install and update scripts into one and also has it's own (very basic) auto-update function.
The new version can be found here in the next couple of days:
http://code.google.com/p/x264-ffmpeg-up-to-date/
And just another little update to say the new script has now been released: http://code.google.com/p/x264-ffmpeg-up-to-date/
It supports:
- Natty, Maverick, Lucid, Hardy
- Initial install and subsequent updates all in one script
- Ability to check and then update the script if there is a new version available
- A basic config file so it can be run with no user interaction via cron
I'll be adding a new feature (hopefully tomorrow) so it will only download and build from source if git says there is a newer version.
I'll try to keep this version updated, but as it took me a year to update the old version, due to work and kids, don't hold your breath.
Thanks for the update. I haven't tried the script myself, but you may want to consider adding --depth 1 to your FFmpeg git command such as:
From man git-clone:Code:git clone --depth 1 git://git.videolan.org/ffmpeg
This would currently create a ~40 MB ffmpeg directory, but if --depth 1 is omitted it would end up ~80 MB.--depth <depth>
Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches.
I debated adding it to this guide, but once in a while a checkout to a specific commit is suggested to avoid bugs and I don't think that can be done with such a shallow clone. I think it would be fine for most users though. I wish I was more familiar with Git. Indecision...
Pardon my curiousity - and maybe I should appologize for not reading the whole thread first to find whether this was asked before or not.
From a complete newbie's perspective (regarding video encoder/decoder stuff), is there any visible differences in playback quality between using standard packages and compiling them yourself?
Like maybe reducing video artifacts or smoother color gradation and so on?
Short answer: it depends. Most users probably wouldn't notice a difference, but of course it depends on what the user is doing. However, compiling the latest source can add new features, fix bugs (and introduce new bugs), and is customizable to your needs.
If you're using ffmpeg by itself and doing a lot of encoding (especially with a more modern and developmentally active encoder such as x264), then you may want to compile. Or if you're experiencing a known bug the newest source may already contain a fix.
If you're using something from the repository that depends on ffmpeg, then you'll want to stick with that. Of course you could have both the repo ffmpeg and a new compiled one, but that would require a few simple changes to the guide.
Note that Ubuntu doesn't use ffmpeg (the binary) from FFmpeg (the project) anymore as of Natty. The maintainer switched to libav which is a recent fork of FFmpeg.
Thank you.
I'm planning to upgrade my DSLR to a more capable one with HD video capability so I'll have to learn about video editing and encoding when the time comes. But I think I'll stick with prebuild packages from the repository for now.
I can see the advantage, but if it risks causing the occasional issue, it might be worth avoiding it. Plus, since the user is already building from source, which takes quite a while, and with the fast download speeds available these days, I think it best to leave as is for now.
However, if you add it to your instructions, I'll add it to my script
Bookmarks