Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add myself to the AMF section

2019-07-03 Thread Philip Langdale
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

Re: [FFmpeg-devel] [PATCH] movsub_bsf: Fix mov2textsub regression

2019-06-23 Thread Philip Langdale
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

[FFmpeg-devel] [PATCH 1/3] avfilter/vf_scale_cuda: Fix incorrect scaling of > 8bit content

2019-05-13 Thread Philip Langdale
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

[FFmpeg-devel] [PATCH 0/3] avfilter/vf_scale_cuda: Various improvements

2019-05-13 Thread Philip Langdale
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: Simplify out

[FFmpeg-devel] [PATCH 2/3] avfilter/vf_scale_cuda: Add support for YUV444P16

2019-05-13 Thread Philip Langdale
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

[FFmpeg-devel] [PATCH 3/3] avfilter/vf_scale_cuda: Simplify output plane addressing

2019-05-13 Thread Philip Langdale
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(+),

Re: [FFmpeg-devel] [PATCH] libavfilter/vf_scale_cuda: fix src_pitch for 10bit videos

2019-05-13 Thread Philip Langdale
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

Re: [FFmpeg-devel] [PATCH 2/3] swscale: Add support for NV24 and NV42

2019-05-12 Thread Philip Langdale
-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

[FFmpeg-devel] [PATCH 3/3] swscale: Add test for isSemiPlanarYUV to pixdesc_query

2019-05-11 Thread Philip Langdale
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

[FFmpeg-devel] [PATCH 2/3] swscale: Add support for NV24 and NV42

2019-05-11 Thread Philip Langdale
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 +- libswscale

[FFmpeg-devel] [PATCH 1/3] avutil: Add NV24 and NV42 pixel formats

2019-05-11 Thread Philip Langdale
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| 3

[FFmpeg-devel] [PATCH 0/3] NV24/NV42 support

2019-05-11 Thread Philip Langdale
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 | 24

Re: [FFmpeg-devel] [PATCH] swscale: Add support for NV24 and NV42

2019-05-11 Thread Philip Langdale
-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 NV24 c

Re: [FFmpeg-devel] [PATCH] swscale: Add support for NV24 and NV42

2019-05-10 Thread Philip Langdale
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 check

Re: [FFmpeg-devel] [PATCH] swscale: Add support for NV24 and NV42

2019-05-10 Thread Philip Langdale
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

Re: [FFmpeg-devel] [PATCH] swscale: Add support for NV24 and NV42

2019-05-10 Thread Philip Langdale
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 t

[FFmpeg-devel] [PATCH] swscale: Add support for NV24 and NV42

2019-05-09 Thread Philip Langdale
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/output.c

Re: [FFmpeg-devel] [PATCH] avutil: Add NV24 and NV42 pixel formats

2019-05-07 Thread Philip Langdale
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 interop

[FFmpeg-devel] [PATCH] avutil: Add NV24 and NV42 pixel formats

2019-05-06 Thread 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 interop for 4:4:4 surfaces. Signed-off-by: Philip Langdale --- libavutil/pixdesc.c | 24

Re: [FFmpeg-devel] [PATCH 0/3] *** VDPAU: HEVC YUV 4:4:4 Support ***

2019-05-06 Thread Philip Langdale
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 =

Re: [FFmpeg-devel] [PATCH 0/3] *** VDPAU: HEVC YUV 4:4:4 Support ***

2019-05-05 Thread Philip Langdale
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

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

2019-05-05 Thread Philip Langdale
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

Re: [FFmpeg-devel] [PATCH 0/3] *** VDPAU: HEVC YUV 4:4:4 Support ***

2019-04-25 Thread Philip Langdale
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

Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#4]

2019-04-08 Thread Philip Langdale via ffmpeg-devel
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

Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#4]

2019-04-08 Thread Philip Langdale via ffmpeg-devel
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.

Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#4]

2019-04-08 Thread Philip Langdale via ffmpeg-devel
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

Re: [FFmpeg-devel] [PATCH v3 1/2] vf_crop: Add support for cropping hardware frames

2019-03-24 Thread Philip Langdale via ffmpeg-devel
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

Re: [FFmpeg-devel] [PATCH][FFmpeg-devel v2] Add GPU accelerated video crop filter

