[FFmpeg-devel] [PATCH] vaapi: Add VP9 hwaccell support

2015-12-19 Thread Timo Rothenpieler
Signed-off-by: Timo Rothenpieler <t...@rothenpieler.org> --- Changelog | 1 + configure | 3 + libavcodec/Makefile| 1 + libavcodec/allcodecs.c | 1 + libavcodec/vaapi_vp9.c | 168 + libavcodec/version.h

Re: [FFmpeg-devel] [PATCH] vaapi: Add VP9 hwaccell support

2015-12-21 Thread Timo Rothenpieler
ping Is any further review required, or is it fine to just push? signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avcodec/cuvid: add cuvid decoder

2016-06-05 Thread Timo Rothenpieler
Philip Langdale cscd.cReimar Doeffinger + cuvid.c Timo Rothenpieler dca.c Kostya Shishkov, Benjamin Larsson dirac*Rostislav Pehlivanov dnxhd

[FFmpeg-devel] [PATCH 2/2] ffmpeg: Add cuvid hwaccel support

2016-06-05 Thread Timo Rothenpieler
--- Makefile | 1 + ffmpeg.c | 5 ++ ffmpeg.h | 3 + ffmpeg_cuvid.c | 201 + ffmpeg_opt.c | 3 + 5 files changed, 213 insertions(+) create mode 100644 ffmpeg_cuvid.c diff --git a/Makefile b/Makefile index

Re: [FFmpeg-devel] FFmpeg 3.1

2016-06-06 Thread Timo Rothenpieler
I'd like to merge the cuvid decoder/hwaccel for 3.1. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v3 1/3] avcodec/cuvid: add cuvid decoder

2016-06-07 Thread Timo Rothenpieler
Hilb crystalhd.c Philip Langdale cscd.cReimar Doeffinger + cuvid.c Timo Rothenpieler dca.c Kostya Shishkov, Benjamin Larsson dirac

[FFmpeg-devel] [PATCH v3 3/3] ffmpeg: unref hw_frames_ctx on cleanup

2016-06-07 Thread Timo Rothenpieler
--- ffmpeg.c | 1 + 1 file changed, 1 insertion(+) diff --git a/ffmpeg.c b/ffmpeg.c index 652774f..45c19fc 100644 --- a/ffmpeg.c +++ b/ffmpeg.c @@ -550,6 +550,7 @@ static void ffmpeg_cleanup(int ret) av_frame_free(>sub2video.frame); av_freep(>filters);

[FFmpeg-devel] [PATCH v3 2/3] ffmpeg: Add cuvid hwaccel support

2016-06-07 Thread Timo Rothenpieler
--- Makefile | 1 + ffmpeg.c | 5 ++ ffmpeg.h | 3 + ffmpeg_cuvid.c | 229 + ffmpeg_opt.c | 3 + 5 files changed, 241 insertions(+) create mode 100644 ffmpeg_cuvid.c diff --git a/Makefile b/Makefile index

Re: [FFmpeg-devel] [RFC] MAINTAINERS cleanup

2016-06-12 Thread Timo Rothenpieler
On 6/11/2016 12:57 PM, Michael Niedermayer wrote: > Hi > > the MAINTAINERs file contains a bunch of inaccurate and outdated > entries. > > What should be done about this ? > should we remove everyone who was inactive in FFmpeg > (aka no commit/author since 2 years) as in git log --first-parent

[FFmpeg-devel] [PATCH 1/2] avcodec/cuvid: add cuvid decoder

2016-06-10 Thread Timo Rothenpieler
Hilb crystalhd.c Philip Langdale cscd.cReimar Doeffinger + cuvid.c Timo Rothenpieler dca.c Kostya Shishkov, Benjamin Larsson dirac

[FFmpeg-devel] [PATCH 0/2] Add CUDA CUVID decoder/hwaccel

2016-06-10 Thread Timo Rothenpieler
Will push later today if there are no further comments or objections. Timo Rothenpieler (2): avcodec/cuvid: add cuvid decoder ffmpeg: Add cuvid hwaccel support Changelog | 2 + MAINTAINERS| 1 + Makefile | 1 + configure | 34

[FFmpeg-devel] [PATCH 2/2] ffmpeg: Add cuvid hwaccel support

2016-06-10 Thread Timo Rothenpieler
--- Makefile | 1 + ffmpeg.c | 5 ++ ffmpeg.h | 3 + ffmpeg_cuvid.c | 237 + ffmpeg_opt.c | 3 + 5 files changed, 249 insertions(+) create mode 100644 ffmpeg_cuvid.c diff --git a/Makefile b/Makefile index

[FFmpeg-devel] [PATCH v2 1/2] avcodec/cuvid: add cuvid decoder

