[FFmpeg-devel] mutlithreading in ffmpeg?

Frank Barchard fbarchard at google.com
Sat Mar 19 02:02:08 CET 2011

On Fri, Mar 18, 2011 at 5:33 PM, Thomas Worth <dev at rarevision.com> wrote:

> On Fri, Mar 18, 2011 at 7:31 AM, Michael Niedermayer <michaelni at gmx.at>
> wrote:
> > On Thu, Mar 17, 2011 at 04:10:58PM -0700, Thomas Worth wrote:
> >> >> There is ffmpeg-mt for frame level multithreaded decoding.
> >> >> http://gitorious.org/ffmpeg/ffmpeg-mt
> >> >> It would be nice to see that integrated into mainline ffmpeg.
> >> >> Its quite effective, scales nicely to whatever number of cores you've
> got
> >> >> and not sensitive to what to tool was used to create the content.
> >> >
> >> > It will be integrated soon.
> >>
> >> Hopefully you guys can fix the seeking problem with the H.264 decoder
> >> before then... hint, hint ;-)
> >
> > which issue number on the bug tracker is that?
> I didn't file a bug report in case I was overlooking something.
> However, I've spent some time with this and I am pretty sure it's a
> problem with multi-threaded decoding. Anyway, I put together a simple
> page that explains it in case it's a problem with my code:
> http://rarevision.com/ffmpeg-mt/

One reason it would be good to get ffmpeg-mt changes integrated, is that
bugs specific to 'mt' don't have a formal process.
I think theres a minor bug in ffmpeg-mt theora too.  Its reproducible in
webkit layout tests.  It doesn't happen in ffmpeg.
ffmpeg-mt doesnt have the fate builds, bug tracking, maillist/codereview

My #1 MT request would be vp8.  h264 and vorbis work great.  vp8 would round
out the formats used by browsers.
And consider MJPG (for cameras) and audio formats, on multicore arm, as well
as x86.

Now that ffmpeg is git, it should be easier to merge in changes from

More information about the ffmpeg-devel mailing list