Re: [xine-devel] demux_ac3 and running_time

[Mike M. <mi...@mu...>]

Vincent Mussard wrote:
> Thank you for your answer. I think there is a mistake somewhere because 
> both calculations are not equivalent. For example for a 12 MB file, with 
> frame_size of 896 Bytes and sample rate of 48000 hz (I have such a 
> file), first yield :
> ((12000000 / 896) * 90 * 256 * 3) / 48000 = 19284 ms ~ 19 s (seems low...)
> second yield :
> ((12000000 / 896) * 256 * 3) / 48 = 214272 ms ~ 214 s ~ 3:34 (it is the 
> good length of my example file)

	Hmm, now the AC3 demuxer is bringing back memories. I think it's the 
one I wrote in less than 20 minutes, just to see if I could. Some items 
must have slipped through the cracks.

	I think the idea of my "running_time" calculation was to determine the 
length of the stream in terms of pts units (presentation timestamp, in 
reference to 90 KHz clock) and then dividing by 90 for milliseconds or 
by 90000 for seconds.

	BTW, if you are wondering, as many people do, why the calculation is 
broken up into so many steps, it is because some of these calculations 
can exceed 32 bits (multiplying by 90000 can make a number big, and 
fast). I know there are ways to squeeze the calc onto one line with a 
bunch of special qualifiers to ensure 64 bits are used in the right 
places, but I got tired of fighting with it.

> Thank you for this information. I didn't know and I learned something 
> today.
> 
> By the way, here is a very small patch which will fix (I hope) length 
> calculation in demux_ac3 and add time seeking.

	I will evaluate this patch. Thanks for testing. Not sure about this part:

   this->running_time /= this->sample_rate / 1000

Does that mean (running_time / sample_rate), then / 1000; or 
(sample_rate / 1000) and divide running_time by that quotient? I think 
it is important in the case of sample_rate == 44100.

-- 
	-Mike Melanson