Author Topic: 2.6/2.7 AudioCopy Duping  (Read 20873 times)

mean

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 10959
Re: 2.6/2.7 AudioCopy Duping
« Reply #30 on: January 01, 2013, 07:10:23 PM »
right again
I should stop arguing with you :)

KoolAidMan

  • Jr. Member
  • **
  • Posts: 68
Re: 2.6/2.7 AudioCopy Duping
« Reply #31 on: January 01, 2013, 07:22:15 PM »
right again
I should stop arguing with you :)
It's okay. You're a lot easier to deal with than some of the contributors at the apache software foundation. :) I've submitted patches to them and had to wait for a month, only to have to rewrite portions of it, add a software license I forgot to add, etc.

mean

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 10959
Re: 2.6/2.7 AudioCopy Duping
« Reply #32 on: January 02, 2013, 06:32:43 AM »
I'll merge it soon
It needs just a little change : Ask muxer if it can deal with timestamp
It yes, no need to dupe audio, it can starts anywhere in time, same for audio skew

If the muxer cannot cope with that (e.g. avi ), duping needs to be done

mean

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 10959
Re: 2.6/2.7 AudioCopy Duping
« Reply #33 on: January 06, 2013, 08:27:33 AM »
I've done it slightly differently, merging both the non starting at zero & correcting as we go along in audioStreamCopy
If perfectAudio is needed, i.e. avi or any container that cannot manage timestamps, the audio clock is tracked and packets are duped / dropped
to contain the skew within an acceptable margin (80 ms as of now)
Not tested a lot, but seems to work

KoolAidMan

  • Jr. Member
  • **
  • Posts: 68
Re: 2.6/2.7 AudioCopy Duping
« Reply #34 on: January 07, 2013, 12:27:51 AM »
I've done it slightly differently, merging both the non starting at zero & correcting as we go along in audioStreamCopy
If perfectAudio is needed, i.e. avi or any container that cannot manage timestamps, the audio clock is tracked and packets are duped / dropped
to contain the skew within an acceptable margin (80 ms as of now)
Not tested a lot, but seems to work
I've been watching your changes on the subversion log. I like your inheritance-based approach better. This will also allow me to stop working on the audio skew patch (which I had working for certain types of audio, but was having to fix all of the getTime function in order to properly rewind the audio stream).

This has been a problem with avidemux 2.6 since it was alpha builds from Gruntster, and I am glad it is finally resolved! Just a quick glance on CNET, one of the latest comments is "When I tried to process a video there was a difference between video and sound," so I was not the only person who was having this problem (see: http://download.cnet.com/Avidemux/3000-13631_4-12883208.html). Once this patch eventually gets to CNET, hopefully that person will be happy. :)

Thanks again Mean.