[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