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
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 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
> +
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
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
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
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.
___
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 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
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, 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 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 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
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 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 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
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 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
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
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 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
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 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
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
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_
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
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
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 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
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
>> 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
>
> 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
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
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
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
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?
>
> >
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
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
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
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,
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
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,
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
> 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
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
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
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
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 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-
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-
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
___
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
> 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,
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
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.
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
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 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,
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
---
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
---
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 {
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
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 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
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 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 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
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
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
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
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,
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
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
_
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
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
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 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 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 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
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 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,
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
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
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,
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 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
90 matches
Mail list logo
