P016 is the 16-bit variant of NV12 (planar luma, packed chroma), using
two bytes per component.
It may, and in fact is most likely to, be used in situations where
there are less than 16 bits of data. It is the responsibility of
the writer to zero out any unused LSBs.
Signed-off-by: Philip Langdal
It's pretty much P010 with the low 6 bits explicitly allowed to contain
data. I did not attempt to implement any fast path conversion for P010.
Someone could obviously add that if desired.
Updated to bump minor version
Philip Langdale (2):
avutil: add P016 pixel format
swscale: add P016 input
Signed-off-by: Philip Langdale
---
libswscale/input.c | 32
libswscale/utils.c | 2 ++
2 files changed, 34 insertions(+)
diff --git a/libswscale/input.c b/libswscale/input.c
index 1f4ea18..8b5f348 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -719,
At 2016-11-21T15:56:23-0300, James Almer wrote:
> Seeing the maintainer hasn't replied, i have pushed it. Seems to adhere to
> the (draft) spec correctly, and is under an experimental strict check.
Thanks for your assistance getting this reviewed and landed, much
appreciated.
> I tried creating s
2016-11-21 20:29 GMT+08:00 Steven Liu :
> some flv have no metadata,
> ffmpeg will same with the source flv stream.
>
> Signed-off-by: Steven Liu
> ---
> doc/muxers.texi |3 +++
> libavformat/flvenc.c |8 +++-
> 2 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/
Fixes ticket #5973
Signed-off-by: James Almer
---
Maybe init() should propagate the extradata down the filter chain instead
of this, since if an aac stream has extradata then it means that it's an
ASC stream. Neither ADTS or LATM use extradata.
What's preferred?
libavcodec/aac_adtstoasc_bsf.c
On 11/21/2016 9:37 PM, Neil Birkbeck wrote:
> On Sat, Nov 19, 2016 at 3:28 PM, James Almer wrote:
>
>> On 11/19/2016 7:19 PM, Michael Niedermayer wrote:
>>> On Sat, Nov 19, 2016 at 03:09:15PM -0300, James Almer wrote:
This makes av_stream_add_side_data() consistent with
>> av_packet_add_side
On 11/21/2016 10:20 PM, Carl Eugen Hoyos wrote:
> 2016-11-21 16:49 GMT+01:00 James Almer :
>
>>> +int64_t avpriv_atomic_int64_cas(int64_t volatile *ptr, int64_t oldval,
>>> int64_t newval)
>>
>> There's a bunch of libav commits in queue to replace the entire custom atomic
>> API and use instead t
On Tue, Nov 22, 2016 at 12:15:16AM +0100, Martin Vignali wrote:
> Hello,
>
> 2016-11-21 23:16 GMT+01:00 Moritz Barsnick :
>
> > On Mon, Nov 21, 2016 at 21:44:55 +0100, Martin Vignali wrote:
> > > +avpriv_request_sample(s->avctx, "ZIP without predictor
> > compression");
> > > +ret
2016-11-21 16:49 GMT+01:00 James Almer :
>> +int64_t avpriv_atomic_int64_cas(int64_t volatile *ptr, int64_t oldval,
>> int64_t newval)
>
> There's a bunch of libav commits in queue to replace the entire custom atomic
> API and use instead the standard C11 API.
What does that mean for pre-C11 com
2016-11-21 19:52 GMT+01:00 Gregory J. Wolfe :
> (2) When ALL threading support is disabled, the build should not create a
> dependency on ANY thread library.
If this done through "#if HAVE_THREADS", it would be preferable to
split the patches imo.
Carl Eugen
_
Adds unknown channel layout support for filters where query_formats is not
specified. List of the affected filters:
abench
afifo
ainterleave
aloop
ametadata
anull
anullsink
apad
aperms
arealtime
aselect
asendcmd
asetnsamples
asetpts
asettb
ashowinfo
asidedata
asplit
asyncts
atrim
azmq
Also remove
On Tue, 22 Nov 2016 01:21:08 +0100, Carl Eugen Hoyos wrote:
> If an application writes psd files with width or height > 3 (or,
> horribile dictu, Adobe changes the limits), we want to decode
> such images (unless strict strict was set).
We shouldn't be encouraging theoretical random broken cr
2016-11-22 0:20 GMT+01:00 Andreas Cadhalpun :
> On 20.11.2016 21:27, Carl Eugen Hoyos wrote:
>> But --enable-sdl2 made no difference at all, or do I misunderstand?
>
> Indeed, I just thought it would. Isn't that a bug?
It is neither a bug nor not a bug, it is just how FFmpeg's configure
works for
On Sat, Nov 19, 2016 at 3:28 PM, James Almer wrote:
> On 11/19/2016 7:19 PM, Michael Niedermayer wrote:
> > On Sat, Nov 19, 2016 at 03:09:15PM -0300, James Almer wrote:
> >> This makes av_stream_add_side_data() consistent with
> av_packet_add_side_data().
> >>
> >> Signed-off-by: James Almer
> >
2016-11-22 0:06 GMT+01:00 Andreas Cadhalpun :
> On 20.11.2016 21:02, Carl Eugen Hoyos wrote:
>> 2016-11-20 20:40 GMT+01:00 Andreas Cadhalpun
>> :
>>> Currently many demuxers silently accept wrong (i.e. negative) values
>>> for channels, bit_rate, block_align and so on. I'd like to fix that,
>>> so
On Mon, Nov 21, 2016 at 03:37:49PM -0800, Wan-Teh Chang wrote:
> Make the one-time initialization in av_get_cpu_flags() thread-safe.
> The fix assumes -1 is an invalid value for cpu flags.
please explain the bug / race that occurs and how it is fixed
>
> The fix requires new atomic functions to
2016-11-22 0:40 GMT+01:00 Andreas Cadhalpun :
> For example what should be done about overflows, e.g. when
> calculating the bit rate? Does this count as demuxer failing?
I don't understand this question:
There are formats for which we don't know the specification (or
it may not exist): Of course
2016-11-22 0:57 GMT+01:00 Andreas Cadhalpun :
> On 20.11.2016 17:57, Martin Vignali wrote:
+s->height = bytestream2_get_be32(&s->gb);
+
+if ((s->height < 1) || (s->height > 3)) {
>>>
>>> Why 3?
>>> ff_set_dimensions already checks for sane dimensions.
>>>
>>
>> Follo
On Mon, Nov 21, 2016 at 04:37:12PM +0100, wm4 wrote:
[...]
> Besides, using this in practice would only trigger tons of malloc
> failure handling bugs, so practical uses would probably involve
> tearing down the whole process.
If such bugs exist (no doubt some do) they need to be fixed with or
wit
On 20.11.2016 17:57, Martin Vignali wrote:
>>> Support uncompress and rle compression in Image Data Section.
>> ^
>> decompression
>>
>
> Not sure i understand, do you mean :
> Support uncompress and rle decompression in Image Data Section.
> ?
> Because currently, the psd reader, can ma
On 21.11.2016 03:13, Michael Niedermayer wrote:
> On Sun, Nov 20, 2016 at 08:40:24PM +0100, Andreas Cadhalpun wrote:
>> Currently many demuxers silently accept wrong (i.e. negative) values
>> for channels, bit_rate, block_align and so on. I'd like to fix that,
>> so the question is now, how?
>>
>>
Make the one-time initialization in av_get_cpu_flags() thread-safe.
The fix assumes -1 is an invalid value for cpu flags.
The fix requires new atomic functions to get, set, and compare-and-swap
an integer without a memory barrier.
The data race fix is written by Dmitry Vyukov of Google.
Signed-o
Hi,
This patch makes the one-time initialization in av_get_cpu_flags()
thread-safe. The data race was reported by ThreadSanitizer.
Wan-Teh Chang (1):
avutil: fix data race in av_get_cpu_flags().
libavutil/atomic.c | 40
libavutil/atomic.h |
On Mon, 21 Nov 2016, Nicolas George wrote:
Le primidi 1er frimaire, an CCXXV, Marton Balint a écrit :
This reverts d300f5f6f570659e4b58567b35c9e8600c9f2956.
Further reference:
https://ffmpeg.org/pipermail/ffmpeg-devel/2013-October/149935.html
I can't reproduce ticket #2899 so I am not sure t
On 20.11.2016 21:52, Michael Niedermayer wrote:
> On Sun, Nov 20, 2016 at 08:55:44PM +0100, Andreas Cadhalpun wrote:
>> On 20.11.2016 12:57, Michael Niedermayer wrote:
>>> +if (intnum == 1 && d == (double)UINT64_MAX) {
>>> +*(int64_t *)dst = UINT64_MAX;
>>
>> Is there a reason w
On 20.11.2016 21:27, Carl Eugen Hoyos wrote:
> 2016-11-20 19:48 GMT+01:00 Andreas Cadhalpun
> :
>> On 20.11.2016 13:38, Carl Eugen Hoyos wrote:
>>> --enable-sdl2
>>
>> I'd rather not remove this. The thing is that sdl2 is autodetected, like sdl
>> used to be, but ffplay depends on it.
>
> How is
Hello,
2016-11-21 23:16 GMT+01:00 Moritz Barsnick :
> On Mon, Nov 21, 2016 at 21:44:55 +0100, Martin Vignali wrote:
> > +avpriv_request_sample(s->avctx, "ZIP without predictor
> compression");
> > +return AVERROR_PATCHWELCOME;
> > +break;
> > +case 3:
> > +avpr
On 14/11/16 07:11, Jun Zhao wrote:
> V2 : - Change the last_idr_frame filed location based on Mark code review.
> - Modify the commit message to actually explain the problem.
>
> From a1bf2b021effd36f8297b331855a282d775f2a44 Mon Sep 17 00:00:00 2001
> From: Jun Zhao
> Date: Fri, 11 Nov 2016
On 20.11.2016 21:02, Carl Eugen Hoyos wrote:
> 2016-11-20 20:40 GMT+01:00 Andreas Cadhalpun
> :
>> Currently many demuxers silently accept wrong (i.e. negative) values
>> for channels, bit_rate, block_align and so on. I'd like to fix that,
>> so the question is now, how?
>>
>> There are a few poss
On 14/11/16 00:19, Jun Zhao wrote:
>
>
> On 2016/11/12 22:00, Mark Thompson wrote:
>> On 11/11/16 02:24, Jun Zhao wrote:
>>> From 5db0b2cd0930ed88d853114f13b69a80a44d9c4c Mon Sep 17 00:00:00 2001
>>> From: Jun Zhao
>>> Date: Fri, 11 Nov 2016 10:04:53 +0800
>>> Subject: [PATCH] lavc/vaapi_encode_
On Mon, Nov 21, 2016 at 21:44:55 +0100, Martin Vignali wrote:
> +avpriv_request_sample(s->avctx, "ZIP without predictor compression");
> +return AVERROR_PATCHWELCOME;
> +break;
> +case 3:
> +avpriv_request_sample(s->avctx, "ZIP with predictor compression");
> +
On 21 November 2016 at 21:47, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Nov 21, 2016 at 4:40 PM, Rostislav Pehlivanov >
> wrote:
>
> > On 21 November 2016 at 20:44, Martin Vignali
> > wrote:
> >
> > > Hello,
> > >
> > > New patchs in attach.
> > > Correction have been made followings comments f
On Mon, Nov 21, 2016 at 12:17:43 +0100, Miroslav Slugeň wrote:
> + "Defined rc_lookahead require more surfaces, "
Nit:^ requires
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http:/
Hi,
On Mon, Nov 21, 2016 at 4:40 PM, Rostislav Pehlivanov
wrote:
> On 21 November 2016 at 20:44, Martin Vignali
> wrote:
>
> > Hello,
> >
> > New patchs in attach.
> > Correction have been made followings comments from Andreas and Carl.
> >
> > @Rotislav : thanks for your answer.
> >
> > Martin
On 21 November 2016 at 20:44, Martin Vignali
wrote:
> Hello,
>
> New patchs in attach.
> Correction have been made followings comments from Andreas and Carl.
>
> @Rotislav : thanks for your answer.
>
> Martin
>
> ___
> ffmpeg-devel mailing list
> ffmpeg
Hello,
New patchs in attach.
Correction have been made followings comments from Andreas and Carl.
@Rotislav : thanks for your answer.
Martin
From d923d4e8031fae4fa87cab39b431d055d2744ffe Mon Sep 17 00:00:00 2001
From: Martin Vignali
Date: Mon, 21 Nov 2016 21:39:07 +0100
Subject: [PATCH 1/2] lib
On 11/18/2016 12:35 AM, Matthew Gregan wrote:
> Without this, it's possible to mux VP9 into MOV without passing -strict -2.
> This tightens the check to restrict VP9 to MODE_MP4 only.
>
> Based on the discussion with James Almer on the experimental FLAC in MP4
> muxing patch.
>
>
> 0001-Restrict
On 11/18/2016 12:25 AM, Matthew Gregan wrote:
> At 2016-11-17T22:57:49-0300, James Almer wrote:
>>> > > @@ -345,6 +346,7 @@ const AVCodecTag ff_codec_movaudio_tags[] = {
>>> > > +{ AV_CODEC_ID_FLAC,MKTAG('f', 'L', 'a', 'C') }, /*
>>> > > nonstandard */
>> >
>> > This is enables mu
On 11/1/2016 8:23 PM, Matthew Gregan wrote:
> At 2016-11-01T18:07:07-0300, James Almer wrote:
>> > Just include libavcodec/flac.h which already defines it.
>> >
>> > With the above header you'll also be able to use the inline function
>> > flac_parse_block_header() for this. See flac and matroska
(1) Multi-threading support requires knowing the number of CPUs available.
When building with MinGW on a Windows system, both Windows and gcc run
time functions are available to get this information. If available,
the Windows function should be used, not the gcc function. This avoids
creating an
Thanks, sending corrected version.
just changed OFFSET(surfaces) to OFFSET(nb_surfaces)
Miroslav Slugeň
Dne 21.11.2016 v 13:29 Timo Rothenpieler napsal(a):
Does not compile:
libavcodec/cuvid.c:861:19: error: 'CuvidContext' has no member named
'surfaces'
#define OFFSET(x) offsetof(CuvidConte
On Mon, Nov 21, 2016 at 04:34:54PM +0100, wm4 wrote:
> On Mon, 21 Nov 2016 16:18:56 +0100
> Michael Niedermayer wrote:
>
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavutil/mem.c | 44
> > 1 file changed, 32 insertions(+), 12 deletions(-)
>
I omitted developers who do not use their account and i felt would prefer not
to be listed.
I think everyone using their account should be listed if we list anyone
Signed-off-by: Michael Niedermayer
---
MAINTAINERS | 25 +
1 file changed, 25 insertions(+)
diff --git a/MA
On Mon, Aug 24, 2015 at 03:37:42AM +0300, Ludmila Glinskih wrote:
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
patch applied
this seems to have been forgotten
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
What does censorship reveal? It reveal
On Mon, Nov 21, 2016 at 5:23 PM, Gregory J Wolfe
wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
>> Behalf Of wm4
>> Sent: Monday, November 21, 2016 10:05 AM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH] Avoid creating
On Mon, 21 Nov 2016 16:23:03 +
Gregory J Wolfe wrote:
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf Of wm4
> > Sent: Monday, November 21, 2016 10:05 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH] Avoid
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf Of wm4
> Sent: Monday, November 21, 2016 10:05 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] Avoid creating unecessary
> dependencies on thread libraries.
>
> On Mon, 21
On Mon, 21 Nov 2016 09:58:33 -0500
"Gregory J. Wolfe" wrote:
> (1) Multi-threading support requires knowing the number of CPUs available.
> When building with MinGW on a Windows system, both gcc and Windows run
> time functions are available to get this information. However, when Windows
> threa
Le primidi 1er frimaire, an CCXXV, Michael Niedermayer a écrit :
> With this it is possible to prevent OOM with untrusted media
>
> As this fundamentally requires keeping track of allocated memory sizes
> and the memalign hack code does nearly exactly that already, this feature
> depends on it bei
Le primidi 1er frimaire, an CCXXV, wm4 a écrit :
> I do not understand this. Please explain why requesting features is
> against policy or not useful.
Please stop your passive-aggressive flame bait.
signature.asc
Description: Digital signature
___
ffmp
On 11/21/2016 12:18 PM, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavutil/atomic.c | 20
> libavutil/atomic.h | 10 ++
> libavutil/atomic_gcc.h | 12
> 3 files changed, 42 insertions(+)
>
> diff --git a/libavutil/a
On Mon, 21 Nov 2016 16:18:58 +0100
Michael Niedermayer wrote:
> With this it is possible to prevent OOM with untrusted media
>
> As this fundamentally requires keeping track of allocated memory sizes
> and the memalign hack code does nearly exactly that already, this feature
> depends on it bein
On Sun, 20 Nov 2016 14:35:51 -0800
Philip Langdale wrote:
> P016 is the 16-bit variant of NV12 (planar luma, packed chroma), using
> two bytes per component.
>
> It may, and in fact is most likely to, be used in situations where
> there are less than 16 bits of data. It is the responsibility of
On Mon, 21 Nov 2016 16:18:56 +0100
Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavutil/mem.c | 44
> 1 file changed, 32 insertions(+), 12 deletions(-)
>
"Fix" is not a good description. Was it broken? What was broken?
nvenc doesn't officially support P016 input, but at the same time,
cuvid only outputs P016, technically (it uses the same format for
both 10 and 12 bit output). As it's safe to pass P016 when P010 is
expected, let's just allow it; it's wasteful to force content through
swscale.
After this change,
These changes allow cuvid to output P016 for 10/12bit content
and nvenc to accept it (treating it as P010). Additional work
will be required for transcoding, however.
Philip Langdale (2):
avcodec/cuvid: Add support for P016 as an output surface format
avcodec/nvenc: Accept P016 content
compa
The nvidia 375.xx driver introduces support for P016 output surfaces,
for 10bit and 12bit HEVC content (it's also the first driver to support
hardware decoding of 12bit content).
This change introduces cuvid decoder support for P016 output for
output to hardware and system memory surfaces. For sim
Signed-off-by: Michael Niedermayer
---
libavutil/mem.c | 44
1 file changed, 32 insertions(+), 12 deletions(-)
diff --git a/libavutil/mem.c b/libavutil/mem.c
index 1a8fc21..6273d89 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -86,12 +86,15 @@
Signed-off-by: Michael Niedermayer
---
libavutil/atomic.c | 20
libavutil/atomic.h | 10 ++
libavutil/atomic_gcc.h | 12
3 files changed, 42 insertions(+)
diff --git a/libavutil/atomic.c b/libavutil/atomic.c
index 64cff25..27561ad 100644
--- a/li
With this it is possible to prevent OOM with untrusted media
As this fundamentally requires keeping track of allocated memory sizes
and the memalign hack code does nearly exactly that already, this feature
depends on it being enabled.
Signed-off-by: Michael Niedermayer
---
libavutil/mem.c | 45
(1) Multi-threading support requires knowing the number of CPUs available.
When building with MinGW on a Windows system, both gcc and Windows run
time functions are available to get this information. However, when Windows
threading has been selected, the Windows function should be used, not the
gc
On 11/21/2016 4:21 AM, Rostislav Pehlivanov wrote:
> On 17 November 2016 at 00:08, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
>> All the fields can be set via options read from the ffm file and thus
>> have to be sanitized.
>>
>> A negative extradata size for example gets pas
Thanks, sending corrected version.
just changed OFFSET(surfaces) to OFFSET(nb_surfaces)
Miroslav Slugeň
+420 724 825 885
Dne 21.11.2016 v 13:29 Timo Rothenpieler napsal(a):
Does not compile:
libavcodec/cuvid.c:861:19: error: 'CuvidContext' has no member named
'surfaces'
#define OFFSET(x) of
some flv have no metadata,
ffmpeg will same with the source flv stream.
Signed-off-by: Steven Liu
---
doc/muxers.texi |3 +++
libavformat/flvenc.c |8 +++-
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 806182a..8689341 10
Does not compile:
libavcodec/cuvid.c:861:19: error: 'CuvidContext' has no member named
'surfaces'
#define OFFSET(x) offsetof(CuvidContext, x)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Mon, 21 Nov 2016 13:08:37 +0100
Carl Eugen Hoyos wrote:
> 2016-11-21 13:06 GMT+01:00 wm4 :
> > On Mon, 21 Nov 2016 12:48:31 +0100
> > Carl Eugen Hoyos wrote:
> >
> >> 2016-11-21 12:04 GMT+01:00 wm4 :
> >> > On Mon, 21 Nov 2016 07:36:44 +
> >>
> >> > Can we get support for .doc and
We are using more decoding threads at once, so it is sometime useful to
lower number of surfaces used for decoding, it could lower GPU memory usage.
--
Miroslav Slugeň
>From 30ddf173c87a9da16ba4725f8beea67d8fa6f537 Mon Sep 17 00:00:00 2001
From: Miroslav Slugen
Date: Mon, 21 Nov 2016 10:51:25
2016-11-21 13:06 GMT+01:00 wm4 :
> On Mon, 21 Nov 2016 12:48:31 +0100
> Carl Eugen Hoyos wrote:
>
>> 2016-11-21 12:04 GMT+01:00 wm4 :
>> > On Mon, 21 Nov 2016 07:36:44 +
>>
>> > Can we get support for .doc and .html too? I think these would be great
>> > features.
>>
>> Maybe such comments are
On Mon, 21 Nov 2016 12:48:31 +0100
Carl Eugen Hoyos wrote:
> 2016-11-21 12:04 GMT+01:00 wm4 :
> > On Mon, 21 Nov 2016 07:36:44 +
>
> > Can we get support for .doc and .html too? I think these would be great
> > features.
>
> Maybe such comments are not against our policy (that you reque
Thx, i has same opinion :)
Miroslav Slugeň
+420 724 825 885
Dne 21.11.2016 v 12:57 Timo Rothenpieler napsal(a):
Please split the patch into two (or three) patches to make
the review and possible regression tests easier.
The bug was implicitly fixed by the new code, it doesn't seem necessary
to
Patch LGTM, applied locally, will push most likely tomorrow.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> Please split the patch into two (or three) patches to make
> the review and possible regression tests easier.
The bug was implicitly fixed by the new code, it doesn't seem necessary
to me to fix it independently, specially as so far nobody seems to have
run into it.
Patch LGTM, applied locally,
On Sat, 19 Nov 2016 17:18:08 -0800
Philip Langdale wrote:
> The nvidia 375.xx driver introduces support for P016 output surfaces,
> for 10bit and 12bit HEVC content (it's also the first driver to support
> hardware decoding of 12bit content).
>
> Technically, we don't support P016, but in practi
On Sun, 20 Nov 2016 13:52:02 +0100
Clément Bœsch wrote:
> On Fri, Nov 11, 2016 at 04:46:51PM +0100, wm4 wrote:
> [...]
> > > +
> > > +frame->sub_start_display = sub.start_display_time ?
> > > av_rescale_q(sub.start_display_time, av_make_q(1, 1000), AV_TIME_BASE_Q)
> > > +
2016-11-21 12:04 GMT+01:00 wm4 :
> On Mon, 21 Nov 2016 07:36:44 +
> Can we get support for .doc and .html too? I think these would be great
> features.
Maybe such comments are not against our policy (that you requested so
much), in any case they are not useful.
Carl Eugen
___
2016-11-21 12:17 GMT+01:00 Miroslav Slugeň :
> That was the easy part, now littlebit more...
>
> Next part of this patch is to always prefer rc_lookahead
[...]
> There were also bug
Please split the patch into two (or three) patches to make
the review and possible regression tests easier.
Than
2016-11-21 12:30 GMT+01:00 wm4 :
> On Sun, 20 Nov 2016 14:24:00 +0100
> Carl Eugen Hoyos wrote:
>
>> 2016-11-20 13:52 GMT+01:00 Clément Bœsch :
>>
>> >> > +static const AVOption sbuffer_options[] = {
>> >> > +{ "time_base", NULL, OFFSET(time_base),
>> >> > AV_OPT_TYPE_RATIONAL, { .dbl =
On Sun, 20 Nov 2016 14:24:00 +0100
Carl Eugen Hoyos wrote:
> 2016-11-20 13:52 GMT+01:00 Clément Bœsch :
>
> >> > +static const AVOption sbuffer_options[] = {
> >> > +{ "time_base", NULL, OFFSET(time_base), AV_OPT_TYPE_RATIONAL,
> >> > { .dbl = 0 }, 0, INT_MAX, S },
> >> > +{ "form
User selectable surfaces are not working correctly, if you set number of
surfaces on cmdline, it will always use minimum 32 or 48 depends on
selected resolution, but in nvenc it is not necessary to use so many
surfaces.
So from now you can define as low as 1 surface and nvenc will still
work,
On Mon, 21 Nov 2016 07:36:44 +
Rostislav Pehlivanov wrote:
> On 20 November 2016 at 17:05, Kieran Kunhya wrote:
>
> > I object to this patch for the reasons Rostislav outlined..
> >
> > Kieran
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel
Le primidi 1er frimaire, an CCXXV, Marton Balint a écrit :
> This reverts d300f5f6f570659e4b58567b35c9e8600c9f2956.
>
> Further reference:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2013-October/149935.html
>
> I can't reproduce ticket #2899 so I am not sure the original patch is still
> needed.
Maximum usable surfaces is limited to MAX_REGISTERED_FRAMES constant in
nvenc.h
--
Miroslav Slugeň
>From 96b28516942d76b65e9dce033317909e4c0e019a Mon Sep 17 00:00:00 2001
From: Miroslav Slugen
Date: Mon, 21 Nov 2016 11:04:45 +0100
Subject: [PATCH] NVENC: Maximum usable surfaces is limited to
On 21/11/2016 09:51, Carl Eugen Hoyos wrote:
2016-11-21 10:35 GMT+01:00 Josh de Kock :
On 20/11/2016 22:49, Carl Eugen Hoyos wrote:
2016-11-19 17:37 GMT+01:00 Josh de Kock :
I've mapped a fair amount of the CoreMedia FourCCs to their
respective AVCodecIDs. The ones I didn't know or thought d
2016-11-21 10:35 GMT+01:00 Josh de Kock :
> On 20/11/2016 22:49, Carl Eugen Hoyos wrote:
>>
>> 2016-11-19 17:37 GMT+01:00 Josh de Kock :
>>>
>>> I've mapped a fair amount of the CoreMedia FourCCs to their
>>> respective AVCodecIDs. The ones I didn't know or thought didn't
>>> exist in FFmpeg have b
2016-11-21 2:09 GMT+01:00 Marton Balint :
> This reverts d300f5f6f570659e4b58567b35c9e8600c9f2956.
>
> Further reference:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2013-October/149935.html
>
> I can't reproduce ticket #2899
I just tested the following with FFmpeg 2.1:
$ ffmpeg -i test.wav -af "p
On 20/11/2016 22:49, Carl Eugen Hoyos wrote:
2016-11-19 17:37 GMT+01:00 Josh de Kock :
I've mapped a fair amount of the CoreMedia FourCCs to their
respective AVCodecIDs. The ones I didn't know or thought didn't
exist in FFmpeg have been mapped to AV_CODEC_ID_NONE.
Could you explain the use-cas
87 matches
Mail list logo
