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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20171212/9dae20af/attachment.html>
Brian Willoughby
2017-Dec-12 23:44 UTC
[flac-dev] using libflac++ on a live internet stream
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.colo at 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 >
Thanks Brian. I converted everything to libFLAC and got the same results. Here is some debug output encoder: [34.270050] FLAC encoder set succeeded [34.271183] write_callback, frame: 0, samples: 0 [34.271282] write_callback, frame: 0, samples: 0 [34.271313] write_callback, frame: 0, samples: 0 [34.271351] FLAC encoder initialization succeeded [34.356251] write_callback, frame: 0, samples: 4096 [34.441582] write_callback, frame: 1, samples: 4096 [34.526905] write_callback, frame: 2, samples: 4096 [34.612213] write_callback, frame: 3, samples: 4096 [34.697556] write_callback, frame: 4, samples: 4096 [34.697594] SendChanDataMsg: 146 [34.782898] write_callback, frame: 5, samples: 4096 [34.782936] SendChanDataMsg: 12 [34.868168] write_callback, frame: 6, samples: 4096 [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, Chris On Tue, Dec 12, 2017 at 4:44 PM, Brian Willoughby <brianw at audiobanshee.com> wrote:> 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.colo at 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 > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20171213/c0a8005a/attachment.html>