[FFmpeg-devel] [PATCH] Implement NewTek NDI support

Maksym Veremeyenko verem at m1stereo.tv
Tue Aug 8 12:29:03 EEST 2017


On 05.08.2017 22:46, Marton Balint wrote:
> On Thu, 3 Aug 2017, Maksym Veremeyenko wrote:
[...]
> About the warnings for the bottom field order and the negative linesize,
> I still think it is better to reject them (return an error), this way
> the user will be forced to fix the input, by changing the field order
> (e.g by using the fieldorder filter before passing video) or getting rid
> of the negative linesize.
done

> To support negative linesizes, there is one more thing you might do: If the
> source frame has a negative linesize, then instead of cloning, allocate
> a new
> avframe with av_frame_alloc, set widht/height/format, use
> av_frame_get_buffer
> to allocate a buffer, then use av_frame_copy to copy the data from the
> source
> frame to the newly allocated one which should have a positive linesize.
> A bit too much work for a rarely used feature, but if you are
> interested, it is
> doable. You can generate a negative linesize source with the vflip filter.
>
i though it really transparent...

> I did some further tests, and I still cannot see my own ffmpeg generated
> source, I am running this command:
>
> ./ffmpeg -nostdin -f libndi_newtek -wait_sources 10 -find_sources 1 -i
> none & ./ffmpeg -f lavfi -i mptestsrc,format=pix_fmts=uyvy422 -f
> libndi_newtek dummy
>
> Even after 10 seconds, the first process finds 0 sources, the second
> process is
> running happily. Does this work for you?

Check if *avahi* daemon is running and firewall turned off.

[root at dev-5 ffmpeg.git-head]# ffmpeg -v debug -nostdin -f libndi_newtek 
-wait_sources 10 -find_sources 1 -i none & ffmpeg -f lavfi -i 
mptestsrc,format=pix_fmts=uyvy422 -f libndi_newtek dummy
/.../
[libndi_newtek @ 0x211bdc0] Waiting for sources 10000 miliseconds
Output #0, libndi_newtek, to 'dummy':
   Metadata:
     encoder         : Lavf57.76.100
     Stream #0:0: Video: wrapped_avframe, uyvy422, 512x512 [SAR 1:1 DAR 
1:1], q=2-31, 200 kb/s, 25 fps, 10000k tbn, 25 tbc
     Metadata:
       encoder         : Lavc57.102.100 wrapped_avframe
[libndi_newtek @ 0x211bdc0] NDIlib_find_wait_for_sources returns 1
[libndi_newtek @ 0x211bdc0] Waiting for sources 10000 miliseconds
[libndi_newtek @ 0x211bdc0] NDIlib_find_wait_for_sources returns 1
[libndi_newtek @ 0x211bdc0] Waiting for sources 10000 miliseconds
[libndi_newtek @ 0x211bdc0] NDIlib_find_wait_for_sources returns 1
[libndi_newtek @ 0x211bdc0] Waiting for sources 10000 miliseconds
[libndi_newtek @ 0x211bdc0] NDIlib_find_wait_for_sources returns 1peed=40.1x
[libndi_newtek @ 0x211bdc0] Waiting for sources 10000 miliseconds
[libndi_newtek @ 0x211bdc0] NDIlib_find_wait_for_sources returns 
0speed=41.4x
[libndi_newtek @ 0x211bdc0] Found 4 NDI sources:
[libndi_newtek @ 0x211bdc0]     'DEV-5.INTERNAL.M1STEREO.TV (dummy)' 
'10.1.5.57:5961'
[libndi_newtek @ 0x211bdc0]     'H264-LIVE (CH1)'       '10.1.5.99:5961'
[libndi_newtek @ 0x211bdc0]     'H264-LIVE (CH2)'       '10.1.5.99:5962'
[libndi_newtek @ 0x211bdc0]     'H264-LIVE (CH3)'       '10.1.5.99:5963'
none: Immediate exit requested
frame=24732 fps=1036 q=-0.0 Lsize=N/A time=00:16:29.24 bitrate=N/A 
speed=41.4x
/.../