2016-06-06 Thread Timo Rothenpieler
Philip Langdale cscd.cReimar Doeffinger + cuvid.c Timo Rothenpieler dca.c Kostya Shishkov, Benjamin Larsson dirac*Rostislav Pehlivanov dnxhd

[FFmpeg-devel] [PATCH v2 2/2] ffmpeg: Add cuvid hwaccel support

2016-06-06 Thread Timo Rothenpieler
--- Makefile | 1 + ffmpeg.c | 5 ++ ffmpeg.h | 3 + ffmpeg_cuvid.c | 217 + ffmpeg_opt.c | 3 + 5 files changed, 229 insertions(+) create mode 100644 ffmpeg_cuvid.c diff --git a/Makefile b/Makefile index

Re: [FFmpeg-devel] [PATCH v4 1/5] libavutil: VAAPI infrastructure

2016-01-24 Thread Timo Rothenpieler
>> +void *address; >> +// On current Intel drivers, derive gives you memory which is very slow >> +// to read (uncached?). It can be better for write-only cases, but for >> +// now play it safe and never use derive. > > Still subject to debate when we introduce a "GPU memcpy". >

[FFmpeg-devel] [PATCH] configure: Fail if CUDA enabled but not found

2016-03-25 Thread Timo Rothenpieler
Without this patch, configure still passes and enables CUDA, no matter if it was actually found, breaking the build in case it was not. --- configure | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/configure b/configure index feb0bc2..2b16198 100755 --- a/configure +++

Re: [FFmpeg-devel] [PATCH] configure: Fail if CUDA enabled but not found

2016-03-27 Thread Timo Rothenpieler
ping Any objections/problems, or can I push this? Timo signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

2016-03-04 Thread Timo Rothenpieler
>> Of course, this argument operates on the premise that >> making things easier for users is of utmost concern >> for us. Please inspire me if this is not the case. > > On the contrary, I believe while the current versioing > scheme is simple and understandable, the suggested one > is

Re: [FFmpeg-devel] [PATCH] nvenc Fix H264 and HEVC vui info update

2016-03-04 Thread Timo Rothenpieler
>> >> In case of the git send-email sends corrupted patch again, I attach the >> original patch file. >> >> Agatha Hu >> > > That's strange, does anyone received my patch sent at 17:22 GMT+8? > Looks like the first mail (sent by git sent-email, no attachment) was somehow > blocked. > > Agatha

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

2016-03-04 Thread Timo Rothenpieler
> So what about the release tag? Well it is a quite useful extension because of > the already mentioned possibility of determining the existing features at > once. > I'm pro adding it to the version string. The release tags are not made in the master branch, so git describe won't pick them up.

Re: [FFmpeg-devel] [PATCH] nvenc Fix H264 and HEVC vui info update

2016-03-04 Thread Timo Rothenpieler
> breaks build here > > libavcodec/nvenc.c: In function ‘nvenc_encode_init’: > libavcodec/nvenc.c:952:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named > ‘hevcVUIParameters’ > libavcodec/nvenc.c:953:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named > ‘hevcVUIParameters’ >

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

2016-03-03 Thread Timo Rothenpieler
> Accessing a remote URL in the version script seems like a bad idea to me. I aggree, but I'm unsure how to propperly address the issue. The problem is that a plain "git pull" does not update tags, so if you have an older clone you allways updated via git pull, you end up with a version number

[FFmpeg-devel] [PATCH] configure: NVENC API version 6 is now required

2016-03-04 Thread Timo Rothenpieler
--- configure | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure b/configure index 81769ee..9b56a4d 100755 --- a/configure +++ b/configure @@ -5681,8 +5681,8 @@ enabled mmal && enabled netcdf&& require_pkg_config netcdf netcdf.h nc_inq_libvers

[FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

2016-03-03 Thread Timo Rothenpieler
The version numbers based on the 15 years old N tag are confusing and don't offer a lot of information about what release the version is close to. This patch stops using the N tag and always bases it on the most recent dev tag instead. So instead of N-78885-g966eade One now gets

Re: [FFmpeg-devel] [PATCH] Add encoder stats to the NVENC codec.

2016-03-07 Thread Timo Rothenpieler
> --- > libavcodec/nvenc.c | 18 +++--- > 1 file changed, 11 insertions(+), 7 deletions(-) > > diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c > index a3b02fa..67232c7 100644 > --- a/libavcodec/nvenc.c > +++ b/libavcodec/nvenc.c > @@ -1208,31 +1208,35 @@ static int

Re: [FFmpeg-devel] [PATCH] configure: Don't require nonfree for nvenc

2016-04-25 Thread Timo Rothenpieler
ping I'd really like some feedback on this. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: Don't require nonfree for nvenc

2016-04-27 Thread Timo Rothenpieler
> On Wed, 27 Apr 2016 12:19:10 +0200, Timo Rothenpieler wrote: > >> Will push Sunday the 1st if nobody has objected by then. > > Nobody has objected and it's been 4 days. Feel free to push now if you > prefer. pushed signature.asc Description: Open

Re: [FFmpeg-devel] [PATCH] configure: Don't require nonfree for nvenc

2016-04-27 Thread Timo Rothenpieler
Will push Sunday the 1st if nobody has objected by then. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] configure: Don't require nonfree for nvenc

