On Wed, 22 May 2024 11:10:31 -0400
"Ronald S. Bultje" wrote:
> Hi,
>
> On Wed, May 22, 2024 at 10:36 AM Hendrik Leppkes
> wrote:
>
> > On Thu, Feb 29, 2024 at 7:19 AM llyyr wrote:
> > >
> > > segmentation.update_map is never reset to 0 on a new frame, and
> > > retains the value from the pr
On Tue, 14 May 2024 19:07:59 -0700
Philip Langdale via ffmpeg-devel wrote:
> On Wed, 15 May 2024 01:36:43 +0530
> llyyr.pub...@gmail.com wrote:
>
> > From: llyyr
> >
> > ab77b878f1 attempted to fix the issue of broken packets being sent
> > to the decode
On Wed, 15 May 2024 01:36:43 +0530
llyyr.pub...@gmail.com wrote:
> From: llyyr
>
> ab77b878f1 attempted to fix the issue of broken packets being sent to
> the decoder by implementing logic that kept attempting to PTS-step
> backwards until it reached a valid point, however applying this
> heuris
On Wed, 31 Jan 2024 17:34:08 +0100 (CET)
Lynne wrote:
> The configure check already had fallback for the previous version
> of glslang, which had different requirements for flags.
> This commit simply moves the flags needed for glslang 13 to the
> fallback, while first trying to use new flags for
On Sat, 2 Dec 2023 23:02:36 +0100
Thomas Mundt wrote:
>
> LGTM, thanks.
>
I am going to squash the three commits and push. There's no real need
to put each filter in a separate diff when the logical change is
identical in all three.
Thanks,
--phil
On Sun, 29 Oct 2023 07:22:46 +0100 (CET)
Lynne wrote:
> Due to making the decode frames context use the coded size, the
> filter started to display those artifacts as it reused the input
> frame's size.
>
> Change it to instead output the real image size for images, not the
> input.
>
> Patch a
On Fri, 27 Oct 2023 12:00:10 +0200
David Rosca wrote:
> This allows some optimizations in driver, such as not having to read
> back the data if write-only mapping is requested.
> ---
> v3: Fix another warning
>
> libavutil/hwcontext_vaapi.c | 11 +++
> 1 file changed, 11 insertions(+)
>
On Fri, 27 Oct 2023 23:37:01 +0800
Zhao Zhili wrote:
> From: Zhao Zhili
>
> av_hwframe_transfer_data try with src_ctx first. If the operation
> failed with AVERROR(ENOSYS), it will try again with dst_ctx. Return
> AVERROR(EINVAL) makes the second step being skipped.
> ---
> libavutil/hwcontext
On Fri, 27 Oct 2023 23:37:00 +0800
Zhao Zhili wrote:
> From: Zhao Zhili
>
> Move it to transfer_get_formats.
> ---
> libavutil/hwcontext_vulkan.c | 25 +
> 1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/libavutil/hwcontext_vulkan.c
> b/libavutil/hwc
On Thu, 5 Oct 2023 23:26:38 +0200 (CEST)
Lynne wrote:
> This fixes filtering on Nvidia.
>
> Patch attached.
>
Tested locally. Filtering works and vulkan validation passes.
Ship it!
--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https:
As we are introducing two new formats and supporting conversions
between them, and also with the existing 0rgb32/0bgr32 formats, we get
a combinatorial explosion of kernels. I introduced a few new macros to
keep the things mostly managable.
The conversions are all simple, following existing patter
As we are introducing two new formats and supporting conversions
between them, and also with the existing 0rgb32/0bgr32 formats, we get
a combinatorial explosion of kernels. I introduced a few new macros to
keep the things mostly managable.
The conversions are all simple, following existing patter
On Sat, 10 Jun 2023 19:59:35 -0700
Philip Langdale wrote:
> These are physically compatible formats and are potentially useful.
>
> Signed-off-by: Philip Langdale
> ---
> libavutil/hwcontext_cuda.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/liba
On Wed, 14 Jun 2023 20:04:35 -0700
Philip Langdale wrote:
> I'm not sure why I originally did this, but there's no good reason to
> put pointers to the cuda context and stream in the priv struct. They
> are directly available in the device context that is already b
I've been sitting on this for 3 1/2 years now(!), and I finally got
around to fixing the loose ends and convincing myself that it was
correct. It follows the same basic structure as yadif_cuda, including
leaving out the edge handling, to avoid expensive branching.
Signed-off-by: Philip Lan
I'm not sure why I originally did this, but there's no good reason to
put pointers to the cuda context and stream in the priv struct. They
are directly available in the device context that is already being
stored there.
Signed-off-by: Philip Langdale
---
libavfilter/vf_yadif_c
These are physically compatible formats and are potentially useful.
Signed-off-by: Philip Langdale
---
libavutil/hwcontext_cuda.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
index 5ae7711c94..22eb9f5513 100644
--- a/libavutil
I've been sitting on this for 3 1/2 years now(!), and I finally got
around to fixing the loose ends and convincing myself that it was
correct. It follows the same basic structure as yadif_cuda, including
leaving out the edge handling, to avoid expensive branching.
Signed-off-by: Philip Lan
On Sat, 25 Mar 2023 00:02:03 +0100
Thomas Mundt wrote:
> Hi Philip,
>
> Philip Langdale schrieb am Fr., 24. März 2023,
> 23:21:
>
> > bwdif inherited this check from yadif, which was originally
> > supposed to prefer the spatial predictor if the temporal pr
On Wed, 7 Jun 2023 01:23:24 +0200 (CEST)
Lynne wrote:
> From eb74297de8662c9fa66cd719c6315567966afe56 Mon Sep 17 00:00:00 2001
> From: Lynne
> Date: Wed, 7 Jun 2023 01:16:29 +0200
> Subject: [PATCH 2/2] vulkan: discard dependencies when explicitly
> waiting for execution
>
> This reduces memory
On Wed, 7 Jun 2023 01:59:55 +0200 (CEST)
Lynne wrote:
> Jun 7, 2023, 01:45 by d...@lynne.ee:
>
> > Jun 7, 2023, 01:22 by d...@lynne.ee:
> >
> >> vkResetFences is specified as being user-synchronized
> >> (yet vkWaitFences, is not).
> >>
> >> Patch attached.
> >>
> >
> > Stray change in vulkan_de
On Wed, 7 Jun 2023 01:22:25 +0200 (CEST)
Lynne wrote:
> From c79aa3ed01033f515cbb21251e83cb5bafdf83d7 Mon Sep 17 00:00:00 2001
> From: Lynne
> Date: Wed, 7 Jun 2023 00:24:43 +0200
> Subject: [PATCH 1/2] vulkan: synchronize access to execution pool
> fences
>
> vkResetFences is specified as bein
On Tue, 6 Jun 2023 13:03:43 +0200 (CEST)
Lynne wrote:
> It was introduced for Vulkan, but it is equivalent to
> short_term_ref_pic_set_size when !short_term_ref_pic_set_sps_flag,
> and when !!short_term_ref_pic_set_sps_flag, Vulkan hardcodes a zero
> anyway.
>
> 3-line patch attached.
>
LGTM
context on both sides, and the only way to propagate
the cuda context all the way through is to derive the device at each
stage.
ie:
-vf hwupload=derive_device=vulkan,,hwupload=derive_device=cuda
Signed-off-by: Philip Langdale
---
libavutil/hwcontext_vulkan.c | 25 ++---
1 file
context on both sides, and the only way to propagate
the cuda context all the way through is to derive the device at each
stage.
ie:
-vf hwupload=derive_device=vulkan,,hwupload=derive_device=cuda
Signed-off-by: Philip Langdale
---
libavutil/hwcontext_vulkan.c | 5 +
1 file changed, 5 insertions
On Wed, 31 May 2023 19:55:19 +0200 (CEST)
Lynne wrote:
> + May 31st, 2023, Vulkan decoding
> +
> + Recently, Vulkan-powered decoding hardware acceleration code was
> merged into the codebase.
> + This is the first vendor-generic and platform-generic decode
> acceleration API, enabling th
On Mon, 29 May 2023 04:08:17 +0200 (CEST)
Lynne wrote:
> According to Dave Airlie:
>
> > but I think ignoring it should be fine, I can't see any
> > other way to get the imaeg extents correct for other usage
> > what width/height should be used for the images?
> > the final presentable dimensi
On Wed, 08 Feb 2023 19:38:07 +0200
Rémi Denis-Courmont wrote:
> Le keskiviikkona 8. helmikuuta 2023, 16.27.52 EET Devin Heitmueller a
> écrit :
> > On Wed, Feb 8, 2023 at 8:08 AM Jean-Baptiste Kempf
> > wrote:
> > > Do we really need those PIX_FMT in FFmpeg public API?
> >
> > Tiled formats
On Tue, 31 Jan 2023 13:17:56 +0100
Anton Khirnov wrote:
> The hardware is old and not relevant today. The decoders also have
> many special quirks and are effectively unmaintained.
> ---
> Philip confirmed on IRC that he no longer has the hardware for
> maintaining this and does not believe it is
On Tue, 3 Jan 2023 02:39:19 +0300
Dennis Mungai wrote:
> Related,
>
> If this were to be implemented in mpv, can libplacebo pick up this
> feature spec as a filter in ffmpeg? Perhaps that would make such a
> feature easier to merge down the line, instead of re-implementing it
> directly in ffmpe
.
Is this mergeable? No - but it was an interesting exercise and maybe
folks in narrow circumstances may find some genuine use from it.
Signed-off-by: Philip Langdale
---
configure | 7 +-
libavfilter/Makefile | 1 +
libavfilter/allfilters.c
it be if nvidia had sane licensing on this stuff?
I'll keep a branch at: https://github.com/philipl/FFmpeg/tree/fruc-me
--phil
Philip Langdale (2):
lavu/hwcontext_cuda: declare support for argb/abgr/rgba/bgra
avfilter/vf_nvoffruc: Add filter for nvidia's Optical Flow FRUC
library
These can be useful.
Signed-off-by: Philip Langdale
---
libavutil/hwcontext_cuda.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
index 5ae7711c94..22eb9f5513 100644
--- a/libavutil/hwcontext_cuda.c
+++ b/libavutil
On Fri, 9 Dec 2022 15:16:17 +0100
Timo Rothenpieler wrote:
> ---
> libavcodec/nvdec.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
> index fbaedf0b6b..a477449d14 100644
> --- a/libavcodec/nvdec.c
> +++ b/libavco
On Fri, 9 Dec 2022 15:16:16 +0100
Timo Rothenpieler wrote:
> ---
> doc/APIchanges | 3 +++
> libavcodec/avcodec.h | 16
> libavcodec/options_table.h | 1 +
> libavcodec/version.h | 4 ++--
> 4 files changed, 22 insertions(+), 2 deletions(-)
>
> diff
On Mon, 5 Dec 2022 23:25:59 +0100
Timo Rothenpieler wrote:
> ---
> libavcodec/nvdec.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
> index fbaedf0b6b..76ee395734 100644
> --- a/libavcodec/nvdec.c
> +++ b/libavco
On Mon, 5 Dec 2022 23:25:58 +0100
Timo Rothenpieler wrote:
> ---
> doc/APIchanges | 3 +++
> libavcodec/avcodec.h | 11 +++
> libavcodec/options_table.h | 1 +
> libavcodec/version.h | 2 +-
> 4 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/
t, as the channels are all bit-aligned inside a 32bit word.
Signed-off-by: Philip Langdale
---
libavutil/pixdesc.c | 70 -
1 file changed, 50 insertions(+), 20 deletions(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index ca3e204a0b..62a
On Fri, 4 Nov 2022 12:40:16 +0100
Timo Rothenpieler wrote:
> The encoder seems to be trading blows with hevc_nvenc.
> In terms of quality at low bitrate cbr settings, it seems to
> outperform it even. It produces fewer artifacts and the ones it
> does produce are less jarring to my perception.
>
On Sat, 29 Oct 2022 19:12:44 +0200
Timo Rothenpieler wrote:
> ---
> configure | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 70c9e41dcc..30f0ce4e26 100755
> --- a/configure
> +++ b/configure
> @@ -6757,7 +6757,8 @@ enabled mmal
On Tue, 18 Oct 2022 15:31:21 +0200
Andreas Rheinhardt wrote:
> This file is built iff said hwaccel is enabled.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/nvdec_mjpeg.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/libavcodec/nvdec_mjpeg.c b/libavcodec/nvdec_mjpeg.c
On Sat, 17 Sep 2022 21:13:37 +0200
Michael Niedermayer wrote:
> > ---
> > libavutil/pixdesc.c | 31 +++-
> > libavutil/pixdesc.h | 15 ++--
> > libavutil/tests/pixfmt_best.c | 129
> > +- tests/ref/fate/pixfmt_best|
> > 2 +- 4 files c
have a smaller penalty than having greater than
needed chroma resolution.
v5: Update fate reference.
Signed-off-by: Philip Langdale
---
libavutil/pixdesc.c | 31 +++-
libavutil/pixdesc.h | 15 ++--
libavutil/tests/pixfmt_best.c | 129 +++
On Fri, 18 Jun 2021 23:07:58 +0200
Timo Rothenpieler wrote:
> >> +
> >> +if (inflateInit2(&stream, 32 + 15) != Z_OK) {
> >
> > Can you add a comment explaining the magic numbers?
>
> I have no idea what those numbers do, I copied them from http.c and
> they work.
Heh.
So, I read this:
On Fri, 11 Jun 2021 16:43:07 +0200
Timo Rothenpieler wrote:
> ---
> configure | 2 +
> doc/filters.texi| 46 ++
> libavfilter/Makefile| 1 +
> libavfilter/allfilters.c| 1 +
> libavfilter/cuda/vector_helpers.cuh |
On Sat, 12 Jun 2021 18:47:50 +0200
Timo Rothenpieler wrote:
> ---
> .gitignore | 1 +
> compat/cuda/ptx2c.sh| 34
> configure | 17 ++
> ffbuild/.gitignore | 1 +
> ffbuild/bin2c.c | 76 +++
On Tue, 23 Feb 2021 12:16:53 +0100
Andreas Rheinhardt wrote:
> Andreas Rheinhardt:
> > The counter for the number of styles is written on two bytes, ergo
> > anything > UINT16_MAX is invalid. This also fixes a compiler warning
> > because of a tautologically true check on 64bit systems.
> >
> >
On Fri, 19 Feb 2021 18:01:42 +0100
Timo Rothenpieler wrote:
> On 19.02.2021 16:29, Ricardo Monteiro wrote:
> > Hello,
> >
> > The patch fixes a bug regarding the number of B frames being used:
> > The default number of B frames is now -1 for both h264_nvenc and
> > hevc_nvenc. This allows the nu
On Sun, 13 Dec 2020 15:51:04 -0300
James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/cuviddec.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
> index 331851231f..49775b5a09 100644
> --- a/libavcodec/cuviddec.c
> +++ b
On Sun, 13 Dec 2020 15:51:03 -0300
James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/cuviddec.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
> index 61d7f36c79..331851231f 100644
> --- a/libavcodec/cuviddec.c
> ++
Monochrome encoding with libaom was buggy for a long time, but this was
finally sorted out in libaom 2.0.1 (2.0.0 is almost there but was still
buggy in realtime mode).
Signed-off-by: Philip Langdale
---
Changelog | 1 +
libavcodec/libaomenc.c | 42
uch a category.
Signed-off-by: Philip Langdale
---
Changelog | 1 +
configure | 8
libavcodec/libaomenc.c | 14 ++
libavcodec/version.h | 2 +-
4 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/Changelog b/Changelog
index 503317dfae..8f5e8
ional - YUV440P doesn't seem a logical pix_fmt for
monochrome and conditioning on chroma sub-sampling doesn't make sense.
So I changed it.
I've tested 8bit content, but I haven't found a way to create a 10bit
sample, so that path is untested for now.
Signed-off-by: Philip Langdale
On Sat, 17 Oct 2020 09:37:38 +0200
Andreas Rheinhardt wrote:
> Background colour was never initialized if no style was available.
> Use a sane default of zero (i.e. completely transparent).
>
> Fixes Coverity issue #1461471.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> No change for this patc
On Sat, 17 Oct 2020 20:22:38 +0200
Andreas Rheinhardt wrote:
> If allocating fonts fails when reading the header, all fonts are
> freed, yet the counter of fonts is not reset and no error is
> returned; when subtitles are decoded lateron, the inexistent list of
> fonts is searched for the matchin
On Sun, 11 Oct 2020 18:36:42 +0200
Thomas Mundt wrote:
> Hi Philip,
>
> Am Fr., 9. Okt. 2020 um 18:33 Uhr schrieb Philip Langdale
> >:
>
> > I've been sitting on this for a couple of years now, and I figured I
> > should just send it out. This is what I be
da.c
new file mode 100644
index 00..7651a869d5
--- /dev/null
+++ b/libavfilter/vf_bwdif_cuda.c
@@ -0,0 +1,394 @@
+/*
+ * Copyright (C) 2018 Philip Langdale
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the
On Thu, 8 Oct 2020 11:48:51 +0530
ManojGuptaBonda wrote:
> Added VDPAU to list of supported formats for VP9 420 10 and 12 bit
> formats. Add VP9 10/12 Bit support for VDPAU
> ---
> libavcodec/vp9.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.
The latest builds of glslang introduce new libraries that need to be
linked for all symbols to be fully resolved.
Presumably, requiring these new libraries breaks building against
older glslang releases? What range are we committing to supporting?
Signed-off-by: Philip Langdale
---
configure
On Sat, 18 Jul 2020 20:29:01 +0300
Aleksey Skripka wrote:
> Greetings!
>
> unconditional AVFMT_TS_DISCONT also helps to survive when pts
> rollover in mpegts occurs. seems like this patch will break again
> reading long-lasting hls.
>
Right.
The flag on the InputFormat says the format _might_
On Sat, 27 Jun 2020 19:04:20 +0530
ManojGuptaBonda wrote:
> NVIDIA R450 driver added VDPAU support for HEVC 10/12 bit Decoding
> adding the same in ffmpeg. Updated version with #ifdef guards
> to continue compiling with older releases
>
>
> ManojGuptaBonda (2):
> lavc/vdpau_hevc: add function
On Fri, 26 Jun 2020 12:43:29 +0530
ManojGuptaBonda wrote:
> Added VDPAU to list of supported formats for HEVC10 and 12 bit formats
> also added 42010 bit to surface_parameters and new VDP chroma formats
> to VDPAUPixFmtMaps
>
> Add HEVC 420 10/12 Bit and 444 10/12 Bit support for VDPAU
>
>
>
On Fri, 26 Jun 2020 17:47:32 +0300
Rémi Denis-Courmont wrote:
>
> Is this really supposed to be done with string matching in
> libavcodec? That looks rather brittle to me.
It's a fair statement, but, surprisingly, we don't have a profile enum.
The profile calculator parses all the various contr
On Thu, 25 Jun 2020 09:17:19 -0700
Philip Langdale wrote:
>
>
> LGTM.
>
I have been reminded that this only compiles cleanly with the latest
vdpau. We need #ifdef guards to continue compiling with older releases.
--phil
___
ffmpeg-d
On Thu, 25 Jun 2020 16:53:02 +0530
ManojGuptaBonda wrote:
> Added VDPAU to list of supported formats for HEVC10 and 12 bit formats
> also added 42010 bit to surface_parameters and new VDP chroma formats
> to VDPAUPixFmtMaps
>
> Add HEVC 420 10/12 Bit and 444 10/12 Bit support for VDPAU
>
>
>
On Thu, 25 Jun 2020 16:53:01 +0530
ManojGuptaBonda wrote:
> Add vdpau_parse_rext_profile and use profile constraint flags to
> determine the exact vdp_profile for HEVC_REXT.
>
> If profile mismatch is allowed, select Main profile by default.
>
> Add build object in Makefile for h265_profile_lev
On Mon, 1 Jun 2020 09:50:56 +
Amit Pandya wrote:
> Hi all,
>
> This patch can support hardware-accelerated decode in ffmpeg on
> Jetson platforms.
Hi Amit,
I appreciate you sending this in. People have asked about Jetson
support a few times.
Is there any plan to enable the normal nvdec/nv
On Thu, 16 Apr 2020 14:07:49 -0300
James Almer wrote:
> On 4/16/2020 1:26 PM, Philip Langdale wrote:
> > On Tue, 10 Mar 2020 16:33:41 -0300
> > James Almer wrote:
> >>
> >> I can withdraw this patch (And remove the relevant chunks from the
> >> follo
On Tue, 10 Mar 2020 16:33:41 -0300
James Almer wrote:
>
> I can withdraw this patch (And remove the relevant chunks from the
> following two) if this function was effectively not meant for
> encoders. Also maybe poke Timo regarding nvenc flushing, to see why
> it is needed and if there's an alter
ally safe or not. As this combination
doesn't exist today, we'll deal with it if it ever comes up.
Signed-off-by: Philip Langdale
---
doc/APIchanges | 6 ++
libavcodec/audiotoolboxenc.c | 3 ++-
libavcodec/avcodec.h | 25 -
On Fri, 10 Apr 2020 21:49:35 +
John Stebbins wrote:
> On Fri, 2020-04-10 at 14:12 -0700, Philip Langdale wrote:
> > On Fri, 10 Apr 2020 13:02:16 -0600
> > John Stebbins wrote:
> >
> > > Patch set makes return codes from subtitle encoders more
> > >
On Fri, 10 Apr 2020 20:01:29 -0300
James Almer wrote:
> The assert needs to be under the following chunk, like it was in the
> first version, after we have already established that we're dealing
> with a flush enabled encoder to ensure that it's not also wrongly
> marked as supporting frame threa
an encoder. But I did add a sanity check to reject attempts to
flush a frame threaded encoder because I couldn't wrap my head around
whether that code path was actually safe or not. As this combination
doesn't exist today, we'll deal with it if it ever comes up.
Signed-off-by: Phili
On Fri, 10 Apr 2020 18:47:06 -0300
James Almer wrote:
>
> Seems fine in principle, but I'd like to hear Anton's opinion.
Thanks. I've sent an updated patch and will wait for Anton.
--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https:/
an encoder. But I did add a sanity check to reject attempts to
flush a frame threaded encoder because I couldn't wrap my head around
whether that code path was actually safe or not. As this combination
doesn't exist today, we'll deal with it if it ever comes up.
Signed-off-by: Phili
On Fri, 10 Apr 2020 13:02:16 -0600
John Stebbins wrote:
> Patch set makes return codes from subtitle encoders more meaningful
> and consistent. Also fixes output buffer size checking where needed.
>
> After this, a user of a subtitle encoder can attempt to encode again
> with a larger buffer if
an encoder. But I did add a sanity check to reject attempts to
flush a frame threaded encoder because I couldn't wrap my head around
whether that code path was actually safe or not. As this combination
doesn't exist today, we'll deal with it if it ever comes up.
Signed-off-by: Phili
On Thu, 9 Apr 2020 23:28:49 +
John Stebbins wrote:
> Essentially yes. We've had our own mov text encoder and decoder in
> HandBrake for years. I added support for using ffmpeg for decoding
> subtitles last year but the movtext decoder wasn't up to the same
> level as ours, so we weren't us
On Thu, 9 Apr 2020 19:30:53 +
John Stebbins wrote:
>
> Pushed to https://github.com/jstebbins/FFmpeg/commits/movtext
>
> There's one additional patch on the top implementing what we discussed
> about highlight alpha updates. Should I send that to the ml as well?
>
The new one looks good t
On Thu, 9 Apr 2020 15:51:23 +
John Stebbins wrote:
> On Wed, 2020-04-08 at 12:24 -0700, Philip Langdale wrote:
> > On Tue, 7 Apr 2020 14:38:52 +
> > John Stebbins wrote:
> >
> > > After checking carefully, patches 10 and 23 are as I want them.
> &g
On Thu, 9 Apr 2020 15:21:35 +
John Stebbins wrote:
> Well, I was leaving that in as a comment showing the structure of the
> sample description. But if it's confusing, I can just remove all
> those comments. There are several others that do not represent the
> actual values written.
Ok. T
On Thu, 9 Apr 2020 16:17:21 +
John Stebbins wrote:
> > >
> > > Worth a comment that secondary alpha can't be preserved?
> >
> > Sure, will do.
>
> Taking a second look at this, I'm wondering if alpha_id = 2 should be
> applied to the highlight color that is set in mov_text_color_cb? A
On Thu, 9 Apr 2020 11:20:09 -0300
James Almer wrote:
> On 4/8/2020 7:04 PM, Philip Langdale wrote:
> > On Wed, 8 Apr 2020 14:58:36 -0300
> > James Almer wrote:
> >
> >> Signed-off-by: James Almer
> >> ---
> >> This removes the encode2()
On Thu, 9 Apr 2020 15:09:45 +
John Stebbins wrote:
> >
>
> I missed this review earlier. What about the indentation is off? Do
> you mean the indent of the function parameters does not align after
> the opening paren? I was keeping the lines aligned without wrapping
> at 80 characters.
On Wed, 8 Apr 2020 14:58:36 -0300
James Almer wrote:
> Signed-off-by: James Almer
> ---
> This removes the encode2() implementation as it'll never be used if a
> receive_packet() one exists, and the flush() implementation since
> according to Anton Khirnov avcodec_flush_buffers() is not meant t
On Tue, 7 Apr 2020 14:38:52 +
John Stebbins wrote:
>
> After checking carefully, patches 10 and 23 are as I want them. Sizes
> are relative to 288 when using override APIs, but are relative to
> PlayResY when processing the script.
>
> On the other hand, patch 20 needs a fix. If the cancel
On Mon, 6 Apr 2020 11:52:17 -0600
John Stebbins wrote:
> Initializes the mov text sample description from the ASS header and
> creates an mov font table from the fonts available in the ASS Styles.
> ---
> libavcodec/ass_split.c | 5 +
> libavcodec/ass_split.h | 8 ++
> libavcodec/movtexten
On Mon, 6 Apr 2020 11:52:18 -0600
John Stebbins wrote:
> If the video dimensions are different than the ASS play_res then the
> font sizes need to be adjusted to get the same apparent render size.
> ---
> libavcodec/movtextenc.c | 30 +-
> 1 file changed, 29 insertion
On Mon, 6 Apr 2020 11:52:16 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextenc.c | 13 -
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index 2e65489c4d..167dffee6a 100644
> --- a/libavcodec/movtextenc.c
>
On Tue, 7 Apr 2020 09:00:34 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextenc.c | 43
> - 1 file changed, 34
> insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index 9e657c9635..2d3c416407 100644
> -
On Mon, 6 Apr 2020 11:52:14 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextenc.c | 39 ++-
> 1 file changed, 30 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index e82393dde7..9e657c9635 100644
> ---
On Mon, 6 Apr 2020 11:52:13 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextenc.c | 25 -
> 1 file changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index 090536b887..e82393dde7 100644
> --- a/libavcodec/mo
On Mon, 6 Apr 2020 11:52:12 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextenc.c | 28
> 1 file changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index 4e7d55efcb..090536b887 100644
> --- a/libavcode
On Mon, 6 Apr 2020 11:52:11 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextenc.c | 60
> ++--- 1 file changed, 50
> insertions(+), 10 deletions(-)
>
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index d389111419..4e7d55efcb 100644
>
On Mon, 6 Apr 2020 12:35:32 -0600
John Stebbins wrote:
> The [Script Info] section was skipped if starts with UTF8 BOM
> ---
> libavcodec/ass_split.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/ass_split.c b/libavcodec/ass_split.c
> index 67da7c6d84..c2c388d9f0 100644
On Mon, 6 Apr 2020 11:52:05 -0600
John Stebbins wrote:
> Font sizes are relative to the subtitle frame dimensions. If the
> expected frame dimensions are not known, the font sizes will most
> likely be incorrect.
> ---
> libavcodec/ass.c| 30 +++---
> libavcodec/a
On Mon, 6 Apr 2020 11:52:09 -0600
John Stebbins wrote:
> Makes style update code easier to extend for style types not yet
> handled ---
> libavcodec/movtextenc.c | 131
> +++- 1 file changed, 62
> insertions(+), 69 deletions(-)
>
> diff --git a/libavcodec/movt
On Mon, 6 Apr 2020 11:52:10 -0600
John Stebbins wrote:
> The last record at the end of each dialog was never closed
> ---
> libavcodec/movtextenc.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index 05532cd544..d389111419 10
On Mon, 6 Apr 2020 11:52:08 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextenc.c | 38 ++
> 1 file changed, 22 insertions(+), 16 deletions(-)
>
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index 8638e303fe..5e5b786f44 100644
> ---
On Mon, 6 Apr 2020 11:52:07 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextenc.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
> index c19ef384bc..8638e303fe 100644
> --- a/libavcodec/movtextenc.c
> ++
1 - 100 of 620 matches
Mail list logo