i also found that there are some problem with older version of dbus that 
supplied with CentOs7 - it is not thread-safe of NDI functioning.

>> + at subsection Examples
>> +
>> + at itemize
>> +
>> + at item
>> +Play video clip:
>> + at example
>> +ffmpeg -i
>> "udp://@239.1.1.1:10480?fifo_size=1000000&overrun_nonfatal=1" -vf
>> "scale=720:576,fps=fps=25,setdar=dar=16/9,format=pix_fmts=uyvy422" -f
>> libndi_newtek NEW_NDI1
>
> @ needs escaping into @@
done

>> +    while (1)
>> +    {
>> +        int f, t = ctx->wait_sources / 1000;
>> +        av_log(avctx, AV_LOG_DEBUG, "Waiting for sources %d
>> miliseconds\n", t);
>> +        f = NDIlib_find_wait_for_sources(ctx->ndi_find, t);
>> +        av_log(avctx, AV_LOG_DEBUG, "NDIlib_find_wait_for_sources
>> returns %d\n", f);
>> +        if (!f)
>> +            break;
>> +    };
>
> You should not loop indefinitely, give up after a few tries.

from my researches, each loop iteration adds new source, so if you have 
40 sources, then you'll have 40+ iterations. moreover, if no new sources 
found, NDIlib_find_wait_for_sources will block only for specified period 
(default value is 0.5 second). so, there are no default way to make this 
loop indefinite.

>> +static int ndi_write_video_packet(AVFormatContext *avctx, AVStream
>> *st, AVPacket *pkt)
>> +{
>> +    struct NDIContext *ctx = avctx->priv_data;
>> +    AVFrame *avframe, *tmp = (AVFrame *)pkt->data;
>> +
>> +    if (tmp->format != AV_PIX_FMT_UYVY422 ||
>> +        tmp->width  != ctx->video->xres ||
>> +        tmp->height != ctx->video->yres) {
>> +        av_log(avctx, AV_LOG_ERROR, "Got a frame with invalid pixel
>> format or dimension.\n");
>> +        av_log(avctx, AV_LOG_ERROR, "tmp->width=%d, tmp->height=%d,
>> ctx->video->xres=%d, ctx->video->yres=%d\n", tmp->width, tmp->height,
>> ctx->video->xres, ctx->video->yres);
>> +        return AVERROR(EINVAL);
>> +    }
>> +    avframe = av_frame_clone(tmp);
>> +    if (!avframe) {
>> +        av_log(avctx, AV_LOG_ERROR, "Could not clone video frame.\n");
>
> For ENOMEM we typically don't use an error message.
done

>> +static int ndi_write_header(AVFormatContext *avctx)
>> +{
>> +    int ret = 0;
>> +    unsigned int n;
>> +    struct NDIContext *ctx = avctx->priv_data;
>> +    const NDIlib_send_create_t ndi_send_desc = { .p_ndi_name =
>> avctx->filename,
>> +        .p_groups = NULL, .clock_video = false, .clock_audio = false };
>
> Setting both clock_video and clock_audio to false is intentional? Maybe
> better
> to clock based on the stream types you get? (E.g. clock to video if you
> have a
> video stream, clock to audio otherwise?)

i see no reason setting it true - we have properly clocked audio/video 
samples sent to SDK,

BUT, for some experimental reason, i added two parameters *clock_audio* 
and *clock_video* that could be used for testings or tuning for 
appropriate conditions

-- 
Maksym Veremeyenko

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-lavd-implement-NewTek-NDI-input-output-device-suppor.patch
Type: text/x-patch
Size: 33718 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170808/8bb096cc/attachment.bin>


More information about the ffmpeg-devel mailing list