Hi Chris, Have you tried the Standard C libflac option? Not that I have anything against the C++ flavor, but I've only ever worked with the C API, to keep things simple. Sorry for the brief response, but I wanted to reply quickly.
Brian On Dec 12, 2017, at 1:51 PM, Chris Barrett <cbarrett.c...@gmail.com> wrote: > I'm trying to use libflac++ on a live internet audio stream. I don't see > anything mentioned in the documentation that suggests this should not be > possible, so I hope I'm not chasing down the wrong path (two weeks in). > > The encoder seems to be working fine and creates data for the write_callback, > which I have coded to packetize that data and send it across the network. > > The question is how the decoder at the receiver should operate. Ideally, > when a packet arrives, 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 it and > sending it. It seems like encoder init causes three write_callbacks that > make up the metadata, and then each call to process causes one write_callback > that is presumably the frame data. The documentation states that one cannot > rely on this, but I can't see any other choice. Just to be safe, I let the > metadata and the first four frames queue up before sending it. Still the > decoder asks for more data when I call process_single_frame with this data > and never calls write_callback. I don't have the decoder meta callback > installed, but could try that to test if it is at least decoding the metadata. > > Any help is greatly appreciated. > > Thanks, > Chris > _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
