On 27.06.2015 22:40, Michael Niedermayer wrote:
> On Sat, Jun 27, 2015 at 07:42:48PM +0200, Andreas Cadhalpun wrote:
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavcodec/huffyuvdec.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuv
On 27.06.2015 23:01, Michael Niedermayer wrote:
> On Sat, Jun 27, 2015 at 08:36:15PM +0200, Andreas Cadhalpun wrote:
>> Claiming to have decoded more bytes than the packet size is wrong.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavcodec/wmavoice.c | 4 ++--
>> 1 file changed, 2 insertio
On 27.06.2015 23:27, Paul B Mahol wrote:
> On 6/27/15, Andreas Cadhalpun wrote:
>> get_bits should not be used for more than 25 bits.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavcodec/wavpack.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/w
On 28.06.2015 11:40, Luca Barbato wrote:
> On 28/06/15 11:28, Andreas Cadhalpun wrote:
>>> am i assuming correct that gb was read beyond its end ?
>>
>> That only happens in the second case, not in the first.
>>
>>> if so this maybe should be treated as an error instead of cliping
>>
>> Treating on
On Sat, Jun 27, 2015 at 6:50 PM, Ludmila Glinskih
wrote:
> Location of api-h264-test changed to special directory for api tests.
> ---
> libavformat/Makefile| 1 -
> libavformat/api-h264-test.c | 183
>
> tests/api/Makefile | 1 +
Hi,
On Sun, Jun 28, 2015 at 5:28 AM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> On 27.06.2015 23:01, Michael Niedermayer wrote:
> > On Sat, Jun 27, 2015 at 08:36:15PM +0200, Andreas Cadhalpun wrote:
> >> Claiming to have decoded more bytes than the packet size is wrong.
> >>
>
On 28.06.2015 13:13, Ronald S. Bultje wrote:
> On Sun, Jun 28, 2015 at 5:28 AM, Andreas Cadhalpun
>> Treating one like an error, but not the other seems strange as well.
>> One could add an explode mode for both. Would that be better?
>
>
> In the first case, it's an error. If the frame size is 2
On Sun, Jun 28, 2015 at 11:23:12AM +0200, Andreas Cadhalpun wrote:
> On 27.06.2015 22:40, Michael Niedermayer wrote:
> > On Sat, Jun 27, 2015 at 07:42:48PM +0200, Andreas Cadhalpun wrote:
> >> Signed-off-by: Andreas Cadhalpun
> >> ---
> >> libavcodec/huffyuvdec.c | 6 ++
> >> 1 file changed,
On Sat, Jun 27, 2015 at 10:12:18PM -0300, Claudio Freire wrote:
> LGTM
applied
thanks
>
> On Fri, Jun 26, 2015 at 5:16 PM, Rostislav Pehlivanov
> wrote:
> > -float distortion;
> > -float perceptual_weight;
>
> Those are in fact in disuse. Thought I'd clarify.
> __
On 28.06.2015 14:17, Michael Niedermayer wrote:
> On Sun, Jun 28, 2015 at 11:23:12AM +0200, Andreas Cadhalpun wrote:
>> huffyuvdec.c |5 +
>> 1 file changed, 5 insertions(+)
>> bc13fbe9569565b84fde3c4757c64f3f391a4f9b
>> 0001-huffyuvdec-validate-image-size.patch
>> From b840a905bebfb6549
Hi!
Attached patch fixes ticket #3957 here, the output file plays
fine with WMP and QT.
Please comment, Carl Eugen
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 9efa9fc..09f62d6 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -1313,9 +1313,9 @@ static
On Fri, Jun 26, 2015 at 08:23:36AM +, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/vf_psnr.c | 2 ++
> libavfilter/vf_ssim.c | 2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787
Hi,
As you may already know new asf demuxer hit the tree but did not
replace the old one.
Here I ask for samples which show that one is better than another,
whichever that one is.
Thanks for patience.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.o
On 6/28/15, Michael Niedermayer wrote:
> On Fri, Jun 26, 2015 at 08:23:36AM +, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol
>> ---
>> libavfilter/vf_psnr.c | 2 ++
>> libavfilter/vf_ssim.c | 2 +-
>> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> LGTM
>
> thx
>
> [...]
> --
> Mich
On Sun, Jun 28, 2015 at 01:39:41PM +0200, Andreas Cadhalpun wrote:
> On 28.06.2015 13:13, Ronald S. Bultje wrote:
> > On Sun, Jun 28, 2015 at 5:28 AM, Andreas Cadhalpun
> >> Treating one like an error, but not the other seems strange as well.
> >> One could add an explode mode for both. Would that
Le decadi 10 messidor, an CCXXIII, Paul B Mahol a écrit :
> Can Nicolas comment too?
> I'm not really sure why just 'shortest' is not needed.
I suspect it might be a bug in the options mapping between dualinput and
framesync.
if (s->shortest)
in[0].after = in[1].after = EXT_STOP;
On Sunday 28 June 2015 04:10:48 pm Paul B Mahol wrote:
> Hi,
>
> As you may already know new asf demuxer hit the tree but did not
> replace the old one.
Do you know of a sample that gets fixed by the new demuxer?
I was unable to find one;-(
> Here I ask for samples which show that one is better
On Sun, 28 Jun 2015 16:30:43 +0200
Carl Eugen Hoyos wrote:
> On Sunday 28 June 2015 04:10:48 pm Paul B Mahol wrote:
> > Hi,
> >
> > As you may already know new asf demuxer hit the tree but did not
> > replace the old one.
>
> Do you know of a sample that gets fixed by the new demuxer?
>
> I was
Hi,
> On Jun 27, 2015, at 4:52 PM, Paul B Mahol wrote:
>
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi | 76
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/vf_drawgraph.c | 297 +
On Sunday 28 June 2015 04:32:58 pm wm4 wrote:
> Surely you know, as it has been severe enough that
> you got MiNi to block the new demuxer and not only
> keep the old demuxer, but to leave it as default.
I don't understand this sentence.
(Except for the insult.)
But please allow me to repeat my
Le decadi 10 messidor, an CCXXIII, Carl Eugen Hoyos a écrit :
> But please allow me to repeat my question: Why do
> think the new demuxer should be used? What sample
> does it fix?
Why do you think it should NOT be used?
Regards,
--
Nicolas George
signature.asc
Description: Digital signat
On Sunday 28 June 2015 04:42:30 pm Nicolas George wrote:
> Le decadi 10 messidor, an CCXXIII, Carl Eugen Hoyos a écrit :
> > But please allow me to repeat my question: Why do
> > think the new demuxer should be used? What sample
> > does it fix?
>
> Why do you think it should NOT be used?
The main
On Wed, Jun 24, 2015 at 07:58:15AM -0500, Rodger Combs wrote:
> ---
> libavcodec/adpcm.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1
"Used only on
On Sun, 28 Jun 2015 16:46:12 +0200
Carl Eugen Hoyos wrote:
> On Sunday 28 June 2015 04:42:30 pm Nicolas George wrote:
> > Le decadi 10 messidor, an CCXXIII, Carl Eugen Hoyos a écrit :
> > > But please allow me to repeat my question: Why do
> > > think the new demuxer should be used? What sample
>
Le decadi 10 messidor, an CCXXIII, Carl Eugen Hoyos a écrit :
> From a very quick look, the new code seems mostly
> unreviewed
What makes you say that? Where did you give your "very quick look" exactly?
> Do you disagree?
I do disagree, on several counts. First, the old muxer was based on
rever
On Sunday 28 June 2015 04:51:53 pm wm4 wrote:
> On Sun, 28 Jun 2015 16:46:12 +0200
>
> Carl Eugen Hoyos wrote:
> > On Sunday 28 June 2015 04:42:30 pm Nicolas George wrote:
> > > Le decadi 10 messidor, an CCXXIII, Carl Eugen Hoyos a écrit :
> > > > But please allow me to repeat my question: Why do
On 6/28/15, Dave Rice wrote:
> Hi,
>
>> On Jun 27, 2015, at 4:52 PM, Paul B Mahol wrote:
>>
>> Signed-off-by: Paul B Mahol
>> ---
>> doc/filters.texi | 76
>> libavfilter/Makefile | 1 +
>> libavfilter/allfilters.c | 1 +
>> libavfilter/vf_drawgraph.c | 297
>> ++
On Sunday 28 June 2015 04:54:02 pm Nicolas George wrote:
> Second, someone actually took efforts to do so, I take it as
> a sign that it was considered useful by someone knowing the
> issue better than me.
This argument surprises me (very much)!
Over the last four years, I had a completely diff
On 28.06.2015 16:26, Michael Niedermayer wrote:
> On Sun, Jun 28, 2015 at 01:39:41PM +0200, Andreas Cadhalpun wrote:
>> On 28.06.2015 13:13, Ronald S. Bultje wrote:
>>> On Sun, Jun 28, 2015 at 5:28 AM, Andreas Cadhalpun
Treating one like an error, but not the other seems strange as well.
Le decadi 10 messidor, an CCXXIII, Carl Eugen Hoyos a écrit :
> This argument surprises me (very much)!
> Over the last four years, I had a completely different
> impression.
Shall I understand that, from you point of view, code merged from the libav
side is always bad?
Regards,
--
Nicolas G
On Sunday 28 June 2015 05:14:38 pm Nicolas George wrote:
> Le decadi 10 messidor, an CCXXIII, Carl Eugen Hoyos a écrit :
> > On Sunday 28 June 2015 04:54:02 pm Nicolas George wrote:
> > > Second, someone actually took efforts to do so, I take it as
> > > a sign that it was considered useful by som
On Sun, 28 Jun 2015 17:02:50 +0200
Carl Eugen Hoyos wrote:
> On Sunday 28 June 2015 04:51:53 pm wm4 wrote:
> > On Sun, 28 Jun 2015 16:46:12 +0200
> >
> > Carl Eugen Hoyos wrote:
> > > On Sunday 28 June 2015 04:42:30 pm Nicolas George wrote:
> > > > Le decadi 10 messidor, an CCXXIII, Carl Eugen H
This avoids the need to print such warning in all callers
Signed-off-by: Michael Niedermayer
---
libavutil/dict.c |1 +
1 file changed, 1 insertion(+)
diff --git a/libavutil/dict.c b/libavutil/dict.c
index 6ff1af5..3625f19 100644
--- a/libavutil/dict.c
+++ b/libavutil/dict.c
@@ -131,6 +131,
On 6/28/15, Michael Niedermayer wrote:
> This avoids the need to print such warning in all callers
>
> Signed-off-by: Michael Niedermayer
> ---
> libavutil/dict.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavutil/dict.c b/libavutil/dict.c
> index 6ff1af5..3625f19 100644
> ---
Le decadi 10 messidor, an CCXXIII, Michael Niedermayer a écrit :
> This avoids the need to print such warning in all callers
I believe this is a bad idea: the warning will be duplicated when callers
already include them.
There are low-level APIs that return an error and high-level APIs that print
On Sun, Jun 28, 2015 at 04:54:02PM +0200, Nicolas George wrote:
> Le decadi 10 messidor, an CCXXIII, Carl Eugen Hoyos a écrit :
> > From a very quick look, the new code seems mostly
> > unreviewed
>
> What makes you say that? Where did you give your "very quick look" exactly?
>
> > Do you disagr
On Sun, Jun 28, 2015 at 05:47:51PM +0200, Nicolas George wrote:
> Le decadi 10 messidor, an CCXXIII, Michael Niedermayer a écrit :
> > This avoids the need to print such warning in all callers
>
> I believe this is a bad idea: the warning will be duplicated when callers
> already include them.
we
On 28/06/15 1:21 PM, Michael Niedermayer wrote:
> On Sun, Jun 28, 2015 at 04:54:02PM +0200, Nicolas George wrote:
>> Le decadi 10 messidor, an CCXXIII, Carl Eugen Hoyos a écrit :
>>> From a very quick look, the new code seems mostly
>>> unreviewed
>>
>> What makes you say that? Where did you give
> So I have a more conceptual question, maybe Kieran can help answer this
> also. Why are these tests called api-$codec tests? I don't see anything
> flac/h264 specific in these tests so far, and they could basically be
> reused for any video (h264) or audio (flac) test (for audio: as long as
> the
On Sun, 28 Jun 2015 17:47:51 +0200
Nicolas George wrote:
> Le decadi 10 messidor, an CCXXIII, Michael Niedermayer a écrit :
> > This avoids the need to print such warning in all callers
>
> I believe this is a bad idea: the warning will be duplicated when callers
> already include them.
>
> The
Le decadi 10 messidor, an CCXXIII, Michael Niedermayer a écrit :
> i understand that but taking the burden off the caller to print an
> error for memory allocation failures seemed overall to be the
> correct thing to do in this case
>
> if thats not wanted iam happy to drop this patch, it was just
On Sun, 28 Jun 2015 17:46:48 +0100
Kieran Kunhya wrote:
> > So I have a more conceptual question, maybe Kieran can help answer this
> > also. Why are these tests called api-$codec tests? I don't see anything
> > flac/h264 specific in these tests so far, and they could basically be
> > reused for
On Fri, Jun 26, 2015 at 5:16 PM, Rostislav Pehlivanov
wrote:
> +memset(cpe->ms_mask, 0, sizeof(uint8_t)*128);
sizeof(cpe->ms_mask) would be safer
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Sun, Jun 28, 2015 at 06:54:50PM +0200, Nicolas George wrote:
> Le decadi 10 messidor, an CCXXIII, Michael Niedermayer a écrit :
> > i understand that but taking the burden off the caller to print an
> > error for memory allocation failures seemed overall to be the
> > correct thing to do in this
On Sun, Jun 28, 2015 at 03:07:00PM +, Paul B Mahol wrote:
> On 6/28/15, Dave Rice wrote:
> > Hi,
> >
> >> On Jun 27, 2015, at 4:52 PM, Paul B Mahol wrote:
> >>
> >> Signed-off-by: Paul B Mahol
> >> ---
> >> doc/filters.texi | 76
> >> libavfilter/Makefile | 1 +
Hi Team,
I am using ffmpeg.exe to convert video files from one format to another format.
But due to the encryption algorithms present in ffmpeg.exe this exe cannot be
used in some of the countries.
Hence to remove the crypto and encryption support I am using below command to
configure ffmpeg for
On Sun, Jun 28, 2015, at 02:37 AM, Sanjay Jadhav wrote:
> Hi Team,
>
> I am using ffmpeg.exe to convert video files from one format to another
> format.
> [...]
Please do not send the same message to multiple mailing lists, and
ffmpeg-devel was the wrong place your your question. For mailing list
> On Jun 28, 2015, at 11:07 AM, Paul B Mahol wrote:
>
> On 6/28/15, Dave Rice wrote:
>> Hi,
>>
>>> On Jun 27, 2015, at 4:52 PM, Paul B Mahol wrote:
>>>
>>> Signed-off-by: Paul B Mahol
>>> ---
>>> doc/filters.texi | 76
>>> libavfilter/Makefile | 1 +
>>> libavf
From: Nicolas George
Signed-off-by: Paul B Mahol
---
libavfilter/dualinput.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavfilter/dualinput.c b/libavfilter/dualinput.c
index 45f6810..37535d1 100644
--- a/libavfilter/dualinput.c
+++ b/libavfilter/dualinput.c
@@ -59,
On 6/28/15, Dave Rice wrote:
>
>> On Jun 28, 2015, at 11:07 AM, Paul B Mahol wrote:
>>
>> On 6/28/15, Dave Rice wrote:
>>> Hi,
>>>
On Jun 27, 2015, at 4:52 PM, Paul B Mahol wrote:
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 76
libavf
Le decadi 10 messidor, an CCXXIII, Paul B Mahol a écrit :
> From: Nicolas George
>
>
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/dualinput.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
LGTM if tested, of course. I had no time to test (with the various modes
exposed by over
On Fri, Jun 26, 2015 at 5:16 PM, Rostislav Pehlivanov
wrote:
> This commit adds support for both PNS and IS (intensity stereo) codebooks to
> the encode_window_bands_info() quantizer, used by the faast, faac and anmr
> non-default, native coders. This does not mean that both extensions now work
> On Jun 28, 2015, at 1:54 PM, Paul B Mahol wrote:
>
> On 6/28/15, Dave Rice wrote:
>>
>>> On Jun 28, 2015, at 11:07 AM, Paul B Mahol wrote:
>>>
>>> On 6/28/15, Dave Rice wrote:
Hi,
> On Jun 27, 2015, at 4:52 PM, Paul B Mahol wrote:
>
> Signed-off-by: Paul B Mahol
On 6/28/15, Dave Rice wrote:
>
>> On Jun 28, 2015, at 1:54 PM, Paul B Mahol wrote:
>>
>> On 6/28/15, Dave Rice wrote:
>>>
On Jun 28, 2015, at 11:07 AM, Paul B Mahol wrote:
On 6/28/15, Dave Rice wrote:
> Hi,
>
>> On Jun 27, 2015, at 4:52 PM, Paul B Mahol wrote:
>
On Sun, Jun 28, 2015 at 03:17:46PM -0300, Claudio Freire wrote:
> On Fri, Jun 26, 2015 at 5:16 PM, Rostislav Pehlivanov
> wrote:
> > This commit adds support for both PNS and IS (intensity stereo) codebooks
> > to the encode_window_bands_info() quantizer, used by the faast, faac and
> > anmr non
On Sat, Jun 27, 2015 at 10:36:11PM -0300, Claudio Freire wrote:
> On Fri, Jun 26, 2015 at 5:16 PM, Rostislav Pehlivanov
> wrote:
> > +/* Energy spread threshold value below which no PNS is used, this
> > corresponds to
> > + * typically around 17Khz, after which PNS usage decays ending at 19Khz *
Le decadi 10 messidor, an CCXXIII, Stephan Holljes a écrit :
> Hi,
> attached patches are the current state of work.
> It's probably still a bit rough around the edges, but I think I made
> some progress.
> The sample code in doc/examples does not write any data as of yet, but
> the HTTP handshake
Hi,
On 28.06.2015 16:10, Paul B Mahol wrote:
> As you may already know new asf demuxer hit the tree but did not
> replace the old one.
>
> Here I ask for samples which show that one is better than another,
> whichever that one is.
For starters, the new asf demuxer crashes, where the old one didn
This ensures they are built before the tests are run.
---
tests/api/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/api/Makefile b/tests/api/Makefile
index 86c0cf2..9f82be2 100644
--- a/tests/api/Makefile
+++ b/tests/api/Makefile
@@ -9,7 +9,7 @@ $(APITESTOBJS): |
On Sun, Jun 28, 2015 at 01:50:25AM +0300, Ludmila Glinskih wrote:
> Location of api-h264-test changed to special directory for api tests.
> ---
> libavformat/Makefile| 1 -
> libavformat/api-h264-test.c | 183
>
> tests/api/Makefile
On Sun, 28 Jun 2015 16:51:53 +0200
wm4 wrote:
> The new demuxer was written based on the official ASF spec, and was
> tested against a number of real world samples.
>
i really dont care about the pissing contest in this thread.
if someone wants to bench-test the new demuxer, could someone ask
On Sun, Jun 28, 2015 at 11:47:19PM +0100, George Boyle wrote:
> This ensures they are built before the tests are run.
> ---
> tests/api/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0F
Seems straightforward enough. LGTM.
On Fri, Jun 26, 2015 at 5:16 PM, Rostislav Pehlivanov
wrote:
> This commit adds support for the coding of intensity stereo scalefactor
> indices. It does not do any marking of such bands and as such does no
> functional changes to the encoder. It removes any
63 matches
Mail list logo
