search for: read_callback

..., it can be fed to the decoder. When the decoder has enough data for a new uncompressed frame, it returns one. But the decoder API does not seem setup for this type of synchronous operation. When a packet arrives, I'm trying to call process_single_frame and then supply the packet data in the read_callback. It takes the data but always calls the read_callback again for more data. It does call error_callback (status == 0) once, but never write_callback. So, I'm guessing that the packet does not have enough data for a frame. So, I tried queueing write_callbacks at the encoder before packetizing...

...6 [34.868210] SendChanDataMsg: 12 The audio is silence, so I believe there is a high compression ratio ((4096 x 5) + metadata) -> 146 bytes decoder: [29.009735] HandleChanDataMsg, start: 1 [29.009773] SetAudioTimer, total: 1200, holdoff: 585 <process_single_frame called here> [29.009792] read_callback, size: 146 [29.009809] error_callback, status: 0 [29.009821] read_callback, size: 146 [29.009834] read_callback, size: 146 [29.009844] read_callback, size: 146 [29.009855] read_callback, size: 146 ... <calls read_callback forever> I can send out some of the code fragments if needed. Thanks,...

...; > don't you just hate those? maybe just manually turning > on basic debug info in the release build would get you > enough to narrow it down. OK, here's the stack trace: (gdb) bt #0 FLAC__bitbuffer_read_raw_uint32 (bb=0x20000000008c8048, val=0x80000fffffffa498, bits=24, read_callback=0x20000000003b1008, client_data=0x60000000002beb20) at bitbuffer.c:1107 #1 0x2000000000123dc0 in stream_decoder_read_metadata_ ( decoder=0x60000000002beb20) at stream_decoder.c:633 #2 0x2000000000123300 in FLAC__stream_decoder_process_metadata ( decoder=0x60000000002beb20) at stream_...

Hi, The stream decoder follows a push model, however, I need a pull model decoder, like, for example, implemented by the Vorbis libs. For this I simply save the pointer to the audio data in the read callback and acces the data lateron after the call to FLAC__stream_decoder_process_one_frame returned. Is this safe? Can I assume that the internal buffer is not freed, when

...e fed to the decoder. When the decoder has enough data for a new uncompressed frame, it returns one. > > But the decoder API does not seem setup for this type of synchronous operation. When a packet arrives, I'm trying to call process_single_frame and then supply the packet data in the read_callback. It takes the data but always calls the read_callback again for more data. It does call error_callback (status == 0) once, but never write_callback. So, I'm guessing that the packet does not have enough data for a frame. > > So, I tried queueing write_callbacks at the encoder before p...

Thanks for the reply, But that still tries to read for itself from libogg... i need to be able to feed data only... it can never try and read for itself. That code is still trying to control the data flow. Basicly i need to operate like this. SetupCodec when i have data to give to the codec FeedDataToCodec(data) //Receive a bunch of callbacks somewhere returning me pcm data //Codec

...files Severity: normal Package: libflac4 Version: 1.1.0-11 Running ogg123 on http://rzlab.ucr.edu/debian/libflac/crash.flac results in a segfault in libFLAC: (gdb) bt full #0 0x40205422 in FLAC__bitbuffer_read_rice_signed_block (bb=0x80601b8, vals=0x807dd80, nvals=4294967293, parameter=9, read_callback=0x40220080 <read_callback_>, client_data=0x805ba58) at bitbuffer.c:2254 available_bits = 134733184 buffer = ( const FLAC__blurb *) 0x8060228 "o?z\023\017\a???\216???c??????vc?\201q\030NE+\030\213?5*?k??R2?\035?\207iP!?\237??oQ??\207?\202\"?\235\220?\212Us??v??f??\231%\233??qJ?...

