27.08.2017 19:13, Marton Balint пише:
On Fri, 25 Aug 2017, Maksym Veremeyenko wrote:
25.08.2017 0:17, Marton Balint пише:
[...]
Ok. If it works in v3, then I guess it is OK to apply as is. Let me
know when you want me to do that.
please apply
Applied with a small fix to the docs describi
On Fri, 25 Aug 2017, Maksym Veremeyenko wrote:
25.08.2017 0:17, Marton Balint пише:
[...]
Ok. If it works in v3, then I guess it is OK to apply as is. Let me know
when you want me to do that.
please apply
Applied with a small fix to the docs describing encoder supported pixel
formats.
25.08.2017 0:17, Marton Balint пише:
[...]
Ok. If it works in v3, then I guess it is OK to apply as is. Let me know
when you want me to do that.
please apply
--
Maksym Veremeyenko
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.o
On Wed, 23 Aug 2017, Maksym Veremeyenko wrote:
22.08.2017 23:14, Maksym Veremeyenko пише:
[...]
One more thing I noticed testing, maybe you can take a look: rgba and
rgb0 format is not working (I used the V1 SDK), only audio frames are
received, but no apparent error is shown. On the other ha
22.08.2017 23:14, Maksym Veremeyenko пише:
[...]
One more thing I noticed testing, maybe you can take a look: rgba and
rgb0 format is not working (I used the V1 SDK), only audio frames are
received, but no apparent error is shown. On the other hand, bgr0 and
bgra formats do work. If you can't f
22.08.2017 21:06, Marton Balint пише:
On Fri, 18 Aug 2017, Maksym Veremeyenko wrote:
[...]
Thanks for all the fixes. Is it ok to apply this version, or we are
still waiting for some V3 SDK stuff?
i received updated v3 SDK with a fixed issues i noticed, but i will ask
about next release dat
On Fri, 18 Aug 2017, Maksym Veremeyenko wrote:
[...]
Thanks for all the fixes. Is it ok to apply this version, or we are still
waiting for some V3 SDK stuff?
One more thing I noticed testing, maybe you can take a look: rgba and rgb0
format is not working (I used the V1 SDK), only audio fram
On 14.08.2017 0:00, Marton Balint wrote:
[...]
+ret = av_new_packet(pkt, v->yres * v->line_stride_in_bytes);
+if (ret < 0)
+return ret;
You are leaking the NDI video frame here on error. Maybe better to put
NDIlib_recv_free_video into the parent function.
done
[...]
+ret
On 17.08.2017 11:42, Ali KIZIL wrote:
[...]
As general infomation, NDI v3 SDK is released at:
http://pages.newtek.com/NDI-Developers-SDK-Download-Link.html
i found two issues with v3, so wait for final issues resolving.
--
Maksym Veremeyenko
___
ff
2017-08-14 0:00 GMT+03:00 Marton Balint :
>
> On Tue, 8 Aug 2017, Maksym Veremeyenko wrote:
>
> [...]
>>
>
>
>> Check if *avahi* daemon is running and firewall turned off.
>>
>
> Thanks, it works now.
>
> I have some final comments, after addressing those, I guess this can be
> applied, it's been
On Tue, 8 Aug 2017, Maksym Veremeyenko wrote:
[...]
Check if *avahi* daemon is running and firewall turned off.
Thanks, it works now.
I have some final comments, after addressing those, I guess this can be
applied, it's been discussed for quite a long time now.
[...]
+static int ndi
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
On 03.08.2017 10:41, Steinar H. Gunderson wrote:
On Thu, Aug 03, 2017 at 08:21:09AM +0300, Maksym Veremeyenko wrote:
You should reject bottom field first formats, as NDI explicitly
disallows them.
even if it disallowed, why to drop? may be warning message would be enough?
FWIW, the documentat
On Thu, 3 Aug 2017, Maksym Veremeyenko wrote:
On 30.07.2017 17:19, Marton Balint wrote:
[...]
Subject: [PATCH] lavd: implement NewTek NDI muxer/demuxer support
Hi,
About the warnings for the bottom field order and the negative linesize, I
still think it is better to reject them (return an
On Thu, Aug 03, 2017 at 08:21:09AM +0300, Maksym Veremeyenko wrote:
>> You should reject bottom field first formats, as NDI explicitly
>> disallows them.
> even if it disallowed, why to drop? may be warning message would be enough?
FWIW, the documentation may say that formats are always TFF, but o
On Thu, Aug 03, 2017 at 08:21:09AM +0300, Maksym Veremeyenko wrote:
>> You should reject bottom field first formats, as NDI explicitly
>> disallows them.
> even if it disallowed, why to drop? may be warning message would be enough?
FWIW, the documentation may say that formats are always TFF, but o
On 30.07.2017 17:19, Marton Balint wrote:
[...]
Subject: [PATCH] lavd: implement NewTek NDI muxer/demuxer support
lavd: implement NewTek NDI input/output device support
fixed
[...]
- Dolby E decoder and SMPTE 337M demuxer
+- NewTek NDI muxer/demuxer
NewTek NDI input/output device
fixed
Hi,
Some comments below.
>From f40b87b4c7e08ccf23ee896923459e5901ae1086 Mon Sep 17 00:00:00 2001
From: Maksym Veremeyenko
Date: Wed, 26 Jul 2017 03:22:20 -0400
Subject: [PATCH] lavd: implement NewTek NDI muxer/demuxer support
lavd: implement NewTek NDI input/output device support
---
Cha
On 24.07.2017 20:11, Nicolas George wrote:
Le quintidi 5 thermidor, an CCXXV, Maksym Veremeyenko a écrit :
would it be ok:
Subject: [PATCH] lavf: implement NewTek NDI support
Exactly. Except I mistyped: that would be lavd, not lavf; my bad.
fixed
would you *newtek_ndi* or *libndi_newt
Le quintidi 5 thermidor, an CCXXV, Maksym Veremeyenko a écrit :
> would it be ok:
>
>Subject: [PATCH] lavf: implement NewTek NDI support
Exactly. Except I mistyped: that would be lavd, not lavf; my bad.
> would you *newtek_ndi* or *libndi_newtek"
I prefer libndi_newtek, but that is only my
Le quintidi 5 thermidor, an CCXXV, Maksym Veremeyenko a écrit :
> according to SDK documentation terminology, *source* and *find* used for
> this, there are no actual *devices* but only network sources.
This is a case where we have two opposite requirements: consistency
within FFmpeg or consistenc
On 23.07.2017 14:53, Marton Balint wrote:
[...]
@@ -3012,6 +3014,10 @@ decklink_indev_deps="decklink threads"
decklink_indev_extralibs="-lstdc++"
decklink_outdev_deps="decklink threads"
decklink_outdev_extralibs="-lstdc++"
+ndi_indev_deps="ndi pthreads"
you only need threads not pthreads.
On 23.07.2017 18:07, Nicolas George wrote:
[...]
Maybe it's just me, but I am not sure what kind of probing are you referring
to. Could you explain in a bit more detail how the changed code should work?
The same way it works for formats without global header, for example
MPEG-PS: read_header()
On 23.07.2017 15:43, Marton Balint wrote:
[...]
But I think it would be better if you tried to use AVThreadMessageQueue
instead. You can extend it if necessary.
That is copied from decklink_dec as far as I see. Maybe better to
factorize first, and move it to AVThreadMessageQueue as a second ste
On 23.07.2017 13:20, Nicolas George wrote:
Le quintidi 5 thermidor, an CCXXV, Maksym Veremeyenko a écrit :
[...]
Subject: [PATCH] Implement NewTek NDI support
Nit: "lavf: implement..."
would it be ok:
Subject: [PATCH] lavf: implement NewTek NDI support
[...]
I would prefer libndi_new
Le quintidi 5 thermidor, an CCXXV, Marton Balint a écrit :
> That is copied from decklink_dec as far as I see. Maybe better to factorize
> first, and move it to AVThreadMessageQueue as a second step?
I had not noticed it was copied from decklink_dec. If so, then it must
absolutely be shared betwee
On 23.07.2017, at 12:20, Nicolas George wrote:
>
>> +if (!q->last_pkt) {
>> +q->first_pkt = pkt1;
>> +} else {
>> +q->last_pkt->next = pkt1;
>> +}
If kept, I would invert the condition, otherwise the else is essentially a
double-negation.
>> +q->last_pkt = p
On Sun, 23 Jul 2017, Nicolas George wrote:
[..]
+int abort_request;
+pthread_mutex_t mutex;
+pthread_cond_t cond;
+AVFormatContext *avctx;
+} AVPacketQueue;
This whole API looks duplicated in the encoder. Not acceptable. You need
to move it into a pair of .c/.h files, with th
Le quintidi 5 thermidor, an CCXXV, Marton Balint a écrit :
> >+if (ctx->video_st || ctx->audio_st)
> >+{
> >+ctx->f_started = 1;
> >+pthread_create(&ctx->reader, NULL, ndi_reader, ctx);
> >+}
>
> else
> ret = AVERROR(EIO);
EINVAL, I think.
Regards,
--
Nicolas
On Sun, 23 Jul 2017, Maksym Veremeyenko wrote:
Hi,
attached patched for HEAD and n3.3 that implemented NewTek NDI, standard
created by NewTek to make it easy to develop video-related products that
share video on a local Ethernet network.
Thanks! Below are some comments.
From: Maksym Vere
On Sun, Jul 23, 2017 at 11:08:17AM +0300, Maksym Veremeyenko wrote:
> Hi,
>
> attached patched for HEAD and n3.3 that implemented NewTek NDI,
> standard created by NewTek to make it easy to develop video-related
> products that share video on a local Ethernet network.
>
> --
> Maksym Veremeyenko
Le quintidi 5 thermidor, an CCXXV, Maksym Veremeyenko a écrit :
> attached patched for HEAD and n3.3 that implemented NewTek NDI, standard
Thanks for the patch. It looks promising.
No need to keep the patch for n3.3, new features only go in Git master.
And see comments below.
> created by NewTe
Hi,
attached patched for HEAD and n3.3 that implemented NewTek NDI, standard
created by NewTek to make it easy to develop video-related products that
share video on a local Ethernet network.
--
Maksym Veremeyenko
>From d5df13750d029d5314be24c9b1cb7306947507c1 Mon Sep 17 00:00:00 2001
From: M
33 matches
Mail list logo
