[mythtv] Re: [mythtv-commits] Re: Ticket #850: Inaccuracies in audio timecode calculations

[Mark Spieth]

>  Thank you for taking the time to investigate my patch.
>
>  I am happy that your testing revealed no noticeable change in the
>  behaviour of the 2 algorithms, I hope that this indicates that my patch
is
>  working correctly; video playback was working correctly for me before I
>  developed the patch. The original bug I set out to resolve was the
>  indicated playback position for tracks played from within MythMusic.
>
>  Through my investigation I discovered the root cause of that fault to lie
>  within the "AudioOutputBase" class and the way that it keeps track of the
>  current playback position ("AudioTime"), which is basically achieved by
>  accumulating the time in milliseconds represented by each buffer of audio
>  submitted to the class via one of the "AddSamples" member functions. The
>  audio timecode represented by the last sample stored in the audio cyclic
>  buffer ("audiobuffer") is accumulated into the "audbuf_timecode" member
>  variable by lines 626 through 633 of the original code:-
>
>  {{{
>      if (timecode < 0)
>          timecode = audbuf_timecode; // add to current timecode
>
>      /* we want the time at the end -- but the file format stores
>         time at the start of the chunk. */
>      // even with timestretch, timecode is still calculated from original
>      // sample count
>      audbuf_timecode = timecode + (int)((samples * 100000.0) / effdsp);
>  }}}
>
>  For video playback (I am based in the UK with a DVB-T setup):-
>
>  Audio is 16bit, stereo, at 48000Hz[[BR]][[BR]]
>  timecode = is always provided (i.e. is positive)[[BR]]
>  samples = (in my testing at least) was always 1152[[BR]]
>  effdsp = 100 * audio_samplerate[[BR]]
>  [[BR]]
>  audbuf_timecode = timecode + (int)((1152 * 100000.0)/(100 * 48000)[[BR]]
>  audbuf_timecode = timecode + (int)(24)[[BR]]
>
>  As such everything works as expected.........
>
>  Now for audio playback in MythMusic (playing FLAC encoded CD tracks):-
>
>  Audio is 16bit, stereo, 44100Hz[[BR]][[BR]]
>  timecode = is not provided (i.e. is "-1")[[BR]]
>  samples = (in my testing at least) was always 512[[BR]]
>  effdsp = 100 * audio_samplerate[[BR]]
>  [[BR]]
>  audbuf_timecode = audbuf_timecode + (int)((512 * 100000.0)/(100 *
>  44100)[[BR]]
>  audbuf_timecode = audbuf_timecode + (int)(11.60997732426303855)[[BR]]
>
>  As such, each audio buffer provided to the AudioOutputBase class is
>  actually approximately 0.6 milliseconds longer than it is given credit
for
>  resulting in the misreporting of playback position within MythMusic
(which
>  is based upon the figures provided by the AudioOutputBase class).

I understand your problem now. however, your olution if you jump around
(seek) may cause problems due to the dead reckoning of samples played and
not using only the amount of data stored.
The easier way would be to change the baseline of audbuf_timecode to be 1000
more and adjust its use appropriately. the trouble is with your no timecode
case it may be problematic with seeking which would be nice to support.
perhaps it would be better to go to mythmusic (other cases too?) and fake
the timecodes correctly at the source based on the file index or number of
packets from start of file perhaps. then no audio code needs to change. this
also implies that timecodes start at 0 for each track which should be ok but
I havent looked deeply at mythmusics audio data flow yet and hope not to :)
FYI timecodes are in microseconds.
Im sorry but I thought your fix was a bit more complex than it needed to be,
which of course you may disagree.
I have also found 1 avi file with no video timecodes and only the occasiona
audio timecode which caused problems too. havent thought of a good fix for
that yet.

>
>
>  The "int" to "long long" return type from the "GetAudioTime" function was
>  a change that I noticed along the way, and thought I would fix it as it
>  might have strange ramifications that might otherwise be hard to
replicate
>  and fix.
this should be done too but is not really that vital due to the long playing
time required to make this happen.

>  understand more about the context within which this code operates. I have
>  some experience of writing audio processing code, I write soundcard
>  drivers for a living, but I am less familiar with the video decoding and
>  corresponding syncronisation issues.
I do lots of dsp work too :) lots of fun.

>
>  It is probably possible to rectify the MythMusic behaviour without
>  touching the existing mechanism for reporting timecode for the video
>  playback case. I would not be surprised if the video playback case always
>  arranges that the audio buffer supplied to the "AddSamples" function
>  consists of an integer number of milliseconds worth of data. But as this
this is correct too.
>  was beyond my knowledge and I always consider it to be good to avoid any
>  such assumptions where at all possible I proposed the alterations I have.

cheers
mark