2019-03-24 Thread Philip Langdale via ffmpeg-devel
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 + >

Re: [FFmpeg-devel] [PATCH 4/5] avfilter/vf_thumbnail_cuda: Switch to using ffnvcodec

2019-02-22 Thread Philip Langdale
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

[FFmpeg-devel] [PATCH 0/5] Clean up CUDA SDK usage and remove non-free requirement

2019-02-20 Thread Philip Langdale
. With 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: Switch

[FFmpeg-devel] [PATCH 2/5] avfilter/vf_yadif_cuda: Switch to using ffnvcodec

2019-02-20 Thread Philip Langdale
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

[FFmpeg-devel] [PATCH 5/5] configure: Remove cuda_sdk dependency option

2019-02-20 Thread Philip Langdale
, the 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

[FFmpeg-devel] [PATCH 3/5] avfilter/vf_scale_cuda: Switch to using ffnvcodec

2019-02-20 Thread Philip Langdale
, and 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

[FFmpeg-devel] [PATCH 4/5] avfilter/vf_thumbnail_cuda: Switch to using ffnvcodec

2019-02-20 Thread Philip Langdale
, 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

[FFmpeg-devel] [PATCH 1/5] configure: Add an explicit check and option for nvcc

2019-02-20 Thread Philip Langdale
)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 bf40c1dcb9

[FFmpeg-devel] [PATCH] avutil/cuda_check: Fix non-dynamic-loader implementation

2019-02-19 Thread Philip Langdale
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 --- libavutil

[FFmpeg-devel] [PATCH] avfilter/vf_yadif_cuda: Relicence cuda kernel to MIT

2019-02-19 Thread Philip Langdale
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 100644

Re: [FFmpeg-devel] FW: Requirements for compiling with CUDA_SDK option enabled

2019-02-19 Thread Philip Langdale
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

Re: [FFmpeg-devel] FW: Requirements for compiling with CUDA_SDK option enabled

2019-02-19 Thread Philip Langdale
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

Re: [FFmpeg-devel] FW: Requirements for compiling with CUDA_SDK option enabled

2019-02-18 Thread Philip Langdale
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

Re: [FFmpeg-devel] FW: Requirements for compiling with CUDA_SDK option enabled

2019-02-18 Thread Philip Langdale
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

Re: [FFmpeg-devel] [PATCH 4/4] avcodec/cuviddec: Add support for decoding HEVC 4:4:4 content

2019-02-14 Thread Philip Langdale
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

[FFmpeg-devel] [PATCH 2/4] avcodec/nvdec: Add support for decoding HEVC 4:4:4 content

2019-02-13 Thread Philip Langdale
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

[FFmpeg-devel] [PATCH 1/4] avcodec/hevc_ps: Expose all SPS and PPS range extension flags

2019-02-13 Thread Philip Langdale
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 Langdale

[FFmpeg-devel] [PATCH 4/4] avcodec/cuviddec: Add support for decoding HEVC 4:4:4 content

2019-02-13 Thread Philip Langdale
the 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

[FFmpeg-devel] [PATCH 3/4] avcodec/nvdec: Explicitly mark codecs that support 444 output formats

2019-02-13 Thread Philip Langdale
-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

[FFmpeg-devel] [PATCH 0/4] nvdec/cuviddec: Support HEVC 4:4:4 decoding

2019-02-13 Thread Philip Langdale
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 4:4:4

Re: [FFmpeg-devel] [PATCH 2/2] libavcodec/cuviddec: adding HEVC YUV444P decoding support

2019-02-13 Thread Philip Langdale
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, > >

Re: [FFmpeg-devel] fate-source : add cuda_check to ignore files list

2018-11-17 Thread Philip Langdale
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

Re: [FFmpeg-devel] HEVC decoder for Raspberry Pi

2018-11-15 Thread Philip Langdale
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.

Re: [FFmpeg-devel] [PATCH 0/2] Update vf_bwdif to use yadif_common v2

2018-11-14 Thread Philip Langdale
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 th

[FFmpeg-devel] [PATCH 2/2] avfilter/vf_bwdif: Use common yadif frame management logic

