[FFmpeg-soc] [Patch] Maxis EA XA decoder - GSoC Task

[Robert Marston]

On Sat, Apr 12, 2008 at 7:21 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Sat, Apr 12, 2008 at 06:12:15PM +0200, Robert Marston wrote:
>  > On Sat, Apr 12, 2008 at 3:00 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>  > >
>  > > On Sat, Apr 12, 2008 at 01:39:45PM +0200, Robert Marston wrote:
>  > >  >
>  > >  > Thanks for pointing that out, I will be the first to admit that my c
>  > >  > knowledge is probably not up to standard when it comes to FFMPEG and
>  > >  > as such would required much feedback from my mentor. I see the GSoC as
>  > >  > good learning opportunity for the myself and a chance to bolster open
>  > >  > source development and potential to increase the code base of the
>  > >  > mentor organizations project.
>  > >  >
>  > >  > Would casting the *(src + channel) to a int32_t stop the above from happening?
>  > >
>  > >  i would put the cast after <<0x1C but before >>shift[channel]
>  > >
>  >
>  > As a matter of interest is that to avoid loosing higher order bits in
>  > the <<0x1C shift?
>
>  no
>

Sorry that a was a stupid question, the cast would have dropped the
bits anyway. What is the reason for putting the cast after the 0x1C
shift?

> >>
>  > >  >
>  > >  > My logic on this is that there are 2 samples per byte and 14 bytes per
>  > >  > channel. = 28 x num_channels
>  > >  > There are is 1 sample every 1 / sample rate seconds and 90 K ticks per
>  > >  > second if we use a 90 KHz clock
>  > >  >
>  > >  > Therefore the pts, which in my understanding of the time base being
>  > >  > the number of ticks of the 90 KHz clock, will be advanced  by 28 x
>  > >  > num_channels /  sample rate * 90 K for each block read from the file.
>  > >  >
>  > >  > Have I misunderstood something here?
>  > >
>  > >  yes, there is no 90khz clock. The "clock" is what the code calls time_base
>  > >  and what you set with av_set_pts_info()
>  > >
>  > >  [...]
>  >
>  >
>  > Ok that makes a little more sense. I was using a 90 KHz clock since I
>  > had seen it in some of the other game format demuxers and presumed
>  > that it was needed. In this case do I only advance the pts by the
>  > number of samples sent in each packet?
>
>  This depends on how you define sample, so possibly yes. What the pts
>  is increased by is the duration of the packet.
>
>
>  [...]

Attached is my latest attempt at the patch.

Thanks
Robert
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: maxis_ea_xa_format.txt
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20080413/8aa11cdb/attachment.txt>