Thread: [Mlt-devel] flv - small sync, minutes of invalid
Brought to you by:
ddennedy,
lilo_booter
From: Carl K. <ca...@pe...> - 2009-09-27 21:45:33
|
I made a red/blue test flv, uploaded to blip, it plays perfectly: http://carlfk.blip.tv/file/2650272/ nothing new here, but if you want the details, I am setting the description to the melt and .mlt. I am not escaping the xml right, so it doesn't show up, but it's in the source. So I used the 'same thing' on a talk video. there is a slight sync problem about 3 seconds after 20 min, and there is about 8 minutes of "INVALID" on the screen. http://blip.tv/file/2651947 <mlt> <producer id="title" in="0" out="149" resource="title.png" /> <producer id="producer119" resource="/media/pycon25wed/Videos/veyepar/DjangoCon/djc09/dv/Holladay/2009-09-08/12:25:25.dv" /> <producer id="producer125" resource="/home/carl/Videos/veyepar/DjangoCon/djc09/dv/Holladay/2009-09-08/13:01:55.dv" /> <playlist id="playlist0"> <entry id="clip113" in="0" out="999999" producer="producer119" /> <entry id="clip114" in="0" out="999999" producer="producer125" /> <filter from="1" mlt_service="channelcopy" to="0" /> <filter max_gain="30" mlt_service="volume" normalise="28" /> </playlist> <playlist id="playlist1"> <entry producer="title" /> </playlist> <tractor id="tractor0"> <multitrack> <track producer="playlist0" /> <track producer="playlist1" /> </multitrack> <transition a_track="1" b_track="0" in="100" mlt_service="luma" out="149" /> </tractor> </mlt> #!/bin/bash -x BASE=red_blue BASE=veyepar OUTDIR=~/a SOURCE=$BASE.mlt TARGET=$OUTDIR/$BASE-3-mlt-trunk.flv cat $SOURCE cat $SOURCE $0 > $OUTDIR/mlt.log melt --version 2>> $OUTDIR/mlt.log time melt -verbose -profile dv_ntsc $SOURCE -consumer avformat:$TARGET \ acodec=libmp3lame ab=128k ar=44100 vcodec=flv minrate=0 b=600k progressive=1 # acodec=libvorbis ab=128k ar=44100 vcodec=libtheora minrate=0 b=600k # f=dv pix_fmt=yuv411p s=720x480 # -vcodec flashsv MLT melt 0.4.5 Copyright (C) 2002-2009 Ushodaya Enterprises Limited <http://www.mltframework.org/> This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Carl K |
From: Dan D. <da...@de...> - 2009-09-28 19:02:09
|
On Sun, Sep 27, 2009 at 2:45 PM, Carl Karsten <ca...@pe...> wrote: > I made a red/blue test flv, uploaded to blip, it plays perfectly: > http://carlfk.blip.tv/file/2650272/ nothing new here, but if you > want the details, I am setting the description to the melt and .mlt. > I am not escaping the xml right, so it doesn't show up, but it's in > the source. > > So I used the 'same thing' on a talk video. there is a slight sync > problem about 3 seconds after 20 min, and I wonder if you are running into a problem with DV unlocked audio. You can search to learn more, but Kino users had similar problems with footage captured from certain devices. Then, I added some special handling in Kino for this problem, and it resolved nearly all complaints. So, to test this hypothesis, you can load the source DV file into Kino, do no editing, and export it as a new DV file leaving the resample audio checkbox enabled. This process converts it from unlocked to locked and uses resampling to interpolate the missing PCM data. Then, use the output of that in your mlt and script and see if resolved it. > there is about 8 minutes of "INVALID" on the screen. investigate that on your own, please -- +-DRD-+ |
From: Carl K. <ca...@pe...> - 2009-09-29 04:56:43
|
On Mon, Sep 28, 2009 at 2:01 PM, Dan Dennedy <da...@de...> wrote: > On Sun, Sep 27, 2009 at 2:45 PM, Carl Karsten <ca...@pe...> wrote: >> I made a red/blue test flv, uploaded to blip, it plays perfectly: >> http://carlfk.blip.tv/file/2650272/ nothing new here, but if you >> want the details, I am setting the description to the melt and .mlt. >> I am not escaping the xml right, so it doesn't show up, but it's in >> the source. >> >> So I used the 'same thing' on a talk video. there is a slight sync >> problem about 3 seconds after 20 min, and > > I wonder if you are running into a problem with DV unlocked audio. You > can search to learn more, but Kino users had similar problems with > footage captured from certain devices. Then, I added some special > handling in Kino for this problem, and it resolved nearly all > complaints. So, to test this hypothesis, you can load the source DV > file into Kino, do no editing, and export it as a new DV file leaving > the resample audio checkbox enabled. This process converts it from > unlocked to locked and uses resampling to interpolate the missing PCM > data. Then, use the output of that in your mlt and script and see if > resolved it. Well, you are onto something. It did get rid of the audio sync problem when blip converted it. It also got rid of the audio anytime p-n-p was enabled, which is most of the time. Guessing this is a dvswitch problem, especially given I reported a bug on it: "when using playdv to monitor mix, audio cuts out when pnp is enabled." This is not the same buggy code that was causing the other audio problem, but it may be the same mistake implemented in 2 places. Ben agreed with your diagnoses of the first bug, so I didn't try this: """ Can you locate that line in libdv/audio.c I mentioned, change it, and test it? libdv/audio.c, line 485, from: return dv_is_normal_speed(decoder); to: return(TRUE); """ Think it might help the sync problem? I am going to give it a shot, but getting your input will help me prioritize this thread. -- Carl K |
From: Dan D. <da...@de...> - 2009-09-29 18:36:21
|
On Mon, Sep 28, 2009 at 9:56 PM, Carl Karsten <ca...@pe...> wrote: > On Mon, Sep 28, 2009 at 2:01 PM, Dan Dennedy <da...@de...> wrote: >> On Sun, Sep 27, 2009 at 2:45 PM, Carl Karsten <ca...@pe...> wrote: >>> I made a red/blue test flv, uploaded to blip, it plays perfectly: >>> http://carlfk.blip.tv/file/2650272/ nothing new here, but if you >>> want the details, I am setting the description to the melt and .mlt. >>> I am not escaping the xml right, so it doesn't show up, but it's in >>> the source. >>> >>> So I used the 'same thing' on a talk video. there is a slight sync >>> problem about 3 seconds after 20 min, and >> >> I wonder if you are running into a problem with DV unlocked audio. You >> can search to learn more, but Kino users had similar problems with >> footage captured from certain devices. Then, I added some special >> handling in Kino for this problem, and it resolved nearly all >> complaints. So, to test this hypothesis, you can load the source DV >> file into Kino, do no editing, and export it as a new DV file leaving >> the resample audio checkbox enabled. This process converts it from >> unlocked to locked and uses resampling to interpolate the missing PCM >> data. Then, use the output of that in your mlt and script and see if >> resolved it. > > Well, you are onto something. It did get rid of the audio sync > problem when blip converted it. I am adding near the top of my MLT ToDo list, to work on better support for unlocked DV audio. I can not jump on it right away, but it is rather important. I am not sure I can make it automatic. I might have to make it something like Replay Gain normalization. That means you would do two passes: the first pass will report a correction value that you supply to a filter for the second pass. -- +-DRD-+ |
From: Dan D. <da...@de...> - 2009-11-21 06:23:37
|
On Tue, Sep 29, 2009 at 10:36 AM, Dan Dennedy <da...@de...> wrote: > On Mon, Sep 28, 2009 at 9:56 PM, Carl Karsten <ca...@pe...> wrote: >> On Mon, Sep 28, 2009 at 2:01 PM, Dan Dennedy <da...@de...> wrote: >>> On Sun, Sep 27, 2009 at 2:45 PM, Carl Karsten <ca...@pe...> wrote: >>>> I made a red/blue test flv, uploaded to blip, it plays perfectly: >>>> http://carlfk.blip.tv/file/2650272/ nothing new here, but if you >>>> want the details, I am setting the description to the melt and .mlt. >>>> I am not escaping the xml right, so it doesn't show up, but it's in >>>> the source. >>>> >>>> So I used the 'same thing' on a talk video. there is a slight sync >>>> problem about 3 seconds after 20 min, and >>> >>> I wonder if you are running into a problem with DV unlocked audio. You >>> can search to learn more, but Kino users had similar problems with >>> footage captured from certain devices. Then, I added some special >>> handling in Kino for this problem, and it resolved nearly all >>> complaints. So, to test this hypothesis, you can load the source DV >>> file into Kino, do no editing, and export it as a new DV file leaving >>> the resample audio checkbox enabled. This process converts it from >>> unlocked to locked and uses resampling to interpolate the missing PCM >>> data. Then, use the output of that in your mlt and script and see if >>> resolved it. >> >> Well, you are onto something. It did get rid of the audio sync >> problem when blip converted it. > > I am adding near the top of my MLT ToDo list, to work on better > support for unlocked DV audio. I can not jump on it right away, but it > is rather important. I am not sure I can make it automatic. I might > have to make it something like Replay Gain normalization. That means > you would do two passes: the first pass will report a correction value > that you supply to a filter for the second pass. > Carl, I just found and fixed a math bug that was causing the MLT avformat producer to drop some extra audio samples. This would account for some a/v sync drift as well as some crackling in the output. There will be a new release by the end of the month. -- +-DRD-+ |
From: Carl K. <ca...@pe...> - 2009-11-21 06:44:58
|
On Sat, Nov 21, 2009 at 12:23 AM, Dan Dennedy <da...@de...> wrote: > On Tue, Sep 29, 2009 at 10:36 AM, Dan Dennedy <da...@de...> wrote: >> On Mon, Sep 28, 2009 at 9:56 PM, Carl Karsten <ca...@pe...> wrote: >>> On Mon, Sep 28, 2009 at 2:01 PM, Dan Dennedy <da...@de...> wrote: >>>> On Sun, Sep 27, 2009 at 2:45 PM, Carl Karsten <ca...@pe...> wrote: >>>>> I made a red/blue test flv, uploaded to blip, it plays perfectly: >>>>> http://carlfk.blip.tv/file/2650272/ nothing new here, but if you >>>>> want the details, I am setting the description to the melt and .mlt. >>>>> I am not escaping the xml right, so it doesn't show up, but it's in >>>>> the source. >>>>> >>>>> So I used the 'same thing' on a talk video. there is a slight sync >>>>> problem about 3 seconds after 20 min, and >>>> >>>> I wonder if you are running into a problem with DV unlocked audio. You >>>> can search to learn more, but Kino users had similar problems with >>>> footage captured from certain devices. Then, I added some special >>>> handling in Kino for this problem, and it resolved nearly all >>>> complaints. So, to test this hypothesis, you can load the source DV >>>> file into Kino, do no editing, and export it as a new DV file leaving >>>> the resample audio checkbox enabled. This process converts it from >>>> unlocked to locked and uses resampling to interpolate the missing PCM >>>> data. Then, use the output of that in your mlt and script and see if >>>> resolved it. >>> >>> Well, you are onto something. It did get rid of the audio sync >>> problem when blip converted it. >> >> I am adding near the top of my MLT ToDo list, to work on better >> support for unlocked DV audio. I can not jump on it right away, but it >> is rather important. I am not sure I can make it automatic. I might >> have to make it something like Replay Gain normalization. That means >> you would do two passes: the first pass will report a correction value >> that you supply to a filter for the second pass. >> > > Carl, I just found and fixed a math bug that was causing the MLT > avformat producer to drop some extra audio samples. This would account > for some a/v sync drift as well as some crackling in the output. There > will be a new release by the end of the month. Thanks for keeping me posted. -- Carl K |