2018-11-11 Thread Philip Langdale
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

[FFmpeg-devel] [PATCH 1/2] avfilter/yadif_common: Add field type tracking to help bwdif

2018-11-11 Thread Philip Langdale
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. ---

[FFmpeg-devel] [PATCH 0/2] Update vf_bwdif to use yadif_common v2

2018-11-11 Thread Philip Langdale
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 + libavfilter

[FFmpeg-devel] [PATCH 2/2] avfilter/vf_bwdif: Use common yadif frame management logic

2018-11-10 Thread Philip Langdale
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

[FFmpeg-devel] [PATCH 1/2] avfilter/yadif_common: Add field type tracking to help bwdif

2018-11-10 Thread Philip Langdale
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. ---

[FFmpeg-devel] [PATCH 0/2] Update vf_bwdif to use yadif_common

2018-11-10 Thread Philip Langdale
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 | 235

Re: [FFmpeg-devel] [PATCH] Add CUDA function cuDeviceGetAttribute

2018-11-01 Thread Philip Langdale
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

[FFmpeg-devel] [PATCH 3/3] avcodec/nvdec: Increase frame pool size to help deinterlacing

2018-11-01 Thread Philip Langdale
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

[FFmpeg-devel] [PATCH 2/3] avfilter/vf_yadif_cuda: CUDA accelerated deinterlacer

2018-11-01 Thread Philip Langdale
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

[FFmpeg-devel] [PATCH 0/3] CUDA implementation of yadif filter v2