2016-04-23 Thread Timo Rothenpieler
As the nvEncodeApi.h header is now MIT licensed, this can be dropped. The loaded CUDA and NVENC libraries are part of the nvidia driver, and thus count as system libraries. --- configure | 1 - 1 file changed, 1 deletion(-) diff --git a/configure b/configure index 97f374b..1a4ff56 100755 ---

Re: [FFmpeg-devel] Compile using bash in Win10 anniversary?

2016-08-13 Thread Timo Rothenpieler
On 8/12/2016 8:12 PM, Dan Haddix wrote: > Can you cross compile ffmpeg for Windows using the new bash built in to Win10 > anniversary? I'm currently using MinGW but it seems like it might be easier > to use the built in bash if possible. However I tried a basic build, using > the same commands

Re: [FFmpeg-devel] why ffmpeg 3.1.1 still uses AVStream::codec

2016-07-19 Thread Timo Rothenpieler
> Hi, > > I have read part of source code of ffmpeg 3.1.1. In the structure of 'struct > AVStream', 'AVCodecContext *codec' is declared as deprecated. But in > ffmpeg.c, 'AVCodecContext *codec' is still used in some functions. Why? Because nobody felt like changing that yet.

[FFmpeg-devel] [PATCH 3/3] lavfi: Move new field to the end of AVFilterContext

2016-06-29 Thread Timo Rothenpieler
--- libavfilter/avfilter.h | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h index 8a7f791..757b81a 100644 --- a/libavfilter/avfilter.h +++ b/libavfilter/avfilter.h @@ -344,6 +344,13 @@ struct AVFilterContext {

[FFmpeg-devel] [PATCH 0/3] Correct (non-public) ABI breakage since 3.0

2016-06-29 Thread Timo Rothenpieler
place. Moving it now _will_ break ffmpeg/ffplay from 3.1.0 linked against the updated libraries. Nothing external seems to be accessing the fields after the hw_device_ctx, so it's more then questionable if it should be moved. Timo Rothenpieler (3): ffplay: Fix usage of private lavfi API lavfi

[FFmpeg-devel] [PATCH 2/3] lavfi: Move new field to the end of AVFilterLink

2016-06-29 Thread Timo Rothenpieler
Even though this is not part of the public API, some external applications access fields after it, thus breaking after updating from ffmpeg 3.0 or earlier. Since it is not public, it can be freely moved to the end to avoid that problem in the future. --- libavfilter/avfilter.h | 12 ++--

[FFmpeg-devel] [PATCH 1/3] ffplay: Fix usage of private lavfi API

2016-06-29 Thread Timo Rothenpieler
--- ffplay.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ffplay.c b/ffplay.c index f28e087..b0702eb 100644 --- a/ffplay.c +++ b/ffplay.c @@ -2725,7 +2725,7 @@ static int stream_component_open(VideoState *is, int stream_index) goto fail; link

Re: [FFmpeg-devel] [PATCH] doc/APIchanges: document the lavu/lavf field moves

2016-06-30 Thread Timo Rothenpieler
On 6/30/2016 6:15 PM, Michael Niedermayer wrote: > The text is copied from the lavfi case. Not sure this matches > exactly private / public ABI wise, better text welcome! > > Signed-off-by: Michael Niedermayer > --- > doc/APIchanges | 16 > 1 file

[FFmpeg-devel] [PATCH] lavfi: Move new field to the end of AVFilterContext

2016-06-29 Thread Timo Rothenpieler
This fixes an accidental ABI break introduced at 8688d3a. --- doc/APIchanges | 8 libavfilter/avfilter.h | 14 +++--- libavfilter/version.h | 4 ++-- 3 files changed, 17 insertions(+), 9 deletions(-) diff --git a/doc/APIchanges b/doc/APIchanges index 6dd5ad7..47106c2

Re: [FFmpeg-devel] [PATCH] lavfi: Move new field to the end of AVFilterContext

2016-06-29 Thread Timo Rothenpieler
> (1) Iam not sure APIchanges, RELEASE_NOTES or Changelog is the best > place, iam fine with any of them ... APIchanges seems like the place where a distribution maintainer would most likely look for something like this to me. ___ ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/frame: Move new field to the end of AVFrame

2016-06-29 Thread Timo Rothenpieler
On 6/29/2016 10:31 PM, Michael Niedermayer wrote: > This is a similar ABI fix to 1eb43af1a0e542ad83dcbf327197785d815fc42d +1 for this. While it's true that all fields after it are not public API/ABI, a lot of software seems to misuse it, so to avoid too much trouble for now, this should be

Re: [FFmpeg-devel] [PATCH] avutil/frame: Move new field to the end of AVFrame

2016-06-29 Thread Timo Rothenpieler
>> During an actual major bump, where such breakage is expected. >> A lot of stuff gets it wrong, and it is indeed confusing, so putting all >> blame on API users seems wrong to me. Specially as this issue will block >> distributions from adapting 3.1. > > How? Just like they are updating to 3.1,

Re: [FFmpeg-devel] [PATCH] avutil/frame: Move new field to the end of AVFrame

2016-06-29 Thread Timo Rothenpieler
>> While it's true that all fields after it are not public API/ABI, a lot >> of software seems to misuse it, so to avoid too much trouble for now, >> this should be fixed. > > How do you expect library users to start using the API correctly if every > time they do something wrong we are the ones

Re: [FFmpeg-devel] [PATCH 3/3] lavfi: Move new field to the end of AVFilterContext

2016-06-29 Thread Timo Rothenpieler
> This has to be documented in APIChanges i think Adding that field was documented there originally. It came in as a merge from libav in 8688d3a, and should have been merged to the end of the struct there. Technically it was an ABI break, but nothing seems to be affected by it. So I'm not

Re: [FFmpeg-devel] [PATCH 1/2] avutil: Add MSB packed YUV444P10 format

2017-02-02 Thread Timo Rothenpieler
>> In the mean time, common 12 bit content (YUV420P12 or P016) will be >> correctly converted to P010 for nvenc. > > What does this change have to do with 4:2:0 content? Apparently swscale decides that any kind of 12 or 16 bit content, even if 4:2:0, whould be converted to YUV444P16 instead of

Re: [FFmpeg-devel] Add 10-bit transcode support for hwaccel cuvid

2017-01-31 Thread Timo Rothenpieler
> Hi, > > Please review the attached patch which adds 420 10-bit transcode support for > hwaccel cuvid. > > Sample Command: > ffmpeg -hwaccel cuvid -c:v hevc_cuvid -i input.265 -c:v hevc_nvenc output.265 > > Thanks, > Sumit Are you sure the attached patch is complete? All it does is replace

Re: [FFmpeg-devel] Add 10-bit transcode support for hwaccel cuvid

2017-02-01 Thread Timo Rothenpieler
applied ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/6] lavc: Add device context field to AVCodecContext

