2017-02-14 15:02 GMT+08:00 su.gao :
> Add this option to force the box width equl text width:
>
> diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
> index 0b94725..5b16cfa 100644
> --- a/libavfilter/vf_drawtext.c
> +++ b/libavfilter/vf_drawtext.c
> @@ -164,6 +164,7 @@ typedef st
Add this option to force the box width equl text width:
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index 0b94725..5b16cfa 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -164,6 +164,7 @@ typedef struct DrawTextContext {
int use_kerning;
On 13 February 2017 at 19:42, Rostislav Pehlivanov
wrote:
>
>
> On 11 February 2017 at 00:25, Rostislav Pehlivanov
> wrote:
>
>> This series of commits implements a native Opus encoder.
>>
>> This is v2 of the patchset, the changes are:
>> - The forward MDCT doesn't need a third buffer and c
On Mon, 13 Feb 2017 18:04:10 -0800
Aman Gupta wrote:
> From: Aman Gupta
>
> The videotoolbox hwaccel returns a dummy frame with a 1-byte buffer from
> alloc_frame(). In end_frame(), this buffer is replaced with the actual
> decoded data from VTDecompressionSessionDecodeFrame(). This is hacky,
>
On Mon, 13 Feb 2017 18:51:39 +0100
u-9...@aetey.se wrote:
> Then abstracting a "mini-swscale" could become justifiable.
And this is why we should probably reject this patch. What you wrote
paints a horrifying future.
Note that we would have this discussion even if it'd speed up the h264
decoder.
On Mon, Feb 13, 2017 at 11:00 PM, Timo Rothenpieler
wrote:
>> 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 tri
libavformat/utils.c,line 3308:
if (ic->flags & AVFMT_FLAG_NOBUFFER)
> free_packet_buffer(&ic->internal->packet_buffer,
>&ic->internal->packet_buffer_end);
> {
> pkt = add_to_pktbuf(&ic->internal->packet_buffer, &pkt1,
> &ic->internal->packet_
2017-02-13 21:15 GMT+08:00 Miroslav Slugeň :
> This patch will fix cutting hls segments into exactly same length. Because
> it will intialize only on first ref_packet, which is video frame, not audio
> frame (old behavior)
>
> Now it should be possible to create segments at exactly same length if
I found that the box_length is shorter than the text_length, and there is no
option to adapt（Equal）.
So I suggest ffmpeg.org can add a opption(like boxw_equal_textw) to adapt it !
the old source:
box_w = FFMIN(width - 1 , max_text_line_w);
box_h = FFMIN(height - 1, y + s->max_glyph_h)
On Tue, Feb 14, 2017 at 09:39:08AM +0800, Steven Liu wrote:
> 2017-02-13 20:46 GMT+08:00 Michael Niedermayer :
>
> > Reported-by: SleepProgger
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/http.c | 11 ++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff
From: Aman Gupta
The videotoolbox hwaccel returns a dummy frame with a 1-byte buffer from
alloc_frame(). In end_frame(), this buffer is replaced with the actual
decoded data from VTDecompressionSessionDecodeFrame(). This is hacky,
but works well enough, as long as the VT decoder returns a valid f
2017-02-13 20:46 GMT+08:00 Michael Niedermayer :
> Reported-by: SleepProgger
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/http.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/http.c b/libavformat/http.c
> index 944a6cf322..bd1be3f7b
Dne 13.2.2017 v 23:00 Timo Rothenpieler napsal(a):
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
> 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
Dne 13.2.2017 v 11:18 Timo Rothenpieler napsal(a):
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
On 11 February 2017 at 00:25, Rostislav Pehlivanov
wrote:
> This series of commits implements a native Opus encoder.
>
> This is v2 of the patchset, the changes are:
> - The forward MDCT doesn't need a third buffer and can handle
> the full set of sizes the init function allows
> -
On Mon, Feb 13, 2017 at 02:23:47PM +0100, Paul B Mahol wrote:
> >> @@ -488,4 +1026,6 @@ AVCodec ff_cinepak_decoder = {
> >> .close = cinepak_decode_end,
> >> .decode = cinepak_decode_frame,
> >> .capabilities = AV_CODEC_CAP_DR1,
> >> +.pix_fmts = pixfmt_l
On 2017-02-13 08:33, Miroslav Slugeň wrote:
I am sure that i know what is going on, NVENC is inserting wrong SPS
VUI aspect_ratio_idc to h264 packets when you encode at resolution
720x576 and 720x480
AR 16:9 will insert aspect_ratio_idc=4 but it should be
aspect_ratio_idc=255, sar_width=64, sar_
Dne 13.2.2017 v 17:07 Philip Langdale napsal(a):
On Mon, 13 Feb 2017 07:21:51 -0800
Philip Langdale wrote:
On Mon, 13 Feb 2017 08:52:34 +0100
Miroslav Slugeň wrote:
I am using current STABLE drivers 375.26, because BETA drivers
378.09 caused some crashes while encoding on NVENC.
I tes
On Mon, 13 Feb 2017 07:21:51 -0800
Philip Langdale wrote:
> On Mon, 13 Feb 2017 08:52:34 +0100
> Miroslav Slugeň wrote:
>
> > >
> > I am using current STABLE drivers 375.26, because BETA drivers
> > 378.09 caused some crashes while encoding on NVENC.
> >
> > I tested this on BETA drivers t
Friendly ping! Any issues receiving this updated patch (submitted with git
send-email)? Anyone try it out yet?
Thanks,
Joel
> On Jan 30, 2017, at 10:00 AM, Joel Cunningham wrote:
>
> This commit optimizes HTTP performance by reducing forward seeks, instead
> favoring a read-ahead and disca
On Mon, 13 Feb 2017 08:52:34 +0100
Miroslav Slugeň wrote:
> Dne 12.2.2017 v 23:20 Philip Langdale napsal(a):
> > On Sun, 12 Feb 2017 22:43:41 +0100
> > Miroslav Slugeň wrote:
> >
> >> Dne 12.2.2017 v 22:31 Timo Rothenpieler napsal(a):
> >>> On 2/12/2017 10:25 PM, Miroslav Slugeň wrote:
> >
Thanks Michael,
Your corrections are appreciated.
On Mon, Feb 13, 2017 at 02:19:45PM +0100, Michael Niedermayer wrote:
> you may want to add yourself to MAINTAINERs (after talking with
> roberto, who i belive has less interrest in cinepak than you do
> nowadays)
Sounds ok for me. Roberto, what d
- This patch contains the changes to interface the Turing codec
(http://turingcodec.org/) with ffmpeg. The patch was modified to address the
comments in the review as follows:
- Added a pkg-config file to list all dependencies required by libturing.
This should address the issue pointed out by
On 2/13/17, Michael Niedermayer wrote:
> On Sat, Feb 11, 2017 at 10:25:03PM +0100, u-9...@aetey.se wrote:
>> Hello,
>>
>> This is my best effort attempt to make the patch acceptable
>> by the upstream's criteria.
>>
>> Daniel, do you mind that I referred to your message in the commit?
>> I believe
On Sat, Feb 11, 2017 at 10:25:03PM +0100, u-9...@aetey.se wrote:
> Hello,
>
> This is my best effort attempt to make the patch acceptable
> by the upstream's criteria.
>
> Daniel, do you mind that I referred to your message in the commit?
> I believe is is best to indicate numbers from a third pa
This patch will fix cutting hls segments into exactly same length.
Because it will intialize only on first ref_packet, which is video
frame, not audio frame (old behavior)
Now it should be possible to create segments at exactly same length if
we use new -force_key_frames hls:time_in_seconds pa
On Mon, Feb 13, 2017 at 12:43:51PM +0100, Hendrik Leppkes wrote:
> On Mon, Feb 13, 2017 at 11:36 AM, Timo Rothenpieler
> wrote:
> > 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
On Mon, Feb 13, 2017 at 08:56:19AM +0100, Miroslav Slugeň wrote:
> Dne 12.2.2017 v 23:35 Michael Niedermayer napsal(a):
> >On Sun, Feb 12, 2017 at 07:31:43PM +0100, Miroslav Slugeň wrote:
> >>This patch will fix cutting hls segments into exactly same length.
> >>Because it will intialize only on fi
Originally committed to x264 in 1637239a by Henrik Gramner who has
agreed to re-license it as LGPL. Original commit message follows.
x86: Avoid some bypass delays and false dependencies
A bypass delay of 1-3 clock cycles may occur on some CPUs when transitioning
between int and float
---
libavcodec/x86/h264_deblock.asm | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/libavcodec/x86/h264_deblock.asm b/libavcodec/x86/h264_deblock.asm
index 435c8be56f..509a0dbe0c 100644
--- a/libavcodec/x86/h264_deblock.asm
+++ b/libavcodec/x8
---
libavcodec/x86/h264_deblock.asm | 5 -
libavcodec/x86/h264_deblock_10bit.asm | 5 -
libavcodec/x86/hevc_deblock.asm | 5 -
libavutil/x86/x86util.asm | 5 +
4 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/libavcodec/x86/h264_deblock.asm b/
x86-64 only
Yorkfield:
- sse2: 2.16x (434 vs. 201 cycles)
Skylake:
- sse2: 3.04x (378 vs. 124 cycles)
- avx: 3.29x (378 vs. 115 cycles)
---
libavcodec/x86/h264_deblock.asm | 119
libavcodec/x86/h264dsp_init.c | 10
2 files changed, 129 insertions
Reported-by: SleepProgger
Signed-off-by: Michael Niedermayer
---
libavformat/http.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index 944a6cf322..bd1be3f7bb 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -10
On Mon, Feb 13, 2017 at 10:31:19AM +0100, wm4 wrote:
> On Fri, 10 Feb 2017 15:25:13 +0100
> Michael Niedermayer wrote:
>
> > On Fri, Feb 10, 2017 at 03:22:28PM +0100, Michael Niedermayer wrote:
> > > On Fri, Feb 10, 2017 at 03:15:29PM +0100, Michael Niedermayer wrote:
> > > > On Fri, Feb 10, 20
On Mon, Feb 13, 2017 at 11:36 AM, Timo Rothenpieler
wrote:
> 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 request
2017-02-13 6:37 GMT+01:00 Alex Converse :
> On Thu, Feb 9, 2017 at 4:11 PM, Carl Eugen Hoyos wrote:
>>
>> 2017-02-09 18:40 GMT+01:00 Alex Converse :
>> > Quiets some log spam on pure upsampling mode.
>>
>> Please mention ticket #5163.
>
> Done
Thank you.
>> For the whole patchset, I suggest you
Allow all struct fields to be accessed directly, as long as they're
public.
Before this change, many fields were "public", but could be accessed via
AVOption only. This meant they were effectively not public, but were
present for documentation purposes, which was incredibly confusing at
best.
---
Public fields were added after the private fields (negating the entire
point of this). New private fields go into AVStreamInternal anyway.
The new marker was set by guessing which fields are supposed to be
private and wshich not. recommended_encoder_configuration is accessed by
ffserver_config.c d
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 penalty (like libnpp does
>> 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.
>>
On Fri, 10 Feb 2017 15:25:13 +0100
Michael Niedermayer wrote:
> On Fri, Feb 10, 2017 at 03:22:28PM +0100, Michael Niedermayer wrote:
> > On Fri, Feb 10, 2017 at 03:15:29PM +0100, Michael Niedermayer wrote:
> > > On Fri, Feb 10, 2017 at 01:35:32PM +0100, wm4 wrote:
> > > > These patches merge
Dne 12.2.2017 v 23:27 Timo Rothenpieler napsal(a):
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
Dne 13.2.2017 v 09:11 Hendrik Leppkes napsal(a):
On Mon, Feb 13, 2017 at 9:08 AM, Miroslav Slugeň wrote:
Problem is that when you are using for example 200 input streams you have to
always specify correct input format h264/mpeg2/nvenc. Also when you are
using -hwaccel cuvid you have to specify
On Mon, Feb 13, 2017 at 9:08 AM, Miroslav Slugeň wrote:
> Problem is that when you are using for example 200 input streams you have to
> always specify correct input format h264/mpeg2/nvenc. Also when you are
> using -hwaccel cuvid you have to specify it too, otherwise there is error:
> CUVID hwac
On Mon, 13 Feb 2017 09:03:09 +0100
Miroslav Slugeň wrote:
> Dne 13.2.2017 v 05:03 wm4 napsal(a):
> > On Sun, 12 Feb 2017 21:07:40 +0100
> > Miroslav Slugeň wrote:
> >
> >> Dne 12.2.2017 v 20:59 Hendrik Leppkes napsal(a):
> >>> On Sun, Feb 12, 2017 at 8:51 PM, Miroslav Slugeň
> >>> wrote:
Dne 13.2.2017 v 05:08 wm4 napsal(a):
On Sun, 12 Feb 2017 21:20:12 +
Mark Thompson wrote:
On 12/02/17 20:37, Miroslav Slugeň wrote:
This patch is for discussion only, not ready to commit yet and maybe newer will
be.
We were facing issue when using -hwaccel cuvid we have to also specify i
Dne 13.2.2017 v 05:03 wm4 napsal(a):
On Sun, 12 Feb 2017 21:07:40 +0100
Miroslav Slugeň wrote:
Dne 12.2.2017 v 20:59 Hendrik Leppkes napsal(a):
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 suppo
48 matches
Mail list logo
