On Sun, 2009-01-04 at 20:19 +0000, Andrew Church wrote: > I forgot to comment on this in my previous message, but would it resolve > the issue if we enforced singlethreaded filtering? If so, I think that > would probably be the best idea for 1.1.0, rather than throwing in a > whole new block of code right before release. For the majority of use > cases, I imagine encoders could make better use of multiple threads than > filters could anyway.
Ok, looks like I've fixed the bug using old framebuffer code. It was actually a set of bugs: 1 bug in tc_import_threads_cancel: hang if import threads aren't already done. 1 bug in tc_framebuffer_flush(): cond_wait if no frames are avalaible, that fine during normal operation, but is no good *in flush*. 1 bug in frame_threads code: start flag is not set on (re)start. Using --psu_mode seems to work fine on my box now. No regression spotted so far. So, the wisest thing now looks to be revert the newframebuffer patchset on 1.1.x, apply a few pending patches (mov handling, slot change for transform/stabilize) and roll out 1.1.0 RC 5. And, if noone complains, roll 1.1.0 final on schedule (20090118). +++ Anyway, I'm still firmly convinced the newframebuffer patchset is a serious improvement over current code, and I'll keep it on HEAD, and go ahead with sliding window implementation. The only drawback is until the sliding window code gets committed, HEAD will be broken. But reverting the framebuffer code in HEAD is not an option for me. OK, that's the plan. I'll go ahead tomorrow (20080105) and release if noone complains. Bests, -- Francesco Romani // Ikitt http://fromani.exit1.org ::: transcode homepage http://tcforge.berlios.de ::: transcode experimental forge
