New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP Very rough cut of streaming from stdin. #1823
base: master
Are you sure you want to change the base?
Conversation
Welcome back @regularfry! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very cool! This is a very useful example to have
I'm very much aware that it's not exactly in a state where it would want to be merged, so what I would like is some indication either way as to whether it's worth my doing the refactoring work to share the streaming consumption code and get rid of the copy/paste duplication.
Yes, if you can figure out a way to reduce the copy-paste would be nice. If it turns out to be too complicated or too much effort, we can probably just merge it as it is, despite the copy-paste
I love the simplicity of this, and I use ffmpeg for many of my workflows (e.g., rtsp publishing of a USB condenser mic source in my daughter's nursery), so I can appreciate the flexibility and minimalism of this approach. I would love to find a way to abstract out some of the common code with the SDL stream example (stream.cpp could be largely unchanged, and the audio_async is 90% the same as well) as I ran into the same thing with my gRPC PR, which I am thinking I could use this abstraction interface to more efficiently do my gRPC work. But of course, those abstractions require time and effort to tease out. :-) Let me know if you would be open to a collaborator on that, @regularfry |
Early on it felt a little bit like I was dodging lasers and and stretching to find "common" code for these two versions (like the bad old days of OOP, where everyone was attempting to use inheritance where it didn't fit), but I think I have a sensibly factored out and pushed up an abstract base class using templates (int16 vs float buffers, with float always being the "result" output, of course) that I use for both the common-sdl and audio-stdin versions--now I just need to bring together the two versions of stream.cpp into one that has a CLI param for either "stdin" or the old/existing SDL source: shanelenagh@59a1906 Using this makes the SDL version largely contain just SDL specific code, and the stdin version has this fairly short implementation:
|
I've got this running on mac with this command:
It doesn't work well (
|
This is a feature I've been wanting for a while, but haven't seen go past anywhere else. It allows streaming raw audio from
stdin
. It's different from thestdin
support inmain
because it doesn't need to slurp the entire stream before processing it. That means you can (for instance) useffmpeg
to pipe audio from the network straight intostream-stdin
without knowing how long the stream is going to be.There are naturally a couple of trade-offs to this. Because it's raw audio, there's no metadata to tell it what the audio format is. Right now it must be 16kHz mono
pcm_s16le
. The trade-off is that it doesn't need to be compiled against SDL, and it doesn't need to know anything about thewav
file format sodr_wav.h
isn't needed either.Given an input wav file, you might want to try it with a command like:
Implementation-wise this is very rough: I've basically copy and pasted
examples/stream.cpp
, and written something that's got a similar enough interface toaudio_async
to not need too many changes. I'm very much aware that it's not exactly in a state where it would want to be merged, so what I would like is some indication either way as to whether it's worth my doing the refactoring work to share the streaming consumption code and get rid of the copy/paste duplication.