On Mon, Aug 18, 2014 at 10:44:03AM +0800, Andre Wolokita wrote:
> Fixed parentheses mismatch.
>
> Signed-off-by: Andre Wolokita ---
> libavdevice/v4l2.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied
with the previous patches "commit message", as that was more verbose
Thank
Hi,
2014-08-17 23:53 GMT+02:00 Michael Niedermayer :
>> > i think these need a check for top >= s->screen_height and
>> > left >= s->screen_width
[...]
> 0x007319ea in gif_fill_rect (picture=0x1a96a60, color=16777215, l=0,
> t=65535, w=192, h=-65367) at libavcodec/gifdec.c:108
Sorry for
On Mon, Aug 18, 2014 at 03:14:01AM -0300, James Almer wrote:
> Fixes ticket #3862.
> As a side effect, this also fixes aac_latm in wav.
>
> Signed-off-by: James Almer
applied
> ---
> Maybe a check for channels <= 0 should be also added to ff_get_wav_header()
> right after the sample_rate one?
Hi,
here's the new version of the patch. Sorry for the delay.
James, I have not done 8-bit AVX versions because it requires unpacks that are
done differently in AVX.
Thanks for the feedback !
-Pierre-Edouard Leperecommit 414ebcfeb47ea99ac7e8281d2794996d8a2a09fc
Author: plepere
Date: Wed Jul
Hi,
2014-08-17 19:09 GMT+02:00 Christophe Gisquet :
> It would possible to detect bitstreams before this change and achieve
> correct decoding if need be.
So after further exploration, you can't really detect this:
- there's no metadata for the alac bitstream
- the container one may be stripped o
On Mon, Aug 18, 2014 at 09:42:08AM +0200, Christophe Gisquet wrote:
> Hi,
>
> 2014-08-17 23:53 GMT+02:00 Michael Niedermayer :
> >> > i think these need a check for top >= s->screen_height and
> >> > left >= s->screen_width
> [...]
> > 0x007319ea in gif_fill_rect (picture=0x1a96a60, color=
Hi,
Ticket #3846 is about an incorrect profile being used:
- The user wants alpha but the profile indicates to software there's no alpha
- Also, the encoder still encodes the alpha channel in spite of the profile
The attached patch is not the most user-friendly, but is preferred by
the encoder au
On Sun, Aug 17, 2014 at 9:29 PM, Nicolas George wrote:
> Le decadi 30 thermidor, an CCXXII, Micah Galizia a écrit :
>> When new cookie values (with the same name as an existing cookie) are
>> returned in an HLS stream, the current implementation will append the
>> new cookie to the list of cookies
On Mon, Aug 18, 2014 at 07:59:11PM +1000, Micah Galizia wrote:
> On Sun, Aug 17, 2014 at 9:29 PM, Nicolas George wrote:
> > Le decadi 30 thermidor, an CCXXII, Micah Galizia a écrit :
> >> When new cookie values (with the same name as an existing cookie) are
> >> returned in an HLS stream, the curr
On date Sunday 2014-08-17 20:08:35 +0200, Clément Bœsch encoded:
[...]
> From 76f24f87bdfe1ca8778a6d39751fd70246c3b093 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Cl=C3=A9ment=20B=C5=93sch?=
> Date: Wed, 16 Jul 2014 16:42:42 +0200
> Subject: [PATCH] avcodec: export motion vectors in frame side data
On date Sunday 2014-08-17 19:04:35 -0400, compn encoded:
> libav brought up the point again that it doesnt like libmpcodecs.
That is, they will reunite if we drop mp? Or is that one of the
conditional requirements?
> is there anyone using the remaining libmpcodecs filters ?
> most of the filters
On Sat, 16 Aug 2014, Thomas Goirand wrote:
> Yes, the Linux kernel is a successful project. Does this mean using a
> list for reviewing patches is a good thing? No! The workflow with a list
> is simply horrible. Using git-review and gerrit is so much better.
Strong NAK here.
First: it breaks th
Le primidi 1er fructidor, an CCXXII, Micah Galizia a écrit :
> Yes & no. I agree its not an ideal implementation (it actually was
> mine to begin with) to just use a string full of cookies. But we can't
> pass around complex structures through avopts, which is where we would
> really see the benefi
Le primidi 1er fructidor, an CCXXII, Stefano Sabatini a écrit :
> That is, they will reunite if we drop mp?
And accept the features in FFmpeg that they have disparagingly called hacks?
I would not bet on that.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
_
Hi Thomas,
On 18.08.2014 08:36, Thomas Goirand wrote:
There's been a very well commented technical reason stated here: the
release team don't want to deal with 2 of the same library that are
doing (nearly) the same things, with potentially the same security
issues that we'd have to fix twice rat
Christophe Gisquet gmail.com> writes:
> An alternative would be to select the profile based on
> the pixel format.
What would be the disadvantage in this case?
> If a user wants to encode without alpha, he would then
> need to change the pixel format as well as specify the
> proper profile,
Le primidi 1er fructidor, an CCXXII, Thomas Goirand a écrit :
> The problem was enforcing patch review policies.
No, it never was.
> There's been a very well commented technical reason stated here: the
> release team don't want to deal with 2 of the same library that are
> doing (nearly) the same
Andre Wolokita analog.com> writes:
> -if (ret == AVERROR(EINVAL)) {
> +if (ret == AVERROR(EINVAL) || ret == AVERROR(ENODATA)) {
If I read fate correctly this broke compilation
on OpenBSD where ENODATA isn't defined.
Carl Eugen
___
ffmpeg-dev
Ivan Kalvachev gmail.com> writes:
> softpulldown - turns soft into hard telecine.
Do you remember how this filter was used with MEncoder?
I have a suspicion that it cannot work with FFmpeg.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg
On Mon, Aug 18, 2014 at 11:42:15AM +, Carl Eugen Hoyos wrote:
> Andre Wolokita analog.com> writes:
>
> > -if (ret == AVERROR(EINVAL)) {
> > +if (ret == AVERROR(EINVAL) || ret == AVERROR(ENODATA)) {
>
> If I read fate correctly this broke compilation
> on OpenBSD where ENODATA isn't
On Mon, Aug 18, 2014 at 02:04:48PM +0200, Michael Niedermayer wrote:
> On Mon, Aug 18, 2014 at 11:42:15AM +, Carl Eugen Hoyos wrote:
> > Andre Wolokita analog.com> writes:
> >
> > > -if (ret == AVERROR(EINVAL)) {
> > > +if (ret == AVERROR(EINVAL) || ret == AVERROR(ENODATA)) {
> >
> >
On 07.08.2014 15:36, Michael Niedermayer wrote:
On Thu, Aug 07, 2014 at 01:58:55AM +0200, Lukasz Marek wrote:
PulseAudio expilitly requires name of the source.
This patch makes it use default source when not provided.
It simplifies programistic use.
Signed-off-by: Lukasz Marek
---
libavdevic
On Mon, Aug 18, 2014 at 01:27:05PM +0200, Stefano Sabatini wrote:
> On date Sunday 2014-08-17 20:08:35 +0200, Clément Bœsch encoded:
> [...]
> > From 76f24f87bdfe1ca8778a6d39751fd70246c3b093 Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?Cl=C3=A9ment=20B=C5=93sch?=
> > Date: Wed, 16 Jul 2014 16:42:4
Andreas Cadhalpun schrieb:
> Hi Thomas,
>
> On 18.08.2014 08:36, Thomas Goirand wrote:
>> There's been a very well commented technical reason stated here: the
>> release team don't want to deal with 2 of the same library that are
>> doing (nearly) the same things, with potentially the same securit
On 8/18/14, Carl Eugen Hoyos wrote:
> Ivan Kalvachev gmail.com> writes:
>
>> softpulldown - turns soft into hard telecine.
>
> Do you remember how this filter was used with MEncoder?
> I have a suspicion that it cannot work with FFmpeg.
I have written about it before:
On 5/4/13, Ivan Kalvachev
---
libavfilter/af_apad.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/libavfilter/af_apad.c b/libavfilter/af_apad.c
index 15ba8c4..c58cacf 100644
--- a/libavfilter/af_apad.c
+++ b/libavfilter/af_apad.c
@@ -39,8 +39,8 @@ typedef struct {
---
doc/filters.texi | 47 +--
1 file changed, 45 insertions(+), 2 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 0ca1d6f..44eecca 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -742,8 +742,51 @@ Pass the audio source uncha
Hi,
2014-06-19 6:23 GMT+02:00 Michael Niedermayer :
> patch applied
Am I missing something or was it not applied?
--
Christophe
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 18 August 2014 02:26, Ivan Kalvachev wrote:
> ilpack - interlaced yuv420-> yuv422 converter. Scale should be able to
> do that too.
Scale doesn't have much (any?) knowledge of interlaced chroma.
That said I could probably port this filter to lavfi because it would
be quite useful to me. I was
Hi Moritz,
On 18.08.2014 14:05, Moritz Mühlenhoff wrote:
Andreas Cadhalpun schrieb:
On 18.08.2014 08:36, Thomas Goirand wrote:
There's been a very well commented technical reason stated here: the
release team don't want to deal with 2 of the same library that are
doing (nearly) the same thing
On 8/18/14, Kieran Kunhya wrote:
> On 18 August 2014 02:26, Ivan Kalvachev wrote:
>
>> ilpack - interlaced yuv420-> yuv422 converter. Scale should be able to
>> do that too.
>
> Scale doesn't have much (any?) knowledge of interlaced chroma.
> That said I could probably port this filter to lavfi b
On 18 August 2014 14:37, Ivan Kalvachev wrote:
> On 8/18/14, Kieran Kunhya wrote:
>> On 18 August 2014 02:26, Ivan Kalvachev wrote:
>>
>>> ilpack - interlaced yuv420-> yuv422 converter. Scale should be able to
>>> do that too.
>>
>> Scale doesn't have much (any?) knowledge of interlaced chroma.
Hi,
On Mon, Aug 18, 2014 at 9:48 AM, Kieran Kunhya wrote:
> On 18 August 2014 14:37, Ivan Kalvachev wrote:
> > On 8/18/14, Kieran Kunhya wrote:
> >> On 18 August 2014 02:26, Ivan Kalvachev wrote:
> >>
> >>> ilpack - interlaced yuv420-> yuv422 converter. Scale should be able to
> >>> do that t
> How is it different? If you're interlacing-aware and call swscale_convert()
> twice (once for each field, double stride each, alternate offset for second
> call), isn't that the same?
That would be true in the 422 domain, yes. In 420, the chroma planes
are offset and this has to be taken into ac
Hi,
this is a proposal to allow decoding incorrect files. There is no
obvious and systematic way to detect them however.
--
Christophe
From feaacb09d8660b7e8784ad4a550dda455f172e24 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Mon, 18 Aug 2014 09:53:20 +0200
Subject: [PATCH] alac: add
2014-08-18 15:59 GMT+02:00 Christophe Gisquet :
> this is a proposal to allow decoding incorrect files. There is no
> obvious and systematic way to detect them however.
Ignore the version.h stray change in your review, I thought I had removed it.
--
Christophe
___
On 8/18/14, Christophe Gisquet wrote:
> Hi,
>
> this is a proposal to allow decoding incorrect files. There is no
> obvious and systematic way to detect them however.
>
> --
> Christophe
>
AFAIK it is missing AVClass *class in codec context.
___
ffmpeg-
On 2014-08-18 14:53, Stefano Sabatini wrote:
> +@item whole_len
> +Set the target number of sample in the audio stream. After the value
^^
samples, plural
signature.asc
Description: OpenPGP digital signature
___
ffmpeg-
From: Clément Bœsch
---
Note: I didn't use FF_API_DEBUG_MV because it seems to overlap with all
kind of other things and I couldn't test properly the conditional
compilation.
BTW, I could add a FATE test easily, but I didn't find any relevant
samples available.
TODO: minor bump avfilter, micro
On Mon, 18 Aug 2014 13:31:26 +0200
Stefano Sabatini wrote:
> On date Sunday 2014-08-17 19:04:35 -0400, compn encoded:
> > is there anyone using the remaining libmpcodecs filters ?
>
> Of the remaining filters, at least eq and eq2 are useful, and they are
> actually used by real users.
ok, then i
On Mon, Aug 18, 2014 at 5:53 AM, Stefano Sabatini wrote:
> ---
> doc/filters.texi | 47 +--
> 1 file changed, 45 insertions(+), 2 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 0ca1d6f..44eecca 100644
> --- a/doc/filters.texi
Hello,
Attached patch fixes segmentation fault in libavformat/a64.c
a64_write_header() when output stream's codec is not open, so
avctx->codec is NULL (in "stream_copy" use case for example). Correct
access to codec id is use of "avctx->codec_id" instead of
"avctx->codec->id".
Additiona
> So could you help me fix this problem and make the measurment result is
> better.
It is quite a bit of work to make ffmpeg do this properly. Also those
encoder settings are quite interesting.
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.o
Le primidi 1er fructidor, an CCXXII, Andrey Myznikov a écrit :
> Additionally, in 'default' section of switch() statement here, I
> propose to return AVERROR(ENOTSUP) instead of AVERROR_INVALIDDATA,
> because it is more clear to get someting like
> "avformat_write_header() fails: Operation not
Hello,
Attached patch fixes segmentation fault in libavformat/a64.c
a64_write_header() when output stream's codec is not open, so
avctx->codec is NULL (in "stream_copy" use case for example). Correct
access to codec id is use of "avctx->codec_id" instead of
"avctx->codec->id".
Regards,
Signed-off-by: Deti fliegl
---
libavdevice/decklink_common.cpp | 227 ++
libavdevice/decklink_common.h | 98
libavdevice/decklink_common_c.h | 32 +++
libavdevice/decklink_dec.cpp| 520
libavdevice/decklink_dec.h | 3
Hi,
On Mon, Aug 18, 2014 at 9:58 AM, Kieran Kunhya wrote:
> > How is it different? If you're interlacing-aware and call
> swscale_convert()
> > twice (once for each field, double stride each, alternate offset for
> second
> > call), isn't that the same?
>
> That would be true in the 422 domain,
Deti Fliegl fliegl.de> writes:
> +/* free() is needed for a string returned by the DeckLink SDL. */
> +#undef free
I believe this is not needed anymore but ...
> +free((void *) tmpDisplayName);
... please move the comment here.
Is the cast necessary?
> +av_log(NULL, AV_LOG_ERR
2014-08-18 19:26 GMT+02:00 Christophe Gisquet :
> Hi,
And with all patches.
--
Christophe
From 89b54fbd698eb9c68f0bf30105bcaf72c5575d27 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Mon, 18 Aug 2014 11:27:50 +0200
Subject: [PATCH] proresenc: force correct profile for alpha
Irrespecti
On Mon, Aug 18, 2014 at 01:22:37PM -0400, Ronald S. Bultje wrote:
> Hi,
>
>
> On Mon, Aug 18, 2014 at 9:58 AM, Kieran Kunhya wrote:
>
> > > How is it different? If you're interlacing-aware and call
> > swscale_convert()
> > > twice (once for each field, double stride each, alternate offset for
On Mon, Aug 18, 2014 at 01:31:26PM +0200, Stefano Sabatini wrote:
> On date Sunday 2014-08-17 19:04:35 -0400, compn encoded:
> > libav brought up the point again that it doesnt like libmpcodecs.
>
> That is, they will reunite if we drop mp? Or is that one of the
> conditional requirements?
>
> >
Hi,
2014-08-18 13:40 GMT+02:00 Carl Eugen Hoyos :
> Christophe Gisquet gmail.com> writes:
> If a profile was set, the automatic setting should
> probably not overwrite it.
> (If this is possible.)
>
> But I consider the usecase where a user wants to encode
> alpha but at the same time using a pro
Hi,
2014-08-18 19:22 GMT+02:00 Ronald S. Bultje :
> You mean the centerpoint chroma location (top-left, top-middle,
> middle-middle, etc.) respective to the set of luma pixels?
I don't think it's only that, but it's probably only slightly longer
to implement.
For interlaced 4:2:0, each chroma fi
On Mon, Aug 18, 2014 at 08:05:41PM +0300, Andrey Myznikov wrote:
> Hello,
>
> Attached patch fixes segmentation fault in libavformat/a64.c
> a64_write_header() when output stream's codec is not open, so
> avctx->codec is NULL (in "stream_copy" use case for example).
> Correct access to codec i
On 18.08.14 19:23, Carl Eugen Hoyos wrote:
> Deti Fliegl fliegl.de> writes:
>
>> +/* free() is needed for a string returned by the DeckLink SDL. */
>> +#undef free
>
> I believe this is not needed anymore but ...
removed it - but this has been part of the existing code which I simply
moved to a
>
> From: Clément Bœsch
>To: FFmpeg development discussions and patches
>Sent: Sunday, 20 July 2014, 10:40
>Subject: Re: [FFmpeg-devel] Filters
>
>
>On Fri, Jul 18, 2014 at 10:33:40PM +0100, JULIAN GARDNER wrote:
>[...]
>> fmpeg -i .ts -vcodec libx264 -b:v 1
>> I bet Michael or me could do this in 15 minutes.
>
> i had almost forgotten it but there is:
> { "src_v_chr_pos", "source vertical chroma position in luma grid/256"
> , OFFSET(src_v_chr_pos), AV_OPT_TYPE_INT, { .i64 = -1}, -1,
> 512, VE },
> { "src_h_chr
Deti Fliegl fliegl.de> writes:
> >> +av_log(NULL, AV_LOG_ERROR,
> >
> > Context should not be NULL.
> Can hardly be done in this file unless you supply avctx as
> argument in every function only for av_log purposes.
Please do this.
The patch you sent in your second mail is complet
On 18/08/14 5:01 AM, Pierre Edouard Lepere wrote:
> Hi,
> here's the new version of the patch. Sorry for the delay.
> James, I have not done 8-bit AVX versions because it requires unpacks that
> are done differently in AVX.
Aren't you thinking of AVX2 with 256bits wide registers? With AVX i mean
Rebased commits to have all changes in one patch. Hopefully it's
complete now.
Deti
On 18.08.14 19:48, Deti Fliegl wrote:
> On 18.08.14 19:23, Carl Eugen Hoyos wrote:
>> Deti Fliegl fliegl.de> writes:
>>
>>> +/* free() is needed for a string returned by the DeckLink SDL. */
>>> +#undef free
>>
>
On 18.08.14 20:05, Carl Eugen Hoyos wrote:
> Deti Fliegl fliegl.de> writes:
>
+av_log(NULL, AV_LOG_ERROR,
>>>
>>> Context should not be NULL.
>> Can hardly be done in this file unless you supply avctx as
>> argument in every function only for av_log purposes.
>
> Please do this
Signed-off-by: Michael Niedermayer
---
libavcodec/proresenc_kostya.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index 1e40dcf..2c09e03 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/pr
Signed-off-by: Michael Niedermayer
---
libavcodec/proresenc_kostya.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index 0f69767..1e40dcf 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_
On Mon, Aug 18, 2014 at 04:06:30PM +0200, Paul B Mahol wrote:
> On 8/18/14, Christophe Gisquet wrote:
> > Hi,
> >
> > this is a proposal to allow decoding incorrect files. There is no
> > obvious and systematic way to detect them however.
> >
> > --
> > Christophe
> >
>
> AFAIK it is missing AVCl
On Mon, Aug 18, 2014 at 03:02:14PM +0200, Christophe Gisquet wrote:
> Hi,
>
> 2014-06-19 6:23 GMT+02:00 Michael Niedermayer :
> > patch applied
>
> Am I missing something or was it not applied?
the "[PATCH 1/2] huffyuv: change statistics initialization"
patch has has been applied
git says:
git
patch requested by ubitux.
found in code dump from kierank:
+{ CODEC_ID_PCM_S24LE, MKTAG('n', 'i', '2', '4') }, /* BBC
typo fix for using ni24 instead of in24 (#3051) */ //GARYH added
(sorry for inline)
-compn
diff --git a/libavformat/isom.c b/libavformat/isom.c
index d768c32..613
On Mon, Aug 18, 2014 at 04:42:15PM -0400, compn wrote:
> patch requested by ubitux.
>
> found in code dump from kierank:
>
> +{ CODEC_ID_PCM_S24LE, MKTAG('n', 'i', '2', '4') }, /* BBC
> typo fix for using ni24 instead of in24 (#3051) */ //GARYH added
>
> (sorry for inline)
>
Why do
This is adapted from Elemental/libavformat.isom.c.patch by a certain
GARYH. The original patch only includes the LE version.
See also
http://lists.apple.com/archives/quicktime-users/2009/Oct/msg00048.html
---
libavformat/isom.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/iso
On Mon, Aug 18, 2014 at 02:14:23PM +0200, Lukasz Marek wrote:
> On 07.08.2014 15:36, Michael Niedermayer wrote:
> >On Thu, Aug 07, 2014 at 01:58:55AM +0200, Lukasz Marek wrote:
> >>PulseAudio expilitly requires name of the source.
> >>This patch makes it use default source when not provided.
> >>It
On Mon, Aug 18, 2014 at 11:01:39PM +0200, Clément Bœsch wrote:
> This is adapted from Elemental/libavformat.isom.c.patch by a certain
> GARYH. The original patch only includes the LE version.
>
> See also
> http://lists.apple.com/archives/quicktime-users/2009/Oct/msg00048.html
> ---
> libavformat
I'm wondering if this patch request got missed? ... or if I neglected something
when submitting? ... Any feedback appreciated.
Cheers
GT
Graham Torn
graham.t...@gmail.com
Begin forwarded message:
> From: Graham Torn
> Subject: [PATCH] libavformat: Add poster_time and time_scale to quicktim
On Mon, Aug 18, 2014 at 11:01:39PM +0200, Clément Bœsch wrote:
> This is adapted from Elemental/libavformat.isom.c.patch by a certain
> GARYH. The original patch only includes the LE version.
>
> See also
> http://lists.apple.com/archives/quicktime-users/2009/Oct/msg00048.html
> ---
> libavformat
Hi
On Thu, Aug 14, 2014 at 01:24:37PM -0600, Graham Torn wrote:
> From: gt-sdi
>
> Extract poster_time and time_scale from quicktime mdhd atom
> and add to metadata for output by ffprobe.
>
> Signed-off-by: gt-sdi
> ---
> libavformat/mov.c | 27 +--
> 1 file changed, 2
On Mon, Aug 18, 2014 at 7:03 AM, Timothy Gu wrote:
> On Sun, Aug 17, 2014 at 4:54 PM, Muhammad Faiz wrote:
> > This fontcolor option uses arithmetic expression, not color value,
> > so color names aren't available.
> > Thank's
>
> You should use AV_OPT_TYPE_COLOR instead of AV_OPT_TYPE_STRING to
On Thu, Aug 14, 2014 at 12:03:25PM +0200, Christophe Gisquet wrote:
> Hi,
>
> 2014-08-12 12:44 GMT+02:00 Christophe Gisquet :
> > Forgot a parameter to the call to avpriv_request_sample, will be added
> > later.
>
> If there's no further comment on this option for the reallocation,
> here's an u
On 18/08/14 4:42 AM, Michael Niedermayer wrote:
> On Mon, Aug 18, 2014 at 03:14:01AM -0300, James Almer wrote:
>> Fixes ticket #3862.
>> As a side effect, this also fixes aac_latm in wav.
>>
>> Signed-off-by: James Almer
>
> applied
>
>
>> ---
>> Maybe a check for channels <= 0 should be also a
On Mon, Aug 18, 2014 at 02:53:45PM +0200, Stefano Sabatini wrote:
> ---
> libavfilter/af_apad.c | 29 +
> 1 file changed, 17 insertions(+), 12 deletions(-)
probably ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
DNS cache poisoni
Hi!
Attached patch removes a request for samples of which we already have several
that all work fine.
Please comment, Carl Eugendiff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 7a4633f..aabae69 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1603,9 +1603,6 @@ sta
On Mon, Aug 18, 2014 at 07:44:39PM -0300, James Almer wrote:
> On 18/08/14 4:42 AM, Michael Niedermayer wrote:
> > On Mon, Aug 18, 2014 at 03:14:01AM -0300, James Almer wrote:
> >> Fixes ticket #3862.
> >> As a side effect, this also fixes aac_latm in wav.
> >>
> >> Signed-off-by: James Almer
> >
Hi!
Attached patch from MIKEH / Elemental is apparently meant to implement
setting h264 bitrate. It makes no difference for the sample from ticket
#3392.
I have no idea how to attribute the patch.
Please comment, Carl Eugendiff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 201367
Hi!
Attached patch from Elemental increases the maximum superframe size, I
don't know if this fixes any samples.
The original patchfile contains no further attribution.
Please comment, Carl Eugendiff --git a/libavcodec/wma.h b/libavcodec/wma.h
index c4056ec..37be627 100644
--- a/libavcodec/wma
On Mon, 18 Aug 2014 22:49:13 +0200
Clément Bœsch wrote:
> On Mon, Aug 18, 2014 at 04:42:15PM -0400, compn wrote:
> > +{ CODEC_ID_PCM_S24LE, MKTAG('n', 'i', '2', '4') }, /* BBC
> > typo fix for using ni24 instead of in24 (#3051) */ //GARYH added
> Why do you remove the comment?
becaus
Clément Bœsch pkh.me> writes:
> +{ AV_CODEC_ID_PCM_S24BE, MKTAG('n', 'i', '2', '4') },
> BBC typo */
> +{ AV_CODEC_ID_PCM_S24LE, MKTAG('n', 'i', '2', '4') },
> /* BBC typo */
Doesn't this patch make absolutely sure that the same
files that didn't work before this patch (and
On 19 August 2014 00:32, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch from MIKEH / Elemental is apparently meant to implement
> setting h264 bitrate. It makes no difference for the sample from ticket
> #3392.
This patch is nonsensical unfortunately.
___
On 18 August 2014 23:15, Andreas Cadhalpun
wrote:
> Why is FFmpeg treated differently than MariaDB/PerconaDB?
>
That's a very good question really.
But reading some of the comments in regards to having a nay for
including project that duplicate code, my guess is that it's a totally
irrational d
Signed-off-by: James Almer
---
Seems to work great with yuv deflate tiff images created with our tiff encoder
libavcodec/tiff.c | 71 +++
1 file changed, 35 insertions(+), 36 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
inde
Am 19.08.2014 01:34 schrieb "Carl Eugen Hoyos" :
>
> Hi!
>
> Attached patch from Elemental increases the maximum superframe size, I
don't know if this fixes any samples.
> The original patchfile contains no further attribution.
>
> Please comment, Carl Eugen
It makes no sense to send random patche
On Mon, Aug 18, 2014 at 06:54:55AM +0700, Muhammad Faiz wrote:
> This fontcolor option uses arithmetic expression, not color value,
> so color names aren't available.
> Thank's
>
> ---
> doc/filters.texi | 20 +++
> libavfilter/avf_showcqt.c | 84
> +
Fixes ticket #3829
---
libavfilter/af_atempo.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
index 6a3fd61..fcd0cb0 100644
--- a/libavfilter/af_atempo.c
+++ b/libavfilter/af_atempo.c
@@ -949,7 +949,13 @@ static int yae_
On 19.08.2014, at 02:24, Kieran Kunhya wrote:
> On 19 August 2014 00:32, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch from MIKEH / Elemental is apparently meant to implement
>> setting h264 bitrate. It makes no difference for the sample from ticket
>> #3392.
>
> This patch is nonsensical
90 matches
Mail list logo
