Hi:
I find an issue about http. I don't use chunked, so s->chunksize will
be set as UINT64_MAX when http open, but because of "if (s->chunksize > 0)
s->chunksize -= len;" then chunksize will not be UINT64_MAX.
If ffurl_read return to 0, s->off < target_end, http_buf_read will
return to 0,
A lot of codecs require aligned frame data, but do not document it.
It can result in crashes with perfectly valid uses of the API.
Design rationale:
- requiring frame data to be always aligned would be wasteful;
- alignment requirements will evolve
(the 16->32 bump is still recent);
- requiri
A lot of filters require aligned frame data, but do not document it.
It can result in crashes with perfectly valid uses of the API.
For now, the default alignment is not set.
Signed-off-by: Nicolas George
---
libavfilter/avfilter.c | 51 ++
libavfi
Signed-off-by: Nicolas George
---
doc/APIchanges| 3 +++
libavutil/frame.c | 17 +
libavutil/frame.h | 8
3 files changed, 28 insertions(+)
With the linesize check and without the 1<<.
diff --git a/doc/APIchanges b/doc/APIchanges
index 67a6142401..6d3b573c2d 100
On Thu, May 18, 2017 at 10:11 AM, Nicolas George wrote:
> Signed-off-by: Nicolas George
> ---
> doc/APIchanges| 3 +++
> libavutil/frame.c | 17 +
> libavutil/frame.h | 8
> 3 files changed, 28 insertions(+)
>
>
I wonder if there should be an exception in here som
Le nonidi 29 floréal, an CCXXV, Hendrik Leppkes a écrit :
> I wonder if there should be an exception in here somewhere for
> hardware pixelformats, there is no reason to assume the hardware
> pointers passed in AVFrame would be aligned, and aligning them would
> cause all sorts of crashes.
> Best c
On Thu, May 18, 2017 at 10:44 AM, Nicolas George wrote:
> Le nonidi 29 floréal, an CCXXV, Hendrik Leppkes a écrit :
>> I wonder if there should be an exception in here somewhere for
>> hardware pixelformats, there is no reason to assume the hardware
>> pointers passed in AVFrame would be aligned,
Le nonidi 29 floréal, an CCXXV, Hendrik Leppkes a écrit :
> I think its a saner choice to design the API to try to avoid instant
> heap corruption, instead of hoping every case sets the alignment
> properly in all cases.
> A single if condition shouldn't be too much trouble, we already flag
> hardw
On Thu, May 18, 2017 at 3:11 PM, Nicolas George wrote:
> Signed-off-by: Nicolas George
> ---
> doc/APIchanges| 3 +++
> libavutil/frame.c | 17 +
> libavutil/frame.h | 8
> 3 files changed, 28 insertions(+)
>
>
> With the linesize check and without the 1<<.
>
>
> d
Le nonidi 29 floréal, an CCXXV, Muhammad Faiz a écrit :
> Missing linesize check.
No, check again.
> I tested the behaviour of av_frame_get_buffer(frame, 32) and check
> linesize[0], here the result of some different pixel formats:
> yuv420p: 32
> rgb24: 96
> rgba: 32
>
> So linesize constraint
On Thu, May 18, 2017 at 11:16 AM, Nicolas George wrote:
> Le nonidi 29 floréal, an CCXXV, Hendrik Leppkes a écrit :
>> I think its a saner choice to design the API to try to avoid instant
>> heap corruption, instead of hoping every case sets the alignment
>> properly in all cases.
>> A single if c
Le nonidi 29 floréal, an CCXXV, Hendrik Leppkes a écrit :
> We could put the check in another central place
Yes.
> This is not bikeshedding, its an actual concern.
Well, you win, I drop the baby, catch it or not, I do not care.
But I still oppose to bad fixed being committed in areas of code I
On Thu, May 18, 2017 at 5:20 PM, Nicolas George wrote:
> Le nonidi 29 floréal, an CCXXV, Muhammad Faiz a écrit :
>> Missing linesize check.
>
> No, check again.
Oh, I'm sorry. My fault.
>
>> I tested the behaviour of av_frame_get_buffer(frame, 32) and check
>> linesize[0], here the result of som
Hi folks,
I'm completely new to the list but have a couple of years experience as a
user. I happen to work a lot with things I record from satellite. My
recorder will include a lot of empty streams in the transport stream and
that is annoying. I have tweaked ffmpeg here and there to show only
non
Le nonidi 29 floréal, an CCXXV, Muhammad Faiz a écrit :
> I mean for rgb24 format, when alignment is 32, linesize should be
> multiple of 96 (32 is not enough).
I think you are wrong. I do not know any alignment requirement that is
not a power of 2.
Regards,
--
Nicolas George
signature.asc
On Thu, May 18, 2017 at 5:30 PM, Nicolas George wrote:
> Le nonidi 29 floréal, an CCXXV, Muhammad Faiz a écrit :
>> I mean for rgb24 format, when alignment is 32, linesize should be
>> multiple of 96 (32 is not enough).
>
> I think you are wrong. I do not know any alignment requirement that is
> n
Le nonidi 29 floréal, an CCXXV, Muhammad Faiz a écrit :
> But that is what av_frame_get_buffer does (and maybe ff_get_buffer too).
Maybe it does that, but I do not think it is an alignment issue, and I
am not entirely convinced this is intentional.
Anyway, I have wasted enough of my time on this
Hey Carl,
I am not aware of non-FFmpeg apps which can record to MP4 containing AMR.
That's not to say one does not exist.
I would agree that we likely need no changes for playing these MP4 files.
The MP4 requirement was from one of our customers.
Thanks,
Bob
On Wed, May 17, 2017 at 8:01 PM, Ca
Shivraj: yes, -mmsa flag will be added and should not be an issue for big
endian mips builds.
> +if enabled bigendian && enabled msa; then
> +disable msa
> +fi
As currently, MSA optimizations does not support big endian, above code will
disable MSA and switch to default C functi
On Tue, May 16, 2017 at 03:38:32PM -0700, Aaron Levinson wrote:
> Signed-off-by: Aaron Levinson
> ---
> configure | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/configure b/configure
> index 7980d92..49f91ac 100755
> --- a/configure
> +++ b/configure
> @@ -6013,10 +
Should fix Ticket6349.
Modifying data pointer may make it unaligned.
Also change frame->nb_samples < max to frame->nb_samples <= max.
This improves performance. Benchmark:
./ffmpeg -filter_complex "aevalsrc=0:n=1166,firequalizer=fixed=on" -f null null
old:
25767 decicycles in take_samples,10
On Wed, May 17, 2017 at 4:06 PM, Muhammad Faiz wrote:
> On Wed, May 17, 2017 at 3:20 PM, Nicolas George wrote:
>> L'octidi 28 floréal, an CCXXV, Muhammad Faiz a écrit :
>>> Of course, pushing the partial fix won't conflict with the complete
>>> fix.
>>
>> Of course it will, it touches the same ar
Le nonidi 29 floréal, an CCXXV, Muhammad Faiz a écrit :
> Should fix Ticket6349.
> Modifying data pointer may make it unaligned.
>
> Also change frame->nb_samples < max to frame->nb_samples <= max.
> This improves performance. Benchmark:
> ./ffmpeg -filter_complex "aevalsrc=0:n=1166,firequalizer=f
On 5/18/17, Nicolas George wrote:
> Le nonidi 29 floreal, an CCXXV, Muhammad Faiz a ecrit :
>> Should fix Ticket6349.
>> Modifying data pointer may make it unaligned.
>>
>> Also change frame->nb_samples < max to frame->nb_samples <= max.
>> This improves performance. Benchmark:
>> ./ffmpeg -filter
nearly copy paste from buffersink.h
Signed-off-by: Muhammad Faiz
---
libavfilter/filters.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavfilter/filters.h b/libavfilter/filters.h
index 2c78d60..c695fbf 100644
--- a/libavfilter/filters.h
+++ b/libavfilter/filters.h
@@ -92,6 +92,9 @@
On 5/18/2017 12:49 PM, Paul B Mahol wrote:
> On 5/18/17, Nicolas George wrote:
>> Le nonidi 29 floreal, an CCXXV, Muhammad Faiz a ecrit :
>>> Should fix Ticket6349.
>>> Modifying data pointer may make it unaligned.
>>>
>>> Also change frame->nb_samples < max to frame->nb_samples <= max.
>>> This i
On Thu, May 18, 2017 at 10:56 PM, James Almer wrote:
> On 5/18/2017 12:49 PM, Paul B Mahol wrote:
>> On 5/18/17, Nicolas George wrote:
>>> Le nonidi 29 floreal, an CCXXV, Muhammad Faiz a ecrit :
Should fix Ticket6349.
Modifying data pointer may make it unaligned.
Also change f
On Thu, May 18, 2017 at 10:32 PM, Muhammad Faiz wrote:
> On Thu, May 18, 2017 at 9:59 PM, Nicolas George wrote:
>> Le nonidi 29 floréal, an CCXXV, Muhammad Faiz a écrit :
>>> Should fix Ticket6349.
>>> Modifying data pointer may make it unaligned.
>>>
>>> Also change frame->nb_samples < max to fr
On Thu, May 18, 2017 at 10:37 PM, Nicolas George wrote:
> Le nonidi 29 floréal, an CCXXV, Muhammad Faiz a écrit :
>> >> Should fix Ticket6349.
>
> Forgot: please remove that, it is not true. The bug in this ticket is in
> libavcodec, it cannot be fixed by a change in libavfilter.
In my opinion, i
On 5/17/17, Muhammad Faiz wrote:
> See http://lists.ffmpeg.org/pipermail/ffmpeg-user/2017-April/035975.html
> Parsed_filter_X is not intuitive as filter instance name and
> also undocumented.
>
> Signed-off-by: Muhammad Faiz
> ---
> doc/filters.texi | 13 ++---
> libavfilter/gra
On Thu, May 18, 2017 at 3:18 PM, Michael Niedermayer
wrote:
> On Tue, May 16, 2017 at 03:38:32PM -0700, Aaron Levinson wrote:
>> Signed-off-by: Aaron Levinson
>> ---
>> configure | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/configure b/configure
>> index 7980d9
On Thu, May 18, 2017 at 11:11 PM, Paul B Mahol wrote:
> On 5/17/17, Muhammad Faiz wrote:
>> See http://lists.ffmpeg.org/pipermail/ffmpeg-user/2017-April/035975.html
>> Parsed_filter_X is not intuitive as filter instance name and
>> also undocumented.
>>
>> Signed-off-by: Muhammad Faiz
>> ---
>>
On 5/18/17, Muhammad Faiz wrote:
> On Thu, May 18, 2017 at 11:11 PM, Paul B Mahol wrote:
>> On 5/17/17, Muhammad Faiz wrote:
>>> See http://lists.ffmpeg.org/pipermail/ffmpeg-user/2017-April/035975.html
>>> Parsed_filter_X is not intuitive as filter instance name and
>>> also undocumented.
>>>
>>
Le nonidi 29 floréal, an CCXXV, Muhammad Faiz a écrit :
> In my opinion, it can.
No, it cannot: the frame that crashes goes from the application to
libavcodec. It came earlier from libavfilter, but that is irrelevant: an
application could have done the same thing without libavfilter, and
resulted
Le nonidi 29 floréal, an CCXXV, James Almer a écrit :
> Let's work on a solution instead of fighting and shit flinging for once...
Thank you.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffm
Hi,
cursory review, I appreciate that this is work in progress so don't read
too much into it.
General points:
- I really like how you're doing a literal translation without trying to
change it, this makes review easier and also reduces the likelihood that
there's performance implications.
- do y
On 5/18/2017 9:21 AM, Hendrik Leppkes wrote:
On Thu, May 18, 2017 at 3:18 PM, Michael Niedermayer
wrote:
On Tue, May 16, 2017 at 03:38:32PM -0700, Aaron Levinson wrote:
Signed-off-by: Aaron Levinson
---
configure | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/confi
On Thu, 18 May 2017 12:20:55 +0200, Pedro Andres Aranda Gutierrez
wrote:
> I'm completely new to the list but have a couple of years experience as a
> user. I happen to work a lot with things I record from satellite. My
> recorder will include a lot of empty streams in the transport stream and
>
avio_read may make multiple calls to fill_buffer to accumulate bytes
to fulfill a request. fill_buffer will overwrite previously read data
if it is not prepped. Added a call to 'ffio_ensure_seekback' to adjust
the s->buffer to fill_buffer's liking. This isn't necessary for the
very first call to fi
On Thu, May 18, 2017 at 01:12:49PM -0700, Rob Meyers wrote:
> avio_read may make multiple calls to fill_buffer to accumulate bytes
> to fulfill a request. fill_buffer will overwrite previously read data
> if it is not prepped. Added a call to 'ffio_ensure_seekback' to adjust
> the s->buffer to fill
avio_read does multiple calls to fill_buffer(). Adjusting things in
fill_buffer was frowned upon; how would you suggest I approach this? The
id3v2 seek doesn't come into play; the return from avio_read is the "full"
read.
The call I added in avio_read is only done when there was accumulated data,
On Thu, May 18, 2017 at 11:59 PM, Nicolas George wrote:
> Le nonidi 29 floréal, an CCXXV, Muhammad Faiz a écrit :
>> In my opinion, it can.
>
> No, it cannot: the frame that crashes goes from the application to
> libavcodec. It came earlier from libavfilter, but that is irrelevant: an
> applicatio
On 4/13/2017 4:54 PM, James Almer wrote:
> Don't just look at zero sized packets, and also check for AAC extradata
> updates, in preparation for the following patches.
>
> Signed-off-by: James Almer
> ---
> libavformat/movenc.c | 34 ++
> 1 file changed, 18 insert
On 2017/5/14 12:26, Jun Zhao wrote:
> V3: - Fix build error with old VAAPI version.
> V2: - Refine the name/value type to mb_rate_control/bool.
> - Only supported GEN9+ (SKL/APL/KBL/...)
> - i965 driver default use frame-level rate control algorithm (generate
> the QP for each frame),
>
2017-05-18 12:20 GMT+02:00 Pedro Andres Aranda Gutierrez :
> I'm completely new to the list but have a couple of years experience as a
> user. I happen to work a lot with things I record from satellite. My
> recorder will include a lot of empty streams in the transport stream and
> that is annoyi
45 matches
Mail list logo
