HandBrake

I use IHB almost exclusively. It leaks as bad as HB.

probably should not use libmf. Instead libmediafork.

Is there such a thing as a DVD database we can use to lookup info about the DVD when we scan the DVD?

Unfortunately I don't think there is going to be an easy fix for our upcoming planned release of 0.7.2. (if we are still going to do that) I do plan on trying some long term, rather invasive changes in the coming weeks within my own working directory. FYI, I typically work long hours during the week...

The more I look through the code, the more I am concerned about the architecture titer choose. Don't get me wrong, he has some great modularity when accessing the various codecs. But I think the flaw is having the video and audio decompression and recompression on seperate threads. The muxer would p...

My only guess is if the user choose a smaller frame rate for the output than exists on the DVD.

Look in sync.c for SyncVideo and SyncAudio functions.

I changed the MuxerFunc here: buf = hb_fifo_get( track->fifo ); if(buf) { if( job->pass != 1 ) { if(buf->start < mux->pts) { hb_log("track:%s, OFL Start:%"PRId64", Current:%"PRId64", Stop:%"PRId64"", track->name, buf->start, mux->pts, buf->stop); } m->mux( m, ...

More info on this issue. As rhester suggested the problem is not libavformats' av_interleaved_write_frame. It specifically states in the documentation that it can use extensive memory. I have diagnosed the problem to GetTrack in the muxer. GetTrack returns the next audio or video sample ready for wr...

benlake, the contrib lib updates are only in the branch. The trunk is what we should release.

Even the library may need a new name. libchickensandwich instead of libhb. And what about IHB?

how is hb_thread_init implemented in the windows build? Are the thread priorities being used?

That's the idea of the branch. The objective is to get our contribs updated to the latest version. Every dev will need to confirm that their platforms compile is still working.

prigaux, do we still need the libdvdread patch:

patch-libdvdread.patch?

I'm in.

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.

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. pri...

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. ...

I commited a change that may help in finding the ffmpeg leak.

-added call to av_log_set_level in hb_init_real based on value of verbose param.
-makes ffmpeg debbuging level the same as ours.
-will be useful while finding the memory leak issue.

I commited the following in an attempt to clean up HB and IHB in preperation for the release. -barber pole progress bar is shown during the "muxing" phase and no longer show 0.0%. applies to both HB and IHB -When we can figure out how to get a percent complete, we can use that. -IHB now us...

I ordered one as well.

from utils.c in libavformat: (note the reference to lots of memory) /** * Writes a packet to an output media file ensuring correct interleaving. * * The packet must contain one audio or video frame. * If the packets are already correctly interleaved the application should * call av_write_frame() ins...

OK I found the beginning of the trail.... in muxcommon.c, comment out this line: m->mux( m, track->mux_data, buf ); and start the conversion. My memory usage hovers around 30-32 MB and no longer increases as before. EDIT: this call goes to muxmp4.c: MP4Mux, which calls down to ffmpegs libavformat. I...

another point I just found. Doing a Cntl^C is not a valid test. Looks like it just tells libhb to drop everything and stop. So we WILL see that the fifos have data in them when we Cntl^C. If, instead you let it complete the conversion, they should show empty.

dynaflash, remember the "Muxing" being shown is the same as the 100% hang issue we have always had. It just shows "Muxing" instead of sitting there saying nothing. av_write_trailer in mp4end is still taking several minutes to close the file. Just remember this is not new.

anything is possible, but.... The change in fifo.c was the addition of a method for letting us now what percent full the fifo is. Only thing available prior was method to indicate that it was full. I left the method in fifo.c, but no longer use it. reader.c change was reverted back. Change was to se...