Can we upgrade ffmpeg?
Forum rules
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.
*******************************
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.
*******************************
Can we upgrade ffmpeg?
While the memory leak is first and foremost our biggest problem right now, I'd like to see if we can upgrade to a new ffmpeg revision. The revision we're using is r6324 from the ffmpeg Subversion trunk.
I tried using the latest revision of ffmpeg, r7433, and this fixes problems I saw with ffmpeg 2-pass encoding in the MinGW/Windows and Linux builds.
In short, we need the newest ffmpeg for Windows and Linux for them to work with 2-pass ffmpeg, but we need building and encoding testing on the MacOSX side to make sure there's no regressions.
Thoughts?
I tried using the latest revision of ffmpeg, r7433, and this fixes problems I saw with ffmpeg 2-pass encoding in the MinGW/Windows and Linux builds.
In short, we need the newest ffmpeg for Windows and Linux for them to work with 2-pass ffmpeg, but we need building and encoding testing on the MacOSX side to make sure there's no regressions.
Thoughts?
Re: Can we upgrade ffmpeg?
Sorry, been focusing on the mem leak this evening so I haven't had a chance to test it out yet.mirkwood wrote:we need building and encoding testing on the MacOSX side to make sure there's no regressions.
Re: Can we upgrade ffmpeg?
No problem, the mem leak is more urgent.jbrjake wrote:Sorry, been focusing on the mem leak this evening so I haven't had a chance to test it out yet.mirkwood wrote:we need building and encoding testing on the MacOSX side to make sure there's no regressions.
I just noticed that when running the MinGW build there's a warning that ffmpeg prints out saying that "the compiler did not align the stack variables and libavcodec may run slow or crash", so this needs more testing on MinGW!
At the moment though, given all the other problems I have with MinGW, I'm going to try again with the Cygwin build with the new ffmpeg and see how that goes. Maybe x264 encoding kept crashing on the Cygwin build because of the memory leak since I was always using .mp4 output.
Cygwin has memalign(), so it doesn't need the hack. However, MinGW does need the hack since it doesn't provide memalign(), but the alignment problem happens with both Cygwin and MinGW, so I don't really think it's the real memalign vs memalign-hack.
It basically looks like gcc on Cygwin/MinGW doesn't support the alignment directive ffmpeg is using, though there may be a compiler flag that could get this to work, I just haven't done much testing here yet.
It basically looks like gcc on Cygwin/MinGW doesn't support the alignment directive ffmpeg is using, though there may be a compiler flag that could get this to work, I just haven't done much testing here yet.
In the future, could you please run svn commits by everyone else before you change a major component *while* we're trying to fix a major memory leak *with* said component? Especially because this upgrade doesn't fix the memory leak, and, as mirkwood explained earlier today, it needs more testing for win32 before we can be sure that fixing 2-pass doesn't break something else.prigaux wrote:I upgraded ffmpeg to revision 7444 in the svn.
Remove your ffmpeg.tar.gz file from your contrib folder to use it.
Like any other change (newer x264, johnallen's threading modification, the new GUI, etc) library upgrades should have been held off until after 0.7.2, per *the consensus we all came to together in the roadmap to 0.7.2 thread*...
All, let's not get in the habit of [Censored] off good developers. prigauxs' update to the newest ffmpg appears sound to me. The latest version could have fixed the memory leak. After all it's a leak in ffmpegs' libs, not ours.
As he states, we can goback fairly easily.
prigaux, don't leave us now. We need all the help we can get.
As he states, we can goback fairly easily.
prigaux, don't leave us now. We need all the help we can get.
I've taken the liberty of creating a branch for development of the future release, 0.7.3 of HB. I suggest we try to fix the ffmpeg issue within the trunk, then release 0.7.2. All other development can be commited to the 0.7.3 branch. Once we release 0.7.2, we can merge 0.7.3 back into the trunk.
prigaux, I would like to have your work on using the latest contrib libs. So can you commit these changes to the branch? I'd also like to see if we can make use of some of the work titer did in his branch. Personally I would like to use the fix where he builds everything from within XCode. This makes it easier for us to debug libhb from within XCode.
We also need to be adamant about getting 0.7.2 released. Not everyone can play in the new branch. We need some people tracking down this ffmpeg issue for the release.
prigaux, I would like to have your work on using the latest contrib libs. So can you commit these changes to the branch? I'd also like to see if we can make use of some of the work titer did in his branch. Personally I would like to use the fix where he builds everything from within XCode. This makes it easier for us to debug libhb from within XCode.
We also need to be adamant about getting 0.7.2 released. Not everyone can play in the new branch. We need some people tracking down this ffmpeg issue for the release.
I would say the Windows side seems ok, even with the alignment problem. New code was added since our last revision of ffmpeg to actually check the alignment during runtime, so I have a feeling our old ffmpeg probably has the same alignment problem with Cygwin or MinGW gcc.
What I may do is add a patch to our contrib folder to get rid of that alignment warning message that the ffmpeg libavcodec prints out, otherwise the HandBrake forums will be flooded with Windows users asking what the deal with that warning message is.
What I may do is add a patch to our contrib folder to get rid of that alignment warning message that the ffmpeg libavcodec prints out, otherwise the HandBrake forums will be flooded with Windows users asking what the deal with that warning message is.
The Cygwin/Windows patch is needed to build correctly. I'll generate a new patch for this version and uncomment the patch for Cygwin in the Jamfile.johnallen wrote:I updated the 0.7.3 branch to use r618 of x264. I also removed (by commenting out) the patch for intel macs and windows platforms. If someone realizes we still need the patch, feel free to uncomment the lines int the Jamfile.
The libdvdread patch is needed to get rid of that annoying ASSERT message that will be printed a zillion times.
If you compile and build without the patch and it doesn't print the error, then I guess we can comment out the patch for now, but otherwise please keep the patch updated.
And PLEASE, folks, don't just willy nilly upgrade stuff without going through the patches and making sure other people can get the things to compile on other platforms besides OSX.
If you compile and build without the patch and it doesn't print the error, then I guess we can comment out the patch for now, but otherwise please keep the patch updated.
And PLEASE, folks, don't just willy nilly upgrade stuff without going through the patches and making sure other people can get the things to compile on other platforms besides OSX.