On 4/17/2023 8:51 AM, Anton Khirnov wrote:
Quoting James Almer (2023-04-17 13:32:16)
On 4/17/2023 7:49 AM, Anton Khirnov wrote:
Quoting James Almer (2023-04-12 21:49:32)
Signed-off-by: James Almer
---
Missing version bump and APIChanges entry.
libavutil/frame.h | 9 +
1 file cha
Today the decklink SDI output supports putting out captions over
VANC when the caption data is packet side data. However some
container formats such as MP4 support a dedicated subtitle stream,
and we end up receiving packets containing the 608 tuples separate
from the video frames.
Make use of a
This patch series implements output of SMPTE 2038 VANC over SDI, building
on the prior patch series which added it in the TS domain. Note that
we moved the AVPacketQueue to be common code within libavdevice so it
can be shared by both the decklink input and output.
Comments/feedback are welcome.
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 embed
the data into the video frame when it is output.
Note that this patch has some additional abstr
Move the AVPacketQueue functionality that is currently only used
for the decklink decode module into decklink_common, so it can
be shared by the decklink encoder (i.e. for VANC insertion when
we receive data packets separate from video).
Signed-off-by: Devin Heitmueller
---
libavdevice/decklink_
Hello all,
I am reaching out because the company I work for is using FFmpeg to perform
a variety of video processing tasks and we are in need of some assistance
optimizing the performance of some of these tasks.
Some background + platform specifications:
- Currently running a custom build of
From: Jan Ekström
The contents are full TTML XML documents. TTML writing tests'
results are updated as the streams are now properly identified
as TTML ones.
Signed-off-by: Jan Ekström
---
libavformat/mov.c| 11 +--
tests/ref/fate/mov-mp4-ttml-dfxp | 9 +
tests/
On 4/20/23 19:53, Michael Niedermayer wrote:
On Thu, Apr 20, 2023 at 12:54:59PM -0400, Leo Izen wrote:
The change introduced in b18a9c29713abc3a1b081de3f320ab53a47120c6
created a regression for non-subsampled progressive RGB jpegs. This
should fix that.
Additionally, this should fix other RGB J
THis filter can correct certain issues seen from upstream sources
where the cc_count is not properly set or the CEA-608 tuples are
not at the start of the payload as expected.
Make use of the ccfifo to extract and immediately repack the CEA-708
side data, thereby removing any extra padding and ens
Because the interlacing filter halves the effective framerate, we
need to ensure that no CEA-708 data is lost as frames are merged.
Make use of the new ccfifo mechanism to ensure that caption data
is properly preserved as frames pass through the filter.
Thanks to Thomas Mundt for review and notic
Various deinterlacing modes have the effect of doubling the
framerate, and we need to ensure that the caption data isn't
duplicated (or else you get double captions on-screen).
Use the new ccfifo mechanism for yadif (and yadif_cuda and bwdif
since they use the same yadif core) so that CEA-708 data
The existing implementation made an attempt to remove duplicate
captions if increasing the framerate, but made no attempt to
handle reducing the framerate, nor did it rewrite the caption
payloads to have the appropriate cc_count (e.g. the cc_count needs
to change from 20 to 10 when going from 1080i
When transcoding video that contains 708 closed captions, the
caption data is tied to the frames as side data. Simply dropping
or adding frames to change the framerate will result in loss of
data, so the caption data needs to be preserved and reformatted.
For example, without this patch convertin
This updated patch series addresses all issues reported to date.
Specifically, the latest round includes a memory leak spotted by
Lance Wang and the functions have been renamed to be prefixed with ff_
per James Almer's suggestion.
Thanks,
Devin
Devin Heitmueller (5):
ccfifo: Properly handle CE
On 4/17/2023 8:59 PM, James Almer wrote:
If it's not empty here, then a leak would ocurr immediately after.
Signed-off-by: James Almer
---
libavcodec/pcm_rechunk_bsf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/pcm_rechunk_bsf.c b/libavcodec/pcm_rechunk_bsf.c
index 032f91
Signed-off-by: James Almer
---
tests/fate/h264.mak | 4 ++
tests/ref/fate/h264-no-cropping | 95 +
2 files changed, 99 insertions(+)
create mode 100644 tests/ref/fate/h264-no-cropping
diff --git a/tests/fate/h264.mak b/tests/fate/h264.mak
index 17380
From: Zhao Zhili
Regression introduced by b40856.
Fix #10327.
---
fftools/ffmpeg_mux.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
index a2e8873ad2..b4b4dab8fd 100644
--- a/fftools/ffmpeg_mux.c
+++ b/fftools/ffmpeg_
17 matches
Mail list logo
