From: Dâniel F. <fr...@gm...> - 2012-02-07 09:46:42
|
Are you planning to add a feature to automatically sync external audio? I always record with my Zoom H2N audio recorder and it's very boring to drag the audio track exactly at the exact position of the original audio track from the camera. I know Final Cut does have this feature. When will Kdenlive be able to do this, too? I bet a lot of users will enjoy this... and this will attract even more users to kdenlive. Thanks. Ps: since the recent git has stabilize feature... you could add audio auto-sync too. Ps2: I imagine it's not difficult at all... just compare the 2 tracks ("audio" and "original video with audio") and position the audio track according to the original track. Then we can mute the original audio and that's it. -- Linux 3.2.2: Saber-toothed Squirrel http://www.youtube.com/DanielFragaBR |
From: Stefan N. <sna...@ya...> - 2012-02-07 19:13:48
|
Hey there - again. I recently got the SVN-PPA for Ubuntu of KDEnlive and the current version of KDEnlive. I might repeat myself - but it's still not really usable for me. The recording option ... I think it works with Terratec Grabby (Video4Linux2) - why don't you let the user freely decide the codecs and formats in which he wants to record.?? And the second point: AVCHD. (H264). I always record in H264 for it resulting in smallest filesizes with high CPU Load while decoding. :D I see it's a pretty hard video codec, but as far as I unterstand it there is one image fully defined and then only the changes based on the one full picture. If there is a change, that is too big or o heavy there will be another full frame. (i-Frame (????)) I see that even Adobe Premiere has its problems with this codec, but it is in my humble opinion the best one for sake of my harddiskdrives. Adobe (apparently) searched bad to the last i-frame and builds all later changes on top of it ... so it is pretty slow loading a random position in a video. But KDEnlive is too slow to accomplish a nice editing envirornment. The video in Timeline is too slow --- for 5 seconds then there is ja jump to the real position after the 5 seconds. I can understand it hanging for a while, when I clicked on a later point in time ... searching for last iframe ... but if it is always so slow... that's just unusable ... I hope this critics are not taken personally - And maybe I helped you to make an even better editing experience for video cutters all around the world. ;) (nice sentence, ain't it) Regards Stefan Naumann |
From: jb <jb...@kd...> - 2012-02-07 20:32:07
|
On Tuesday 07 February 2012 19:13:41 Stefan Naumann wrote: > Hey there - again. > > I recently got the SVN-PPA for Ubuntu of KDEnlive and the current version of > KDEnlive. I might repeat myself - but it's still not really usable for me. > The recording option ... I think it works with Terratec Grabby > (Video4Linux2) - why don't you let the user freely decide the codecs and > formats in which he wants to record.?? If you have the last version of Kdenlive, recording codecs and formats are fully customizable. In Kdenlive settings > Capture > FFmpeg, there is an "Encoding Profile" combobox which lets you decide the ffmpeg encoding parameters. You can click on the configure button next to it to manually enter whatever parameters you want. > And the second point: AVCHD. (H264). I always record in H264 for it > resulting in smallest filesizes with high CPU Load while decoding. :D I see > it's a pretty hard video codec, but as far as I unterstand it there is one > image fully defined and then only the changes based on the one full > picture. If there is a change, that is too big or o heavy there will be > another full frame. (i-Frame (????)) I see that even Adobe Premiere has its > problems with this codec, but it is in my humble opinion the best one for > sake of my harddiskdrives. Adobe (apparently) searched bad to the last > i-frame and builds all later changes on top of it ... so it is pretty slow > loading a random position in a video. But KDEnlive is too slow to > accomplish a nice editing envirornment. The video in Timeline is too slow > --- for 5 seconds then there is ja jump to the real position after the 5 > seconds. I can understand it hanging for a while, when I clicked on a later > point in time ... searching for last iframe ... but if it is always so > slow... that's just unusable ... I hope this critics are not taken > personally - And maybe I helped you to make an even better editing > experience for video cutters all around the world. ;) (nice sentence, ain't > it) As explained by Simon, you can't expect fast h264 video editing in the near future, it is anyways in the hands of the FFmpeg project, we cannot make it better in Kdenlive. Proxy clips should help you: In the project settings, enable proxy clips, and to have them automatically created when adding a new clip, also enable the "Generate for videos larger than..." option. You can also manually enable / disable a proxy clip from the context menu of the project tree. Encoding options for the proxy clips are fully customizable from Kdenlive Settings > Project Defaults > Proxy Clips > Encoding Profile That should make Kdenlive usable for most users. regards jb |
From: Simon A. E. <sim...@gm...> - 2012-02-07 19:26:32
|
On 02/07/2012 08:13 PM, Stefan Naumann wrote: > Hey there - again. ------- 8< ----- > And the second point: AVCHD. (H264). I always record in H264 for it > resulting in smallest filesizes with high CPU Load while decoding. :D I > see it's a pretty hard video codec, but as far as I unterstand it there > is one image fully defined and then only the changes based on the one > full picture. If there is a change, that is too big or o heavy there > will be another full frame. (i-Frame (????)) I see that even Adobe http://en.wikipedia.org/wiki/Group_of_pictures H.264 not only uses P-frames (which is what you described; basically they are predicted from preceding I-frames and the I-frame data corrects the error that is created hereby) but also B-frames which are predicted from anywhere, like from the last I-frame or the next P-frame. All very CPU intense, therefore the decoding algorithm is often implemented in hardware today (e.g. on the GPU or other chips like also on smartphones). > Premiere has its problems with this codec, but it is in my humble > opinion the best one for sake of my harddiskdrives. Adobe (apparently) > searched bad to the last i-frame and builds all later changes on top of > it ... so it is pretty slow loading a random position in a video. But > KDEnlive is too slow to accomplish a nice editing envirornment. The > video in Timeline is too slow --- for 5 seconds then there is ja jump to > the real position after the 5 seconds. I can understand it hanging for a > while, when I clicked on a later point in time ... searching for last > iframe ... but if it is always so slow... that's just unusable ... I > hope this critics are not taken personally - And maybe I helped you to > make an even better editing experience for video cutters all around the > world. ;) (nice sentence, ain't it) Actually not our problem since decoding is done by ffmpeg. H.264 decoding will probably never be fast done in software. We have proxy clips for this however. I have edited some projects with proxies already, works better than anything else. Note that you have to enable them in the project preferences, then you can right-click on your clips in the project tree and select «generate proxy» or so. Simon |
From: Stefan N. <sna...@ya...> - 2012-02-07 19:47:31
|
What? I have to "manually" create them? VLC does it way faster than KDEnlive ... there are some differences between the two projects, but I think VLC does it nicely whereas KDEnlive is pretty slow... And I don't see any indicator that it create VIDEO proxy clips... Audio-ones ... yes. But no Video proxies. ---------- Waren Sie schon auf: www.oettinger-games.net.tf . Helfen Sie mit. ________________________________ Von: Simon A. Eugster <sim...@gm...> An: Stefan Naumann <sna...@ya...>; For kdenlive developers <kde...@li...> Gesendet: 20:26 Dienstag, 7.Februar 2012 Betreff: Re: [Kdenlive-devel] AVCHD On 02/07/2012 08:13 PM, Stefan Naumann wrote: > Hey there - again. ------- 8< ----- > And the second point: AVCHD. (H264). I always record in H264 for it > resulting in smallest filesizes with high CPU Load while decoding. :D I > see it's a pretty hard video codec, but as far as I unterstand it there > is one image fully defined and then only the changes based on the one > full picture. If there is a change, that is too big or o heavy there > will be another full frame. (i-Frame (????)) I see that even Adobe http://en.wikipedia.org/wiki/Group_of_pictures H.264 not only uses P-frames (which is what you described; basically they are predicted from preceding I-frames and the I-frame data corrects the error that is created hereby) but also B-frames which are predicted from anywhere, like from the last I-frame or the next P-frame. All very CPU intense, therefore the decoding algorithm is often implemented in hardware today (e.g. on the GPU or other chips like also on smartphones). > Premiere has its problems with this codec, but it is in my humble > opinion the best one for sake of my harddiskdrives. Adobe (apparently) > searched bad to the last i-frame and builds all later changes on top of > it ... so it is pretty slow loading a random position in a video. But > KDEnlive is too slow to accomplish a nice editing envirornment. The > video in Timeline is too slow --- for 5 seconds then there is ja jump to > the real position after the 5 seconds. I can understand it hanging for a > while, when I clicked on a later point in time ... searching for last > iframe ... but if it is always so slow... that's just unusable ... I > hope this critics are not taken personally - And maybe I helped you to > make an even better editing experience for video cutters all around the > world. ;) (nice sentence, ain't it) Actually not our problem since decoding is done by ffmpeg. H.264 decoding will probably never be fast done in software. We have proxy clips for this however. I have edited some projects with proxies already, works better than anything else. Note that you have to enable them in the project preferences, then you can right-click on your clips in the project tree and select «generate proxy» or so. Simon |
From: Simon A. E. <sim...@gm...> - 2012-02-07 20:18:28
|
On 02/07/2012 08:47 PM, Stefan Naumann wrote: > What? I have to "manually" create them? VLC does it way faster than ??? > KDEnlive ... there are some differences between the two projects, but I > think VLC does it nicely whereas KDEnlive is pretty slow... And I don't VLC is just a player. Just one layer. No editing. > see any indicator that it create VIDEO proxy clips... Audio-ones ... > yes. But no Video proxies. http://userbase.kde.org/Kdenlive/Manual/Projects_and_Files/Clips > ---------- Waren Sie schon auf: www.oettinger-games.net.tf . Helfen Sie mit. > ------------------------------------------------------------------------ > *Von:* Simon A. Eugster <sim...@gm...> > *An:* Stefan Naumann <sna...@ya...>; For kdenlive developers > <kde...@li...> > *Gesendet:* 20:26 Dienstag, 7.Februar 2012 > *Betreff:* Re: [Kdenlive-devel] AVCHD > > On 02/07/2012 08:13 PM, Stefan Naumann wrote: > > Hey there - again. > ------- 8< ----- > > And the second point: AVCHD. (H264). I always record in H264 for it > > resulting in smallest filesizes with high CPU Load while decoding. :D I > > see it's a pretty hard video codec, but as far as I unterstand it there > > is one image fully defined and then only the changes based on the one > > full picture. If there is a change, that is too big or o heavy there > > will be another full frame. (i-Frame (????)) I see that even Adobe > > http://en.wikipedia.org/wiki/Group_of_pictures > H.264 not only uses P-frames (which is what you described; basically > they are predicted from preceding I-frames and the I-frame data corrects > the error that is created hereby) but also B-frames which are predicted > from anywhere, like from the last I-frame or the next P-frame. All very > CPU intense, therefore the decoding algorithm is often implemented in > hardware today (e.g. on the GPU or other chips like also on smartphones). > > > Premiere has its problems with this codec, but it is in my humble > > opinion the best one for sake of my harddiskdrives. Adobe (apparently) > > searched bad to the last i-frame and builds all later changes on top of > > it ... so it is pretty slow loading a random position in a video. But > > KDEnlive is too slow to accomplish a nice editing envirornment. The > > video in Timeline is too slow --- for 5 seconds then there is ja jump to > > the real position after the 5 seconds. I can understand it hanging for a > > while, when I clicked on a later point in time ... searching for last > > iframe ... but if it is always so slow... that's just unusable ... I > > hope this critics are not taken personally - And maybe I helped you to > > make an even better editing experience for video cutters all around the > > world. ;) (nice sentence, ain't it) > > Actually not our problem since decoding is done by ffmpeg. H.264 > decoding will probably never be fast done in software. > We have proxy clips for this however. I have edited some projects with > proxies already, works better than anything else. > Note that you have to enable them in the project preferences, then you > can right-click on your clips in the project tree and select «generate > proxy» or so. > > Simon > > > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > > > > _______________________________________________ > Kdenlive-devel mailing list > Kde...@li... > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel |
From: Ernie Z. <ern...@gm...> - 2012-02-07 23:39:03
|
Hi Daniel, Interesting feature suggestion. This could be a real attention grabber. But you mention that you imagine it not to be too difficult to achieve. How do you propose this to be true? Can you use an example? As of now FCPX has an API for this but the results are inconsistent. If Apple doesn't have it stable yet then I'd be a little skeptical of this being an easy task. On 02/07/2012 04:46 AM, Dâniel Fraga wrote: > Are you planning to add a feature to automatically sync > external audio? I always record with my Zoom H2N audio recorder and > it's very boring to drag the audio track exactly at the > exact position of the original audio track from the camera. > > I know Final Cut does have this feature. When will Kdenlive be > able to do this, too? > > I bet a lot of users will enjoy this... and this will attract > even more users to kdenlive. > > Thanks. > > Ps: since the recent git has stabilize feature... you could add > audio auto-sync too. > > Ps2: I imagine it's not difficult at all... just compare the 2 > tracks ("audio" and "original video with audio") and position the audio > track according to the original track. Then we can mute the original > audio and that's it. > |
From: Alexandre P. <ale...@gm...> - 2012-02-08 02:36:39
|
On Wed, Feb 8, 2012 at 3:39 AM, Ernie Zahn wrote: > Hi Daniel, > > Interesting feature suggestion. This could be a real attention grabber. > > But you mention that you imagine it not to be too difficult to achieve. > How do you propose this to be true? Can you use an example? http://jeff.ecchi.ca/blog/2011/07/25/automated-multicamera-clip-syncing/ Alexandre Prokoudine http://libregraphicsworld.org |
From: Simon A. E. <sim...@gm...> - 2012-02-08 07:32:23
|
On 02/08/2012 03:36 AM, Alexandre Prokoudine wrote: > On Wed, Feb 8, 2012 at 3:39 AM, Ernie Zahn wrote: >> Hi Daniel, >> >> Interesting feature suggestion. This could be a real attention grabber. >> >> But you mention that you imagine it not to be too difficult to achieve. >> How do you propose this to be true? Can you use an example? > > http://jeff.ecchi.ca/blog/2011/07/25/automated-multicamera-clip-syncing/ I have no idea how you manage to have a link to a solution for nearly every problem. Thanks for the link! How accurate can we position audio streams? Just by full frames, or is it possible to have a finer granularity? When I synced audio/video I often had the problem that the audio was too early and after moving it by one frame it was too late. Simon |
From: Alexandre P. <ale...@gm...> - 2012-02-08 08:08:45
|
On Wed, Feb 8, 2012 at 11:32 AM, Simon A. Eugster wrote: >> http://jeff.ecchi.ca/blog/2011/07/25/automated-multicamera-clip-syncing/ > > I have no idea how you manage to have a link to a solution for nearly > every problem. Thanks for the link! YW :) > How accurate can we position audio streams? Just by full frames, or is > it possible to have a finer granularity? When I synced audio/video I > often had the problem that the audio was too early and after moving it > by one frame it was too late. Admittedly, I haven't had a chance to test it myself yet. However http://bemasc.net/wordpress/2011/07/26/an-auto-aligner-for-pitivi/ states: "The algorithm I settled on resembles the method a human uses when looking at the waveform view. First, it breaks each input audio stream into 40 ms blocks and computes the mean absolute value of each block. The resulting 25 Hz signal is the “volume envelope”. The code subtracts the mean volume from each track’s envelope, then performs a cross-correlation between tracks and looks for the peak, which identifies the relative shift. To avoid performing N^2 cross-correlations, one clip is selected as the fixed reference, and all others are compared to it. The peak position is quantized to the block duration (creating an error of +/- 20ms), so to improve accuracy a parabolic fit is used to interpolate the true maximum. I don’t know the exact residual error, but I expect it’s typically less than 5 ms, which should be plenty good enough, seeing as sound travels about 1 foot per ms." Alexandre Prokoudine http://libregraphicsworld.org |
From: Simon A. E. <sim...@gm...> - 2012-02-08 08:48:12
|
On 02/08/2012 09:08 AM, Alexandre Prokoudine wrote: > On Wed, Feb 8, 2012 at 11:32 AM, Simon A. Eugster wrote: > >>> http://jeff.ecchi.ca/blog/2011/07/25/automated-multicamera-clip-syncing/ >> >> I have no idea how you manage to have a link to a solution for nearly >> every problem. Thanks for the link! > > YW :) > >> How accurate can we position audio streams? Just by full frames, or is >> it possible to have a finer granularity? When I synced audio/video I >> often had the problem that the audio was too early and after moving it >> by one frame it was too late. > > Admittedly, I haven't had a chance to test it myself yet. However > http://bemasc.net/wordpress/2011/07/26/an-auto-aligner-for-pitivi/ > states: Already read! :) I rather meant kdenlive/MLT here. Can we move an audio clip by just a few samples or only by full frames? Simon > "The algorithm I settled on resembles the method a human uses when > looking at the waveform view. First, it breaks each input audio stream > into 40 ms blocks and computes the mean absolute value of each block. > The resulting 25 Hz signal is the “volume envelope”. The code > subtracts the mean volume from each track’s envelope, then performs a > cross-correlation between tracks and looks for the peak, which > identifies the relative shift. To avoid performing N^2 > cross-correlations, one clip is selected as the fixed reference, and > all others are compared to it. The peak position is quantized to the > block duration (creating an error of +/- 20ms), so to improve accuracy > a parabolic fit is used to interpolate the true maximum. I don’t know > the exact residual error, but I expect it’s typically less than 5 ms, > which should be plenty good enough, seeing as sound travels about 1 > foot per ms." > > Alexandre Prokoudine > http://libregraphicsworld.org > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Kdenlive-devel mailing list > Kde...@li... > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel |
From: Dan D. <da...@de...> - 2012-02-08 18:39:43
|
On Wed, Feb 8, 2012 at 12:47 AM, Simon A. Eugster <sim...@gm...> wrote: > On 02/08/2012 09:08 AM, Alexandre Prokoudine wrote: >> On Wed, Feb 8, 2012 at 11:32 AM, Simon A. Eugster wrote: >> >>>> http://jeff.ecchi.ca/blog/2011/07/25/automated-multicamera-clip-syncing/ >>> >>> I have no idea how you manage to have a link to a solution for nearly >>> every problem. Thanks for the link! >> >> YW :) >> >>> How accurate can we position audio streams? Just by full frames, or is >>> it possible to have a finer granularity? When I synced audio/video I >>> often had the problem that the audio was too early and after moving it >>> by one frame it was too late. then your sense is more acute than most humans' >> >> Admittedly, I haven't had a chance to test it myself yet. However >> http://bemasc.net/wordpress/2011/07/26/an-auto-aligner-for-pitivi/ >> states: > > Already read! :) > I rather meant kdenlive/MLT here. Can we move an audio clip by just a > few samples or only by full frames? at the framework level only by frame, but something more precise can be achieved with an audio filter, e.g. sox.delay > > Simon > >> "The algorithm I settled on resembles the method a human uses when >> looking at the waveform view. First, it breaks each input audio stream >> into 40 ms blocks and computes the mean absolute value of each block. 40ms aka duration of 25 fps frame, this value can be simply computed per mlt_frame >> The resulting 25 Hz signal is the “volume envelope”. The code >> subtracts the mean volume from each track’s envelope, then performs a >> cross-correlation between tracks and looks for the peak, which >> identifies the relative shift. can be implemented as a passive transition that computes the shift and reports it through a property. Then, an application can make a frame-level adjustment at the edit level and apply sox.delay or frei0r.delay0r filters for sub-frame accuracy. Or, the transition can be dual pass, and perform the sub-frame adjustments itself on the second pass. Alternatively, kdenlive is already getting all of the audio in a consumer-frame-show event, so it could just do all of this analysis in its own code and use existing filters for sub-frame accuracy. >> To avoid performing N^2 >> cross-correlations, one clip is selected as the fixed reference, and >> all others are compared to it. The peak position is quantized to the >> block duration (creating an error of +/- 20ms), so to improve accuracy >> a parabolic fit is used to interpolate the true maximum. I don’t know >> the exact residual error, but I expect it’s typically less than 5 ms, >> which should be plenty good enough, seeing as sound travels about 1 >> foot per ms." >> >> Alexandre Prokoudine >> http://libregraphicsworld.org >> |
From: Gabriel G. <gab...@gm...> - 2012-02-08 23:13:17
|
2012/2/8 Dan Dennedy <da...@de...> > >>> How accurate can we position audio streams? Just by full frames, or is > >>> it possible to have a finer granularity? When I synced audio/video I > >>> often had the problem that the audio was too early and after moving it > >>> by one frame it was too late. > > then your sense is more acute than most humans' > I think frame level accuracy is usually "not enough" precision, as also happens when you keyframe fast movements. That's why 3D animation programs, for example, have sub-frame keying capabilities. cheers, Gabriel |
From: Dan D. <da...@de...> - 2012-02-09 00:29:57
|
2012/2/8 Gabriel Gazzán <gab...@gm...>: > I think frame level accuracy is usually "not enough" precision, as also it is good enough for me |
From: Brian M. <pez...@ya...> - 2012-02-09 03:45:18
|
>2012/2/8 Gabriel Gazzán <gab...@gm...>: >> I think frame level accuracy is usually "not enough" precision, as also > >it is good enough for me It really depends on your use case. The ITU did a study and found that the threshold of detectability of lip sync errors is about +45 ms to –125 ms (audio early to audio late) and that the threshold of acceptability is about +90 ms to –185 ms. Apparently it is generally more tolerable for the audio to be slightly delayed than for it to be slightly early. If you only synchronize on video frame boundaries, then the worst case scenario would be +20ms or -20ms for 25fps video (that is +/- 1/2 video frame). The ITU research supports Dan's comment that most people can't even detect that much error. That may be acceptable if your project will be consumed directly. But if the output of your project is destined for further processing (like being transcoded by another system, or being sent through a broadcast chain), the down stream systems may add to the AV sync error. If the error stacks up, it could exceed the thresholds of detectability or possibly even the threshold of acceptability. So the amount of A/V error that is appropriate for your project depends on what you plan on doing with it. ~BM |
From: Simon A. E. <sim...@gm...> - 2012-02-10 08:21:06
|
On 02/09/2012 04:45 AM, Brian Matherly wrote: >> 2012/2/8 Gabriel Gazzán<gab...@gm...>: > >>> I think frame level accuracy is usually "not enough" precision, as also >> >> it is good enough for me > > > It really depends on your use case. > > The ITU did a study and found that the threshold of detectability of lip sync errors is about +45 ms to –125 ms (audio early to audio late) and that the threshold of acceptability is about +90 ms to –185 ms. Apparently it is generally more tolerable for the audio to be slightly delayed than for it to be slightly early. > > > If you only synchronize on video frame boundaries, then the worst case scenario would be +20ms or -20ms for 25fps video (that is +/- 1/2 video frame). The ITU research supports Dan's comment that most people can't even detect that much error. That may be acceptable if your project will be consumed directly. But if the output of your project is destined for further processing (like being transcoded by another system, or being sent through a broadcast chain), the down stream systems may add to the AV sync error. If the error stacks up, it could exceed the thresholds of detectability or possibly even the threshold of acceptability. > > So the amount of A/V error that is appropriate for your project depends on what you plan on doing with it. > > ~BM Thanks a lot for this information! Did they also test detectability of sync errors of hard sound effects? Could it be lower there? Maybe I'm a little too sensitive here, I hate watching videos in German since they usually are badly synched (obviously ... different language) and I often have to force myself to look somewhere else than to the actors' faces in the first minutes. So we could start with frame accuracy first. Also, thanks Dan for the hints. Simon |
From: Gabriel G. <gab...@gm...> - 2012-02-10 18:49:47
|
Record a fast bouncing ball, chances are that you will catch it in contact with the floor in *none* of the frames of the video. Where will you put the sound fx? The only way to put this kind of sound fx right is to have more than *frame* presicion! People who animate, like me, have learned this a long ago. That said I know there might be technocal problems in implementing this functionality, and I totally undestand that this could not make it into Kdenlive soon. That's perfectly ok. g 2012/2/10 Simon A. Eugster <sim...@gm...> > On 02/09/2012 04:45 AM, Brian Matherly wrote: > >> 2012/2/8 Gabriel Gazzán<gab...@gm...>: > > > >>> I think frame level accuracy is usually "not enough" precision, as also > >> > >> it is good enough for me > > > > > > It really depends on your use case. > > > > The ITU did a study and found that the threshold of detectability of lip > sync errors is about +45 ms to –125 ms (audio early to audio late) and that > the threshold of acceptability is about +90 ms to –185 ms. Apparently it is > generally more tolerable for the audio to be slightly delayed than for it > to be slightly early. > > > > > > If you only synchronize on video frame boundaries, then the worst case > scenario would be +20ms or -20ms for 25fps video (that is +/- 1/2 video > frame). The ITU research supports Dan's comment that most people can't even > detect that much error. That may be acceptable if your project will be > consumed directly. But if the output of your project is destined for > further processing (like being transcoded by another system, or being sent > through a broadcast chain), the down stream systems may add to the AV sync > error. If the error stacks up, it could exceed the thresholds of > detectability or possibly even the threshold of acceptability. > > > > So the amount of A/V error that is appropriate for your project depends > on what you plan on doing with it. > > > > ~BM > > Thanks a lot for this information! > Did they also test detectability of sync errors of hard sound effects? > Could it be lower there? > Maybe I'm a little too sensitive here, I hate watching videos in German > since they usually are badly synched (obviously ... different language) > and I often have to force myself to look somewhere else than to the > actors' faces in the first minutes. > So we could start with frame accuracy first. > Also, thanks Dan for the hints. > > Simon > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Kdenlive-devel mailing list > Kde...@li... > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel > |
From: Brian M. <pez...@ya...> - 2012-02-11 02:51:41
|
>> The ITU did a study and found that the threshold of detectability of lip > sync errors is about +45 ms to –125 ms (audio early to audio late) and that the > threshold of acceptability is about +90 ms to –185 ms. Apparently it is > generally more tolerable for the audio to be slightly delayed than for it to be > slightly early. >> >> >> If you only synchronize on video frame boundaries, then the worst case > scenario would be +20ms or -20ms for 25fps video (that is +/- 1/2 video frame). > The ITU research supports Dan's comment that most people can't even > detect that much error. That may be acceptable if your project will be consumed > directly. But if the output of your project is destined for further processing > (like being transcoded by another system, or being sent through a broadcast > chain), the down stream systems may add to the AV sync error. If the error > stacks up, it could exceed the thresholds of detectability or possibly even the > threshold of acceptability. >> >> So the amount of A/V error that is appropriate for your project depends on > what you plan on doing with it. >> >> ~BM > > Thanks a lot for this information! > Did they also test detectability of sync errors of hard sound effects? > Could it be lower there? My understanding of the study is that they took a series of samples across many different types of clips (talking heads, hard sound effects, etc) and across many different people and they applied some statistical averages to the results. So it is possible that some types of sounds are more detectable than others - just as some people are more sensitive to errors than others. > Maybe I'm a little too sensitive here, I hate watching videos in German > since they usually are badly synched (obviously ... different language) > and I often have to force myself to look somewhere else than to the > actors' faces in the first minutes. > So we could start with frame accuracy first. It stands to reason that you could start with frame accuracy, and then see if there is any demand for sub-frame accuracy. ~Brian |
From: Till T. <ro...@tt...> - 2012-02-12 19:04:33
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/08/2012 03:36 AM, Alexandre Prokoudine wrote: > On Wed, Feb 8, 2012 at 3:39 AM, Ernie Zahn wrote: >> Hi Daniel, >> >> Interesting feature suggestion. This could be a real attention >> grabber. >> >> But you mention that you imagine it not to be too difficult to >> achieve. How do you propose this to be true? Can you use an >> example? > > http://jeff.ecchi.ca/blog/2011/07/25/automated-multicamera-clip-syncing/ > > This might be of interest too: http://shenidam.org/ (Someone posted in on our forum last year: http://kdenlive.org/forum/open-source-tool-av-audio-sync) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk84DQMACgkQzwEyz7QP6nTk0gCfaW0xpmZw4rOAdaO626W79rY2 kpkAoLizq8rFiFdLrtTU42YFkz4I3aed =RJ0W -----END PGP SIGNATURE----- |
From: Simon A. E. <sim...@gm...> - 2012-02-15 07:24:26
|
On 02/12/2012 08:03 PM, Till Theato wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 02/08/2012 03:36 AM, Alexandre Prokoudine wrote: >> On Wed, Feb 8, 2012 at 3:39 AM, Ernie Zahn wrote: >>> Hi Daniel, >>> >>> Interesting feature suggestion. This could be a real attention >>> grabber. >>> >>> But you mention that you imagine it not to be too difficult to >>> achieve. How do you propose this to be true? Can you use an >>> example? >> >> http://jeff.ecchi.ca/blog/2011/07/25/automated-multicamera-clip-syncing/ >> >> > This might be of interest too: > http://shenidam.org/ Thanks for the link! I used it to find out how he's doing it -- or at least I tried since I desperately searched for a single line of comment but found none. Ah yes, the license. ;) In the audioAlign branch in git I have a version that already works: http://commits.kde.org/kdenlive/a7be14d538d33a1f4ecb88df578af1fdbf042382 Feel free to test :) Simon |
From: Dâniel F. <fr...@gm...> - 2012-02-08 00:49:13
|
I'm not an programmer, but I can imagine the concept... Is it so difficult to compare 2 different audio tracks? If at least Audacity could do that, it would be a great help... On Tue, 07 Feb 2012 18:39:10 -0500 Ernie Zahn <ern...@gm...> wrote: > Hi Daniel, > > Interesting feature suggestion. This could be a real attention grabber. > > But you mention that you imagine it not to be too difficult to achieve. > How do you propose this to be true? Can you use an example? As of now > FCPX has an API for this but the results are inconsistent. If Apple > doesn't have it stable yet then I'd be a little skeptical of this being > an easy task. > > On 02/07/2012 04:46 AM, Dâniel Fraga wrote: > > Are you planning to add a feature to automatically sync > > external audio? I always record with my Zoom H2N audio recorder and > > it's very boring to drag the audio track exactly at the > > exact position of the original audio track from the camera. > > > > I know Final Cut does have this feature. When will Kdenlive be > > able to do this, too? > > > > I bet a lot of users will enjoy this... and this will attract > > even more users to kdenlive. > > > > Thanks. > > > > Ps: since the recent git has stabilize feature... you could add > > audio auto-sync too. > > > > Ps2: I imagine it's not difficult at all... just compare the 2 > > tracks ("audio" and "original video with audio") and position the audio > > track according to the original track. Then we can mute the original > > audio and that's it. > > > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d -- Linux 3.2.2: Saber-toothed Squirrel http://www.youtube.com/DanielFragaBR |