...M uses FLAC: - using libFLAC stream encoder/decoder - many samples are encoded/decoded in the same file using the same encoder/decoder instance (the individual sample formats may differ but the block size is fixed currently) - CRAM uses its own container format (EBML) - FLAC header is forged in the read_callback (isn't actually written to CRAM file) If anyone has any ideas on how this issue can be resolved I'd appreciate the input. In particular this is related to some change between version 1.1.1 and 1.1.2 of FLAC. I'll continue to try and narrow down what exactly it is. Best regards, Jos...

Hi! I am working on an application that reads audio data from files, and runs it through some user defined filters. The filters basically all derive from some base filter and have methods start(), update() and finish(). The start routine performs any initialization required by the filter, and finish() does the clean up. In between, I simply read the file piece by piece into a buffer using

...just manually turning > > on basic debug info in the release build would get you > > enough to narrow it down. > > OK, here's the stack trace: > > (gdb) bt > #0 FLAC__bitbuffer_read_raw_uint32 (bb=0x20000000008c8048, > val=0x80000fffffffa498, bits=24, > read_callback=0x20000000003b1008, > client_data=0x60000000002beb20) at bitbuffer.c:1107 > #1 0x2000000000123dc0 in stream_decoder_read_metadata_ ( > decoder=0x60000000002beb20) at stream_decoder.c:633 > #2 0x2000000000123300 in FLAC__stream_decoder_process_metadata ( > decoder=0x600...

Well, unless somebody has a brilliant idea, I am giving up on this. I don't see how I can do what I wanted to. The slightly hacky way I thought would work, was by guaranteeing the read_callback could read at least enough data to make process_single() return (ie the buffer should contain at least 1 frame or block). But it seems that even when the maximum frame size is known, that can never be guaranteed (probably due to sync errors). The only solution I can think of is an API change such a...

...tream /*****************************************************************************/ class TMyFlacEncoder: public FLAC::Encoder::Stream { protected: TMyFileAccess *FFile; // the file we are writing to long long FFlacOffset; virtual FLAC__StreamEncoderReadStatus read_callback (FLAC__byte buffer[], size_t *bytes) { if(*bytes > 0) { *bytes = FFile->Read(buffer, sizeof(FLAC__byte), *bytes); if(FFile->Error()) return FLAC__STREAM_ENCODER_READ_STATUS_ABORT; else if(*bytes == 0)...

On Fri, Jul 20, 2001 at 10:51:11PM -0400, Matt Zimmerman wrote: > This version seems to work at least partially on ia64. I am able to encode my > usual test WAV file now, but I still get a segfault during the self-tests. Interestingly enough, when I recompiled with --enable-debug to get a stack trace, it worked. Any ideas how to track down the problem? -- - mdz

...LAC stream encoder/decoder > - many samples are encoded/decoded in the same file using the same > encoder/decoder instance (the individual sample formats may differ but > the block size is fixed currently) > - CRAM uses its own container format (EBML) > - FLAC header is forged in the read_callback (isn't actually written to > CRAM file) > > If anyone has any ideas on how this issue can be resolved I'd appreciate > the input. In particular this is related to some change between version > 1.1.1 and 1.1.2 of FLAC. I'll continue to try and narrow down what > exac...

...; > - many samples are encoded/decoded in the same file using the same > > encoder/decoder instance (the individual sample formats may differ > but > > the block size is fixed currently) > > - CRAM uses its own container format (EBML) > > - FLAC header is forged in the read_callback (isn't actually > written to > > CRAM file) > > > > If anyone has any ideas on how this issue can be resolved I'd > appreciate > > the input. In particular this is related to some change between > version > > 1.1.1 and 1.1.2 of FLAC. I'll contin...

Hi all, Thanks in advance for your help, and sorry for the slow reply. I've created a small OS X example project <https://drive.google.com/file/d/0B8vFUUth7NpvRFI0MmI2bVJNNEU/view?usp=sharing> that reproduces the issue. (I've run into the size limit for emails on this list so I've put it on Google Drive.) The program just initializes a libFLAC++ stream decoder for a given file

...+ msbs = 0; state = 0; } @@ -2212,7 +2217,7 @@ bb->consumed_blurbs = i; bb->consumed_bits = cbits; bb->total_consumed_bits = (i << FLAC__BITS_PER_BLURB_LOG2) | cbits; - if(val_i < nvals) { + if(val_i > 0) { if(!bitbuffer_read_from_client_(bb, read_callback, client_data)) return false; /* these must be zero because we can only get here if we got to the end of the buffer */ > > btw how are you playing it on the ipod? With a modified version of Music Player Daemon (MPD, www.musicpd.org). http://www.ipodlinux.org/MPD has more info abo...

I refer to a problem that appeared on the flac list last August that was either solved off-list or abandoned. (http://lists.xiph.org/pipermail/flac/2005-August/000468.html) The problem is with using the C++ encoder classes, particularly the FLAC::Encoder::File:set_metadata function. JC said that the developers version of how to add a simple metadata block looked right, but it did not work for

Pulled from my Arch archive, this following patch seems to have made quite a difference in getting my ARM7TDMI chip to play FLAC (compression levels 0-2) on my ipod. I don't have benchmarks with hard numbers, but playing with skips vs playing without skips is a fairly noticeable difference. memcpy and memset on uClibc are optimized in asm for the ARM7TDMI in uClibc. Other hardware/libc

...tion `OggFLAC__ogg_decoder_aspect_reset': ogg_decoder_aspect.c:95: error: `aspect' undeclared (first use in this function) ogg_decoder_aspect.c: At top level: ogg_decoder_aspect.c:101: error: parse error before '*' token ogg_decoder_aspect.c: In function `OggFLAC__ogg_decoder_aspect_read_callback_wrapper': ogg_decoder_aspect.c:104: error: `bytes' undeclared (first use in this function) ogg_decoder_aspect.c:133: error: `aspect' undeclared (first use in this function) ogg_decoder_aspect.c:140: error: `buffer' undeclared (first use in this function) ogg_decoder_aspect.c:156: wa...