2017-02-01 Thread Timo Rothenpieler
Am 17.01.2017 um 23:28 schrieb Mark Thompson: > For use by codec implementations which require a device to operation > but will allocate frames internally. > --- > The following patches make use of it for qsv. Is this definition appropriate > to solve the issues with cuvid device setup as well?

Re: [FFmpeg-devel] Add 10-bit transcode support for hwaccel cuvid

2017-01-31 Thread Timo Rothenpieler
> IIRC, past conversations on this have concluded that the 'avconv' > rewrite will allow this by > avoiding the current problem that the encoder is fully initialised up > front before the cuvid > parser can run. Presumably, at some point in the future, we'll get > through the merge backlog > and

Re: [FFmpeg-devel] [PATCH 1/6] lavc: Add device context field to AVCodecContext

2017-01-22 Thread Timo Rothenpieler
This would also be very useful for cuvid, and would remove some ugly hacks and confusing corner cases from both cuvid.c and ffmpeg_cuvid.c. patch looks fine to me as well ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle video parameters

2017-01-22 Thread Timo Rothenpieler
> Despite wm4 objections I am resubmitting this patch, because I can > find no other reasonable method for rejecting ffmpeg cuvid decoder > when it can't handle a given video stream. An unreasonable > alternative would be to duplicate the work that cuvid.c does > internally on my application

Re: [FFmpeg-devel] [PATCH] cuvid: don't overwrite deinterlace at progressive input

2017-02-18 Thread Timo Rothenpieler
applied ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] cuvid: add drop_second_field as input option v2

2017-02-18 Thread Timo Rothenpieler
applied ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] (for discussion): ffmpeg_filter: initialize cuvid for filter_complex

2017-02-13 Thread Timo Rothenpieler
> It is problem in NVENC. > > You create first frame before initialization of NVENC in CUVID, so this > first frame is not accesible to NVENC until > dl_fn->cuda_dl->cuCtxPushCurrent(ctx->cu_context) is called in NVENC. > > This trivial patch should fix your problem. > > M. Very interesting. I

Re: [FFmpeg-devel] [PATCH] cuvid: add drop_second_field as input option and enable it by default

2017-02-12 Thread Timo Rothenpieler
It does make sense, the deinterlacers convert 50 interlaced fields to 50 progressive frames, like for example yadif can do as well. And disabling that functionality by default seems strange to me, as it's clearly the superior mode of operation. On 2/12/2017 8:02 PM, Miroslav Slugeň wrote: >

