On Tue, Aug 17, 2021 at 3:58 PM Nicolas George <geo...@nsup.org> wrote:
> Xiang Xiao (12021-08-17): > > Nicolas, do you have any more progress? I am very interested in your > > proposal and want to test your change in our special device. > > We are building an audio framework on top of FFmpeg for a wearable device: 1. Reuse avfilter to form the process pipeline 2. Add the new avfilter to process our special audio/a2dp/sco device 3. Add audio routing policy through https://github.com/intel/parameter-framework 4. Expose a bunch of audio play, capture and routing API to client by RPC Since the wearable device has very limited resources, we want to run all processes in one loop thread. It's easy to achieve by poll/select: 1. Mark output/input device file handle to non-block 2. Mark RPC socket handle to non-block 3. Poll the aboved handles in the main loop 4. Call the filter/graph function to trigger the audio/route action Sorry. I have been focusing on other projects while looking for a good > way to avoid dynamic allocations in the thread-aware scheduler. > > Since I could not find one, I will try to start again on this soon. > > Do you have an opinion on the low-level single-thread API? > > Yes, you can see our approach is one thread solution. But, there is a major block issue: protocol/avformat can't handle the non-block I/O correctly. Two approach I can think: 1. Handle the partial read(or -EGAIN) correctly by saving the intermediate result into protocol/avformat context 2. Protocol/avformat utilize your event loop to wait the new data instead of blocking on recv call, the same loop can replace the one we used in the main thread. The first approach requires reviewing and adapting each protocol/avformat carefully which is a huge amount of work. The second approach is more simple. Can you share some details about the needs your special device? I would > consider them when writing the API. > > Regards, > > -- > Nicolas George > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
