On 25.11.2015 11:56, Tobias Rapp wrote:
When creating a fresh working copy I noticed that the
"doc/examples/pc-uninstalled" folder which is created by ./configure is
not cleaned up when running "make distclean".
Attached patch adds the removal of "doc/examples/pc-uninstalled" folder
to "make dis
On Mon, Nov 30, 2015 at 1:04 PM, Hendrik Leppkes wrote:
> On Mon, Nov 30, 2015 at 4:50 PM, Claudio Freire
> wrote:
>> On Mon, Nov 30, 2015 at 12:27 PM, Rostislav Pehlivanov
>> wrote:
>>> On Sun, 2015-11-29 at 16:54 -0300, Claudio Freire wrote:
Before pushing this, I'd like some feedback,
>
On Sun, Nov 22, 2015 at 9:05 AM, Ganesh Ajjanagadde
wrote:
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavfilter/avf_showcqt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
> index d6e2928..cd90c88 100644
> --- a/
On Mon, Nov 30, 2015 at 12:06 PM, Michael Niedermayer wrote:
> On Mon, Nov 30, 2015 at 07:02:47PM +0100, Nicolas George wrote:
>> Le decadi 10 frimaire, an CCXXIV, Michael Niedermayer a écrit :
>> > > ISO/IEC 9899:TC3
>> > > 5.2.4.2.2 Characteristics of floating types
>> > >
>> > > 8 Exce
On Mon, Nov 30, 2015 at 10:00 AM, Nicolas George wrote:
> Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
>> gcc -c -std=c89 -O2
>
> gcc -S would have been more useful: as is, it lacks the definition for
> basefreq, and apparently also the other constant.
>
The strange behaviour is that
On Sun, Nov 29, 2015 at 6:03 PM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi | 61 +
> libavfilter/Makefile | 1 +
> libavfilter/af_agate.c | 170
> ++-
> libavfilter/allfilters.c | 1 +
2015-11-30 3:26 GMT-05:00 Paul B Mahol :
> On 11/22/15, Ganesh Ajjanagadde wrote:
>> Signed-off-by: Ganesh Ajjanagadde
>> ---
>> libavfilter/af_compand.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavfilter/af_compand.c b/libavfilter/af_compand.c
>> index 3
On Mon, Nov 30, 2015 at 9:35 AM, Ganesh Ajjanagadde wrote:
> On Mon, Nov 30, 2015 at 6:39 AM, wm4 wrote:
>> On Sun, 29 Nov 2015 20:40:11 -0500
>> Ganesh Ajjanagadde wrote:
>>
>>> The table in question is a 253 byte one. In fact, it turns out that
>>> dynamic generation of the table results in an
On Mon, 30 Nov 2015 19:53:41 +
Aaron Colwell wrote:
> On Mon, Nov 30, 2015 at 10:57 AM wm4 wrote:
>
> > On Mon, 30 Nov 2015 18:31:56 +
> > Aaron Colwell wrote:
> >
> > > Hi,
> > > Can I get a review for this please? It has been a week since I sent out
> > > this patch and I haven't g
---
libavformat/mpegtsenc.c | 65 ++---
1 file changed, 35 insertions(+), 30 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 468bad4..a8fb3a2 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -698,7
---
libavformat/internal.h | 11 +++
libavformat/utils.c| 19 +++
2 files changed, 30 insertions(+)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 5ed548e..dcd2971 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -467,6 +467,17 @@
---
libavformat/matroskaenc.c | 43 +++
1 file changed, 35 insertions(+), 8 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 10cf0a0..85e5d82 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -845
This solves the problem discussed in
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179238.html
by allowing AVCodec::write_header to be delayed until after packets have been
run through required bitstream filters in order to generate global extradata.
It also provides a mechanism by whi
---
libavformat/tee.c | 44 +++-
1 file changed, 3 insertions(+), 41 deletions(-)
diff --git a/libavformat/tee.c b/libavformat/tee.c
index af52a49..8c54d32 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -405,45 +405,6 @@ fail:
return ret;
}
---
ffmpeg.c | 46 --
ffmpeg.h | 1 -
ffmpeg_opt.c | 6 +-
3 files changed, 9 insertions(+), 44 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index bf5e983..c24c8ed 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -683,47 +683,10 @@ static void wri
---
libavformat/avformat.h | 11 +++
libavformat/utils.c| 49 +
2 files changed, 60 insertions(+)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 36f9d02..d94191e 100644
--- a/libavformat/avformat.h
+++ b/libavformat/a
On Mon, Nov 30, 2015 at 3:31 PM, Reynaldo H. Verdejo Pinochet
wrote:
> This one looks OK (pending a final decision on
> av_clipd64())
I don't think any decision needs to be made, i.e it has passed review.
The problem is that it is currently locked in avutil/internal and
needs to be exposed in som
On Mon, Nov 30, 2015 at 09:17:26AM -0600, Will Kelleher wrote:
> On 11/26, Michael Niedermayer wrote:
> >
> > I tried to apply this but it seems to doesnt apply cleanly anymore
> > id fix the conflicts and apply but i cant test this so i think its
> > better if you would fix it
> >
>
> Here is a
From: Chris Cunningham
"Fast seek" uses linear interpolation to find the position of the
requested seek time. For CBR this is more direct than using the
mp3 TOC and bypassing the TOC avoids problems with TOC precision.
(see https://crbug.com/545914#c13)
For VBR, fast seek is not precise, so cont
Looks like I messed up the tab for "return best_pos;"... fix incoming.
On Mon, Nov 30, 2015 at 2:10 PM, wrote:
> From: Chris Cunningham
>
> "Fast seek" uses linear interpolation to find the position of the
> requested seek time. For CBR this is more direct than using the
> mp3 TOC and bypassing
On Sun, Nov 29, 2015 at 5:21 PM, Nicolas George wrote:
> Instead of calling the input filter request_frame() method,
> ff_request_frame() now marks the link and returns immediately.
> bufferskin is changed to activate the marked filters until
> a frame is obtained.
>
> Signed-off-by: Nicolas Georg
On Sun, Nov 29, 2015 at 05:21:52PM +0100, Nicolas George wrote:
> Instead of calling the input filter request_frame() method,
> ff_request_frame() now marks the link and returns immediately.
> bufferskin is changed to activate the marked filters until
sink
didnt review the rest (migh
From: Chris Cunningham
"Fast seek" uses linear interpolation to find the position of the
requested seek time. For CBR this is more direct than using the
mp3 TOC and bypassing the TOC avoids problems with TOC precision.
(see https://crbug.com/545914#c13)
For VBR, fast seek is not precise, so cont
On Sun, Nov 29, 2015 at 05:21:51PM +0100, Nicolas George wrote:
> The status field can carry any error code instead of just EOF.
> Also only update it through a wrapper function and provide a timestamp.
> Update the few filters that used it directly.
>
> Signed-off-by: Nicolas George
> ---
> lib
(Fixed CCs)
Thanks for review. Patch coming shortly.
On Thu, Nov 26, 2015 at 10:13 AM, wm4 wrote:
> On Tue, 24 Nov 2015 16:55:03 -0800
> chcunning...@chromium.org wrote:
>
> > From: Chris Cunningham
> >
> > "Fast seek" uses linear interpolation to find the position of the
> > requested seek ti
On Sun, Nov 29, 2015 at 05:21:50PM +0100, Nicolas George wrote:
> Applications are not supposed to mess with links,
> they should close the sinks.
> Furthermore, this function does not distinguish what end
> of the link caused the close and does not have a timestamp.
>
> Signed-off-by: Nicolas Geo
On Sun, Nov 29, 2015 at 05:21:49PM +0100, Nicolas George wrote:
> Signed-off-by: Nicolas George
> ---
> libavfilter/avfilter.c | 2 ++
> libavfilter/avfilter.h | 6 ++
> 2 files changed, 8 insertions(+)
id say, the addition makes sense, exact timebases are better when
they are possible
thx
On Sun, Nov 29, 2015 at 01:36:48PM +0100, Nicolas George wrote:
> It is no longer needed since looping is not necessary.
>
> Signed-off-by: Nicolas George
> ---
> libavfilter/vf_mpdecimate.c | 14 --
> 1 file changed, 14 deletions(-)
>
>
> Passes the FATE test (the one that is brok
On Sun, Nov 29, 2015 at 05:21:48PM +0100, Nicolas George wrote:
> This field is used for fast comparison between link ages,
> it is in AV_TIME_BASE units, in other words microseconds,
> µs =~ us.
> Renaming it allows a second field in link time base units.
>
> Signed-off-by: Nicolas George
> ---
On Mon, Nov 30, 2015 at 01:18:21AM +0100, Carl Eugen Hoyos wrote:
> On Saturday 28 November 2015 02:32:37 am Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Jpeg over rtp requires standard huffman tables, but the test I implemented
> > was too strict. Attached patch tries to improve this, related to ticket
On Mon, Nov 30, 2015 at 12:46:25PM -0800, Reynaldo H. Verdejo Pinochet wrote:
>
>
> On 11/01/2015 09:34 AM, Michael Niedermayer wrote:
> > [...]
> > --- a/ffserver.c
> > +++ b/ffserver.c
> > @@ -2366,6 +2366,7 @@ static int http_prepare_data(HTTPContext *c)
> >
> > av_freep
---
I'm not quite sure if this fix is 100% correct, but it works here.
The problem is that FF_DEP_LIBS points to the .dll files, but you can't link to
the .dll files,
you need to point to the import libraries. Unfortunately there is no variable
which simply
holds all import libraries - but they
On Fri, Nov 27, 2015 at 07:16:10PM +0100, Nicolas George wrote:
> Signed-off-by: Nicolas George
> ---
> libavformat/mpegts.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> Untested. Offending commit was:
ok (based on what the commit message said)
[...]
--
Michael GnuPG fin
On Mon, Nov 30, 2015 at 2:20 PM, Rostislav Pehlivanov
wrote:
> On Mon, 2015-11-30 at 12:50 -0300, Claudio Freire wrote:
>> Also I don't see how a static var would help or even be correct here.
>> Perhaps you meant something else?
> static uint8_t cond1 = param1 && param2;
> static uint8_t cond2 =
On Mon, Nov 30, 2015 at 8:21 AM, Nicolas Derouineau
wrote:
> Hello
>
>>you should look at avframesidedata
>
> Actually the issue is that the green metadatadata are concerning the upcoming
> frame (They are used to predict the upcoming complexity).
>
> The avframesidedata are concerning a frame wh
On 11/01/2015 09:34 AM, Michael Niedermayer wrote:
> [...]
> --- a/ffserver.c
> +++ b/ffserver.c
> @@ -2366,6 +2366,7 @@ static int http_prepare_data(HTTPContext *c)
>
> av_freep(&c->pb_buffer);
> len = avio_close_dyn_buf(ctx->pb, &c->pb_buffer);
> +
On Fri, Nov 27, 2015 at 07:16:08PM +0100, Nicolas George wrote:
> Signed-off-by: Nicolas George
> ---
> libavformat/mpeg.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> Problem can be observed with files containing large portions of junk, for
> example:
>
> { ffmpeg -lavfi test
This one looks OK (pending a final decision on
av_clipd64())
Bests,
--
Reynaldo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Mon, Nov 30, 2015 at 07:02:47PM +0100, Nicolas George wrote:
> Le decadi 10 frimaire, an CCXXIV, Michael Niedermayer a écrit :
> > > ISO/IEC 9899:TC3
> > > 5.2.4.2.2 Characteristics of floating types
> > >
> > > 8 Except for assignment and cast (which remove all extra range and
> > >
On Mon, Nov 30, 2015 at 10:57 AM wm4 wrote:
> On Mon, 30 Nov 2015 18:31:56 +
> Aaron Colwell wrote:
>
> > Hi,
> > Can I get a review for this please? It has been a week since I sent out
> > this patch and I haven't gotten any real feedback about the changes. I've
> > attached a new copy that
On Mon, 30 Nov 2015 18:31:56 +
Aaron Colwell wrote:
> Hi,
> Can I get a review for this please? It has been a week since I sent out
> this patch and I haven't gotten any real feedback about the changes. I've
> attached a new copy that has been rebased to HEAD. If I need to be doing
> somethin
Le decadi 10 frimaire, an CCXXIV, Michael Niedermayer a écrit :
> > ISO/IEC 9899:TC3
> > 5.2.4.2.2 Characteristics of floating types
> >
> > 8 Except for assignment and cast (which remove all extra range and
> > precision), the values
> > of operations with floating operands and valu
Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
> gcc -c -std=c89 -O2
gcc -S would have been more useful: as is, it lacks the definition for
basefreq, and apparently also the other constant.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
__
On Mon, Nov 30, 2015 at 06:25:15PM +0100, Michael Niedermayer wrote:
> On Mon, Nov 30, 2015 at 04:52:20PM +0100, Nicolas George wrote:
> > Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
> > > -if (s->basefreq != BASEFREQ || s->endfreq != ENDFREQ) {
> > > +if (s->basefreq != (doub
From: Clément Bœsch
---
tests/api/Makefile | 1 +
tests/api/api-threadmessage-test.c | 202 +
tests/fate/api.mak | 6 ++
3 files changed, 209 insertions(+)
create mode 100644 tests/api/api-threadmessage-test.c
diff --git a
From: Clément Bœsch
---
libavutil/threadmessage.c | 37 ++---
libavutil/threadmessage.h | 21 ++---
2 files changed, 52 insertions(+), 6 deletions(-)
diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c
index b7fcbe2..87ce8dc 100644
So I've been playing with threadmessage a bit. Since I'm trying to extend the
API for (currently) external usage, I'm also adding an API test.
I've been triggering deadlocks thoughm, typically by setting queue_size=1. I
haven't investigated but I think the issue lies in the fact that there is a
si
On Mon, Nov 30, 2015 at 04:52:20PM +0100, Nicolas George wrote:
> Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
> > -if (s->basefreq != BASEFREQ || s->endfreq != ENDFREQ) {
> > +if (s->basefreq != (double) BASEFREQ || s->endfreq != (double)
> > ENDFREQ) {
>
> Looks wrong to me
On Mon, 2015-11-30 at 12:50 -0300, Claudio Freire wrote:
> Also I don't see how a static var would help or even be correct here.
> Perhaps you meant something else?
static uint8_t cond1 = param1 && param2;
static uint8_t cond2 = param3 && !param4;
...etc
return cond1 && cond2;
_
On Mon, Nov 30, 2015 at 11:09 PM, Nicolas George wrote:
> Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
>> double basefreq = BASEFREQ, endfreq = ENDFREQ;
>> if (basefreq == BASEFREQ && endfreq == ENDFREQ)
>> printf("equal\n");
>> else
>> printf("inequal\n");
>>
>> I try with gc
On Mon, Nov 30, 2015 at 1:04 PM, Hendrik Leppkes wrote:
> On Mon, Nov 30, 2015 at 4:50 PM, Claudio Freire
> wrote:
>> On Mon, Nov 30, 2015 at 12:27 PM, Rostislav Pehlivanov
>> wrote:
>>> On Sun, 2015-11-29 at 16:54 -0300, Claudio Freire wrote:
Before pushing this, I'd like some feedback,
>
Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
> double basefreq = BASEFREQ, endfreq = ENDFREQ;
> if (basefreq == BASEFREQ && endfreq == ENDFREQ)
> printf("equal\n");
> else
> printf("inequal\n");
>
> I try with gcc -std=c89 / -std=c99 on mingw 32-bit
> the result is inequal.
T
On Mon, Nov 30, 2015 at 10:52 PM, Nicolas George wrote:
> Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
>> -if (s->basefreq != BASEFREQ || s->endfreq != ENDFREQ) {
>> +if (s->basefreq != (double) BASEFREQ || s->endfreq != (double) ENDFREQ)
>> {
>
> Looks wrong to me. Since s->
On Mon, Nov 30, 2015 at 4:50 PM, Claudio Freire wrote:
> On Mon, Nov 30, 2015 at 12:27 PM, Rostislav Pehlivanov
> wrote:
>> On Sun, 2015-11-29 at 16:54 -0300, Claudio Freire wrote:
>>> Before pushing this, I'd like some feedback,
>>> especially about
>>> the implementation of point 3. I'm not sur
Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
> -if (s->basefreq != BASEFREQ || s->endfreq != ENDFREQ) {
> +if (s->basefreq != (double) BASEFREQ || s->endfreq != (double) ENDFREQ) {
Looks wrong to me. Since s->basefreq is double and operands are always
converted to the largest
On Mon, Nov 30, 2015 at 12:27 PM, Rostislav Pehlivanov
wrote:
> On Sun, 2015-11-29 at 16:54 -0300, Claudio Freire wrote:
>> Before pushing this, I'd like some feedback,
>> especially about
>> the implementation of point 3. I'm not sure the AAC encoder
>> setting the cutoff in the encoder context l
fix default basefreq/endfreq comparison
on platform that does not do comparison
in double type
found on zeranoe 32-bit build, where
default freq range is detected as non-default
patch attached
From 26d93c48b7c89849bfd962fbc66069c24f11e752 Mon Sep 17 00:00:00 2001
From: Muhammad Faiz
Date: Mon, 3
On Mon, Nov 30, 2015 at 4:25 PM, Will Kelleher wrote:
> On 11/29, Hendrik Leppkes wrote:
>>
>> These options were added in a merge from Libav, no further action
>> seems to be required.
>>
> Oh, good!
>
> I should probably note for the record that these toggles don't always/ever
> work.
> I was t
On 11/30/15 10:24 AM, Nicolas George wrote:
Le decadi 10 frimaire, an CCXXIV, Alexander Agranovsky a écrit :
Without getting into a religious debate
This is the reason I gave practical argument.
As pointed later in the thread, lu is used elsewhere. And yes, MS makes it
interesting in this c
On Sun, 2015-11-29 at 16:54 -0300, Claudio Freire wrote:
> Before pushing this, I'd like some feedback,
> especially about
> the implementation of point 3. I'm not sure the AAC encoder
> setting the cutoff in the encoder context like this is legal or
> desirable.
I think setting the cutoff is neces
On 11/29, Hendrik Leppkes wrote:
>
> These options were added in a merge from Libav, no further action
> seems to be required.
>
Oh, good!
I should probably note for the record that these toggles don't always/ever work.
I was testing on Ivy Bridge hardware and the toggles are "accepted" by the A
Le decadi 10 frimaire, an CCXXIV, Alexander Agranovsky a écrit :
> Without getting into a religious debate
This is the reason I gave practical argument.
> As pointed later in the thread, lu is used elsewhere. And yes, MS makes it
> interesting in this case.
wm4 explained that point. Really, long
On 11/26, Michael Niedermayer wrote:
>
> I tried to apply this but it seems to doesnt apply cleanly anymore
> id fix the conflicts and apply but i cant test this so i think its
> better if you would fix it
>
Here is a rebased version.
will
>From 5452911c08cdb8cebe861d38a9c1b12924120d78 Mon Sep
On Mon, Nov 30, 2015 at 6:39 AM, wm4 wrote:
> On Sun, 29 Nov 2015 20:40:11 -0500
> Ganesh Ajjanagadde wrote:
>
>> The table in question is a 253 byte one. In fact, it turns out that
>> dynamic generation of the table results in an increased binary size.
>>
>> Code compiled with GCC 5.2.0, x86-64
On 11/30/15 7:34 AM, wm4 wrote:
On Mon, 30 Nov 2015 07:27:14 -0500
Alexander Agranovsky wrote:
On 11/30/15 2:41 AM, Nicolas George wrote:
Le nonidi 9 frimaire, an CCXXIV, Alexander Agranovsky a écrit :
Please see the updated patches attached. The trimming loop that was subject
of the discu
Hello
>you should look at avframesidedata
Actually the issue is that the green metadatadata are concerning the upcoming
frame (They are used to predict the upcoming complexity).
The avframesidedata are concerning a frame which is already decoded (so it's
not useful in the case of greenmetadata
On Mon, Nov 30, 2015 at 10:03:58AM +0100, wm4 wrote:
> The heuristic for enabling it is not very reliable. Even if always
> parsing should cause problems in some cases, it would be better to
> fix the parser instead. (But no bad samples are known to me.)
heres one sample:
https://dl.dropboxusercon
On 11/30/15 7:34 AM, wm4 wrote:
On Mon, 30 Nov 2015 07:27:14 -0500
Alexander Agranovsky wrote:
On 11/30/15 2:41 AM, Nicolas George wrote:
Le nonidi 9 frimaire, an CCXXIV, Alexander Agranovsky a écrit :
Please see the updated patches attached. The trimming loop that was subject
of the discu
On 11/30/15 6:37 AM, wm4 wrote:
On Mon, 30 Nov 2015 08:41:42 +0100
Nicolas George wrote:
+"Expected boundary '%s' not found, instead found a line of %lu
bytes\n",
+expected_boundary,
+strlen(line));
"%lu" is not correct for size_t. The correc
On Mon, 30 Nov 2015 07:27:14 -0500
Alexander Agranovsky wrote:
> On 11/30/15 2:41 AM, Nicolas George wrote:
> > Le nonidi 9 frimaire, an CCXXIV, Alexander Agranovsky a écrit :
> >> Please see the updated patches attached. The trimming loop that was subject
> >> of the discussion had been rewrit
> -Ursprüngliche Nachricht-
> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
> von Sven Dueking
> Gesendet: Montag, 30. November 2015 11:06
> An: 'FFmpeg development discussions and patches'
> Betreff: Re: [FFmpeg-devel] [PATCH] making qsv session routines private
>
On 11/30/15 2:41 AM, Nicolas George wrote:
Le nonidi 9 frimaire, an CCXXIV, Alexander Agranovsky a écrit :
Please see the updated patches attached. The trimming loop that was subject
of the discussion had been rewritten to use indices rather than pointer
arithmetics.
This kind of drastic chan
On Sun, 29 Nov 2015 20:40:11 -0500
Ganesh Ajjanagadde wrote:
> The table in question is a 253 byte one. In fact, it turns out that
> dynamic generation of the table results in an increased binary size.
>
> Code compiled with GCC 5.2.0, x86-64 (size in bytes), before and after
> patch:
> old: 623
On Mon, 30 Nov 2015 08:41:42 +0100
Nicolas George wrote:
> > +"Expected boundary '%s' not found, instead found a line of
> > %lu bytes\n",
> > +expected_boundary,
> > +strlen(line));
>
> "%lu" is not correct for size_t. The correct type would be
On Monday 30 November 2015 03:58:16 am James Almer wrote:
> One could argue no releases have been made since the last major bump, so
But given that releases get not much support, this is not a valid argument.
> breakages like this are unlikely to affect anyone. But then again, it's
> been months
> -Ursprüngliche Nachricht-
> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
> von Hendrik Leppkes
> Gesendet: Montag, 30. November 2015 10:56
> An: FFmpeg development discussions and patches
> Betreff: Re: [FFmpeg-devel] [PATCH] making qsv session routines private
On Mon, Nov 30, 2015 at 10:45 AM, Sven Dueking wrote:
> Hi all,
>
> This is a follow up patch according to the discussion of
>
> [FFmpeg-devel] [PATCH] qsv.c: making qsv session routines
>
> Hopefully this is the correct way to share internal functions between codecs
> and filters.
> At least othe
Hi all,
This is a follow up patch according to the discussion of
[FFmpeg-devel] [PATCH] qsv.c: making qsv session routines
Hopefully this is the correct way to share internal functions between codecs
and filters.
At least other filters seems to do it this way ...
Thanks,
Sven
0001-make-qsv
The heuristic for enabling it is not very reliable. Even if always
parsing should cause problems in some cases, it would be better to
fix the parser instead. (But no bad samples are known to me.)
Fixes trac 5047
---
libavformat/mov.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
On Sun, 29 Nov 2015 23:58:16 -0300
James Almer wrote:
> On 11/29/2015 11:45 PM, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sun, Nov 29, 2015 at 9:41 PM, Ganesh Ajjanagadde
> > wrote:
> >
> >> There was no reason AFAIK for making AV_CRC_24_IEEE 12. This simply
> >> resulted in wasted space un
On 11/22/15, Ganesh Ajjanagadde wrote:
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavfilter/af_compand.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/af_compand.c b/libavfilter/af_compand.c
> index 3848d67..a64778e 100644
> --- a/libavfilter/af_comp
81 matches
Mail list logo