Re: [FFmpeg-devel] [PATCH] cuvid: add drop_second_field as input option and enable it by default

2017-02-12 Thread Timo Rothenpieler
On 2/12/2017 8:35 PM, Miroslav Slugeň wrote: > Thx for comment, > > cuvid can't output 50fps deinterlaced output, both frames are same, and > default behavior for yadif is to downcovert to half frame rate, so i > think is very clever to do the same here. > > Also if we return in decoder that

Re: [FFmpeg-devel] [PATCH] (for discussion): ffmpeg_filter: initialize cuvid for filter_complex

2017-02-12 Thread Timo Rothenpieler
On 2/12/2017 8:53 PM, Miroslav Slugeň wrote: > Dne 12.2.2017 v 20:25 Timo Rothenpieler napsal(a): >> On 2/12/2017 8:18 PM, Miroslav Slugeň wrote: >>> This patch is for discussion only, not ready to commit yet. >>> >>> We were facing issue when using -hwaccel c

Re: [FFmpeg-devel] [PATCH] (for discussion): ffmpeg_filter: initialize cuvid for filter_complex

2017-02-12 Thread Timo Rothenpieler
On 2/12/2017 8:18 PM, Miroslav Slugeň wrote: > This patch is for discussion only, not ready to commit yet. > > We were facing issue when using -hwaccel cuvid, then we were unable to > use -filter_complex filters for video streams, this hack fixed it, but i > am sure that it is not ready to

Re: [FFmpeg-devel] [PATCH] nvenc: FIX wrong forced keyframe behavior

2017-02-12 Thread Timo Rothenpieler
On 2/12/2017 8:43 PM, Miroslav Slugeň wrote: > Dne 12.2.2017 v 20:29 Timo Rothenpieler napsal(a): >> The current behavior is intended like it is. >> On the default of -1, it does not care about I/IDR frame requests, in >> mode 0 it will generate intra frames, and in mode 1 it

Re: [FFmpeg-devel] [PATCH] nvenc: support dynamic aspect ratio change

2017-02-12 Thread Timo Rothenpieler
On 2/12/2017 7:53 PM, Miroslav Slugeň wrote: > If there is input like DVB-T streams it can change aspect ratio > on-the-fly, so nvenc should respect this change and change aspect ratio > in encoder. Haven't tested yet, but seems like a good idea. Are there other parameters that would make sense

Re: [FFmpeg-devel] [PATCH] nvenc: FIX wrong forced keyframe behavior

2017-02-12 Thread Timo Rothenpieler
On 2/12/2017 8:56 PM, Miroslav Slugeň wrote: >>> 2. We should change it in libx264 and libx265 >> Changing it in nvenc now would be kind of an API break, as the behaviour >> might change without someone expecting it. >> ___ >> ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH] nvenc: FIX wrong forced keyframe behavior

2017-02-12 Thread Timo Rothenpieler
The current behavior is intended like it is. On the default of -1, it does not care about I/IDR frame requests, in mode 0 it will generate intra frames, and in mode 1 it will generate full IDR frames. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] (for discussion): nvenc: fix wrong aspect ratio for 720x576 and 720x480 resolution

2017-02-12 Thread Timo Rothenpieler
On 2/12/2017 10:43 PM, Miroslav Slugeň wrote: > Dne 12.2.2017 v 22:31 Timo Rothenpieler napsal(a): >> On 2/12/2017 10:25 PM, Miroslav Slugeň wrote: >>> This patch is for discussion only, not ready to commit yet and maybe >>> newer will be. >>> >>>

Re: [FFmpeg-devel] [PATCH] (for discussion): ffmpeg_filter: initialize cuvid for filter_complex

2017-02-12 Thread Timo Rothenpieler
> I have seen those patches in mailing list. Have you tried it on QUADRO > cards which are not limited to only 2 streams per system? It could be > related to protection in NVIDIA drivers for NON-PRO cards. It it definitely not related to that limitation, that fails way ealier and with a somewhat

Re: [FFmpeg-devel] [PATCH] (for discussion): nvenc: fix wrong aspect ratio for 720x576 and 720x480 resolution

2017-02-12 Thread Timo Rothenpieler
On 2/12/2017 10:25 PM, Miroslav Slugeň wrote: > This patch is for discussion only, not ready to commit yet and maybe > newer will be. > > NVENC in current CUDA 8 SDK is setting wrong aspect ratio when encoding > resolution 720x576 and 720x480 and using AR 4:3 or 16:9 it will encode > to h264

Re: [FFmpeg-devel] [PATCH] (for discussion): ffmpeg_filter: initialize cuvid for filter_complex

