Re: [flac-dev] Lets do a 1.3.2 release

[lvqcl]

Dave Yeo wrote:

>> I cannot find information what version of binutils supports AVX/AVX2/FMA
>> instructions, but IIRC OS/2 doesn't support AVX instructions anyway,
>> so it doesn't matter much.
>
> Surprisingly, I've yet to have a report of an AVX related crash or trap
> (used in FFmpeg and projects based on it, Mozilla, probably others).
> As I understand it, support is a matter of saving the extended registers
> during a context switch and perhaps our kernel had some future proofing
> added towards the end.

WinXP/Vista also don't support AVX but ffmpeg doesn't crash there.

IIRC, OS must explicitely enable AVX support, and an application must check
whether the OS supports AVX or not.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

[Dave Yeo]

On 01/19/16 01:04 PM, lvqcl wrote:
> Dave Yeo wrote:
>
>>> I cannot find information what version of binutils supports AVX/AVX2/FMA
>>> instructions, but IIRC OS/2 doesn't support AVX instructions anyway,
>>> so it doesn't matter much.
>>
>> Surprisingly, I've yet to have a report of an AVX related crash or trap
>> (used in FFmpeg and projects based on it, Mozilla, probably others).
>> As I understand it, support is a matter of saving the extended registers
>> during a context switch and perhaps our kernel had some future proofing
>> added towards the end.
>
> WinXP/Vista also don't support AVX but ffmpeg doesn't crash there.
>
> IIRC, OS must explicitely enable AVX support, and an application must check
> whether the OS supports AVX or not.

OK, that makes sense and after looking quickly at Agners 
optimizing_assembly.pdf I can see how FFmpeg does it though I still find 
it hard to follow the code in flac.
The second version of the patch is to be preferred.
I'll have to ask the Russians about their alternative kernel (OS/4)
Dave
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC__stream_decoder_seek_absolute calling write callback

[Tamás Zahola]

> Hi,
> Sorry for the tardy response to this. I've now read your email a number of
> times and I'm still not sure what needs to be done.
> Maybe it would help if you could explain the following:
> * What is actually happening.
> * What you expect to happen and how that differs from what is happening.
> * Propose a fix.
> Once thing that may actually help is a small chunk of code demonstrating
> the problem.

Thanks for your response!
Here's an example:

#include 
#include 

int main(int argc, const char * argv[]) {
class Decoder : public FLAC::Decoder::File {
protected:
virtual ::FLAC__StreamDecoderWriteStatus
write_callback(const ::FLAC__Frame *frame, const FLAC__int32 * const
buffer[]) override {
std::cout << "write_callback called!" << std::endl;
abort();
return
FLAC__StreamDecoderWriteStatus::FLAC__STREAM_DECODER_WRITE_STATUS_CONTINUE;
}

virtual void
error_callback(::FLAC__StreamDecoderErrorStatus status) override {}
} decoder;

decoder.init("sample.flac");
decoder.process_until_end_of_metadata();
decoder.seek_absolute(1);

return 0;
}

Despite not calling `process_single`, this snippet crashes with
"write_callback called!" because internally `seek_absolute(sample)`
processes the frame which contains `sample`. My question was whether
this behaviour was intentional/documented (I haven't found it being
mentioned in the docs) and whether if it happens always (or e.g. only
if I specify a sample that's not on a frame boundary, etc.)?

Best regards,
Tamas Zahola
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC__stream_decoder_seek_absolute calling write callback

[Erik de Castro Lopo]

Tamás Zahola wrote:

> Hello,
> 
> The API documentation [1] `FLAC__stream_decoder_seek_absolute` says:
> 
> "Flush the input and seek to an absolute sample. Decoding will resume
> at the given sample. Note that because of this, the next write
> callback may contain a partial block."
> 
> I expected that subsequent `process_single` calls would return data
> starting exactly from the sample I've seeked to. To my surprise
> hovewer it seems that `seek_absolute` implicitly processes the frame
> which contains the requested sample (the write callback receives only
> the tail of the frame from the given sample).
> 
> Since the documentation haven't mentioned seek_absolute triggering the
> write callback, my question would be whether this behaviour is
> guaranteed or not? Is seek_absolute guaranteed to implicitly process
> the frame containing the requested sample? (in other worfs: a
> process_single call after a successful seek_absolute call always
> processes the frame _after_ the one contaning the requested sample)

Hi,

Sorry for the tardy response to this. I've now read your email a number of
times and I'm still not sure what needs to be done.

Maybe it would help if you could explain the following:

* What is actually happening.
* What you expect to happen and how that differs from what is happening.
* Propose a fix.

Once thing that may actually help is a small chunk of code demonstrating
the problem.

Cheers,
Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev