05.09.2017 23:50, Marton Balint пише:
[...]
If I get this correctly, this patch is needed because you can only
schedule 1 frame to the NDI API, therefore especially for shorter audio
frames the buffer may underrun, right?. If that is the case, then I'd
describe this in a bit more detail in the docs and/or the commit message.
this patch was needed to make an audio play smooth. sometimes i notices
some audio issue with /reference monitoring tool/ - so it is rather
research purpose to find a proper way.
if i specify 16 packets queue and use two queues i got video/audio
unsync (all monitoring performed by *Studio Monitor* software).
*perfectly* working was reached by audio queue for two packets
(previously processed by *asetnsamples* filter) and no-threads for video.
then i say about audio issue i mean that i *hear* by NDI software but
not a logged output of reference analizer - i have only visual/cosumer
method for estimating quality of audio/video packets sending...
Also, decklink uses a concept called preroll for a similar purpose, it
is specified in time, and the video buffer is capable of storing
preroll*2 amount of video. (Also, at the start of the stream the code
only starts draining the buffer after preroll amount of video is
received, there comes the name, preroll. This way the buffer won't
underrun even at the start of the stream).
decklink has driver's DMAed memory for prerolled frame and decklink
internally align audio/video samples to make it synchronous... so it
hard to compare with hardware driven device.
I just mentioned this because you may want to support a similar concept,
or specify buffer sizes in time, instead of in frames. But if not, that
is fine as well.
queues is in a packet count units - AVPacket been queued.
As for the actual code - I see a lot of code duplications :), maybe you
can factorize audio_thread and video_thread to use the same function,
and also the code which creates these threads.
if it does not decrease code reading quality i can do that easy
But in general the code looks fine.
thanks
--
Maksym Veremeyenko
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
