gnize this may cause
some breakage in existing applications.
Thoughts?
Devin
--
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com
___
ffmpeg-devel
+for (i = 0; i < 5; i++) {
> +bit_depth = depths[i];
Perhaps this should use FF_ARRAY_ELEMS(depths) rather than a hard-coded "5"?
Devin
--
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com e: devin.heitmu
> Does extracting really make sense? Doesn't the data end up out of
> order and basically unusable?
For what it’s worth, I’ve got a video filter which extracts the A53 side data
and saves it into an MCC file (Telestream MacCaption format). If people think
that’s something that would be useful,
Hello,
I’m doing some debugging of format selection for the decklink device, and in
particular trying to get it to properly support interlaced formats. One thing
that came to my attention was the following commit:
https://github.com/FFmpeg/FFmpeg/commit/48f8ad329010a93c323569cad695090a5930277b
Hi Marton,
> As far as I remember ffmpeg.c has code for this around line 1220:
>
> if (in_picture->interlaced_frame) {
> if (enc->codec->id == AV_CODEC_ID_MJPEG)
>mux_par->field_order = in_picture->top_field_first ?
> AV_FIELD_TT:AV_FIELD_BB;
> else
>mux_par->field_order
Hi James,
> No, this is done after that, while processing a packet.
> It is also making changes to the output codecpar after write_header()
> was called, which is wrong.
>
> libavformat used to delay writing the header until you feed it the first
> packet, an internal functionality this code here
t, but I really do think things like
V210 should be a raw frame colorspace rather than a codec. Then we would be
able to use a wrapped avframe for everything and wouldn’t lose all that data
when translating from an AVFrame to an AVPacket.
Devin
---
Devin Heitmueller - LTN Global Commun
scaler for format
conversion as needed).
Devin
---
Devin Heitmueller - LTN Global Communications
dheitmuel...@ltnglobal.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hello all,
> On Mar 24, 2018, at 6:37 AM, Michael Niedermayer
> wrote:
>
> On Sat, Mar 24, 2018 at 01:07:48AM +0100, Marton Balint wrote:
>>
>>
>> On Fri, 23 Mar 2018, Devin Heitmueller wrote:
>>
>>> Hello,
>>>
>>> I am in the
g new features to both capture and output, it would be
good to better understand which of the two structs is appropriate to own the
state information.
Thanks in advance,
Devin
---
Devin Heitmueller - LTN Global Communications
dheitmuel...@ltngloba
Hi Grady,
> On Mar 27, 2018, at 3:05 PM, grady player wrote:
>
> So I haven't looked in great detail so this may all be info that you know,
> and maybe not helpful...
>
> 1. You can easily link C objects to C++ code by marking it `extern "C"`
> 2. You can not easily link C++ objects to C code,
Hi John,
On Wed, Apr 25, 2018 at 5:11 PM, John P Poet wrote:
> I am working on a project where I need to insert a repeating image (10
> seconds) in the middle of a video stream while also transcoding from one
> video codec to another. The images are going to be either png or jpg
> images. I hav
This patch series provides a number of enhancements for both capture
and output using the decklink module, including addressing comments from
Marton Balint, Derek Buitenhuis, and James Almer.
Devin Heitmueller (8):
libavdevice/decklink: Add support for EIA-708 output over SDI
decklink: Add
Implement support for including AFD in decklink output. This
includes making sure the AFD data is preserved when going from
an AVFrame to a V210 packet (needed for 10-bit support).
Updated to reflect feedback from Marton Balint
Signed-off-by: Devin Heitmueller
---
libavcodec/avcodec.h
: https://github.com/stoth68000/libklvanc
Updated to reflect feedback from Marton Balint
Signed-off-by: Devin Heitmueller
---
configure | 4 ++
libavcodec/v210enc.c| 10 +++
libavdevice/decklink_common.cpp | 17 +++--
libavdevice/decklink_common.h | 10
This is needed to ensure that AFD data continues to work when
capturing V210 video with the Decklink libavdevice input.
Signed-off-by: Devin Heitmueller
---
libavcodec/decode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 3f5b086f7e
Add support for the ability to capture all audio pairs available
to the capture hardware. Each pair is exposed as a different audio
stream, which matches up with the most common use cases for the
broadcast space (i.e. where there is one stereo pair per audio
language).
To support the existing use
feedback from Derek Buitenhuis
Signed-off-by: Devin Heitmueller
---
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 6
libavdevice/decklink_common.h | 6
libavdevice/decklink_common_c.h | 1 +
libavdevice/decklink_dec.cpp| 61 ++
types (i.e. videotoolbox, etc).
Updated to reflect feedback from Derek Buitenhuis
Signed-off-by: Devin Heitmueller
---
libavcodec/internal.h | 3 +++
libavcodec/libx264.c | 47 +++
libavcodec/utils.c| 36
3 files
Make use of libklvanc from within the decklink capture module,
initially for EIA-708 and AFD. Support for other VANC types will
come in subsequent patches.
Incorporates feedback from Derek Buitenhuis
and James Almer
Signed-off-by: Devin Heitmueller
---
libavdevice/decklink_dec.cpp | 133
ltraStudio Mini Monitor'
Note that the default behavior continues to be to do PCM output,
which means without specifying the copy codec a stream containing
AC-3 will be decoded and downmixed to stereo audio before output.
Signed-off-by: Devin Heitmueller
---
libavdevice/de
Hi Carl,
Thanks for your feedback. Comments inline>
> On Dec 29, 2017, at 3:41 PM, Carl Eugen Hoyos wrote:
>
> 2017-12-29 19:12 GMT+01:00 Devin Heitmueller :
>
>> +side_data = av_frame_get_side_data(pic, AV_FRAME_DATA_A53_CC);
>> +if (s
> On Dec 29, 2017, at 3:48 PM, Carl Eugen Hoyos wrote:
>
> 2017-12-29 19:12 GMT+01:00 Devin Heitmueller :
>
>> +/* FIXME: Should really rely on the coded_width but seems like that
>> + is not accessible to libavdevice outputs */
>> +if
> On Dec 29, 2017, at 3:59 PM, Carl Eugen Hoyos wrote:
>
> 2017-12-29 19:12 GMT+01:00 Devin Heitmueller :
>
>> +uint8_t *outbuf = NULL;
>
>> +if (st->codecpar->codec_id == AV_CODEC_ID_AC3)
>> +av_free(outbuf);
>
> The "if()&qu
Hi Carl,
> On Dec 29, 2017, at 3:55 PM, Carl Eugen Hoyos wrote:
>
> 2017-12-29 19:12 GMT+01:00 Devin Heitmueller :
>
>> +for (int i = 0; i < ctx->max_audio_channels / 2; i++) {
>> +st = avformat_new_stream(avctx, NULL);
>> +i
> On Dec 29, 2017, at 4:09 PM, Carl Eugen Hoyos wrote:
>
> 2017-12-29 22:02 GMT+01:00 Devin Heitmueller :
>>
>>> On Dec 29, 2017, at 3:48 PM, Carl Eugen Hoyos wrote:
>>>
>>> 2017-12-29 19:12 GMT+01:00 Devin Heitmueller :
>>>
>>>&g
> On Dec 29, 2017, at 4:17 PM, Carl Eugen Hoyos wrote:
>
> 2017-12-29 22:14 GMT+01:00 Devin Heitmueller :
>> Hi Carl,
>>
>>> On Dec 29, 2017, at 3:55 PM, Carl Eugen Hoyos wrote:
>>>
>>> 2017-12-29 19:12 GMT+01:00 Devin Heitmuel
Hello Aaron,
Thanks for the feedback. Comments inline.
On Sat, Dec 30, 2017 at 12:34 AM, Aaron Levinson
wrote:
> Technically, there are a number of 2K and 4K video modes supported by some
> DeckLink cards that have a 16x9 aspect ratio as well. This code would treat
> such video modes at 4:3.
Hi Aaron,
Comments inline:
>
> Most of the changes in this set of patches appear to only be relevant in the
> case that libklvanc is enabled. Nevertheless, a number of the changes are
> not wrapped in #if CONFIG_LIBKLVANC, which means that they will be exercised
> even if libklvanc is not ava
Hi Aaron,
>> +ret = ff_alloc_afd_sei(frame, 0, &sei_data, &sei_size);
>> +if (ret < 0) {
>> +for (i = 0; i < num_payloads; i++)
>> +av_free(x4->pic.extra_sei.payloads[i].payload);
>> +av_free(x4->pic.extra_sei.payloads);
>
Hi Aaron,
> On Dec 30, 2017, at 2:34 AM, Aaron Levinson wrote:
>
> Patch title: "suppoort" -> "support", also "decklink" -> “DeckLink"
Ok.
>>ff_decklink_cleanup(avctx);
>> avpacket_queue_end(&ctx->queue);
>> +klvanc_context_destroy(ctx->vanc_ctx);
>
> Shouldn't this last lin
> On Dec 30, 2017, at 3:11 AM, Aaron Levinson wrote:
>
> On 12/29/2017 10:12 AM, Devin Heitmueller wrote:
>> Make use of libklvanc to parse SCTE-104 packets and announce them
>> as a new stream. Right now we just pass the payload straight
>> through, but once this
>> +if (ctx->max_audio_channels > DECKLINK_MAX_AUDIO_CHANNELS) {
>> +av_log(avctx, AV_LOG_WARNING, "Decklink card reported support for
>> more channels than ffmpeg supports\n");
>
> "Decklink" -> "DeckLink", "ffmpeg" -> "FFmpeg". Also, I think it is
> preferable to not state "FFmpe
Hello Matthias,
Thanks for the feedback. Comments inline:
> On Jan 2, 2018, at 4:52 AM, Matthias Hunstock wrote:
>
> Am 29.12.2017 um 19:12 schrieb Devin Heitmueller:
>> To support the existing use case where multi-channel audio can be
>> captured (i.e. 7.1)
>
> Ju
Hi Aaron,
>> +static int create_s337_payload(AVPacket *pkt, enum AVCodecID codec_id,
>> uint8_t **outbuf, int *outsize)
>> +{
>> +uint8_t *s337_payload;
>> +uint8_t *s337_payload_start;
>> +int i;
>> +
>> +/* Encapsulate AC3 syncframe into SMPTE 337 packet */
>> +*outsize = (
Implement support for including AFD in decklink output. This
includes making sure the AFD data is preserved when going from
an AVFrame to a V210 packet (needed for 10-bit support).
Updated to reflect feedback from Marton Balint ,
Carl Eugen Hoyos and Aaron Levinson
.
Signed-off-by: Devin
use case where multi-channel audio can be
captured (i.e. 7.1), we introduced a new configuration option, which
defaults to the existing behavior.
Updated to reflect comments from Carl Eugen Hoyos ,
Aaron Levinson , and Matthias Hunstock
.
Signed-off-by: Devin Heitmueller
---
doc/indevs.texi
types (i.e. videotoolbox, etc).
Updated to reflect feedback from Derek Buitenhuis
and Aaron Levinson .
Signed-off-by: Devin Heitmueller
---
libavcodec/internal.h | 3 +++
libavcodec/libx264.c | 47 +++
libavcodec/utils.c| 36
: https://github.com/stoth68000/libklvanc
Updated to reflect feedback from Marton Balint ,
Carl Eugen Hoyos , and Aaron Levinson
.
Signed-off-by: Devin Heitmueller
---
configure | 4 +
libavcodec/v210enc.c| 9 ++
libavdevice/decklink_common.cpp | 16
This patch series provides a number of enhancements for both capture
and output using the decklink module, including addressing comments from
Marton Balint, Derek Buitenhuis, James Almer, Carl Eugen Hoyos, and
Aaron Levinson.
Devin Heitmueller (11):
libavdevice/decklink: Add support for EIA-708
Make use of libklvanc from within the DeckLink capture module,
initially for EIA-708 and AFD. Support for other VANC types will
come in subsequent patches.
Incorporates feedback from Derek Buitenhuis ,
James Almer , and Aaron Levinson
Signed-off-by: Devin Heitmueller
---
libavdevice
This is needed to ensure that AFD data continues to work when
capturing V210 video with the Decklink libavdevice input.
Signed-off-by: Devin Heitmueller
---
libavcodec/decode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index f67b214..14660ac
rom Derek Buitenhuis
and Aaron Levinson
Signed-off-by: Devin Heitmueller
---
doc/indevs.texi | 4 +++
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 6
libavdevice/decklink_common.h | 6
libavdevice/decklink_common_c.h | 1 +
libavdev
ltraStudio Mini Monitor'
Note that the default behavior continues to be to do PCM output,
which means without specifying the copy codec a stream containing
AC-3 will be decoded and downmixed to stereo audio before output.
Updated to reflect feedback from Aaron Levinson
Signed-off-b
When building with Clang, the following warning is shown:
warning: struct 'IDeckLinkVideoFrame' was previously declared as a
class [-Wmismatched-tags]
The function incorrectly casts IDeckLinkVideoFrame as a struct
instead of a class pointer.
Signed-off-by: Devin Heitmueller
---
l
Add a line to show the SDK version used in the build, if loglevel
is set to verbose. This is simply to aid in debugging when
building against different SDKs.
Signed-off-by: Devin Heitmueller
---
libavdevice/decklink_common.cpp | 4
1 file changed, 4 insertions(+)
diff --git a/libavdevice
magic SDK sources, so
suppress the warning just for that one #include.
Signed-off-by: Devin Heitmueller
---
libavdevice/decklink_common.cpp | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index b033e63..c0b3c93 1
Hello Moritz,
> On Wed, Jan 10, 2018 at 14:29:43 +0100, Moritz Barsnick wrote:
>>> +for (size_t i = 0; i < cc_count; i++) {
>> Declare i outside the clause.
>>> +for (int i = 0; i < vanc_lines.num_lines; i++) {
>> Same here.
>
> Sorry, this rule may not apply to C++ files, as it's par
Hello Marton,
Thank you for the feedback. Comments inline.
>> +vanc_ctx->callback_context = &cb_ctx;
>> +int ret = klvanc_packet_parse(vanc_ctx, lineNr, decoded_words,
>> sizeof(decoded_words) / (sizeof(uint16_t)));
>
> A parity error also causes a negative return value? Or par
Hi Ray,
Thanks for your patch. A few questions:
Could you confirm whether you are capturing via SDI or analog (i.e.
composite/component)? Also what is the capturing device and SDK version you
are using? I’ve found various bugs in the numbering of VANC lines in some
cards, particularly with
Hi Ray,
> On Jan 22, 2018, at 10:47 PM, Ray Tiley wrote:
>> Could you confirm whether you are capturing via SDI or analog (i.e.
>> composite/component)? Also what is the capturing device and SDK version
>> you are using? I’ve found various bugs in the numbering of VANC lines in
>> some cards, p
Hi Ray,
> On Jan 22, 2018, at 11:20 PM, Ray Tiley wrote:
>
> I'm reading 334-1:2017 Sec 4
> "When the ANC packets defined in this standard are carried in a high
> definition signal, they shall be carried in the Y stream."
>
> I couldn't find anywhere in the document where it calls out standard
Hi Ray,
>
> Please find updated patch attatched. I reverted the vanc lines changes and
> found that all my tests worked as expected, so not sure what was wrong w/
> my original test. The need to extract vanc from the entire line vs just the
> luma in NTSC is still required.
It’s helpful if in th
Hello Marton,
> I thought you are working on an updated patch, or I just missed the new one?
> The email you replied to here definitely contains the old, without
> interleaved VANC autodetection or proper width for get_metadata.
I did some digging into this after discussion with Ray (both by re
Hi Marton,
>
> Have you found which standard contains reference to interleaved VANC?
So SMPTE falls back onto the earlier standards for digital video bitstreams as
defined in ITU BT.656 (for SD) and BT.1120 (for HD).
>
>>
>> That said, the list of modes should probably be expanded to include
> On Mar 7, 2018, at 12:49 PM, Michael Niedermayer
> wrote:
>
> On Tue, Mar 06, 2018 at 02:25:12PM -0800, Aman Gupta wrote:
>> From: Aman Gupta
>>
>> Some streams include both a53 and scte20 data. Before this commit,
>> the scte20 data would be used instead of the a53 data.
>>
>> See https:/
> From what I've seen in US broadcast television, scte20 is only used on
> standard-def content and everything else uses normal a53.
A53 is definitely the more popular standard, and all that is approved for
distribution in digital over the air broadcasts. SCTE-20 would only be found
further up
>> +ffmpeg -re -f lavfi -i "testsrc=s=1920x1080:rate=3/1000" -f lavfi -i
>> "sine=frequency=1000:sample_rate=48000" +-ac 2 -acodec pcm_s16le
>> -pix_fmt uyvy422 -format_code Hi30 -f decklink 'DeckLink Studio 2'
>
> You should not need the -re flag, the decklink outdev blocks if it g
> The decklink outdev finds the correct mode by searching for the properties
> (frame rate, field order, dimension) of the stream which is provided to it.
> So specifying the format_code should not be needed.
In principle you are correct that it "should not be needed". However
there are numerous
on't have the expertise necessary to modify the
actual libavcodec HEVC decoder to do the interleaving. If somebody
were to fix the decoder itself then I could throw away all those
hacks.
Regards,
Devin
--
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o
On Mon, Jul 31, 2023 at 9:38 AM Devin Heitmueller
wrote:
>
> Properly set up the MPEG-TS mux and recalculate the pts_adjust field
> in SCTE_35 packets, such that a user can transparently pass through
> SCTE-35 streams when both the input and output are MPEG-TS.
>
> This patch
On Fri, Aug 4, 2023 at 7:16 AM Devin Heitmueller
wrote:
>
> On Mon, Jul 31, 2023 at 9:38 AM Devin Heitmueller
> wrote:
> >
> > Properly set up the MPEG-TS mux and recalculate the pts_adjust field
> > in SCTE_35 packets, such that a user can transparently pass throu
pt to tackle the problem of the SCTE-35
timestamp not being as accurate as it could be.
Devin
--
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com
___
Thanks,
Devin
--
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman
On Thu, Aug 10, 2023 at 8:48 AM Kieran Kunhya wrote:
>
>
>
> On Thu, 10 Aug 2023 at 08:41, Kieran Kunhya wrote:
>>
>> On Thu, 10 Aug 2023 at 08:20, Devin Heitmueller
>> wrote:
>>>
>>> On Thu, Aug 10, 2023 at 8:13 AM Kieran Kunhya wrote:
>&
to solve
some orthogonal problem that I'm not really worried about isn't
grounds for rejecting it.
I would be happy to see other developers weigh in, or if Kieran's is
the final word then I would like to see this reviewed by the TC. I'm
making a genuine effort to improve the s
7m avformat
module might also be an option but it's harder since the s337m module
expects AVIOBufs which is more difficult to provide.
Devin
--
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal
check for first_dts_check will
always fail).
FWIW, the basic change is definitely useful, as I've had a nearly
identical patch in my tree for some time:
https://github.com/LTNGlobal-opensource/FFmpeg-ltn/commit/b974e431f7de39401a04d2c6e9bbdcc21e2982da
Devin
--
Devin Heitmueller, Senior Software En
> note, to make this clear there will be no ffmpeg.org or mplayerhq.hu
> soon if noone helps
> we need a server we need volunteers to help with the move
Is there anything you can share about what the current bandwidth
requirements are? It might make it easier to assess whether it's
feasible to ho
Given the questions regarding the format used for the timecodes, this
patch from my personal repo might help:
commit e4c9ae661fb55e59eff1461140a8cd039b7c3f04
Author: Devin Heitmueller
Date: Thu Jul 5 17:18:36 2018 -0400
Clarify where the binary representation comes from for ffmpeg's
higher framerates
to support SMPTE 12-3 (which supports fps > 60), but that should be a
different side data field. Right now the most important thing is that
the behavior be consistent across decoders.
Devin
--
Devin Heitmueller, Senior Software Engineer
LTN Global Communication
> I'm leaning toward 2, but there would need to be some other way to deal
> with people not getting along. Maybe Mumble conferences where the
> involved parties get to air their feelings on whatever is at issue? I
> dunno
I'm not weighing in on the CoC so much as offering my experience with
other
Hello Aman,
On Thu, May 17, 2018 at 8:04 PM, Aman Gupta wrote:
> From: Aman Gupta
>
> Some filtered mpegts streams may erroneously include PMTs for programs
> that are not advertised in the PAT. This confuses ffmpeg and most
> players because multiple audio/video streams are created and it is
>
selection of audio/video in MPEG-TS
streams behave differently than other formats).
Thoughts?
Devin
---
Devin Heitmueller - LTN Global Communications
dheitmuel...@ltnglobal.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hello Gyan,
Thanks for your comments. See inline:
> On May 18, 2018, at 10:24 AM, Gyan Doshi wrote:
> If nb_input_files is 1, coupling the stream selection seems to me an
> improvement. But in the scenario of multiple inputs and no -map options,
> users usually intend to want a stream from al
> The issue is that the PMT PID advertised in the PAT contains multiple PMTs
> for different programs. This is because the broadcaster decided to re-use
> the same PID for multiple program PMTs.
Ugh, ok. I understand the case you're talking about now. Thanks for
clarifying.
> To be clear, this
>
> I'd rather see a new AVPacketSideData type which will contain the timecode as
> a string, so you can set it frame-by-frame.
For what it’s worth, this is what I’ve done on the decklink output side. I’ve
introduced a new side data type and I’m able to decode timecodes provided in
H.264 stre
Hello Ibrahim,
> I do have another issue with Audio sync when segmenting live content coming
> from satellite but without encoding (stream copying only). And since you
> cannot use aresample when copying I am unsure how you would go about to
> solve that issue.
I can make a few general suggestion
it
was to insert a split filter on the video stream and feed both the actual video
encoder and a second encoder instance which throws away the video frames and
just acts on the side data to create the caption stream.
And of course you have same problem in the other direction - if you rece
> On Jul 16, 2018, at 2:56 PM, Jonathan Morley wrote:
>
> That is really interesting feedback guys. I have been thinking about things
> mostly in a MOV independent timecode track (or tracks) kind of way, but I
> know OMF, MXF, AAF, etc handle it more analogously to packet/frame side data.
>
>
it has some optimized assembly worth
looking closer at, but my gut reaction is that it’s likely just that
libswscale’s defaults to a higher quality scaler (at the associated cost), and
you can achieve comparable numbers as found in libyuv by tweaking the
configuration.
Devin
mber of commercial hardware encoders I’ve worked with.
We can debate the mechanics of how the buffers are referenced (which is why I
believe it wasn’t merged last year), but I can say that this is a very real
problem and at least this patch results in those streams playing properly.
Cheers,
The following patches add support for output of 708 and AFD over
the Decklink SDI interface. This series is a subset of a series
submitted in early January, with the hope of getting the less
controversial parts merged upstream.
Devin Heitmueller (2):
libavdevice/decklink: Add support for EIA
Implement support for including AFD in decklink output. This
includes making sure the AFD data is preserved when going from
an AVFrame to a V210 packet (needed for 10-bit support).
Updated to reflect feedback from Marton Balint ,
Carl Eugen Hoyos and Aaron Levinson
.
Signed-off-by: Devin
: https://github.com/stoth68000/libklvanc
Updated to reflect feedback from Marton Balint ,
Carl Eugen Hoyos , Aaron Levinson
, and Moritz Barsnick
Signed-off-by: Devin Heitmueller
---
configure | 4 +
libavcodec/v210enc.c| 9 ++
libavdevice/decklink_common.cpp
ad, and use that to determine the actual PTS of the embedded
non-PCM packet? Unless I"m misreading the code, it seems like it's
simply setting the PTS of the non-pcm packet to be the PTS of the
original S302 packet, which will result in incorrect A/V sync.
Devin
--
Devin Heitmueller, Se
ious one.
I knew the Dolby-E packet had to be cotimed with the video frame, but
was unaware that the S302M packets also had that requirement. But
yeah, now that I look at the spec I see that to be the case
(S302M-2007 Sec 6.10).
Devin
--
Devin Heitmueller, Senior Software Engineer
LTN Global Comm
on what
major platforms/versions we expect to be able to build on.
Devin
--
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com
___
ffmpeg-devel mailing list
On Mon, Feb 5, 2024 at 3:31 PM Anton Khirnov wrote:
>
> Quoting Devin Heitmueller (2024-02-05 21:13:22)
> > On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov wrote:
> > >
> > > It should be available in all relevant modern compilers and will allow
> > > u
e impact and conclude whether
it's worth it, but it doesn't effect any of my use cases and (in my
opinion) there are likely to be far fewer users impacted by such a
change.
This feels like just the sort of thing the TC is meant to
discuss/resolve. And the fact that your positio
Hello Marton,
On Fri, May 12, 2023 at 11:09 AM Devin Heitmueller
wrote:
>
> The existing DecklinkQueue implementation was using the PacketList
> structure but wasn't using the standard avpriv_packet_list_get and
> avpriv_packet_list_put functions. Convert to using them so w
Hello Marton,
On Fri, Apr 28, 2023 at 1:45 PM Devin Heitmueller
wrote:
>
> Support decoding and embedding VANC packets delivered via SMPTE 2038
> into the SDI output. We leverage an intermediate queue because
> data packets are announced separately from video but we need to embe
the patches to the
H.264/HEVC decoders and libx264 to properly handle the SEI data.
Devin Heitmueller (7):
Preserve AFD side data when going from AVPacket to AVFrame
vf_drawtext: Add ability to show AFD value
avcodec/avframe: add new side data types for Bar Data
libavfilter: Add filter to
This is needed to ensure that AFD data continues to work when
capturing V210 video with the Decklink libavdevice input.
Signed-off-by: Devin Heitmueller
---
libavcodec/decode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index a7c1302..6ee2c85
Add new side data types for both AVPacket and AVFrame to support
"bar data" as defined in SMPTE 2016-1, ATSC A/53, and SCTE 128-1.
Signed-off-by: Devin Heitmueller
---
libavcodec/decode.c | 1 +
libavcodec/defs.h | 12
libavcodec/packet.h | 6 ++
libavutil/fram
Introduce a new filter which allows the user to manually set the
AFD or bar data side data on AVFrames.
Signed-off-by: Devin Heitmueller
---
doc/filters.texi | 52 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_afd.c | 133
ot;:fontsize=32:x=10:y=50:fontcolor=blue
burnin.ts
Signed-off-by: Devin Heitmueller
---
doc/filters.texi | 5 +
libavfilter/vf_drawtext.c | 19 +++
2 files changed, 24 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index a46357b..9179c20 100644
--
Add a new description for bar data, so that the presence of bar
data can be seen through ffprobe.
Signed-off-by: Devin Heitmueller
---
libavutil/frame.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index b6cee2d..03d1b31 100644
--- a/libavutil
When encoding to V210, make sure the bar side data makes it through
in the resulting AVPacket. This is needed so the decklink output
module can put out bar data as VANC when in 10-bit mode.
Signed-off-by: Devin Heitmueller
---
libavcodec/v210enc.c | 8
1 file changed, 8 insertions
SMPTE ST2016-3 supports both AFD and bar data within the VANC message.
Extend the existing support to pass through both.
Example usage:
ffmpeg -i input.ts -vf setafd=afd=1:code=0x00:bardata=1:top=100:bottom=120 -f
decklink -vcodec v210 'DeckLink Duo (4)'
Signed-off-by: Devin H
101 - 200 of 329 matches
Mail list logo
