>
>> Frames can be mapped from nvdec/cuvid, not needing any actual memory
>> allocation, but all other features of the hw_frames_ctx.
>> Hence the dummy-mode, which does not allocate any (notable amounts of)
>> memory but otherwise behaves the exact same.
Can someone explain the actual use-case?
>>
>> I want to add a mapped-frame/dummy mode to the CUDA frame allocator, where
>> it does everything a normal hwframes ctx does, except allocating memory,
>> because the backing memory comes mapped from the cuvid frame.
>>
>> Which is a simple flag to set, but there is no way to tell it righ
On Tue, 2018-05-08 at 00:11 +0100, Mark Thompson wrote:
> The user should only interact directly with the data length, not the
> payload size.
> ---
> libavcodec/cbs_h264_syntax_template.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/cbs_h264_syntax_t
On Mon, 2018-05-07 at 22:03 +0100, Mark Thompson wrote:
> On 04/05/18 09:54, Xiang, Haihao wrote:
> > On Thu, 2018-05-03 at 22:43 +0100, Mark Thompson wrote:
> > > On 03/05/18 04:07, Haihao Xiang wrote:
> > > > '-sei xxx' is added to control SEI insertion, so far only mastering
> > > > display colo
On Mon, 2018-05-07 at 21:48 +0100, Mark Thompson wrote:
> On 04/05/18 15:41, Haihao Xiang wrote:
> > The structure has reserved bytes, it is required to set the reserved
> > bytes to 0 for future use.
> >
> > Signed-off-by: Haihao Xiang
> > ---
> > libavcodec/vaapi_encode_vp8.c | 2 ++
> > 1 fil
On Mon, 2018-05-07 at 21:48 +0100, Mark Thompson wrote:
> On 04/05/18 15:41, Haihao Xiang wrote:
> > Otherwise va_rt_format might be unitialized
> >
> > Signed-off-by: Haihao Xiang
> > ---
> > libavutil/hwcontext_vaapi.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/libavu
2018-05-08 5:10 GMT+08:00 Timo Rothenpieler :
> Frames can be mapped from nvdec/cuvid, not needing any actual memory
> allocation, but all other features of the hw_frames_ctx.
> Hence the dummy-mode, which does not allocate any (notable amounts of)
> memory but otherwise behaves the exact same.
>
On Mon, 2018-05-07 at 21:46 +0100, Mark Thompson wrote:
> On 04/05/18 15:41, Haihao Xiang wrote:
> > Otherwise it might use unitialized last_pic in av_assert0(last_pic)
> >
> > Signed-off-by: Haihao Xiang
> > ---
> > libavcodec/vaapi_encode.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletio
On Mon, May 07, 2018 at 07:24:16PM +0200, Clément Bœsch wrote:
> ssd_integral_image_c: 49204.6
> ssd_integral_image_neon: 28346.8
> ---
> libavfilter/aarch64/Makefile | 3 +
> libavfilter/aarch64/vf_nlmeans_init.c | 33 +++
> libavfilter/aarch64/vf_nlmeans_neon.S | 80 +++
On 08/05/18 01:06, James Almer wrote:
> On 5/7/2018 8:11 PM, Mark Thompson wrote:
>> The artificial sample file sei-1.h264 contains five frames (IDR P B I B)
>> and the following SEI message types:
>> * Buffering period
>> * Picture timing
>> * Pan-scan rectangle (display as 4:3)
>> * User data reg
On 5/7/2018 8:11 PM, Mark Thompson wrote:
> The artificial sample file sei-1.h264 contains five frames (IDR P B I B)
> and the following SEI message types:
> * Buffering period
> * Picture timing
> * Pan-scan rectangle (display as 4:3)
> * User data registered, containing A/53 closed captions (capt
On 5/7/2018 8:11 PM, Mark Thompson wrote:
> ---
> libavcodec/cbs_h264.h | 10 ++
> libavcodec/cbs_h2645.c| 1 +
> libavcodec/cbs_h264_syntax_template.c | 23 +++
> libavcodec/h264_sei.h | 1 +
> 4 files changed, 35 inser
On Mon, May 7, 2018 at 3:18 PM, Michael Niedermayer
wrote:
> On Mon, Apr 23, 2018 at 11:03:57AM -0700, Jacob Trimble wrote:
>> While integrating my encryption info changes, I noticed a problem with
>> the init info structs. I implemented them as side-data on the Stream.
>> But this means there ca
On 5/7/2018 8:05 PM, Hendrik Leppkes wrote:
> On Sun, May 6, 2018 at 10:27 PM, James Almer wrote:
>> On 5/5/2018 5:38 PM, James Almer wrote:
>>> On 4/10/2018 2:16 PM, Sergey Lavrushkin wrote:
diff --git a/libavfilter/vf_srcnn.c b/libavfilter/vf_srcnn.c
new file mode 100644
index 000
On Mon, May 7, 2018 at 4:07 PM, Marton Balint wrote:
>
>
> On Mon, 7 May 2018, Aman Gupta wrote:
>
>
>>
>> On Mon, May 7, 2018 at 12:50 PM, Aman Gupta wrote:
>>
>>
>> On Sun, May 6, 2018 at 2:05 PM, Marton Balint
>> wrote:
>> Inspired by the VideoLAN text decoder and its port
On 07/05/18 22:28, Timo Rothenpieler wrote:
> Am 07.05.2018 um 23:22 schrieb Mark Thompson:
>> On 07/05/18 22:10, Timo Rothenpieler wrote:
>>> Frames can be mapped from nvdec/cuvid, not needing any actual memory
>>> allocation, but all other features of the hw_frames_ctx.
>>> Hence the dummy-mode,
On Sun, May 6, 2018 at 10:27 PM, James Almer wrote:
> On 5/5/2018 5:38 PM, James Almer wrote:
>> On 4/10/2018 2:16 PM, Sergey Lavrushkin wrote:
>>> diff --git a/libavfilter/vf_srcnn.c b/libavfilter/vf_srcnn.c
>>> new file mode 100644
>>> index 00..d9b4891f7f
>>> --- /dev/null
>>> +++ b/lib
The artificial sample file sei-1.h264 contains five frames (IDR P B I B)
and the following SEI message types:
* Buffering period
* Picture timing
* Pan-scan rectangle (display as 4:3)
* User data registered, containing A/53 closed captions (captions match
frame content, including reordering)
* Re
---
libavcodec/cbs_h264.h | 10 ++
libavcodec/cbs_h2645.c| 1 +
libavcodec/cbs_h264_syntax_template.c | 23 +++
libavcodec/h264_sei.h | 1 +
4 files changed, 35 insertions(+)
diff --git a/libavcodec/cbs_h264.h b/libavco
---
No immediate use for this or the following patch, but they were helpful for SEI
testing.
libavcodec/cbs_h264.h | 12
libavcodec/cbs_h2645.c| 1 +
libavcodec/cbs_h264_syntax_template.c | 28
libavcodec/h264_sei.h
The aud structure exists on the stack, so the variable was previously
out-of-scope when the unit is written.
---
Something of a "how did this ever work", though apparently no compiler barfs on
it until I was add more stuff after.
libavcodec/h264_metadata_bsf.c | 9 +
1 file changed, 5 i
This should be derived from the data length rather than set explicitly.
---
libavcodec/h264_metadata_bsf.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index 27053dbdcf..1fbc5e3282 100644
--- a/libavcodec/h264_metadata_bsf.c
+
The user should only interact directly with the data length, not the
payload size.
---
libavcodec/cbs_h264_syntax_template.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/cbs_h264_syntax_template.c
b/libavcodec/cbs_h264_syntax_template.c
index 3ec4299915..b
On Mon, 7 May 2018, Aman Gupta wrote:
On Mon, May 7, 2018 at 12:50 PM, Aman Gupta wrote:
On Sun, May 6, 2018 at 2:05 PM, Marton Balint wrote:
Inspired by the VideoLAN text decoder and its port to FFmpeg made
by Aman
Gupta.
Thanks for incorporating my chan
On 6 May 2018 at 23:19, Rostislav Pehlivanov wrote:
> Saves 1 gpr and 2 instructions and simplifies the macros a bit.
>
> Signed-off-by: Rostislav Pehlivanov
> ---
> libavcodec/x86/mdct15.asm | 37 +
> 1 file changed, 17 insertions(+), 20 deletions(-)
>
> dif
This should make sure detection only succeeds on systems where we expect
it will be used.
Signed-off-by: James Almer
---
The current access() test succeeds on systems lacking unistd.h, like msvc.
This results in the scrnn_filter being enabled but ultimately failing to
compile, as POSIX constants
On Mon, Apr 23, 2018 at 11:03:57AM -0700, Jacob Trimble wrote:
> While integrating my encryption info changes, I noticed a problem with
> the init info structs. I implemented them as side-data on the Stream.
> But this means there can only be one per stream. However, there can
> be multiple 'pssh
Am 07.05.2018 um 19:37 schrieb Oscar Amoros Huguet:
I was looking at the NVIDIA Video codec sdk samples
(https://developer.nvidia.com/nvidia-video-codec-sdk#Download), where you can
find the header NvDecoder.h next to cuviddec.h where CUVIDPROCPARAMS is defined.
Anyway, I should have looked at
Frames can be mapped from nvdec/cuvid, not needing any actual memory
allocation, but all other features of the hw_frames_ctx.
Hence the dummy-mode, which does not allocate any (notable amounts of)
memory but otherwise behaves the exact same.
---
doc/APIchanges | 3 +++
libavutil/hwcon
Am 07.05.2018 um 23:22 schrieb Mark Thompson:
On 07/05/18 22:10, Timo Rothenpieler wrote:
Frames can be mapped from nvdec/cuvid, not needing any actual memory
allocation, but all other features of the hw_frames_ctx.
Hence the dummy-mode, which does not allocate any (notable amounts of)
memory bu
On 07/05/18 22:10, Timo Rothenpieler wrote:
> Frames can be mapped from nvdec/cuvid, not needing any actual memory
> allocation, but all other features of the hw_frames_ctx.
> Hence the dummy-mode, which does not allocate any (notable amounts of)
> memory but otherwise behaves the exact same.
> ---
Frames can be mapped from nvdec/cuvid, not needing any actual memory
allocation, but all other features of the hw_frames_ctx.
Hence the dummy-mode, which does not allocate any (notable amounts of)
memory but otherwise behaves the exact same.
---
doc/APIchanges | 3 +++
libavutil/hwcon
On 07/05/18 21:52, Timo Rothenpieler wrote:
>> Nack. Implementation-specific details go in the implementation-specific
>> structure (AVHWFramesContext.hwctx).
>>
>> What are you actually thining of using this for? If you want to add flags
>> which are in common between multiple different implem
On 04/05/18 09:54, Xiang, Haihao wrote:
> On Thu, 2018-05-03 at 22:43 +0100, Mark Thompson wrote:
>> On 03/05/18 04:07, Haihao Xiang wrote:
>>> '-sei xxx' is added to control SEI insertion, so far only mastering
>>> display colour colume is available for testing.
>>
>> Typo: "colume" (also in the c
On 04/05/18 15:41, Haihao Xiang wrote:
> Otherwise it might use unitialized last_pic in av_assert0(last_pic)
>
> Signed-off-by: Haihao Xiang
> ---
> libavcodec/vaapi_encode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_en
Nack. Implementation-specific details go in the implementation-specific
structure (AVHWFramesContext.hwctx).
What are you actually thining of using this for? If you want to add flags
which are in common between multiple different implementations then maybe it
would be suitable to put it here
On 04/05/18 15:41, Haihao Xiang wrote:
> The structure has reserved bytes, it is required to set the reserved
> bytes to 0 for future use.
>
> Signed-off-by: Haihao Xiang
> ---
> libavcodec/vaapi_encode_vp8.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/vaapi_encode_vp8
On 04/05/18 05:03, Xiang, Haihao wrote:
> On Thu, 2018-05-03 at 22:32 +0100, Mark Thompson wrote:
>> On 03/05/18 04:07, Haihao Xiang wrote:
>>> Similar to H264, cbs_h265_{read, write}_nal_unit() can handle HEVC
>>> prefix SEI NAL units. Currently mastering display colour volume SEI
>>> message is a
On 04/05/18 15:41, Haihao Xiang wrote:
> Otherwise va_rt_format might be unitialized
>
> Signed-off-by: Haihao Xiang
> ---
> libavutil/hwcontext_vaapi.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 7daaa951cc..e5
On 07/05/18 19: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
> --- a
On Mon, May 7, 2018 at 12:50 PM, Aman Gupta wrote:
>
>
> On Sun, May 6, 2018 at 2:05 PM, Marton Balint wrote:
>
>> Inspired by the VideoLAN text decoder and its port to FFmpeg made by Aman
>> Gupta.
>>
>
> Thanks for incorporating my changes.
>
> I ran some tests, and colors work as expected. Po
On Sun, May 6, 2018 at 2:05 PM, Marton Balint wrote:
> Inspired by the VideoLAN text decoder and its port to FFmpeg made by Aman
> Gupta.
>
Thanks for incorporating my changes.
I ran some tests, and colors work as expected. Positioning also works well,
and is also pretty close to my version.
On Wed, May 2, 2018 at 7:59 AM, Ronak Patel <
ronak2121-at-yahoo@ffmpeg.org> wrote:
> Hi all,
>
> So I’ve noticed that ffmpeg does not always properly follow the number we
> specify for hls_time when generating hls content.
>
> For example, if we have an MP4/AAC file at 44.1kHz sampling rate,
On Sun, May 6, 2018 at 2:05 PM, Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> doc/decoders.texi| 5 +++--
> libavcodec/libzvbi-teletextdec.c | 31 ++-
> 2 files changed, 25 insertions(+), 11 deletions(-)
>
> diff --git a/doc/decoders.te
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
--- a/doc/APIchange
---
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
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavut
2018-05-07 17:41 GMT+03:00 Pedro Arthur :
> 2018-05-07 0:30 GMT-03:00 Steven Liu :
> > Hi Sergey,
> >
> > How should i test this filter?
> > I tested it some days ago, the picture get worse from 2nd frame.
> > input resolution 640x480 to 1280x720;
> >
> > ffmpeg -i
Thanks for the tip on the push/pop solution (custom version of the ffnvcodec
headers). It works for us, we may do as you say.
Thanks again.
Oscar
-Original Message-
From: ffmpeg-devel On Behalf Of Timo
Rothenpieler
Sent: Monday, May 7, 2018 1:25 PM
To: ffmpeg-devel@ffmpeg.org
Subject:
Hi!
Even if there is need to have a syncronization before leaving the ffmpeg call,
callin cuMemcpyAsync will allow the copies to overlap with any other task on
the gpu, that was enqueued using any other non-blocking cuda stream. That’s
exactly what we want to achieve.
This would benefit automa
I was looking at the NVIDIA Video codec sdk samples
(https://developer.nvidia.com/nvidia-video-codec-sdk#Download), where you can
find the header NvDecoder.h next to cuviddec.h where CUVIDPROCPARAMS is defined.
Anyway, I should have looked at ffmpeg code directly, to see what’s being used,
sorr
On 5/7/18, Clement Boesch wrote:
> Changes since v1:
>
> - fixed float operation in double as pointed out by Moritz
> - fix broken commit split as pointed out by Michael
> - added patch 10: "use unsigned for the integral patch"
> - misc instruction shuffling in AArch64 SIMD for better performances
Overall speed appears to be 1.1x faster with no noticeable quality
impact.
---
libavfilter/vf_nlmeans.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavfilter/vf_nlmeans.c b/libavfilter/vf_nlmeans.c
index f37f1183f7..aba587f46b 100644
--- a/libavfilter/vf_nl
This value can not be negative.
---
libavfilter/vf_nlmeans.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavfilter/vf_nlmeans.c b/libavfilter/vf_nlmeans.c
index 22d26a12e3..547cb80acd 100644
--- a/libavfilter/vf_nlmeans.c
+++ b/libavfilter/vf_nlmeans.c
@@
This helps figuring out where the filter is slow:
70.53% ffmpeg_g ffmpeg_g [.] nlmeans_slice
25.73% ffmpeg_g ffmpeg_g [.] compute_safe_ssd_integral_image_c
1.74% ffmpeg_g ffmpeg_g [.] compute_unsafe_ssd_integral_image
0.82% ffmpeg_g ffmpeg_g [.
This doesn't seem to make much of a difference but it can't hurt.
---
libavfilter/vf_nlmeans.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_nlmeans.c b/libavfilter/vf_nlmeans.c
index 72a75a6e7a..22d26a12e3 100644
--- a/libavfilter/vf_nlmeans.c
+++ b/liba
before: ssd_integral_image_c: 49204.6
after: ssd_integral_image_c: 44272.8
Unrolling by 4 for made the biggest different on odroid-c2 (aarch64);
unrolling by 2 or 8 both raised 46k cycles vs 44k for 4.
Additionally, this is a much better reference when writing SIMD (SIMD
vectorization will jus
---
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c | 3 +
tests/checkasm/checkasm.h | 1 +
tests/checkasm/vf_nlmeans.c | 113
4 files changed, 118 insertions(+)
create mode 100644 tests/checkasm/vf_nlmeans.c
diff --git a/tests/checkasm
SIMD code will not have to deal with padding itself. Overwriting in that
function may have been possible but involve large overreading of the
sources. Instead, we simply make sure the width to process is always a
multiple of 16. Additionally, there must be some actual area to process
so the SIMD co
ssd_integral_image_c: 49204.6
ssd_integral_image_neon: 28346.8
---
libavfilter/aarch64/Makefile | 3 +
libavfilter/aarch64/vf_nlmeans_init.c | 33 +++
libavfilter/aarch64/vf_nlmeans_neon.S | 80 +++
libavfilter/vf_nlmeans.c | 26 ++---
lib
Similarly to previous commit, this will help writing SIMD code by not
having manual zero-extension in SIMD code
---
libavfilter/vf_nlmeans.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/libavfilter/vf_nlmeans.c b/libavfilter/vf_nlmeans.c
index 3f
This makes nlmeans_slice() slightly faster at least on GCC 7.3.
---
libavfilter/vf_nlmeans.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_nlmeans.c b/libavfilter/vf_nlmeans.c
index e4952e187e..d222d3913e 100644
--- a/libavfilter/vf_nlmeans.c
+++ b/liba
Changes since v1:
- fixed float operation in double as pointed out by Moritz
- fix broken commit split as pointed out by Michael
- added patch 10: "use unsigned for the integral patch"
- misc instruction shuffling in AArch64 SIMD for better performances
I plan to push this soon unless someone wan
On 5/6/2018 10:23 AM, Gyan Doshi wrote:
On 5/6/2018 4:39 AM, James Almer wrote:
On 5/5/2018 8:06 PM, Michael Niedermayer wrote:
On Sat, May 05, 2018 at 05:16:09PM +0530, Gyan Doshi wrote:
Since the muxer author hasn't made the change, the patch is submitted.
Reference:
http://www.ffmpeg.
Am 07.05.2018 um 18:25 schrieb Oscar Amoros Huguet:
Have a look at this, looks pretty interesting:
/**
* @brief This function decodes a frame and returns the locked frame
buffers
* This makes the buffers available for use by the application without
the buffers
* getting o
On Fri, Apr 27, 2018 at 5:30 PM, Jacob Trimble wrote:
> On Fri, Apr 27, 2018 at 10:33 AM, Jacob Trimble wrote:
>> On Mon, Apr 23, 2018 at 11:03 AM, Jacob Trimble wrote:
>>> While integrating my encryption info changes, I noticed a problem with
>>> the init info structs. I implemented them as si
2018-05-07 12:38 GMT+02:00, Michael Niedermayer :
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index c0db10b3c2..00dfce977b 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -691,7 +691,7 @@ static void mxf_write_preface(AVFormatContext *s)
>
> // write ver
2018-05-05 2:26 GMT+02:00, Carl Eugen Hoyos :
> Attached patch fixes ticket #6195 for me.
I'll push this if there are no comments.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Have a look at this, looks pretty interesting:
/**
* @brief This function decodes a frame and returns the locked frame
buffers
* This makes the buffers available for use by the application without the
buffers
* getting overwritten, even if subsequent decode calls are made. The
Removing the need for the memcpy itself would clearly be the best.
Looking at NSIGHT, I see that NVDEC internally calls a color space
transformation kernel on the default stream, and does not synchronize with the
calling CPU thread. The cuMemcpy calls you have right now, use the same default
st
On Sun, May 06, 2018 at 04:53:54PM +0200, Moritz Barsnick wrote:
> On Sun, May 06, 2018 at 13:40:58 +0200, Clément Bœsch wrote:
> > Overall speed appears to be 1.1x faster with no noticeable quality impact.
>
> Probably platform dependant?
>
> > struct weighted_avg {
> > -double total_weight
On Mon, May 07, 2018 at 12:14:37AM +0200, Michael Niedermayer wrote:
> On Sun, May 06, 2018 at 01:40:53PM +0200, Clément Bœsch wrote:
> > SIMD code will not have to deal with padding itself. Overwriting in that
> > function may have been possible but involve large overreading of the
> > sources. In
From 8082ba451d089790f0719c4ec6788796b2079e9d Mon Sep 17 00:00:00 2001
From: Reino17
Date: Mon, 7 May 2018 17:28:10 +0200
Subject: [PATCH] configure: add pkg-config check for libmysofa
This does require libmysofa with today's latest commit
(https://github.com/hoene/libmysofa/commit/08f243d1ec35f
Am 07.05.2018 um 17:05 schrieb Oscar Amoros Huguet:
To clarify a bit what I was saying in the last email. When I said CUDA
non-blocking streams, I meant non-default streams. All non-blocking streams are
non-default streams, but non-default streams can be blocking or non-bloking
with respect to
To clarify a bit what I was saying in the last email. When I said CUDA
non-blocking streams, I meant non-default streams. All non-blocking streams are
non-default streams, but non-default streams can be blocking or non-bloking
with respect to the default streams.
https://docs.nvidia.com/cuda/cu
2018-05-07 0:30 GMT-03:00 Steven Liu :
> Hi Sergey,
>
> How should i test this filter?
> I tested it some days ago, the picture get worse from 2nd frame.
> input resolution 640x480 to 1280x720;
>
> ffmpeg -i input -vf srcnn output
Hi,
The filter expects the input ups
On 5/7/2018 10:59 AM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/vf_fftdnoiz.c | 393
> ++
> 3 files changed, 395 insertions(+)
> create mode 100644 l
Signed-off-by: Paul B Mahol
---
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_fftdnoiz.c | 393 ++
3 files changed, 395 insertions(+)
create mode 100644 libavfilter/vf_fftdnoiz.c
diff --git a/libavfilter/Makefile
From: Vishwanath Dixit
HMS is formatted as HH:MM:SS.mmm, but, HH part is not limited to
24 hours. For example, the the drawn text may look like this:
243029:20:30.342. To present the timestamp in more readable and
user friendly format, this patch provides an additional option
to limit the hour pa
>> Additionally, could you give your opinion on the feature we also may
want to add in the future, that we mentioned in the previous email?
Basically, we may want to add one more CUDA function, specifically
cuMemcpy2DAsync, and the possibility to set a CUStream in
AVCUDADeviceContext, so it is used
On 26.04.2018 18:03, Oscar Amoros Huguet wrote:
> Thanks Mark,
>
> You are right, we can implement in our code a sort of "av_hwdevice_ctx_set"
> (which does not exist), by using av_hwdevice_ctx_alloc() +
> av_hwdevice_ctx_init(). We actually use av_hwdevice_ctx_alloc in our code to
> use the fe
Signed-off-by: Michael Niedermayer
---
libavformat/mxfenc.c| 1 +
tests/ref/fate/copy-trac4914| 4 ++--
tests/ref/fate/mxf-reel_name| 2 +-
tests/ref/fate/time_base| 2 +-
tests/ref/lavf/mxf | 12 ++--
tests/ref/lavf/mxf_d10 | 4 ++--
Signed-off-by: Michael Niedermayer
---
libavformat/mxfenc.c| 7 ++-
tests/ref/fate/copy-trac4914| 2 +-
tests/ref/fate/mxf-reel_name| 2 +-
tests/ref/fate/time_base| 2 +-
tests/ref/lavf/mxf | 6 +++---
tests/ref/lavf/mxf_d10 | 2 +-
tests/ref
Signed-off-by: Michael Niedermayer
---
libavformat/mxfenc.c| 39 +
tests/ref/fate/copy-trac4914| 2 +-
tests/ref/fate/mxf-reel_name| 2 +-
tests/ref/fate/time_base| 2 +-
tests/ref/lavf/mxf | 6 ++---
tests/ref/lavf/mxf_
Signed-off-by: Michael Niedermayer
---
libavformat/mxfenc.c| 18 ++
tests/ref/fate/copy-trac4914| 2 +-
tests/ref/fate/mxf-reel_name| 2 +-
tests/ref/fate/time_base| 2 +-
tests/ref/lavf/mxf | 6 +++---
tests/ref/lavf/mxf_d10 |
Signed-off-by: Michael Niedermayer
---
libavformat/mxfenc.c| 7 ++-
tests/ref/fate/copy-trac4914| 2 +-
tests/ref/fate/mxf-reel_name| 2 +-
tests/ref/fate/time_base| 2 +-
tests/ref/lavf/mxf | 6 +++---
tests/ref/lavf/mxf_d10 | 2 +-
tests/ref
Signed-off-by: Michael Niedermayer
---
libavformat/mxfenc.c| 8
tests/ref/fate/copy-trac4914| 2 +-
tests/ref/fate/mxf-reel_name| 2 +-
tests/ref/fate/time_base| 2 +-
tests/ref/lavf/mxf | 6 +++---
tests/ref/lavf/mxf_d10 | 2 +-
tests/re
This fixes the width to have computations matching the height
Signed-off-by: Michael Niedermayer
---
libavformat/mxfenc.c | 3 +-
.../ref/fate/concat-demuxer-extended-lavf-mxf | 2 +-
.../fate/concat-demuxer-extended-lavf-mxf_d10 | 2 +-
.../ref/fate/concat-demuxer
Signed-off-by: Michael Niedermayer
---
libavformat/mxfenc.c| 39 +++--
tests/ref/fate/copy-trac4914| 4 ++--
tests/ref/fate/mxf-reel_name| 2 +-
tests/ref/fate/time_base| 2 +-
tests/ref/lavf/mxf | 12 +-
tests/ref/la
Signed-off-by: Michael Niedermayer
---
libavformat/mxfenc.c| 28 +++-
tests/ref/fate/copy-trac4914| 2 +-
tests/ref/fate/mxf-reel_name| 2 +-
tests/ref/fate/time_base| 2 +-
tests/ref/lavf/mxf | 6 +++---
tests/ref/lavf/mxf_d10
Signed-off-by: Michael Niedermayer
---
libavformat/mxfenc.c| 11 +++
tests/ref/fate/copy-trac4914| 2 +-
tests/ref/fate/mxf-reel_name| 2 +-
tests/ref/fate/time_base| 2 +-
tests/ref/lavf/mxf | 6 +++---
tests/ref/lavf/mxf_d10 | 2 +-
Signed-off-by: Michael Niedermayer
---
libavformat/mxfenc.c| 22 ++
tests/ref/fate/copy-trac4914| 2 +-
tests/ref/fate/mxf-reel_name| 2 +-
tests/ref/fate/time_base| 2 +-
tests/ref/lavf/mxf | 6 +++---
tests/ref/lavf/mxf_d10
Signed-off-by: Michael Niedermayer
---
libavformat/mxfenc.c| 4 ++--
tests/ref/fate/copy-trac4914| 2 +-
tests/ref/fate/mxf-reel_name| 2 +-
tests/ref/fate/time_base| 2 +-
tests/ref/lavf/mxf | 6 +++---
tests/ref/lavf/mxf_d10 | 2 +-
tests/ref/la
Signed-off-by: Michael Niedermayer
---
libavformat/mxfenc.c | 1 +
.../ref/fate/concat-demuxer-extended-lavf-mxf | 2 +-
.../fate/concat-demuxer-extended-lavf-mxf_d10 | 2 +-
.../ref/fate/concat-demuxer-simple1-lavf-mxf | 242 +-
.../fate/concat-dem
On 5/7/18 1:59 AM, Michael Niedermayer wrote:
> On Sun, May 06, 2018 at 06:04:35PM +, Dixit, Vishwanath wrote:
>>
>>
>> On 4/28/18 6:38 AM, Michael Niedermayer wrote:
>>> On Fri, Apr 27, 2018 at 08:00:23AM +, Dixit, Vishwanath wrote:
On 4/27/18 5:15 AM, Michael Niedermayer w
From: Vishwanath Dixit
This utility function creates 64-bit NTP time format as per the RFC
5905.
A simple explaination of 64-bit NTP time format is here
http://www.beaglesoft.com/Manual/page53.htm
---
libavformat/internal.h | 8
libavformat/utils.c| 22 ++
2 fil
From: Vishwanath Dixit
---
doc/muxers.texi | 4
libavformat/dashenc.c | 7 +++
2 files changed, 11 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index db81901..e9082a4 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -282,6 +282,10 @@ corrects that index value
From: Vishwanath Dixit
The producer reference time box supplies relative wall-clock times
at which movie fragments, or files containing movie fragments
(such as segments) were produced.
The box is mainly useful in live streaming use cases. A media player
can parse the box and utilize the time fie
On Sun, May 06, 2018 at 11:12:12PM +0800, Jun Zhao wrote:
> Signed-off-by: Jun Zhao
> ---
> libavformat/network.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/network.h b/libavformat/network.h
> index e3fda4d..efaa789 100644
> --- a/libavformat/net
On Sun, May 06, 2018 at 01:40:52PM +0200, Clément Bœsch wrote:
> This makes nlmeans_slice() slightly faster at least on GCC 7.3.
> ---
> libavfilter/vf_nlmeans.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730B
sön 2018-05-06 klockan 21:31 +0200 skrev Thomas Mundt:
> 2018-05-06 13:32 GMT+02:00 Tomas Härdin :
>
> > fre 2018-05-04 klockan 01:52 +0200 skrev Thomas Mundt:
> > > Hi,
> > >
> > > this is a better version of the patch.
> > > 10 bit and TFF are mandatory for AVC Intra only. Other profiles
> > >
100 matches
Mail list logo
