Hi,
2014-08-17 19:09 GMT+02:00 Christophe Gisquet :
> It would possible to detect bitstreams before this change and achieve
> correct decoding if need be.
So after further exploration, you can't really detect this:
- there's no metadata for the alac bitstream
- the container one may be stripped o
Carl Eugen Hoyos ag.or.at> writes:
> If this is related to ticket #2768, please mention it in the
> commit message.
Sorry, please disregard...
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg
Christophe Gisquet gmail.com> writes:
> The encoder, for content having a bitdepth higher than 16,
> stores the LSBs uncompressed. To do so, it performs first
> channel rematrixing then extract these MSBs.
If this is related to ticket #2768, please mention it in the
commit message.
Thank you
Hi,
2014-08-17 19:56 GMT+02:00 Michael Niedermayer :
> do you have a testcase with which this can be tested ?
Ticket #2768:
http://trac.ffmpeg.org/ticket/2768
shows such an issue starting at around 37xxx byte or something.
> or can the fate test be changed / extended to cover this ?
I haven't l
On Sun, Aug 17, 2014 at 07:15:54PM +0200, Christophe Gisquet wrote:
> 2014-08-17 19:09 GMT+02:00 Christophe Gisquet :
> > It would possible to detect bitstreams before this change and achieve
> > correct decoding if need be.
>
> fate tests still pass with the changes, which means the test sample
>
2014-08-17 19:09 GMT+02:00 Christophe Gisquet :
> It would possible to detect bitstreams before this change and achieve
> correct decoding if need be.
fate tests still pass with the changes, which means the test sample
doesn't contain the corner case involved, and not all encoded content
prior to
The encoder, for content having a bitdepth higher than 16, stores the
LSBs uncompressed. To do so, it performs first channel rematrixing then
extract these MSBs.
However, these 2 steps are inverted, as can be seen in the decoder, or
in the official encoder:
http://alac.macosforge.org/trac/browser/