2018-11-01 Thread Philip Langdale
. (It 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 frame

[FFmpeg-devel] [PATCH 1/3] libavfilter/vf_yadif: Make frame management logic and options shareable

2018-11-01 Thread Philip Langdale
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 ++ libavfilter

Re: [FFmpeg-devel] [PATCH 2/3] avfilter/vf_yadif_cuda: CUDA accelerated deinterlacer

2018-11-01 Thread Philip Langdale
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 ->

Re: [FFmpeg-devel] [PATCH 2/3] avfilter/vf_yadif_cuda: CUDA accelerated deinterlacer

2018-11-01 Thread Philip Langdale
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

Re: [FFmpeg-devel] [PATCH 1/3] libavfilter/vf_yadif: Make frame management logic and options shareable

2018-11-01 Thread Philip Langdale
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

[FFmpeg-devel] [PATCH 2/3] avfilter/vf_yadif_cuda: CUDA accelerated deinterlacer

2018-10-26 Thread Philip Langdale
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

[FFmpeg-devel] [PATCH 3/3] avcodec/nvdec: Increase frame pool size to help deinterlacing

2018-10-26 Thread Philip Langdale
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

[FFmpeg-devel] [PATCH 1/3] libavfilter/vf_yadif: Make frame management logic and options shareable

2018-10-26 Thread Philip Langdale
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 ++ libavfilter

[FFmpeg-devel] [PATCH 0/3] CUDA implementation of yadif filter

2018-10-26 Thread Philip Langdale
. (It 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 deinterlacer

Re: [FFmpeg-devel] [PATCH 4/5] avcodec/cuviddec: Add support for decoding HEVC 4:4:4 content

2018-10-20 Thread Philip Langdale
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 =

Re: [FFmpeg-devel] [PATCH 2/5] avcodec/nvdec: Add support for decoding HEVC 4:4:4 content

2018-10-20 Thread Philip Langdale
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

[FFmpeg-devel] [PATCH 1/5] avutil: Add YUV444P10_MSB and YUV444P12_MSB pixel formats

2018-10-20 Thread Philip Langdale
, but 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

[FFmpeg-devel] [PATCH 0/5] Add nvidia hw decode support for HEVC 4:4:4 content

2018-10-20 Thread Philip Langdale
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 pixel formats avcodec/nvdec: Add support for decoding HEVC 4:4:4 content

[FFmpeg-devel] [PATCH 3/5] avcodec/nvdec: Explicitly mark codecs that support 444 output formats

2018-10-20 Thread Philip Langdale
-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

[FFmpeg-devel] [PATCH 4/5] avcodec/cuviddec: Add support for decoding HEVC 4:4:4 content

2018-10-20 Thread Philip Langdale
the 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

[FFmpeg-devel] [PATCH 5/5] avcodec/nvenc: Accept YUV444P10_MSB and YUV444P12_MSB content

2018-10-20 Thread 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 --- Changelog

[FFmpeg-devel] [PATCH 2/5] avcodec/nvdec: Add support for decoding HEVC 4:4:4 content

2018-10-20 Thread Philip Langdale
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 --- libavcodec/hevcdec.c

Re: [FFmpeg-devel] [PATCH 1/5] avutil: Add YUV444P10_LSB and YUV444P12_LSB pixel formats

2018-10-08 Thread Philip Langdale
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

Re: [FFmpeg-devel] [PATCH 4/5] avcodec/cuviddec: Add support for decoding HEVC 4:4:4 content

2018-10-07 Thread Philip Langdale
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

[FFmpeg-devel] [PATCH 5/5] avcodec/nvenc: Accept YUV444P10_LSB and YUV444P12_LSB content

2018-10-07 Thread 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 --- Changelog

[FFmpeg-devel] [PATCH 3/5] avcodec/nvdec: Explicitly mark codecs that support 444 output formats

2018-10-07 Thread Philip Langdale
-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

[FFmpeg-devel] [PATCH 2/5] avcodec/nvdec: Add support for decoding HEVC 4:4:4 content

2018-10-07 Thread Philip Langdale
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 --- libavcodec/hevcdec.c

[FFmpeg-devel] [PATCH 4/5] avcodec/cuviddec: Add support for decoding HEVC 4:4:4 content

2018-10-07 Thread Philip Langdale
the 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

[FFmpeg-devel] [PATCH 0/5] Add nvidia hw decode support for HEVC 4:4:4 content

2018-10-07 Thread Philip Langdale
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

[FFmpeg-devel] [PATCH 1/5] avutil: Add YUV444P10_LSB and YUV444P12_LSB pixel formats

2018-10-07 Thread Philip Langdale
, but 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

[FFmpeg-devel] [PATCH] avcodec/nvdec: Add support for decoding HEVC 4:4:4 content

2018-10-06 Thread Philip Langdale
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

Re: [FFmpeg-devel] [PATCH] avcodec/nvdec_hevc: Fix scaling lists

2018-05-10 Thread Philip Langdale
On Thu, 10 May 2018 12:18:13 +0200 Timo Rothenpieler <t...@rothenpieler.org> wrote: > Am 10.05.2018 um 03:48 schrieb Philip Langdale: > > The main issue here was the use of [i] instead of [i * 3] for the > > 32x32 matrix. As part of fixing this, I changed the code t

Re: [FFmpeg-devel] [PATCH] avcodec/hevcdec: make ff_hevc_frame_nb_refs take a const pointer

2018-05-10 Thread Philip Langdale
On Thu, 10 May 2018 12:23:01 +0200 Timo Rothenpieler wrote: > --- > libavcodec/hevc_refs.c | 4 ++-- > libavcodec/hevcdec.h | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c > index

[FFmpeg-devel] [PATCH] avcodec/nvdec_hevc: Fix scaling lists

2018-05-09 Thread Philip Langdale
The main issue here was the use of [i] instead of [i * 3] for the 32x32 matrix. As part of fixing this, I changed the code to match that used in vdpau_hevc, which I spent a lot of time verifying. I also changed to calculating NumPocTotalCurr using the existing helper, which is what vdpau does.

Re: [FFmpeg-devel] [PATCH 1/5] avcodec/nvdec: avoid needless copy of output frame

2018-05-08 Thread Philip Langdale
On 2018-05-08 11:36, Timo Rothenpieler wrote: Replaces the data pointers with the mapped cuvid ones. Adds buffer_refs to the frame to ensure the needed contexts stay alive and the cuvid idx stays allocated. Adds another buffer_ref to unmap the frame when it's unreferenced itself. ---

Re: [FFmpeg-devel] [PATCH] avutil/hwcontext: add flags field to AVHWFramesContext

2018-05-07 Thread Philip Langdale
On 2018-05-07 11:39, Timo Rothenpieler wrote: --- doc/APIchanges| 3 +++ libavutil/hwcontext.h | 7 +++ libavutil/version.h | 2 +- 3 files changed, 11 insertions(+), 1 deletion(-) diff --git a/doc/APIchanges b/doc/APIchanges index ede5b186ae..307c7a51ee 100644 ---

Re: [FFmpeg-devel] cuda-gl

2018-04-30 Thread Philip Langdale
On 2018-04-30 08:20, Daniel Oberhoff wrote: On 30. Apr 2018, at 15:52, Daniel Oberhoff wrote: Hello All, I am fighting since a few days to get the frames from the cuvid decoder using the cuda pixel format transfered to opengl. What i have done is create

Re: [FFmpeg-devel] [PATCH 1/1] add CUgraphicsRegisterFlags enum

2018-04-28 Thread Philip Langdale
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 26 Apr 2018 17:09:14 +0200 Daniel Oberhoff wrote: > > On 26. Apr 2018, at 16:20, Daniel Oberhoff > > wrote: > > > > --- > > include/ffnvcodec/dynlink_cuda.h | 8 > > 1 file

Re: [FFmpeg-devel] [PATCH] avcodec/nvdec_hevc: add support for new extended sps/pps flags from SDK 8.1

2018-04-11 Thread Philip Langdale
On Wed, 11 Apr 2018 13:48:59 +0200 t...@rothenpieler.org wrote: > From: Timo Rothenpieler > > --- > libavcodec/hevc_ps.c| 5 ++--- > libavcodec/hevc_ps.h| 1 + > libavcodec/nvdec_hevc.c | 6 ++ > 3 files changed, 9 insertions(+), 3 deletions(-) > > diff

Re: [FFmpeg-devel] [PATCH] avcodec/movtextdec: Check style_start/end

2018-04-07 Thread Philip Langdale
On Sun, 8 Apr 2018 03:29:44 +0200 Michael Niedermayer wrote: > Limits based on 3GPP TS 26.245 V14.0.0 > Fixes: Timeout > Fixes: > 6377/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOVTEXT_fuzzer-5175929115508736 > > Found-by: continuous fuzzing process >

Re: [FFmpeg-devel] [PATCH] movtextenc: fix handling of utf-8 subtitles

2018-03-28 Thread Philip Langdale
On Wed, 28 Mar 2018 13:14:57 +0200 wm4 wrote: > On Wed, 28 Mar 2018 14:02:04 +0300 > Andrey Turkin wrote: > > > I think first check (ascii case) should be explicit bit-test, or > > (if there is some reason to use sign-bit approach) at least "c" >

Re: [FFmpeg-devel] [PATCH] movtextenc: fix handling of utf-8 subtitles

2018-03-28 Thread Philip Langdale
On Wed, 28 Mar 2018 12:01:47 +0200 wm4 wrote: > > LGTM. > > Maybe a later patch that adds the UTF-8 length as lavu function (or > macro for SPEEED?) eould be nice, since we seem to need that often. I can do that. Although, I'm not sure the SPEEED version is readable

[FFmpeg-devel] [PATCH] movtextenc: fix handling of utf-8 subtitles

2018-03-28 Thread Philip Langdale
See the earlier fix for movtextdec for details. The equivalent bug is present on the encoder side as well. We need to track the text length in 'characters' (which seems to really mean codepoints) to ensure that styles are applied across the correct ranges. Signed-off-by: Philip Langdale <p

[FFmpeg-devel] [PATCH] movtextenc: fix handling of utf-8 subtitles

2018-03-27 Thread Philip Langdale
See the earlier fix for movtextdec for details. The equivalent bug is present on the encoder side as well. We need to track the text length in 'characters' (which seems to really mean codepoints) to ensure that styles are applied across the correct ranges. Signed-off-by: Philip Langdale <p

Re: [FFmpeg-devel] [PATCH] avcodec: add a subcharenc mode that disables UTF-8 check

2018-03-25 Thread Philip Langdale
On Sat, 24 Mar 2018 13:43:21 +0100 wm4 wrote: > This is for applications which want to explicitly check for invalid > UTF-8 manually, and take actions that are better than dropping invalid > subtitles silently. (It's pretty much silent because sporadic avcodec > error

  1   2   3   4   5   >