On 05.09.2016 16:43, Nicolas George wrote:
Le decadi 20 fructidor, an CCXXIV, Marton Balint a écrit :
The order of the channels to remain unchanged regardless of the input
channel layout (which is often guessed only). Filtering in ffmpeg is
unfortunately forcing you to use channel layouts, even
Hi!
Attached patch fixes ticket #5823.
Please comment, Carl Eugen
From 89c6b4034e24d76db2202008ffdd97770fed93f8 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 6 Sep 2016 11:16:19 +0200
Subject: [PATCH] doc/showspectrum*: Change options order to reflect numeric
values.
Fixes ticket
On 9/6/16, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes ticket #5823.
>
> Please comment, Carl Eugen
>
ok
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
2016-09-06 11:23 GMT+02:00 Paul B Mahol :
> On 9/6/16, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes ticket #5823.
>>
>> Please comment, Carl Eugen
>
> ok
Patch applied.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpe
2016-09-05 20:51 GMT+02:00 Marton Balint :
> Can/will I do this with -channel_layout 0 or
> something like that?
This (-channel_layout 0) was broken in 2012.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/lis
2016-09-06 5:26 GMT+02:00 Rodger Combs :
> ---
> libavformat/matroskaenc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index decb66d..7deccaa 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -1314,6
On Tue, Sep 06, 2016 at 01:34:19AM +0200, Paul B Mahol wrote:
> On 9/6/16, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavfilter/fifo.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
>
> should be ok
applied
thx
[...]
--
Michael G
2016-09-05 14:23 GMT+02:00 Mihai Chindea :
> https://github.com/FFmpeg/FFmpeg/blob/master/ffmpeg_vaapi.c#L305
> i imagine it should test with ctx->output_format, not ctx->decode_format
> which is always AV_PIX_FMT_NONE due to previous assignment ...
Please consider to send a patch made with git fo
2016-09-05 13:18 GMT+02:00 Burt P :
> * use the actual sample rate
Is hdcd supposed to work for sample_rates
different from 44100?
> * use a more sensible frequency for the tone
> * update fate test result
Can't this be split?
Carl Eugen
___
ffmpeg-de
On Tue, Sep 06, 2016 at 12:59:12AM +0200, Paul B Mahol wrote:
> On 9/6/16, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavfilter/af_amix.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> lgtm
applied
thx
[...]
--
Michael GnuPG finger
2016-09-05 12:47 GMT+02:00 Ligverd Haer :
> Create valide manifest.
> Calculate current bandwidth for eath chunk.
> Now works correctly with dash.sj
> -avio_printf(out, "\t\t segmentAlignment=\"true\" bitstreamSwitching=\"true\"");
> -if (c->max_frame_rate.num && !c->ambiguous_fram
On Mon, Sep 05, 2016 at 10:25:47PM -0600, Pavel Koshevoy wrote:
> On Sep 5, 2016 4:41 PM, "Michael Niedermayer"
> wrote:
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavfilter/af_atempo.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/libavfilter/af_
Hi!
Attached patch tries to fix Debian bug 785690.
Please comment, Carl Eugen
From fd0391ac4cefffe15da42ac1e14aafc5b3a9dbaf Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 6 Sep 2016 12:47:34 +0200
Subject: [PATCH] ffmpeg_opt: Suggest to use "file:..." if a protocol was not
found.
F
On Tue, Sep 06, 2016 at 12:51:05PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch tries to fix Debian bug 785690.
>
> Please comment, Carl Eugen
> ffmpeg_opt.c |2 ++
> 1 file changed, 2 insertions(+)
> 7ea4c9b62c1fa94707e3d88143bb2df73cf501c6
> 0001-ffmpeg_opt-Suggest-to-use-fil
В письме от вторник, 6 сентября 2016 г. 12:26:49 MSK пользователь Carl Eugen
Attributes
profiles
width
height
sar
frameRate
audioSamplingRate
mimeType
segmentProfiles
codecs
maximumSAPPeriod
startWithSAP
maxPlayoutRate
codingDependency
scanType
Common attributes for AdaptationSet and Representat
2016-09-06 12:56 GMT+02:00 Ligverd Haer :
> in particular, the attribute frameRate is duplicated in the node
> Representation
If this is the case, remove the offending line, do not
change the adjacent lines to make your intention easier
to understand.
Please do not top-post here, Carl Eugen
_
В письме от вторник, 6 сентября 2016 г. 13:02:42 MSK пользователь Carl Eugen
Hoyos написал:
> If this is the case, remove the offending line, do not
> change the adjacent lines to make your intention easier
> to understand.
Well, if that's clearer
if (c->has_video) {
avio_printf(out
2016-09-06 13:05 GMT+02:00 Ligverd Haer :
> В письме от вторник, 6 сентября 2016 г. 13:02:42 MSK пользователь Carl Eugen
> Hoyos написал:
>> If this is the case, remove the offending line, do not
>> change the adjacent lines to make your intention easier
>> to understand.
>
> Well, if that's clear
On Tue, Sep 6, 2016 at 5:22 AM, Carl Eugen Hoyos wrote:
> 2016-09-05 13:18 GMT+02:00 Burt P :
>> * use the actual sample rate
>
> Is hdcd supposed to work for sample_rates
> different from 44100?
As I understand it, yes. The PM Model 2 supported code insertion at
all CD and DVD-Audio sample rates
2016-09-06 13:02 GMT+02:00 Burt P. :
> On Tue, Sep 6, 2016 at 5:22 AM, Carl Eugen Hoyos wrote:
>> 2016-09-05 13:18 GMT+02:00 Burt P :
>>> * use the actual sample rate
>>
>> Is hdcd supposed to work for sample_rates
>> different from 44100?
>
> As I understand it, yes. The PM Model 2 supported code
Hi,
(Cc'ing as it's been some time.)
On 08/31/2016 04:42 PM, Carl Eugen Hoyos wrote:
I meant "defaulting to an additional track in the output mov file if the
input file contains such a data track (instead of ignoring this track
of the input file by default)".
So I looked into it and indeed th
(Oops, sorry about the subject, our MTA helpfully prepended it.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
It generally does not work.
Signed-off-by: Paul B Mahol
---
libavcodec/gif.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/gif.c b/libavcodec/gif.c
index 6af1f4a..d9c99d5 100644
--- a/libavcodec/gif.c
+++ b/libavcodec/gif.c
@@ -83,7 +83,7 @@ static int gif_image_
2016-09-06 13:30 GMT+02:00 Paul B Mahol :
> It generally does not work.
Shouldn't a warning be printed in this case?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi!
2016-09-06 13:13 GMT+02:00 Erkki Seppälä :
> (Cc'ing as it's been some time.)
Please don't.
> On 08/31/2016 04:42 PM, Carl Eugen Hoyos wrote:
>>
>> I meant "defaulting to an additional track in the output mov file if the
>> input file contains such a data track (instead of ignoring this trac
On Tue, Sep 6, 2016 at 6:12 AM, Carl Eugen Hoyos wrote:
> 2016-09-06 13:02 GMT+02:00 Burt P. :
>> On Tue, Sep 6, 2016 at 5:22 AM, Carl Eugen Hoyos wrote:
>>> 2016-09-05 13:18 GMT+02:00 Burt P :
* use the actual sample rate
>>>
>>> Is hdcd supposed to work for sample_rates
>>> different from
2016-09-06 14:01 GMT+02:00 Burt P. :
> In this patch, I took the opportunity to remove a hard-coded rate and
> use one from the framework.
Thanks for explaining!
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman
On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote:
> On Mon, Sep 05, 2016 at 10:04:35PM -0300, James Almer wrote:
> > On 9/5/2016 12:41 PM, Michael Niedermayer wrote:
> > > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote:
> > >> From: Clément Bœsch
> > >>
> > >> The
On Tue, Sep 06, 2016 at 02:18:35PM +0200, Michael Niedermayer wrote:
> On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote:
> > On Mon, Sep 05, 2016 at 10:04:35PM -0300, James Almer wrote:
> > > On 9/5/2016 12:41 PM, Michael Niedermayer wrote:
> > > > On Mon, Sep 05, 2016 at 04:41:5
On Tue, Sep 6, 2016 at 2:21 PM, Michael Niedermayer
wrote:
> On Tue, Sep 06, 2016 at 02:18:35PM +0200, Michael Niedermayer wrote:
>> On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote:
>> > On Mon, Sep 05, 2016 at 10:04:35PM -0300, James Almer wrote:
>> > > On 9/5/2016 12:41 PM, M
On Tue, Sep 06, 2016 at 02:39:11PM +0200, Hendrik Leppkes wrote:
> On Tue, Sep 6, 2016 at 2:21 PM, Michael Niedermayer
> wrote:
> > On Tue, Sep 06, 2016 at 02:18:35PM +0200, Michael Niedermayer wrote:
> >> On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote:
> >> > On Mon, Sep 05,
On 09/06/2016 02:37 PM, Carl Eugen Hoyos wrote:
I meant that for the same ffmpeg command line and the same
input file, I believe that with your patch, the output file (suddenly)
has one track more than before (because the data codec is now
listed in AVOutputFormat, the ffmpeg cli will try to add
applied
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 9/6/2016 9:57 AM, Clément Bœsch wrote:
>> We don't have time_base in codecpar, so why do we need ticks per frame in it?
>> >
>> > Which time_base does it modify the interpretation of? The field should
>> > be bundled with that, then.
> When do we have a mismatch of st->time_base and that "codec
On Tue, Sep 06, 2016 at 11:32:24AM -0300, James Almer wrote:
> On 9/6/2016 9:57 AM, Clément Bœsch wrote:
> >> We don't have time_base in codecpar, so why do we need ticks per frame in
> >> it?
> >> >
> >> > Which time_base does it modify the interpretation of? The field should
> >> > be bundled w
On Fri, Sep 02, 2016 at 10:42:09PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/vf_palettegen.c | 27 +++
> 1 file changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/libavfilter/vf_palettegen.c b/libavfilter/vf_palettegen.c
> index
On Fri, Sep 02, 2016 at 10:42:10PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/vf_paletteuse.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
> index dece05a..ed
On Tue, Sep 06, 2016 at 01:30:17PM +0200, Paul B Mahol wrote:
> It generally does not work.
>
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/gif.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/gif.c b/libavcodec/gif.c
> index 6af1f4a..d9c99d5 100644
> ---
From: Matthieu Bouron
Fixes escaping of consecutive 0x00, 0x00, 0x0{0-3} sequences.
---
libavcodec/mediacodecdec_h264.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mediacodecdec_h264.c b/libavcodec/mediacodecdec_h264.c
index a141174..4f9d737 100644
--- a/
On Tue, Sep 06, 2016 at 02:39:11PM +0200, Hendrik Leppkes wrote:
> On Tue, Sep 6, 2016 at 2:21 PM, Michael Niedermayer
> wrote:
> > On Tue, Sep 06, 2016 at 02:18:35PM +0200, Michael Niedermayer wrote:
> >> On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote:
> >> > On Mon, Sep 05,
On Tue, Sep 06, 2016 at 11:32:24AM -0300, James Almer wrote:
> On 9/6/2016 9:57 AM, Clément Bœsch wrote:
> >> We don't have time_base in codecpar, so why do we need ticks per frame in
> >> it?
> >> >
> >> > Which time_base does it modify the interpretation of? The field should
> >> > be bundled w
On Mon, Sep 05, 2016 at 07:58:36PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> tests/fate-run.sh | 15 +++
> 1 file changed, 15 insertions(+)
Approved-by: on IRC
applied
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC78
On Tue, Sep 6, 2016 at 5:10 PM, Michael Niedermayer
wrote:
> On Tue, Sep 06, 2016 at 02:39:11PM +0200, Hendrik Leppkes wrote:
>> On Tue, Sep 6, 2016 at 2:21 PM, Michael Niedermayer
>> wrote:
>> > On Tue, Sep 06, 2016 at 02:18:35PM +0200, Michael Niedermayer wrote:
>> >> On Tue, Sep 06, 2016 at 04
On Mon, Sep 05, 2016 at 03:20:27PM -0300, James Almer wrote:
> On 9/5/2016 2:58 PM, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > tests/fate/ffmpeg.mak | 5 +
> > tests/ref/fate/copy-236 | 2 ++
> > 2 files changed, 7 insertions(+)
> > create mode 100644 tes
On Tue, Sep 06, 2016 at 05:45:46PM +0200, Hendrik Leppkes wrote:
> On Tue, Sep 6, 2016 at 5:10 PM, Michael Niedermayer
> wrote:
> > On Tue, Sep 06, 2016 at 02:39:11PM +0200, Hendrik Leppkes wrote:
> >> On Tue, Sep 6, 2016 at 2:21 PM, Michael Niedermayer
> >> wrote:
> >> > On Tue, Sep 06, 2016 at
__MAC_10_11 can be present in updated revision of an older SDK so it
can't reliably detect availability of kAudioFormatEnhancedAC3 constant.
Fixes: b4daa2c40f ('lavc/audiotoolboxdec: add eac3 decoder')
Cc: Rodger Combs
Signed-off-by: Dmitry Kalinkin
---
libavcodec/audiotoolboxdec.c | 2 +-
1 fi
__MAC_10_11 can be present in updated revision of an older SDK so it
can't reliably detect availability of kAudioFormatEnhancedAC3 constant.
Fixes: b4daa2c40f ('lavc/audiotoolboxdec: add eac3 decoder')
Cc: Rodger Combs
Signed-off-by: Dmitry Kalinkin
---
libavcodec/audiotoolboxdec.c | 2 +-
1 fi
> On 06 Sep 2016, at 00:05, Rodger Combs wrote:
>
>
>> On Sep 5, 2016, at 22:58, Dmitry Kalinkin wrote:
>>
>> __MAC_10_11 can be present in updated revision of an older SDK so it
>> can't reliably detect availability of kAudioFormatEnhancedAC3 constant.
>>
>> Fixes: b4daa2c40f ('lavc/audioto
This patch addresses your concerns.
On Fri, Sep 2, 2016 at 5:05 PM, Michael Niedermayer
wrote:
> On Fri, Sep 02, 2016 at 03:31:21PM -0700, Brett Harrison wrote:
> > Addressed the following concerns.
> >
> > ===
> >
> > >libavfilter/vf_drawtext.c: In function ‘update_fontsize’:
> > >libavfilter/v
2016-09-06 15:07 GMT+02:00 Erkki Seppälä :
> Would it be even better to not copy the data tracks at
> all by default, so not set the .data_codec field for any
> format?
This was my original question for which I do not know
the answer: If you feel it doesn't hurt not to copy the
track I am all for
On Mon, Sep 05, 2016 at 10:26:26PM -0500, Rodger Combs wrote:
> ---
> libavformat/matroskaenc.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is
> On Sep 6, 2016, at 05:10, Carl Eugen Hoyos wrote:
>
> 2016-09-06 5:26 GMT+02:00 Rodger Combs :
>> ---
>> libavformat/matroskaenc.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
>> index decb66d..7deccaa 100644
>> --- a/libavfo
On Mon, Sep 05, 2016 at 10:26:28PM -0500, Rodger Combs wrote:
> ---
> libavformat/matroskaenc.c | 10 +-
> tests/fate/matroska.mak | 2 +-
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index 7deccaa..3eeb09b
On Mon, Sep 05, 2016 at 10:26:27PM -0500, Rodger Combs wrote:
> ---
> libavformat/matroskaenc.c | 1 +
> 1 file changed, 1 insertion(+)
no objection from me
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Asymptotically faster algorithms should always be prefer
On Mon, Sep 05, 2016 at 06:18:41AM -0500, Burt P wrote:
> Following a suggestion by Diego Biurrun.
> _t is reserved for POSIX, apparently.
>
> Signed-off-by: Burt P
> ---
> libavfilter/af_hdcd.c | 58
> +--
> 1 file changed, 29 insertions(+), 29 d
On Mon, Sep 05, 2016 at 06:18:43AM -0500, Burt P wrote:
> Signed-off-by: Burt P
> ---
> libavfilter/af_hdcd.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
> index c8bda82..c249589 100644
> --- a/libavfilter/af_hdc
On Mon, Sep 05, 2016 at 06:18:42AM -0500, Burt P wrote:
> Signed-off-by: Burt P
> ---
> libavfilter/af_hdcd.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
> index cde2340..c8bda82 100644
> --- a/libavfilter/af_hdc
Previously, we used a different list of checks when deciding whether to
write a set of tags at all than we did when deciding whether to write an
individual tag in the set. This resulted in sometimes writing an empty
tag master and seekhead. Now we use mkv_check_tag_name everywhere, so
if a dictiona
On Tue, Sep 06, 2016 at 05:13:52PM -0500, Rodger Combs wrote:
> Previously, we used a different list of checks when deciding whether to
> write a set of tags at all than we did when deciding whether to write an
> individual tag in the set. This resulted in sometimes writing an empty
> tag master an
Hello,
I haven't been sending patches in ages. Can somebody walk me through?
The patch is a "low hanging fruit" and simply adds the pixel formats RGBA and
BGRA to the Nvidia encoder "nvenc", which supports these two formats natively.
The gain here is that when one grabs the screen with x11grab
Hi!
2016-09-07 1:02 GMT+02:00 Sven C. Dack :
> +case AV_PIX_FMT_RGBA:
Should be AV_PIX_FMT_RGB0...
> +ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_ABGR;
> +break;
> +
> +case AV_PIX_FMT_BGRA:
... and AV_PIX_FMT_BGR0
> +ctx->surfaces[idx].format = NV_ENC_BUF
On 07/09/16 00:43, Carl Eugen Hoyos wrote:
Should be AV_PIX_FMT_RGB0...
... and AV_PIX_FMT_BGR0
I was wondering about that. The 0 means undefined/unused and I didn't want to
open a can of worms with it. Should I add BGR0 and RGB0, too? Does the 0 mean it
is reliably 0?
Sven
On 07/09/16 01:08, Sven C. Dack wrote:
On 07/09/16 00:43, Carl Eugen Hoyos wrote:
Should be AV_PIX_FMT_RGB0...
... and AV_PIX_FMT_BGR0
I was wondering about that. The 0 means undefined/unused and I didn't want to
open a can of worms with it. Should I add BGR0 and RGB0, too? Does the 0 mean
Hi,
The attached patch fixes playback of MP4/VP9 media containing superframes
when using the built-in VP9 decoder.
As an example,
https://github.com/Netflix/vp9-dash/raw/master/DASH-Samples/Fountain_2997_0560kbps_640x480_4x3PAR.ivf_DashUnencrypted.ismv
plays with corrupted frames using ffplay wit
Hi Matthew,
On Tue, Sep 6, 2016 at 10:10 PM, Matthew Gregan wrote:
> Hi,
>
> The attached patch fixes playback of MP4/VP9 media containing superframes
> when using the built-in VP9 decoder.
>
> As an example,
> https://github.com/Netflix/vp9-dash/raw/master/DASH-Samples/Fountain_2997_
> 0560kbps
At 2016-09-06T22:18:18-0400, Ronald S. Bultje wrote:
> I think the patch is fine, but I wonder if it should set it to _FULL (the
> parser ignores the option, but it is semantically more correct).
Good point, thanks for the feedback. Updated (simpler!) patch attached.
Cheers,
>From a9d69f145bb92
66 matches
Mail list logo