2017-02-12 Thread Timo Rothenpieler
> I just tried your build with this cmd line: > > ffmpeg -hwaccel cuvid -c:v h264_cuvid -i simpson_1920p_h264.mp4 -y -c:v > hevc_nvenc -an -b:v 512K -qmin 5 -qmax 50 -preset slow > out_1920p_1920p_hq.mp4 > > And everything works well, do you have not working example? > > I have GTX 1060 3GB

Re: [FFmpeg-devel] [PATCH] (for discussion): cuvid: allow to crop and resize in decoder

2017-02-13 Thread Timo Rothenpieler
Am 12.02.2017 um 20:59 schrieb Hendrik Leppkes: > On Sun, Feb 12, 2017 at 8:51 PM, Miroslav Slugeň wrote: >> This patch is for discussion only, not ready to commit yet. >> >> 1. Cuvid decoder actualy support scaling input to requested resolution >> without any performance

Re: [FFmpeg-devel] [PATCH] (for discussion): ffmpeg_filter: initialize cuvid for filter_complex

2017-02-13 Thread Timo Rothenpieler
>> That's what it looks like for me: >> https://bpaste.net/show/890855410dac >> >> Happens on two independend machines, on both Windows using MSVC and >> Linux with gcc. >> Both machines are definitely nowehre near out of memory, on either >> system or device memory. >>

Re: [FFmpeg-devel] [PATCH 0/9] Merge lazy filter initialization in ffmpeg CLI

2017-02-10 Thread Timo Rothenpieler
Am 10.02.2017 um 13:35 schrieb wm4: > These patches merge the previously skipped Libav commits, which made > avconv lazily initialize libavfilter graphs. This means the filters > are initialized with the actual output format, instead of whatever > libavformat reports. > > It's a prerequisite to

