[FFmpeg-devel] [PATCH] lavd: implement threaded NewTek NDI output
verem at m1stereo.tv
Thu Sep 7 18:57:30 EEST 2017
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.
More information about the ffmpeg-devel