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? _______________________________________________ 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".
