Le mer. 19 janv. 2022 à 09:45, Gyan Doshi <ffm...@gyani.pro> a écrit : > On 2022-01-19 08:51 pm, Romain Beauxis wrote: > > Le mer. 19 janv. 2022 à 09:19, Gyan Doshi <ffm...@gyani.pro> a écrit : > >> On 2022-01-19 08:44 pm, Romain Beauxis wrote: > >>> Le mer. 19 janv. 2022 à 08:31, Gyan Doshi <ffm...@gyani.pro> a écrit : > >>>> On 2022-01-19 07:53 pm, Romain Beauxis wrote: > >>>>> This patch switches the logic around audio settings to let the caller > >>>>> drive the format. > >>>>> > >>>>> After experimenting with the AudioConverter, we realized that, even > >>>>> when adhering to a strict implementation of the documented API, we were > >>>>> still getting errors during conversions. The input device would > >>>>> randomly change from e.g. s32le to s24le between restarts and error out > >>>>> on conversion (using a freshly initialized converter). > >>>> At present, the code uses the first frame to set attributes. If you > >>>> wait for a few frames and then probe, the attributes are stable. > >>> How is that supposed to work to get a full A/V stream? Discarding > >>> initial audio frames results in data loss in audio-only input and > >>> corrupted initial audio in A/V inputs. > >> We're talking about around 5-6 packets, so ~100 ms. The streaming > >> scenarios I worked on weren't sensitive to that amount of initial loss. > >> YMMV. > > I see thanks. And what advantages does this method provide aside from > > supporting 24 bit sample formats which are currently excluded from > > these changes? > > I was remarking on a way to avoid format changes post-initialization. > Not a comment on your patches.
For sure, and I appreciate the feedback. _______________________________________________ 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".
