Re: [FFmpeg-devel] The Crystalhd video decoder is broken - last ffmpeg good commit: 6d160afab2fa8d3bfb216fee96d3537ffc9e86e8
In the meantime, I have updated the CrystalHD kernel driver to linux 4.9.y: https://github.com/wallak/crystalhd Wallak. - Mail original - De: "wm4" À: ffmpeg-devel@ffmpeg.org Envoyé: Mardi 14 Mars 2017 23:35:13 Objet: Re: [FFmpeg-devel] The Crystalhd video decoder is broken - last ffmpeg good commit: 6d160afab2fa8d3bfb216fee96d3537ffc9e86e8 On Tue, 14 Mar 2017 22:44:10 +0100 (CET) Marton Balint wrote: > On Mon, 13 Mar 2017, Philip Langdale wrote: > > > On Mon, 13 Mar 2017 19:39:35 -0700 > > Philip Langdale wrote: > > > >> On Tue, 14 Mar 2017 02:49:27 +0100 (CET) > >> wal...@free.fr wrote: > >> > >> > Indeed 7447ec91b5a692121b81a04c6501a5811d867775 is working; But I > >> > have the following errors with the last ffmpeg git state: > >> > [h264_crystalhd @ 0x7fda3c060500] This decoder requires using the > >> > avcodec_send_packet() API. Last message repeated 456 times ... > >> > > >> > I've 'bisected' this last issue; The last good commit (with ffplay > >> > -vcodec h264_crystalhd working without error) is the > >> > following one: 234d3cbf469e9feef255e229202d4b029e66e9fe > >> > > >> > Is there a configuration flag to fix this issue? A software update > >> > is required? > >> > >> Heh - I switched the crystalhd decoder to the new send_packet API in > >> the next change, so that's entirely expected. CrystalHD basically > >> requires the new API as it allows for flexibility in how often frames > >> are returned vs submitted to the decoder; I only ever got it barely > >> working with the old API using vicious hacks that failed in many edge > >> cases. > >> > >> As it uses the new API, the application using the decoder must also > >> support the new API. 'ffmpeg' does, but I guess ffplay does not. My > >> first reaction is to ask why you're using ffplay. I'd recommend using > >> mpv - which is much more capable, and does support the new API; it's > >> what I use for all my testing. > >> > > > > Marton, > > > > Would you be interested in updating ffplay to use the new decode API? > > > > I think I have something working already, yet I did not post it to the > list, because I hoped the new API will support subtitles as well, so I > wouldn't have to handle them differently... > > I will try to dig up my old patch and submit it. Subtitles are a whole different complication, so I wouldn't hold my breath. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] spherical: Change types of bounding and pad to uint32_t
2017-03-14 23:02 GMT+01:00 Vittorio Giovara : > These types better reflect the ones described in the specification and > avoid any platform-specific implementation issues. Sorry if I miss something but could you clarify who the author of this patch is? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/h264dec: use OFFSET macro
On Tue, Feb 07, 2017 at 07:56:55PM +0100, Michael Niedermayer wrote: > On Mon, Feb 06, 2017 at 05:14:57PM +0100, Matthieu Bouron wrote: > > --- > > libavcodec/h264dec.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > ok Pushed. (and sorry for the delay). Thanks, Matthieu [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vp56: Require 1 undamaged frame for 5 damaged frames for concealment to be used
Hi, On Tue, Mar 14, 2017 at 11:12 PM, Michael Niedermayer < mich...@niedermayer.cc> wrote: > Fixes timeout with 847/clusterfuzz-testcase-5291877358108672 > Fixes timeout with 850/clusterfuzz-testcase-5721296509861888 > > This likely will need to be tweaked Sorry, but this is getting insane. I can't possibly be expected to just approve this. What's your end game? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavc/aarch64: add simple idct neon functions
On Mon, Mar 06, 2017 at 03:48:57PM +0100, Matthieu Bouron wrote:
> On Thu, Feb 23, 2017 at 04:59:16PM +0100, Matthieu Bouron wrote:
> > Hello,
> >
> > The following patchset add the ff_simple_idct function neon functions for
> > the
> > aarch64 platform. It's ported from armv7 simple_idct_neon with some
> > improvements:
> > * the source idct blocks are now loaded once and kept in v24-v31
> > * the source idct blocks are no longer overriden in idct_col4_top
> > * the destination is now written in one pass at the end of
> >ff_simple_idct{,_put,_add}_neon
> >
> > It is bitexact with the armv7 neon implementation.
> >
> > Here are some results (reported by {START,STOP}_TIMER) on an Odroid-C2
> > (Cortex
> > A53):
> >
> > Functions IDCT: simple IDCT: simpleneon
> > ff_simple_idct_put 9795 units3170 units
> > ff_simple_idct_add10227 units3302 units
> >
>
> Ping.
I'd like to push the patch tomorrow if there is no objection.
If that helps, here is the output of mjpegdec with simple and simpleneon
idct methods.
Original: http://0x5c.me/idct/original.jpg
Simple: http://0x5c.me/idct/simplec.png
Simpleneon: http://0x5c.me/idct/simpleneon.png
The diff between simple and simpleneon shows off some off by 1
differences: http://0x5c.me/idct/diff.png (simpleneon aarch64 is bitexact
with its armv7 counterpart though).
Matthieu
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/2] lavc/libfdk-aacenc: VBR check message fix
On Sat, Mar 11, 2017 at 12:59:06 +0100, Michael Niedermayer wrote: > > I am under the impression that Martin Storsjö is > > maintaining the libfdk_aac wrapper, but primarily on "libav". He is > you could send martin a private mail and ask I did (or rather, he did by getting in touch with me privately), and Martin is kindly taking care. Thanks, Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vp56: Require 1 undamaged frame for 5 damaged frames for concealment to be used
On Wed, 15 Mar 2017 at 12:05 Ronald S. Bultje wrote: > Hi, > > On Tue, Mar 14, 2017 at 11:12 PM, Michael Niedermayer < > mich...@niedermayer.cc> wrote: > > > Fixes timeout with 847/clusterfuzz-testcase-5291877358108672 > > Fixes timeout with 850/clusterfuzz-testcase-5721296509861888 > > > > This likely will need to be tweaked > > > Sorry, but this is getting insane. I can't possibly be expected to just > approve this. What's your end game? > I have tons of testcases for h264 that are 1KB and can make error concealment run for ages. Trying to fix them will just become a never ending set of heuristics to guess the conditions like the above. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vp56: Require 1 undamaged frame for 5 damaged frames for concealment to be used
Hi, On Wed, Mar 15, 2017 at 8:21 AM, Kieran Kunhya wrote: > On Wed, 15 Mar 2017 at 12:05 Ronald S. Bultje wrote: > > > Hi, > > > > On Tue, Mar 14, 2017 at 11:12 PM, Michael Niedermayer < > > mich...@niedermayer.cc> wrote: > > > > > Fixes timeout with 847/clusterfuzz-testcase-5291877358108672 > > > Fixes timeout with 850/clusterfuzz-testcase-5721296509861888 > > > > > > This likely will need to be tweaked > > > > > > Sorry, but this is getting insane. I can't possibly be expected to just > > approve this. What's your end game? > > > > I have tons of testcases for h264 that are 1KB and can make error > concealment run for ages. > Trying to fix them will just become a never ending set of heuristics to > guess the conditions like the above. Right. Also, this is fuzz-specific code. I've made remarks about this before, but I'll say it again: ideally, I don't want fuzz-specific code anywhere. Especially not "carefully crafted" crap like this. I'm actually starting to believe that the error concealment code in this decoder (vp56) is fuzz-specific code also. Is there a real-world input where the user experience is improved by this code? (If you want to speed up fuzzing, just add an artificial resolution limit of 64x64 in your fuzzing binary's get_buffer2() callback.) Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: error out if jni is enabled and not found
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 1e2e774950..a4890ca0d3 100755
--- a/configure
+++ b/configure
@@ -5744,7 +5744,7 @@ enabled frei0r&& { check_header frei0r.h ||
die "ERROR: frei0r.h hea
enabled gmp && require2 gmp gmp.h mpz_export -lgmp
enabled gnutls&& require_pkg_config gnutls gnutls/gnutls.h
gnutls_global_init
enabled jni && { [ $target_os = "android" ] && check_header
jni.h && enabled pthreads &&
- check_lib2 "dlfcn.h" dlopen -ldl; }
+ check_lib2 "dlfcn.h" dlopen -ldl || die "ERROR:
JNI not found"; }
enabled ladspa&& { check_header ladspa.h || die "ERROR: ladspa.h
header not found"; }
enabled libiec61883 && require libiec61883 libiec61883/iec61883.h
iec61883_cmp_connect -lraw1394 -lavc1394 -lrom1394 -liec61883
enabled libass&& require_pkg_config libass ass/ass.h
ass_library_init
--
2.12.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avcodec/videotoolbox: add rc_max_bitrate control into videotoolbox
On March 14, 2017 at 10:54:47 AM, Steven Liu (l...@chinaffmpeg.org) wrote:
add kVTCompressionPropertyKey_DataRateLimits support by rc_max_bitrate
Reviewed-by: Rick Kern
Signed-off-by: Steven Liu
---
libavcodec/videotoolboxenc.c | 47
1 file changed, 47 insertions(+)
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index 005f5d6..0cba2c8 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -898,7 +898,14 @@ static int vtenc_create_encoder(AVCodecContext *avctx,
{
VTEncContext *vtctx = avctx->priv_data;
SInt32 bit_rate = avctx->bit_rate;
+ SInt32 max_rate = avctx->rc_max_rate;
CFNumberRef bit_rate_num;
+ CFNumberRef bytes_per_second;
+ CFNumberRef one_second;
+ CFArrayRef data_rate_limits;
+ int64_t bytes_per_second_value = 0;
+ int64_t one_second_value = 0;
+ void *nums[2];
int status = VTCompressionSessionCreate(kCFAllocatorDefault,
avctx->width,
@@ -938,6 +945,46 @@ static int vtenc_create_encoder(AVCodecContext *avctx,
return AVERROR_EXTERNAL;
}
+ bytes_per_second_value = max_rate >> 3;
+ bytes_per_second = CFNumberCreate(kCFAllocatorDefault,
+ kCFNumberSInt64Type,
+ &bytes_per_second_value);
+ if (!bytes_per_second) {
+ return AVERROR(ENOMEM);
+ }
+ one_second_value = 1;
+ one_second = CFNumberCreate(kCFAllocatorDefault,
+ kCFNumberSInt64Type,
+ &one_second_value);
+ if (!one_second) {
+ CFRelease(bytes_per_second);
+ return AVERROR(ENOMEM);
+ }
+ nums[0] = bytes_per_second;
+ nums[1] = one_second;
+ data_rate_limits = CFArrayCreate(kCFAllocatorDefault,
+ nums,
+ 2,
+ &kCFTypeArrayCallBacks);
+
+ if (!data_rate_limits) {
+ CFRelease(bytes_per_second);
+ CFRelease(one_second);
+ return AVERROR(ENOMEM);
+ }
+ status = VTSessionSetProperty(vtctx->session,
+ kVTCompressionPropertyKey_DataRateLimits,
+ data_rate_limits);
+
+ CFRelease(bytes_per_second);
+ CFRelease(one_second);
+ CFRelease(data_rate_limits);
+
+ if (status) {
+ av_log(avctx, AV_LOG_ERROR, "Error setting max bitrate property: %d\n",
status);
+ return AVERROR_EXTERNAL;
+ }
+
if (profile_level) {
status = VTSessionSetProperty(vtctx->session,
kVTCompressionPropertyKey_ProfileLevel,
--
2.10.1.382.ga23ca1b.dirty
Pushed - thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] The Crystalhd video decoder is broken - last ffmpeg good commit: 6d160afab2fa8d3bfb216fee96d3537ffc9e86e8
On Wed, 15 Mar 2017 10:09:17 +0100 (CET) wal...@free.fr wrote: > In the meantime, I have updated the CrystalHD kernel driver to linux > 4.9.y: https://github.com/wallak/crystalhd > > Wallak. I've been sending updates to: https://github.com/dbason/crystalhd --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vp56: Require 1 undamaged frame for 5 damaged frames for concealment to be used
On Wed, 15 Mar 2017 08:58:39 -0400 "Ronald S. Bultje" wrote: > Hi, > > On Wed, Mar 15, 2017 at 8:21 AM, Kieran Kunhya wrote: > > > On Wed, 15 Mar 2017 at 12:05 Ronald S. Bultje wrote: > > > > > Hi, > > > > > > On Tue, Mar 14, 2017 at 11:12 PM, Michael Niedermayer < > > > mich...@niedermayer.cc> wrote: > > > > > > > Fixes timeout with 847/clusterfuzz-testcase-5291877358108672 > > > > Fixes timeout with 850/clusterfuzz-testcase-5721296509861888 > > > > > > > > This likely will need to be tweaked > > > > > > > > > Sorry, but this is getting insane. I can't possibly be expected to just > > > approve this. What's your end game? > > > > > > > I have tons of testcases for h264 that are 1KB and can make error > > concealment run for ages. > > Trying to fix them will just become a never ending set of heuristics to > > guess the conditions like the above. > > > Right. Also, this is fuzz-specific code. I've made remarks about this > before, but I'll say it again: ideally, I don't want fuzz-specific code > anywhere. Especially not "carefully crafted" crap like this. +1 Effort should be put into generally making the code more robust, instead of adding new elaborate special cases for every fuzz sample we hit... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] swresample/options: enable linear_interp and exact_rational by default
On Mon, Mar 13, 2017 at 8:40 PM, Muhammad Faiz wrote: > better quality without speedloss > > Signed-off-by: Muhammad Faiz > --- > doc/resampler.texi | 5 +- > libswresample/options.c | 4 +- > tests/fate/libswresample.mak | 189 > --- > tests/ref/acodec/s302m | 6 +- > tests/ref/lavf/dv_fmt| 8 +- > tests/ref/lavf/gxf | 8 +- > tests/ref/lavf/mxf | 12 +-- > 7 files changed, 201 insertions(+), 31 deletions(-) I'm going to push this tomorrow if no one object Thx. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vp56: Require 1 undamaged frame for 5 damaged frames for concealment to be used
On Wed, Mar 15, 2017 at 08:58:39AM -0400, Ronald S. Bultje wrote: > Hi, > > On Wed, Mar 15, 2017 at 8:21 AM, Kieran Kunhya wrote: > > > On Wed, 15 Mar 2017 at 12:05 Ronald S. Bultje wrote: > > > > > Hi, > > > > > > On Tue, Mar 14, 2017 at 11:12 PM, Michael Niedermayer < > > > mich...@niedermayer.cc> wrote: > > > > > > > Fixes timeout with 847/clusterfuzz-testcase-5291877358108672 > > > > Fixes timeout with 850/clusterfuzz-testcase-5721296509861888 > > > > > > > > This likely will need to be tweaked > > > > > > > > > Sorry, but this is getting insane. I can't possibly be expected to just > > > approve this. What's your end game? > > > > > > > I have tons of testcases for h264 that are 1KB and can make error > > concealment run for ages. and how is this related to a fix for th vp* decoder ? > > Trying to fix them will just become a never ending set of heuristics to > > guess the conditions like the above. Thats only true to some extend. The issue that a file can take a long time to decode isnt fixable, a file can always have a long duration and high resolution. The issue that a file that has few bytes size takes a long time to decode can be fixed for some codecs. Id say we should fix this where it can be done cleanly. In formats that allow one to encode gigabyte sized blue frames in 1 byte theres no fix possible OTOH. In cases where it is fixable the fix has to ensure that theres a limit on the computations per byte. Thats exactly what happens by limiting the number of concealed frames in relation to error free frames. Keep in mind a "fixable" codec implies that undamaged frames would not require unbound computational resources per byte. > > > Right. Also, this is fuzz-specific code. I've made remarks about this > before, but I'll say it again: ideally, I don't want fuzz-specific code > anywhere. Especially not "carefully crafted" crap like this. > > I'm actually starting to believe that the error concealment code in this > decoder (vp56) is fuzz-specific code also. Is there a real-world input > where the user experience is improved by this code? I have no real world damaged vp56 files iam aware of, in fact i dont think i remember seeing vp56 in the wild, what i have are just our samples or at least thats what iam concioulsy aware of Damaged data is inevitable though from packet loss, damaged sectors and other, so damaged data is real it occurs with anything eventually that is stored or transmitted. The only way it can never occur is if a codec is never used more or less and error concealment can provide better quality than lack of EC. when fixing fuzz issues iam trying to do something usefull when theres a related feature like implementing the very basic EC code in vp56. Working error concealment code would be nice for every codec IMO but if people dont want EC code in vp56 then we can drop this code of course, makes no difference to me. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vp56: Require 1 undamaged frame for 5 damaged frames for concealment to be used
Hi, On Wed, Mar 15, 2017 at 2:51 PM, Michael Niedermayer wrote: > On Wed, Mar 15, 2017 at 08:58:39AM -0400, Ronald S. Bultje wrote: > > I'm actually starting to believe that the error concealment code in this > > decoder (vp56) is fuzz-specific code also. Is there a real-world input > > where the user experience is improved by this code? > > I have no real world damaged vp56 files iam aware of, in fact i dont > think i remember seeing vp56 in the wild, what i have are just our > samples or at least thats what iam concioulsy aware of > > Damaged data is inevitable though from packet loss, damaged sectors > and other, so damaged data is real it occurs with anything eventually > that is stored or transmitted. The only way it can never occur is if > a codec is never used more or less > > and error concealment can provide better quality than lack of EC. > > when fixing fuzz issues iam trying to do something usefull when theres > a related feature like implementing the very basic EC code in vp56. > Working error concealment code would be nice for every codec IMO > I agree in general, but we need a way of verifying that it actually works, which in this case means "leads to an improvement in decoded stream quality". I don't think that has been verified here. No benefit (..) for a very quickly escalation in code complexity related to this feature makes me wonder whether that's the right approach. but if people dont want EC code in vp56 then we can drop this code of > course, makes no difference to me. I would personally probably vote to remove EC from vp56. I'd like to hear other people's opinions also, don't remove it just because I said so ;-). Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vp56: Require 1 undamaged frame for 5 damaged frames for concealment to be used
On Wed, 15 Mar 2017 15:02:08 -0400 "Ronald S. Bultje" wrote: > Hi, > > On Wed, Mar 15, 2017 at 2:51 PM, Michael Niedermayer > wrote: > > > On Wed, Mar 15, 2017 at 08:58:39AM -0400, Ronald S. Bultje wrote: > > > I'm actually starting to believe that the error concealment code in this > > > decoder (vp56) is fuzz-specific code also. Is there a real-world input > > > where the user experience is improved by this code? > > > > I have no real world damaged vp56 files iam aware of, in fact i dont > > think i remember seeing vp56 in the wild, what i have are just our > > samples or at least thats what iam concioulsy aware of > > > > Damaged data is inevitable though from packet loss, damaged sectors > > and other, so damaged data is real it occurs with anything eventually > > that is stored or transmitted. The only way it can never occur is if > > a codec is never used more or less > > > > and error concealment can provide better quality than lack of EC. > > > > when fixing fuzz issues iam trying to do something usefull when theres > > a related feature like implementing the very basic EC code in vp56. > > Working error concealment code would be nice for every codec IMO > > > > I agree in general, but we need a way of verifying that it actually works, > which in this case means "leads to an improvement in decoded stream > quality". I don't think that has been verified here. > > No benefit (..) for a very quickly escalation in code complexity related to > this feature makes me wonder whether that's the right approach. > > but if people dont want EC code in vp56 then we can drop this code of > > course, makes no difference to me. > > > I would personally probably vote to remove EC from vp56. I'd like to hear > other people's opinions also, don't remove it just because I said so ;-). I think the right question is: are vp56 streams usually broken? For example, for mpeg2 or h264, the answer can be "yes" because those are used in DVB (i.e. very unreliable transport). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vp56: Require 1 undamaged frame for 5 damaged frames for concealment to be used
On Wed, Mar 15, 2017 at 03:02:08PM -0400, Ronald S. Bultje wrote: > Hi, > > On Wed, Mar 15, 2017 at 2:51 PM, Michael Niedermayer > wrote: > > > On Wed, Mar 15, 2017 at 08:58:39AM -0400, Ronald S. Bultje wrote: [...] > but if people dont want EC code in vp56 then we can drop this code of > > course, makes no difference to me. > > > I would personally probably vote to remove EC from vp56. I'd like to hear > other people's opinions also, don't remove it just because I said so ;-). note, if we remove it we may need to be carefull with the resulting frames or frames using them as reference as they would have areas that havent been initialized. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mpeg12dec: parse A53 caption data embedded in SCTE-20 user data
On Sat, Mar 11, 2017 at 7:05 AM, Michael Niedermayer wrote:
> On Mon, Mar 06, 2017 at 10:23:14AM -0800, Aman Gupta wrote:
> > From: Aman Gupta
> >
> > ---
> > libavcodec/mpeg12dec.c | 38 ++
> > 1 file changed, 38 insertions(+)
> >
> > diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
> > index 27db14c..8cafdb0 100644
> > --- a/libavcodec/mpeg12dec.c
> > +++ b/libavcodec/mpeg12dec.c
> > @@ -2260,6 +2260,44 @@ static int mpeg_decode_a53_cc(AVCodecContext
> *avctx,
> > avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
> > }
> > return 1;
> > +} else if (buf_size >= 2 &&
> > + p[0] == 0x03 && (p[1]&0x7f) == 0x01) {
> > +/* extract SCTE-20 CC data */
> > +GetBitContext gb;
> > +int cc_count = 0;
> > +int i;
> > +
> > +init_get_bits(&gb, p + 2, buf_size - 2);
> > +cc_count = get_bits(&gb, 5);
> > +if (cc_count > 0) {
> > +av_freep(&s1->a53_caption);
> > +s1->a53_caption_size = cc_count * 3;
> > +s1->a53_caption = av_malloc(s1->a53_caption_size);
> > +if (s1->a53_caption) {
>
> a53_caption_size should be reset to 0 if allocation fails to keep the
> fields consistent
>
The other branches in this function all follow the same pattern, and will
not reset a53_caption_size on malloc failure.
Would you like me to fix all of them?
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In fact, the RIAA has been known to suggest that students drop out
> of college or go to community college in order to be able to afford
> settlements. -- The RIAA
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vp56: Require 1 undamaged frame for 5 damaged frames for concealment to be used
On 3/15/2017 3:51 PM, Michael Niedermayer wrote: > On Wed, Mar 15, 2017 at 08:58:39AM -0400, Ronald S. Bultje wrote: >> Hi, >> >> On Wed, Mar 15, 2017 at 8:21 AM, Kieran Kunhya wrote: >> >>> On Wed, 15 Mar 2017 at 12:05 Ronald S. Bultje wrote: >>> Hi, On Tue, Mar 14, 2017 at 11:12 PM, Michael Niedermayer < mich...@niedermayer.cc> wrote: > Fixes timeout with 847/clusterfuzz-testcase-5291877358108672 > Fixes timeout with 850/clusterfuzz-testcase-5721296509861888 > > This likely will need to be tweaked Sorry, but this is getting insane. I can't possibly be expected to just approve this. What's your end game? >>> > >>> I have tons of testcases for h264 that are 1KB and can make error >>> concealment run for ages. > > and how is this related to a fix for th vp* decoder ? > > > >>> Trying to fix them will just become a never ending set of heuristics to >>> guess the conditions like the above. > > Thats only true to some extend. The issue that a file can take a long > time to decode isnt fixable, a file can always have a long duration > and high resolution. > The issue that a file that has few bytes size takes a long time to > decode can be fixed for some codecs. > Id say we should fix this where it can be done cleanly. > In formats that allow one to encode gigabyte sized blue frames in 1 > byte theres no fix possible OTOH. > > In cases where it is fixable the fix has to ensure that theres a > limit on the computations per byte. Thats exactly what happens by > limiting the number of concealed frames in relation to error free > frames. Keep in mind a "fixable" codec implies that undamaged frames > would not require unbound computational resources per byte. > > >> >> >> Right. Also, this is fuzz-specific code. I've made remarks about this >> before, but I'll say it again: ideally, I don't want fuzz-specific code >> anywhere. Especially not "carefully crafted" crap like this. >> > >> I'm actually starting to believe that the error concealment code in this >> decoder (vp56) is fuzz-specific code also. Is there a real-world input >> where the user experience is improved by this code? > > I have no real world damaged vp56 files iam aware of, in fact i dont > think i remember seeing vp56 in the wild, what i have are just our > samples or at least thats what iam concioulsy aware of Afaik, old flv videos used VP6 (libavcodec reports them as vp6f). There are some real world files out there, like video game trailers. I have a Diablo 3 and a Starcraft 2 trailers encoded in VP6 here if you'd like to check them. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vp56: Require 1 undamaged frame for 5 damaged frames for concealment to be used
> > > > I have tons of testcases for h264 that are 1KB and can make error > > > concealment run for ages. > > and how is this related to a fix for th vp* decoder ? > My point is you can spend a lifetime fixing obscure conditions that cause error concealment to take a long time. Error concealment is good in itself but the above is essentially an arbitrary condition that you've come up with to stop the bug. This is essentially lavf-style guesswork and probing inside lavc. Regards, Kieran Kunhya ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mpeg12dec: parse A53 caption data embedded in SCTE-20 user data
On Wed, Mar 15, 2017 at 12:10:35PM -0700, Aman Gupta wrote:
> On Sat, Mar 11, 2017 at 7:05 AM, Michael Niedermayer > wrote:
>
> > On Mon, Mar 06, 2017 at 10:23:14AM -0800, Aman Gupta wrote:
> > > From: Aman Gupta
> > >
> > > ---
> > > libavcodec/mpeg12dec.c | 38 ++
> > > 1 file changed, 38 insertions(+)
> > >
> > > diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
> > > index 27db14c..8cafdb0 100644
> > > --- a/libavcodec/mpeg12dec.c
> > > +++ b/libavcodec/mpeg12dec.c
> > > @@ -2260,6 +2260,44 @@ static int mpeg_decode_a53_cc(AVCodecContext
> > *avctx,
> > > avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
> > > }
> > > return 1;
> > > +} else if (buf_size >= 2 &&
> > > + p[0] == 0x03 && (p[1]&0x7f) == 0x01) {
> > > +/* extract SCTE-20 CC data */
> > > +GetBitContext gb;
> > > +int cc_count = 0;
> > > +int i;
> > > +
> > > +init_get_bits(&gb, p + 2, buf_size - 2);
> > > +cc_count = get_bits(&gb, 5);
> > > +if (cc_count > 0) {
> > > +av_freep(&s1->a53_caption);
> > > +s1->a53_caption_size = cc_count * 3;
> > > +s1->a53_caption = av_malloc(s1->a53_caption_size);
> > > +if (s1->a53_caption) {
> >
> > a53_caption_size should be reset to 0 if allocation fails to keep the
> > fields consistent
> >
>
> The other branches in this function all follow the same pattern, and will
> not reset a53_caption_size on malloc failure.
>
> Would you like me to fix all of them?
i think it would be more robust to reset it, yes, in a seperate patch
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 1/2] avcodec/mpeg12dec: parse A53 caption data embedded in SCTE-20 user data
From: Aman Gupta
includes a fate test, which requires
https://s3.amazonaws.com/tmm1/ccaptions/scte20.ts
to be uploaded as sub/scte20.ts
---
libavcodec/mpeg12dec.c | 39 +++
tests/fate/subtitles.mak | 3 +++
tests/ref/fate/sub-cc-scte20 | 15 +++
3 files changed, 57 insertions(+)
create mode 100644 tests/ref/fate/sub-cc-scte20
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index e49167f..cea8963 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -2260,6 +2260,45 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
}
return 1;
+} else if (buf_size >= 2 &&
+ p[0] == 0x03 && (p[1]&0x7f) == 0x01) {
+/* extract SCTE-20 CC data */
+GetBitContext gb;
+int cc_count = 0;
+int i;
+
+init_get_bits(&gb, p + 2, buf_size - 2);
+cc_count = get_bits(&gb, 5);
+if (cc_count > 0) {
+av_freep(&s1->a53_caption);
+s1->a53_caption_size = cc_count * 3;
+s1->a53_caption = av_malloc(s1->a53_caption_size);
+if (s1->a53_caption) {
+uint8_t field, cc1, cc2;
+uint8_t *cap = s1->a53_caption;
+for (i = 0; i < cc_count; i++) {
+skip_bits(&gb, 2); // priority
+field = get_bits(&gb, 2);
+skip_bits(&gb, 5); // line_offset
+cc1 = get_bits(&gb, 8);
+cc2 = get_bits(&gb, 8);
+skip_bits(&gb, 1); // marker
+
+if (!field) { // forbidden
+cap[0] = cap[1] = cap[2] = 0x00;
+} else {
+field = (field == 2 ? 1 : 0);
+if (!s1->mpeg_enc_ctx.top_field_first) field = !field;
+cap[0] = 0x04 | field;
+cap[1] = ff_reverse[cc1];
+cap[2] = ff_reverse[cc2];
+}
+cap += 3;
+}
+}
+avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
+}
+return 1;
} else if (buf_size >= 11 &&
p[0] == 'C' && p[1] == 'C' && p[2] == 0x01 && p[3] == 0xf8) {
/* extract DVD CC data
diff --git a/tests/fate/subtitles.mak b/tests/fate/subtitles.mak
index fc2b192..0963479 100644
--- a/tests/fate/subtitles.mak
+++ b/tests/fate/subtitles.mak
@@ -7,6 +7,9 @@ fate-sub-cc: CMD = fmtstdout ass -f lavfi -i
"movie=$(TARGET_SAMPLES)/sub/Closed
FATE_SUBTITLES_ASS-$(call ALLYES, AVDEVICE LAVFI_INDEV CCAPTION_DECODER
MOVIE_FILTER MPEGTS_DEMUXER) += fate-sub-cc-realtime
fate-sub-cc-realtime: CMD = fmtstdout ass -real_time 1 -f lavfi -i
"movie=$(TARGET_SAMPLES)/sub/Closedcaption_rollup.m2v[out0+subcc]"
+FATE_SUBTITLES_ASS-$(call ALLYES, AVDEVICE LAVFI_INDEV CCAPTION_DECODER
MOVIE_FILTER MPEGTS_DEMUXER) += fate-sub-cc-scte20
+fate-sub-cc-scte20: CMD = fmtstdout ass -f lavfi -i
"movie=$(TARGET_SAMPLES)/sub/scte20.ts[out0+subcc]"
+
FATE_SUBTITLES_ASS-$(call DEMDEC, ASS, ASS) += fate-sub-ass-to-ass-transcode
fate-sub-ass-to-ass-transcode: CMD = fmtstdout ass -i
$(TARGET_SAMPLES)/sub/1ededcbd7b.ass
diff --git a/tests/ref/fate/sub-cc-scte20 b/tests/ref/fate/sub-cc-scte20
new file mode 100644
index 000..71fc92b
--- /dev/null
+++ b/tests/ref/fate/sub-cc-scte20
@@ -0,0 +1,15 @@
+[Script Info]
+; Script generated by FFmpeg/Lavc
+ScriptType: v4.00+
+PlayResX: 384
+PlayResY: 288
+
+[V4+ Styles]
+Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour,
OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY,
Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR,
MarginV, Encoding
+Style:
Default,Monospace,16,&Hff,&Hff,&H0,&H0,0,0,0,0,100,100,0,0,3,1,0,2,10,10,10,0
+
+[Events]
+Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
+Dialogue: 0,0:00:00.00,0:00:01.44,Default,,0,0,0,,{\an7}{\pos(48,182)}BESIDES
THE
+Dialogue:
0,0:00:01.43,0:00:03.93,Default,,0,0,0,,{\an7}{\pos(38,166)}\hBESIDES THE
\N{\an7}{\pos(38,197)}SPENDING AND THIS, IS THAT CAR
+Dialogue: 0,0:00:03.94,0:00:06.31,Default,,0,0,0,,{\an7}{\pos(38,182)}SPENDING
AND THIS, IS THAT CAR \N{\an7}{\pos(38,197)}MANUFACTURERS ARE ABOUT AS
--
2.10.1 (Apple Git-78)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 2/2] avcodec/mpeg12dec: ensure a53_caption_size is reset on malloc failures
From: Aman Gupta
---
libavcodec/mpeg12dec.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index cea8963..f71f207 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -2255,8 +2255,11 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
av_freep(&s1->a53_caption);
s1->a53_caption_size = cc_count * 3;
s1->a53_caption = av_malloc(s1->a53_caption_size);
-if (s1->a53_caption)
+if (!s1->a53_caption) {
+s1->a53_caption_size = 0;
+} else {
memcpy(s1->a53_caption, p + 7, s1->a53_caption_size);
+}
avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
}
return 1;
@@ -2273,7 +2276,9 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
av_freep(&s1->a53_caption);
s1->a53_caption_size = cc_count * 3;
s1->a53_caption = av_malloc(s1->a53_caption_size);
-if (s1->a53_caption) {
+if (!s1->a53_caption) {
+s1->a53_caption_size = 0;
+} else {
uint8_t field, cc1, cc2;
uint8_t *cap = s1->a53_caption;
for (i = 0; i < cc_count; i++) {
@@ -2337,7 +2342,9 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
av_freep(&s1->a53_caption);
s1->a53_caption_size = cc_count * 6;
s1->a53_caption = av_malloc(s1->a53_caption_size);
-if (s1->a53_caption) {
+if (!s1->a53_caption) {
+s1->a53_caption_size = 0;
+} else {
uint8_t field1 = !!(p[4] & 0x80);
uint8_t *cap = s1->a53_caption;
p += 5;
--
2.10.1 (Apple Git-78)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 1/2] avcodec/mpeg12dec: parse A53 caption data embedded in SCTE-20 user data
On Wed, Mar 15, 2017 at 12:53:03PM -0700, Aman Gupta wrote:
> From: Aman Gupta
>
> includes a fate test, which requires
> https://s3.amazonaws.com/tmm1/ccaptions/scte20.ts
> to be uploaded as sub/scte20.ts
uploaded
> ---
> libavcodec/mpeg12dec.c | 39 +++
> tests/fate/subtitles.mak | 3 +++
> tests/ref/fate/sub-cc-scte20 | 15 +++
> 3 files changed, 57 insertions(+)
> create mode 100644 tests/ref/fate/sub-cc-scte20
>
> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
> index e49167f..cea8963 100644
> --- a/libavcodec/mpeg12dec.c
> +++ b/libavcodec/mpeg12dec.c
> @@ -2260,6 +2260,45 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
> avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
> }
> return 1;
> +} else if (buf_size >= 2 &&
> + p[0] == 0x03 && (p[1]&0x7f) == 0x01) {
> +/* extract SCTE-20 CC data */
> +GetBitContext gb;
> +int cc_count = 0;
> +int i;
> +
> +init_get_bits(&gb, p + 2, buf_size - 2);
> +cc_count = get_bits(&gb, 5);
> +if (cc_count > 0) {
remainig bits or buf_size should be checked to be large enough for
cc_count
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 2/2] avcodec/mpeg12dec: ensure a53_caption_size is reset on malloc failures
On Wed, Mar 15, 2017 at 12:53:04PM -0700, Aman Gupta wrote: > From: Aman Gupta > > --- > libavcodec/mpeg12dec.c | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] spherical: Change types of bounding and pad to uint32_t
These values are defined to be 32bit in the specification,
so it makes more sense to store them as fixed width.
Signed-off-by: Vittorio Giovara
---
Updated commit message, changed a couple of internal types.
Please CC or I can't see replies.
Vittorio
libavformat/dump.c| 2 +-
libavformat/matroskadec.c | 6 +++---
libavformat/mov.c | 7 +++
libavutil/spherical.h | 10 +-
4 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 7514aee7ac..c56895628d 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -339,7 +339,7 @@ static void dump_spherical(void *ctx, AVCodecParameters
*par, AVPacketSideData *
&l, &t, &r, &b);
av_log(ctx, AV_LOG_INFO, "[%zu, %zu, %zu, %zu] ", l, t, r, b);
} else if (spherical->projection == AV_SPHERICAL_CUBEMAP) {
-av_log(ctx, AV_LOG_INFO, "[pad %zu] ", spherical->padding);
+av_log(ctx, AV_LOG_INFO, "[pad %"PRIu32"] ", spherical->padding);
}
}
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 4fbf4b9a96..c6e1a190a8 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1601,8 +1601,8 @@ static int mkv_parse_video_projection(AVStream *st, const
MatroskaTrack *track)
AVSphericalMapping *spherical;
enum AVSphericalProjection projection;
size_t spherical_size;
-size_t l = 0, t = 0, r = 0, b = 0;
-size_t padding = 0;
+uint32_t l = 0, t = 0, r = 0, b = 0;
+uint32_t padding = 0;
int ret;
GetByteContext gb;
@@ -1627,7 +1627,7 @@ static int mkv_parse_video_projection(AVStream *st, const
MatroskaTrack *track)
if (b >= UINT_MAX - t || r >= UINT_MAX - l) {
av_log(NULL, AV_LOG_ERROR,
"Invalid bounding rectangle coordinates "
- "%zu,%zu,%zu,%zu\n", l, t, r, b);
+ "%"PRIu32",%"PRIu32",%"PRIu32",%"PRIu32"\n", l, t, r,
b);
return AVERROR_INVALIDDATA;
}
} else if (track->video.projection.private.size != 0) {
diff --git a/libavformat/mov.c b/libavformat/mov.c
index c6e7a38398..1c1857eaf9 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3237,9 +3237,8 @@ static int mov_read_sv3d(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
MOVStreamContext *sc;
int size, version, layout;
int32_t yaw, pitch, roll;
-size_t l = 0, t = 0, r = 0, b = 0;
-size_t padding = 0;
-uint32_t tag;
+uint32_t l = 0, t = 0, r = 0, b = 0;
+uint32_t tag, padding = 0;
enum AVSphericalProjection projection;
if (c->fc->nb_streams < 1)
@@ -3335,7 +3334,7 @@ static int mov_read_sv3d(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
if (b >= UINT_MAX - t || r >= UINT_MAX - l) {
av_log(c->fc, AV_LOG_ERROR,
"Invalid bounding rectangle coordinates "
- "%zu,%zu,%zu,%zu\n", l, t, r, b);
+ "%"PRIu32",%"PRIu32",%"PRIu32",%"PRIu32"\n", l, t, r, b);
return AVERROR_INVALIDDATA;
}
diff --git a/libavutil/spherical.h b/libavutil/spherical.h
index e7fc1d69fb..fd662cf676 100644
--- a/libavutil/spherical.h
+++ b/libavutil/spherical.h
@@ -164,10 +164,10 @@ typedef struct AVSphericalMapping {
* projection type (@ref AV_SPHERICAL_EQUIRECTANGULAR_TILE),
* and should be ignored in all other cases.
*/
-size_t bound_left; ///< Distance from the left edge
-size_t bound_top;///< Distance from the top edge
-size_t bound_right; ///< Distance from the right edge
-size_t bound_bottom; ///< Distance from the bottom edge
+uint32_t bound_left; ///< Distance from the left edge
+uint32_t bound_top;///< Distance from the top edge
+uint32_t bound_right; ///< Distance from the right edge
+uint32_t bound_bottom; ///< Distance from the bottom edge
/**
* @}
*/
@@ -179,7 +179,7 @@ typedef struct AVSphericalMapping {
* (@ref AV_SPHERICAL_CUBEMAP), and should be ignored in all other
* cases.
*/
-size_t padding;
+uint32_t padding;
} AVSphericalMapping;
/**
--
2.12.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libswscale/swscale_unscaled: fix DITHER_COPY macro
Hello!
There are 3 problems with DITHER_COPY macro in libswscale/swscale_unscaled.c:
1) there is overflow in dithering from 12-bit to 10-bit (output value > 1023);
2) for limit range the lower limit is not respected, for example from 10-bit to
8-bit value 64 is converted to 15;
3) for many iteration of downscale/upscale of the same image the 200th
iteration is significantly darker.
The first bug is due to wrong dithers table (now it is OK only for 8-bit
destination), fix is:
-const uint8_t *dither= dithers[src_depth-9][i&7];\
+const uint8_t *dither= dithers[src_depth-dst_depth-1][i&7];\
For bugs 2) and 3) it is needed formula that do not make images darker (in
attachment). So please review.
Mateusz
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index ba3d688..429c98c 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -110,24 +110,6 @@ DECLARE_ALIGNED(8, static const uint8_t,
dithers)[8][8][8]={
{ 112, 16,104, 8,118, 22,110, 14,},
}};
-static const uint16_t dither_scale[15][16]={
-{2,3,3,5,5,5,5,5,5,5,5,5,
5,5,5,5,},
-{2,3,7,7, 13, 13, 25, 25, 25, 25, 25, 25,
25, 25, 25, 25,},
-{3,3,4, 15, 15, 29, 57, 57, 57, 113, 113, 113,
113, 113, 113, 113,},
-{3,4,4,5, 31, 31, 61, 121, 241, 241, 241, 241,
481, 481, 481, 481,},
-{3,4,5,5,6, 63, 63, 125, 249, 497, 993, 993,
993, 993, 993, 1985,},
-{3,5,6,6,6,7, 127, 127, 253, 505, 1009, 2017,
4033, 4033, 4033, 4033,},
-{3,5,6,7,7,7,8, 255, 255, 509, 1017, 2033,
4065, 8129,16257,16257,},
-{3,5,6,8,8,8,8,9, 511, 511, 1021, 2041,
4081, 8161,16321,32641,},
-{3,5,7,8,9,9,9,9, 10, 1023, 1023, 2045,
4089, 8177,16353,32705,},
-{3,5,7,8, 10, 10, 10, 10, 10, 11, 2047, 2047,
4093, 8185,16369,32737,},
-{3,5,7,8, 10, 11, 11, 11, 11, 11, 12, 4095,
4095, 8189,16377,32753,},
-{3,5,7,9, 10, 12, 12, 12, 12, 12, 12, 13,
8191, 8191,16381,32761,},
-{3,5,7,9, 10, 12, 13, 13, 13, 13, 13, 13,
14,16383,16383,32765,},
-{3,5,7,9, 10, 12, 14, 14, 14, 14, 14, 14,
14, 15,32767,32767,},
-{3,5,7,9, 11, 12, 14, 15, 15, 15, 15, 15,
15, 15, 16,65535,},
-};
-
static void fillPlane(uint8_t *plane, int stride, int width, int height, int y,
uint8_t val)
@@ -1485,22 +1467,22 @@ static int packedCopyWrapper(SwsContext *c, const
uint8_t *src[],
}
#define DITHER_COPY(dst, dstStride, src, srcStride, bswap, dbswap)\
-uint16_t scale= dither_scale[dst_depth-1][src_depth-1];\
-int shift= src_depth-dst_depth + dither_scale[src_depth-2][dst_depth-1];\
+int scale= 31-src_depth, shift= 31-dst_depth;\
for (i = 0; i < height; i++) {\
-const uint8_t *dither= dithers[src_depth-9][i&7];\
+const uint8_t *dither= dithers[src_depth-dst_depth-1][i&7];\
for (j = 0; j < length-7; j+=8){\
-dst[j+0] = dbswap((bswap(src[j+0]) + dither[0])*scale>>shift);\
-dst[j+1] = dbswap((bswap(src[j+1]) + dither[1])*scale>>shift);\
-dst[j+2] = dbswap((bswap(src[j+2]) + dither[2])*scale>>shift);\
-dst[j+3] = dbswap((bswap(src[j+3]) + dither[3])*scale>>shift);\
-dst[j+4] = dbswap((bswap(src[j+4]) + dither[4])*scale>>shift);\
-dst[j+5] = dbswap((bswap(src[j+5]) + dither[5])*scale>>shift);\
-dst[j+6] = dbswap((bswap(src[j+6]) + dither[6])*scale>>shift);\
-dst[j+7] = dbswap((bswap(src[j+7]) + dither[7])*scale>>shift);\
+int32_t tmp = (bswap(src[j+0]) + (unsigned)dither[0])<>31)) & 0x7FFF; dst[j+0] = dbswap(tmp>>shift);\
+tmp = (bswap(src[j+1]) + (unsigned)dither[1])<>31)) & 0x7FFF; dst[j+1] = dbswap(tmp>>shift);\
+tmp = (bswap(src[j+2]) + (unsigned)dither[2])<>31)) & 0x7FFF; dst[j+2] = dbswap(tmp>>shift);\
+tmp = (bswap(src[j+3]) + (unsigned)dither[3])<>31)) & 0x7FFF; dst[j+3] = dbswap(tmp>>shift);\
+tmp = (bswap(src[j+4]) + (unsigned)dither[4])<>31)) & 0x7FFF; dst[j+4] = dbswap(tmp>>shift);\
+tmp = (bswap(src[j+5]) + (unsigned)dither[5])<>31)) & 0x7FFF; dst[j+5] = dbswap(tmp>>shift);\
+tmp = (bswap(src[j+6]) + (unsigned)dither[6])<>31)) & 0x7FFF; dst[j+6] = dbswap(tmp>>shift);\
+tmp = (bswap(src[j+7]) + (unsigned)dither[7])<>31)) & 0x7FFF; dst[j+7] = dbswap(tmp>>shift);\
+}\
+for (; j < length; j++){\
+int32_t tmp = (bswap(src[j]) + (unsigned)dither[j&7])<>31)) & 0x7FFF; dst[j] = dbswap(tmp>>shift);\
}\
-
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vp56: Require 1 undamaged frame for 5 damaged frames for concealment to be used
On Wed, Mar 15, 2017 at 07:18:30PM +, Kieran Kunhya wrote: > > > > > > I have tons of testcases for h264 that are 1KB and can make error > > > > concealment run for ages. > > > > and how is this related to a fix for th vp* decoder ? > > > > My point is you can spend a lifetime fixing obscure conditions that cause > error concealment to take a long time. the vp56 EC code just sets every block to the reference frames content, thats speedwise at the level of a memcpy() or memset(). if its slow thats because the resolution is high and the frame has few bytes resulting in lots of pixels being initilaized from just frame headers data. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix duration wrong when no pkt duration
Hi!
On 2017-03-13 17:12 +0800, Steven Liu wrote:
> when cannot get pkt duration, hlsenc segments duration will
> be set to 0, this patch can fix it.
>
> Signed-off-by: Steven Liu
> ---
> libavformat/hlsenc.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 5df2514..d6f0631 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -1354,7 +1354,12 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> * st->time_base.num /
> st->time_base.den;
> hls->dpp = (double)(pkt->duration) * st->time_base.num /
> st->time_base.den;
> } else {
> -hls->duration += (double)(pkt->duration) * st->time_base.num /
> st->time_base.den;
> +if (pkt->duration) {
> +hls->duration += (double)(pkt->duration) * st->time_base.num
> / st->time_base.den;
> +} else {
> +av_log(s, AV_LOG_WARNING, "pkt->duration = 0, maybe the hls
> segment duration will not precise\n");
^
There is a word missing in the log message: "be"
For a warning it might have been better to use more natural language and to
convey a bit more information:
"Packet duration is 0. Trying to compensate. Segment duration may not be
accurate.\n"
> +hls->duration = (double)(pkt->pts - hls->end_pts) *
> st->time_base.num / st->time_base.den;
> +}
> }
>
> }
I am sorry to comment after you pushed already. Anyway my remarks are only
cosmetics and not so important. I did not investigate the issue at all.
Thank you,
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vp56: Require 1 undamaged frame for 5 damaged frames for concealment to be used
Hi!
This is not a review, just a comment you can address in case you push this.
On 2017-03-15 04:12 +0100, Michael Niedermayer wrote:
> Fixes timeout with 847/clusterfuzz-testcase-5291877358108672
> Fixes timeout with 850/clusterfuzz-testcase-5721296509861888
>
> This likely will need to be tweaked
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/vp56.c | 10 +++---
> libavcodec/vp56.h | 1 +
> 2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/vp56.c b/libavcodec/vp56.c
> index 9d4162bb96..b4ee760080 100644
> --- a/libavcodec/vp56.c
> +++ b/libavcodec/vp56.c
> @@ -508,6 +508,7 @@ static int vp56_size_changed(VP56Context *s)
> s->plane_height[1] = s->plane_height[2] = avctx->coded_height/2;
>
> s->have_undamaged_frame = 0;
> +s->damaged_frame_count = 0;
>
> for (i=0; i<4; i++)
> s->stride[i] = s->flip * s->frames[VP56_FRAME_CURRENT]->linesize[i];
> @@ -712,8 +713,9 @@ static int ff_vp56_decode_mbs(AVCodecContext *avctx, void
> *data,
> int ret = vp56_decode_mb(s, mb_row, mb_col, is_alpha);
> if (ret < 0) {
> damaged = 1;
> -if (!s->have_undamaged_frame) {
> +if (5*s->have_undamaged_frame <= s->damaged_frame_count)
> {
> s->discard_frame = 1;
> +s->damaged_frame_count ++;
If I am not mistaken, the space before ++ is not needed and not usual for
FFmpeg's code base.
> return AVERROR_INVALIDDATA;
> }
> }
> @@ -733,8 +735,10 @@ static int ff_vp56_decode_mbs(AVCodecContext *avctx,
> void *data,
> }
> }
>
> -if (!damaged)
> -s->have_undamaged_frame = 1;
> +if (!damaged) {
> +s->have_undamaged_frame ++;
> +} else
> +s->damaged_frame_count ++;
Same.
>
> next:
> if (p->key_frame || s->golden_frame) {
> diff --git a/libavcodec/vp56.h b/libavcodec/vp56.h
> index c049399df8..37837d0c7b 100644
> --- a/libavcodec/vp56.h
> +++ b/libavcodec/vp56.h
> @@ -206,6 +206,7 @@ struct vp56_context {
>
> int have_undamaged_frame;
> int discard_frame;
> +int damaged_frame_count;
> };
>
>
> --
> 2.11.0
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 1/2] avcodec/mpeg12dec: parse A53 caption data embedded in SCTE-20 user data
On Wed, Mar 15, 2017 at 2:06 PM, Michael Niedermayer wrote:
> On Wed, Mar 15, 2017 at 12:53:03PM -0700, Aman Gupta wrote:
> > From: Aman Gupta
> >
> > includes a fate test, which requires
> > https://s3.amazonaws.com/tmm1/ccaptions/scte20.ts
> > to be uploaded as sub/scte20.ts
>
> uploaded
>
>
>
> > ---
> > libavcodec/mpeg12dec.c | 39 ++
> +
> > tests/fate/subtitles.mak | 3 +++
> > tests/ref/fate/sub-cc-scte20 | 15 +++
> > 3 files changed, 57 insertions(+)
> > create mode 100644 tests/ref/fate/sub-cc-scte20
> >
> > diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
> > index e49167f..cea8963 100644
> > --- a/libavcodec/mpeg12dec.c
> > +++ b/libavcodec/mpeg12dec.c
> > @@ -2260,6 +2260,45 @@ static int mpeg_decode_a53_cc(AVCodecContext
> *avctx,
> > avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
> > }
> > return 1;
> > +} else if (buf_size >= 2 &&
> > + p[0] == 0x03 && (p[1]&0x7f) == 0x01) {
> > +/* extract SCTE-20 CC data */
> > +GetBitContext gb;
> > +int cc_count = 0;
> > +int i;
> > +
> > +init_get_bits(&gb, p + 2, buf_size - 2);
> > +cc_count = get_bits(&gb, 5);
> > +if (cc_count > 0) {
>
> remainig bits or buf_size should be checked to be large enough for
> cc_count
>
Good catch. Changing to buf_size>=3 in the outer conditional should be
sufficient, right?
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Complexity theory is the science of finding the exact solution to an
> approximation. Benchmarking OTOH is finding an approximation of the exact
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/wavpack: Fix multiple integer overflows
On Tue, Mar 14, 2017 at 01:52:23AM +0100, Michael Niedermayer wrote: > Fixes: 839/clusterfuzz-testcase-4871084446842880 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/wavpack.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) patchset applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] avcodec/simple_idct_template: Fix several integer overflows
On Tue, Mar 14, 2017 at 10:20:45PM +0100, Michael Niedermayer wrote: > On Mon, Mar 13, 2017 at 12:53:27PM +0100, Michael Niedermayer wrote: > > On Mon, Mar 13, 2017 at 09:51:40AM +0100, Paul B Mahol wrote: > > > On 3/13/17, Michael Niedermayer wrote: > > > > Benchmarks with START_TIMER indicate that the code is faster with > > > > unsigned, > > > > (that is > > > > with the patch), there was quite some fluctuation in the numbers so > > > > this may > > > > be just > > > > random > > > > > > > > Fixes: 811/clusterfuzz-testcase-6465493076541440 > > > > > > > > Found-by: continuous fuzzing process > > > > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg > > > > Signed-off-by: Michael Niedermayer > > > > --- > > > > libavcodec/simple_idct_template.c | 36 > > > > ++-- > > > > 1 file changed, 18 insertions(+), 18 deletions(-) > > > > > > > > > > So this fixes remote code execution? > > > > It fixes integer overflows which are undefined behavior, > > i very much doubt this allows any RCE in practive anywhere but > > strictly speaking undefined means anything can happen > > > > > > > > > > Please state what commit fixes. > > > > Please see the first line of the commit message, which git puts in > > the subject of the mail: > > > > Subject: Re: [FFmpeg-devel] [PATCH 3/4] avcodec/simple_idct_template: Fix > > several integer overflows > > i will apply the patch in 24h unless there is an objection applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vp56: Require 1 undamaged frame for 5 damaged frames for concealment to be used
Hi, On Wed, Mar 15, 2017 at 6:12 PM, Michael Niedermayer wrote: > On Wed, Mar 15, 2017 at 07:18:30PM +, Kieran Kunhya wrote: > > > > > > > > I have tons of testcases for h264 that are 1KB and can make error > > > > > concealment run for ages. > > > > > > and how is this related to a fix for th vp* decoder ? > > > > > > > My point is you can spend a lifetime fixing obscure conditions that cause > > error concealment to take a long time. > > the vp56 EC code > just sets every block to the reference frames content I don't see how this helps the user experience. I once again think you should consider removing the vp56 EC code until we have a better idea of requirements of and need for such a feature. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] Add experimental support for Opus in ISO BMFF (MP4)
Hi,
The attached patch adds experimental muxing support for Opus audio codec in
ISOBMFF/MP4. This is based on v0.6.8 of the draft spec at
https://vfrmaniac.fushizen.eu/contents/opus_in_isobmff.html.
Firefox supports demuxing/playback of these files since Firefox 50.
>From cff9b592d4efd87e80120fb3fce07ccb7e857a9d Mon Sep 17 00:00:00 2001
From: Matthew Gregan
Date: Thu, 16 Mar 2017 14:17:12 +1300
Subject: [PATCH 1/2] Add experimental muxing support for Opus in ISO BMFF
(MP4).
Based on the draft spec at http://vfrmaniac.fushizen.eu/contents/opus_in_isobmff.html
'-strict -2' is required to create files in this format.
Signed-off-by: Matthew Gregan
---
libavformat/isom.c | 2 +
libavformat/movenc.c | 137 ---
2 files changed, 131 insertions(+), 8 deletions(-)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index 7da2700842..3a932dae08 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -59,6 +59,7 @@ const AVCodecTag ff_mp4_obj_type[] = {
{ AV_CODEC_ID_AC3 , 0xA5 },
{ AV_CODEC_ID_EAC3, 0xA6 },
{ AV_CODEC_ID_DTS , 0xA9 }, /* mp4ra.org */
+{ AV_CODEC_ID_OPUS, 0xAD }, /* mp4ra.org */
{ AV_CODEC_ID_VP9 , 0xC0 }, /* nonstandard, update when there is a standard value */
{ AV_CODEC_ID_FLAC, 0xC1 }, /* nonstandard, update when there is a standard value */
{ AV_CODEC_ID_TSCC2 , 0xD0 }, /* nonstandard, camtasia uses it */
@@ -357,6 +358,7 @@ const AVCodecTag ff_codec_movaudio_tags[] = {
{ AV_CODEC_ID_EVRC,MKTAG('s', 'e', 'v', 'c') }, /* 3GPP2 */
{ AV_CODEC_ID_SMV, MKTAG('s', 's', 'm', 'v') }, /* 3GPP2 */
{ AV_CODEC_ID_FLAC,MKTAG('f', 'L', 'a', 'C') }, /* nonstandard */
+{ AV_CODEC_ID_OPUS,MKTAG('O', 'p', 'u', 's') }, /* mp4ra.org */
{ AV_CODEC_ID_NONE, 0 },
};
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index a28621080d..8e82a8b15f 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -676,6 +676,29 @@ static int mov_write_dfla_tag(AVIOContext *pb, MOVTrack *track)
return update_size(pb, pos);
}
+static int mov_write_dops_tag(AVIOContext *pb, MOVTrack *track)
+{
+int64_t pos = avio_tell(pb);
+avio_wb32(pb, 0);
+ffio_wfourcc(pb, "dOps");
+avio_w8(pb, 0); /* Version */
+if (track->par->extradata_size < 19) {
+av_log(pb, AV_LOG_ERROR, "invalid extradata size\n");
+return AVERROR_INVALIDDATA;
+}
+/* extradata contains an Ogg OpusHead, other than byte-ordering and
+ OpusHead's preceeding magic/version, OpusSpecificBox is currently
+ identical. */
+avio_w8(pb, AV_RB8(track->par->extradata + 9)); /* OuputChannelCount */
+avio_wb16(pb, AV_RL16(track->par->extradata + 10)); /* PreSkip */
+avio_wb32(pb, AV_RL32(track->par->extradata + 12)); /* InputSampleRate */
+avio_wb16(pb, AV_RL16(track->par->extradata + 16)); /* OutputGain */
+/* Write the rest of the header out without byte-swapping. */
+avio_write(pb, track->par->extradata + 18, track->par->extradata_size - 18);
+
+return update_size(pb, pos);
+}
+
static int mov_write_chan_tag(AVFormatContext *s, AVIOContext *pb, MOVTrack *track)
{
uint32_t layout_tag, bitmap;
@@ -985,19 +1008,26 @@ static int mov_write_audio_tag(AVFormatContext *s, AVIOContext *pb, MOVMuxContex
avio_wb16(pb, 16);
avio_wb16(pb, track->audio_vbr ? -2 : 0); /* compression ID */
} else { /* reserved for mp4/3gp */
-if (track->par->codec_id == AV_CODEC_ID_FLAC) {
+if (track->par->codec_id == AV_CODEC_ID_FLAC ||
+track->par->codec_id == AV_CODEC_ID_OPUS) {
avio_wb16(pb, track->par->channels);
-avio_wb16(pb, track->par->bits_per_raw_sample);
} else {
avio_wb16(pb, 2);
+}
+if (track->par->codec_id == AV_CODEC_ID_FLAC) {
+avio_wb16(pb, track->par->bits_per_raw_sample);
+} else {
avio_wb16(pb, 16);
}
avio_wb16(pb, 0);
}
avio_wb16(pb, 0); /* packet size (= 0) */
-avio_wb16(pb, track->par->sample_rate <= UINT16_MAX ?
- track->par->sample_rate : 0);
+if (track->par->codec_id == AV_CODEC_ID_OPUS)
+avio_wb16(pb, 48000);
+else
+avio_wb16(pb, track->par->sample_rate <= UINT16_MAX ?
+ track->par->sample_rate : 0);
avio_wb16(pb, 0); /* Reserved */
}
@@ -1038,6 +1068,8 @@ static int mov_write_audio_tag(AVFormatContext *s, AVIOContext *pb, MOVMuxContex
mov_write_wfex_tag(s, pb, track);
else if (track->par->codec_id == AV_CODEC_ID_FLAC)
mov_write_dfla_tag(pb, track);
+else if (track->par->codec_id == AV_CODEC_ID_OPUS)
+mov_write_dops_tag(pb, track);
else if (track->vos_len
[FFmpeg-devel] [PATCH 2/2] Add experimental support for Opus in ISO BMFF (MP4)
Hi,
The attached patch adds demuxing support for Opus audio codec in
ISOBMFF/MP4. This is based on v0.6.8 of the draft spec at
https://vfrmaniac.fushizen.eu/contents/opus_in_isobmff.html.
Firefox supports demuxing/playback of these files since Firefox 50.
>From 9d6f1b4c12b08cf5fbba61bdeb31c785aa1a6a5f Mon Sep 17 00:00:00 2001
From: Matthew Gregan
Date: Thu, 16 Mar 2017 14:17:21 +1300
Subject: [PATCH 2/2] Add experimental demuxing support for Opus in ISO BMFF
(MP4).
Based on the draft spec at http://vfrmaniac.fushizen.eu/contents/opus_in_isobmff.html
Signed-off-by: Matthew Gregan
---
libavformat/mov.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index d5c3949050..324d628985 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5246,6 +5246,54 @@ static int cenc_filter(MOVContext *c, MOVStreamContext *sc, int64_t index, uint8
return 0;
}
+static int mov_read_dops(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+const int OPUS_SEEK_PREROLL_MS = 80;
+AVStream *st;
+size_t size;
+int16_t pre_skip;
+
+if (c->fc->nb_streams < 1)
+return 0;
+st = c->fc->streams[c->fc->nb_streams-1];
+
+if ((uint64_t)atom.size > (1<<30) || atom.size < 11)
+return AVERROR_INVALIDDATA;
+
+/* Check OpusSpecificBox version. */
+if (avio_r8(pb) != 0) {
+av_log(c->fc, AV_LOG_ERROR, "unsupported OpusSpecificBox version\n");
+return AVERROR_INVALIDDATA;
+}
+
+/* OpusSpecificBox size plus magic for Ogg OpusHead header. */
+size = atom.size + 16;
+
+if (ff_alloc_extradata(st->codecpar, size))
+return AVERROR(ENOMEM);
+
+AV_WL32(st->codecpar->extradata, MKTAG('O','p','u','s'));
+AV_WL32(st->codecpar->extradata + 4, MKTAG('H','e','a','d'));
+AV_WB8(st->codecpar->extradata + 8, 1); /* OpusHead version */
+avio_read(pb, st->codecpar->extradata + 9, size - 17);
+
+/* OpusSpecificBox is stored in big-endian, but OpusHead is
+ little-endian; aside from the preceeding magic and version they're
+ otherwise currently identical. Data after output gain at offset 16
+ doesn't need to be bytewapped. */
+pre_skip = AV_RB16(st->codecpar->extradata + 10);
+AV_WL16(st->codecpar->extradata + 10, pre_skip);
+AV_WL32(st->codecpar->extradata + 12, AV_RB32(st->codecpar->extradata + 12));
+AV_WL16(st->codecpar->extradata + 16, AV_RB16(st->codecpar->extradata + 16));
+
+st->codecpar->initial_padding = pre_skip;
+st->codecpar->seek_preroll = av_rescale_q(OPUS_SEEK_PREROLL_MS,
+ (AVRational){1, 1000},
+ (AVRational){1, 48000});
+
+return 0;
+}
+
static const MOVParseTableEntry mov_default_parse_table[] = {
{ MKTAG('A','C','L','R'), mov_read_aclr },
{ MKTAG('A','P','R','G'), mov_read_avid },
@@ -5327,6 +5375,7 @@ static const MOVParseTableEntry mov_default_parse_table[] = {
{ MKTAG('d','f','L','a'), mov_read_dfla },
{ MKTAG('s','t','3','d'), mov_read_st3d }, /* stereoscopic 3D video box */
{ MKTAG('s','v','3','d'), mov_read_sv3d }, /* spherical video box */
+{ MKTAG('d','O','p','s'), mov_read_dops },
{ 0, NULL }
};
--
2.12.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/h264_direct: Fix runtime error: signed integer overflow: -9 - 2147483647 cannot be represented in type 'int'
Fixes: 864/clusterfuzz-testcase-4774385942528000
See: [FFmpeg-devel] [PATCH 1/2] avcodec/h264_direct: Fix runtime error: signed
integer overflow: 2147483647 - -14133 cannot be represented in type 'int'
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/h264_direct.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264_direct.c b/libavcodec/h264_direct.c
index 66e54479d1..dac9f9d1a8 100644
--- a/libavcodec/h264_direct.c
+++ b/libavcodec/h264_direct.c
@@ -48,8 +48,13 @@ static int get_scale_factor(H264SliceContext *sl,
if (td == 0 || sl->ref_list[0][i].parent->long_ref) {
return 256;
} else {
-int tb = av_clip_int8(poc - poc0);
+int64_t pocdiff0 = poc - (int64_t)poc0;
+int tb = av_clip_int8(pocdiff0);
int tx = (16384 + (FFABS(td) >> 1)) / td;
+
+if (pocdiff0 != (int)pocdiff0)
+avpriv_request_sample(sl->h264->avctx, "pocdiff0 overflow\n");
+
return av_clip_intp2((tb * tx + 32) >> 6, 10);
}
}
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/tiff: Check stripsize strippos for overflow
Fixes: 861/clusterfuzz-testcase-5688284384591872
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/tiff.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 0be7be7528..5a6573fb79 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -914,6 +914,11 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame)
break;
case TIFF_STRIP_OFFS:
if (count == 1) {
+if (value > INT_MAX) {
+av_log(s->avctx, AV_LOG_ERROR,
+"strippos %u too large\n", value);
+return AVERROR_INVALIDDATA;
+}
s->strippos = 0;
s->stripoff = value;
} else
@@ -925,6 +930,11 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame)
break;
case TIFF_STRIP_SIZE:
if (count == 1) {
+if (value > INT_MAX) {
+av_log(s->avctx, AV_LOG_ERROR,
+"stripsize %u too large\n", value);
+return AVERROR_INVALIDDATA;
+}
s->stripsizesoff = 0;
s->stripsize = value;
s->strips= 1;
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/mpegtsenc: clarify pcr_period unit of measurement
pcr_period is in milliseconds.
Signed-off-by: Lou Logan
---
libavformat/mpegtsenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 0f394c5fe0..3250dde311 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -1945,7 +1945,7 @@ static const AVOption options[] = {
{ "omit_video_pes_length", "Omit the PES packet length for video packets",
offsetof(MpegTSWrite, omit_video_pes_length), AV_OPT_TYPE_BOOL,
{ .i64 = 1 }, 0, 1, AV_OPT_FLAG_ENCODING_PARAM },
-{ "pcr_period", "PCR retransmission time",
+{ "pcr_period", "PCR retransmission time in milliseconds",
offsetof(MpegTSWrite, pcr_period), AV_OPT_TYPE_INT,
{ .i64 = PCR_RETRANS_TIME }, 0, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
{ "pat_period", "PAT/PMT retransmission time limit in seconds",
--
2.12.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix duration wrong when no pkt duration
2017-03-16 6:24 GMT+08:00 Alexander Strasser :
> Hi!
>
> On 2017-03-13 17:12 +0800, Steven Liu wrote:
> > when cannot get pkt duration, hlsenc segments duration will
> > be set to 0, this patch can fix it.
> >
> > Signed-off-by: Steven Liu
> > ---
> > libavformat/hlsenc.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> > index 5df2514..d6f0631 100644
> > --- a/libavformat/hlsenc.c
> > +++ b/libavformat/hlsenc.c
> > @@ -1354,7 +1354,12 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> > * st->time_base.num /
> st->time_base.den;
> > hls->dpp = (double)(pkt->duration) * st->time_base.num /
> st->time_base.den;
> > } else {
> > -hls->duration += (double)(pkt->duration) *
> st->time_base.num / st->time_base.den;
> > +if (pkt->duration) {
> > +hls->duration += (double)(pkt->duration) *
> st->time_base.num / st->time_base.den;
> > +} else {
> > +av_log(s, AV_LOG_WARNING, "pkt->duration = 0, maybe the
> hls segment duration will not precise\n");
>
> ^
>
> There is a word missing in the log message: "be"
>
> For a warning it might have been better to use more natural language and
> to convey a bit more information:
>
> "Packet duration is 0. Trying to compensate. Segment duration may not be
> accurate.\n"
>
>
>
> > +hls->duration = (double)(pkt->pts - hls->end_pts) *
> st->time_base.num / st->time_base.den;
> > +}
> > }
> >
> > }
>
>
> I am sorry to comment after you pushed already. Anyway my remarks are
> only
> cosmetics and not so important. I did not investigate the issue at all.
>
>
> Thank you,
> Alexander
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Hi Alexander,
Your suggestion is right, i will merge it in next commit.
Thanks
Steven
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] spherical: Change types of bounding and pad to uint32_t
On 3/15/2017 6:39 PM, Vittorio Giovara wrote:
> These values are defined to be 32bit in the specification,
> so it makes more sense to store them as fixed width.
>
> Signed-off-by: Vittorio Giovara
> ---
> Updated commit message, changed a couple of internal types.
> Please CC or I can't see replies.
> Vittorio
Mention it's based on a patch by Michael Niedermayer.
>
> libavformat/dump.c| 2 +-
> libavformat/matroskadec.c | 6 +++---
> libavformat/mov.c | 7 +++
> libavutil/spherical.h | 10 +-
> 4 files changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/libavformat/dump.c b/libavformat/dump.c
> index 7514aee7ac..c56895628d 100644
> --- a/libavformat/dump.c
> +++ b/libavformat/dump.c
> @@ -339,7 +339,7 @@ static void dump_spherical(void *ctx, AVCodecParameters
> *par, AVPacketSideData *
> &l, &t, &r, &b);
> av_log(ctx, AV_LOG_INFO, "[%zu, %zu, %zu, %zu] ", l, t, r, b);
> } else if (spherical->projection == AV_SPHERICAL_CUBEMAP) {
> -av_log(ctx, AV_LOG_INFO, "[pad %zu] ", spherical->padding);
> +av_log(ctx, AV_LOG_INFO, "[pad %"PRIu32"] ", spherical->padding);
> }
> }
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 4fbf4b9a96..c6e1a190a8 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -1601,8 +1601,8 @@ static int mkv_parse_video_projection(AVStream *st,
> const MatroskaTrack *track)
> AVSphericalMapping *spherical;
> enum AVSphericalProjection projection;
> size_t spherical_size;
> -size_t l = 0, t = 0, r = 0, b = 0;
> -size_t padding = 0;
> +uint32_t l = 0, t = 0, r = 0, b = 0;
> +uint32_t padding = 0;
> int ret;
> GetByteContext gb;
>
> @@ -1627,7 +1627,7 @@ static int mkv_parse_video_projection(AVStream *st,
> const MatroskaTrack *track)
> if (b >= UINT_MAX - t || r >= UINT_MAX - l) {
> av_log(NULL, AV_LOG_ERROR,
> "Invalid bounding rectangle coordinates "
> - "%zu,%zu,%zu,%zu\n", l, t, r, b);
> + "%"PRIu32",%"PRIu32",%"PRIu32",%"PRIu32"\n", l, t, r,
> b);
This chunk doesn't apply.
> return AVERROR_INVALIDDATA;
> }
> } else if (track->video.projection.private.size != 0) {
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index c6e7a38398..1c1857eaf9 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -3237,9 +3237,8 @@ static int mov_read_sv3d(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> MOVStreamContext *sc;
> int size, version, layout;
> int32_t yaw, pitch, roll;
> -size_t l = 0, t = 0, r = 0, b = 0;
> -size_t padding = 0;
> -uint32_t tag;
> +uint32_t l = 0, t = 0, r = 0, b = 0;
> +uint32_t tag, padding = 0;
> enum AVSphericalProjection projection;
>
> if (c->fc->nb_streams < 1)
> @@ -3335,7 +3334,7 @@ static int mov_read_sv3d(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> if (b >= UINT_MAX - t || r >= UINT_MAX - l) {
> av_log(c->fc, AV_LOG_ERROR,
> "Invalid bounding rectangle coordinates "
> - "%zu,%zu,%zu,%zu\n", l, t, r, b);
> + "%"PRIu32",%"PRIu32",%"PRIu32",%"PRIu32"\n", l, t, r, b);
Same.
> return AVERROR_INVALIDDATA;
> }
>
> diff --git a/libavutil/spherical.h b/libavutil/spherical.h
> index e7fc1d69fb..fd662cf676 100644
> --- a/libavutil/spherical.h
> +++ b/libavutil/spherical.h
> @@ -164,10 +164,10 @@ typedef struct AVSphericalMapping {
> * projection type (@ref AV_SPHERICAL_EQUIRECTANGULAR_TILE),
> * and should be ignored in all other cases.
> */
> -size_t bound_left; ///< Distance from the left edge
> -size_t bound_top;///< Distance from the top edge
> -size_t bound_right; ///< Distance from the right edge
> -size_t bound_bottom; ///< Distance from the bottom edge
> +uint32_t bound_left; ///< Distance from the left edge
> +uint32_t bound_top;///< Distance from the top edge
> +uint32_t bound_right; ///< Distance from the right edge
> +uint32_t bound_bottom; ///< Distance from the bottom edge
> /**
> * @}
> */
> @@ -179,7 +179,7 @@ typedef struct AVSphericalMapping {
> * (@ref AV_SPHERICAL_CUBEMAP), and should be ignored in all other
> * cases.
> */
> -size_t padding;
> +uint32_t padding;
> } AVSphericalMapping;
>
> /**
LGTM otherwise.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec, avformat: deprecate anything related to side data merging
This patch deprecates anything that has to do with merging/splitting
side data. Automatic side data merging (and splitting), as well as all
API symbols involved in it, are removed completely.
Two FF_API_ defines are dedicated to deprecating API symbols related to
this: FF_API_MERGE_SD_API removes av_packet_split/merge_side_data in
libavcodec, and FF_API_LAVF_KEEPSIDE_FLAG deprecates
AVFMT_FLAG_KEEP_SIDE_DATA in libavformat.
Since it was claimed that changing the default from merging side data to
not doing it is an ABI change, there are two additional FF_API_ defines,
which stop using the side data merging/splitting by default (and remove
any code in avformat/avcodec doing this): FF_API_MERGE_SD in libavcodec,
and FF_API_LAVF_MERGE_SD in libavformat.
It is very much intended that FF_API_MERGE_SD and FF_API_LAVF_MERGE_SD
are quickly defined to 0 in the next ABI bump, while the API symbols are
retained for a longer time for the sake of compatibility.
AVFMT_FLAG_KEEP_SIDE_DATA will (very much intentionally) do nothing for
most of the time it will still be defined. Keep in mind that no code
exists that actually tries to unset this flag for any reason, nor does
such code need to exist. Code setting this flag explicitly will work as
before. Thus it's ok for AVFMT_FLAG_KEEP_SIDE_DATA to do nothing once
side data merging has been removed from libavformat.
In order to avoid that anyone in the future does this incorrectly, here
is a small guide how to update the internal code on bumps:
- next ABI bump (probably soon):
- define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it
- define FF_API_MERGE_SD to 0, and remove all code covered by it
- next API bump (typically two years in the future or so):
- define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it
- define FF_API_MERGE_SD_API to 0, and remove all code covered by it
This forces anyone who actually wants packet side data to temporarily
use deprecated API to get it all. If you ask me, this is batshit fucked
up crazy, but it's how we roll. Making AVFMT_FLAG_KEEP_SIDE_DATA to be
set by default was rejected as an ABI change, so I'm going all the way
to get rid of this once and for all.
---
doc/APIchanges | 5 +
libavcodec/avcodec.h| 4
libavcodec/avpacket.c | 4
libavcodec/utils.c | 16
libavcodec/version.h| 9 -
libavformat/avformat.h | 4 +++-
libavformat/mux.c | 6 ++
libavformat/options_table.h | 2 ++
libavformat/utils.c | 2 ++
libavformat/version.h | 8 +++-
10 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index dc36a6bea7..acb67d38e4 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,11 @@ libavutil: 2015-08-28
API changes, most recent first:
+2017-03-16 - xxx - lavf 57.66.105, lavc 57.83.101 - avformat.h, avcodec.h
+ Deprecate AVFMT_FLAG_KEEP_SIDE_DATA. It will be ignored after the next major
+ bump, and libavformat will behave as if it were always set.
+ Deprecate av_packet_merge_side_data() and av_packet_split_side_data().
+
2017-02-10 - xxx - lavu 55.48.100 / 55.33.0 - spherical.h
Add AV_SPHERICAL_EQUIRECTANGULAR_TILE, av_spherical_tile_bounds(),
and projection-specific properties (bound_left, bound_top, bound_right,
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index e32f57983c..e279dd59ee 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -4575,9 +4575,13 @@ int av_packet_shrink_side_data(AVPacket *pkt, enum
AVPacketSideDataType type,
uint8_t* av_packet_get_side_data(AVPacket *pkt, enum AVPacketSideDataType type,
int *size);
+#if FF_API_MERGE_SD_API
+attribute_deprecated
int av_packet_merge_side_data(AVPacket *pkt);
+attribute_deprecated
int av_packet_split_side_data(AVPacket *pkt);
+#endif
const char *av_packet_side_data_name(enum AVPacketSideDataType type);
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 60269aa63d..6af3bb68f1 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -379,6 +379,8 @@ const char *av_packet_side_data_name(enum
AVPacketSideDataType type)
return NULL;
}
+#if FF_API_MERGE_SD_API
+
#define FF_MERGE_MARKER 0x8c4d9d108e25e9feULL
int av_packet_merge_side_data(AVPacket *pkt){
@@ -460,6 +462,8 @@ int av_packet_split_side_data(AVPacket *pkt){
return 0;
}
+#endif
+
uint8_t *av_packet_pack_dictionary(AVDictionary *dict, int *size)
{
AVDictionaryEntry *t = NULL;
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 4d1b63222f..456e707c8f 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -2263,7 +2263,9 @@ int attribute_align_arg
avcodec_decode_video2(AVCodecContext *avctx, AVFrame *pi
if ((avctx->codec->capabilities & AV_CODEC_CAP_DELAY) || avpkt->size ||
(avctx->active_thread_type & FF_THREAD_FRAME)) {
+#if FF_API_MERGE_SD
[FFmpeg-devel] [PATCH 2/2] ffmpeg: don't unnecessarily use a deprecated API function
Since we've disabled side data merging in ffmpeg.c, this really changes
nothing.
---
ffmpeg.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index 63fc1bc5f4..bc2157e544 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -818,7 +818,6 @@ static void output_packet(OutputFile *of, AVPacket *pkt,
OutputStream *ost)
if (ost->nb_bitstream_filters) {
int idx;
-av_packet_split_side_data(pkt);
ret = av_bsf_send_packet(ost->bsf_ctx[0], pkt);
if (ret < 0)
goto finish;
@@ -4245,8 +4244,6 @@ static int process_input(int file_index)
/* add the stream-global side data to the first packet */
if (ist->nb_packets == 1) {
-if (ist->st->nb_side_data)
-av_packet_split_side_data(&pkt);
for (i = 0; i < ist->st->nb_side_data; i++) {
AVPacketSideData *src_sd = &ist->st->side_data[i];
uint8_t *dst_data;
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 3.3
On Tue, 14 Mar 2017 12:29:52 +0100 Michael Niedermayer wrote: > Hi all > > are there any issues/tickets that block making 3.3 ? > > What about the spherical API size_t / uint32_t issue ? > we can change it before the release but not after it > I will insist that avcodec, avformat: deprecate anything related to side data merging will be part of the release. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] swresample/x86/resample: extend resample_double to support avx and fma3
benchmark:
sse2 10.670s
avx 8.763s
fma3 8.380s
Signed-off-by: Muhammad Faiz
---
libswresample/x86/resample.asm| 15 ---
libswresample/x86/resample_init.c | 10 ++
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/libswresample/x86/resample.asm b/libswresample/x86/resample.asm
index 4163df1..7107cf9 100644
--- a/libswresample/x86/resample.asm
+++ b/libswresample/x86/resample.asm
@@ -203,7 +203,7 @@ cglobal resample_common_%1, 1, 7, 2, ctx, phase_count, dst,
frac, \
; horizontal sum & store
%if mmsize == 32
vextractf128 xm1, m0, 0x1
-addpsxm0, xm1
+addp%4 xm0, xm1
%endif
movhlps xm1, xm0
%ifidn %1, float
@@ -489,8 +489,8 @@ cglobal resample_linear_%1, 1, 7, 5, ctx,
min_filter_length_x4, filter2, \
%if mmsize == 32
vextractf128 xm1, m0, 0x1
vextractf128 xm3, m2, 0x1
-addpsxm0, xm1
-addpsxm2, xm3
+addp%4 xm0, xm1
+addp%4 xm2, xm3
%endif
cvtsi2s%4xm1, fracd
subp%4 xm2, xm0
@@ -608,3 +608,12 @@ RESAMPLE_FNS int16, 2, 1
INIT_XMM sse2
RESAMPLE_FNS double, 8, 3, d, pdbl_1
+
+%if HAVE_AVX_EXTERNAL
+INIT_YMM avx
+RESAMPLE_FNS double, 8, 3, d, pdbl_1
+%endif
+%if HAVE_FMA3_EXTERNAL
+INIT_YMM fma3
+RESAMPLE_FNS double, 8, 3, d, pdbl_1
+%endif
diff --git a/libswresample/x86/resample_init.c
b/libswresample/x86/resample_init.c
index e515762..c6b2a36 100644
--- a/libswresample/x86/resample_init.c
+++ b/libswresample/x86/resample_init.c
@@ -42,6 +42,8 @@ RESAMPLE_FUNCS(float, avx);
RESAMPLE_FUNCS(float, fma3);
RESAMPLE_FUNCS(float, fma4);
RESAMPLE_FUNCS(double, sse2);
+RESAMPLE_FUNCS(double, avx);
+RESAMPLE_FUNCS(double, fma3);
av_cold void swri_resample_dsp_x86_init(ResampleContext *c)
{
@@ -85,6 +87,14 @@ av_cold void swri_resample_dsp_x86_init(ResampleContext *c)
c->dsp.resample_linear = ff_resample_linear_double_sse2;
c->dsp.resample_common = ff_resample_common_double_sse2;
}
+if (EXTERNAL_AVX_FAST(mm_flags)) {
+c->dsp.resample_linear = ff_resample_linear_double_avx;
+c->dsp.resample_common = ff_resample_common_double_avx;
+}
+if (EXTERNAL_FMA3_FAST(mm_flags)) {
+c->dsp.resample_linear = ff_resample_linear_double_fma3;
+c->dsp.resample_common = ff_resample_common_double_fma3;
+}
break;
}
}
--
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] swresample/swresample: do not use s32p internally by default when resampling
use fltp when doing s32 -> s32 resampling
because s32p has no simd optimization
benchmark:
old 17.913s
new 7.584s (use fma3)
Signed-off-by: Muhammad Faiz
---
libswresample/swresample.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libswresample/swresample.c b/libswresample/swresample.c
index f2e6600..74c96dc 100644
--- a/libswresample/swresample.c
+++ b/libswresample/swresample.c
@@ -223,6 +223,8 @@ av_cold int swr_init(struct SwrContext *s){
}else if( av_get_planar_sample_fmt(s-> in_sample_fmt) ==
AV_SAMPLE_FMT_S32P
&& av_get_planar_sample_fmt(s->out_sample_fmt) ==
AV_SAMPLE_FMT_S32P
&& !s->rematrix
+ && s->out_sample_rate == s->in_sample_rate
+ && !(s->flags & SWR_FLAG_RESAMPLE)
&& s->engine != SWR_ENGINE_SOXR){
s->int_sample_fmt= AV_SAMPLE_FMT_S32P;
}else if(av_get_bytes_per_sample(s->in_sample_fmt) <= 4){
--
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample/swresample: do not use s32p internally by default when resampling
On Thu, 16 Mar 2017 12:43:10 +0700
Muhammad Faiz wrote:
> use fltp when doing s32 -> s32 resampling
> because s32p has no simd optimization
>
> benchmark:
> old 17.913s
> new 7.584s (use fma3)
>
> Signed-off-by: Muhammad Faiz
> ---
> libswresample/swresample.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libswresample/swresample.c b/libswresample/swresample.c
> index f2e6600..74c96dc 100644
> --- a/libswresample/swresample.c
> +++ b/libswresample/swresample.c
> @@ -223,6 +223,8 @@ av_cold int swr_init(struct SwrContext *s){
> }else if( av_get_planar_sample_fmt(s-> in_sample_fmt) ==
> AV_SAMPLE_FMT_S32P
> && av_get_planar_sample_fmt(s->out_sample_fmt) ==
> AV_SAMPLE_FMT_S32P
> && !s->rematrix
> + && s->out_sample_rate == s->in_sample_rate
> + && !(s->flags & SWR_FLAG_RESAMPLE)
> && s->engine != SWR_ENGINE_SOXR){
> s->int_sample_fmt= AV_SAMPLE_FMT_S32P;
> }else if(av_get_bytes_per_sample(s->in_sample_fmt) <= 4){
Wouldn't going over float lose bits? I guess most times, s32 is
actually 24 bit padded (since we have no 24 bit format). But it could
be true 32 bit as well (with all bits used). Or does it use double, or
am I missing something else?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
