> On Mon, Feb 25, 2013 at 10:26 PM, Dan Dennedy <d...@dennedy.org> wrote:
>> On Mon, Feb 25, 2013 at 10:20 PM, Dan Dennedy <d...@dennedy.org> > wrote: >>> On Mon, Feb 25, 2013 at 8:45 PM, Brian Matherly > <pez4br...@yahoo.com> wrote: >>>> Dan, >>>> >>>> I added a new module: avsync. It has one producer and one consumer. > The producer generates a stream with a classic blip/flash pattern. The > consumer > attempts to detect the blip/flash and calculate the audio/video sync. The > consumer will report the caluclated lipsync in milliseconds. A positive > number > indicates that audio leads video. A negative number indicates that audio lags > video. >>>> > [,,,] >>>> melt blipflash -consumer libdv:test.dv >>>> melt -silent test.dv -consumer blipflash >>>> avsync = -40.00 >>>> >>> >>> It is interesting to note that >>> >>> melt blipflash -consumer libdv:test.dv >> >> excuse me, I meant >> melt -silent libdv:test.dv -consumer blipflash >> >> using the libdv producer instead of avformat. >> >>> gives 0.00, which lends itself to a possible off-by-one error in the >>> avformat producer since this is PAL, which is 40ms per frame. >> >> I started to look into this, but like the other isolation problem, now >> I am not sure whether to look at audio or video initially! > > I created a blipflash DV with frame numbers: > melt blipflash -attach dynamictext:#frame# bgcolour=white -consumer > libdv:test.dv > > Then, I generated an image sequence with the libdv producer: > melt -silent libdvtest.dv -consumer avformat:test-%04d.jpg progressive=1 > > It looks fine. Then, using the avformat producer: > melt -silent test.dv -consumer avformat:test-%04d.jpg progressive=1 > > The result shows frame 0 followed by frame 2! > > Now, applying an in point: > melt -silent test.dv in=5 -consumer avformat:test-%04d.jpg progressive=1 > > test-0001.jpg shows frame# 6 instead of 5. > > Off-by-one in the video handling of the avformat producer. Nice! It looks like the module has been useful already. I Hope I didn't just create a whole bunch of work for you :) My plan was to try to script some automated tests to run weekly on the build server. That way we would know if any avsync regressions occurred. But it didn't occur to me that we might have to fix up some producers/consumers. My plan was to use +/-3ms as my pass/fail criteria (hence my previous comment). But maybe it would make more sense to use one frame duration - at least until everything gets dialed in. When you run "melt -silent", do you use CTL-C to stop it? Is there any way to tell melt to exit after x frames? ~BM ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
