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