Re: [FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle video resolution (v5)

2017-01-23 Thread Timo Rothenpieler
applied ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/nvenc.c Reduce initialization time for gpu id > 0

2017-01-18 Thread Timo Rothenpieler
Seems like a good idea to run the full set of capability checks only on the device that's actually about to be used. The only issue I see is that if a system has a bunch of different GPUs, of which some don't support the required capabilities, one might get unexpected results with the device

Re: [FFmpeg-devel] [PATCH] libavcodec/nvenc.c Reduce initialization time for gpu id > 0

2017-01-18 Thread Timo Rothenpieler
Made this into a patch: https://github.com/BtbN/FFmpeg/commit/cbd128a67fc4621c953419dddc5cc17612764a57 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/nvenc.c Reduce initialization time for gpu id > 0

2017-01-20 Thread Timo Rothenpieler
> Yes, this is a simpler logic. Works for me locally. Can you please apply this > patch to ffmpeg master. Thanks. Applied We also discovered a case where this patch is necessary to successfully use multiple GPUs at all. A user asked in #ffmpeg about nvenc getting stuck when one GPU is at full

Re: [FFmpeg-devel] PATCH: dshow prevent some windows 10 anniv. ed crashes

2016-08-20 Thread Timo Rothenpieler
On 8/19/2016 3:28 PM, Roger Pack wrote: > No complaints, would someone please push it for me? Sorry still > haven't figured out the key thing yet. pushed ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] Remove qmin and qmax constraints for nvenc vbr

2017-02-28 Thread Timo Rothenpieler
Am 28.02.2017 um 01:24 schrieb Ganapathy Raman Kasi: > Can someone please help review patch. Thanks. I have seen an marked it, but I don't have time to review and test stuff right now. Will get to it eventually. ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH] Remove qmin and qmax constraints for nvenc vbr

2017-02-28 Thread Timo Rothenpieler
> Patch looks good to me too. Timo, I can push it if you don't mind not > testing it yourself. I have some stilistic nits, otherwise it's ok. It leaves the fall through comment dangling, even though there is no fall through anymore. And it could use fallthrough to in the new location of

Re: [FFmpeg-devel] [PATCH] (for discussion): cuvid: allow to crop and resize in decoder

2017-03-01 Thread Timo Rothenpieler
>> We recently just had all sorts of discussions what decoders should and >> should not do, I don't think scaling in a decoder is a good thing to >> start doing here. > > scaling in some decoders is mandated by some specs > some standards support reduced resolution which can switch from frame >

[FFmpeg-devel] [PATCH] configure: convert MSVC ident to utf-8 if possible

2017-03-01 Thread Timo Rothenpieler
--- configure | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/configure b/configure index 0199fec..398d530 100755 --- a/configure +++ b/configure @@ -4095,7 +4095,11 @@ probe_cc(){ disable stripping elif $_cc -nologo- 2>&1 | grep -q Microsoft; then

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

2016-08-24 Thread Timo Rothenpieler
Am 24.08.2016 um 10:21 schrieb Oliver Collyer: >> In any case, please split the rate control patch from the 10bit patch. >> > > Just double-checking this - both changes require a bump of the minimum NVENC > version to 7. Do you still want them as separate patches or does this tie > them

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

2016-08-25 Thread Timo Rothenpieler
Am 24.08.2016 um 12:30 schrieb Oliver Collyer: > Ok thanks, Timo. > > So I’ve split this into two patches and revised as per the discussions and > they are attached here. > > The only thing to be decided is whether my conversion code to enable > YUV420P10 support should be included in this or

[FFmpeg-devel] [PATCH 2/2] swscale: add unscaled conversion from yuv420p to p010

2016-09-02 Thread Timo Rothenpieler
--- libswscale/swscale_unscaled.c| 83 tests/ref/fate/filter-pixdesc-p010le | 2 +- tests/ref/fate/filter-pixfmts-copy | 2 +- tests/ref/fate/filter-pixfmts-crop | 2 +- tests/ref/fate/filter-pixfmts-field | 2 +-

Re: [FFmpeg-devel] [PATCH] swscale: add unscaled copy from yuv420p10 to p010

2016-09-02 Thread Timo Rothenpieler
Could you please make sure to properly reply to mails in the future? Otherwise this causes quite a mess to anyone who's viewing the ML in a threaded view, which includes the list archives. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

[FFmpeg-devel] [PATCH v2 1/2] swscale: add unscaled copy from yuv420p10 to p010

2016-09-02 Thread Timo Rothenpieler
--- libswscale/swscale_unscaled.c | 44 +++ 1 file changed, 44 insertions(+) diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c index b231abe..f0b2fbf 100644 --- a/libswscale/swscale_unscaled.c +++ b/libswscale/swscale_unscaled.c @@

Re: [FFmpeg-devel] [PATCH 2/2] swscale: add unscaled conversion from yuv420p to p010

2016-09-02 Thread Timo Rothenpieler
On 9/2/2016 7:16 PM, Carl Eugen Hoyos wrote: > 2016-09-02 16:36 GMT+02:00 Timo Rothenpieler <t...@rothenpieler.org>: > >> +#if AV_HAVE_BIGENDIAN >> +static int planar8ToP010leWrapper(SwsContext *c, const uint8_t *src[], > > Why does this function not work on both

Re: [FFmpeg-devel] [PATCH] configure: check for dlsym as well

2016-09-02 Thread Timo Rothenpieler
> > LGTM completely forgot about this applied ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v3] swscale: add unscaled conversion from yuv420p to p010

2016-09-05 Thread Timo Rothenpieler
--- libswscale/swscale_unscaled.c| 57 tests/ref/fate/filter-pixdesc-p010le | 2 +- tests/ref/fate/filter-pixfmts-copy | 2 +- tests/ref/fate/filter-pixfmts-crop | 2 +- tests/ref/fate/filter-pixfmts-field | 2 +-

Re: [FFmpeg-devel] [PATCH 2/2] swscale: add unscaled conversion from yuv420p to p010

2016-09-03 Thread Timo Rothenpieler
On 9/3/2016 3:15 PM, Carl Eugen Hoyos wrote: > 2016-09-03 14:54 GMT+02:00 Timo Rothenpieler <t...@rothenpieler.org>: > >>>> +AV_WL16([2*x ], (t | (t << 8)) & 0xFFC0); >>> >>> Why is "& 0xFFC0" necessary? >&

Re: [FFmpeg-devel] [PATCH v2] swscale: add unscaled conversion from yuv420p to p010

2016-09-03 Thread Timo Rothenpieler
> @@ -236,6 +237,57 @@ static int planarToP010Wrapper(SwsContext *c, const > uint8_t *src8[], > return srcSliceH; > } > > +#if AV_HAVE_BIGENDIAN || 1 Nevermind the || 1, left over from testing speed differences and forgot to remove it. ___

[FFmpeg-devel] [PATCH v2] swscale: add unscaled conversion from yuv420p to p010

2016-09-03 Thread Timo Rothenpieler
--- libswscale/swscale_unscaled.c| 57 tests/ref/fate/filter-pixdesc-p010le | 2 +- tests/ref/fate/filter-pixfmts-copy | 2 +- tests/ref/fate/filter-pixfmts-crop | 2 +- tests/ref/fate/filter-pixfmts-field | 2 +-

Re: [FFmpeg-devel] [PATCH v3] swscale: add unscaled conversion from yuv420p to p010

2016-09-06 Thread Timo Rothenpieler
applied ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] configure: fix ldl dependency for new nvenc encoder names

2016-09-01 Thread Timo Rothenpieler
Am 31.08.2016 um 21:26 schrieb Michael Niedermayer: > On Wed, Aug 31, 2016 at 04:42:54PM +0200, Timo Rothenpieler wrote: >> --- >> configure | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/configure b/configure >> index e30

[FFmpeg-devel] [PATCH] swscale: add unscaled copy from yuv420p10 to p010

