On Tue, Mar 22, 2016 at 11:43:50PM -0700, Chris Cunningham wrote:
> Hey Group,
>
> I'm seeing an interesting pattern [0][1] where we allocate 1 byte in places
> where I would expect no allocation to be necessary. Why is this being done?
Well, what else would you do?
None of the alternatives reall
On date Tuesday 2016-03-22 02:51:33 +0100, Michael Niedermayer encoded:
> On Mon, Mar 21, 2016 at 09:49:54PM +0100, Thilo Borgmann wrote:
> > Am 21.03.16 um 20:42 schrieb Michael Niedermayer:
> > > On Mon, Mar 21, 2016 at 12:14:40PM +0100, Thilo Borgmann wrote:
> > >> Hi,
> > >>
> > >> last weekend
On 3/23/16, Benjamin St wrote:
> Isn't this needed by AVFILTER_DEFINE_CLASS ?
You dont need it if filter doesnt have options to set.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Chris Cunningham chromium.org> writes:
> I'm seeing an interesting pattern [0][1] where we allocate 1 byte in places
> where I would expect no allocation to be necessary. Why is this being done?
>
> [0] https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/mem.c#L136
Iirc, alloc(0) crashes (or
On Wed, Mar 23, 2016 at 12:25:07PM +, Carl Eugen Hoyos wrote:
> Chris Cunningham chromium.org> writes:
>
> > I'm seeing an interesting pattern [0][1] where we allocate 1 byte in places
> > where I would expect no allocation to be necessary. Why is this being done?
> >
> > [0] https://github.
Hi,
On Wed, Mar 23, 2016 at 2:43 AM, Chris Cunningham wrote:
> Hey Group,
>
> I'm seeing an interesting pattern [0][1] where we allocate 1 byte in places
> where I would expect no allocation to be necessary. Why is this being done?
>
> [0] https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/m
Hi,
On Wed, Mar 23, 2016 at 8:32 AM, Ronald S. Bultje
wrote:
> Hi,
>
> On Wed, Mar 23, 2016 at 2:43 AM, Chris Cunningham <
> chcunning...@chromium.org> wrote:
>
>> Hey Group,
>>
>> I'm seeing an interesting pattern [0][1] where we allocate 1 byte in
>> places
>> where I would expect no allocatio
Remove the duplicated code for handling failure of apply_param_change().
---
libavcodec/utils.c | 34 +++---
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index c625bbc..2436f16 100644
--- a/libavcodec/utils.c
++
Until now, the decoding API was restricted to outputting 0 or 1 frames
per input packet. It also enforces a somewhat rigid dataflow in general.
This new API seeks to relax these restrictions by decoupling input and
output. Instead of doing a single call on each decode step, which may
consume the p
It's not practical to keep this with the new decode API.
---
ffmpeg.c | 7 ---
ffmpeg.h | 1 -
2 files changed, 8 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index 9a14294..bdb0e5e 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -2316,13 +2316,6 @@ static int process_input_packet(InputStream *ist,
---
Not so sure about the frame duplication logic etc.
---
ffmpeg.c | 71 +---
1 file changed, 46 insertions(+), 25 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index 1f1de8e..a7b07fb 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -788,7 +788,
wm4 (8):
lavu: improve documentation of some AVFrame functions
lavc: factor apply_param_change() AV_EF_EXPLODE handling
lavc: introduce a new decoding/encoding API with decoupled
input/output
ffmpeg: remove sub-frame warning
ffmpeg: use new decode API
ffmpeg: use new encode API
la
---
libavutil/frame.h | 12
1 file changed, 12 insertions(+)
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 76a8123..2d6299b 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -591,6 +591,10 @@ void av_frame_free(AVFrame **frame);
* If src is not reference counted,
---
libavformat/utils.c | 29 -
1 file changed, 12 insertions(+), 17 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 67d4d1b..c7b7969 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2814,27 +2814,22 @@ static int try_decode_fram
This needs to be explicitly supported by the AVCodec. Async mode can
be enabled for AVCodecs without explicit support too, which is treated
as if the codec performs all work instantly.
---
libavcodec/avcodec.h | 114 ++-
libavcodec/utils.c | 30 ++
This is a bit messy, mainly due to timestamp handling.
decode_video() relied on the fact that it could set dts on a flush/drain
packet. This is not possible with the old API, and won't be. (I think
doing this was very questionable with the old API. Flush packets should
not contain any information;
wm4 googlemail.com> writes:
> + * warning: if frame already has been allocated, calling this function will
> + * leak memory. In addition, undefined behavior can occur in certain
> + * cases.
If this is correct, I believe the following is a slightly
better wording:
if frame already has
wm4 googlemail.com> writes:
> Until now, the decoding API was restricted to outputting 0 or 1 frames
> per input packet. It also enforces a somewhat rigid dataflow in general.
>
> This new API seeks to relax these restrictions by decoupling input and
> output. Instead of doing a single call on e
On Wed, Mar 23, 2016 at 2:45 PM, Carl Eugen Hoyos wrote:
> wm4 googlemail.com> writes:
>
>> Until now, the decoding API was restricted to outputting 0 or 1 frames
>> per input packet. It also enforces a somewhat rigid dataflow in general.
>>
>> This new API seeks to relax these restrictions by de
Most useful for MPEG-TS. Works by having the underlying muxer configure the
bitstream filters, then moving them to our own AVStreams.
---
libavformat/segment.c | 43 ++-
1 file changed, 38 insertions(+), 5 deletions(-)
diff --git a/libavformat/segment.c b/l
On Tue, Mar 22, 2016 at 11:43:50PM -0700, Chris Cunningham wrote:
> Hey Group,
>
> I'm seeing an interesting pattern [0][1] where we allocate 1 byte in places
> where I would expect no allocation to be necessary. Why is this being done?
>
> [0] https://github.com/FFmpeg/FFmpeg/blob/master/libavut
If I understand well you want me to do a test that given a multimedia file test
if it loads works ok. If so how can I get a simple multimedia file?
I see this tests more like a unitary tests. In my opinion, test if
loading/storing to AVFrame need to be done in AVFrame.
Thanks :)
___
On Wed, Mar 23, 2016 at 12:39:30PM +0100, Benjamin St wrote:
> >
> > const?
> >
> Fixed
>
> missing new line.
>
> Fixed
>
>
> > Here and in every other function, { must be on own, separate line like
> > in every other filter.
> >
> Fixed
>
> Please use FFMIN()
>
> Fixed
>
> > +} HDCDContext
On Tue, Mar 22, 2016 at 06:40:27PM -0700, Amancio Hasty wrote:
[...]
> +static int vc264_init(AVCodecContext *avctx) {
> +
> +
> +
> + OMX_ERRORTYPE r;
> + int error;
> +
> +
> +
> + VC264Context *vc = avctx->priv_data;
> +
> + vc->width = avctx->width;
> + vc->height = avctx->height;
>
From: Clément Bœsch
./ffmpeg -nostats -f lavfi -i testsrc2=4k:d=2 -vf
bench=start,scale=1024x1024,bench=stop -f null -
before: t:0.489726 avg:0.489883 max:0.491852 min:0.489482
after: t:0.259438 avg:0.257707 max:0.260125 min:0.255893
---
I don't really like the roundtrip back to the ge
All tests were in the main method which produces a long main. Now, each test
is in his own method.
I think this produces a more clear code and follows more with the main
priority of FFmpeg "simplicity and small code size"
---
libavutil/parseutils.c | 338 +-
On Wed, Mar 23, 2016 at 02:02:09PM +0100, wm4 wrote:
> Remove the duplicated code for handling failure of apply_param_change().
> ---
> libavcodec/utils.c | 34 +++---
> 1 file changed, 19 insertions(+), 15 deletions(-)
still LGTM
thx
[...]
--
Michael GnuPG fing
- Added tests for av_find_info_tag().
- Added test for av_get_known_color_name()
---
libavutil/parseutils.c| 37
tests/ref/fate/parseutils | 151 ++
2 files changed, 188 insertions(+)
diff --git a/libavutil/parseutils.c b/liba
Is there a pretty formatter for ffmpeg’s coding style and
coding style guideline?
Amancio
> On Mar 23, 2016, at 8:17 AM, Michael Niedermayer
> wrote:
>
> On Tue, Mar 22, 2016 at 06:40:27PM -0700, Amancio Hasty wrote:
> [...]
>
>> +static int vc264_init(AVCodecContext *avctx) {
>> +
>> +
>> +
Hi,
On Wed, Mar 23, 2016 at 11:41 AM, Amancio Hasty wrote:
> Is there a pretty formatter for ffmpeg’s coding style and
> coding style guideline?
https://ffmpeg.org/developer.html#Coding-Rules-1
Please don't top-post.
Ronald
___
ffmpeg-devel mailing
This is the modified diff with few changes in mlp_encode_frame function.
-Disha
On Tue, Mar 22, 2016 at 1:59 AM, Disha Singh
wrote:
> Qualification task for project TrueHD encoder.
> There are two patches.
> One has the changes made to other files to support mlpenc.c and the other
> only has ml
Good day,
my previous attempts for GSoC aren't very successful. I talked with Carl Eugen
about GSoC. He advise me to choose a project with clear aims that fits clearly
into the scope of the framework. Such a thing would be MPEG DASH demuxing [1]
, so I want to bring it up as suggestion.
DASH is a
Benjamin St gmail.com> writes:
> This patch applies filtering/decoding for hdcds(see ticket #4441) .
> The filter is heavily based on
> https://github.com/kode54/foo_hdcd/. (Is this ok?
It seems to me as if the most simple solution is not
to change the license but add the license to our
used
On Wed, Mar 23, 2016 at 02:02:11PM +0100, wm4 wrote:
> It's not practical to keep this with the new decode API.
> ---
> ffmpeg.c | 7 ---
> ffmpeg.h | 1 -
> 2 files changed, 8 deletions(-)
its not practical in ffmpeg.c but libavcodec should be able to easily
check that a decoder which doesnt
On Wed, 23 Mar 2016 17:51:11 +0100
Michael Niedermayer wrote:
> On Wed, Mar 23, 2016 at 02:02:11PM +0100, wm4 wrote:
> > It's not practical to keep this with the new decode API.
> > ---
> > ffmpeg.c | 7 ---
> > ffmpeg.h | 1 -
> > 2 files changed, 8 deletions(-)
>
> its not practical in
On Tue, Mar 22, 2016 at 10:04 AM, Matthieu Bouron wrote:
>
>
> On Fri, Mar 18, 2016 at 5:50 PM, Matthieu Bouron <
> matthieu.bou...@gmail.com> wrote:
>
>> From: Matthieu Bouron
>>
>> ---
>>
>> Hello,
>>
>> The following patch add hwaccel support to the mediacodec (h264) decoder
>> by allowing
>>
On Wed, Mar 23, 2016 at 02:02:12PM +0100, wm4 wrote:
> This is a bit messy, mainly due to timestamp handling.
>
> decode_video() relied on the fact that it could set dts on a flush/drain
> packet. This is not possible with the old API, and won't be. (I think
> doing this was very questionable with
On Wed, Mar 23, 2016 at 06:06:37PM +0100, wm4 wrote:
> On Wed, 23 Mar 2016 17:51:11 +0100
> Michael Niedermayer wrote:
>
> > On Wed, Mar 23, 2016 at 02:02:11PM +0100, wm4 wrote:
> > > It's not practical to keep this with the new decode API.
> > > ---
> > > ffmpeg.c | 7 ---
> > > ffmpeg.h |
> On Mar 23, 2016, at 8:17 AM, Michael Niedermayer
> wrote:
>
> On Tue, Mar 22, 2016 at 06:40:27PM -0700, Amancio Hasty wrote:
> [...]
>
>> +static int vc264_init(AVCodecContext *avctx) {
>> +
>> +
>> +
>> + OMX_ERRORTYPE r;
>> + int error;
>> +
>> +
>> +
>> + VC264Context *vc = avctx->p
Hello Again,
I took a look at the FFmpeg j2k code. Now, I've worked with OpenJPEG for
many years, and I would say at least 20% of the code in FFmpeg was either
directly copied from OpenJPEG, or is very similar to OpenJPEG code.
I think the people who did the work on the FFmpeg codec would readily
On Wed, 23 Mar 2016 18:37:25 +0100
Michael Niedermayer wrote:
> On Wed, Mar 23, 2016 at 06:06:37PM +0100, wm4 wrote:
> > On Wed, 23 Mar 2016 17:51:11 +0100
> > Michael Niedermayer wrote:
> >
> > > On Wed, Mar 23, 2016 at 02:02:11PM +0100, wm4 wrote:
> > > > It's not practical to keep this w
On Wed, Mar 23, 2016 at 12:24 PM, Aaron Boxer wrote:
> Hello Again,
>
> I took a look at the FFmpeg j2k code. Now, I've worked with OpenJPEG for
> many years, and I would say at least 20% of the code in FFmpeg was either
> directly copied from OpenJPEG, or is very similar to OpenJPEG code.
>
> I t
On Wed, Mar 23, 2016 at 08:44:41PM +0100, wm4 wrote:
> On Wed, 23 Mar 2016 18:37:25 +0100
> Michael Niedermayer wrote:
>
> > On Wed, Mar 23, 2016 at 06:06:37PM +0100, wm4 wrote:
> > > On Wed, 23 Mar 2016 17:51:11 +0100
> > > Michael Niedermayer wrote:
> > >
> > > > On Wed, Mar 23, 2016 at 02:
On Wed, 23 Mar 2016 21:36:35 +0100
Michael Niedermayer wrote:
> On Wed, Mar 23, 2016 at 08:44:41PM +0100, wm4 wrote:
> > On Wed, 23 Mar 2016 18:37:25 +0100
> > Michael Niedermayer wrote:
> >
> > > On Wed, Mar 23, 2016 at 06:06:37PM +0100, wm4 wrote:
> > > > On Wed, 23 Mar 2016 17:51:11 +010
On Wed, Mar 23, 2016 at 03:31:38PM +0100, Michael Niedermayer wrote:
> On Tue, Mar 22, 2016 at 11:43:50PM -0700, Chris Cunningham wrote:
> > Hey Group,
> >
> > I'm seeing an interesting pattern [0][1] where we allocate 1 byte in places
> > where I would expect no allocation to be necessary. Why is
On Wed, Mar 23, 2016 at 03:24:47PM -0400, Aaron Boxer wrote:
> Hello Again,
>
> I took a look at the FFmpeg j2k code. Now, I've worked with OpenJPEG for
> many years, and I would say at least 20% of the code in FFmpeg was either
> directly copied from OpenJPEG, or is very similar to OpenJPEG code.
On Wed, Mar 23, 2016 at 09:51:46PM +0100, wm4 wrote:
> On Wed, 23 Mar 2016 21:36:35 +0100
> Michael Niedermayer wrote:
>
> > On Wed, Mar 23, 2016 at 08:44:41PM +0100, wm4 wrote:
> > > On Wed, 23 Mar 2016 18:37:25 +0100
> > > Michael Niedermayer wrote:
> > >
> > > > On Wed, Mar 23, 2016 at 06:
Reimar Döffinger gmx.de> writes:
> If it is copied the authors will hopefully admit to it
> (and hopefully be more careful about attribution in the
> future).
I of course agree with what you wrote but the original
author of the jpeg 2000 codec was unreachable a few
weeks after he had submitt
On 23.03.2016 17:09, Gerion Entrup wrote:
> 3. Implement adaptive switching.
>
> A note to the 3rd point. I'm absolutely not sure, what amount of work this is
> (maybe you could comment it) and what the best place would be to implement
> this (including whether this whole feature is meaningful).
On 23 March 2016 at 21:22, Carl Eugen Hoyos wrote:
> Reimar Döffinger gmx.de> writes:
>
> > If it is copied the authors will hopefully admit to it
> > (and hopefully be more careful about attribution in the
> > future).
>
> I of course agree with what you wrote but the original
> author of the j
On Wed, Mar 23, 2016 at 3:59 PM, Michael Bradshaw wrote:
> On Wed, Mar 23, 2016 at 12:24 PM, Aaron Boxer wrote:
> > Hello Again,
> >
> > I took a look at the FFmpeg j2k code. Now, I've worked with OpenJPEG for
> > many years, and I would say at least 20% of the code in FFmpeg was either
> > dire
Hi!
Attached patch fixes ticket #5364 for me.
Please review, Carl Eugen
diff --git a/libavcodec/flicvideo.c b/libavcodec/flicvideo.c
index 3e0573a..7535a40 100644
--- a/libavcodec/flicvideo.c
+++ b/libavcodec/flicvideo.c
@@ -423,7 +423,7 @@ static int flic_decode_frame_8BPP(AVCodecContext *avctx,
Adds per slave option 'onfail' to the tee muxer allowing an output to
fail,so other slave outputs can continue.
Signed-off-by: Jan Sebechlebsky
---
doc/muxers.texi | 14 +
libavformat/tee.c | 91 +--
2 files changed, 96 insertions(+),
Calling close_slave in case error is to be returned from open_slave
will free allocated resources.
Since failure can happen before bsfs array is initialized,
close_slave must check that bsfs is not NULL before accessing
tee_slave->bsfs[i] element.
Signed-off-by: Jan Sebechlebsky
---
libavformat
Closing single slave operation is pulled out into separate
function close_slave(TeeSlave*).
Both close_slave and close_slaves function are moved before
open_slave function.
Signed-off-by: Jan Sebechlebsky
---
libavformat/tee.c | 59 +++
1 file
On 23 March 2016 at 22:35, Aaron Boxer wrote:
> Back to my original point, what is the reasoning not to just switch to
> OpenJPEG?
Both OpenJPEG 1 and 2 are supported to add as external libraries in
FFmpeg. What do you mean by switching to OpenJPEG?
___
Benjamin St gmail.com> writes:
> This patch applies filtering/decoding for hdcds(see
> ticket #4441)
I tried to test with the files sample.cdda.flac and
sample.hdcd.flac attached in the ticket.
The output is different and one possible reason
is the usage of floating point arithmetic in the
f
On Wed, Mar 23, 2016 at 09:29:38AM -0500, Rodger Combs wrote:
> Most useful for MPEG-TS. Works by having the underlying muxer configure the
> bitstream filters, then moving them to our own AVStreams.
> ---
> libavformat/segment.c | 43 ++-
> 1 file changed,
On Wed, Mar 23, 2016 at 9:48 PM, Ricardo Constantino
wrote:
> On 23 March 2016 at 22:35, Aaron Boxer wrote:
> > Back to my original point, what is the reasoning not to just switch to
> > OpenJPEG?
> Both OpenJPEG 1 and 2 are supported to add as external libraries in
> FFmpeg. What do you mean by
On Wed, Mar 23, 2016 at 03:32:56PM +, Petru Rares Sincraian wrote:
> All tests were in the main method which produces a long main. Now, each test
> is in his own method.
>
> I think this produces a more clear code and follows more with the main
> priority of FFmpeg "simplicity and small code s
On Wed, Mar 23, 2016 at 03:33:02PM +, Petru Rares Sincraian wrote:
>
> - Added tests for av_find_info_tag().
> - Added test for av_get_known_color_name()
> ---
> libavutil/parseutils.c| 37
> tests/ref/fate/parseutils | 151
>
On Wed, Mar 23, 2016 at 02:37:31PM +, Petru Rares Sincraian wrote:
> If I understand well you want me to do a test that given a multimedia file
> test if it loads works ok. If so how can I get a simple multimedia file?
>
i dont know, but there are probably 3 ways or so
1. search for such a f
On Wed, Mar 23, 2016 at 06:35:20PM -0400, Aaron Boxer wrote:
> On Wed, Mar 23, 2016 at 3:59 PM, Michael Bradshaw wrote:
>
> > On Wed, Mar 23, 2016 at 12:24 PM, Aaron Boxer wrote:
> > > Hello Again,
> > >
> > > I took a look at the FFmpeg j2k code. Now, I've worked with OpenJPEG for
> > > many ye
On Wed, Mar 23, 2016 at 10:50:06PM -0400, Aaron Boxer wrote:
> On Wed, Mar 23, 2016 at 9:48 PM, Ricardo Constantino
> wrote:
>
> > On 23 March 2016 at 22:35, Aaron Boxer wrote:
> > > Back to my original point, what is the reasoning not to just switch to
> > > OpenJPEG?
> > Both OpenJPEG 1 and 2
This isn't necessary here, and for some reason broke only multichannel
AAC encoding when a channel layout tag was set.
---
libavcodec/audiotoolboxenc.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
---
libavcodec/audiotoolboxdec.c | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c
index 270e07f..1fa6f16 100644
--- a/libavcodec/audiotoolboxdec.c
+++ b/libavcodec/audiotoolboxdec.c
@
- ADTS-formatted AAC didn't work
- Channel layouts were never exported
- Channel mappings were incorrect beyond stereo
- Channel counts weren't updated after packets were decoded
- Timestamps were exported incorrectly
---
libavcodec/audiotoolboxdec.c | 248 -
- size variables were used in a confusing way
- incorrect size var use led to channel layouts not being set properly
- channel layouts were incorrectly mapped for >2-channel AAC
- bitrates not accepted by the encoder were discarded instead of being clamped
- some minor style/indentation fixes
---
68 matches
Mail list logo
