On 12/22/2016 9:12 PM, Thomas Turner wrote:
> Signed-off-by: Thomas Turner
> ---
> libavutil/tests/random_seed.c | 34 +-
> tests/ref/fate/random_seed| 1 +
> 2 files changed, 22 insertions(+), 13 deletions(-)
>
> diff --git a/libavutil/tests/random_seed.c b/
On Fri, Dec 23, 2016 at 05:44:22PM +0100, Paul B Mahol wrote:
> ffmpeg | branch: master | Paul B Mahol | Fri Dec 23
> 15:41:51 2016 +0100| [ea93052db3594f93f2d10be085a770184da0513d] | committer:
> Paul B Mahol
>
> avcodec/utvideodec: add SIMD support for median prediction for planar formats
>
On Sat, Dec 24, 2016 at 03:18:11AM +0100, Michael Niedermayer wrote:
> On Sat, Dec 24, 2016 at 03:10:28AM +0100, Michael Niedermayer wrote:
> > On Fri, Dec 23, 2016 at 09:49:52PM +0100, Nicolas George wrote:
> > > Reduce peak memory consumption with ffmpeg in certain cases.
> > >
> > > Signed-off-
On Sat, Dec 24, 2016 at 03:10:28AM +0100, Michael Niedermayer wrote:
> On Fri, Dec 23, 2016 at 09:49:52PM +0100, Nicolas George wrote:
> > Reduce peak memory consumption with ffmpeg in certain cases.
> >
> > Signed-off-by: Nicolas George
> > ---
> > libavfilter/buffersrc.c | 25 +
On Fri, Dec 23, 2016 at 09:49:52PM +0100, Nicolas George wrote:
> Reduce peak memory consumption with ffmpeg in certain cases.
>
> Signed-off-by: Nicolas George
> ---
> libavfilter/buffersrc.c | 25 +
> 1 file changed, 25 insertions(+)
deadlocks
./ffmpeg -i mpegts_with_
On Fri, Dec 23, 2016 at 11:46:07PM +0100, Nicolas George wrote:
> Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit :
> > shouldnt there be a public annoncement about the intend to make the API
> > public
> > shouldnt there be a public call for API design suggestions and discussion
> > shou
> Hello everybody,
>
> it's been a while since my contribution to matroskaenc in July. In case you
> don't remember my scenario - it's about realtime transcoding and and
> streaming of mkv files.
> That means that the header is sent to the client before the ffmpeg process is
> completed.
>> can
On 23.12.2016 09:17, Paul B Mahol wrote:
> On 12/23/16, Andreas Cadhalpun wrote:
>> On 22.12.2016 22:52, Paul B Mahol wrote:
>>> +xflag = flag + cnt1;
>>> +yflag = xflag;
>>> +
>>> +if (flag + cnt1 == 0) {
>>> +value = 0;
>>> +} else {
>>> +x
Le tridi 3 nivôse, an CCXXV, Marton Balint a écrit :
> I guess we could buffer the undecoded packets instead of the decoded frames
> if there is a higher-than-usual delay between the streams. Is this also your
> plan?
Well, at some point in the far future I would have libavfilter capable
of handli
>From af75a5bbfe9f37672478b6a67f8bcfe32b7b997f Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Sat, 24 Dec 2016 00:21:23 +0100
Subject: [PATCH 1/1] flv demuxer supports live rtmp inputs but there is no any
info about it in the docs.
Signed-off-by: Bela Bodecs
---
doc/demuxers.texi | 10
Hi,
On Fri, Dec 23, 2016 at 6:18 PM, James Almer wrote:
> On 12/23/2016 8:00 PM, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Fri, Dec 23, 2016 at 12:32 PM, Paul B Mahol wrote:
> >
> >> diff --git a/libavcodec/lossless_videodsp.h b/libavcodec/lossless_
> >> videodsp.h
> >>
> > [..]
> >
> >> @@ -3
On 12/23/2016 8:00 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Fri, Dec 23, 2016 at 12:32 PM, Paul B Mahol wrote:
>
>> diff --git a/libavcodec/lossless_videodsp.h b/libavcodec/lossless_
>> videodsp.h
>>
> [..]
>
>> @@ -32,6 +32,7 @@ typedef struct LLVidDSPContext {
>>
> [..]
>
>> +void (*add_
Hi,
On Fri, Dec 23, 2016 at 12:32 PM, Paul B Mahol wrote:
> diff --git a/libavcodec/lossless_videodsp.h b/libavcodec/lossless_
> videodsp.h
>
[..]
> @@ -32,6 +32,7 @@ typedef struct LLVidDSPContext {
>
[..]
> +void (*add_magy_median_pred_int16)(uint16_t *dst, const uint16_t
> *top, const u
Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit :
> shouldnt there be a public annoncement about the intend to make the API public
> shouldnt there be a public call for API design suggestions and discussion
> shouldnt there be a public call for API related patches with deadline
> shouldnt
Le tridi 13 frimaire, an CCXXV, Nicolas George a écrit :
> > Does this make AV_BUFFERSRC_FLAG_PUSH useless?
> For the most part, yes. I intended to do the cleanup of these small
> aspects of the API after implementing a cleaner over API.
Hum, scratch that, it is still acutely needed with certain w
On Fri, Dec 23, 2016 at 09:23:50PM +0100, Nicolas George wrote:
> Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit :
> > APIs in FFmpeg will change as long as the project is alive.
> >
> > new developers join, older ones leave, peoples goals and oppinions
> > change. The libavfilter API is
On Fri, Dec 23, 2016 at 02:50:16PM +0100, Tobias Rapp wrote:
> Fixes pts gaps when reading AVI files > 256GiB generated by FFmpeg.
>
> Signed-off-by: Tobias Rapp
> ---
> libavformat/avidec.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
applied
thx
[...]
--
Michael GnuPG fing
Reduce peak memory consumption with ffmpeg in certain cases.
Signed-off-by: Nicolas George
---
libavfilter/buffersrc.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
index 1314397a32..77fd174219 100644
--- a/libavf
Signed-off-by: Nicolas George
---
libavformat/matroskaenc.c | 1 +
1 file changed, 1 insertion(+)
I do not have time to fix this, but I got a few segfaults here, so it needs
to be fixed. Either push the patch or, better push an actual fix.
diff --git a/libavformat/matroskaenc.c b/libavformat/
Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit :
> APIs in FFmpeg will change as long as the project is alive.
>
> new developers join, older ones leave, peoples goals and oppinions
> change. The libavfilter API is based on the lessons learned from
> previous projects and frameworks, in
On Fri, Dec 23, 2016 at 06:51:38PM +0100, Nicolas George wrote:
> Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit :
> > libavfilter had a public API that allowed filters to be implemented
> > these changes move it farther away from it
> > I do care about having some public API that allows
On Fri, 23 Dec 2016 03:58:16 +0100, Michael Niedermayer wrote:
> On Thu, Dec 22, 2016 at 03:39:05PM -0900, Lou Logan wrote:
> > Signed-off-by: Lou Logan
> > ---
> > doc/scaler.texi | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/scaler.texi b/doc/scaler.texi
Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit :
> libavfilter had a public API that allowed filters to be implemented
> these changes move it farther away from it
> I do care about having some public API that allows filters
> to be implemented.
> You pointed out that you work alone and p
Signed-off-by: Paul B Mahol
---
libavcodec/lossless_videodsp.c | 18 ++
libavcodec/lossless_videodsp.h | 1 +
libavcodec/magicyuv.c | 23 +---
libavcodec/x86/lossless_videodsp.asm| 62 +
libavcodec/x86/lossle
On Fri, Dec 23, 2016 at 05:08:49PM +0100, Nicolas George wrote:
> Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit :
> > From these 2 the first
>
> Ok, that makes one.
>
> > but i think the user app needs more access
> > to be able to implement filters and this could
On 12/23/2016 11:31 AM, Nicolas George wrote:
> L'octidi 28 frimaire, an CCXXV, Nicolas George a écrit :
>> +AVRational av_buffersink_get_frame_rate (const
>> AVFilterContext *ctx);
>> +int av_buffersink_get_w (const
>> AVFilterContext *ctx);
>> +int
On Fri, 23 Dec 2016 15:49:16 +0100
Nicolas George wrote:
> Le primidi 1er nivôse, an CCXXV, wm4 a écrit :
>
> [about windows COM system]
>
> > To make it short, everything in COM consists of structs with function
> > pointers. Structs are never extended, if you need new function
> > pointers, y
Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit :
> also AVCodecParameters would be an option to use as a struct if a
> struct is used
Unfortunately not, since it lacks at least time_base and frame_rate. We
could add them, but think it would be a bad idea. It also has a lot of
other field
Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit :
> From these 2 the first
Ok, that makes one.
>but i think the user app needs more access
> to be able to implement filters and this could make either API
> obsoleete
User app implementing filters is not for today
On Fri, Dec 23, 2016 at 04:59:45PM +0100, Michael Niedermayer wrote:
> On Fri, Dec 23, 2016 at 03:31:45PM +0100, Nicolas George wrote:
> > L'octidi 28 frimaire, an CCXXV, Nicolas George a écrit :
> > > +AVRational av_buffersink_get_frame_rate (const
> > > AVFilterContext *ctx);
> >
On Fri, Dec 23, 2016 at 03:31:45PM +0100, Nicolas George wrote:
> L'octidi 28 frimaire, an CCXXV, Nicolas George a écrit :
> > +AVRational av_buffersink_get_frame_rate (const
> > AVFilterContext *ctx);
> > +int av_buffersink_get_w (const
> > AVFilterC
On Fri, Dec 23, 2016 at 03:12:26PM +0100, Nicolas George wrote:
> Le quintidi 25 frimaire, an CCXXV, Marton Balint a écrit :
[...]
> > --- a/tests/ref/fate/filter-amerge
> > +++ b/tests/ref/fate/filter-amerge
> > @@ -2,8 +2,8 @@
> > #media_type 0: audio
> > #codec_id 0: pcm_s16le
> > #sample_rat
Le primidi 1er nivôse, an CCXXV, wm4 a écrit :
[about windows COM system]
> To make it short, everything in COM consists of structs with function
> pointers. Structs are never extended, if you need new function
> pointers, you just add new structs, which you can dynamically query
> from the old o
Le duodi 22 frimaire, an CCXXV, Michael Niedermayer a écrit :
> OOM is a security issue under some(1) circumstances, one can hit OOM due
> to too many pixels (or streams), this specific issue is fixed by the
> options
> (1) For example a server process that dies due to it. Even if restarted
> this
L'octidi 28 frimaire, an CCXXV, Nicolas George a écrit :
> +AVRational av_buffersink_get_frame_rate (const
> AVFilterContext *ctx);
> +int av_buffersink_get_w (const
> AVFilterContext *ctx);
> +int av_buffersink_get_h (c
Le tridi 3 nivôse, an CCXXV, James Almer a écrit :
> Yes, i can confirm this fixes it.
Thanks, pushed.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/
On 12/23/2016 7:25 AM, Nicolas George wrote:
> Le tridi 3 nivôse, an CCXXV, Nicolas George a écrit :
>> Yes, thanks. This is the glitch I am currently working on, and I think
>> it is almost fixed cleanly. Note that the actual time is still very
>> small, it is only ffmpeg keeps thinking the filter
Le quintidi 25 frimaire, an CCXXV, Marton Balint a écrit :
> This is the right thing to do, but I am afraid this will break too many
> existing filter chains. How can we implement this properly? Ideas/options:
>
> - change it, break it, users will fix it
> - add a guess_output_layout option which
On 12/23/16, Soft Works wrote:
>
>
>
> From: ffmpeg-devel on behalf of Paul B
> Mahol
> Sent: Friday, December 23, 2016 12:21 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] Serious Regression in matroskaenc:
>
> On 12/23
Le quintidi 25 frimaire, an CCXXV, Marton Balint a écrit :
> Signed-off-by: Marton Balint
> ---
> libavfilter/af_amerge.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
LGTM (I trust you tested it), sorry for the delay.
Regards,
--
Nicolas George
signature.asc
Descrip
Fixes pts gaps when reading AVI files > 256GiB generated by FFmpeg.
Signed-off-by: Tobias Rapp
---
libavformat/avidec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index d465965..4a054ee 100644
--- a/libavformat/avidec.c
+++ b
On Thu, Dec 15, 2016 at 04:39:19AM +0100, Marton Balint wrote:
> This is the right thing to do, but I am afraid this will break too many
> existing filter chains. How can we implement this properly? Ideas/options:
do you have an example of a filter chain it would break ?
[...]
--
Michael Gnu
>> To matroskaenc were only a few.
I'm counting 33 commits since my change from 17 July 2016
softworkz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 12/23/16, Soft Works wrote:
>
> On Fri, Dec 23, 2016 at 11:19:06AM +, Soft Works wrote:
>> Hello everybody,
>>
>> it's been a while since my contribution to matroskaenc in July. In case
>> you don't remember my scenario - it's about realtime transcoding and and
>> streaming of mkv files.
>>
On Fri, Dec 23, 2016 at 11:19:06AM +, Soft Works wrote:
> Hello everybody,
>
> it's been a while since my contribution to matroskaenc in July. In case you
> don't remember my scenario - it's about realtime transcoding and and
> streaming of mkv files.
> That means that the header is sent to
Nicolas, I'm afraid but I got the feeling that you haven't really understood
what this is about.
In July I already submitted a patch for matroscaenc.c in order to write
duration metadata to the
mkv header early. The purpose was to have a duration value in the mkv header
even in cases
where the
On Fri, Dec 23, 2016 at 11:19:06AM +, Soft Works wrote:
> Hello everybody,
>
> it's been a while since my contribution to matroskaenc in July. In case you
> don't remember my scenario - it's about realtime transcoding and and
> streaming of mkv files.
> That means that the header is sent to
On Fri, Dec 23, 2016 at 12:01:08AM -0600, Rodger Combs wrote:
> This allows us to report the correct codec ID here
> ---
> libavformat/allformats.c | 3 ++-
> libavformat/mp3dec.c | 66
> +++-
> libavformat/rawenc.c | 13 ++
> libavform
Le tridi 3 nivôse, an CCXXV, Soft Works a écrit :
> Are you making some fun out of me..?
No, sorry if it seemed that way.
> What I laid out was a method to reproduce as requested.
And the clear answer is: it is not a bug. You were using ffmpeg in an
unsupported way.
Note: for bugs without patch
>Le tridi 3 nivôse, an CCXXV, Soft Works a écrit :
>> Only thing that you shouldn't do is breaking the ffmpeg process via key
>> commands
>> because in this case the header would still be finalized.
>
>Then do that!
>
>Or possibly use the "live" option.
>
>Regards,
>
>--
> Nicolas George
Are yo
Le tridi 3 nivôse, an CCXXV, Soft Works a écrit :
> Only thing that you shouldn't do is breaking the ffmpeg process via key
> commands
> because in this case the header would still be finalized.
Then do that!
Or possibly use the "live" option.
Regards,
--
Nicolas George
signature.asc
Desc
From: ffmpeg-devel on behalf of Paul B Mahol
Sent: Friday, December 23, 2016 12:21 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] Serious Regression in matroskaenc:
On 12/23/16, Soft Works wrote:
> Hello everybody,
>
> i
On 12/23/16, Soft Works wrote:
> Hello everybody,
>
> it's been a while since my contribution to matroskaenc in July. In case you
> don't remember my scenario - it's about realtime transcoding and and
> streaming of mkv files.
> That means that the header is sent to the client before the ffmpeg pr
Hello everybody,
it's been a while since my contribution to matroskaenc in July. In case you
don't remember my scenario - it's about realtime transcoding and and streaming
of mkv files.
That means that the header is sent to the client before the ffmpeg process is
completed.
In this context we
Le tridi 3 nivôse, an CCXXV, Nicolas George a écrit :
> Yes, thanks. This is the glitch I am currently working on, and I think
> it is almost fixed cleanly. Note that the actual time is still very
> small, it is only ffmpeg keeps thinking the filter is not ready and
> sleeping.
Actually, it was no
Le duodi 2 nivôse, an CCXXV, James Almer a écrit :
> This patch made audio encoding extremely slow.
>
> time ./ffmpeg -i INPUT.wav -c:a tta -f null -
>
> Before
> size=N/A time=00:00:22.98 bitrate=N/A speed= 373x
> video:0kB audio:1272kB subtitle:0kB other streams:0kB global headers:0kB
> muxing
On 12/23/16, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/pixlet.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
applied
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffm
Le tridi 3 nivôse, an CCXXV, Paul B Mahol a écrit :
> I found no difference, but using float could help more one day when
> someone write SIMD code.
Ok, it was a reason to use floats that I did not know. Thanks.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
Le primidi 1er nivôse, an CCXXV, Michael Niedermayer a écrit :
> how hard would it be to write a preprocessor like tool to convert
> all if (ARCH/HAVE/CONFIG_SYMBOL ...)
> to
> #if
> ?
For a very general case, quite hard, but we do not need it.
If we stick to a few reasonable cosmetic conventions
On 12/23/16, Nicolas George wrote:
> Le duodi 2 nivôse, an CCXXV, James Almer a écrit :
>> Signed-off-by: James Almer
>> ---
>> libavcodec/pixlet.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavcodec/pixlet.c b/libavcodec/pixlet.c
>> index c5d37bb..c1bd32
Le duodi 2 nivôse, an CCXXV, James Almer a écrit :
> Signed-off-by: James Almer
> ---
> libavcodec/pixlet.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/pixlet.c b/libavcodec/pixlet.c
> index c5d37bb..c1bd321 100644
> --- a/libavcodec/pixlet.c
> +++ b
On 12/23/16, Andreas Cadhalpun wrote:
> On 22.12.2016 22:52, Paul B Mahol wrote:
>> ffmpeg | branch: master | Paul B Mahol | Fri Dec 2
>> 20:30:50 2016 +0100| [73651090ca1183f37753ee30a7e206ca4fb9f4f0] |
>> committer: Paul B Mahol
>>
>> avcodec: add Apple Pixlet decoder
>>
>> Signed-off-by: Paul
62 matches
Mail list logo