2016-09-01 Thread Timo Rothenpieler
--- libswscale/swscale_unscaled.c | 42 ++ 1 file changed, 42 insertions(+) diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c index b231abe..f47e1f4 100644 --- a/libswscale/swscale_unscaled.c +++ b/libswscale/swscale_unscaled.c @@

[FFmpeg-devel] [PATCH] configure: check for dlsym as well

2016-09-01 Thread Timo Rothenpieler
For some reason, when compiling with gcc-asan and a recent enough gcc version(seen on 5.3+ so far), linking dlopen works without -ldl, but dlsym fails with: undefined reference to symbol 'dlsym@@GLIBC_2.2.5' So this patchs checks for both dlopen and dlsym to work for determining if -ldl is

Re: [FFmpeg-devel] Performance of P010LE/BE pixel convertion

2016-09-01 Thread Timo Rothenpieler
> Hi, > > On Thu, Sep 1, 2016 at 7:00 AM, Ali KIZIL wrote: > >> Hi Oliver, >> >> I just setup my DDR3 RAM speed to 2133 Mhz on i7 4960x server. It dosnt >> make a much difference. FPS is still waiving 41-44 fps for UHD P010LE HEVC >> Main 10 encoding. >> >> Also, rawvideo

Re: [FFmpeg-devel] Performance of P010LE/BE pixel convertion

2016-09-01 Thread Timo Rothenpieler
Am 01.09.2016 um 13:44 schrieb Ronald S. Bultje: > Hi Timo, > > On Thu, Sep 1, 2016 at 7:34 AM, Timo Rothenpieler <t...@rothenpieler.org> > wrote: > >>> Hi, >>> >>> On Thu, Sep 1, 2016 at 7:00 AM, Ali KIZIL <aliki...@gmail.com> wrote: >&g

Re: [FFmpeg-devel] [PATCH] swscale: add unscaled copy from yuv420p10 to p010

2016-09-02 Thread Timo Rothenpieler
> Just sticking my head above the parapet, but shouldn’t things like... > >> +for (x = 0; x < c->srcW / 2; x++) { >> +dstUV[x*2 ] = src[1][x] << 6; >> +dstUV[x*2+1] = src[2][x] << 6; >> +} > > …be more efficiently written as... > >

Re: [FFmpeg-devel] [PATCH] swscale: add unscaled copy from yuv420p10 to p010

2016-09-02 Thread Timo Rothenpieler
Am 02.09.2016 um 11:02 schrieb Michael Niedermayer: > On Fri, Sep 02, 2016 at 10:38:39AM +0200, Timo Rothenpieler wrote: >>>> +uint16_t *src[] = { >>>> +(uint16_t*)(src8[0] + srcStride[0] * srcSliceY), >>>> +(uint16

Re: [FFmpeg-devel] [PATCH] swscale: add unscaled copy from yuv420p10 to p010

2016-09-02 Thread Timo Rothenpieler
>> +uint16_t *src[] = { >> +(uint16_t*)(src8[0] + srcStride[0] * srcSliceY), >> +(uint16_t*)(src8[1] + srcStride[1] * srcSliceY), >> +(uint16_t*)(src8[2] + srcStride[2] * srcSliceY) > > this looks odd, why is this needed ? > Without it, every dstY[x] = src[0][x] <<

Re: [FFmpeg-devel] [PATCH] swscale: add unscaled copy from yuv420p10 to p010

2016-09-02 Thread Timo Rothenpieler
>>> >>> …or is that really old-school and a modern compiler does all that when >>> optimising? >>> >>> Or is readability considered more important than marginal gains in >>> performance? >>> >>> Oliver (time travelling from the 1980s) >> >> You would still have to add the remaining stride. >>

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

2016-09-07 Thread Timo Rothenpieler
> avctx->width << 1, avctx->height); > +} else if (frame->format == AV_PIX_FMT_RGBA || frame->format == > AV_PIX_FMT_RGB0) { > + av_image_copy_plane(buf, lockBufferParams->pitch, > + frame->data[0], frame->linesize[0], > + avctx->width << 2,

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

2016-09-07 Thread Timo Rothenpieler
Am 07.09.2016 um 15:26 schrieb Sven C. Dack: > On 07/09/16 12:40, Timo Rothenpieler wrote: >> libavutil/pixfmt.h defines AV_PIX_FMT_RGB0 and the other ones like this: >> >> packed RGB 8:8:8, 32bpp, XRGBXRGB... X=unused/undefined >> >> So I would expect

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

2016-09-07 Thread Timo Rothenpieler
>> Also, why is the twist from AV_PIX_FMT_RGBA to NV_ENC_BUFFER_FORMAT_ABGR >> necessary? >> >> The nvenc header describes it as "8 bit Packed A8B8G8R8", so did they >> mess it up? > > It is necessary in order to make it work. The twist here is intentional > as I pointed out earlier. If you do it

<    1   2   3   4   5   6   7   >