Carl Eugen Hoyos:
> Hi!
>
> Attached patch is supposed to fix HandBrake issue 1964, FFmpeg
> currently fails to identify WebVTT in Matroska (only webm is supported
> as container). I don't have the original sample to test though.
>
> Please comment, Carl Eugen
The way WebVTT is stored in
On 11/03/2019 15:51, Carl Eugen Hoyos wrote:
> 2019-03-11 11:16 GMT+01:00, Timo Rothenpieler :
>> On 11/03/2019 09:40, Carl Eugen Hoyos wrote:
>>> 2019-03-11 6:36 GMT+01:00, Ruta Gadkari :
>>>
Please find attached the patch, it enables ffnvcodec and nvenc,
nvdec, cuvid for PPC64
Hi Carl,
Thanks for review, is there any more issue I need to take care ?
or any process I need to follow before applying the patch? I am new to the
community, don't know too much.
Thanks
-Jun
On Mon, Mar 11, 2019 at 11:44 AM Carl Eugen Hoyos
wrote:
> 2019-03-11 18:58 GMT+01:00, Jun Li :
>
> >
Thank you James and Moritz.
For many of these parameters, the default value within the codec is '1'. So
we want to add the option for disabling it also.
I would like to follow the method used for "frame-parallel", after
changing the default value to -1.
{ "frame-parallel", "Enable frame
---
libavcodec/vaapi_encode.c | 128
libavcodec/vaapi_encode.h | 11 +++
libavcodec/vaapi_encode_h264.c | 2 +
libavcodec/vaapi_encode_h265.c | 2 +
libavcodec/vaapi_encode_mpeg2.c | 2 +
libavcodec/vaapi_encode_vp8.c | 2 +
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Wednesday, March 13, 2019 8:18 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2 3/6] libx264: Update ROI behaviour to
> match documentation
>
> Fix
On 08/03/2019 07:44, Oliver Collyer wrote:
> From c704e3535f866d9f89535b9df59db9ca9811bcf9 Mon Sep 17 00:00:00 2001
> From: Oliver Collyer
> Date: Fri, 8 Mar 2019 07:42:41 +
> Subject: [PATCH 1/1] avcodec/nvenc: Reconfigure resolution on-the-fly
>
> ---
> libavcodec/nvenc.c | 31
On 09/03/2019 20:30, Peter F wrote:
> Thank you very much for your reply.
> Am Sa., 9. März 2019 um 21:09 Uhr schrieb Jan Ekström :
>
>>> From 386c94489a86bb747b6531f727843cf259a24f5d Mon Sep 17 00:00:00 2001
>>> From: xbmc
>> Is this author field meant to not have an actual name in it? Just
> On 12 Mar 2019, at 23:40, Mark Thompson wrote:
>
>> On 08/03/2019 07:44, Oliver Collyer wrote:
>> From c704e3535f866d9f89535b9df59db9ca9811bcf9 Mon Sep 17 00:00:00 2001
>> From: Oliver Collyer
>> Date: Fri, 8 Mar 2019 07:42:41 +
>> Subject: [PATCH 1/1] avcodec/nvenc: Reconfigure
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Wednesday, March 13, 2019 8:18 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2 4/6] libx265: Update ROI behaviour to
> match documentation
>
>
Hi Giovara,
SVT HEVC has the interface to enable/disable sending a vui structure in the
HEVC bitstream, but supports no interface for setting the color properties
before encoding yet. I will be opening an issue in SVT HEVC github asking if
they have plans to add such feature, and will keep you
On Monday, March 11, 2019 10:50 PM Vittorio Giovara vittorio.giov...@gmail.com
wrote:
>On Mon, Mar 11, 2019 at 12:50 AM Sun, Jing A wrote:
>I just searched my inbox again but failed to find that email of question you
>mentioned.
>
>Yeah I often see my mail bounced with this message:
>
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Wednesday, March 13, 2019 8:18 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2 5/6] vaapi_encode: Add ROI support
>
> ---
>
On 12/03/2019 09:52, Ruta Gadkari wrote:
On 11/03/2019 15:51, Carl Eugen Hoyos wrote:
2019-03-11 11:16 GMT+01:00, Timo Rothenpieler :
On 11/03/2019 09:40, Carl Eugen Hoyos wrote:
2019-03-11 6:36 GMT+01:00, Ruta Gadkari :
Please find attached the patch, it enables ffnvcodec and nvenc,
Hi
I think we should add a entry for fate-samples to MAINTAINERS
so that people who need a file uploaded know with whom to talk
if the file is not being uploaded from a post to the ML
if people agree. Who can i add to that entry ? (i dont want to
just dump everyone who has access to it as people
tis 2019-03-12 klockan 10:27 + skrev Matthew Fearnley:
> > On 11 Mar 2019, at 10:37, Tomas Härdin wrote:
> >
> >
> > There's some justification for adding sub-8bpp, like BMP. bmp.c
> > converts all of them except GRAY8 to PAL8. Bitdepths besides 1, 4
> > and 8
> > don't work at all.
> >
>
On Tue, Mar 12, 2019 at 05:05:00AM +, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Sun, Mar 10, 2019 at 11:03:00PM +, Andreas Rheinhardt wrote:
> >> Michael Niedermayer:
> >>> On Fri, Mar 08, 2019 at 10:25:59AM +0100, Andreas Rheinhardt wrote:
> When the new incremental
On Tue, Mar 12, 2019 at 11:45:06 -0300, James Almer wrote:
> > +{ "frame-parallel", "Enable frame parallel decodability features",
> > OFFSET(frame_parallel), AV_OPT_TYPE_BOOL,{.i64 = -1}, -1, 1, VE},
>
> A bool with three values is weird. If this is meant to be disabled by
> default,
On 3/8/2019 10:21 PM, Sam John wrote:
> The following are the newly added options:
> arnr_max_frames, arnr_strength, aq_mode, denoise_noise_level,
> denoise_block_size,
> rc_undershoot_pct, rc_overshoot_pct, minsection_pct, maxsection_pct,
> frame_parallel,
> enable_cdef, and
On Tue, 5 Mar 2019, Marton Balint wrote:
set_metadata with many entries is not very efficient, and with small audio
frames the performance loss is noticable. Also with this very simple
calculations (like peak) can be even further optimized.
Unfoturnately there are some small differences in
On Sat, 9 Mar 2019 at 12:56, Oliver Collyer wrote:
> Although accenc appears able to cope with dynamic bitrate changes, this
> patch makes sure that any such changes are validated in the same manner as
> the initial bitrate and also adds logging of such changes in verbose mode.
>
>
> On 12 Mar 2019, at 21:57, Rostislav Pehlivanov wrote:
>
>> On Sat, 9 Mar 2019 at 12:56, Oliver Collyer wrote:
>>
>> Although accenc appears able to cope with dynamic bitrate changes, this
>> patch makes sure that any such changes are validated in the same manner as
>> the initial bitrate
> On 11 Mar 2019, at 10:37, Tomas Härdin wrote:
>
> fre 2019-03-08 klockan 21:39 + skrev Matthew Fearnley:
On Fri, 8 Mar 2019 at 18:07, Carl Eugen Hoyos wrote:
2019-03-08 15:04 GMT+01:00, Tomas Härdin :
Maybe we could coordinate 1/2/4/24-bit support with the
>>>
>>> I
On Mon, Mar 11, 2019 at 01:22:38PM -0700, mindm...@gmail.com wrote:
> From: Mark Reid
>
> ---
> tests/fate/mxf.mak | 15 ++-
> tests/ref/fate/mxf-d10-user-comments| 1 +
> tests/ref/fate/mxf-opatom-user-comments | 1 +
> tests/ref/fate/mxf-user-comments
I am submitting another patch. Please disregard this one.
-Mike
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Looks like the variable 'cur_timestamp' is not used anywhere.
So remove this variable.
Signed-off-by: Jun Li
---
libavformat/rtpdec.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/rtpdec.h b/libavformat/rtpdec.h
index 5a47d6f79d..9144edbe8b 100644
--- a/libavformat/rtpdec.h
+++
Replaced VSHUFPS with VPBLENDD to relieve port 5 bottleneck
AVX2 is now 1.4x faster than AVX
Tested on Broadwell CPU, Ubuntu 18.10 x86_64
~/FFmpeg$ tests/checkasm/checkasm --bench --test=v210dec
benchmarking with native FFmpeg timers
nop: 94.1
checkasm: using random seed 3963743306
SSSE3:
-
Michael Niedermayer:
>
> thanks for the detailed analysis, and yes i agree this is a bug in
> existing code
>
Does this mean that the fact that this patch affects seeking does not
hinder its merging? Or does the seeking issue have to be fixed first?
In the latter case, I'd omitt this patch for
On 3/5/2019 3:19 PM, Vittorio Giovara wrote:
> ---
> configure | 2 +-
> libavcodec/libdav1d.c | 30 +-
> 2 files changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/configure b/configure
> index dcead3a300..a5cef4bc09 100755
> --- a/configure
>
> On Mar 13, 2019, at 05:26, Jun Li wrote:
>
> Looks like the variable 'cur_timestamp' is not used anywhere.
> So remove this variable.
>
> Signed-off-by: Jun Li
> ---
> libavformat/rtpdec.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/libavformat/rtpdec.h b/libavformat/rtpdec.h
>
The definition here previously matched the way cropping worked, but the
actual uses in libavcodec instead treated the values as the coordinates
of the top-left and bottom-right corners.
The most common way of defining rectangles in FFmpeg appears to be as
coordinates of the top-left corner
Clarify and add examples for the behaviour of the quantisation offset,
and define how multiple ranges should be handled.
---
libavutil/frame.h | 46 ++
1 file changed, 34 insertions(+), 12 deletions(-)
diff --git a/libavutil/frame.h b/libavutil/frame.h
This can be used to add region of interest side data to video frames.
---
Now using the x,y,w,h style to match other filters.
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_addroi.c | 265 +++
3 files changed, 267
Fix the quantisation offset - use the whole range, and don't change the
offset size based on bit depth.
Iterate the list in reverse order. The first region in the list is the one
that applies in the case of overlapping regions.
---
libavcodec/libx264.c | 51
Equivalent to the previous patch for libx264.
---
libavcodec/libx265.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index c2c1f8b9bc..a580d113b9 100644
--- a/libavcodec/libx265.c
+++
35 matches
Mail list logo
