| Message ID | CAB0OVGqotVRKRQifitGcMEAsjS1pb1_VGfnuWr2cfxPvhkUKVA@mail.gmail.com |
|---|---|
| State | Withdrawn |
| Headers | show |
On 2017-09-28 14:20, Carl Eugen Hoyos wrote: > I don't have decklink hardware but I assume it never outputs actual > transparency. > Or does it? > From what I understand about SDI, it is possible to send alpha information over an SDI link in certain configuration (RGBA) -- from what I read on Wikipedia ( https://en.wikipedia.org/wiki/Serial_digital_interface#Link_numbering ) on SDI. I will assume that it might be possible to access that information from such a decklink card (I don't have and SDI hardware as of yet, but might end up getting one) --Doug (dx9s)
29.09.2017 0:20, Carl Eugen Hoyos пише: > Hi! > > I don't have decklink hardware but I assume it never outputs actual > transparency. > Or does it? dual link SDI could provide fill/key, some boards could support this
2017-09-29 17:35 GMT+02:00 Maksym Veremeyenko <verem@m1stereo.tv>: > 29.09.2017 0:20, Carl Eugen Hoyos пише: >> I don't have decklink hardware but I assume it never outputs actual >> transparency. >> Or does it? > > dual link SDI could provide fill/key, some boards could support this (Do they or don't they?) Thank you both for the explanations! Patch dropped, Carl Eugen
On Fri, 29 Sep 2017, Carl Eugen Hoyos wrote: > 2017-09-29 17:35 GMT+02:00 Maksym Veremeyenko <verem@m1stereo.tv>: >> 29.09.2017 0:20, Carl Eugen Hoyos пише: > >>> I don't have decklink hardware but I assume it never outputs actual >>> transparency. >>> Or does it? >> >> dual link SDI could provide fill/key, some boards could support this > > (Do they or don't they?) For output, there is definitely hardware support. For capture - I am not sure. I have not heard of a decklink device capturing key/fill. Unfortunately the decklink SDK uses the same constants for both capture and output, and if we want to follow the SDK, we can't drop alpha channel, because for both RGBA and ARGB modes it explicitly mentions that the alpha channel might be valid. It does not differentiate between input and output however. Maybe somebody should ask BlackMagic. Regards, Marton
29.09.2017 23:54, Marton Balint пише: [...] > For output, there is definitely hardware support. For capture - I am not > sure. I have not heard of a decklink device capturing key/fill. > > Unfortunately the decklink SDK uses the same constants for both capture > and output, and if we want to follow the SDK, we can't drop alpha > channel, because for both RGBA and ARGB modes it explicitly mentions > that the alpha channel might be valid. It does not differentiate between > input and output however. > > Maybe somebody should ask BlackMagic. https://www.blackmagicdesign.com/media/release/20150413-16 [...] .... get simultaneous fill and key capture and playback ...
On Mon, 2 Oct 2017, Maksym Veremeyenko wrote: > 29.09.2017 23:54, Marton Balint пише: > [...] >> For output, there is definitely hardware support. For capture - I am not >> sure. I have not heard of a decklink device capturing key/fill. >> >> Unfortunately the decklink SDK uses the same constants for both capture >> and output, and if we want to follow the SDK, we can't drop alpha >> channel, because for both RGBA and ARGB modes it explicitly mentions >> that the alpha channel might be valid. It does not differentiate between >> input and output however. >> >> Maybe somebody should ask BlackMagic. > > https://www.blackmagicdesign.com/media/release/20150413-16 > [...] > .... get simultaneous fill and key capture and playback ... Ok, but I think from the driver's point of view this is actually two completely separate inputs. Yeah, you can capture both at the same time, and one signal might be key, other might be fill, but as far as I know the driver will not merge these two signals behind the scenes to one single input with an alpha channel. Regards, Marton
Am 02.10.2017 um 18:34 schrieb Marton Balint: > Yeah, you can capture both at the same time, and one signal might be > key, other might be fill, but as far as I know the driver will not > merge these two signals behind the scenes to one single input with an > alpha channel. Is there a video filter for splitting RGBA->key/fill or joining key/fill -> RGBA? Then an example in the docs would be helpful, though I'm not sure if the two streams will be perfectly synchronized. Matthias
29.09.2017 0:20, Carl Eugen Hoyos пише: > Hi! > > I don't have decklink hardware but I assume it never outputs actual > transparency. > Or does it? it outputs or use internal keyer to put it over passthrow SDI signal. in external keyer mode it accept BGRA frame and output two SDI signals: one for *fill* another one for *key*
On Thu, 5 Oct 2017, Maksym Veremeyenko wrote: > 29.09.2017 0:20, Carl Eugen Hoyos пише: >> Hi! >> >> I don't have decklink hardware but I assume it never outputs actual >> transparency. >> Or does it? > > it outputs or use internal keyer to put it over passthrow SDI signal. > > in external keyer mode it accept BGRA frame and output two SDI signals: > one for *fill* another one for *key* That is true, but that is the feature of the decklink output device. Is the decklink *input* device capable of capturing in RGBA with useful alpha? I'd say, probably not. So I am more and more willing to accept the patch unless somebody has strong objections. Regards, Marton
On Thu, 5 Oct 2017, Matthias Hunstock wrote: > Am 02.10.2017 um 18:34 schrieb Marton Balint: >> Yeah, you can capture both at the same time, and one signal might be >> key, other might be fill, but as far as I know the driver will not >> merge these two signals behind the scenes to one single input with an >> alpha channel. > > > Is there a video filter for splitting RGBA->key/fill or joining key/fill > -> RGBA? Then an example in the docs would be helpful, though I'm not > sure if the two streams will be perfectly synchronized. Both should be doable with extractplanes or mergeplanes filters. Regards, Marton
2017-10-06 21:10 GMT+02:00 Marton Balint <cus@passwd.hu>: > Is the decklink *input* device capable of capturing in RGBA with useful > alpha? I'd say, probably not. > > So I am more and more willing to accept the patch unless > somebody has strong objections. I'll push on Sunday unless somebody objects. Carl Eugen
06.10.2017 22:10, Marton Balint пише: > > On Thu, 5 Oct 2017, Maksym Veremeyenko wrote: > >> 29.09.2017 0:20, Carl Eugen Hoyos пише: >>> Hi! >>> >>> I don't have decklink hardware but I assume it never outputs actual >>> transparency. >>> Or does it? >> >> it outputs or use internal keyer to put it over passthrow SDI signal. >> >> in external keyer mode it accept BGRA frame and output two SDI >> signals: one for *fill* another one for *key* > > That is true, but that is the feature of the decklink output device. > > Is the decklink *input* device capable of capturing in RGBA with useful > alpha? I'd say, probably not. i would say that it is probably *yes* because of that feature (capturing fill&key signal) mentioned in press release: > https://www.blackmagicdesign.com/media/release/20150413-16 > [...] > .... get simultaneous fill and key capture and playback ... on other hand, if capturing RGB from HDMI returns transparent picture - then yes - this patch should be applied.
2017-09-28 23:20 GMT+02:00 Carl Eugen Hoyos <ceffmpeg@gmail.com>: > I don't have decklink hardware but I assume it never outputs actual > transparency. I have applied this patch. Thank you, Carl Eugen
From 3ab60460c7892b094b01b175f1a3aa735cb3cea6 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos <ceffmpeg@gmail.com> Date: Thu, 28 Sep 2017 23:18:09 +0200 Subject: [PATCH] lavd/decklink_dec: Do not claim to output transparency information. --- libavdevice/decklink_dec.cpp | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp index 3ce2cab..17c0d20 100644 --- a/libavdevice/decklink_dec.cpp +++ b/libavdevice/decklink_dec.cpp @@ -973,13 +973,13 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx) case bmdFormat8BitARGB: st->codecpar->codec_id = AV_CODEC_ID_RAWVIDEO; st->codecpar->codec_tag = avcodec_pix_fmt_to_codec_tag((enum AVPixelFormat)st->codecpar->format);; - st->codecpar->format = AV_PIX_FMT_ARGB; + st->codecpar->format = AV_PIX_FMT_0RGB; st->codecpar->bit_rate = av_rescale(ctx->bmd_width * ctx->bmd_height * 32, st->time_base.den, st->time_base.num); break; case bmdFormat8BitBGRA: st->codecpar->codec_id = AV_CODEC_ID_RAWVIDEO; st->codecpar->codec_tag = avcodec_pix_fmt_to_codec_tag((enum AVPixelFormat)st->codecpar->format); - st->codecpar->format = AV_PIX_FMT_BGRA; + st->codecpar->format = AV_PIX_FMT_BGR0; st->codecpar->bit_rate = av_rescale(ctx->bmd_width * ctx->bmd_height * 32, st->time_base.den, st->time_base.num); break; case bmdFormat10BitRGB: -- 1.7.10.4