On Mon, Nov 14, 2016 at 12:18:12AM +0100, Nicolas George wrote:
> Le quartidi 24 brumaire, an CCXXV, Hendrik Leppkes a écrit :
> > I disagree with that, this is generic utility code, not a tight
> > algorithm loop, where absolute efficiency is not necessarily required,
> > and disregarding code sim
2016-11-14 3:32 GMT+01:00 Michael Niedermayer :
> On Mon, Nov 14, 2016 at 01:59:06AM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patches are a requirement to fix two tickets.
>>
>> Please review, Carl Eugen
>
> patches LGTM
Patches applied.
Thank you, Carl Eugen
_
This work is sponsored by, and copyright, Google.
These are ported from the ARM version; thanks to the larger
amount of registers available, we can do the 16x16 and 32x32
transforms in slices 8 pixels wide instead of 4. This gives
a speedup of around 1.4x compared to the 32 bit version.
The fact
This work is sponsored by, and copyright, Google.
These are ported from the ARM version; it is essentially a 1:1
port with no extra added features, but with some hand tuning
(especially for the plain copy/avg functions). The ARM version
isn't very register starved to begin with, so there's not muc
With apple tools, the linker fails with errors like these, if the
offset is negative:
ld: in section __TEXT,__text reloc 8: symbol index out of range for
architecture arm64
This is cherry-picked from libav commit
c44a8a3eabcd6acd2ba79f32ec8a432e6ebe552c.
---
libavutil/aarch64/asm.S | 14 +++
This work is sponsored by, and copyright, Google.
The implementation tries to have smart handling of cases
where no pixels need the full filtering for the 8/16 width
filters, skipping both calculation and writeback of the
unmodified pixels in those cases. The actual effect of this
is hard to test
This work is sponsored by, and copyright, Google.
The filter coefficients are signed values, where the product of the
multiplication with one individual filter coefficient doesn't
overflow a 16 bit signed value (the largest filter coefficient is
127). But when the products are accumulated, the res
This work is sponsored by, and copyright, Google.
For the transforms up to 8x8, we can fit all the data (including
temporaries) in registers and just do a straightforward transform
of all the data. For 16x16, we do a transform of 4x16 pixels in
4 slices, using a temporary buffer. For 32x32, we tra
This work is sponsored by, and copyright, Google.
These are ported from the ARM version; thanks to the larger
amount of registers available, we can do the loop filters with
16 pixels at a time. The implementation is fully templated, with
a single macro which can generate versions for both 8 and
16
Le quartidi 24 brumaire, an CCXXV, Clement Boesch a écrit :
> You can dereference once before entering the loop
That requires one extra variable, and therefore leaves one less register
for the loop itself.
And of course, all these efficiency problems correspond directly to
readability issues. Now
We reset .Lpic_gp to zero at the start of each function, which means
that the logic within movrelx for clearing gp when necessary will
be missed.
This fixes using movrelx in different functions with a different
helper register.
This is cherry-picked from libav commit
824e8c284054f323f854892d1b473
Make them aligned, to allow efficient access to them from simd.
This is an adapted cherry-pick from libav commit
a4cfcddcb0f76e837d5abc06840c2b26c0e8aefc.
---
libavcodec/vp9dsp.c | 56 +++
libavcodec/vp9dsp.h | 3 +++
libavcodec/vp9dsp_templa
On Sun, Nov 13, 2016 at 10:32:13PM +0100, Hendrik Leppkes wrote:
> ffmpeg | branch: master | Hendrik Leppkes | Sun Nov 13
> 22:29:04 2016 +0100| [bd0db4a32d85d027da4d4dc00490c20048090312] | committer:
> Hendrik Leppkes
>
> Merge commit '7a745f014f528d1001394ae4d2f4ed1a20bf7fa2'
>
> * commit '7
Le tridi 23 brumaire, an CCXXV, James Almer a écrit :
> Why do you always only accept or consider replies and arguments from other
> people when they exclusively fit the narrative you expect them to be? You're
> literally telling me what i said is worth nothing because it wasn't, or you
> assumed i
Hello,
This patch is to close Ticker 4155: https://trac.ffmpeg.org/ticket/4155
Actualy, patch is made by "rycius".
I just updated the diff file to date and separated into two parts with
making a small change
a) Overflow fix exit fix
b) Underflow timebase fix
Kind Regards,
Ali KIZIL
0001-Fix-U
On Sun, Nov 13, 2016 at 11:54:23PM +0100, Nicolas George wrote:
> Le tridi 23 brumaire, an CCXXV, James Almer a écrit :
> > AVSomethingInternal *internal;
>
> > No technical advantages i can think of compared to your method, but it's
> > thoroughly tested, clean, and above all ubiquitous. See
2016-11-14 12:21 GMT+01:00 Ali KIZIL :
> This patch is to close Ticker 4155: https://trac.ffmpeg.org/ticket/4155
>
> Actualy, patch is made by "rycius".
Then why does the patch claim to be written by you?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg
2016-11-14 14:31 GMT+03:00 Carl Eugen Hoyos :
> 2016-11-14 12:21 GMT+01:00 Ali KIZIL :
>
> > This patch is to close Ticker 4155: https://trac.ffmpeg.org/ticket/4155
> >
> > Actualy, patch is made by "rycius".
>
> Then why does the patch claim to be written by you?
>
> Carl Eugen
>
Le quartidi 24 brumaire, an CCXXV, Clement Boesch a écrit :
> The pros for an internal fields are, for me:
>
> - consistency across the codebase
> - definitions more readable (if you're advocating the fact that a
> multiline define is as readable I'll stop reading right now)
> - common C pattern
2016-11-14 12:41 GMT+01:00 Ali KIZIL :
> I dont claim anything and I also said it is not written by me.
In your mail you wrote 'patch is made by "rycius"'.
The git-formatted patch you attached has the following
in its author field: "smallishzulu ".
This is a contradiction.
I don't know who wrote
On Mon, Nov 14, 2016 at 01:06:30PM +0100, Nicolas George wrote:
> Le quartidi 24 brumaire, an CCXXV, Clement Boesch a écrit :
> > The pros for an internal fields are, for me:
> >
> > - consistency across the codebase
> > - definitions more readable (if you're advocating the fact that a
> > multi
2016-11-14 15:15 GMT+03:00 Carl Eugen Hoyos :
> 2016-11-14 12:41 GMT+01:00 Ali KIZIL :
>
> > I dont claim anything and I also said it is not written by me.
>
> In your mail you wrote 'patch is made by "rycius"'.
> The git-formatted patch you attached has the following
> in its author field: "small
2016-11-14 13:24 GMT+01:00 Ali KIZIL :
> 2016-11-14 15:15 GMT+03:00 Carl Eugen Hoyos :
>
>> 2016-11-14 12:41 GMT+01:00 Ali KIZIL :
>>
>> > I dont claim anything and I also said it is not written by me.
>>
>> In your mail you wrote 'patch is made by "rycius"'.
>> The git-formatted patch you attached
Hi,
assume this is my reply on all patches in the range 2-9:
On Mon, Nov 14, 2016 at 5:32 AM, Martin Storsjö wrote:
> We reset .Lpic_gp to zero at the start of each function, which means
> that the logic within movrelx for clearing gp when necessary will
> be missed.
>
> This fixes using movrel
Hi,
On Mon, Nov 14, 2016 at 5:32 AM, Martin Storsjö wrote:
> Make them aligned, to allow efficient access to them from simd.
>
> This is an adapted cherry-pick from libav commit
> a4cfcddcb0f76e837d5abc06840c2b26c0e8aefc.
> ---
> libavcodec/vp9dsp.c | 56 +++
On Mon, 14 Nov 2016, Ronald S. Bultje wrote:
Hi,
On Mon, Nov 14, 2016 at 5:32 AM, Martin Storsjö wrote:
Make them aligned, to allow efficient access to them from simd.
This is an adapted cherry-pick from libav commit
a4cfcddcb0f76e837d5abc06840c2b26c0e8aefc.
---
libavcodec/vp9dsp.c
2016-11-14 15:52 GMT+03:00 Carl Eugen Hoyos :
> 2016-11-14 13:24 GMT+01:00 Ali KIZIL :
> > 2016-11-14 15:15 GMT+03:00 Carl Eugen Hoyos :
> >
> >> 2016-11-14 12:41 GMT+01:00 Ali KIZIL :
> >>
> >> > I dont claim anything and I also said it is not written by me.
> >>
> >> In your mail you wrote 'patc
On 11/11/2016 4:01 PM, Timo Rothenpieler wrote:
> -1 and 0 both mean false now, and I left in the option to pass -1 to
> stay compatible with possible 3rd parties who pass it.
Well that's certainly non-obvious...
> So changing to default to 0 doesn't really matter, and I decided to keep
> the pat
On 11/12/2016 6:02 AM, Sasi Inguva wrote:
> +/* Adjust skip_samples correctly when ignore_editlist is set, to support
> gapless playback */
> +if (mov->ignore_editlist && sc->num_non_empty_elst <= 1 &&
> +st->codecpar->codec_id == AV_CODEC_ID_AAC &&
> sc->first_elist_start_time >
Hi!
I believe attached patch fixes an out-of-bound-read in mov_read_mac_string()
if pFrom 6c69f755e1c4f22d1efb36777631c98a4d20ffef Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Mon, 14 Nov 2016 14:52:58 +0100
Subject: [PATCH] lavf/mov: Fix an out-of-bound-read in mov_read_mac_string().
On Mon, Nov 14, 2016 at 12:32:19PM +0200, Martin Storsjö wrote:
> Make them aligned, to allow efficient access to them from simd.
>
> This is an adapted cherry-pick from libav commit
> a4cfcddcb0f76e837d5abc06840c2b26c0e8aefc.
> ---
> libavcodec/vp9dsp.c | 56
Le quartidi 24 brumaire, an CCXXV, Clement Boesch a écrit :
> I don't see how. You add a pointer at the beginning of your function
> pointing on that internal structure and use that.
That makes extra code. Remember we are talking about lavfi: we
frequently have inlink1, inlink2, outlink. If we mus
On Mon, Nov 14, 2016 at 04:52:01PM +0100, Nicolas George wrote:
> Le quartidi 24 brumaire, an CCXXV, Clement Boesch a écrit :
> > I don't see how. You add a pointer at the beginning of your function
> > pointing on that internal structure and use that.
>
> That makes extra code. Remember we are ta
Le quartidi 24 brumaire, an CCXXV, Clement Boesch a écrit :
> You could also make a local copy of the fields you need; it is -in my
> opinion- not that much noise to add one or a few more lines of
> declaration.
When the fields are used read-only, probably. Still more code for no
good reason.
Whe
Skip the intermediary codecpar struct and instead copy everything to the
destination codecpar struct directly.
Signed-off-by: James Almer
---
ffmpeg.c | 17 +++--
ffmpeg.h | 1 -
ffmpeg_opt.c | 6 --
3 files changed, 7 insertions(+), 17 deletions(-)
diff --git a/ffmpeg
On Sun, 13 Nov 2016 23:50:03 +0100
Carl Eugen Hoyos wrote:
> 2016-11-11 12:15 GMT+01:00 wm4 :
> > On Fri, 11 Nov 2016 10:19:08 +0100
> > Carl Eugen Hoyos wrote:
> >
> >> 2016-11-11 9:03 GMT+01:00 Hendrik Leppkes :
> >> > On Fri, Nov 11, 2016 at 6:34 AM, Yogender Gupta
> >> > wrote:
>
>
On Sun, 13 Nov 2016 11:10:20 +0100
Nicolas George wrote:
> Signed-off-by: Nicolas George
> ---
> libavfilter/Makefile | 1 +
> libavfilter/framequeue.c | 123 +
> libavfilter/framequeue.h | 173
> +++
> 3 files c
Le quartidi 24 brumaire, an CCXXV, wm4 a écrit :
> Nice, previous review was completely ignored.
Indeed. You told me yourself to do that when I consider your remarks
rude.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpe
On 11/14/2016 8:01 AM, Michael Niedermayer wrote:
> On Sun, Nov 13, 2016 at 10:32:13PM +0100, Hendrik Leppkes wrote:
>> ffmpeg | branch: master | Hendrik Leppkes | Sun Nov 13
>> 22:29:04 2016 +0100| [bd0db4a32d85d027da4d4dc00490c20048090312] | committer:
>> Hendrik Leppkes
>>
>> Merge commit '7a
On Mon, Nov 14, 2016 at 05:42:51PM +0100, Nicolas George wrote:
[...]
> What about:
>
> struct AVFilterLink {
> ...
> #ifdef FF_INTERNAL_API
> #inclde "avfilterlink_internal.h"
> #endif
>
I'm OK to make an exception for filter links that way if it's really
important for you, but I don't thin
On 14.11.2016 00:01, Luca Barbato wrote:
> On 13/11/2016 19:23, Andreas Cadhalpun wrote:
>> avc->channels can be 0.
>
> 0 and less than zero shouldn't be an error?
Such values should be rejected, wherever they are set.
However, ensuring that is a larger change I'm currently
working on.
Meanwhile,
On 14.11.2016 17:42, Nicolas George wrote:
> What about:
>
> struct AVFilterLink {
> ...
> #ifdef FF_INTERNAL_API
> #inclde "avfilterlink_internal.h"
> #endif
I suspect that having different sizes for the same struct in different
parts of the code base will upset some static analyzers.
(I'm t
2016-10-23 17:18 GMT+02:00 Martin Vignali :
>
>
> 2016-10-23 15:41 GMT+02:00 Moritz Barsnick :
>
>> On Sat, Oct 22, 2016 at 22:06:50 +0200, Martin Vignali wrote:
>> > +This filter export frame metadata @code{lavfi.blackframe.pblack}.
>> ^s
>> > +The value represent the percent
Le quartidi 24 brumaire, an CCXXV, Andreas Cadhalpun a écrit :
> I suspect that having different sizes for the same struct in different
> parts of the code base will upset some static analyzers.
Still, it is completely legal wrt the C standard.
> Consider the (not so) theoretical case of API user
Le quartidi 24 brumaire, an CCXXV, Clement Boesch a écrit :
> I'm OK to make an exception for filter links that way if it's really
> important for you, but I don't think that's a good way of dealing with the
> problem in the rest of the codebase.
Why? The arguments I gave for AVFilterLink apply to
On 14.11.2016 20:54, Anton Khirnov wrote:
> Quoting Andreas Cadhalpun (2016-11-14 20:30:10)
>> On 14.11.2016 00:01, Luca Barbato wrote:
>>> On 13/11/2016 19:23, Andreas Cadhalpun wrote:
avc->channels can be 0.
>>>
>>> 0 and less than zero shouldn't be an error?
>>
>> Such values should be reje
On Mon, Nov 14, 2016 at 9:39 PM, Nicolas George wrote:
> Le quartidi 24 brumaire, an CCXXV, Clement Boesch a écrit :
>> I'm OK to make an exception for filter links that way if it's really
>> important for you, but I don't think that's a good way of dealing with the
>> problem in the rest of the c
On Sun, 23 Oct 2016 17:18:09 +0200, Martin Vignali wrote:
> From b8d7150d4e94fdaa0ed1fa2ac215b03c775f37c6 Mon Sep 17 00:00:00 2001
> From: Martin Vignali
> Date: Sun, 23 Oct 2016 17:16:12 +0200
> Subject: [PATCH] doc/filters : add metadata information for blackframe
>
> ---
> doc/filters.texi |
On 14.11.2016 21:38, Nicolas George wrote:
> Le quartidi 24 brumaire, an CCXXV, Andreas Cadhalpun a écrit :
>> Consider the (not so) theoretical case of API users simply (and wrongly)
>> using the structs on the stack instead of dynamically allocating them.
>>
>> With the internal pointer the inter
On 11/8/2016 1:22 PM, Ronald S. Bultje wrote:
> Also a small cosmetic change to the avx2 idct16 version to make it
> explicit that one of the arguments to the write-out macros is unused
> for >=avx2 (it uses pmovzxbw instead of punpcklbw).
A braindead test (ffmpeg -i 4kHDRsample.webm -benchmark -f
On 14/11/16 00:57, Jun Zhao wrote:
> On 2016/11/11 16:29, Hendrik Leppkes wrote:
>> On Fri, Nov 11, 2016 at 9:09 AM, Jun Zhao wrote:
>>>
>>
>> Do you have a sample file for this case? AFAIK all vc1 files I ever
>> saw worked with the DXVA2 hwaccel before, just want to make sure they
>> are not get
2016-11-14 21:55 GMT+01:00 Andreas Cadhalpun :
>> channels being zero is perfectly valid, it means the caller does not
>> know the channel count and expects the decoder to read it from the
>> bitstream.
>
> In general code this is correct, however if e.g. the matroska demuxer
> reads an audio stre
On 14.11.2016 00:30, Michael Niedermayer wrote:
> On Sun, Nov 13, 2016 at 08:55:01PM +0100, Andreas Cadhalpun wrote:
>> This is similar to commit 9ac61e73d0843ec4b83f4e3d47eded73234e406e.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavutil/softfloat.h | 2 +-
>> 1 file changed, 1 insertion
This patch is a fix for ticket #2833.
Each subtitle segment is its own WebVTT file and has to demuxed individually.
The timing of the subtitles are not perfect but it is the best I could do and
it also does not take into account the X-TIMESTAMP-MAP header in the WebVTT
files which is needed to
On Mon, Nov 14, 2016 at 9:55 PM, Andreas Cadhalpun
wrote:
> On 14.11.2016 20:54, Anton Khirnov wrote:
>> Quoting Andreas Cadhalpun (2016-11-14 20:30:10)
>>> On 14.11.2016 00:01, Luca Barbato wrote:
On 13/11/2016 19:23, Andreas Cadhalpun wrote:
> avc->channels can be 0.
0 and les
On Sun, Nov 13, 2016 at 11:57 AM, Michael Niedermayer
wrote:
> On Sun, Nov 13, 2016 at 10:18:18AM +0100, Michael Niedermayer wrote:
>> On Sat, Nov 12, 2016 at 10:05:22PM -0500, Vittorio Giovara wrote:
>> [...]
>> > So I really do not see a use case for using int64 here.
>>
>> then you can use int3
On Mon, Nov 14, 2016 at 10:31 PM, Mark Thompson wrote:
> On 14/11/16 00:57, Jun Zhao wrote:
>> On 2016/11/11 16:29, Hendrik Leppkes wrote:
>>> On Fri, Nov 11, 2016 at 9:09 AM, Jun Zhao wrote:
>>>
>>> Do you have a sample file for this case? AFAIK all vc1 files I ever
>>> saw worked with the
On Mon, Nov 14, 2016 at 11:15 PM, Hendrik Leppkes wrote:
> On Mon, Nov 14, 2016 at 10:31 PM, Mark Thompson wrote:
>> On 14/11/16 00:57, Jun Zhao wrote:
>>> On 2016/11/11 16:29, Hendrik Leppkes wrote:
On Fri, Nov 11, 2016 at 9:09 AM, Jun Zhao wrote:
>
Do you have a sample file
On 14.11.2016 14:56, Carl Eugen Hoyos wrote:
> I believe attached patch fixes an out-of-bound-read in mov_read_mac_string()
> if p
> Please comment, Carl Eugen
This patch is not necessary, the issue was fixed with commit 437f5daf0.
If (p < end) is false, the 'else if (p < end)' branch will not b
On 14/11/16 21:31, Mark Thompson wrote:
> On 14/11/16 00:57, Jun Zhao wrote:
>> On 2016/11/11 16:29, Hendrik Leppkes wrote:
>>> On Fri, Nov 11, 2016 at 9:09 AM, Jun Zhao wrote:
>>>
>>> Do you have a sample file for this case? AFAIK all vc1 files I ever
>>> saw worked with the DXVA2 hwaccel be
On 14.11.2016 22:59, Carl Eugen Hoyos wrote:
> 2016-11-14 21:55 GMT+01:00 Andreas Cadhalpun
> :
>
>>> channels being zero is perfectly valid, it means the caller does not
>>> know the channel count and expects the decoder to read it from the
>>> bitstream.
>>
>> In general code this is correct, h
On 11/14/2016 7:15 PM, Hendrik Leppkes wrote:
> On Mon, Nov 14, 2016 at 10:31 PM, Mark Thompson wrote:
>> On 14/11/16 00:57, Jun Zhao wrote:
>>> On 2016/11/11 16:29, Hendrik Leppkes wrote:
On Fri, Nov 11, 2016 at 9:09 AM, Jun Zhao wrote:
>
Do you have a sample file for this cas
---
libavformat/mov.c | 23 +--
tests/ref/fate/mov-zombie | 2 +-
tests/ref/fate/rgb24-mkv | 4 ++--
3 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9ec7d03..6176415 100644
--- a/libavformat/mov.c
+++ b/liba
This fixes a heap-buffer-overflow detected by AddressSanitizer.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/mlz.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavcodec/mlz.c b/libavcodec/mlz.c
index a2d1b89..ebce796 100644
--- a/libavcodec/mlz.c
+++ b/libavcodec/mlz.c
@@ -16
---
libavcodec/utils.c | 13 +
tests/api/api-codec-param-test.c | 3 +++
tests/fate/matroska.mak | 2 +-
tests/ref/fate/api-mjpeg-codec-param | 2 +-
tests/ref/fate/api-png-codec-param | 2 +-
tests/ref/fate/mov-zombie| 2 +-
6 file
This fixes the crash reported in ticket #5947.
Signed-off-by: Marton Balint
---
ffplay.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/ffplay.c b/ffplay.c
index 79dc768..12502f2 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -165,6 +165,7 @@ typedef struct Frame {
2016-11-14 23:26 GMT+01:00 Andreas Cadhalpun :
> On 14.11.2016 14:56, Carl Eugen Hoyos wrote:
>> I believe attached patch fixes an out-of-bound-read in mov_read_mac_string()
>> if p>
>> Please comment, Carl Eugen
>
> This patch is not necessary, the issue was fixed with commit 437f5daf0.
> If (p <
Hi!
Attached patch allows GRAY10 encoding, decoding works fine with current
FFmpeg.
Please comment, Carl Eugen
From 5fb552828dc775045ad437065a429a54b4f1e353 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 15 Nov 2016 00:52:30 +0100
Subject: [PATCH] lavc/ffv1enc: Support pix_fmt GRAY1
On Mon, Nov 14, 2016 at 11:47 PM, James Almer wrote:
> On 11/14/2016 7:15 PM, Hendrik Leppkes wrote:
>> On Mon, Nov 14, 2016 at 10:31 PM, Mark Thompson wrote:
>>> On 14/11/16 00:57, Jun Zhao wrote:
On 2016/11/11 16:29, Hendrik Leppkes wrote:
> On Fri, Nov 11, 2016 at 9:09 AM, Jun Zhao w
2016-11-14 23:47 GMT+01:00 James Almer :
> but vc1_sa10143 fails using DXVA2 and a recent driver.
I suspect it actually passes with DXVA2: FFmpeg is not
bit-exact for vc1.
Carl Eugen
Correct output:
0, 0, 0,1, 518400, 0x34fa7f55
0, 1, 1,1,
2016-11-14 23:40 GMT+01:00 Andreas Cadhalpun :
> On 14.11.2016 22:59, Carl Eugen Hoyos wrote:
>> 2016-11-14 21:55 GMT+01:00 Andreas Cadhalpun
>> :
>>
channels being zero is perfectly valid, it means the caller does not
know the channel count and expects the decoder to read it from the
>>
On Tue, Nov 15, 2016 at 1:19 AM, Carl Eugen Hoyos wrote:
> 2016-11-14 23:47 GMT+01:00 James Almer :
>
>> but vc1_sa10143 fails using DXVA2 and a recent driver.
>
> I suspect it actually passes with DXVA2: FFmpeg is not
> bit-exact for vc1.
Looks like you are right, thats the hashes I get as well.
Ping? It's been a couple of weeks since the last comment and patch update.
Can I help move this forward somehow?
Firefox will be shipping experimental support for playback of FLAC in MP4
based on the current spec in Firefox 51.
___
ffmpeg-devel mailing l
On Mon, Nov 14, 2016 at 04:55:36PM -0500, Vittorio Giovara wrote:
> On Sun, Nov 13, 2016 at 11:57 AM, Michael Niedermayer
> wrote:
> > On Sun, Nov 13, 2016 at 10:18:18AM +0100, Michael Niedermayer wrote:
> >> On Sat, Nov 12, 2016 at 10:05:22PM -0500, Vittorio Giovara wrote:
> >> [...]
> >> > So I
On Tue, Nov 15, 2016 at 12:54:11AM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch allows GRAY10 encoding, decoding works fine with current
> FFmpeg.
>
> Please comment, Carl Eugen
> ffv1enc.c |2 ++
> 1 file changed, 2 insertions(+)
> b71c71317d488d0f7e8cd4b820c247c977443080
> 0
On 11/14/2016 10:38 PM, Matthew Gregan wrote:
> Ping? It's been a couple of weeks since the last comment and patch update.
> Can I help move this forward somehow?
>
> Firefox will be shipping experimental support for playback of FLAC in MP4
> based on the current spec in Firefox 51.
CCing Matthie
On Sun, Nov 13, 2016 at 11:24:45PM +0100, Andreas Cadhalpun wrote:
> They are not valid and can cause problems/crashes for API users.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/libschroedingerdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
should be ok
[...]
thx
--
On Sun, Nov 13, 2016 at 11:25:32PM +0100, Andreas Cadhalpun wrote:
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/libschroedingerdec.c | 26 +-
> 1 file changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/libschroedingerdec.c b/libavcodec/libschro
78 matches
Mail list logo
