[FFmpeg-devel] [PATCH] lavd: implement threaded NewTek NDI output

[Maksym Veremeyenko]

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