On Fri, 26 Apr 2019 09:43:39 +0530
ManojGuptaBonda wrote:
> Latest generation video decoder on Turing Chips supports decoding HEVC
> 4:4:4 decoding. These changes adds support for the same for VDPAU
>
> ManojGuptaBonda (3):
> VDPAU: Add support for decoding HEVC 4:4:4 content
> Pass sps and
On Sun, 28 Apr 2019 22:02:11 +0200 (CEST)
Marton Balint wrote:
> Hi All,
>
> There has been discussion on the mailing list several times about the
> inclusion of support for closed source components (codecs, formats,
> filters, etc) in the main ffmpeg codebase.
>
> Also the removal of libNDI
On Thu, 25 Apr 2019 22:00:16 -0700
Philip Langdale wrote:
> On Fri, 26 Apr 2019 09:43:39 +0530
> ManojGuptaBonda wrote:
>
> > Latest generation video decoder on Turing Chips supports decoding
> > HEVC 4:4:4 decoding. These changes adds support for t
On Mon, 6 May 2019 03:33:58 +
Manoj Bonda wrote:
> Thanks Philip for pushing the changes, sorry for the churn.
>
> I am not familiar with the MPV code much, but from a quick check by
> enabling the direct mode for 444 surfaces by modifying the condition
>
> p->direct_mode = mapper->dst
These are the 4:4:4 variants of the semi-planar NV12/NV21 formats.
I'm surprised we've not had a reason to add them until now, but
they are the format that VDPAU uses when doing interop for 4:4:4
surfaces.
Signed-off-by: Philip Langdale
---
libavutil/pixdesc.c
On 2019-05-07 14:43, Carl Eugen Hoyos wrote:
Am Di., 7. Mai 2019 um 06:33 Uhr schrieb Philip Langdale
:
These are the 4:4:4 variants of the semi-planar NV12/NV21 formats.
I'm surprised we've not had a reason to add them until now, but
they are the format that VDPAU uses when doing i
e
asm specific x86 path that did an explicit exclusion check for NV12.
I replaced that with a semi-planar check and also updated the
equivalent PPC code, but which I cannot test.
Signed-off-by: Philip Langdale
---
libswscale/input.c | 2 +
libswscale/out
On Fri, 10 May 2019 11:03:46 +0200
Carl Eugen Hoyos wrote:
> Am Fr., 10. Mai 2019 um 07:59 Uhr schrieb Philip Langdale
> :
> >
> > I don't think this is terribly useful, as the only thing out there
> > that can even handle NV24 content is VDPAU and the only time yo
On Fri, 10 May 2019 09:35:40 +0300
Lauri Kasanen wrote:
>
> I'm having trouble making out what formats exactly isSemiPlanarYUV()
> matches. Are you sure it's an equivalent check?
>
Well, the check's been in there for quite a while; that's not new.
(isPlanarYUV(pix_fmt) && desc->comp[1].plane
On 2019-05-10 08:12, Lauri Kasanen wrote:
On Fri, 10 May 2019 08:07:45 -0700
Philip Langdale wrote:
On Fri, 10 May 2019 09:35:40 +0300
Lauri Kasanen wrote:
>
> I'm having trouble making out what formats exactly isSemiPlanarYUV()
> matches. Are you sure it's an equivalent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sat, 11 May 2019 17:40:41 +0200
Michael Niedermayer wrote:
> On Thu, May 09, 2019 at 10:59:12PM -0700, Philip Langdale wrote:
> > I don't think this is terribly useful, as the only thing out there
> > that can even handle N
As I had to post an update, I've collected the changes together for
convenience.
Philip Langdale (3):
avutil: Add NV24 and NV42 pixel formats
swscale: Add support for NV24 and NV42
swscale: Add test for isSemiPlanarYUV to pixdesc_query
libavutil/pixdesc.c
d the pixel format for media players, even
if there's no direct use within ffmpeg.
Separately, there are apparently webcams that use NV24, but I've
never seen one.
Signed-off-by: Philip Langdale
---
libavutil/pixdesc.c | 24
libavutil/pixfmt.h
Lauri had asked me what the semi planar formats were and that reminded
me that we could add it to pixdesc_query so we know exactly what the
list is.
Signed-off-by: Philip Langdale
---
libswscale/tests/pixdesc_query.c | 1 +
tests/ref/fate/sws-pixdesc-query | 13 +
2 files changed
lso updated the
equivalent PPC code, which Lauri kindly checked.
Signed-off-by: Philip Langdale
---
libswscale/input.c | 2 +
libswscale/output.c | 6 ++-
libswscale/ppc/swscale_altivec.c | 3 +-
libswscale/ppc/swscale_vsx.c | 3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sun, 12 May 2019 12:54:24 +0200
Michael Niedermayer wrote:
>
> all these + 1 in the code above look a bit suspect. Can you explain
> what they do assuming they are intended
Good catch. I should have removed them when I removed the divide by 2.
On Mon, 13 May 2019 11:18:09 +
Sergey Svechnikov wrote:
> When scaling a 10bit video using scale_cuda filter (witch uses pixel
> format AV_PIX_FMT_P010LE), the output video gets distorted. I think
> it has something to do with the differences in processing between
> cuda_sdk and ffnvcodec wit
After Sergey's bug report, I went and fixed a couple of other things
I noticed while I was looking at the filter.
Philip Langdale (3):
avfilter/vf_scale_cuda: Fix incorrect scaling of > 8bit content
avfilter/vf_scale_cuda: Add support for YUV444P16
avfilter/vf_scale_cuda: Simplif
This format is interesting because it's what you get for decoded
10/12bit HEVC 4:4:4.
---
libavfilter/vf_scale_cuda.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
index ecfd6a1c92..a833dcd1a4 100644
I'm not sure why this was written the way it was originally. We
initialise the plane addresses correctly in hwcontext_cuda so
why try and play games to calculate the plane offsets directly
in this code?
---
libavfilter/vf_scale_cuda.c | 22 +++---
1 file changed, 11 insertions(+),
When i converted the filter to use texture objects instead of
texture references, I incorrect dropped the `pixel_size` scaling
factor when setting `pitchInBytes`. `src_pitch` is in pixels and
so must be scaled up.
---
libavfilter/vf_scale_cuda.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
On Sun, 23 Jun 2019 06:46:12 +0200
Andreas Rheinhardt wrote:
> The mov flavour of timed text uses the first two bytes of the packet
> as a length field. And up until 11bef2fe said length field has been
> read correctly in the mov2textsub bsf. But since then the next two
> bytes are read as if the
On Tue, 02 Jul 2019 17:19:02 +0300
Alexander Kravchenko wrote:
>
LGTM, but please try and get git send-email working. Your client is
still doing binary attachments.
--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailm
On 2019-07-30 15:51, Rodger Combs wrote:
This avoids using the CUDA SDK at all; instead, we provide a minimal
reimplementation of the basic functionality that lavfi actually uses.
It generates very similar code to what NVCC produces.
The header contains no implementation code derived from the SD
On 2019-07-30 15:51, Rodger Combs wrote:
Discovered via a warning when building with clang
---
libavfilter/vf_thumbnail_cuda.cu | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_thumbnail_cuda.cu
b/libavfilter/vf_thumbnail_cuda.cu
index c73e49fbc6..d4d4d791f6 1
On 2019-08-03 00:09, Timo Rothenpieler wrote:
On 02.08.2019 11:18, Stefan Schoenefeld wrote:
Hi all,
Recently we encountered an issue when decoding a h.263 file:
FFmpeg will freeze when decoding h.263 video with NVDEC. Turns out
this is not directly related to NVDEC but is a problem that show
On 2019-08-08 11:33, OvchinnikovDmitrii wrote:
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 384d8efc92..f66b95645e 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -213,6 +213,7 @@ static int
amf_init_from_dxva2_device(AVCodecContext *avctx, AVDXVA2DeviceContex
stat
On Tue, 27 Aug 2019 10:08:43 -0700
Philip Langdale wrote:
> On 2019-08-08 11:33, OvchinnikovDmitrii wrote:
> >
> > diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
> > index 384d8efc92..f66b95645e 100644
> > --- a/libavcodec/amfenc.c
> > +++ b/libavco
The latest generation video decoder on the Turing chips supports
decoding HEVC 4:4:4. Supporting this is relatively straight-forward;
we need to account for the different chroma format and pick the
right output and sw formats at the right times.
There was one bug which was the hard-coded assumptio
The new video decoder hardware on Turing GPUs supports HEVC 4:4:4 content.
This patch series adds the necessary new pixel formats and implements
support in nvdec/nvenc/cuviddec.
Philip Langdale (5):
avutil: Add YUV444P10_LSB and YUV444P12_LSB pixel formats
avcodec/nvdec: Add support for
Vulkan also uses the same format definitions.
Signed-off-by: Philip Langdale
---
libavutil/pixdesc.c | 48 +
libavutil/pixfmt.h | 8
libavutil/version.h | 4 ++--
3 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/libavutil
cuvid parser is
used, meaning that 444 JPEG content is still indicated as using a 420
output format.
Signed-off-by: Philip Langdale
---
libavcodec/cuviddec.c | 59 +--
1 file changed, 40 insertions(+), 19 deletions(-)
diff --git a/libavcodec/cuviddec.c b
-off-by: Philip Langdale
---
libavcodec/nvdec.c| 7 ---
libavcodec/nvdec.h| 5 -
libavcodec/nvdec_h264.c | 2 +-
libavcodec/nvdec_hevc.c | 10 --
libavcodec/nvdec_mjpeg.c | 2 +-
libavcodec/nvdec_mpeg12.c | 2 +-
libavcodec/nvdec_mpeg4.c | 2
assumption that the
first chroma plane would be half-height; I fixed this to use the
actual shift value on the plane.
The output formats ('2', and '3') are currently undocumented but
appear to be YUV444P and YUV444P16 based on how they behave.
Signed-off-by: Philip Langdale
---
12bit is implicitly truncated to 10bit as part of doing this, but we
already do that for P016 and YUV444P16.
I've bundled a single version bump and changelog entry in this change
to reflect the updates to all three of nvdec/nvenc/cuviddec.
Signed-off-by: Philip Langdale
---
Chan
On Sun, 7 Oct 2018 10:50:56 -0700
Philip Langdale wrote:
> This is the equivalent change for cuviddec after the previous change
> for nvdec. I made similar changes to the copying routines to handle
> pixel formats in a more generic way.
>
> Note that unlike with nvdec, there
On Mon, 8 Oct 2018 11:55:09 +0200
Hendrik Leppkes wrote:
> On Mon, Oct 8, 2018 at 10:40 AM Timo Rothenpieler
> wrote:
> >
> >
> > I don't think it's YUVJ all over again, as it was the exact same bit
> > layout than normal YUV, while this one is actually different.
> >
>
> Its also the same bi
assumption that the
first chroma plane would be half-height; I fixed this to use the
actual shift value on the plane.
The output formats ('2', and '3') are currently undocumented but
appear to be YUV444P and YUV444P16 based on how they behave.
Signed-off-by: Philip Langdale
---
cuvid parser is
used, meaning that 444 JPEG content is still indicated as using a 420
output format.
Signed-off-by: Philip Langdale
---
libavcodec/cuviddec.c | 59 +--
1 file changed, 40 insertions(+), 19 deletions(-)
diff --git a/libavcodec/cuviddec.c b
12bit is implicitly truncated to 10bit as part of doing this, but we
already do that for P016 and YUV444P16.
I've bundled a single version bump and changelog entry in this change
to reflect the updates to all three of nvdec/nvenc/cuviddec.
Signed-off-by: Philip Langdale
---
Chan
is saying that
we can only expose the hardware capabilities if we implement bit depth
decoupling - that's really saying you don't ever expect this
functionality to go in.
So, please, let's just make a decision.
Philip Langdale (5):
avutil: Add YUV444P10_MSB and YUV444P12_MSB
-off-by: Philip Langdale
---
libavcodec/nvdec.c| 7 ---
libavcodec/nvdec.h| 5 -
libavcodec/nvdec_h264.c | 2 +-
libavcodec/nvdec_hevc.c | 10 --
libavcodec/nvdec_mjpeg.c | 2 +-
libavcodec/nvdec_mpeg12.c | 2 +-
libavcodec/nvdec_mpeg4.c | 2
Vulkan also uses the same format definitions.
Signed-off-by: Philip Langdale
---
libavutil/pixdesc.c | 48 +
libavutil/pixfmt.h | 8
libavutil/version.h | 4 ++--
3 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/libavutil
On Sat, 20 Oct 2018 22:58:34 +0200
Timo Rothenpieler wrote:
> >
> > +// It it semantically incorrect to use AX_PIX_FMT_YUV444P16
> > for either the 10
> > +// or 12 bit case, but ffmpeg and nvidia disagree on which end
> > the padding
> > +// bits go at. P16 is unambiguous and matc
On Sat, 20 Oct 2018 23:10:57 +0200
Timo Rothenpieler wrote:
> >
> > -for (i = 0; i < 2; i++) {
> > +pixdesc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
> > +
> > +for (i = 0; i < pixdesc->nb_components; i++) {
> > +size_t height = avctx->height
does work with the cuviddec decoder which is
a full decoder, but uses nvidia's parsers which tend to be more
limited than the ffmpeg ones).
Philip Langdale (3):
libavfilter/vf_yadif: Make frame management logic and options
shareable
avfilter/vf_yadif_cuda: CUDA accelerated deinter
change
is introducing a function pointer for the filter() function so it
can be specified for the specific filter.
Signed-off-by: Philip Langdale
---
libavfilter/Makefile | 2 +-
libavfilter/vf_yadif.c | 190 +
libavfilter/yadif.h| 9 ++
l
With the cuda yadif filter in use, the number of mapped decoder
frames could increase by two, as the filter holds on to additional
frames.
Signed-off-by: Philip Langdale
---
libavcodec/nvdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/nvdec.c b/libavcodec
Signed-off-by: Philip Langdale
---
Changelog| 1 +
configure| 1 +
doc/filters.texi | 58 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/version.h| 2 +-
libavfilter/vf_yadif_cuda.c
On 2018-11-01 12:42, Michael Niedermayer wrote:
+const AVOption yadif_options[] = {
missing prefix
I will fix. Are you otherwise happy with this change?
Thanks,
--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailm
On 2018-11-01 14:05, Timo Rothenpieler wrote:
On 01.11.2018 21:54, Carl Eugen Hoyos wrote:
2018-10-26 17:56 GMT+02:00, Philip Langdale :
Could you add some sample numbers about how fast the cuda
variant is compared to cpu?
I don't think such numbers are overly useful by themselves
On Thu, 1 Nov 2018 22:16:53 +0100
Hendrik Leppkes wrote:
> One might do something like this:
>
> NVDEC -> hwdownload -> yadif -> x264
> NVDEC -> cuda_yadif -> hwdownload -> x264
>
> How do those compare, maybe when you replace x264 with null?
I set my baseline with NVDEC -> hwdownload -> null.
does work with the cuviddec decoder which is
a full decoder, but uses nvidia's parsers which tend to be more
limited than the ffmpeg ones).
This update includes minor changes to reflect feedback. I will bump
the minor version when I push.
Philip Langdale (3):
libavfilter/vf_yadif: Make
change
is introducing a function pointer for the filter() function so it
can be specified for the specific filter.
Signed-off-by: Philip Langdale
---
libavfilter/Makefile | 2 +-
libavfilter/vf_yadif.c | 196 ++
libavfilter/yadif.h| 9 ++
l
With the cuda yadif filter in use, the number of mapped decoder
frames could increase by two, as the filter holds on to additional
frames.
Signed-off-by: Philip Langdale
---
libavcodec/nvdec.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavcodec/nvdec.c b
Signed-off-by: Philip Langdale
---
Changelog| 1 +
configure| 1 +
doc/filters.texi | 58 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_yadif_cuda.c | 426
On Thu, 1 Nov 2018 23:48:03 +
Soft Works wrote:
> In this context, I wonder if there is some explanation somewhere
> about the differences between the cuvid and nvdec codec
> implementations.
>
> I understand the ffmpeg side where cuvid is a full codec and nvdec is
> implemented as hwaccel.
it, we can then remove all the duplicated logic.
Philip Langdale (2):
avfilter/yadif_common: Add field type tracking to help bwdif
avfilter/vf_bwdif: Use common yadif frame management logic
libavfilter/bwdif.h | 34 +
libavfilter/vf_bwdif.c
After adding field type management to the common yadif logic, we can
remove the duplicate copy of that logic from bwdif.
---
libavfilter/bwdif.h | 34 +
libavfilter/vf_bwdif.c | 235 +---
libavfilter/x86/vf_bwdif_init.c | 3 +-
3 files change
The bwdif filter can use common yadif frame management if we track
when a field is the first or last field in a sequence. While this
information is not used by yadif, the added benefit of removing the
duplicated frame management logic makes it worth tracking this state
in the common code.
---
liba
it, we can then remove all the duplicated logic.
v2: Rename enum values as recommened by Thomas Mundt.
Philip Langdale (2):
avfilter/yadif_common: Add field type tracking to help bwdif
avfilter/vf_bwdif: Use common yadif frame management logic
libavfilter/bwdif.h | 34 +--
The bwdif filter can use common yadif frame management if we track
when a field is the first or last field in a sequence. While this
information is not used by yadif, the added benefit of removing the
duplicated frame management logic makes it worth tracking this state
in the common code.
---
liba
After adding field type management to the common yadif logic, we can
remove the duplicate copy of that logic from bwdif.
---
libavfilter/bwdif.h | 34 +
libavfilter/vf_bwdif.c | 235 +---
libavfilter/x86/vf_bwdif_init.c | 3 +-
3 files change
On Tue, 13 Nov 2018 02:11:15 +0100
Thomas Mundt wrote:
> Am So., 11. Nov. 2018 um 20:47 Uhr schrieb Philip Langdale <
> phil...@overt.org>:
>
> > vf_bwdif's frame management logic is almost identical to that of
> > yadif. The only difference is that it tracks
On 2018-11-15 05:48, John Cox wrote:
Now one way it could be integrated would be as a seperate decoder
That is how I've currently built it and therefore probably the easiest
option.
another is inside the hevc decoder
It started life there but became a very uneasy fit with too many
ifdefs.
a
On Sat, 17 Nov 2018 17:05:00 +0100
Martin Vignali wrote:
> Hello,
>
> Patch in attach fix make fate-source error for cuda_check files
>
> Martin
Thanks for pointing this out. I've pushed a slightly different fix
where I made the inclusion guards follow the standard pattern.
--phil
___
On Mon, 6 Apr 2020 11:51:55 -0600
John Stebbins wrote:
> Patch series adds more complete decoding and encoding of color, alpha,
> font size, font name, and style tags for movtext. It also fixes a
> number of bugs.
>
Hi John,
Thanks for doing all of this! I'll try and take a look at these over
On Mon, 6 Apr 2020 11:51:56 -0600
John Stebbins wrote:
> A conversion from rgb to bgr is necessary
> ---
> libavcodec/movtextdec.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
> index c38c5edce6..05becaf64
On Mon, 6 Apr 2020 11:51:57 -0600
John Stebbins wrote:
> It's not necessary to walk the style record list twice per subtitle
> character. style records are in order and do not overlap.
> ---
> libavcodec/movtextdec.c | 38 --
> 1 file changed, 20 insertions(+
On Mon, 6 Apr 2020 11:51:58 -0600
John Stebbins wrote:
> They should be 0 or 1 so that 0 or -1 is written to the ass header
> ---
> libavcodec/movtextdec.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
> index 47
On Mon, 6 Apr 2020 11:51:59 -0600
John Stebbins wrote:
> Style flags were only being turned on. If the default was on and
> style record turned off, style flag remained on.
> ---
> libavcodec/movtextdec.c | 24 +++-
> 1 file changed, 15 insertions(+), 9 deletions(-)
>
> dif
On Mon, 6 Apr 2020 11:52:00 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextdec.c | 20 +++-
> 1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
> index a3e37d013d..6c7d93702e 100644
> --- a/libavcodec/movtex
On Mon, 6 Apr 2020 22:09:22 +
John Stebbins wrote:
>
> I went back and double checked this in the spec before changing the
> code.
>
> "The styles shall be ordered by starting character offset, and the
> starting offset of one style record shall be greater than or equal to
> the ending char
On Mon, 6 Apr 2020 11:52:01 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextdec.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
> index 6c7d93702e..2481c71af6 100644
> --- a/libavcodec/movtextdec.c
> +++ b/liba
On Mon, 6 Apr 2020 11:52:02 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextdec.c| 14 ++
> tests/ref/fate/sub-movtext | 2 +-
> 2 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
> index 2481c71af6..eb9c7f5
On Mon, 6 Apr 2020 11:52:03 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextdec.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
> index eb9c7f5755..4d5dcdf5e7 100644
> --- a/libavcodec/movtextdec.
On Mon, 6 Apr 2020 11:52:04 -0600
John Stebbins wrote:
> ---
> libavcodec/movtextdec.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
> index 4d5dcdf5e7..f3a504b47b 100644
> --- a/libavcodec/movtextdec.c
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
> ++
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: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: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 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: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 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: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: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 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: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 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: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 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 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 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 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 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 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 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 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 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
1 - 100 of 620 matches
Mail list logo
