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: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: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 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: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 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: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: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: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: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 Sat, 18 Jan 2020 20:23:00 +
Mark Thompson wrote:
> > typedef struct AVHWDeviceInternal AVHWDeviceInternal;
> > diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
> > index 30611b1912..18abb87bbd 100644
> > --- a/libavutil/hwcontext_cuda.c
> > +++ b/libavutil/hwcontext_cu
On Sat, 18 Jan 2020 20:27:12 +
Mark Thompson wrote:
> On 10/01/2020 21:05, Lynne wrote:
> > This is modelled as a transfer, as we have today, but where both
> > the src and the dst are hardware frames with hw contexts. We need
> > to be careful to ensure the contexts are compatible - particul
On Fri, 10 Jan 2020 22:05:21 +0100 (CET)
Lynne wrote:
> Patches attached
> Also pushed to https://github.com/cyanreg/FFmpeg/ master branch
> because they're 9 and they add about 7000 lines. Filtering won't work
> without a recent glslang version since they moved a header and broke
> API because t
On Wed, 8 Jan 2020 14:31:05 -0800
Josh Allmann wrote:
>
> Hi Phil,
>
> Flushing and resumption is documented/supported in nvenc via
> NV_ENC_FLAGS_EOS, but I wasn't sure if this was a feature that
> ffmpeg's integration was intentionally designed for. But if you
> confirm we can expect this beha
On Sat, 21 Dec 2019 14:54:38 -0800
Philip Langdale wrote:
> On Fri, 20 Dec 2019 16:07:18 -0800
> Josh Allmann wrote:
>
> > One concern I had was about the long-term stability of this
> > behavior. Right now, it works, but perhaps only coincidentally?
> > Being flusha
On Fri, 20 Dec 2019 16:07:18 -0800
Josh Allmann wrote:
> One concern I had was about the long-term stability of this behavior.
> Right now, it works, but perhaps only coincidentally? Being flushable
> and resumable like this isn't explicitly part of the "contract" for
> nvenc, as far as I can see
On Fri, 20 Dec 2019 19:12:00 -0500
Dennis Mungai wrote:
> On Fri, 20 Dec 2019 at 19:03, Josh Allmann
>
> For CLI usage, does this affect the behavior of the global output
> option
>
> -flush_packets 1
>
> When the NVENC encoder is in use, in any way?
It's unrelated. This is a muxer level (av
On 2019-11-18 17:13, Josh Allmann wrote:
This patch is meant to be an entry point for discussion around an
issue we are having with flushing the nvenc encoder while doing
segmented transcoding. Hopefully there will be a less kludgey
workaround than this.
Hi Josh,
I happened to see your email r
It can be useful to re-use an encoder instance when doing segmented
encodings, and this requires flushing the encoder at the start of
each segment.
---
libavcodec/nvenc.c | 5 +
libavcodec/nvenc.h | 2 ++
libavcodec/nvenc_h264.c | 1 +
libavcodec/nvenc_hevc.c | 1 +
4 files changed,
There have been many reports over the years about problems when
taking an HLS stream as input to `ffmpeg` where there are timestamp
discontinuities present. This is explicitly supported in the
HLS spec (EXT-X-DISCONTINUITY) and often used for ad injection.
Various fixes and work-arounds have been
On Fri, 25 Oct 2019 11:00:13 +0530
ManojGuptaBonda wrote:
> Support for VDPAU accelerated VP9 decoding was added with
> libvdpau-1.3. Support for the same in ffmpeg is added with this
> patch. Profiles related to VDPAU VP9 can be found in latest vdpau.h
> present in libvdpau-1.3. DRC clips are no
On 2019-10-22 05:06, ManojGuptaBonda wrote:
Support for VDPAU accelerated VP9 decoding was added with libvdpau-1.3.
Support for the same in ffmpeg is added with this patch. Profiles
related to VDPAU VP9 can be found in latest vdpau.h present in
libvdpau-1.3. DRC clips are not supported yet due to
On Mon, 21 Oct 2019 18:01:38 +0530
ManojGuptaBonda wrote:
> Populate the codec specific params that need to be passed to
> VDPAU.
> ---
> libavcodec/vdpau_vp9.c | 155
> - 1 file changed, 153
> insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/vdpa
On Mon, 21 Oct 2019 18:01:37 +0530
ManojGuptaBonda wrote:
> Added file vdpau_vp9.c for supporting VDPAU VP9 decoding in FFmpeg
> with stub functions. Modified configure to add VDPAU VP9 support.
> Mapped VP9 profiles to VDPAU VP9 profiles.
>
> Support for VDPAU accelerated VP9 decoding was added
On Mon, 21 Oct 2019 18:01:36 +0530
ManojGuptaBonda wrote:
> Support for VDPAU accelerated VP9 decoding was added with
> libvdpau-1.3. Support for the same in ffmpeg is being
> added with these patches. DRC clips are not supported yet
> due to http://trac.ffmpeg.org/ticket/8068
>
> ManojGuptaBo
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
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 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-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-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 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 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
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(-
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(+),
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
-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.
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
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
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
-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
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
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 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
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 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
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 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
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 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 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 2019-04-06 09:42, Balint Marton wrote:
Hi All
Here is a call for the people in the voting committee [1] on the
decision of extending it.
Using the same guidelines as in the second extension [2], the
following candidates were found:
git log libav/master..master --no-merges --since=2018-03-3
On 2019-04-08 12:10, Marton Balint wrote:
I emailed Marton out-of-band, but I am not in the list because a few
of my recent commits
were pushed by Timo instead of me pushing them directly. My authored
list is 23 commits
but 4 were pushed by Timo, so Marton's command line returns '19' for
me.
On 2019-04-06 10:35, Marton Balint wrote:
On Sat, 6 Apr 2019, Jean-Baptiste Kempf wrote:
Hello,
On Sat, 6 Apr 2019, at 18:42, Balint Marton wrote:
Here is a call for the people in the voting committee [1] on the
decision of extending it.
Why do you limit at those ones? There are more commit
On Sat, 23 Mar 2019 16:18:48 +
Mark Thompson wrote:
> Set the cropping fields in the AVFrame.
> ---
> libavfilter/vf_crop.c | 74
> +-- 1 file changed, 51
> insertions(+), 23 deletions(-)
>
> There is the slightly unfortunate effect the filter links do
On Sat, 23 Mar 2019 23:51:10 +0800
UsingtcNower wrote:
> Signed-off-by: UsingtcNower
> ---
> Changelog | 1 +
> configure | 1 +
> doc/filters.texi| 31 +++
> libavfilter/Makefile| 1 +
> libavfilter/allfilters.c| 1 +
> libav
e ffnvcodec headers and loader.
> >
> > Most of the change is a direct mapping, but I also switched from
> > using texture references to using texture objects. This is supposed
> > to be the preferred way of using textures, and the texture object
> > API is the one
that understood, we just need to switch the remaining
users of the CUDA SDK to ffnvcodec and we will remove the non-free
entanglements from cuda.
Philip Langdale (5):
configure: Add an explicit check and option for nvcc
avfilter/vf_yadif_cuda: Switch to using ffnvcodec
avfilter/vf_scale_cuda: S
This change switches the vf_thumbnail_cuda filter from using the
full cuda sdk to using the ffnvcodec headers and loader.
Signed-off-by: Philip Langdale
---
configure | 2 +-
libavfilter/vf_yadif_cuda.c | 58 -
2 files changed, 32
use of nvcc from the sdk is still
supported with a distinct option.
Signed-off-by: Philip Langdale
---
configure | 2 --
1 file changed, 2 deletions(-)
diff --git a/configure b/configure
index 31576350bd..78fcc2e1eb 100755
--- a/configure
+++ b/configure
@@ -1819,7 +1819,6 @@ EXTRALIBS_LIST
the texture object API
is the one I added to ffnvcodec.
Signed-off-by: Philip Langdale
---
configure| 2 +-
libavfilter/vf_scale_cuda.c | 168 +++
libavfilter/vf_scale_cuda.cu | 73 ---
3 files changed, 128 insertions(+), 115
, and the texture object API
is the one I added to ffnvcodec.
Signed-off-by: Philip Langdale
---
configure| 2 +-
libavfilter/vf_thumbnail_cuda.c | 147 +--
libavfilter/vf_thumbnail_cuda.cu | 25 +++---
3 files changed, 93 insertions(+), 81
of the (L)GPL
* No proprietary code is included with the ptx files. That code is
only linked in at the final compilation step at runtime.
Signed-off-by: Philip Langdale
---
configure | 28
1 file changed, 28 insertions(+)
diff --git a/configure b/configure
index
The function typedefs we were using are only present when using the
dynamic loader, which means compilation breaks for code directly
using the cuda SDK.
To fix this, let's just duplicate the function typedefs locally.
These are not going to change.
Signed-off-by: Philip Langdale
---
liba
algorithm description from the doom9 forums.
Signed-off-by: Philip Langdale
---
libavfilter/vf_yadif_cuda.cu | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/libavfilter/vf_yadif_cuda.cu b/libavfilter/vf_yadif_cuda.cu
index 12e7e4a443..09dd9e240b 10
On 2019-02-19 11:25, Soft Works wrote:
> From your explanations, the situation doesn't seem to be as
> bad as it could be. When the CPU code of the filters can be
> changed to dynamic linking
The type of the linking of course cannot change the license.
Maybe I should have said 'dynamic loading
On 2019-02-18 20:08, Soft Works wrote:
Thanks again for your kind reply. Although I’m not a lawyer myself, I
know
that if you’re the sole(!) author of the yadif_cuda kernel source, then
you
would be allowed to publish that code under any additional license you
want.
But that would be your
On Mon, 18 Feb 2019 21:44:33 +
Soft Works wrote:
>
> Hi Phil,
>
> thanks for replying. I was just about to start migrating the filters
> to dynamic loading (nv-codec-headers)..
>
> From your explanations, the situation doesn't seem to be as bad as it
> could be. When the CPU code of the fi
On Sun, 17 Feb 2019 06:24:05 +
Soft Works wrote:
> Hi,
>
> in the above context I'm wondering about whether it is mandatory to
> treat the "cuda_sdk" option as a non-free option?
>
> In case of libnpp it's obviously required to statically link to
> proprietary Nvidia code code for which the
On Thu, 14 Feb 2019 13:52:45 +0100
Timo Rothenpieler wrote:
>
> First patch needs ACK by the respective maintainer. Which I believe
> was already done last time it was sent?
>
Actually not. Without the real headers, I didn't know there were new
HEVC fields to set, so this part is new for this
We need all the flags to be exposed to be able to pass them on to
HW decoders. I did not attempt to nuance any of the warnings about
flags being unsupported as there's no way, at the point we extract
flags, to say whether an HW decoder is being used.
Signed-off-by: Philip Lan
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 | 66 ++-
1 file changed, 46 insertions(+), 20 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.
We also need to pass the SPS and PPS range extension flags.
Signed-off-by: Philip Langdale
---
libavcodec/hevcdec.c| 3 +++
libavcodec/nvdec.c | 42
treat them as 444p16, which is not terrible, but does lose
information (the actual bit depth).
I will add a changelog entry and minor version bumps when I push.
Philip Langdale (4):
avcodec/hevc_ps: Expose all SPS and PPS range extension flags
avcodec/nvdec: Add support for decoding HEVC
On Wed, 13 Feb 2019 19:47:27 +0100
Timo Rothenpieler wrote:
> On 13.02.2019 09:56, Roman Arzumanyan wrote:
> > Hello,
> >
> > Please find attached patch, it adds HEVC YUV444P decoding support.
> >
> > Supported formats are AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV444P10LE,
> > AV_PIX_FMT_YUV444P12LE.
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 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 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
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 +--
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.
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
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.
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
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
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.
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 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
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
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
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
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
101 - 200 of 620 matches
Mail list logo
