Re: [FFmpeg-devel] [PATCH] Makefile: add cleanup of pkg-config files created by configure to distclean
On 25.11.2015 11:56, Tobias Rapp wrote: When creating a fresh working copy I noticed that the "doc/examples/pc-uninstalled" folder which is created by ./configure is not cleaned up when running "make distclean". Attached patch adds the removal of "doc/examples/pc-uninstalled" folder to "make distclean". Regards, Tobias Ping. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC encoder: improve SF range utilization
On Mon, Nov 30, 2015 at 1:04 PM, Hendrik Leppkes wrote: > On Mon, Nov 30, 2015 at 4:50 PM, Claudio Freire > wrote: >> On Mon, Nov 30, 2015 at 12:27 PM, Rostislav Pehlivanov >> wrote: >>> On Sun, 2015-11-29 at 16:54 -0300, Claudio Freire wrote: Before pushing this, I'd like some feedback, especially about the implementation of point 3. I'm not sure the AAC encoder setting the cutoff in the encoder context like this is legal or desirable. >>> I think setting the cutoff is necessary. You can't avoid holes and yet >>> keep a full bandwidth as you decrease bits unless you like the sound of >>> massive quantization errors. >> >> My point was more about whether a codec should write into the context >> struct like that or not. Basically an API technicality that's unclear >> to me. >> > > It seems slightly odd to write into that variable, since thats the > cutoff the user requests. > Maybe you can use/write into a private variable instead? ac3enc seems > to use a private variable for similar purposes. Attached patch does that. I'm far more comfortable with this implementation, so if all agree, I'll push. On Mon, Nov 30, 2015 at 2:20 PM, Rostislav Pehlivanov wrote: > On Mon, 2015-11-30 at 12:50 -0300, Claudio Freire wrote: >> Also I don't see how a static var would help or even be correct here. >> Perhaps you meant something else? > static uint8_t cond1 = param1 && param2; > static uint8_t cond2 = param3 && !param4; > ...etc > return cond1 && cond2; I didn't do that since it would not short circuit some terms that ought to be short-circuited. But I did split lines and it does read better. In fact, maybe that was all that was needed? From 1ccc8f8e165ee8111e31253939c3152ff6071f9b Mon Sep 17 00:00:00 2001 From: Claudio Freire Date: Tue, 1 Dec 2015 03:28:36 -0300 Subject: [PATCH] AAC encoder: improve SF range utilization This patch does 4 things, all of which interact and thus it woudln't be possible to commit them separately without causing either quality regressions or assertion failures. Fate comparison targets don't all reflect improvements in quality, yet listening tests show substantially improved quality and stability. 1. Increase SF range utilization. The spec requires SF delta values to be constrained within the range -60..60. The previous code was applying that range to the whole SF array and not only the deltas of consecutive values, because doing so requires smarter code: zeroing or otherwise skipping a band may invalidate lots of SF choices. This patch implements that logic to allow the coders to utilize the full dynamic range of scalefactors, increasing quality quite considerably, and fixing delta-SF-related assertion failures, since now the limitation is enforced rather than asserted. 2. PNS tweaks The previous modification makes big improvements in twoloop's efficiency, and every time that happens PNS logic needs to be tweaked accordingly to avoid it from stepping all over twoloop's decisions. This patch includes modifications of the sort. 3. Account for lowpass cutoff during PSY analysis The closer PSY's allocation is to final allocation the better the quality is, and given these modifications, twoloop is now very efficient at avoiding holes. Thus, to compute accurate thresholds, PSY needs to account for the lowpass applied implicitly during twoloop (by zeroing high bands). This patch makes twoloop set the cutoff in psymodel's context the first time it runs, and makes PSY account for it during threshold computation, making PE and threshold computations closer to the final allocation and thus achieving better subjective quality. 4. Tweaks to RC lambda tracking loop in relation to PNS Without this tweak some corner cases cause quality regressions. Basically, lambda needs to react faster to overall bitrate efficiency changes since now PNS can be quite successful in enforcing maximum bitrates, when PSY allocates too many bits to the lower bands, suppressing the signals RC logic uses to lower lambda in those cases and causing aggressive PNS. This tweak makes PNS much less aggressive, though it can still use some further tweaks. --- libavcodec/aaccoder.c | 60 +-- libavcodec/aaccoder_twoloop.h | 136 +- libavcodec/aacenc.c | 2 +- libavcodec/aacenc_is.c| 11 +++- libavcodec/aacenc_utils.h | 63 +++ libavcodec/aacpsy.c | 20 --- libavcodec/psymodel.c | 1 + libavcodec/psymodel.h | 1 + tests/fate/aac.mak| 18 +++--- 9 files changed, 231 insertions(+), 81 deletions(-) diff --git a/libavcodec/aaccoder.c b/libavcodec/aaccoder.c index 2a66045..2a0cb1f 100644 --- a/libavcodec/aaccoder.c +++ b/libavcodec/aaccoder.c @@ -54,7 +54,7 @@ /* Parameter of f(x) = a*(lambda/100), defines the maximum fourier spread * beyond which no PNS is used (since the SFBs contain tone rather than noise) */ -#define NOISE_SPREAD_T
Re: [FFmpeg-devel] [PATCH 05/10] avfilter/avf_showcqt: use hypot()
On Sun, Nov 22, 2015 at 9:05 AM, Ganesh Ajjanagadde
wrote:
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavfilter/avf_showcqt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
> index d6e2928..cd90c88 100644
> --- a/libavfilter/avf_showcqt.c
> +++ b/libavfilter/avf_showcqt.c
> @@ -170,7 +170,7 @@ static double a_weighting(void *p, double f)
> static double b_weighting(void *p, double f)
> {
> double ret = 12200.0*12200.0 * (f*f*f);
> -ret /= (f*f + 20.6*20.6) * (f*f + 12200.0*12200.0) * sqrt(f*f +
> 158.5*158.5);
> +ret /= (f*f + 20.6*20.6) * (f*f + 12200.0*12200.0) * hypot(f, 158.5);
> return ret;
> }
>
I prefer sqrt in this code, because extra precision and range is not required.
Thank's.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double
On Mon, Nov 30, 2015 at 12:06 PM, Michael Niedermayer wrote: > On Mon, Nov 30, 2015 at 07:02:47PM +0100, Nicolas George wrote: >> Le decadi 10 frimaire, an CCXXIV, Michael Niedermayer a écrit : >> > > ISO/IEC 9899:TC3 >> > > 5.2.4.2.2 Characteristics of floating types >> > > >> > > 8 Except for assignment and cast (which remove all extra range and >> > > precision), the values >> > > of operations with floating operands and values subject to the usual >> > > arithmetic >> > > conversions and of floating constants are evaluated to a format >> > > whose range and precision >> > > may be greater than required by the type. The use of evaluation >> > > formats is characterized >> > > by the implementation-defined value of FLT_EVAL_METHOD:19) >> > > -1 indeterminable; >> > > 0 evaluate all operations and constants just to the range >> > > and precision of the >> > > type; >> > > 1 evaluate operations and constants of type float and >> > > double to the >> > > range and precision of the double type, evaluate long >> > > double >> > > operations and constants to the range and precision of >> > > the long double >> > > type; >> > > 2 evaluate all operations and constants to the range and >> > > precision of the >> > > long double type. >> > > All other negative values for FLT_EVAL_METHOD characterize >> > > implementation-defined >> > > behavior. >> > >> > a few more related parts: >> > 5 The accuracy of the floating-point operations (+, -, *, /) and of >> > the library functions in >> > and that return floating-point results is >> > implementation- >> > defined, as is the accuracy of the conversion between floating-point >> > internal >> > representations and string representations performed by the library >> > functions in >> > , , and . The implementation may state >> > that the >> > accuracy is unknown. >> > >> > 6.4.4.2 Floating constants >> > 7 The translation-time conversion of floating constants should match >> > the execution-time >> > conversion of character strings by library functions, such as strtod, >> > given matching >> > inputs suitable for both conversions, the same result format, and >> > default execution-time >> > rounding.64) >> >> I am not sure why you quoting this. Are you implying this is not a compiler >> bug, the compiler is actually allowed to do that? Possible. But still, I do > > yes, i suspect that is not a compiler bug but i certainly do not have > deep enough knowledge of C to say that for sure > > >> not think we should apply this unless we actually understand what is going >> on here, why a cast that should not change anything does change the result. >> Otherwise, it could just be a coincidence, and break in a different way on a >> different compiler. > > I would not be surprised if a strict and litteral reading of C would > allow that still to fail, but then theres the question if such > equals check is even possible in C in such a strict reading of the > standard. > and theres also IEEE ... But at least the standard said: 'Except for assignment and cast (which remove all extra range and precision)' so we can be sure that BASEFREQ is in double precision when casted to double. So, this patch should be OK > > One could use a special value as default like -1 and check for that > which may be less likely to cause problems with float accuracy and > rounding in case the cast does not work on some real world case or > if the risk of it failing on some obscure plaform should be avoided Unless the platform which makes this patch useless is reported, the patch should be OK for workaround. Thank's. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double
On Mon, Nov 30, 2015 at 10:00 AM, Nicolas George wrote: > Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit : >> gcc -c -std=c89 -O2 > > gcc -S would have been more useful: as is, it lacks the definition for > basefreq, and apparently also the other constant. > The strange behaviour is that gcc uses fldt instead of fldl to load BASEFREQ. I think it is enough to detect the problem. Thank's. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avfilter: add sidechaingate filter
On Sun, Nov 29, 2015 at 6:03 PM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi | 61 +
> libavfilter/Makefile | 1 +
> libavfilter/af_agate.c | 170
> ++-
> libavfilter/allfilters.c | 1 +
> 4 files changed, 230 insertions(+), 3 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 0395c7a..ed4a376 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -2531,6 +2531,67 @@ ffmpeg -i main.flac -i sidechain.flac -filter_complex
> "[1:a]asplit=2[sc][mix];[0
> @end example
> @end itemize
>
> +@section sidechaingate
> +
> +A sidechain gate acts like a normal (wideband) gate but has the ability to
> +filter the detected signal before sending it to the gain reduction stage.
> +Normally a gate uses the full range signal to detect a level above the
> +threshold.
> +For example: If you cut all lower frequencies from your sidechain signal
> +the gate will decrease the volume of your track only if not enough highs
> +appear. With this technique you are able to reduce the resonation of a
> +natural drum or remove "rumbling" of muted strokes from a heavily distorted
> +guitar.
> +It needs two input streams and returns one output stream.
> +First input stream will be processed depending on second stream signal.
> +
> +The filter accepts the following options:
> +
> +@table @option
> +@item level_in
> +Set input level before filtering.
> +Default is 1. Allowed range is from 0.015625 to 64.
> +
> +@item range
> +Set the level of gain reduction when the signal is below the threshold.
> +Default is 0.06125. Allowed range is from 0 to 1.
> +
> +@item threshold
> +If a signal rises above this level the gain reduction is released.
> +Default is 0.125. Allowed range is from 0 to 1.
> +
> +@item ratio
> +Set a ratio about which the signal is reduced.
> +Default is 2. Allowed range is from 1 to 9000.
> +
> +@item attack
> +Amount of milliseconds the signal has to rise above the threshold before gain
> +reduction stops.
> +Default is 20 milliseconds. Allowed range is from 0.01 to 9000.
> +
> +@item release
> +Amount of milliseconds the signal has to fall below the threshold before the
> +reduction is increased again. Default is 250 milliseconds.
> +Allowed range is from 0.01 to 9000.
> +
> +@item makeup
> +Set amount of amplification of signal after processing.
> +Default is 1. Allowed range is from 1 to 64.
> +
> +@item knee
> +Curve the sharp knee around the threshold to enter gain reduction more
> softly.
> +Default is 2.828427125. Allowed range is from 1 to 8.
> +
> +@item detection
> +Choose if exact signal should be taken for detection or an RMS like one.
> +Default is peak. Can be peak or rms.
> +
> +@item link
> +Choose if the average level between all channels or the louder channel
> affects
> +the reduction.
> +Default is average. Can be average or maximum.
> +@end table
> +
> @section silencedetect
>
> Detect silence in an audio stream.
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index e31bdaa..582fd0e 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -82,6 +82,7 @@ OBJS-$(CONFIG_REPLAYGAIN_FILTER) +=
> af_replaygain.o
> OBJS-$(CONFIG_RESAMPLE_FILTER) += af_resample.o
> OBJS-$(CONFIG_RUBBERBAND_FILTER) += af_rubberband.o
> OBJS-$(CONFIG_SIDECHAINCOMPRESS_FILTER) += af_sidechaincompress.o
> +OBJS-$(CONFIG_SIDECHAINGATE_FILTER) += af_agate.o
> OBJS-$(CONFIG_SILENCEDETECT_FILTER) += af_silencedetect.o
> OBJS-$(CONFIG_SILENCEREMOVE_FILTER) += af_silenceremove.o
> OBJS-$(CONFIG_STEREOTOOLS_FILTER)+= af_stereotools.o
> diff --git a/libavfilter/af_agate.c b/libavfilter/af_agate.c
> index d3f74fb..23e45c6 100644
> --- a/libavfilter/af_agate.c
> +++ b/libavfilter/af_agate.c
> @@ -18,6 +18,12 @@
> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> */
>
> +/**
> + * @file
> + * Audio (Sidechain) Gate filter
> + */
> +
> +#include "libavutil/avassert.h"
> #include "libavutil/channel_layout.h"
> #include "libavutil/opt.h"
> #include "avfilter.h"
> @@ -46,12 +52,14 @@ typedef struct AudioGateContext {
> double lin_slope;
> double attack_coeff;
> double release_coeff;
> +
> +AVFrame *input_frame[2];
> } AudioGateContext;
>
> #define OFFSET(x) offsetof(AudioGateContext, x)
> #define A AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
>
> -static const AVOption agate_options[] = {
> +static const AVOption options[] = {
> { "level_in", "set input level",OFFSET(level_in),
> AV_OPT_TYPE_DOUBLE, {.dbl=1}, 0.015625, 64, A },
> { "range", "set max gain reduction", OFFSET(range),
> AV_OPT_TYPE_DOUBLE, {.dbl=0.06125}, 0, 1, A },
> { "threshold", "set threshold", OFFSET(threshold),
> AV_OPT_TYPE_DOUBLE, {.dbl=0.125}, 0, 1, A },
> @@ -69,6 +77,7 @@ stat
Re: [FFmpeg-devel] [PATCH 04/10] avfilter/af_compand: use hypot()
2015-11-30 3:26 GMT-05:00 Paul B Mahol : > On 11/22/15, Ganesh Ajjanagadde wrote: >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavfilter/af_compand.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/libavfilter/af_compand.c b/libavfilter/af_compand.c >> index 3848d67..a64778e 100644 >> --- a/libavfilter/af_compand.c >> +++ b/libavfilter/af_compand.c >> @@ -467,13 +467,13 @@ static int config_output(AVFilterLink *outlink) >> L(2).b = (L(0).y - L(2).y) / (L(0).x - L(2).x); >> >> theta = atan2(L(2).y - L(4).y, L(2).x - L(4).x); >> -len = sqrt(pow(L(2).x - L(4).x, 2.) + pow(L(2).y - L(4).y, 2.)); >> +len = hypot(L(2).x - L(4).x, L(2).y - L(4).y); >> r = FFMIN(radius, len); >> L(3).x = L(2).x - r * cos(theta); >> L(3).y = L(2).y - r * sin(theta); >> >> theta = atan2(L(0).y - L(2).y, L(0).x - L(2).x); >> -len = sqrt(pow(L(0).x - L(2).x, 2.) + pow(L(0).y - L(2).y, 2.)); >> +len = hypot(L(0).x - L(2).x, L(0).y - L(2).y); >> r = FFMIN(radius, len / 2); >> x = L(2).x + r * cos(theta); >> y = L(2).y + r * sin(theta); >> -- >> 2.6.2 >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > > ok pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/ac3: always use hardcoded tables
On Mon, Nov 30, 2015 at 9:35 AM, Ganesh Ajjanagadde wrote:
> On Mon, Nov 30, 2015 at 6:39 AM, wm4 wrote:
>> On Sun, 29 Nov 2015 20:40:11 -0500
>> Ganesh Ajjanagadde wrote:
>>
>>> The table in question is a 253 byte one. In fact, it turns out that
>>> dynamic generation of the table results in an increased binary size.
>>>
>>> Code compiled with GCC 5.2.0, x86-64 (size in bytes), before and after
>>> patch:
>>> old: 62321064 libavcodec/libavcodec.so.57
>>> new: 62320536 libavcodec/libavcodec.so.57
>>>
>>> Thus, it always make sense to statically allocate this.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde
>>> ---
>>> libavcodec/ac3.c| 24
>>> libavcodec/ac3dec.c | 1 -
>>> libavcodec/ac3enc.c | 2 --
>>> libavcodec/ac3tab.h | 8 +---
>>> 4 files changed, 1 insertion(+), 34 deletions(-)
>>>
>>> diff --git a/libavcodec/ac3.c b/libavcodec/ac3.c
>>> index b54315d..1d4eaa5 100644
>>> --- a/libavcodec/ac3.c
>>> +++ b/libavcodec/ac3.c
>>> @@ -39,8 +39,6 @@ const uint8_t ff_ac3_band_start_tab[AC3_CRITICAL_BANDS+1]
>>> = {
>>> 79, 85, 97, 109, 121, 133, 157, 181, 205, 229, 253
>>> };
>>>
>>> -#if CONFIG_HARDCODED_TABLES
>>> -
>>> /**
>>> * Map each frequency coefficient bin to the critical band that contains
>>> it.
>>> */
>>> @@ -69,10 +67,6 @@ const uint8_t ff_ac3_bin_to_band_tab[253] = {
>>> 49, 49, 49, 49, 49, 49, 49, 49, 49, 49, 49, 49
>>> };
>>>
>>> -#else /* CONFIG_HARDCODED_TABLES */
>>> -uint8_t ff_ac3_bin_to_band_tab[253];
>>> -#endif
>>> -
>>> static inline int calc_lowcomp1(int a, int b0, int b1, int c)
>>> {
>>> if ((b0 + 256) == b1) {
>>> @@ -214,21 +208,3 @@ int ff_ac3_bit_alloc_calc_mask(AC3BitAllocParameters
>>> *s, int16_t *band_psd,
>>> }
>>> return 0;
>>> }
>>> -
>>> -/**
>>> - * Initialize some tables.
>>> - * note: This function must remain thread safe because it is called by the
>>> - * AVParser init code.
>>> - */
>>> -av_cold void ff_ac3_common_init(void)
>>> -{
>>> -#if !CONFIG_HARDCODED_TABLES
>>> -/* compute ff_ac3_bin_to_band_tab from ff_ac3_band_start_tab */
>>> -int bin = 0, band;
>>> -for (band = 0; band < AC3_CRITICAL_BANDS; band++) {
>>> -int band_end = ff_ac3_band_start_tab[band+1];
>>> -while (bin < band_end)
>>> -ff_ac3_bin_to_band_tab[bin++] = band;
>>> -}
>>> -#endif /* !CONFIG_HARDCODED_TABLES */
>>> -}
>>> diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
>>> index ad91405..efc58e5 100644
>>> --- a/libavcodec/ac3dec.c
>>> +++ b/libavcodec/ac3dec.c
>>> @@ -185,7 +185,6 @@ static av_cold int ac3_decode_init(AVCodecContext
>>> *avctx)
>>>
>>> s->avctx = avctx;
>>>
>>> -ff_ac3_common_init();
>>> ac3_tables_init();
>>> ff_mdct_init(&s->imdct_256, 8, 1, 1.0);
>>> ff_mdct_init(&s->imdct_512, 9, 1, 1.0);
>>> diff --git a/libavcodec/ac3enc.c b/libavcodec/ac3enc.c
>>> index c8a0caa..636ca72 100644
>>> --- a/libavcodec/ac3enc.c
>>> +++ b/libavcodec/ac3enc.c
>>> @@ -2431,8 +2431,6 @@ av_cold int ff_ac3_encode_init(AVCodecContext *avctx)
>>>
>>> s->eac3 = avctx->codec_id == AV_CODEC_ID_EAC3;
>>>
>>> -ff_ac3_common_init();
>>> -
>>> ret = validate_options(s);
>>> if (ret)
>>> return ret;
>>> diff --git a/libavcodec/ac3tab.h b/libavcodec/ac3tab.h
>>> index 74cbd9e..f529fc8 100644
>>> --- a/libavcodec/ac3tab.h
>>> +++ b/libavcodec/ac3tab.h
>>> @@ -27,12 +27,6 @@
>>> #include "libavutil/internal.h"
>>> #include "ac3.h"
>>>
>>> -#if CONFIG_HARDCODED_TABLES
>>> -# define HCONST const
>>> -#else
>>> -# define HCONST
>>> -#endif
>>> -
>>> extern const uint16_t ff_ac3_frame_size_tab[38][3];
>>> extern const uint8_t ff_ac3_channels_tab[8];
>>> extern av_export const uint16_t avpriv_ac3_channel_layout_tab[8];
>>> @@ -54,7 +48,7 @@ extern const int16_t ff_ac3_floor_tab[8];
>>> extern const uint16_t ff_ac3_fast_gain_tab[8];
>>> extern const uint16_t ff_eac3_default_chmap[8];
>>> extern const uint8_t ff_ac3_band_start_tab[AC3_CRITICAL_BANDS+1];
>>> -extern HCONST uint8_t ff_ac3_bin_to_band_tab[253];
>>> +extern const uint8_t ff_ac3_bin_to_band_tab[253];
>>>
>>> /** Custom channel map locations bitmask
>>> * Other channels described in documentation:
>>
>> Seems fine if it passes FATE. (Note that I'm not AC3 maintainer.)
>
> Maintainer seems to be Justin Ruggles, who has been inactive since
> last year, and moreover works for Libav. Thanks for the review; will
> push later.
pushed
>
>> ___
>> 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] Fix sample_aspect_ratio computation for stereo matroska content.
On Mon, 30 Nov 2015 19:53:41 + Aaron Colwell wrote: > On Mon, Nov 30, 2015 at 10:57 AM wm4 wrote: > > > On Mon, 30 Nov 2015 18:31:56 + > > Aaron Colwell wrote: > > > > > Hi, > > > Can I get a review for this please? It has been a week since I sent out > > > this patch and I haven't gotten any real feedback about the changes. I've > > > attached a new copy that has been rebased to HEAD. If I need to be doing > > > something different, please let me know so I can make progress on this. > > > > > > Thanks, > > > Aaron > > > > > > On Wed, Nov 25, 2015 at 4:40 PM Aaron Colwell > > wrote: > > > > > > > On Tue, Nov 24, 2015 at 10:43 AM Kirill Gavrilov > > > > wrote: > > > > > > > >> On Mon, Nov 23, 2015 at 11:37 PM, Aaron Colwell > > > >> wrote: > > > >> > > > >> > matroskaenc.c applies divisors to the display width/height when > > > >> generating > > > >> > stereo content. This patch adds the corresponding multipliers to > > > >> > matroskadec.c > > > >> > so that the original sample aspect ratio can be recovered. > > > >> > > > >> > > > >> Just to link this patch with Matroska Specification notes: > > > >> http://www.matroska.org/technical/specs/notes.html#3D > > > >> > > > >> > The pixel count of the track (PixelWidth/PixelHeight) should be the > > raw > > > >> > amount of pixels (for example 3840x1080 for full HD side by side) > > > >> > and the DisplayWidth/Height in pixels should be the amount of > > pixels for > > > >> > one plane (1920x1080 for that full HD stream). > > > >> > > > > >> > > > > > > > > Is this intended to be a call to action or are you just adding > > information > > > > to this particular thread? I'd like to get the change reviewed so I can > > > > determine whether I need to make any other changes. > > > > > > > > This change basically allows 'ffmpeg -i blah.mkv foo.mkv ; ffprobe > > > > foo.mkv' to show that foo.mkv has the same SAR and DAR as blah.mkv when > > > > blah.mkv contains stereo content. Without this patch the SAR & DAR get > > > > smaller based on whichever dimension is halved by the stereo layout. > > > > > > > > Hope this helps, > > > > Aaron > > > > > > > > > > > > Are you sure matroskadec is wrong and not matroskaenc? > > > > Thanks for the response. > > Yes. I believe matroskadec is wrong. From what I can tell matroskaenc is > writing the correct information to the file. The issue is that matroskadec > does not appear to be doing the right thing to restore the same state that > was present when the file was written. Specifically sample_aspect_ratio > does not get restored to the value it had during writing. > > Here is an example using a SIDE_BY_SIDE_RL file that has > PixelWidthxPixelHeight of "640x360" and a DisplayWidthxDisplayHeight of > "640x360" > > ./ffmpeg -y -i fp3_RL_640x360.webm blah.webm && ./ffprobe blah.webm > > [ffmpeg output] > Input #0, matroska,webm, from 'fp3_RL_640x360.webm': > Metadata: > encoder : google > Duration: 00:00:04.88, start: 0.00, bitrate: 208 kb/s > Stream #0:0: Video: vp8, yuv420p, 640x360, SAR 1:1 DAR 16:9, 23.98 fps, > 23.98 tbr, 1k tbn, 1k tbc (default) > Metadata: > stereo_mode : right_left > Side data: > stereo3d: side by side (inverted) > [libvpx-vp9 @ 0x33dcfa0] v1.4.0-729-g8bf791e > Output #0, webm, to 'blah.webm': > Metadata: > encoder : Lavf57.19.100 > Stream #0:0: Video: vp9 (libvpx-vp9), yuv420p, 640x360 [SAR 1:1 DAR > 16:9], q=-1--1, 200 kb/s, 23.98 fps, 1k tbn, 23.98 tbc (default) > Metadata: > stereo_mode : right_left > encoder : Lavc57.16.101 libvpx-vp9 > Side data: > stereo3d: side by side (inverted) > Stream mapping: > Stream #0:0 -> #0:0 (vp8 (native) -> vp9 (libvpx-vp9)) > [end of ffmpeg output] > > --[ffprobe output]-- > Input #0, matroska,webm, from 'blah.webm': > Metadata: > encoder : Lavf57.19.100 > Duration: 00:00:04.88, start: 0.00, bitrate: 100 kb/s > Stream #0:0: Video: vp9 (Profile 0), yuv420p(tv), 640x360, SAR 1:2 DAR > 8:9, 23.98 fps, 23.98 tbr, 1k tbn, 1k tbc (default) > Metadata: > stereo_mode : right_left > Side data: > stereo3d: side by side (inverted) > --[end of ffprobe output]-- > > Note that ffprobe SAR and DAR do not match what ffmpeg thought it wrote. > This is what I'm fixing. With my fix, ffprobe reports what ffmpeg said it > wrote. > > Here is what the output looks like with my change: > > ---[ffmpeg output]--- > Input #0, matroska,webm, from 'fp3_RL_640x360.webm': > Metadata: > encoder : google > Duration: 00:00:04.88, start: 0.00, bitrate: 208 kb/s > Stream #0:0: Video: vp8, yuv420p, 640x360, SAR 2:1 DAR 32:9, 23.98 fps, > 23.98 tbr, 1k tbn, 1k tbc (default) > Metadata: > stereo_mode : right_left > Side data: > stereo3d: side by side (inverted) > [libvpx-vp9 @ 0x1fb0fa0] v1.4.0-729-g8bf791e > Output #0, webm, t
[FFmpeg-devel] [PATCH 7/7] lavf/mpegtsenc: add automatic bitstream filtering
---
libavformat/mpegtsenc.c | 65 ++---
1 file changed, 35 insertions(+), 30 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 468bad4..a8fb3a2 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -698,7 +698,7 @@ static void section_write_packet(MpegTSSection *s, const
uint8_t *packet)
avio_write(ctx->pb, packet, TS_PACKET_SIZE);
}
-static int mpegts_write_header(AVFormatContext *s)
+static int mpegts_init(AVFormatContext *s)
{
MpegTSWrite *ts = s->priv_data;
MpegTSWriteStream *ts_st;
@@ -920,26 +920,6 @@ static int mpegts_write_header(AVFormatContext *s)
fail:
av_freep(&pids);
-for (i = 0; i < s->nb_streams; i++) {
-st= s->streams[i];
-ts_st = st->priv_data;
-if (ts_st) {
-av_freep(&ts_st->payload);
-if (ts_st->amux) {
-avformat_free_context(ts_st->amux);
-ts_st->amux = NULL;
-}
-}
-av_freep(&st->priv_data);
-}
-
-for (i = 0; i < ts->nb_services; i++) {
-service = ts->services[i];
-av_freep(&service->provider_name);
-av_freep(&service->name);
-av_freep(&service);
-}
-av_freep(&ts->services);
return ret;
}
@@ -1674,20 +1654,27 @@ static int mpegts_write_packet(AVFormatContext *s,
AVPacket *pkt)
static int mpegts_write_end(AVFormatContext *s)
{
+if (s->pb)
+mpegts_write_flush(s);
+
+return 0;
+}
+
+static void mpegts_deinit(AVFormatContext *s)
+{
MpegTSWrite *ts = s->priv_data;
MpegTSService *service;
int i;
-if (s->pb)
-mpegts_write_flush(s);
-
for (i = 0; i < s->nb_streams; i++) {
AVStream *st = s->streams[i];
MpegTSWriteStream *ts_st = st->priv_data;
-av_freep(&ts_st->payload);
-if (ts_st->amux) {
-avformat_free_context(ts_st->amux);
-ts_st->amux = NULL;
+if (ts_st) {
+av_freep(&ts_st->payload);
+if (ts_st->amux) {
+avformat_free_context(ts_st->amux);
+ts_st->amux = NULL;
+}
}
}
@@ -1698,8 +1685,24 @@ static int mpegts_write_end(AVFormatContext *s)
av_freep(&service);
}
av_freep(&ts->services);
+}
-return 0;
+static int mpegts_check_bitstream(struct AVFormatContext *s, const AVPacket
*pkt)
+{
+int ret = 1;
+AVStream *st = s->streams[pkt->stream_index];
+
+if (st->codec->codec_id == AV_CODEC_ID_H264) {
+if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
+ AV_RB24(pkt->data) != 0x01)
+ret = ff_stream_add_bitstream_filter(st, "h264_mp4toannexb", NULL);
+} else if (st->codec->codec_id == AV_CODEC_ID_HEVC) {
+if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
+ AV_RB24(pkt->data) != 0x01)
+ret = ff_stream_add_bitstream_filter(st, "hevc_mp4toannexb", NULL);
+}
+
+return ret;
}
static const AVOption options[] = {
@@ -1803,9 +1806,11 @@ AVOutputFormat ff_mpegts_muxer = {
.priv_data_size = sizeof(MpegTSWrite),
.audio_codec= AV_CODEC_ID_MP2,
.video_codec= AV_CODEC_ID_MPEG2VIDEO,
-.write_header = mpegts_write_header,
+.init = mpegts_init,
.write_packet = mpegts_write_packet,
.write_trailer = mpegts_write_end,
+.deinit = mpegts_deinit,
+.check_bitstream = mpegts_check_bitstream,
.flags = AVFMT_ALLOW_FLUSH | AVFMT_VARIABLE_FPS,
.priv_class = &mpegts_muxer_class,
};
--
2.6.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/7] lavf: add API to append a bsf to a stream's list
---
libavformat/internal.h | 11 +++
libavformat/utils.c| 19 +++
2 files changed, 30 insertions(+)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 5ed548e..dcd2971 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -467,6 +467,17 @@ enum AVChromaLocation
ff_choose_chroma_location(AVFormatContext *s, AVStream *st
int ff_generate_avci_extradata(AVStream *st);
/**
+ * Add a bitstream filter to a stream.
+ *
+ * @param st output stream to add a filter to
+ * @param name the name of the filter to add
+ * @param args filter-specific argument string
+ * @return >0 on success;
+ * AVERROR code on failure
+ */
+int ff_stream_add_bitstream_filter(AVStream *st, const char *name, const char
*args);
+
+/**
* Wrap errno on rename() error.
*
* @param oldpath source path
diff --git a/libavformat/utils.c b/libavformat/utils.c
index f751e2a..0fcf01b 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4643,6 +4643,25 @@ uint8_t *av_stream_new_side_data(AVStream *st, enum
AVPacketSideDataType type,
return data;
}
+int ff_stream_add_bitstream_filter(AVStream *st, const char *name, const char
*args)
+{
+AVBitStreamFilterContext *bsfc = NULL;
+AVBitStreamFilterContext **dest = &st->internal->bsfc;
+while (*dest && (*dest)->next)
+dest = &(*dest)->next;
+
+if (!(bsfc = av_bitstream_filter_init(name))) {
+av_log(NULL, AV_LOG_FATAL, "Unknown bitstream filter %s\n", name);
+return AVERROR(EINVAL);
+}
+if (args && !(bsfc->args = av_strdup(args))) {
+av_bitstream_filter_close(bsfc);
+return AVERROR(ENOMEM);
+}
+*dest = bsfc;
+return 1;
+}
+
int av_apply_bitstream_filters(AVCodecContext *codec, AVPacket *pkt,
AVBitStreamFilterContext *bsfc)
{
--
2.6.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 6/7] lavf/matroskaenc: add automatic bitstream filtering
---
libavformat/matroskaenc.c | 43 +++
1 file changed, 35 insertions(+), 8 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 10cf0a0..85e5d82 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -845,9 +845,6 @@ static int mkv_write_track(AVFormatContext *s,
MatroskaMuxContext *mkv,
int j, ret;
AVDictionaryEntry *tag;
-// ms precision is the de-facto standard timescale for mkv files
-avpriv_set_pts_info(st, 64, 1, 1000);
-
if (codec->codec_type == AVMEDIA_TYPE_ATTACHMENT) {
mkv->have_attachments = 1;
return 0;
@@ -1388,11 +1385,6 @@ static int mkv_write_header(AVFormatContext *s)
else
mkv->mode = MODE_MATROSKAv2;
-if (s->avoid_negative_ts < 0) {
-s->avoid_negative_ts = 1;
-s->internal->avoid_negative_ts_use_pts = 1;
-}
-
if (mkv->mode != MODE_WEBM ||
av_dict_get(s->metadata, "stereo_mode", NULL, 0) ||
av_dict_get(s->metadata, "alpha_mode", NULL, 0))
@@ -2098,6 +2090,35 @@ static int mkv_query_codec(enum AVCodecID codec_id, int
std_compliance)
return 0;
}
+static int mkv_init(struct AVFormatContext *s)
+{
+int i;
+
+if (s->avoid_negative_ts < 0) {
+s->avoid_negative_ts = 1;
+s->internal->avoid_negative_ts_use_pts = 1;
+}
+
+for (i = 0; i < s->nb_streams; i++) {
+// ms precision is the de-facto standard timescale for mkv files
+avpriv_set_pts_info(s->streams[i], 64, 1, 1000);
+}
+
+return 0;
+}
+
+static int mkv_check_bitstream(struct AVFormatContext *s, const AVPacket *pkt)
+{
+int ret = 1;
+AVStream *st = s->streams[pkt->stream_index];
+
+if (st->codec->codec_id == AV_CODEC_ID_AAC)
+if (pkt->size > 2 && (AV_RB16(pkt->data) & 0xfff0) == 0xfff0)
+ret = ff_stream_add_bitstream_filter(st, "aac_adtstoasc", NULL);
+
+return ret;
+}
+
static const AVCodecTag additional_audio_tags[] = {
{ AV_CODEC_ID_ALAC, 0X },
{ AV_CODEC_ID_EAC3, 0X },
@@ -2160,6 +2181,7 @@ AVOutputFormat ff_matroska_muxer = {
AV_CODEC_ID_VORBIS : AV_CODEC_ID_AC3,
.video_codec = CONFIG_LIBX264_ENCODER ?
AV_CODEC_ID_H264 : AV_CODEC_ID_MPEG4,
+.init = mkv_init,
.write_header = mkv_write_header,
.write_packet = mkv_write_flush_packet,
.write_trailer = mkv_write_trailer,
@@ -2171,6 +2193,7 @@ AVOutputFormat ff_matroska_muxer = {
},
.subtitle_codec= AV_CODEC_ID_ASS,
.query_codec = mkv_query_codec,
+.check_bitstream = mkv_check_bitstream,
.priv_class= &matroska_class,
};
#endif
@@ -2192,9 +2215,11 @@ AVOutputFormat ff_webm_muxer = {
.audio_codec = CONFIG_LIBOPUS_ENCODER ? AV_CODEC_ID_OPUS :
AV_CODEC_ID_VORBIS,
.video_codec = CONFIG_LIBVPX_VP9_ENCODER? AV_CODEC_ID_VP9 :
AV_CODEC_ID_VP8,
.subtitle_codec= AV_CODEC_ID_WEBVTT,
+.init = mkv_init,
.write_header = mkv_write_header,
.write_packet = mkv_write_flush_packet,
.write_trailer = mkv_write_trailer,
+.check_bitstream = mkv_check_bitstream,
.flags = AVFMT_GLOBALHEADER | AVFMT_VARIABLE_FPS |
AVFMT_TS_NONSTRICT | AVFMT_ALLOW_FLUSH,
.priv_class= &webm_class,
@@ -2217,9 +2242,11 @@ AVOutputFormat ff_matroska_audio_muxer = {
.audio_codec = CONFIG_LIBVORBIS_ENCODER ?
AV_CODEC_ID_VORBIS : AV_CODEC_ID_AC3,
.video_codec = AV_CODEC_ID_NONE,
+.init = mkv_init,
.write_header = mkv_write_header,
.write_packet = mkv_write_flush_packet,
.write_trailer = mkv_write_trailer,
+.check_bitstream = mkv_check_bitstream,
.flags = AVFMT_GLOBALHEADER | AVFMT_TS_NONSTRICT |
AVFMT_ALLOW_FLUSH,
.codec_tag = (const AVCodecTag* const []){
--
2.6.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/7] lavf: add automatic bitstream filtering
This solves the problem discussed in
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179238.html
by allowing AVCodec::write_header to be delayed until after packets have been
run through required bitstream filters in order to generate global extradata.
It also provides a mechanism by which a muxer can add a bitstream filter to a
stream automatically, rather than prompting the user to do so.
---
libavformat/avformat.h | 23 +++
libavformat/internal.h | 17 +
libavformat/mux.c | 47 +--
3 files changed, 85 insertions(+), 2 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index d94191e..edbf4cf 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -600,6 +600,29 @@ typedef struct AVOutputFormat {
*/
int (*free_device_capabilities)(struct AVFormatContext *s, struct
AVDeviceCapabilitiesQuery *caps);
enum AVCodecID data_codec; /**< default data codec */
+/**
+ * Initialize format. May allocate data here, and set any AVFormatContext
or
+ * AVStream parameters that need to be set before packets are sent.
+ * This method must not write output.
+ *
+ * Any allocations made here must be freed in deinit().
+ */
+int (*init)(struct AVFormatContext *);
+/**
+ * Deinitialize format. If present, this is called whenever the muxer is
being
+ * destroyed, regardless of whether or not the header has been written.
+ *
+ * If a trailer is being written, this is called after write_trailer().
+ *
+ * This is called if init() fails as well.
+ */
+void (*deinit)(struct AVFormatContext *);
+/**
+ * Set up any necessary bitstream filtering and extract any extra data
needed
+ * for the global header.
+ * Return 0 if more packets from this stream must be checked; 1 if not.
+ */
+int (*check_bitstream)(struct AVFormatContext *, const AVPacket *pkt);
} AVOutputFormat;
/**
* @}
diff --git a/libavformat/internal.h b/libavformat/internal.h
index ee86094..5ed548e 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -117,6 +117,11 @@ struct AVFormatInternal {
int inject_global_side_data;
int avoid_negative_ts_use_pts;
+
+/**
+ * Whether or not a header has already been written
+ */
+int header_written;
};
struct AVStreamInternal {
@@ -125,6 +130,18 @@ struct AVStreamInternal {
* from dts.
*/
int reorder;
+
+/**
+ * bitstream filter to run on stream
+ * - encoding: Set by muxer using ff_stream_add_bitstream_filter
+ * - decoding: unused
+ */
+AVBitStreamFilterContext *bsfc;
+
+/**
+ * Whether or not check_bitstream should still be run on each packet
+ */
+int bitstream_checked;
};
#ifdef __GNUC__
diff --git a/libavformat/mux.c b/libavformat/mux.c
index 05d4170..f3abe0d 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -405,6 +405,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
*options = tmp;
}
+if (s->oformat->init && (ret = s->oformat->init(s)) < 0) {
+s->oformat->deinit(s);
+goto fail;
+}
+
return 0;
fail:
@@ -456,7 +461,7 @@ int avformat_write_header(AVFormatContext *s, AVDictionary
**options)
if ((ret = init_muxer(s, options)) < 0)
return ret;
-if (s->oformat->write_header) {
+if (s->oformat->write_header && !s->oformat->check_bitstream) {
ret = s->oformat->write_header(s);
if (ret >= 0 && s->pb && s->pb->error < 0)
ret = s->pb->error;
@@ -464,6 +469,7 @@ int avformat_write_header(AVFormatContext *s, AVDictionary
**options)
return ret;
if (s->flush_packets && s->pb && s->pb->error >= 0 && s->flags &
AVFMT_FLAG_FLUSH_PACKETS)
avio_flush(s->pb);
+s->internal->header_written = 1;
}
if ((ret = init_pts(s)) < 0)
@@ -1021,6 +1027,17 @@ int av_interleaved_write_frame(AVFormatContext *s,
AVPacket *pkt)
ret = AVERROR(EINVAL);
goto fail;
}
+
+if (s->oformat->check_bitstream) {
+if (!st->internal->bitstream_checked) {
+if ((ret = s->oformat->check_bitstream(s, pkt)) < 0)
+goto fail;
+else if (ret == 1)
+st->internal->bitstream_checked = 1;
+}
+}
+
+av_apply_bitstream_filters(st->codec, pkt, st->internal->bsfc);
} else {
av_log(s, AV_LOG_TRACE, "av_interleaved_write_frame FLUSH\n");
flush = 1;
@@ -1037,10 +1054,22 @@ int av_interleaved_write_frame(AVFormatContext *s,
AVPacket *pkt)
if (ret <= 0) //FIXME cleanup needed for ret<0 ?
return ret;
+if (!s->internal->header_written && s->oformat->write_header) {
+ret = s->oformat->write_header(s);
+if (ret >= 0 && s->pb && s->pb->error < 0)
+ret = s-
[FFmpeg-devel] [PATCH 3/7] lavf/tee: use lavf API for applying bitstream filters
---
libavformat/tee.c | 44 +++-
1 file changed, 3 insertions(+), 41 deletions(-)
diff --git a/libavformat/tee.c b/libavformat/tee.c
index af52a49..8c54d32 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -405,45 +405,6 @@ fail:
return ret;
}
-static int filter_packet(void *log_ctx, AVPacket *pkt,
- AVFormatContext *fmt_ctx, AVBitStreamFilterContext
*bsf_ctx)
-{
-AVCodecContext *enc_ctx = fmt_ctx->streams[pkt->stream_index]->codec;
-int ret = 0;
-
-while (bsf_ctx) {
-AVPacket new_pkt = *pkt;
-ret = av_bitstream_filter_filter(bsf_ctx, enc_ctx, NULL,
- &new_pkt.data, &new_pkt.size,
- pkt->data, pkt->size,
- pkt->flags & AV_PKT_FLAG_KEY);
-if (ret == 0 && new_pkt.data != pkt->data) {
-if ((ret = av_copy_packet(&new_pkt, pkt)) < 0)
-break;
-ret = 1;
-}
-
-if (ret > 0) {
-av_packet_unref(pkt);
-new_pkt.buf = av_buffer_create(new_pkt.data, new_pkt.size,
- av_buffer_default_free, NULL, 0);
-if (!new_pkt.buf)
-break;
-}
-if (ret < 0) {
-av_log(log_ctx, AV_LOG_ERROR,
-"Failed to filter bitstream with filter %s for stream %d in
file '%s' with codec %s\n",
-bsf_ctx->filter->name, pkt->stream_index, fmt_ctx->filename,
-avcodec_get_name(enc_ctx->codec_id));
-}
-*pkt = new_pkt;
-
-bsf_ctx = bsf_ctx->next;
-}
-
-return ret;
-}
-
static int tee_write_trailer(AVFormatContext *avf)
{
TeeContext *tee = avf->priv_data;
@@ -496,8 +457,9 @@ static int tee_write_packet(AVFormatContext *avf, AVPacket
*pkt)
pkt2.duration = av_rescale_q(pkt->duration, tb, tb2);
pkt2.stream_index = s2;
-filter_packet(avf2, &pkt2, avf2, tee->slaves[i].bsfs[s2]);
-if ((ret = av_interleaved_write_frame(avf2, &pkt2)) < 0)
+if ((ret = av_apply_bitstream_filters(avf2->streams[s2]->codec, &pkt2,
+ tee->slaves[i].bsfs[s2])) < 0 ||
+(ret = av_interleaved_write_frame(avf2, &pkt2)) < 0)
if (!ret_all)
ret_all = ret;
}
--
2.6.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/7] ffmpeg: use lavf API for applying bitstream filters
---
ffmpeg.c | 46 --
ffmpeg.h | 1 -
ffmpeg_opt.c | 6 +-
3 files changed, 9 insertions(+), 44 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index bf5e983..c24c8ed 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -683,47 +683,10 @@ static void write_frame(AVFormatContext *s, AVPacket
*pkt, OutputStream *ost)
if (bsfc)
av_packet_split_side_data(pkt);
-while (bsfc) {
-AVPacket new_pkt = *pkt;
-AVDictionaryEntry *bsf_arg = av_dict_get(ost->bsf_args,
- bsfc->filter->name,
- NULL, 0);
-int a = av_bitstream_filter_filter(bsfc, avctx,
- bsf_arg ? bsf_arg->value : NULL,
- &new_pkt.data, &new_pkt.size,
- pkt->data, pkt->size,
- pkt->flags & AV_PKT_FLAG_KEY);
-if(a == 0 && new_pkt.data != pkt->data) {
-uint8_t *t = av_malloc(new_pkt.size +
AV_INPUT_BUFFER_PADDING_SIZE); //the new should be a subset of the old so
cannot overflow
-if(t) {
-memcpy(t, new_pkt.data, new_pkt.size);
-memset(t + new_pkt.size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
-new_pkt.data = t;
-new_pkt.buf = NULL;
-a = 1;
-} else
-a = AVERROR(ENOMEM);
-}
-if (a > 0) {
-pkt->side_data = NULL;
-pkt->side_data_elems = 0;
-av_packet_unref(pkt);
-new_pkt.buf = av_buffer_create(new_pkt.data, new_pkt.size,
- av_buffer_default_free, NULL, 0);
-if (!new_pkt.buf)
-exit_program(1);
-} else if (a < 0) {
-new_pkt = *pkt;
-av_log(NULL, AV_LOG_ERROR, "Failed to open bitstream filter %s for
stream %d with codec %s",
- bsfc->filter->name, pkt->stream_index,
- avctx->codec ? avctx->codec->name : "copy");
-print_error("", a);
-if (exit_on_error)
-exit_program(1);
-}
-*pkt = new_pkt;
-
-bsfc = bsfc->next;
+if ((ret = av_apply_bitstream_filters(avctx, pkt, bsfc)) < 0) {
+print_error("", ret);
+if (exit_on_error)
+exit_program(1);
}
if (!(s->oformat->flags & AVFMT_NOTIMESTAMPS)) {
@@ -4190,7 +4153,6 @@ static int transcode(void)
av_dict_free(&ost->sws_dict);
av_dict_free(&ost->swr_opts);
av_dict_free(&ost->resample_opts);
-av_dict_free(&ost->bsf_args);
}
}
}
diff --git a/ffmpeg.h b/ffmpeg.h
index 82ab1ee..6eeb152 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -452,7 +452,6 @@ typedef struct OutputStream {
AVDictionary *sws_dict;
AVDictionary *swr_opts;
AVDictionary *resample_opts;
-AVDictionary *bsf_args;
char *apad;
OSTFinished finished;/* no more packets should be written for this
stream */
int unavailable; /* true if the steram is unavailable
(possibly temporarily) */
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 131dd89..ca1640c 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -1255,7 +1255,11 @@ static OutputStream *new_output_stream(OptionsContext
*o, AVFormatContext *oc, e
bsfc_prev->next = bsfc;
else
ost->bitstream_filters = bsfc;
-av_dict_set(&ost->bsf_args, bsfc->filter->name, arg, 0);
+if (arg)
+if (!(bsfc->args = av_strdup(arg))) {
+av_log(NULL, AV_LOG_FATAL, "Bitstream filter memory allocation
failed\n");
+exit_program(1);
+}
bsfc_prev = bsfc;
bsf = next;
--
2.6.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/7] lavf: add API to apply a list of bsfs to a packet
---
libavformat/avformat.h | 11 +++
libavformat/utils.c| 49 +
2 files changed, 60 insertions(+)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 36f9d02..d94191e 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2761,6 +2761,17 @@ int avformat_match_stream_specifier(AVFormatContext *s,
AVStream *st,
int avformat_queue_attached_pictures(AVFormatContext *s);
+/**
+ * Apply a list of bitstream filters to a packet.
+ *
+ * @param codec AVCodecContext, usually from an AVStream
+ * @param pkt the packet to apply filters to
+ * @param bsfc a NULL-terminated list of filters to apply
+ * @return >=0 on success;
+ * AVERROR code on failure
+ */
+int av_apply_bitstream_filters(AVCodecContext *codec, AVPacket *pkt,
+ AVBitStreamFilterContext *bsfc);
/**
* @}
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 8cb7d38..f751e2a 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4642,3 +4642,52 @@ uint8_t *av_stream_new_side_data(AVStream *st, enum
AVPacketSideDataType type,
sd->size = size;
return data;
}
+
+int av_apply_bitstream_filters(AVCodecContext *codec, AVPacket *pkt,
+ AVBitStreamFilterContext *bsfc)
+{
+int ret = 0;
+while (bsfc) {
+AVPacket new_pkt = *pkt;
+int a = av_bitstream_filter_filter(bsfc, codec, NULL,
+ &new_pkt.data, &new_pkt.size,
+ pkt->data, pkt->size,
+ pkt->flags & AV_PKT_FLAG_KEY);
+if(a == 0 && new_pkt.data != pkt->data) {
+uint8_t *t = av_malloc(new_pkt.size +
AV_INPUT_BUFFER_PADDING_SIZE); //the new should be a subset of the old so
cannot overflow
+if (t) {
+memcpy(t, new_pkt.data, new_pkt.size);
+memset(t + new_pkt.size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+new_pkt.data = t;
+new_pkt.buf = NULL;
+a = 1;
+} else {
+a = AVERROR(ENOMEM);
+}
+}
+if (a > 0) {
+new_pkt.buf = av_buffer_create(new_pkt.data, new_pkt.size,
+ av_buffer_default_free, NULL, 0);
+if (new_pkt.buf) {
+pkt->side_data = NULL;
+pkt->side_data_elems = 0;
+av_packet_unref(pkt);
+} else {
+av_freep(&new_pkt.data);
+a = AVERROR(ENOMEM);
+}
+}
+if (a < 0) {
+av_log(codec, AV_LOG_ERROR,
+ "Failed to open bitstream filter %s for stream %d with
codec %s",
+ bsfc->filter->name, pkt->stream_index,
+ codec->codec ? codec->codec->name : "copy");
+ret = a;
+break;
+}
+*pkt = new_pkt;
+
+bsfc = bsfc->next;
+}
+return ret;
+}
--
2.6.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] ffserver_config: replace strtod by av_strtod and correct undefined behavior
On Mon, Nov 30, 2015 at 3:31 PM, Reynaldo H. Verdejo Pinochet wrote: > This one looks OK (pending a final decision on > av_clipd64()) I don't think any decision needs to be made, i.e it has passed review. The problem is that it is currently locked in avutil/internal and needs to be exposed in some public header of avutil. Unfortunately, I can't do it myself since: 1. I can't test on Windows, which caused the issues and locking away of the API in the first place. Any effort I make will naturally be untested. 2. This API and related design stuff is not my forte or area of interest. > > Bests, > > -- > Reynaldo > ___ > 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] qsvenc: write a53 caption data to SEI
On Mon, Nov 30, 2015 at 09:17:26AM -0600, Will Kelleher wrote: > On 11/26, Michael Niedermayer wrote: > > > > I tried to apply this but it seems to doesnt apply cleanly anymore > > id fix the conflicts and apply but i cant test this so i think its > > better if you would fix it > > > > Here is a rebased version. > > will > qsv_internal.h |3 ++ > qsvenc.c | 39 ++--- > qsvenc.h |4 +++ > qsvenc_h264.c | 66 > + > 4 files changed, 108 insertions(+), 4 deletions(-) > 683980d90c5baeafcbace922e34b6b29f9a71890 > 0001-qsvenc-write-a53-caption-data-to-SEI.patch > From 5452911c08cdb8cebe861d38a9c1b12924120d78 Mon Sep 17 00:00:00 2001 > From: Will Kelleher > Date: Tue, 27 Oct 2015 12:08:45 -0500 > Subject: [PATCH] qsvenc: write a53 caption data to SEI applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mp3dec: prefer "fast_seek" to TOC seek for CBR files.
From: Chris Cunningham
"Fast seek" uses linear interpolation to find the position of the
requested seek time. For CBR this is more direct than using the
mp3 TOC and bypassing the TOC avoids problems with TOC precision.
(see https://crbug.com/545914#c13)
For VBR, fast seek is not precise, so continue to prefer the TOC
when available (the lesser of two evils).
Also, some re-ordering of the logic in mp3_seek to simplify and
give usetoc=1 precedence over fastseek flag.
---
libavformat/mp3dec.c| 42 --
libavformat/seek-test.c | 8 +---
tests/fate/seek.mak | 2 +-
3 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 32ca00c..3dc2b5c 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -115,7 +115,8 @@ static void read_xing_toc(AVFormatContext *s, int64_t
filesize, int64_t duration
{
int i;
MP3DecContext *mp3 = s->priv_data;
-int fill_index = mp3->usetoc == 1 && duration > 0;
+int fast_seek = s->flags & AVFMT_FLAG_FAST_SEEK;
+int fill_index = (mp3->usetoc || fast_seek) && duration > 0;
if (!filesize &&
!(filesize = avio_size(s->pb))) {
@@ -344,9 +345,6 @@ static int mp3_read_header(AVFormatContext *s)
int ret;
int i;
-if (mp3->usetoc < 0)
-mp3->usetoc = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 2;
-
st = avformat_new_stream(s, NULL);
if (!st)
return AVERROR(ENOMEM);
@@ -501,38 +499,38 @@ static int mp3_seek(AVFormatContext *s, int stream_index,
int64_t timestamp,
MP3DecContext *mp3 = s->priv_data;
AVIndexEntry *ie, ie1;
AVStream *st = s->streams[0];
-int64_t ret = av_index_search_timestamp(st, timestamp, flags);
-int64_t best_pos;
-int fast_seek = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 0;
+int fast_seek = s->flags & AVFMT_FLAG_FAST_SEEK;
int64_t filesize = mp3->header_filesize;
-if (mp3->usetoc == 2)
-return -1; // generic index code
-
if (filesize <= 0) {
int64_t size = avio_size(s->pb);
if (size > 0 && size > s->internal->data_offset)
filesize = size - s->internal->data_offset;
}
-if ( (mp3->is_cbr || fast_seek)
-&& (mp3->usetoc == 0 || !mp3->xing_toc)
-&& st->duration > 0
-&& filesize > 0) {
-ie = &ie1;
-timestamp = av_clip64(timestamp, 0, st->duration);
-ie->timestamp = timestamp;
-ie->pos = av_rescale(timestamp, filesize, st->duration) +
s->internal->data_offset;
-} else if (mp3->xing_toc) {
+if (mp3->xing_toc && (mp3->usetoc || (fast_seek && !mp3->is_cbr))) {
+// NOTE: The MP3 TOC is not a precise lookup table. Accuracy is worse
+// for bigger files.
+av_log(s, AV_LOG_WARNING, "Using MP3 TOC to seek; may be
imprecise.\n");
+
+int64_t ret = av_index_search_timestamp(st, timestamp, flags);
if (ret < 0)
return ret;
ie = &st->index_entries[ret];
+} else if (fast_seek && st->duration > 0 && filesize > 0) {
+if (!mp3->is_cbr)
+av_log(s, AV_LOG_WARNING, "Using scaling to seek VBR MP3; may be
imprecise.\n");
+
+ie = &ie1;
+timestamp = av_clip64(timestamp, 0, st->duration);
+ie->timestamp = timestamp;
+ie->pos = av_rescale(timestamp, filesize, st->duration) +
s->internal->data_offset;
} else {
-return -1;
+return -1; // generic index code
}
-best_pos = mp3_sync(s, ie->pos, flags);
+int64_t best_pos = mp3_sync(s, ie->pos, flags);
if (best_pos < 0)
return best_pos;
@@ -546,7 +544,7 @@ static int mp3_seek(AVFormatContext *s, int stream_index,
int64_t timestamp,
}
static const AVOption options[] = {
-{ "usetoc", "use table of contents", offsetof(MP3DecContext, usetoc),
AV_OPT_TYPE_INT, {.i64 = -1}, -1, 2, AV_OPT_FLAG_DECODING_PARAM},
+{ "usetoc", "use table of contents", offsetof(MP3DecContext, usetoc),
AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM},
{ NULL },
};
diff --git a/libavformat/seek-test.c b/libavformat/seek-test.c
index 1926f21..bfd06db 100644
--- a/libavformat/seek-test.c
+++ b/libavformat/seek-test.c
@@ -56,7 +56,7 @@ static void ts_str(char buffer[60], int64_t ts, AVRational
base)
int main(int argc, char **argv)
{
const char *filename;
-AVFormatContext *ic = NULL;
+AVFormatContext *ic = avformat_alloc_context();
int i, ret, stream_id;
int j;
int64_t timestamp;
@@ -76,8 +76,10 @@ int main(int argc, char **argv)
frame_count = atoi(argv[i+1]);
} else if(!strcmp(argv[i], "-duration")){
duration = atoi(argv[i+1]);
-} else if(!strcmp(argv[i], "-usetoc")) {
-av_dict_set(&format_opts, "usetoc", argv[i+1], 0);
+} else if(!strcmp(argv[i], "-fastseek")) {
+if (atoi(argv[i+1])) {
+ic->flags |= AVFMT_FL
Re: [FFmpeg-devel] [PATCH] avformat/mp3dec: prefer "fast_seek" to TOC seek for CBR files.
Looks like I messed up the tab for "return best_pos;"... fix incoming.
On Mon, Nov 30, 2015 at 2:10 PM, wrote:
> From: Chris Cunningham
>
> "Fast seek" uses linear interpolation to find the position of the
> requested seek time. For CBR this is more direct than using the
> mp3 TOC and bypassing the TOC avoids problems with TOC precision.
> (see https://crbug.com/545914#c13)
>
> For VBR, fast seek is not precise, so continue to prefer the TOC
> when available (the lesser of two evils).
>
> Also, some re-ordering of the logic in mp3_seek to simplify and
> give usetoc=1 precedence over fastseek flag.
> ---
> libavformat/mp3dec.c| 44 +---
> libavformat/seek-test.c | 8 +---
> tests/fate/seek.mak | 2 +-
> 3 files changed, 27 insertions(+), 27 deletions(-)
>
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index 32ca00c..3c8c0ee 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -115,7 +115,8 @@ static void read_xing_toc(AVFormatContext *s, int64_t
> filesize, int64_t duration
> {
> int i;
> MP3DecContext *mp3 = s->priv_data;
> -int fill_index = mp3->usetoc == 1 && duration > 0;
> +int fast_seek = s->flags & AVFMT_FLAG_FAST_SEEK;
> +int fill_index = (mp3->usetoc || fast_seek) && duration > 0;
>
> if (!filesize &&
> !(filesize = avio_size(s->pb))) {
> @@ -344,9 +345,6 @@ static int mp3_read_header(AVFormatContext *s)
> int ret;
> int i;
>
> -if (mp3->usetoc < 0)
> -mp3->usetoc = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 2;
> -
> st = avformat_new_stream(s, NULL);
> if (!st)
> return AVERROR(ENOMEM);
> @@ -501,40 +499,40 @@ static int mp3_seek(AVFormatContext *s, int
> stream_index, int64_t timestamp,
> MP3DecContext *mp3 = s->priv_data;
> AVIndexEntry *ie, ie1;
> AVStream *st = s->streams[0];
> -int64_t ret = av_index_search_timestamp(st, timestamp, flags);
> -int64_t best_pos;
> -int fast_seek = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 0;
> +int fast_seek = s->flags & AVFMT_FLAG_FAST_SEEK;
> int64_t filesize = mp3->header_filesize;
>
> -if (mp3->usetoc == 2)
> -return -1; // generic index code
> -
> if (filesize <= 0) {
> int64_t size = avio_size(s->pb);
> if (size > 0 && size > s->internal->data_offset)
> filesize = size - s->internal->data_offset;
> }
>
> -if ( (mp3->is_cbr || fast_seek)
> -&& (mp3->usetoc == 0 || !mp3->xing_toc)
> -&& st->duration > 0
> -&& filesize > 0) {
> -ie = &ie1;
> -timestamp = av_clip64(timestamp, 0, st->duration);
> -ie->timestamp = timestamp;
> -ie->pos = av_rescale(timestamp, filesize, st->duration) +
> s->internal->data_offset;
> -} else if (mp3->xing_toc) {
> +if (mp3->xing_toc && (mp3->usetoc || (fast_seek && !mp3->is_cbr))) {
> +// NOTE: The MP3 TOC is not a precise lookup table. Accuracy is
> worse
> +// for bigger files.
> +av_log(s, AV_LOG_WARNING, "Using MP3 TOC to seek; may be
> imprecise.\n");
> +
> +int64_t ret = av_index_search_timestamp(st, timestamp, flags);
> if (ret < 0)
> return ret;
>
> ie = &st->index_entries[ret];
> +} else if (fast_seek && st->duration > 0 && filesize > 0) {
> +if (!mp3->is_cbr)
> +av_log(s, AV_LOG_WARNING, "Using scaling to seek VBR MP3; may
> be imprecise.\n");
> +
> +ie = &ie1;
> +timestamp = av_clip64(timestamp, 0, st->duration);
> +ie->timestamp = timestamp;
> +ie->pos = av_rescale(timestamp, filesize, st->duration) +
> s->internal->data_offset;
> } else {
> -return -1;
> +return -1; // generic index code
> }
>
> -best_pos = mp3_sync(s, ie->pos, flags);
> +int64_t best_pos = mp3_sync(s, ie->pos, flags);
> if (best_pos < 0)
> -return best_pos;
> + return best_pos;
>
> if (mp3->is_cbr && ie == &ie1 && mp3->frames) {
> int frame_duration = av_rescale(st->duration, 1, mp3->frames);
> @@ -546,7 +544,7 @@ static int mp3_seek(AVFormatContext *s, int
> stream_index, int64_t timestamp,
> }
>
> static const AVOption options[] = {
> -{ "usetoc", "use table of contents", offsetof(MP3DecContext, usetoc),
> AV_OPT_TYPE_INT, {.i64 = -1}, -1, 2, AV_OPT_FLAG_DECODING_PARAM},
> +{ "usetoc", "use table of contents", offsetof(MP3DecContext, usetoc),
> AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM},
> { NULL },
> };
>
> diff --git a/libavformat/seek-test.c b/libavformat/seek-test.c
> index 1926f21..bfd06db 100644
> --- a/libavformat/seek-test.c
> +++ b/libavformat/seek-test.c
> @@ -56,7 +56,7 @@ static void ts_str(char buffer[60], int64_t ts,
> AVRational base)
> int main(int argc, char **argv)
> {
> const char *filename;
> -AVFormatContext *ic = NULL;
> +AVFormatContext *ic = avformat_alloc_context
Re: [FFmpeg-devel] [PATCH 5/5] lavfi: make request_frame() non-recursive.
On Sun, Nov 29, 2015 at 5:21 PM, Nicolas George wrote:
> Instead of calling the input filter request_frame() method,
> ff_request_frame() now marks the link and returns immediately.
> bufferskin is changed to activate the marked filters until
> a frame is obtained.
>
> Signed-off-by: Nicolas George
> ---
> libavfilter/avfilter.c | 20 +++-
> libavfilter/avfilter.h | 14 +++
> libavfilter/avfiltergraph.c | 58
> +
> libavfilter/buffersink.c| 5
> libavfilter/internal.h | 7 ++
> 5 files changed, 99 insertions(+), 5 deletions(-)
>
> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> index 9c7b462..e413546 100644
> --- a/libavfilter/avfilter.c
> +++ b/libavfilter/avfilter.c
> @@ -185,6 +185,7 @@ void ff_avfilter_link_set_in_status(AVFilterLink *link,
> int status, int64_t pts)
> void ff_avfilter_link_set_out_status(AVFilterLink *link, int status, int64_t
> pts)
> {
> link->status = status;
> +link->frame_wanted_in = link->frame_wanted_out = 0;
> ff_update_link_current_pts(link, pts);
> }
>
> @@ -353,11 +354,21 @@ void ff_tlog_link(void *ctx, AVFilterLink *link, int
> end)
>
> int ff_request_frame(AVFilterLink *link)
> {
> -int ret = -1;
> FF_TPRINTF_START(NULL, request_frame); ff_tlog_link(NULL, link, 1);
>
> if (link->status)
> return link->status;
> +link->frame_wanted_in = 1;
> +link->frame_wanted_out = 1;
> +return 0;
> +}
> +
> +int ff_request_frame_to_filter(AVFilterLink *link)
> +{
> +int ret = -1;
> +
> +FF_TPRINTF_START(NULL, request_frame_to_filter); ff_tlog_link(NULL,
> link, 1);
> +link->frame_wanted_in = 0;
> if (link->srcpad->request_frame)
> ret = link->srcpad->request_frame(link);
> else if (link->src->inputs[0])
> @@ -366,6 +377,9 @@ int ff_request_frame(AVFilterLink *link)
> AVFrame *pbuf = link->partial_buf;
> link->partial_buf = NULL;
> ret = ff_filter_frame_framed(link, pbuf);
> +ff_avfilter_link_set_in_status(link, AVERROR_EOF, AV_NOPTS_VALUE);
> +link->frame_wanted_out = 0;
> +return ret;
> }
> if (ret < 0) {
> if (ret != AVERROR(EAGAIN) && ret != link->status)
> @@ -1135,6 +1149,9 @@ static int ff_filter_frame_needs_framing(AVFilterLink
> *link, AVFrame *frame)
> if (pbuf->nb_samples >= link->min_samples) {
> ret = ff_filter_frame_framed(link, pbuf);
> pbuf = NULL;
> +} else {
> +if (link->frame_wanted_out)
> +link->frame_wanted_in = 1;
> }
> }
> av_frame_free(&frame);
> @@ -1176,6 +1193,7 @@ int ff_filter_frame(AVFilterLink *link, AVFrame *frame)
> }
> }
>
> +link->frame_wanted_out = 0;
> /* Go directly to actual filtering if possible */
> if (link->type == AVMEDIA_TYPE_AUDIO &&
> link->min_samples &&
> diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
> index f3a0f2d..801f29d 100644
> --- a/libavfilter/avfilter.h
> +++ b/libavfilter/avfilter.h
> @@ -515,6 +515,20 @@ struct AVFilterLink {
> * Number of past frames sent through the link.
> */
> int64_t frame_count;
> +
> +/**
> + * True if a frame is currently wanted on the input of this filter.
> + * Set when ff_request_frame() is called by the output,
> + * cleared when the request is handled or forwarded.
> + */
> +unsigned frame_wanted_in;
> +
> +/**
> + * True if a frame is currently wanted on the output of this filter.
> + * Set when ff_request_frame() is called by the output,
> + * cleared when a frame is filtered.
> + */
> +unsigned frame_wanted_out;
We generally just use ints for boolean properties, any particular
reason this uses unsigned instead?
> };
>
> /**
> diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c
> index ec2245f..9f50b41 100644
> --- a/libavfilter/avfiltergraph.c
> +++ b/libavfilter/avfiltergraph.c
> @@ -1367,11 +1367,14 @@ void ff_avfilter_graph_update_heap(AVFilterGraph
> *graph, AVFilterLink *link)
>
> int avfilter_graph_request_oldest(AVFilterGraph *graph)
> {
> +AVFilterLink *oldest = graph->sink_links[0];
> +int r;
> +
> while (graph->sink_links_count) {
> -AVFilterLink *oldest = graph->sink_links[0];
> -int r = ff_request_frame(oldest);
> +oldest = graph->sink_links[0];
> +r = ff_request_frame(oldest);
> if (r != AVERROR_EOF)
> -return r;
> +break;
> av_log(oldest->dst, AV_LOG_DEBUG, "EOF on sink link %s:%s.\n",
> oldest->dst ? oldest->dst->name : "unknown",
> oldest->dstpad ? oldest->dstpad->name : "unknown");
> @@ -1381,5 +1384,52 @@ int avfilter_graph_request_oldest(AVFilterGraph *graph)
> oldest->age_index);
> oldest->age_index = -1;
> }
> -retu
Re: [FFmpeg-devel] [PATCH 5/5] lavfi: make request_frame() non-recursive.
On Sun, Nov 29, 2015 at 05:21:52PM +0100, Nicolas George wrote: > Instead of calling the input filter request_frame() method, > ff_request_frame() now marks the link and returns immediately. > bufferskin is changed to activate the marked filters until sink didnt review the rest (might do it later if noone else does but thats no objection if you feel this is fine and want to push it) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mp3dec: prefer "fast_seek" to TOC seek for CBR files.
From: Chris Cunningham
"Fast seek" uses linear interpolation to find the position of the
requested seek time. For CBR this is more direct than using the
mp3 TOC and bypassing the TOC avoids problems with TOC precision.
(see https://crbug.com/545914#c13)
For VBR, fast seek is not precise, so continue to prefer the TOC
when available (the lesser of two evils).
Also, some re-ordering of the logic in mp3_seek to simplify and
give usetoc=1 precedence over fastseek flag.
---
libavformat/mp3dec.c| 44 +---
libavformat/seek-test.c | 8 +---
tests/fate/seek.mak | 2 +-
3 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 32ca00c..3c8c0ee 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -115,7 +115,8 @@ static void read_xing_toc(AVFormatContext *s, int64_t
filesize, int64_t duration
{
int i;
MP3DecContext *mp3 = s->priv_data;
-int fill_index = mp3->usetoc == 1 && duration > 0;
+int fast_seek = s->flags & AVFMT_FLAG_FAST_SEEK;
+int fill_index = (mp3->usetoc || fast_seek) && duration > 0;
if (!filesize &&
!(filesize = avio_size(s->pb))) {
@@ -344,9 +345,6 @@ static int mp3_read_header(AVFormatContext *s)
int ret;
int i;
-if (mp3->usetoc < 0)
-mp3->usetoc = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 2;
-
st = avformat_new_stream(s, NULL);
if (!st)
return AVERROR(ENOMEM);
@@ -501,40 +499,40 @@ static int mp3_seek(AVFormatContext *s, int stream_index,
int64_t timestamp,
MP3DecContext *mp3 = s->priv_data;
AVIndexEntry *ie, ie1;
AVStream *st = s->streams[0];
-int64_t ret = av_index_search_timestamp(st, timestamp, flags);
-int64_t best_pos;
-int fast_seek = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 0;
+int fast_seek = s->flags & AVFMT_FLAG_FAST_SEEK;
int64_t filesize = mp3->header_filesize;
-if (mp3->usetoc == 2)
-return -1; // generic index code
-
if (filesize <= 0) {
int64_t size = avio_size(s->pb);
if (size > 0 && size > s->internal->data_offset)
filesize = size - s->internal->data_offset;
}
-if ( (mp3->is_cbr || fast_seek)
-&& (mp3->usetoc == 0 || !mp3->xing_toc)
-&& st->duration > 0
-&& filesize > 0) {
-ie = &ie1;
-timestamp = av_clip64(timestamp, 0, st->duration);
-ie->timestamp = timestamp;
-ie->pos = av_rescale(timestamp, filesize, st->duration) +
s->internal->data_offset;
-} else if (mp3->xing_toc) {
+if (mp3->xing_toc && (mp3->usetoc || (fast_seek && !mp3->is_cbr))) {
+// NOTE: The MP3 TOC is not a precise lookup table. Accuracy is worse
+// for bigger files.
+av_log(s, AV_LOG_WARNING, "Using MP3 TOC to seek; may be
imprecise.\n");
+
+int64_t ret = av_index_search_timestamp(st, timestamp, flags);
if (ret < 0)
return ret;
ie = &st->index_entries[ret];
+} else if (fast_seek && st->duration > 0 && filesize > 0) {
+if (!mp3->is_cbr)
+av_log(s, AV_LOG_WARNING, "Using scaling to seek VBR MP3; may be
imprecise.\n");
+
+ie = &ie1;
+timestamp = av_clip64(timestamp, 0, st->duration);
+ie->timestamp = timestamp;
+ie->pos = av_rescale(timestamp, filesize, st->duration) +
s->internal->data_offset;
} else {
-return -1;
+return -1; // generic index code
}
-best_pos = mp3_sync(s, ie->pos, flags);
+int64_t best_pos = mp3_sync(s, ie->pos, flags);
if (best_pos < 0)
-return best_pos;
+ return best_pos;
if (mp3->is_cbr && ie == &ie1 && mp3->frames) {
int frame_duration = av_rescale(st->duration, 1, mp3->frames);
@@ -546,7 +544,7 @@ static int mp3_seek(AVFormatContext *s, int stream_index,
int64_t timestamp,
}
static const AVOption options[] = {
-{ "usetoc", "use table of contents", offsetof(MP3DecContext, usetoc),
AV_OPT_TYPE_INT, {.i64 = -1}, -1, 2, AV_OPT_FLAG_DECODING_PARAM},
+{ "usetoc", "use table of contents", offsetof(MP3DecContext, usetoc),
AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM},
{ NULL },
};
diff --git a/libavformat/seek-test.c b/libavformat/seek-test.c
index 1926f21..bfd06db 100644
--- a/libavformat/seek-test.c
+++ b/libavformat/seek-test.c
@@ -56,7 +56,7 @@ static void ts_str(char buffer[60], int64_t ts, AVRational
base)
int main(int argc, char **argv)
{
const char *filename;
-AVFormatContext *ic = NULL;
+AVFormatContext *ic = avformat_alloc_context();
int i, ret, stream_id;
int j;
int64_t timestamp;
@@ -76,8 +76,10 @@ int main(int argc, char **argv)
frame_count = atoi(argv[i+1]);
} else if(!strcmp(argv[i], "-duration")){
duration = atoi(argv[i+1]);
-} else if(!strcmp(argv[i], "-usetoc")) {
-av_dict_set(&format_opts,
Re: [FFmpeg-devel] [PATCH 4/5] lavfi: replace link.closed by link.status.
On Sun, Nov 29, 2015 at 05:21:51PM +0100, Nicolas George wrote:
> The status field can carry any error code instead of just EOF.
> Also only update it through a wrapper function and provide a timestamp.
> Update the few filters that used it directly.
>
> Signed-off-by: Nicolas George
> ---
> libavfilter/avfilter.c | 25 ++---
> libavfilter/avfilter.h | 12 ++--
> libavfilter/buffersink.c | 4 ++--
> libavfilter/f_interleave.c | 4 ++--
> libavfilter/internal.h | 12
> libavfilter/split.c| 2 +-
> libavfilter/trim.c | 6 --
> libavfilter/vf_extractplanes.c | 2 +-
> 8 files changed, 46 insertions(+), 21 deletions(-)
>
> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> index 06a8239..9c7b462 100644
> --- a/libavfilter/avfilter.c
> +++ b/libavfilter/avfilter.c
> @@ -177,9 +177,20 @@ int avfilter_link_get_channels(AVFilterLink *link)
> return link->channels;
> }
>
> +void ff_avfilter_link_set_in_status(AVFilterLink *link, int status, int64_t
> pts)
> +{
> +ff_avfilter_link_set_out_status(link, status, pts);
> +}
> +
> +void ff_avfilter_link_set_out_status(AVFilterLink *link, int status, int64_t
> pts)
> +{
> +link->status = status;
> +ff_update_link_current_pts(link, pts);
> +}
> +
> void avfilter_link_set_closed(AVFilterLink *link, int closed)
> {
> -link->closed = closed;
> +ff_avfilter_link_set_out_status(link, closed ? AVERROR_EOF : 0,
> AV_NOPTS_VALUE);
> }
>
> int avfilter_insert_filter(AVFilterLink *link, AVFilterContext *filt,
> @@ -345,8 +356,8 @@ int ff_request_frame(AVFilterLink *link)
> int ret = -1;
> FF_TPRINTF_START(NULL, request_frame); ff_tlog_link(NULL, link, 1);
>
> -if (link->closed)
> -return AVERROR_EOF;
> +if (link->status)
> +return link->status;
> if (link->srcpad->request_frame)
> ret = link->srcpad->request_frame(link);
> else if (link->src->inputs[0])
> @@ -357,8 +368,8 @@ int ff_request_frame(AVFilterLink *link)
> ret = ff_filter_frame_framed(link, pbuf);
> }
> if (ret < 0) {
> -if (ret == AVERROR_EOF)
> -link->closed = 1;
> +if (ret != AVERROR(EAGAIN) && ret != link->status)
> +ff_avfilter_link_set_in_status(link, ret, AV_NOPTS_VALUE);
> }
> return ret;
> }
> @@ -1004,9 +1015,9 @@ static int ff_filter_frame_framed(AVFilterLink *link,
> AVFrame *frame)
> AVFilterCommand *cmd= link->dst->command_queue;
> int64_t pts;
>
> -if (link->closed) {
> +if (link->status) {
> av_frame_free(&frame);
> -return AVERROR_EOF;
> +return link->status;
> }
>
> if (!(filter_frame = dst->filter_frame))
> diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
> index 58a0cbd..f3a0f2d 100644
> --- a/libavfilter/avfilter.h
> +++ b/libavfilter/avfilter.h
> @@ -490,16 +490,16 @@ struct AVFilterLink {
> int max_samples;
>
> /**
> - * True if the link is closed.
> - * If set, all attempts of start_frame, filter_frame or request_frame
> - * will fail with AVERROR_EOF, and if necessary the reference will be
> - * destroyed.
> - * If request_frame returns AVERROR_EOF, this flag is set on the
> + * Link status.
> + * If not zero, all attempts of start_frame, filter_frame or
> request_frame
> + * will fail with the corresponding code, and if necessary the reference
> + * will be destroyed.
> + * If request_frame returns an error, the status is set on the
> * corresponding link.
> * It can be set also be set by either the source or the destination
> * filter.
> */
> -int closed;
> +int status;
>
> /**
> * Number of channels.
> diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
> index 5db86abd..7a19df2 100644
> --- a/libavfilter/buffersink.c
> +++ b/libavfilter/buffersink.c
> @@ -134,8 +134,8 @@ int attribute_align_arg
> av_buffersink_get_frame_flags(AVFilterContext *ctx, AVFr
>
> /* no picref available, fetch it from the filterchain */
> while (!av_fifo_size(buf->fifo)) {
> -if (inlink->closed)
> -return AVERROR_EOF;
> +if (inlink->status)
> +return inlink->status;
> if (flags & AV_BUFFERSINK_FLAG_NO_REQUEST)
> return AVERROR(EAGAIN);
> if ((ret = ff_request_frame(inlink)) < 0)
> diff --git a/libavfilter/f_interleave.c b/libavfilter/f_interleave.c
> index e0915b5..422f2bf 100644
> --- a/libavfilter/f_interleave.c
> +++ b/libavfilter/f_interleave.c
> @@ -59,7 +59,7 @@ inline static int push_frame(AVFilterContext *ctx)
> for (i = 0; i < ctx->nb_inputs; i++) {
> struct FFBufQueue *q = &s->queues[i];
>
> -if (!q->available && !ctx->inputs[i]->closed)
> +if (!q->available && !ctx->inputs[i]->status)
> return 0;
> if (q->availabl
Re: [FFmpeg-devel] [PATCH] avformat/mp3dec: prefer "fast_seek" to TOC seek for CBR files.
(Fixed CCs)
Thanks for review. Patch coming shortly.
On Thu, Nov 26, 2015 at 10:13 AM, wm4 wrote:
> On Tue, 24 Nov 2015 16:55:03 -0800
> chcunning...@chromium.org wrote:
>
> > From: Chris Cunningham
> >
> > "Fast seek" uses linear interpolation to find the position of the
> > requested seek time. For CBR this is more direct than using the
> > mp3 TOC and bypassing the TOC avoids problems with TOC precision.
> > (see https://crbug.com/545914#c13)
> >
> > For VBR, fast seek is not precise, so continue to prefer the TOC
> > when available (the lesser of two evils).
> >
> > Also, some re-ordering of the logic in mp3_seek to simplify and
> > give usetoc=1 precedence over fastseek flag.
> > ---
> > libavformat/mp3dec.c | 45 +++--
> > 1 file changed, 23 insertions(+), 22 deletions(-)
> >
> > diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> > index 32ca00c..a1f21b7 100644
> > --- a/libavformat/mp3dec.c
> > +++ b/libavformat/mp3dec.c
> > @@ -115,7 +115,8 @@ static void read_xing_toc(AVFormatContext *s,
> int64_t filesize, int64_t duration
> > {
> > int i;
> > MP3DecContext *mp3 = s->priv_data;
> > -int fill_index = mp3->usetoc == 1 && duration > 0;
> > +int fast_seek = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 0;
>
> Nit: the ?1:0 is not really needed.
>
Will fix.
>
> > +int fill_index = (mp3->usetoc || fast_seek) && duration > 0;
> >
> > if (!filesize &&
> > !(filesize = avio_size(s->pb))) {
> > @@ -344,9 +345,6 @@ static int mp3_read_header(AVFormatContext *s)
> > int ret;
> > int i;
> >
> > -if (mp3->usetoc < 0)
> > -mp3->usetoc = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 2;
> > -
> > st = avformat_new_stream(s, NULL);
> > if (!st)
> > return AVERROR(ENOMEM);
> > @@ -501,40 +499,43 @@ static int mp3_seek(AVFormatContext *s, int
> stream_index, int64_t timestamp,
> > MP3DecContext *mp3 = s->priv_data;
> > AVIndexEntry *ie, ie1;
> > AVStream *st = s->streams[0];
> > -int64_t ret = av_index_search_timestamp(st, timestamp, flags);
> > -int64_t best_pos;
> > int fast_seek = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 0;
> > int64_t filesize = mp3->header_filesize;
> >
> > -if (mp3->usetoc == 2)
> > -return -1; // generic index code
> > -
> > if (filesize <= 0) {
> > int64_t size = avio_size(s->pb);
> > if (size > 0 && size > s->internal->data_offset)
> > filesize = size - s->internal->data_offset;
> > }
> >
> > -if ( (mp3->is_cbr || fast_seek)
> > -&& (mp3->usetoc == 0 || !mp3->xing_toc)
> > -&& st->duration > 0
> > -&& filesize > 0) {
> > -ie = &ie1;
> > -timestamp = av_clip64(timestamp, 0, st->duration);
> > -ie->timestamp = timestamp;
> > -ie->pos = av_rescale(timestamp, filesize, st->duration) +
> s->internal->data_offset;
> > -} else if (mp3->xing_toc) {
> > +if (mp3->xing_toc && (mp3->usetoc || (fast_seek && !mp3->is_cbr))) {
> > +av_log(s, AV_LOG_ERROR, "XING seeking. filesize = %"PRId64"\n",
> filesize);
> > +// NOTE: The MP3 TOC is not a precise lookup table. The
> precision is
> > +// worse closer to the end of the file, especially for large
> files.
> > +// Seeking to 90% of duration in file of size 4M will be off by
> roughly 1 second.
> > +if (filesize > 400)
> > +av_log(s, AV_LOG_WARNING, "Using MP3 TOC to seek; may be
> imprecise.\n");
>
> This seems like a rather questionable heuristic. And only to print a
> message? Maybe it would be better to drop it, or always print it
> regardless of file size.
>
> I'll make this always print. Hopefully this helps people avoid TOC.
> > +
> > +int64_t ret = av_index_search_timestamp(st, timestamp, flags);
> > if (ret < 0)
> > return ret;
> >
> > ie = &st->index_entries[ret];
> > +} else if (fast_seek && st->duration > 0 && filesize > 0) {
> > +if (!mp3->is_cbr)
> > +av_log(s, AV_LOG_WARNING, "Using scaling to seek VBR MP3;
> may be imprecise.\n");
> > +
> > +ie = &ie1;
> > +timestamp = av_clip64(timestamp, 0, st->duration);
> > +ie->timestamp = timestamp;
> > +ie->pos = av_rescale(timestamp, filesize, st->duration) +
> s->internal->data_offset;
> > } else {
> > -return -1;
> > +return -1; // generic index code
> > }
> >
> > -best_pos = mp3_sync(s, ie->pos, flags);
> > +int64_t best_pos = mp3_sync(s, ie->pos, flags);
> > if (best_pos < 0)
> > -return best_pos;
> > + return best_pos;
> >
> > if (mp3->is_cbr && ie == &ie1 && mp3->frames) {
> > int frame_duration = av_rescale(st->duration, 1, mp3->frames);
> > @@ -546,7 +547,7 @@ static int mp3_seek(AVFormatContext *s, int
> stream_index, int64_t timestamp,
> > }
> >
> > static const AVOption options[] = {
>
Re: [FFmpeg-devel] [PATCH 3/5] lavfi: deprecate avfilter_link_set_closed().
On Sun, Nov 29, 2015 at 05:21:50PM +0100, Nicolas George wrote: > Applications are not supposed to mess with links, > they should close the sinks. > Furthermore, this function does not distinguish what end > of the link caused the close and does not have a timestamp. > > Signed-off-by: Nicolas George > --- > libavfilter/avfilter.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h > index a6aa919..58a0cbd 100644 > --- a/libavfilter/avfilter.h > +++ b/libavfilter/avfilter.h > @@ -541,7 +541,10 @@ int avfilter_link_get_channels(AVFilterLink *link); > > /** > * Set the closed field of a link. > + * @deprecated applications are not supposed to mess with links, they should > + * close the sinks. ok thx [...] -- 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 2/5] lavfi: add link.current_pts field.
On Sun, Nov 29, 2015 at 05:21:49PM +0100, Nicolas George wrote: > Signed-off-by: Nicolas George > --- > libavfilter/avfilter.c | 2 ++ > libavfilter/avfilter.h | 6 ++ > 2 files changed, 8 insertions(+) id say, the addition makes sense, exact timebases are better when they are possible thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/vf_mpdecimate: remove request_frame().
On Sun, Nov 29, 2015 at 01:36:48PM +0100, Nicolas George wrote: > It is no longer needed since looping is not necessary. > > Signed-off-by: Nicolas George > --- > libavfilter/vf_mpdecimate.c | 14 -- > 1 file changed, 14 deletions(-) > > > Passes the FATE test (the one that is broken for windows). > > This is the last filter that needed updatint. technically this LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle 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/5] lavfi: rename link.current_pts to current_pts_us.
On Sun, Nov 29, 2015 at 05:21:48PM +0100, Nicolas George wrote: > This field is used for fast comparison between link ages, > it is in AV_TIME_BASE units, in other words microseconds, > µs =~ us. > Renaming it allows a second field in link time base units. > > Signed-off-by: Nicolas George > --- > libavfilter/avfilter.c | 4 ++-- > libavfilter/avfilter.h | 2 +- > libavfilter/avfiltergraph.c | 6 +++--- > 3 files changed, 6 insertions(+), 6 deletions(-) > > > FATE passes after each patch in this series. > > > Note: this patch and the next could have been merged, but having two > separate patches allows to test the intermediate state and check that no use > of current_pts was forgotten. LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/rtpenc_jpeg: Fix huffman table test
On Mon, Nov 30, 2015 at 01:18:21AM +0100, Carl Eugen Hoyos wrote: > On Saturday 28 November 2015 02:32:37 am Carl Eugen Hoyos wrote: > > Hi! > > > > Jpeg over rtp requires standard huffman tables, but the test I implemented > > was too strict. Attached patch tries to improve this, related to ticket > > #3823. > > New patch attached. > > Please review, Carl Eugen should be ok if it works [...] -- 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 2/2] ffserver: Clear avio context after closing it
On Mon, Nov 30, 2015 at 12:46:25PM -0800, Reynaldo H. Verdejo Pinochet wrote: > > > On 11/01/2015 09:34 AM, Michael Niedermayer wrote: > > [...] > > --- a/ffserver.c > > +++ b/ffserver.c > > @@ -2366,6 +2366,7 @@ static int http_prepare_data(HTTPContext *c) > > > > av_freep(&c->pb_buffer); > > len = avio_close_dyn_buf(ctx->pb, &c->pb_buffer); > > +ctx->pb = NULL; > > Looks good. I think there's a similar issue at the end > of rtp_new_av_stream() you might want to handle too but will clear that too > please feel free to push as-is. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] tests/api: Fix API test build on windows with --enable-shared
--- I'm not quite sure if this fix is 100% correct, but it works here. The problem is that FF_DEP_LIBS points to the .dll files, but you can't link to the .dll files, you need to point to the import libraries. Unfortunately there is no variable which simply holds all import libraries - but they do appear to be part of FF_EXTRALIBS, so thats used instead. tests/api/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/api/Makefile b/tests/api/Makefile index c48c34a..a6d8e42 100644 --- a/tests/api/Makefile +++ b/tests/api/Makefile @@ -14,7 +14,7 @@ $(APITESTOBJS) $(APITESTOBJS:.o=.i): CPPFLAGS += -DTEST $(APITESTOBJS) $(APITESTOBJS:.o=.i): CFLAGS += -Umain $(APITESTPROGS): %$(EXESUF): %.o $(EXEOBJS) $(FF_DEP_LIBS) - $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) $(FF_DEP_LIBS) $(FFEXTRALIBS) $(ELIBS) + $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) $(FF_EXTRALIBS) $(ELIBS) testclean:: $(RM) $(addprefix $(APITESTSDIR)/,$(CLEANSUFFIXES) *-test$(EXESUF)) -- 2.6.2.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] lavf/mpegts: use AVERROR_INVALIDDATA instead of AVERROR(EINTR).
On Fri, Nov 27, 2015 at 07:16:10PM +0100, Nicolas George wrote: > Signed-off-by: Nicolas George > --- > libavformat/mpegts.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > > Untested. Offending commit was: ok (based on what the commit message said) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC encoder: improve SF range utilization
On Mon, Nov 30, 2015 at 2:20 PM, Rostislav Pehlivanov wrote: > On Mon, 2015-11-30 at 12:50 -0300, Claudio Freire wrote: >> Also I don't see how a static var would help or even be correct here. >> Perhaps you meant something else? > static uint8_t cond1 = param1 && param2; > static uint8_t cond2 = param3 && !param4; > ...etc > return cond1 && cond2; I don't think the static there does what you think it does. Just an: int cond1 = ...; Would be enough. Not even uint8_t is a win (the conversion to uint8_t tends to be slower than leaving it at the native int register size). Same with naming variables, that can tie the compiler's hands regarding optimizations. So, as before, I'll see what can be done. If it doesn't break any optimizations and really makes things more readable I'll do that. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GreenMetadata complexity metric access through high level API
On Mon, Nov 30, 2015 at 8:21 AM, Nicolas Derouineau wrote: > Hello > >>you should look at avframesidedata > > Actually the issue is that the green metadatadata are concerning the upcoming > frame (They are used to predict the upcoming complexity). > > The avframesidedata are concerning a frame which is already decoded (so it's > not useful in the case of greenmetadata). > > We made a proof of concept using a home made parsing function (replacing > av_read_frame() by a custom one), but we are thinking about a more portable > solution. I am definitely not familiar with what the green metadata is or does, but from the sound of it I still think it is suited for AVFrameSideData: it's data which is not essential for decoding, it's frame bound, and applications outside lavc might need to act differently depending on its contents. Even if this green metadata is used within libavcodec and concerns the upcoming frame, there is still a way to make it work: I believe that frame side data in ffmpeg are ref counted (meaning you can just add a reference to the side data rather than allocating/copying data), put it in a queue of green metadata and apply it when the upcoming frame is decoded or it's about to be decoded. You would have to be careful only in frame reordering, but the rest should be pretty simple. Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] ffserver: Clear avio context after closing it
On 11/01/2015 09:34 AM, Michael Niedermayer wrote: > [...] > --- a/ffserver.c > +++ b/ffserver.c > @@ -2366,6 +2366,7 @@ static int http_prepare_data(HTTPContext *c) > > av_freep(&c->pb_buffer); > len = avio_close_dyn_buf(ctx->pb, &c->pb_buffer); > +ctx->pb = NULL; Looks good. I think there's a similar issue at the end of rtp_new_av_stream() you might want to handle too but please feel free to push as-is. Bests, -- Reynaldo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] lavf/mpeg: use FFERROR_REDO instead of AVERROR(EAGAIN).
On Fri, Nov 27, 2015 at 07:16:08PM +0100, Nicolas George wrote:
> Signed-off-by: Nicolas George
> ---
> libavformat/mpeg.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> Problem can be observed with files containing large portions of junk, for
> example:
>
> { ffmpeg -lavfi testsrc=d=60 -f vob -;
> head -c $[256*1024*1024] /dev/zero;
> ffmpeg -lavfi testsrc=d=60 -f vob - } > big.mpg
> ffmpeg -i big.mpg -f null -
>
> Observe the time getting stuck after 60 seconds.
probably ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] ffserver_config: replace strtod by av_strtod and correct undefined behavior
This one looks OK (pending a final decision on av_clipd64()) Bests, -- Reynaldo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double
On Mon, Nov 30, 2015 at 07:02:47PM +0100, Nicolas George wrote: > Le decadi 10 frimaire, an CCXXIV, Michael Niedermayer a écrit : > > > ISO/IEC 9899:TC3 > > > 5.2.4.2.2 Characteristics of floating types > > > > > > 8 Except for assignment and cast (which remove all extra range and > > > precision), the values > > > of operations with floating operands and values subject to the usual > > > arithmetic > > > conversions and of floating constants are evaluated to a format whose > > > range and precision > > > may be greater than required by the type. The use of evaluation > > > formats is characterized > > > by the implementation-defined value of FLT_EVAL_METHOD:19) > > > -1 indeterminable; > > > 0 evaluate all operations and constants just to the range > > > and precision of the > > > type; > > > 1 evaluate operations and constants of type float and > > > double to the > > > range and precision of the double type, evaluate long > > > double > > > operations and constants to the range and precision of > > > the long double > > > type; > > > 2 evaluate all operations and constants to the range and > > > precision of the > > > long double type. > > > All other negative values for FLT_EVAL_METHOD characterize > > > implementation-defined > > > behavior. > > > > a few more related parts: > > 5 The accuracy of the floating-point operations (+, -, *, /) and of the > > library functions in > > and that return floating-point results is > > implementation- > > defined, as is the accuracy of the conversion between floating-point > > internal > > representations and string representations performed by the library > > functions in > > , , and . The implementation may state that > > the > > accuracy is unknown. > > > > 6.4.4.2 Floating constants > > 7 The translation-time conversion of floating constants should match > > the execution-time > > conversion of character strings by library functions, such as strtod, > > given matching > > inputs suitable for both conversions, the same result format, and > > default execution-time > > rounding.64) > > I am not sure why you quoting this. Are you implying this is not a compiler > bug, the compiler is actually allowed to do that? Possible. But still, I do yes, i suspect that is not a compiler bug but i certainly do not have deep enough knowledge of C to say that for sure > not think we should apply this unless we actually understand what is going > on here, why a cast that should not change anything does change the result. > Otherwise, it could just be a coincidence, and break in a different way on a > different compiler. I would not be surprised if a strict and litteral reading of C would allow that still to fail, but then theres the question if such equals check is even possible in C in such a strict reading of the standard. and theres also IEEE ... One could use a special value as default like -1 and check for that which may be less likely to cause problems with float accuracy and rounding in case the cast does not work on some real world case or if the risk of it failing on some obscure plaform should be avoided [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix sample_aspect_ratio computation for stereo matroska content.
On Mon, Nov 30, 2015 at 10:57 AM wm4 wrote: > On Mon, 30 Nov 2015 18:31:56 + > Aaron Colwell wrote: > > > Hi, > > Can I get a review for this please? It has been a week since I sent out > > this patch and I haven't gotten any real feedback about the changes. I've > > attached a new copy that has been rebased to HEAD. If I need to be doing > > something different, please let me know so I can make progress on this. > > > > Thanks, > > Aaron > > > > On Wed, Nov 25, 2015 at 4:40 PM Aaron Colwell > wrote: > > > > > On Tue, Nov 24, 2015 at 10:43 AM Kirill Gavrilov > > > wrote: > > > > > >> On Mon, Nov 23, 2015 at 11:37 PM, Aaron Colwell > > >> wrote: > > >> > > >> > matroskaenc.c applies divisors to the display width/height when > > >> generating > > >> > stereo content. This patch adds the corresponding multipliers to > > >> > matroskadec.c > > >> > so that the original sample aspect ratio can be recovered. > > >> > > >> > > >> Just to link this patch with Matroska Specification notes: > > >> http://www.matroska.org/technical/specs/notes.html#3D > > >> > > >> > The pixel count of the track (PixelWidth/PixelHeight) should be the > raw > > >> > amount of pixels (for example 3840x1080 for full HD side by side) > > >> > and the DisplayWidth/Height in pixels should be the amount of > pixels for > > >> > one plane (1920x1080 for that full HD stream). > > >> > > > >> > > > > > > Is this intended to be a call to action or are you just adding > information > > > to this particular thread? I'd like to get the change reviewed so I can > > > determine whether I need to make any other changes. > > > > > > This change basically allows 'ffmpeg -i blah.mkv foo.mkv ; ffprobe > > > foo.mkv' to show that foo.mkv has the same SAR and DAR as blah.mkv when > > > blah.mkv contains stereo content. Without this patch the SAR & DAR get > > > smaller based on whichever dimension is halved by the stereo layout. > > > > > > Hope this helps, > > > Aaron > > > > > > > > Are you sure matroskadec is wrong and not matroskaenc? > Thanks for the response. Yes. I believe matroskadec is wrong. From what I can tell matroskaenc is writing the correct information to the file. The issue is that matroskadec does not appear to be doing the right thing to restore the same state that was present when the file was written. Specifically sample_aspect_ratio does not get restored to the value it had during writing. Here is an example using a SIDE_BY_SIDE_RL file that has PixelWidthxPixelHeight of "640x360" and a DisplayWidthxDisplayHeight of "640x360" ./ffmpeg -y -i fp3_RL_640x360.webm blah.webm && ./ffprobe blah.webm [ffmpeg output] Input #0, matroska,webm, from 'fp3_RL_640x360.webm': Metadata: encoder : google Duration: 00:00:04.88, start: 0.00, bitrate: 208 kb/s Stream #0:0: Video: vp8, yuv420p, 640x360, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 1k tbn, 1k tbc (default) Metadata: stereo_mode : right_left Side data: stereo3d: side by side (inverted) [libvpx-vp9 @ 0x33dcfa0] v1.4.0-729-g8bf791e Output #0, webm, to 'blah.webm': Metadata: encoder : Lavf57.19.100 Stream #0:0: Video: vp9 (libvpx-vp9), yuv420p, 640x360 [SAR 1:1 DAR 16:9], q=-1--1, 200 kb/s, 23.98 fps, 1k tbn, 23.98 tbc (default) Metadata: stereo_mode : right_left encoder : Lavc57.16.101 libvpx-vp9 Side data: stereo3d: side by side (inverted) Stream mapping: Stream #0:0 -> #0:0 (vp8 (native) -> vp9 (libvpx-vp9)) [end of ffmpeg output] --[ffprobe output]-- Input #0, matroska,webm, from 'blah.webm': Metadata: encoder : Lavf57.19.100 Duration: 00:00:04.88, start: 0.00, bitrate: 100 kb/s Stream #0:0: Video: vp9 (Profile 0), yuv420p(tv), 640x360, SAR 1:2 DAR 8:9, 23.98 fps, 23.98 tbr, 1k tbn, 1k tbc (default) Metadata: stereo_mode : right_left Side data: stereo3d: side by side (inverted) --[end of ffprobe output]-- Note that ffprobe SAR and DAR do not match what ffmpeg thought it wrote. This is what I'm fixing. With my fix, ffprobe reports what ffmpeg said it wrote. Here is what the output looks like with my change: ---[ffmpeg output]--- Input #0, matroska,webm, from 'fp3_RL_640x360.webm': Metadata: encoder : google Duration: 00:00:04.88, start: 0.00, bitrate: 208 kb/s Stream #0:0: Video: vp8, yuv420p, 640x360, SAR 2:1 DAR 32:9, 23.98 fps, 23.98 tbr, 1k tbn, 1k tbc (default) Metadata: stereo_mode : right_left Side data: stereo3d: side by side (inverted) [libvpx-vp9 @ 0x1fb0fa0] v1.4.0-729-g8bf791e Output #0, webm, to 'blah.webm': Metadata: encoder : Lavf57.19.100 Stream #0:0: Video: vp9 (libvpx-vp9), yuv420p, 640x360 [SAR 2:1 DAR 32:9], q=-1--1, 200 kb/s, 23.98 fps, 1k tbn, 23.98 tbc (default) Metadata: stereo_mode : right_left encoder : Lavc57.16.101 libvpx-vp9 Side data: stereo3d: side by side (inverted) Stream ma
Re: [FFmpeg-devel] [PATCH] Fix sample_aspect_ratio computation for stereo matroska content.
On Mon, 30 Nov 2015 18:31:56 + Aaron Colwell wrote: > Hi, > Can I get a review for this please? It has been a week since I sent out > this patch and I haven't gotten any real feedback about the changes. I've > attached a new copy that has been rebased to HEAD. If I need to be doing > something different, please let me know so I can make progress on this. > > Thanks, > Aaron > > On Wed, Nov 25, 2015 at 4:40 PM Aaron Colwell wrote: > > > On Tue, Nov 24, 2015 at 10:43 AM Kirill Gavrilov > > wrote: > > > >> On Mon, Nov 23, 2015 at 11:37 PM, Aaron Colwell > >> wrote: > >> > >> > matroskaenc.c applies divisors to the display width/height when > >> generating > >> > stereo content. This patch adds the corresponding multipliers to > >> > matroskadec.c > >> > so that the original sample aspect ratio can be recovered. > >> > >> > >> Just to link this patch with Matroska Specification notes: > >> http://www.matroska.org/technical/specs/notes.html#3D > >> > >> > The pixel count of the track (PixelWidth/PixelHeight) should be the raw > >> > amount of pixels (for example 3840x1080 for full HD side by side) > >> > and the DisplayWidth/Height in pixels should be the amount of pixels for > >> > one plane (1920x1080 for that full HD stream). > >> > > >> > > > > Is this intended to be a call to action or are you just adding information > > to this particular thread? I'd like to get the change reviewed so I can > > determine whether I need to make any other changes. > > > > This change basically allows 'ffmpeg -i blah.mkv foo.mkv ; ffprobe > > foo.mkv' to show that foo.mkv has the same SAR and DAR as blah.mkv when > > blah.mkv contains stereo content. Without this patch the SAR & DAR get > > smaller based on whichever dimension is halved by the stereo layout. > > > > Hope this helps, > > Aaron > > > > Are you sure matroskadec is wrong and not matroskaenc? I suspect the change to matroskadec would make the behavior inconsistent with vf_stereo3d in libavfilter. (But I'm not sure.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double
Le decadi 10 frimaire, an CCXXIV, Michael Niedermayer a écrit : > > ISO/IEC 9899:TC3 > > 5.2.4.2.2 Characteristics of floating types > > > > 8 Except for assignment and cast (which remove all extra range and > > precision), the values > > of operations with floating operands and values subject to the usual > > arithmetic > > conversions and of floating constants are evaluated to a format whose > > range and precision > > may be greater than required by the type. The use of evaluation formats > > is characterized > > by the implementation-defined value of FLT_EVAL_METHOD:19) > > -1 indeterminable; > > 0 evaluate all operations and constants just to the range and > > precision of the > > type; > > 1 evaluate operations and constants of type float and double > > to the > > range and precision of the double type, evaluate long double > > operations and constants to the range and precision of the > > long double > > type; > > 2 evaluate all operations and constants to the range and > > precision of the > > long double type. > > All other negative values for FLT_EVAL_METHOD characterize > > implementation-defined > > behavior. > > a few more related parts: > 5 The accuracy of the floating-point operations (+, -, *, /) and of the > library functions in > and that return floating-point results is > implementation- > defined, as is the accuracy of the conversion between floating-point > internal > representations and string representations performed by the library > functions in > , , and . The implementation may state that > the > accuracy is unknown. > > 6.4.4.2 Floating constants > 7 The translation-time conversion of floating constants should match the > execution-time > conversion of character strings by library functions, such as strtod, > given matching > inputs suitable for both conversions, the same result format, and default > execution-time > rounding.64) I am not sure why you quoting this. Are you implying this is not a compiler bug, the compiler is actually allowed to do that? Possible. But still, I do not think we should apply this unless we actually understand what is going on here, why a cast that should not change anything does change the result. Otherwise, it could just be a coincidence, and break in a different way on a different compiler. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double
Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit : > gcc -c -std=c89 -O2 gcc -S would have been more useful: as is, it lacks the definition for basefreq, and apparently also the other constant. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double
On Mon, Nov 30, 2015 at 06:25:15PM +0100, Michael Niedermayer wrote:
> On Mon, Nov 30, 2015 at 04:52:20PM +0100, Nicolas George wrote:
> > Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
> > > -if (s->basefreq != BASEFREQ || s->endfreq != ENDFREQ) {
> > > +if (s->basefreq != (double) BASEFREQ || s->endfreq != (double)
> > > ENDFREQ) {
> >
> > Looks wrong to me. Since s->basefreq is double and operands are always
> > converted to the largest type before comparison, the cast would be implicit.
> > And BASEFREQ and ENDFREQ are double anyway.
> >
> > The problem, if any, is somewhere else.
>
> ISO/IEC 9899:TC3
> 5.2.4.2.2 Characteristics of floating types
>
> 8 Except for assignment and cast (which remove all extra range and
> precision), the values
> of operations with floating operands and values subject to the usual
> arithmetic
> conversions and of floating constants are evaluated to a format whose
> range and precision
> may be greater than required by the type. The use of evaluation formats
> is characterized
> by the implementation-defined value of FLT_EVAL_METHOD:19)
> -1 indeterminable;
> 0 evaluate all operations and constants just to the range and
> precision of the
> type;
> 1 evaluate operations and constants of type float and double to
> the
> range and precision of the double type, evaluate long double
> operations and constants to the range and precision of the
> long double
> type;
> 2 evaluate all operations and constants to the range and
> precision of the
> long double type.
> All other negative values for FLT_EVAL_METHOD characterize
> implementation-defined
> behavior.
a few more related parts:
5 The accuracy of the floating-point operations (+, -, *, /) and of the
library functions in
and that return floating-point results is
implementation-
defined, as is the accuracy of the conversion between floating-point
internal
representations and string representations performed by the library
functions in
, , and . The implementation may state that the
accuracy is unknown.
6.4.4.2 Floating constants
7 The translation-time conversion of floating constants should match the
execution-time
conversion of character strings by library functions, such as strtod, given
matching
inputs suitable for both conversions, the same result format, and default
execution-time
rounding.64)
>
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Republics decline into democracies and democracies degenerate into
> despotisms. -- Aristotle
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] fate/api: test threadmessage
From: Clément Bœsch
---
tests/api/Makefile | 1 +
tests/api/api-threadmessage-test.c | 202 +
tests/fate/api.mak | 6 ++
3 files changed, 209 insertions(+)
create mode 100644 tests/api/api-threadmessage-test.c
diff --git a/tests/api/Makefile b/tests/api/Makefile
index c48c34a..3556a9b 100644
--- a/tests/api/Makefile
+++ b/tests/api/Makefile
@@ -3,6 +3,7 @@ APITESTPROGS-$(call DEMDEC, H264, H264) += api-h264
APITESTPROGS-yes += api-seek
APITESTPROGS-yes += api-codec-param
APITESTPROGS-$(call DEMDEC, H263, H263) += api-band
+APITESTPROGS-yes += api-threadmessage
APITESTPROGS += $(APITESTPROGS-yes)
APITESTOBJS := $(APITESTOBJS:%=$(APITESTSDIR)%)
$(APITESTPROGS:%=$(APITESTSDIR)/%-test.o)
diff --git a/tests/api/api-threadmessage-test.c
b/tests/api/api-threadmessage-test.c
new file mode 100644
index 000..abf0154
--- /dev/null
+++ b/tests/api/api-threadmessage-test.c
@@ -0,0 +1,202 @@
+/*
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/**
+ * Thread message API test
+ */
+
+#include
+
+#include "libavutil/frame.h"
+#include "libavutil/avstring.h"
+#include "libavutil/threadmessage.h"
+
+struct tdata {
+int id;
+pthread_t tid;
+int workload;
+AVThreadMessageQueue *queue;
+};
+
+static void free_frame(void *arg)
+{
+AVFrame *frame = arg;
+av_frame_free(&frame);
+}
+
+/* Frame producing thread. Will flush the queue half way just to be a jerk */
+static void *worker_thread(void *arg)
+{
+int i, ret;
+struct tdata *td = arg;
+
+av_log(NULL, AV_LOG_INFO, "worker #%d: workload=%d\n", td->id,
td->workload);
+for (i = 0; i < td->workload; i++) {
+if (i == td->workload/2) {
+av_log(NULL, AV_LOG_INFO, "worker #%d: flushing the queue\n",
td->id);
+av_thread_message_flush(td->queue);
+} else {
+char *val;
+AVDictionary *meta = NULL;
+AVFrame *frame = av_frame_alloc();
+if (!frame) {
+ret = AVERROR(ENOMEM);
+break;
+}
+
+/* we add some metadata to identify the frames */
+val = av_asprintf("frame from worker %d", td->id);
+if (!val) {
+av_frame_free(&frame);
+ret = AVERROR(ENOMEM);
+break;
+}
+ret = av_dict_set(&meta, "sig", val, AV_DICT_DONT_STRDUP_VAL);
+if (ret < 0) {
+av_frame_free(&frame);
+break;
+}
+av_frame_set_metadata(frame, meta);
+
+/* allocate a real frame in order to simulate "real" work */
+frame->format = AV_PIX_FMT_RGBA;
+frame->width = 320;
+frame->height = 240;
+ret = av_frame_get_buffer(frame, 32);
+if (ret < 0) {
+av_frame_free(&frame);
+break;
+}
+
+/* push the frame in the common queue */
+av_log(NULL, AV_LOG_INFO, "worker #%d: sending my work (%p), %d
left\n",
+ td->id, frame, td->workload - i - 1);
+ret = av_thread_message_queue_send(td->queue, &frame, 0);
+if (ret < 0) {
+av_frame_free(&frame);
+break;
+}
+}
+}
+av_log(NULL, AV_LOG_INFO, "worker #%d: my work is done here (%s)\n",
+ td->id, av_err2str(ret));
+av_thread_message_queue_set_err_recv(td->queue, ret < 0 ? ret :
AVERROR_EOF);
+return NULL;
+}
+
+static int consume_queue(AVThreadMessageQueue *q, int n)
+{
+int i, ret = 0;
+
+for (i = 0; i < n; i++) {
+AVFrame *frame;
+AVDictionary *meta;
+AVDictionaryEntry *e;
+
+ret = av_thread_message_queue_recv(q, &frame, 0);
+if (ret < 0)
+break;
+meta = av_frame_get_metadata(frame);
+e = av_dict_get(meta, "si
[FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()
From: Clément Bœsch
---
libavutil/threadmessage.c | 37 ++---
libavutil/threadmessage.h | 21 ++---
2 files changed, 52 insertions(+), 6 deletions(-)
diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c
index b7fcbe2..87ce8dc 100644
--- a/libavutil/threadmessage.c
+++ b/libavutil/threadmessage.c
@@ -40,14 +40,16 @@ struct AVThreadMessageQueue {
int err_send;
int err_recv;
unsigned elsize;
+void (*free_func)(void *msg);
#else
int dummy;
#endif
};
-int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
- unsigned nelem,
- unsigned elsize)
+int av_thread_message_queue_alloc2(AVThreadMessageQueue **mq,
+ unsigned nelem,
+ unsigned elsize,
+ void (*free_func)(void *msg))
{
#if HAVE_THREADS
AVThreadMessageQueue *rmq;
@@ -73,6 +75,7 @@ int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
return AVERROR(ret);
}
rmq->elsize = elsize;
+rmq->free_func = free_func;
*mq = rmq;
return 0;
#else
@@ -81,10 +84,18 @@ int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
#endif /* HAVE_THREADS */
}
+int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
+ unsigned nelem,
+ unsigned elsize)
+{
+return av_thread_message_queue_alloc2(mq, nelem, elsize, NULL);
+}
+
void av_thread_message_queue_free(AVThreadMessageQueue **mq)
{
#if HAVE_THREADS
if (*mq) {
+av_thread_message_flush(*mq);
av_fifo_freep(&(*mq)->fifo);
pthread_cond_destroy(&(*mq)->cond);
pthread_mutex_destroy(&(*mq)->lock);
@@ -182,3 +193,23 @@ void
av_thread_message_queue_set_err_recv(AVThreadMessageQueue *mq,
pthread_mutex_unlock(&mq->lock);
#endif /* HAVE_THREADS */
}
+
+void av_thread_message_flush(AVThreadMessageQueue *mq)
+{
+#if HAVE_THREADS
+int used, off;
+
+pthread_mutex_lock(&mq->lock);
+used = av_fifo_size(mq->fifo);
+if (mq->free_func) {
+for (off = 0; off < used; off += mq->elsize) {
+void *msg;
+av_fifo_generic_peek_at(mq->fifo, &msg, off, mq->elsize, NULL);
+mq->free_func(msg);
+}
+}
+av_fifo_drain(mq->fifo, used);
+pthread_cond_broadcast(&mq->cond);
+pthread_mutex_unlock(&mq->lock);
+#endif /* HAVE_THREADS */
+}
diff --git a/libavutil/threadmessage.h b/libavutil/threadmessage.h
index a8481d8..f9004a8 100644
--- a/libavutil/threadmessage.h
+++ b/libavutil/threadmessage.h
@@ -33,17 +33,27 @@ typedef enum AVThreadMessageFlags {
} AVThreadMessageFlags;
/**
+ * @deprecated use av_thread_message_queue_alloc2 instead
+ */
+attribute_deprecated
+int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
+ unsigned nelem,
+ unsigned elsize);
+
+/**
* Allocate a new message queue.
*
* @param mq pointer to the message queue
* @param nelem maximum number of elements in the queue
* @param elsize size of each element in the queue
+ * @param free_func free message callback function, can be NULL
* @return >=0 for success; <0 for error, in particular AVERROR(ENOSYS) if
* lavu was built without thread support
*/
-int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
- unsigned nelem,
- unsigned elsize);
+int av_thread_message_queue_alloc2(AVThreadMessageQueue **mq,
+ unsigned nelem,
+ unsigned elsize,
+ void (*free_func)(void *msg));
/**
* Free a message queue.
@@ -88,4 +98,9 @@ void
av_thread_message_queue_set_err_send(AVThreadMessageQueue *mq,
void av_thread_message_queue_set_err_recv(AVThreadMessageQueue *mq,
int err);
+/**
+ * Flush the message queue
+ */
+void av_thread_message_flush(AVThreadMessageQueue *mq);
+
#endif /* AVUTIL_THREADMESSAGE_H */
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] threadmessage improvements
So I've been playing with threadmessage a bit. Since I'm trying to extend the API for (currently) external usage, I'm also adding an API test. I've been triggering deadlocks thoughm, typically by setting queue_size=1. I haven't investigated but I think the issue lies in the fact that there is a single condition to deal with both growing and shrinking the queue. Or maybe that's because I broke the API or misuse it... (Yes this is a WIP, it's missing APIChanges updates and version bump at least) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double
On Mon, Nov 30, 2015 at 04:52:20PM +0100, Nicolas George wrote:
> Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
> > -if (s->basefreq != BASEFREQ || s->endfreq != ENDFREQ) {
> > +if (s->basefreq != (double) BASEFREQ || s->endfreq != (double)
> > ENDFREQ) {
>
> Looks wrong to me. Since s->basefreq is double and operands are always
> converted to the largest type before comparison, the cast would be implicit.
> And BASEFREQ and ENDFREQ are double anyway.
>
> The problem, if any, is somewhere else.
ISO/IEC 9899:TC3
5.2.4.2.2 Characteristics of floating types
8 Except for assignment and cast (which remove all extra range and
precision), the values
of operations with floating operands and values subject to the usual
arithmetic
conversions and of floating constants are evaluated to a format whose range
and precision
may be greater than required by the type. The use of evaluation formats is
characterized
by the implementation-defined value of FLT_EVAL_METHOD:19)
-1 indeterminable;
0 evaluate all operations and constants just to the range and
precision of the
type;
1 evaluate operations and constants of type float and double to
the
range and precision of the double type, evaluate long double
operations and constants to the range and precision of the long
double
type;
2 evaluate all operations and constants to the range and
precision of the
long double type.
All other negative values for FLT_EVAL_METHOD characterize
implementation-defined
behavior.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC encoder: improve SF range utilization
On Mon, 2015-11-30 at 12:50 -0300, Claudio Freire wrote: > Also I don't see how a static var would help or even be correct here. > Perhaps you meant something else? static uint8_t cond1 = param1 && param2; static uint8_t cond2 = param3 && !param4; ...etc return cond1 && cond2; ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double
On Mon, Nov 30, 2015 at 11:09 PM, Nicolas George wrote:
> Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
>> double basefreq = BASEFREQ, endfreq = ENDFREQ;
>> if (basefreq == BASEFREQ && endfreq == ENDFREQ)
>> printf("equal\n");
>> else
>> printf("inequal\n");
>>
>> I try with gcc -std=c89 / -std=c99 on mingw 32-bit
>> the result is inequal.
>
> That looks like a compiler bug. Could you post the generated assembly code,
> with and without the cast? (and with just one comparison, no need to make
> things complicated)
#include
#define BASEFREQ20.01523126408007475
double basefreq = BASEFREQ;
int
main(int argc, char** argv)
{
if (basefreq == BASEFREQ)
printf("equal\n");
else printf("inequal\n");
return 0;
}
gcc -c -std=c89 -O2
without cast:
<_main>:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 83 e4 f0 and$0xfff0,%esp
6: 83 ec 10 sub$0x10,%esp
9: e8 00 00 00 00 call e <_main+0xe>
e: dd 05 00 00 00 00 fldl 0x0
14: db 2d 10 00 00 00 fldt 0x10
1a: d9 c9 fxch %st(1)
1c: df e9 fucomip %st(1),%st
1e: dd d8 fstp %st(0)
20: 7a 02 jp 24 <_main+0x24>
22: 74 10 je 34 <_main+0x34>
24: c7 04 24 06 00 00 00 movl $0x6,(%esp)
2b: e8 00 00 00 00 call 30 <_main+0x30>
30: 31 c0 xor%eax,%eax
32: c9 leave
33: c3 ret
34: c7 04 24 00 00 00 00 movl $0x0,(%esp)
3b: e8 00 00 00 00 call 40 <_main+0x40>
40: eb ee jmp30 <_main+0x30>
with cast:
<_main>:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 83 e4 f0 and$0xfff0,%esp
6: 83 ec 10 sub$0x10,%esp
9: e8 00 00 00 00 call e <_main+0xe>
e: dd 05 00 00 00 00 fldl 0x0
14: dd 05 10 00 00 00 fldl 0x10
1a: d9 c9 fxch %st(1)
1c: df e9 fucomip %st(1),%st
1e: dd d8 fstp %st(0)
20: 7a 02 jp 24 <_main+0x24>
22: 74 10 je 34 <_main+0x34>
24: c7 04 24 06 00 00 00 movl $0x6,(%esp)
2b: e8 00 00 00 00 call 30 <_main+0x30>
30: 31 c0 xor%eax,%eax
32: c9 leave
33: c3 ret
34: c7 04 24 00 00 00 00 movl $0x0,(%esp)
3b: e8 00 00 00 00 call 40 <_main+0x40>
40: eb ee jmp30 <_main+0x30>
without cast with -std=gnu89:
<_main>:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 83 e4 f0 and$0xfff0,%esp
6: 83 ec 10 sub$0x10,%esp
9: e8 00 00 00 00 call e <_main+0xe>
e: dd 05 00 00 00 00 fldl 0x0
14: dd 05 10 00 00 00 fldl 0x10
1a: d9 c9 fxch %st(1)
1c: df e9 fucomip %st(1),%st
1e: dd d8 fstp %st(0)
20: 7a 02 jp 24 <_main+0x24>
22: 74 10 je 34 <_main+0x34>
24: c7 04 24 06 00 00 00 movl $0x6,(%esp)
2b: e8 00 00 00 00 call 30 <_main+0x30>
30: 31 c0 xor%eax,%eax
32: c9 leave
33: c3 ret
34: c7 04 24 00 00 00 00 movl $0x0,(%esp)
3b: e8 00 00 00 00 call 40 <_main+0x40>
40: eb ee jmp30 <_main+0x30>
without cast and use -std=c89, gcc uses fldt instead of fldl
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC encoder: improve SF range utilization
On Mon, Nov 30, 2015 at 1:04 PM, Hendrik Leppkes wrote: > On Mon, Nov 30, 2015 at 4:50 PM, Claudio Freire > wrote: >> On Mon, Nov 30, 2015 at 12:27 PM, Rostislav Pehlivanov >> wrote: >>> On Sun, 2015-11-29 at 16:54 -0300, Claudio Freire wrote: Before pushing this, I'd like some feedback, especially about the implementation of point 3. I'm not sure the AAC encoder setting the cutoff in the encoder context like this is legal or desirable. >>> I think setting the cutoff is necessary. You can't avoid holes and yet >>> keep a full bandwidth as you decrease bits unless you like the sound of >>> massive quantization errors. >> >> My point was more about whether a codec should write into the context >> struct like that or not. Basically an API technicality that's unclear >> to me. >> > > It seems slightly odd to write into that variable, since thats the > cutoff the user requests. > Maybe you can use/write into a private variable instead? ac3enc seems > to use a private variable for similar purposes. I tried, but it gets very invasive and dirty, because the one that needs to write is the coder in libavcodec/aaccoder, but the one that needs to read it is libavcodec/aacpsy, which are abstracted from each other. That is, aaccoder has no access to aacpsy's internal state and viceversa. Doing the above would imply making one of the two able to access the other's internal state, which seems dirty. Alternatively, I could add the cutoff to the FFPsyContext struct and write into that instead. That seems like a cleaner approach. I'll look into that possibility. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double
Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
> double basefreq = BASEFREQ, endfreq = ENDFREQ;
> if (basefreq == BASEFREQ && endfreq == ENDFREQ)
> printf("equal\n");
> else
> printf("inequal\n");
>
> I try with gcc -std=c89 / -std=c99 on mingw 32-bit
> the result is inequal.
That looks like a compiler bug. Could you post the generated assembly code,
with and without the cast? (and with just one comparison, no need to make
things complicated)
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double
On Mon, Nov 30, 2015 at 10:52 PM, Nicolas George wrote:
> Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
>> -if (s->basefreq != BASEFREQ || s->endfreq != ENDFREQ) {
>> +if (s->basefreq != (double) BASEFREQ || s->endfreq != (double) ENDFREQ)
>> {
>
> Looks wrong to me. Since s->basefreq is double and operands are always
> converted to the largest type before comparison, the cast would be implicit.
> And BASEFREQ and ENDFREQ are double anyway.
>
> The problem, if any, is somewhere else.
>
double basefreq = BASEFREQ, endfreq = ENDFREQ;
if (basefreq == BASEFREQ && endfreq == ENDFREQ)
printf("equal\n");
else
printf("inequal\n");
I try with gcc -std=c89 / -std=c99 on mingw 32-bit
the result is inequal.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC encoder: improve SF range utilization
On Mon, Nov 30, 2015 at 4:50 PM, Claudio Freire wrote:
> On Mon, Nov 30, 2015 at 12:27 PM, Rostislav Pehlivanov
> wrote:
>> On Sun, 2015-11-29 at 16:54 -0300, Claudio Freire wrote:
>>> Before pushing this, I'd like some feedback,
>>> especially about
>>> the implementation of point 3. I'm not sure the AAC encoder
>>> setting the cutoff in the encoder context like this is legal or
>>> desirable.
>> I think setting the cutoff is necessary. You can't avoid holes and yet
>> keep a full bandwidth as you decrease bits unless you like the sound of
>> massive quantization errors.
>
> My point was more about whether a codec should write into the context
> struct like that or not. Basically an API technicality that's unclear
> to me.
>
It seems slightly odd to write into that variable, since thats the
cutoff the user requests.
Maybe you can use/write into a private variable instead? ac3enc seems
to use a private variable for similar purposes.
>>> +unsigned char nextband[128];
>> Code wise, could you rename unsigned chars to uint8_t for consistency
>> with the rest of the code?
>
> Sure
>
>>> + if (!ff_sfdelta_can_remove_band(sce, nextband, prev, w*16+g)) {
>>> + sce-->band_type[w*16+g] = 1;
>>> + } else {
>>> + sce->zeroes[w*16+g] = 1;
>>> + sce->band_type[w*16+g] = 0;
>>> + }
>> I'd recommend putting sce->zeroes[w*16+g] = 0 in the first part for
>> consistency and also band_type[] = ZERO_BT (for 0)
>
> Yeah, not sure why I didn't do that from the start.
>
>> and some random _BT
>> for non-zero bands. The band_type[] gets overriden from what I can see.
>
> That I cannot. The value there is taken as the minimum allowed band
> type by the codebook_trellis_rate function, which picks the optimum
> codebook selection. So it cannot be set to a random number, it really
> needs to be set to 1 (first nonzero codebook), and it has no constant
> or name other than "1".
>
>>> +static inline int ff_sfdelta_can_replace(const SingleChannelElement
>>> *sce, const unsigned char *nextband, int prev_sf, int new_sf, int
>>> band)
>>> +{
>>> +return new_sf >= (prev_sf - SCALE_MAX_DIFF) && new_sf
>>> <= (prev_sf + SCALE_MAX_DIFF)
>>> +&& sce->sf_idx[nextband[band]] >= (new_sf -
>>> SCALE_MAX_DIFF) && sce->sf_idx[nextband[band]] <=
>>> (new_sf + SCALE_MAX_DIFF);
>>> +}
>> Consider splitting up the function definition and using some static
>> uint8_t to split up the ternary operator because it's really long.
>
> I'll see how to make it smaller and easier to read, but this really
> needs to be inlineable (it's called in a tight loop and is very small,
> perhaps amounting to at most a dozen assembler instructions).
>
> Also I don't see how a static var would help or even be correct here.
> Perhaps you meant something else?
> ___
> 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] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double
Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
> -if (s->basefreq != BASEFREQ || s->endfreq != ENDFREQ) {
> +if (s->basefreq != (double) BASEFREQ || s->endfreq != (double) ENDFREQ) {
Looks wrong to me. Since s->basefreq is double and operands are always
converted to the largest type before comparison, the cast would be implicit.
And BASEFREQ and ENDFREQ are double anyway.
The problem, if any, is somewhere else.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC encoder: improve SF range utilization
On Mon, Nov 30, 2015 at 12:27 PM, Rostislav Pehlivanov
wrote:
> On Sun, 2015-11-29 at 16:54 -0300, Claudio Freire wrote:
>> Before pushing this, I'd like some feedback,
>> especially about
>> the implementation of point 3. I'm not sure the AAC encoder
>> setting the cutoff in the encoder context like this is legal or
>> desirable.
> I think setting the cutoff is necessary. You can't avoid holes and yet
> keep a full bandwidth as you decrease bits unless you like the sound of
> massive quantization errors.
My point was more about whether a codec should write into the context
struct like that or not. Basically an API technicality that's unclear
to me.
>> +unsigned char nextband[128];
> Code wise, could you rename unsigned chars to uint8_t for consistency
> with the rest of the code?
Sure
>> + if (!ff_sfdelta_can_remove_band(sce, nextband, prev, w*16+g)) {
>> + sce-->band_type[w*16+g] = 1;
>> + } else {
>> + sce->zeroes[w*16+g] = 1;
>> + sce->band_type[w*16+g] = 0;
>> + }
> I'd recommend putting sce->zeroes[w*16+g] = 0 in the first part for
> consistency and also band_type[] = ZERO_BT (for 0)
Yeah, not sure why I didn't do that from the start.
> and some random _BT
> for non-zero bands. The band_type[] gets overriden from what I can see.
That I cannot. The value there is taken as the minimum allowed band
type by the codebook_trellis_rate function, which picks the optimum
codebook selection. So it cannot be set to a random number, it really
needs to be set to 1 (first nonzero codebook), and it has no constant
or name other than "1".
>> +static inline int ff_sfdelta_can_replace(const SingleChannelElement
>> *sce, const unsigned char *nextband, int prev_sf, int new_sf, int
>> band)
>> +{
>> +return new_sf >= (prev_sf - SCALE_MAX_DIFF) && new_sf
>> <= (prev_sf + SCALE_MAX_DIFF)
>> +&& sce->sf_idx[nextband[band]] >= (new_sf -
>> SCALE_MAX_DIFF) && sce->sf_idx[nextband[band]] <=
>> (new_sf + SCALE_MAX_DIFF);
>> +}
> Consider splitting up the function definition and using some static
> uint8_t to split up the ternary operator because it's really long.
I'll see how to make it smaller and easier to read, but this really
needs to be inlineable (it's called in a tight loop and is very small,
perhaps amounting to at most a dozen assembler instructions).
Also I don't see how a static var would help or even be correct here.
Perhaps you meant something else?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double
fix default basefreq/endfreq comparison
on platform that does not do comparison
in double type
found on zeranoe 32-bit build, where
default freq range is detected as non-default
patch attached
From 26d93c48b7c89849bfd962fbc66069c24f11e752 Mon Sep 17 00:00:00 2001
From: Muhammad Faiz
Date: Mon, 30 Nov 2015 22:20:30 +0700
Subject: [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double
fix default basefreq/endfreq comparison
on platform that does not do comparison
in double type
found on zeranoe 32-bit build, where
default freq range is detected as non-default
---
libavfilter/avf_showcqt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
index d6e2928..712a999 100644
--- a/libavfilter/avf_showcqt.c
+++ b/libavfilter/avf_showcqt.c
@@ -466,7 +466,7 @@ static int init_axis_color(ShowCQTContext *s, AVFrame *tmp)
double *freq = NULL;
int x, y, ret;
-if (s->basefreq != BASEFREQ || s->endfreq != ENDFREQ) {
+if (s->basefreq != (double) BASEFREQ || s->endfreq != (double) ENDFREQ) {
av_log(s->ctx, AV_LOG_WARNING, "font axis rendering is not implemented
in non-default frequency range,"
" please use axisfile option instead.\n");
return AVERROR(EINVAL);
--
1.8.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] qsvenc: Add adaptive_i and adaptive_b toggles
On Mon, Nov 30, 2015 at 4:25 PM, Will Kelleher wrote: > On 11/29, Hendrik Leppkes wrote: >> >> These options were added in a merge from Libav, no further action >> seems to be required. >> > Oh, good! > > I should probably note for the record that these toggles don't always/ever > work. > I was testing on Ivy Bridge hardware and the toggles are "accepted" by the > API, > but the GOP size doesn't actually adapt. Intel has confirmed that they are > broken in the all current releases of the Media SDK [1]. So, be careful. > > [1]: https://software.intel.com/en-us/forums/intel-media-sdk/topic/600181 > > Thanks, > > will The entire MediaSDK encoder is broken on 2 of my 3 Intel GPUs, so I don't expect anything to work they produce anymore. :) - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Allow mpjpeg demuxer to process MIME parts which do not include Content-Length header.
On 11/30/15 10:24 AM, Nicolas George wrote:
Le decadi 10 frimaire, an CCXXIV, Alexander Agranovsky a écrit :
Without getting into a religious debate
This is the reason I gave practical argument.
As pointed later in the thread, lu is used elsewhere. And yes, MS makes it
interesting in this case.
wm4 explained that point. Really, long and short should only ever be used by
libc headers to implement intXX_t.
I've pondered the change, but with
if (!av_stristart(start, "boundary=")) {
start += 9;
'9' seems a bit random, and with
This is the reason for the third argument of av_stristart():
if (av_stristart(start, "boundary=", &start)) {
// no need to add 9, av_stristart() does it
}
Ah, missed that. Thanks -- attaching new iteration with this change.
Regards,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
From 3edc50fc36e6abffaa7ae39d1047537cd17aad62 Mon Sep 17 00:00:00 2001
From: Alex Agranovsky
Date: Sun, 29 Nov 2015 18:36:20 -0500
Subject: [PATCH 1/2] avformat/mpjpeg: allow processing of MIME parts without
Content-Length header
Fixes ticket 5023
Signed-off-by: Alex Agranovsky
---
libavformat/mpjpegdec.c | 168 +++-
1 file changed, 125 insertions(+), 43 deletions(-)
diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
index 2749a48..9d5700a 100644
--- a/libavformat/mpjpegdec.c
+++ b/libavformat/mpjpegdec.c
@@ -23,13 +23,30 @@
#include "avformat.h"
#include "internal.h"
+#include "avio_internal.h"
-static int get_line(AVIOContext *pb, char *line, int line_size)
+
+
+typedef struct MPJPEGDemuxContext {
+char *boundary;
+char *searchstr;
+int searchstr_len;
+} MPJPEGDemuxContext;
+
+
+static void trim_right(char *p)
{
-int i = ff_get_line(pb, line, line_size);
+if (!p || !*p)
+return;
+
+char *end = p + strlen(p);
+while (end > p && av_isspace(*(end-1)))
+*(--end) = '\0';
+}
-if (i > 1 && line[i - 2] == '\r')
-line[i - 2] = '\0';
+static int get_line(AVIOContext *pb, char *line, int line_size)
+{
+ff_get_line(pb, line, line_size);
if (pb->error)
return pb->error;
@@ -37,21 +54,11 @@ static int get_line(AVIOContext *pb, char *line, int
line_size)
if (pb->eof_reached)
return AVERROR_EOF;
+trim_right(line);
return 0;
}
-static void trim_right(char* p)
-{
-char *end;
-if (!p || !*p)
-return;
-end = p + strlen(p) - 1;
-while (end != p && av_isspace(*end)) {
-*end = '\0';
-end--;
-}
-}
static int split_tag_value(char **tag, char **value, char *line)
{
@@ -86,12 +93,24 @@ static int split_tag_value(char **tag, char **value, char
*line)
return 0;
}
-static int parse_multipart_header(AVIOContext *pb, void *log_ctx);
+static int parse_multipart_header(AVIOContext *pb,
+int* size,
+const char* expected_boundary,
+void *log_ctx);
+
+static int mpjpeg_read_close(AVFormatContext *s)
+{
+MPJPEGDemuxContext *mpjpeg = s->priv_data;
+av_freep(&mpjpeg->boundary);
+av_freep(&mpjpeg->searchstr);
+return 0;
+}
static int mpjpeg_read_probe(AVProbeData *p)
{
AVIOContext *pb;
int ret = 0;
+int size = 0;
if (p->buf_size < 2 || p->buf[0] != '-' || p->buf[1] != '-')
return 0;
@@ -100,7 +119,7 @@ static int mpjpeg_read_probe(AVProbeData *p)
if (!pb)
return 0;
-ret = (parse_multipart_header(pb, NULL)>0)?AVPROBE_SCORE_MAX:0;
+ret = (parse_multipart_header(pb, &size, "--", NULL) > 0) ?
AVPROBE_SCORE_MAX : 0;
av_free(pb);
@@ -110,14 +129,15 @@ static int mpjpeg_read_probe(AVProbeData *p)
static int mpjpeg_read_header(AVFormatContext *s)
{
AVStream *st;
-char boundary[70 + 2 + 1];
+char boundary[70 + 2 + 1] = {0};
int64_t pos = avio_tell(s->pb);
int ret;
-
-ret = get_line(s->pb, boundary, sizeof(boundary));
-if (ret < 0)
-return ret;
+do {
+ret = get_line(s->pb, boundary, sizeof(boundary));
+if (ret < 0)
+return ret;
+} while (!boundary[0]);
if (strncmp(boundary, "--", 2))
return AVERROR_INVALIDDATA;
@@ -147,11 +167,16 @@ static int parse_content_length(const char *value)
return val;
}
-static int parse_multipart_header(AVIOContext *pb, void *log_ctx)
+static int parse_multipart_header(AVIOContext *pb,
+int* size,
+const char* expected_boundary,
+void *log_ctx)
{
char line[128];
int found_content_type = 0;
-int ret, size = -1;
+int ret;
+
+*size = -1;
// get the CRLF as empty string
ret = get_line(pb, line, sizeof(line));
@@ -161,14 +186,21 @
Re: [FFmpeg-devel] [PATCH] AAC encoder: improve SF range utilization
On Sun, 2015-11-29 at 16:54 -0300, Claudio Freire wrote:
> Before pushing this, I'd like some feedback,
> especially about
> the implementation of point 3. I'm not sure the AAC encoder
> setting the cutoff in the encoder context like this is legal or
> desirable.
I think setting the cutoff is necessary. You can't avoid holes and yet
keep a full bandwidth as you decrease bits unless you like the sound of massive
quantization errors.
> Fate comparison targets don't all reflect improvements in
> quality, yet listening tests show substantially improved quality
> and stability.
That's okay, FATE isn't meant to replace human ears :)
Definitely a huge improvement at low bitrates though.
> 3. Account for lowpass cutoff during PSY analysis
This is fine and it's what the psy system should be doing instead of
always considering no lowpass is in effect.
> 1. Increase SF range utilization.
Great, this should increase the stability and decrease bug reports :)
> 2. PNS tweaks
> 4. Tweaks to RC lambda tracking loop in relation to PNS
> This tweak makes PNS much less aggressive, though it can still
> use some further tweaks.
That's fine, PNS was previously so aggressive because it needed to fill
up holes that twoloop used to make.
> +unsigned char nextband[128];
Code wise, could you rename unsigned chars to uint8_t for consistency
with the rest of the code?
> + if (!ff_sfdelta_can_remove_band(sce, nextband, prev, w*16+g)) {
> + sce-->band_type[w*16+g] = 1;
> + } else {
> + sce->zeroes[w*16+g] = 1;
> + sce->band_type[w*16+g] = 0;
> + }
I'd recommend putting sce->zeroes[w*16+g] = 0 in the first part for
consistency and also band_type[] = ZERO_BT (for 0) and some random _BT
for non-zero bands. The band_type[] gets overriden from what I can see.
> +static inline int ff_sfdelta_can_replace(const SingleChannelElement
> *sce, const unsigned char *nextband, int prev_sf, int new_sf, int
> band)
> +{
> +return new_sf >= (prev_sf - SCALE_MAX_DIFF) && new_sf
> <= (prev_sf + SCALE_MAX_DIFF)
> +&& sce->sf_idx[nextband[band]] >= (new_sf -
> SCALE_MAX_DIFF) && sce->sf_idx[nextband[band]] <=
> (new_sf + SCALE_MAX_DIFF);
> +}
Consider splitting up the function definition and using some static
uint8_t to split up the ternary operator because it's really long.
But those 3 things are really just small nitpicks. It really improves
quality quite a lot.
So yeah, LGTM. Did test it extensively with quite a lot of tracks and
it doesn't seem to trigger any asserts anymore. Fix those 3 small
things if you have the time.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] qsvenc: Add adaptive_i and adaptive_b toggles
On 11/29, Hendrik Leppkes wrote: > > These options were added in a merge from Libav, no further action > seems to be required. > Oh, good! I should probably note for the record that these toggles don't always/ever work. I was testing on Ivy Bridge hardware and the toggles are "accepted" by the API, but the GOP size doesn't actually adapt. Intel has confirmed that they are broken in the all current releases of the Media SDK [1]. So, be careful. [1]: https://software.intel.com/en-us/forums/intel-media-sdk/topic/600181 Thanks, will ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Allow mpjpeg demuxer to process MIME parts which do not include Content-Length header.
Le decadi 10 frimaire, an CCXXIV, Alexander Agranovsky a écrit :
> Without getting into a religious debate
This is the reason I gave practical argument.
> As pointed later in the thread, lu is used elsewhere. And yes, MS makes it
> interesting in this case.
wm4 explained that point. Really, long and short should only ever be used by
libc headers to implement intXX_t.
> I've pondered the change, but with
> if (!av_stristart(start, "boundary=")) {
> start += 9;
> '9' seems a bit random, and with
This is the reason for the third argument of av_stristart():
if (av_stristart(start, "boundary=", &start)) {
// no need to add 9, av_stristart() does it
}
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] qsvenc: write a53 caption data to SEI
On 11/26, Michael Niedermayer wrote:
>
> I tried to apply this but it seems to doesnt apply cleanly anymore
> id fix the conflicts and apply but i cant test this so i think its
> better if you would fix it
>
Here is a rebased version.
will
>From 5452911c08cdb8cebe861d38a9c1b12924120d78 Mon Sep 17 00:00:00 2001
From: Will Kelleher
Date: Tue, 27 Oct 2015 12:08:45 -0500
Subject: [PATCH] qsvenc: write a53 caption data to SEI
Signed-off-by: Will Kelleher
---
libavcodec/qsv_internal.h | 3 +++
libavcodec/qsvenc.c | 39 +---
libavcodec/qsvenc.h | 4 +++
libavcodec/qsvenc_h264.c | 66 +++
4 files changed, 108 insertions(+), 4 deletions(-)
diff --git a/libavcodec/qsv_internal.h b/libavcodec/qsv_internal.h
index b9ad199..c235e07 100644
--- a/libavcodec/qsv_internal.h
+++ b/libavcodec/qsv_internal.h
@@ -45,6 +45,8 @@
#define ASYNC_DEPTH_DEFAULT 4 // internal parallelism
+#define QSV_MAX_ENC_PAYLOAD 2 // # of mfxEncodeCtrl payloads supported
+
#define QSV_VERSION_ATLEAST(MAJOR, MINOR) \
(MFX_VERSION_MAJOR > (MAJOR) || \
MFX_VERSION_MAJOR == (MAJOR) && MFX_VERSION_MINOR >= (MINOR))
@@ -52,6 +54,7 @@
typedef struct QSVFrame {
AVFrame *frame;
mfxFrameSurface1 *surface;
+mfxEncodeCtrl enc_ctrl;
mfxFrameSurface1 surface_internal;
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 25a57f4..d00fdff 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -30,6 +30,7 @@
#include "libavutil/log.h"
#include "libavutil/time.h"
#include "libavutil/imgutils.h"
+#include "libavcodec/bytestream.h"
#include "avcodec.h"
#include "internal.h"
@@ -753,12 +754,26 @@ int ff_qsv_enc_init(AVCodecContext *avctx, QSVEncContext
*q)
return 0;
}
+static void free_encoder_ctrl_payloads(mfxEncodeCtrl* enc_ctrl)
+{
+if (enc_ctrl) {
+int i;
+for (i = 0; i < enc_ctrl->NumPayload && i < QSV_MAX_ENC_PAYLOAD; i++) {
+mfxPayload* pay = enc_ctrl->Payload[i];
+av_free(enc_ctrl->Payload[i]->Data);
+av_free(pay);
+}
+enc_ctrl->NumPayload = 0;
+}
+}
+
static void clear_unused_frames(QSVEncContext *q)
{
QSVFrame *cur = q->work_frames;
while (cur) {
if (cur->surface && !cur->surface->Data.Locked) {
cur->surface = NULL;
+free_encoder_ctrl_payloads(&cur->enc_ctrl);
av_frame_unref(cur->frame);
}
cur = cur->next;
@@ -791,6 +806,11 @@ static int get_free_frame(QSVEncContext *q, QSVFrame **f)
av_freep(&frame);
return AVERROR(ENOMEM);
}
+frame->enc_ctrl.Payload = av_mallocz(sizeof(mfxPayload*) *
QSV_MAX_ENC_PAYLOAD);
+if (!frame->enc_ctrl.Payload) {
+av_freep(&frame);
+return AVERROR(ENOMEM);
+}
*last = frame;
*f = frame;
@@ -799,7 +819,7 @@ static int get_free_frame(QSVEncContext *q, QSVFrame **f)
}
static int submit_frame(QSVEncContext *q, const AVFrame *frame,
-mfxFrameSurface1 **surface)
+QSVFrame **new_frame)
{
QSVFrame *qf;
int ret;
@@ -860,7 +880,7 @@ static int submit_frame(QSVEncContext *q, const AVFrame
*frame,
qf->surface->Data.TimeStamp = av_rescale_q(frame->pts,
q->avctx->time_base, (AVRational){1, 9});
-*surface = qf->surface;
+*new_frame = qf;
return 0;
}
@@ -885,15 +905,21 @@ int ff_qsv_encode(AVCodecContext *avctx, QSVEncContext *q,
mfxFrameSurface1 *surf = NULL;
mfxSyncPoint sync = NULL;
+QSVFrame *qsv_frame = NULL;
+mfxEncodeCtrl* enc_ctrl = NULL;
int ret;
if (frame) {
-ret = submit_frame(q, frame, &surf);
+ret = submit_frame(q, frame, &qsv_frame);
if (ret < 0) {
av_log(avctx, AV_LOG_ERROR, "Error submitting the frame for
encoding.\n");
return ret;
}
}
+if (qsv_frame) {
+surf = qsv_frame->surface;
+enc_ctrl = &qsv_frame->enc_ctrl;
+}
ret = av_new_packet(&new_pkt, q->packet_size);
if (ret < 0) {
@@ -909,8 +935,12 @@ int ff_qsv_encode(AVCodecContext *avctx, QSVEncContext *q,
bs->Data = new_pkt.data;
bs->MaxLength = new_pkt.size;
+if (q->set_encode_ctrl_cb) {
+q->set_encode_ctrl_cb(avctx, frame, &qsv_frame->enc_ctrl);
+}
+
do {
-ret = MFXVideoENCODE_EncodeFrameAsync(q->session, NULL, surf, bs,
&sync);
+ret = MFXVideoENCODE_EncodeFrameAsync(q->session, enc_ctrl, surf, bs,
&sync);
if (ret == MFX_WRN_DEVICE_BUSY) {
av_usleep(500);
continue;
@@ -1010,6 +1040,7 @@ int ff_qsv_enc_close(AVCodecContext *avctx, QSVEncContext
*q)
while (cur) {
q->work_frames = cur->next;
av_frame_free(&cur->frame);
+av_free(cur->enc_ctrl.Payload);
av_freep(&cur);
cur = q->work_frames;
}
diff --git a/libavcodec/q
Re: [FFmpeg-devel] [PATCH] avcodec/ac3: always use hardcoded tables
On Mon, Nov 30, 2015 at 6:39 AM, wm4 wrote:
> On Sun, 29 Nov 2015 20:40:11 -0500
> Ganesh Ajjanagadde wrote:
>
>> The table in question is a 253 byte one. In fact, it turns out that
>> dynamic generation of the table results in an increased binary size.
>>
>> Code compiled with GCC 5.2.0, x86-64 (size in bytes), before and after
>> patch:
>> old: 62321064 libavcodec/libavcodec.so.57
>> new: 62320536 libavcodec/libavcodec.so.57
>>
>> Thus, it always make sense to statically allocate this.
>>
>> Signed-off-by: Ganesh Ajjanagadde
>> ---
>> libavcodec/ac3.c| 24
>> libavcodec/ac3dec.c | 1 -
>> libavcodec/ac3enc.c | 2 --
>> libavcodec/ac3tab.h | 8 +---
>> 4 files changed, 1 insertion(+), 34 deletions(-)
>>
>> diff --git a/libavcodec/ac3.c b/libavcodec/ac3.c
>> index b54315d..1d4eaa5 100644
>> --- a/libavcodec/ac3.c
>> +++ b/libavcodec/ac3.c
>> @@ -39,8 +39,6 @@ const uint8_t ff_ac3_band_start_tab[AC3_CRITICAL_BANDS+1]
>> = {
>> 79, 85, 97, 109, 121, 133, 157, 181, 205, 229, 253
>> };
>>
>> -#if CONFIG_HARDCODED_TABLES
>> -
>> /**
>> * Map each frequency coefficient bin to the critical band that contains it.
>> */
>> @@ -69,10 +67,6 @@ const uint8_t ff_ac3_bin_to_band_tab[253] = {
>> 49, 49, 49, 49, 49, 49, 49, 49, 49, 49, 49, 49
>> };
>>
>> -#else /* CONFIG_HARDCODED_TABLES */
>> -uint8_t ff_ac3_bin_to_band_tab[253];
>> -#endif
>> -
>> static inline int calc_lowcomp1(int a, int b0, int b1, int c)
>> {
>> if ((b0 + 256) == b1) {
>> @@ -214,21 +208,3 @@ int ff_ac3_bit_alloc_calc_mask(AC3BitAllocParameters
>> *s, int16_t *band_psd,
>> }
>> return 0;
>> }
>> -
>> -/**
>> - * Initialize some tables.
>> - * note: This function must remain thread safe because it is called by the
>> - * AVParser init code.
>> - */
>> -av_cold void ff_ac3_common_init(void)
>> -{
>> -#if !CONFIG_HARDCODED_TABLES
>> -/* compute ff_ac3_bin_to_band_tab from ff_ac3_band_start_tab */
>> -int bin = 0, band;
>> -for (band = 0; band < AC3_CRITICAL_BANDS; band++) {
>> -int band_end = ff_ac3_band_start_tab[band+1];
>> -while (bin < band_end)
>> -ff_ac3_bin_to_band_tab[bin++] = band;
>> -}
>> -#endif /* !CONFIG_HARDCODED_TABLES */
>> -}
>> diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
>> index ad91405..efc58e5 100644
>> --- a/libavcodec/ac3dec.c
>> +++ b/libavcodec/ac3dec.c
>> @@ -185,7 +185,6 @@ static av_cold int ac3_decode_init(AVCodecContext *avctx)
>>
>> s->avctx = avctx;
>>
>> -ff_ac3_common_init();
>> ac3_tables_init();
>> ff_mdct_init(&s->imdct_256, 8, 1, 1.0);
>> ff_mdct_init(&s->imdct_512, 9, 1, 1.0);
>> diff --git a/libavcodec/ac3enc.c b/libavcodec/ac3enc.c
>> index c8a0caa..636ca72 100644
>> --- a/libavcodec/ac3enc.c
>> +++ b/libavcodec/ac3enc.c
>> @@ -2431,8 +2431,6 @@ av_cold int ff_ac3_encode_init(AVCodecContext *avctx)
>>
>> s->eac3 = avctx->codec_id == AV_CODEC_ID_EAC3;
>>
>> -ff_ac3_common_init();
>> -
>> ret = validate_options(s);
>> if (ret)
>> return ret;
>> diff --git a/libavcodec/ac3tab.h b/libavcodec/ac3tab.h
>> index 74cbd9e..f529fc8 100644
>> --- a/libavcodec/ac3tab.h
>> +++ b/libavcodec/ac3tab.h
>> @@ -27,12 +27,6 @@
>> #include "libavutil/internal.h"
>> #include "ac3.h"
>>
>> -#if CONFIG_HARDCODED_TABLES
>> -# define HCONST const
>> -#else
>> -# define HCONST
>> -#endif
>> -
>> extern const uint16_t ff_ac3_frame_size_tab[38][3];
>> extern const uint8_t ff_ac3_channels_tab[8];
>> extern av_export const uint16_t avpriv_ac3_channel_layout_tab[8];
>> @@ -54,7 +48,7 @@ extern const int16_t ff_ac3_floor_tab[8];
>> extern const uint16_t ff_ac3_fast_gain_tab[8];
>> extern const uint16_t ff_eac3_default_chmap[8];
>> extern const uint8_t ff_ac3_band_start_tab[AC3_CRITICAL_BANDS+1];
>> -extern HCONST uint8_t ff_ac3_bin_to_band_tab[253];
>> +extern const uint8_t ff_ac3_bin_to_band_tab[253];
>>
>> /** Custom channel map locations bitmask
>> * Other channels described in documentation:
>
> Seems fine if it passes FATE. (Note that I'm not AC3 maintainer.)
Maintainer seems to be Justin Ruggles, who has been inactive since
last year, and moreover works for Libav. Thanks for the review; will
push later.
> ___
> 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] Allow mpjpeg demuxer to process MIME parts which do not include Content-Length header.
On 11/30/15 7:34 AM, wm4 wrote:
On Mon, 30 Nov 2015 07:27:14 -0500
Alexander Agranovsky wrote:
On 11/30/15 2:41 AM, Nicolas George wrote:
Le nonidi 9 frimaire, an CCXXIV, Alexander Agranovsky a écrit :
Please see the updated patches attached. The trimming loop that was subject
of the discussion had been rewritten to use indices rather than pointer
arithmetics.
This kind of drastic change was not necessary, you can do the same with
pointers. IMHO, the best way of dealing with that situation is this: when
dealing with the end of the string, have the pointer point AFTER the end of
the string, i.e.:
char *p = string + strlen(string); // not -1
if (p > string && av_isspace(p[-1]))
*(--p) = 0;
That works too.
+char* boundary;
Here and in all new code, please use "char *var" instead of "char* var" for
consistency. There is a good reason for that: "char* a, b" means that a is a
pointer and b is not, grouping the pointer mark with the type is misleading.
Without getting into a religious debate, not my favorite part of the
style ;)
Will change the code to match the style of existing, though.
+"Expected boundary '%s' not found, instead found a line of %lu
bytes\n",
+expected_boundary,
+strlen(line));
"%lu" is not correct for size_t. The correct type would be %zu, but it is
possible that we have to use another construct to avoid bugs from microsoft
libraries, see other instances in the code for examples.
As pointed later in the thread, lu is used elsewhere. And yes, MS makes
it interesting in this case.
No, I meant %zu. lu really isn't safe. It will fail on 64 bit Windows,
for one. (But what Nicolas meant was that %zu could fail on Windows
because Windows is stuck in the past, but we work that around if
necessary - I think.)
-size = parse_content_length(value);
-if (size < 0)
-return size;
+*size = parse_content_length(value);
Did you remove the check on purpose?
Yes. Invalid Content-Length, just as no Content-Length at all, should
not prevent us from processing the part.
Probably not a good idea to ignore when the server sends us definitely
broken data. I'd prefer failure or at least an error message.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
And one more round ...
From 3edc50fc36e6abffaa7ae39d1047537cd17aad62 Mon Sep 17 00:00:00 2001
From: Alex Agranovsky
Date: Sun, 29 Nov 2015 18:36:20 -0500
Subject: [PATCH 1/2] avformat/mpjpeg: allow processing of MIME parts without
Content-Length header
Fixes ticket 5023
Signed-off-by: Alex Agranovsky
---
libavformat/mpjpegdec.c | 168 +++-
1 file changed, 125 insertions(+), 43 deletions(-)
diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
index 2749a48..9d5700a 100644
--- a/libavformat/mpjpegdec.c
+++ b/libavformat/mpjpegdec.c
@@ -23,13 +23,30 @@
#include "avformat.h"
#include "internal.h"
+#include "avio_internal.h"
-static int get_line(AVIOContext *pb, char *line, int line_size)
+
+
+typedef struct MPJPEGDemuxContext {
+char *boundary;
+char *searchstr;
+int searchstr_len;
+} MPJPEGDemuxContext;
+
+
+static void trim_right(char *p)
{
-int i = ff_get_line(pb, line, line_size);
+if (!p || !*p)
+return;
+
+char *end = p + strlen(p);
+while (end > p && av_isspace(*(end-1)))
+*(--end) = '\0';
+}
-if (i > 1 && line[i - 2] == '\r')
-line[i - 2] = '\0';
+static int get_line(AVIOContext *pb, char *line, int line_size)
+{
+ff_get_line(pb, line, line_size);
if (pb->error)
return pb->error;
@@ -37,21 +54,11 @@ static int get_line(AVIOContext *pb, char *line, int
line_size)
if (pb->eof_reached)
return AVERROR_EOF;
+trim_right(line);
return 0;
}
-static void trim_right(char* p)
-{
-char *end;
-if (!p || !*p)
-return;
-end = p + strlen(p) - 1;
-while (end != p && av_isspace(*end)) {
-*end = '\0';
-end--;
-}
-}
static int split_tag_value(char **tag, char **value, char *line)
{
@@ -86,12 +93,24 @@ static int split_tag_value(char **tag, char **value, char
*line)
return 0;
}
-static int parse_multipart_header(AVIOContext *pb, void *log_ctx);
+static int parse_multipart_header(AVIOContext *pb,
+int* size,
+const char* expected_boundary,
+void *log_ctx);
+
+static int mpjpeg_read_close(AVFormatContext *s)
+{
+MPJPEGDemuxContext *mpjpeg = s->priv_data;
+av_freep(&mpjpeg->boundary);
+av_freep(&mpjpeg->searchstr);
+return 0;
+}
static int mpjpeg_read_probe(AVProbeData *p)
{
AVIOContext *pb;
int ret = 0;
+int size = 0;
if (p->buf_si
Re: [FFmpeg-devel] GreenMetadata complexity metric access through high level API
Hello >you should look at avframesidedata Actually the issue is that the green metadatadata are concerning the upcoming frame (They are used to predict the upcoming complexity). The avframesidedata are concerning a frame which is already decoded (so it's not useful in the case of greenmetadata). We made a proof of concept using a home made parsing function (replacing av_read_frame() by a custom one), but we are thinking about a more portable solution. Nicolas DEROUINEAU Research Engineer VITEC T. +33 1 46 73 06 06 E. nicolas.derouin...@vitec.com W. www.vitec.com De : ffmpeg-devel-boun...@ffmpeg.org de la part de Vittorio Giovara Envoyé : mercredi 1 juillet 2015 12:22 À : FFmpeg development discussions and patches Cc : Didier Nicholson; Erwan Raffin; Nicolas Tizon; Yahia Benmoussa Objet : Re: [FFmpeg-devel] GreenMetadata complexity metric access through high level API On Wed, Jul 1, 2015 at 11:08 AM, Nicolas Derouineau wrote: > Hello, > > H264 GreenMetadata parsing is now supported in ffmpeg, but the informations > are stored in the h264context, which is not available at a higher level. > > Is it possible to add a new field named "upcoming complexity metrics", which > should be codec agnostic, either in the avcodeccontext struct or in the > AVFrame struct ? you should look at avframesidedata -- Vittorio ___ 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] avformat/mov: always enable parsing for mp3
On Mon, Nov 30, 2015 at 10:03:58AM +0100, wm4 wrote: > The heuristic for enabling it is not very reliable. Even if always > parsing should cause problems in some cases, it would be better to > fix the parser instead. (But no bad samples are known to me.) heres one sample: https://dl.dropboxusercontent.com/u/76042064/packed_maindata.mp3.mp4 i belive theres another potential problem when enabling the parser overrides a packet duration from the demuxer, like for the first or last packet or something [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Allow mpjpeg demuxer to process MIME parts which do not include Content-Length header.
On 11/30/15 7:34 AM, wm4 wrote: On Mon, 30 Nov 2015 07:27:14 -0500 Alexander Agranovsky wrote: On 11/30/15 2:41 AM, Nicolas George wrote: Le nonidi 9 frimaire, an CCXXIV, Alexander Agranovsky a écrit : Please see the updated patches attached. The trimming loop that was subject of the discussion had been rewritten to use indices rather than pointer arithmetics. This kind of drastic change was not necessary, you can do the same with pointers. IMHO, the best way of dealing with that situation is this: when dealing with the end of the string, have the pointer point AFTER the end of the string, i.e.: char *p = string + strlen(string); // not -1 if (p > string && av_isspace(p[-1])) *(--p) = 0; That works too. +char* boundary; Here and in all new code, please use "char *var" instead of "char* var" for consistency. There is a good reason for that: "char* a, b" means that a is a pointer and b is not, grouping the pointer mark with the type is misleading. Without getting into a religious debate, not my favorite part of the style ;) Will change the code to match the style of existing, though. +"Expected boundary '%s' not found, instead found a line of %lu bytes\n", +expected_boundary, +strlen(line)); "%lu" is not correct for size_t. The correct type would be %zu, but it is possible that we have to use another construct to avoid bugs from microsoft libraries, see other instances in the code for examples. As pointed later in the thread, lu is used elsewhere. And yes, MS makes it interesting in this case. No, I meant %zu. lu really isn't safe. It will fail on 64 bit Windows, for one. (But what Nicolas meant was that %zu could fail on Windows because Windows is stuck in the past, but we work that around if necessary - I think.) -size = parse_content_length(value); -if (size < 0) -return size; +*size = parse_content_length(value); Did you remove the check on purpose? Yes. Invalid Content-Length, just as no Content-Length at all, should not prevent us from processing the part. Probably not a good idea to ignore when the server sends us definitely broken data. I'd prefer failure or at least an error message. I'll add a warning, how about that? ___ 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] Allow mpjpeg demuxer to process MIME parts which do not include Content-Length header.
On 11/30/15 6:37 AM, wm4 wrote: On Mon, 30 Nov 2015 08:41:42 +0100 Nicolas George wrote: +"Expected boundary '%s' not found, instead found a line of %lu bytes\n", +expected_boundary, +strlen(line)); "%lu" is not correct for size_t. The correct type would be %zu, but it is possible that we have to use another construct to avoid bugs from microsoft libraries, see other instances in the code for examples. It's used in some portable code (e.g. http.c), so it's probably fine. -size = parse_content_length(value); -if (size < 0) -return size; +*size = parse_content_length(value); Did you remove the check on purpose? He probably did, but now that I look at this again, it seems a bit shady. This code parses the Content-length header, and if parsing it fails, it will now try the boundary instead. But doesn't this header always require a numeric value if it's present at all? It surely does. However, seeing creative ways in which existing endpoints choose to break MIME, I'd rather not introduce a restriction where we don't have to. Take the boundary for example -- the code before my changes (and after as well, at least by default) only looks for "CRLF--". I would've found it unfathomable and unacceptable, if I didn't recently see a trace from a popular consumer camera, where one boundary was declared, and another was used. I'm a huge proponent of standards *compliance*, but when standards *enforcement* will result in a regression report, even if the other side is at fault, choosing to be a bit more flexible may be the way to go. In this particular case I don't see a downside, do you? ___ 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] Allow mpjpeg demuxer to process MIME parts which do not include Content-Length header.
On Mon, 30 Nov 2015 07:27:14 -0500 Alexander Agranovsky wrote: > On 11/30/15 2:41 AM, Nicolas George wrote: > > Le nonidi 9 frimaire, an CCXXIV, Alexander Agranovsky a écrit : > >> Please see the updated patches attached. The trimming loop that was subject > >> of the discussion had been rewritten to use indices rather than pointer > >> arithmetics. > > This kind of drastic change was not necessary, you can do the same with > > pointers. IMHO, the best way of dealing with that situation is this: when > > dealing with the end of the string, have the pointer point AFTER the end of > > the string, i.e.: > > > > char *p = string + strlen(string); // not -1 > > if (p > string && av_isspace(p[-1])) > > *(--p) = 0; > That works too. > > > > >> +char* boundary; > > Here and in all new code, please use "char *var" instead of "char* var" for > > consistency. There is a good reason for that: "char* a, b" means that a is a > > pointer and b is not, grouping the pointer mark with the type is > > misleading. > Without getting into a religious debate, not my favorite part of the > style ;) > Will change the code to match the style of existing, though. > > >> +"Expected boundary '%s' not found, instead found a line > >> of %lu bytes\n", > >> +expected_boundary, > >> +strlen(line)); > > "%lu" is not correct for size_t. The correct type would be %zu, but it is > > possible that we have to use another construct to avoid bugs from microsoft > > libraries, see other instances in the code for examples. > > As pointed later in the thread, lu is used elsewhere. And yes, MS makes > it interesting in this case. No, I meant %zu. lu really isn't safe. It will fail on 64 bit Windows, for one. (But what Nicolas meant was that %zu could fail on Windows because Windows is stuck in the past, but we work that around if necessary - I think.) > >> -size = parse_content_length(value); > >> -if (size < 0) > >> -return size; > >> +*size = parse_content_length(value); > > Did you remove the check on purpose? > > Yes. Invalid Content-Length, just as no Content-Length at all, should > not prevent us from processing the part. Probably not a good idea to ignore when the server sends us definitely broken data. I'd prefer failure or at least an error message. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] making qsv session routines private
> -Ursprüngliche Nachricht- > Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag > von Sven Dueking > Gesendet: Montag, 30. November 2015 11:06 > An: 'FFmpeg development discussions and patches' > Betreff: Re: [FFmpeg-devel] [PATCH] making qsv session routines private > > > > > -Ursprüngliche Nachricht- > > Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag > > von Hendrik Leppkes > > Gesendet: Montag, 30. November 2015 10:56 > > An: FFmpeg development discussions and patches > > Betreff: Re: [FFmpeg-devel] [PATCH] making qsv session routines > > private > > > > On Mon, Nov 30, 2015 at 10:45 AM, Sven Dueking > wrote: > > > Hi all, > > > > > > This is a follow up patch according to the discussion of > > > > > > [FFmpeg-devel] [PATCH] qsv.c: making qsv session routines > > > > > > Hopefully this is the correct way to share internal functions > > > between codecs and filters. > > > At least other filters seems to do it this way ... > > > > > > Thanks, > > > Sven > > > > > > > > > > We really try to avoid avpriv in new code, as its a kludge at best. > > Strange, this was suggested during the discussion > > I guess we need a better way to share internal things. The currently > nonsensical library separation makes this hard. We could just use > avpriv_ in this case, or make a header-only implementation. Certainly > it doesn't need to be public API. > > So, do you prefer that I double the code or a header only > implementation ? > Or, is there another way to do this (besides avpriv) ? Another option is to rename the header from QSV_internal.h to QSV_public.h (something like this) and use the av_ prefix. Not sure that it´s allowed, some other filters call av_ functions from the codecs. What do you think ? > > > ___ > > 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Allow mpjpeg demuxer to process MIME parts which do not include Content-Length header.
On 11/30/15 2:41 AM, Nicolas George wrote:
Le nonidi 9 frimaire, an CCXXIV, Alexander Agranovsky a écrit :
Please see the updated patches attached. The trimming loop that was subject
of the discussion had been rewritten to use indices rather than pointer
arithmetics.
This kind of drastic change was not necessary, you can do the same with
pointers. IMHO, the best way of dealing with that situation is this: when
dealing with the end of the string, have the pointer point AFTER the end of
the string, i.e.:
char *p = string + strlen(string); // not -1
if (p > string && av_isspace(p[-1]))
*(--p) = 0;
That works too.
+char* boundary;
Here and in all new code, please use "char *var" instead of "char* var" for
consistency. There is a good reason for that: "char* a, b" means that a is a
pointer and b is not, grouping the pointer mark with the type is misleading.
Without getting into a religious debate, not my favorite part of the
style ;)
Will change the code to match the style of existing, though.
+"Expected boundary '%s' not found, instead found a line of %lu
bytes\n",
+expected_boundary,
+strlen(line));
"%lu" is not correct for size_t. The correct type would be %zu, but it is
possible that we have to use another construct to avoid bugs from microsoft
libraries, see other instances in the code for examples.
As pointed later in the thread, lu is used elsewhere. And yes, MS makes
it interesting in this case.
-size = parse_content_length(value);
-if (size < 0)
-return size;
+*size = parse_content_length(value);
Did you remove the check on purpose?
Yes. Invalid Content-Length, just as no Content-Length at all, should
not prevent us from processing the part.
+if (!av_strncasecmp(start, "boundary=", 9)) {
+start += 9;
It has already be pointed out: av_stristart() to avoid the duplicated magic
number.
I've pondered the change, but with
if (!av_stristart(start, "boundary=")) {
start += 9;
'9' seems a bit random, and with
if (!av_stristart(start, "boundary=")) {
start += strlen("boundary=");
we end up with unnecessarily taking strlen at least twice.
Again, not critical, but IMHO as written it is the best compromise
between readability and efficiency.
Thanks for your comments!
Can not comment on the functional aspect, sorry.
Regards,
___
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] avcodec/ac3: always use hardcoded tables
On Sun, 29 Nov 2015 20:40:11 -0500
Ganesh Ajjanagadde wrote:
> The table in question is a 253 byte one. In fact, it turns out that
> dynamic generation of the table results in an increased binary size.
>
> Code compiled with GCC 5.2.0, x86-64 (size in bytes), before and after
> patch:
> old: 62321064 libavcodec/libavcodec.so.57
> new: 62320536 libavcodec/libavcodec.so.57
>
> Thus, it always make sense to statically allocate this.
>
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavcodec/ac3.c| 24
> libavcodec/ac3dec.c | 1 -
> libavcodec/ac3enc.c | 2 --
> libavcodec/ac3tab.h | 8 +---
> 4 files changed, 1 insertion(+), 34 deletions(-)
>
> diff --git a/libavcodec/ac3.c b/libavcodec/ac3.c
> index b54315d..1d4eaa5 100644
> --- a/libavcodec/ac3.c
> +++ b/libavcodec/ac3.c
> @@ -39,8 +39,6 @@ const uint8_t ff_ac3_band_start_tab[AC3_CRITICAL_BANDS+1] =
> {
> 79, 85, 97, 109, 121, 133, 157, 181, 205, 229, 253
> };
>
> -#if CONFIG_HARDCODED_TABLES
> -
> /**
> * Map each frequency coefficient bin to the critical band that contains it.
> */
> @@ -69,10 +67,6 @@ const uint8_t ff_ac3_bin_to_band_tab[253] = {
> 49, 49, 49, 49, 49, 49, 49, 49, 49, 49, 49, 49
> };
>
> -#else /* CONFIG_HARDCODED_TABLES */
> -uint8_t ff_ac3_bin_to_band_tab[253];
> -#endif
> -
> static inline int calc_lowcomp1(int a, int b0, int b1, int c)
> {
> if ((b0 + 256) == b1) {
> @@ -214,21 +208,3 @@ int ff_ac3_bit_alloc_calc_mask(AC3BitAllocParameters *s,
> int16_t *band_psd,
> }
> return 0;
> }
> -
> -/**
> - * Initialize some tables.
> - * note: This function must remain thread safe because it is called by the
> - * AVParser init code.
> - */
> -av_cold void ff_ac3_common_init(void)
> -{
> -#if !CONFIG_HARDCODED_TABLES
> -/* compute ff_ac3_bin_to_band_tab from ff_ac3_band_start_tab */
> -int bin = 0, band;
> -for (band = 0; band < AC3_CRITICAL_BANDS; band++) {
> -int band_end = ff_ac3_band_start_tab[band+1];
> -while (bin < band_end)
> -ff_ac3_bin_to_band_tab[bin++] = band;
> -}
> -#endif /* !CONFIG_HARDCODED_TABLES */
> -}
> diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
> index ad91405..efc58e5 100644
> --- a/libavcodec/ac3dec.c
> +++ b/libavcodec/ac3dec.c
> @@ -185,7 +185,6 @@ static av_cold int ac3_decode_init(AVCodecContext *avctx)
>
> s->avctx = avctx;
>
> -ff_ac3_common_init();
> ac3_tables_init();
> ff_mdct_init(&s->imdct_256, 8, 1, 1.0);
> ff_mdct_init(&s->imdct_512, 9, 1, 1.0);
> diff --git a/libavcodec/ac3enc.c b/libavcodec/ac3enc.c
> index c8a0caa..636ca72 100644
> --- a/libavcodec/ac3enc.c
> +++ b/libavcodec/ac3enc.c
> @@ -2431,8 +2431,6 @@ av_cold int ff_ac3_encode_init(AVCodecContext *avctx)
>
> s->eac3 = avctx->codec_id == AV_CODEC_ID_EAC3;
>
> -ff_ac3_common_init();
> -
> ret = validate_options(s);
> if (ret)
> return ret;
> diff --git a/libavcodec/ac3tab.h b/libavcodec/ac3tab.h
> index 74cbd9e..f529fc8 100644
> --- a/libavcodec/ac3tab.h
> +++ b/libavcodec/ac3tab.h
> @@ -27,12 +27,6 @@
> #include "libavutil/internal.h"
> #include "ac3.h"
>
> -#if CONFIG_HARDCODED_TABLES
> -# define HCONST const
> -#else
> -# define HCONST
> -#endif
> -
> extern const uint16_t ff_ac3_frame_size_tab[38][3];
> extern const uint8_t ff_ac3_channels_tab[8];
> extern av_export const uint16_t avpriv_ac3_channel_layout_tab[8];
> @@ -54,7 +48,7 @@ extern const int16_t ff_ac3_floor_tab[8];
> extern const uint16_t ff_ac3_fast_gain_tab[8];
> extern const uint16_t ff_eac3_default_chmap[8];
> extern const uint8_t ff_ac3_band_start_tab[AC3_CRITICAL_BANDS+1];
> -extern HCONST uint8_t ff_ac3_bin_to_band_tab[253];
> +extern const uint8_t ff_ac3_bin_to_band_tab[253];
>
> /** Custom channel map locations bitmask
> * Other channels described in documentation:
Seems fine if it passes FATE. (Note that I'm not AC3 maintainer.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Allow mpjpeg demuxer to process MIME parts which do not include Content-Length header.
On Mon, 30 Nov 2015 08:41:42 +0100 Nicolas George wrote: > > +"Expected boundary '%s' not found, instead found a line of > > %lu bytes\n", > > +expected_boundary, > > +strlen(line)); > > "%lu" is not correct for size_t. The correct type would be %zu, but it is > possible that we have to use another construct to avoid bugs from microsoft > libraries, see other instances in the code for examples. It's used in some portable code (e.g. http.c), so it's probably fine. > > -size = parse_content_length(value); > > -if (size < 0) > > -return size; > > +*size = parse_content_length(value); > > Did you remove the check on purpose? He probably did, but now that I look at this again, it seems a bit shady. This code parses the Content-length header, and if parsing it fails, it will now try the boundary instead. But doesn't this header always require a numeric value if it's present at all? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/crc: avoid needless space wastage of hardcoded crc table
On Monday 30 November 2015 03:58:16 am James Almer wrote: > One could argue no releases have been made since the last major bump, so But given that releases get not much support, this is not a valid argument. > breakages like this are unlikely to affect anyone. But then again, it's > been months since said major bump. That's why an ifdef is appropriate. > What's been chosen in previous bumps as the drawing line for ABI breakages? A week is ok, it was too long this time. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] making qsv session routines private
> -Ursprüngliche Nachricht- > Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag > von Hendrik Leppkes > Gesendet: Montag, 30. November 2015 10:56 > An: FFmpeg development discussions and patches > Betreff: Re: [FFmpeg-devel] [PATCH] making qsv session routines private > > On Mon, Nov 30, 2015 at 10:45 AM, Sven Dueking wrote: > > Hi all, > > > > This is a follow up patch according to the discussion of > > > > [FFmpeg-devel] [PATCH] qsv.c: making qsv session routines > > > > Hopefully this is the correct way to share internal functions between > > codecs and filters. > > At least other filters seems to do it this way ... > > > > Thanks, > > Sven > > > > > > We really try to avoid avpriv in new code, as its a kludge at best. Strange, this was suggested during the discussion I guess we need a better way to share internal things. The currently nonsensical library separation makes this hard. We could just use avpriv_ in this case, or make a header-only implementation. Certainly it doesn't need to be public API. So, do you prefer that I double the code or a header only implementation ? Or, is there another way to do this (besides avpriv) ? > ___ > 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] making qsv session routines private
On Mon, Nov 30, 2015 at 10:45 AM, Sven Dueking wrote: > Hi all, > > This is a follow up patch according to the discussion of > > [FFmpeg-devel] [PATCH] qsv.c: making qsv session routines > > Hopefully this is the correct way to share internal functions between codecs > and filters. > At least other filters seems to do it this way ... > > Thanks, > Sven > > We really try to avoid avpriv in new code, as its a kludge at best. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] making qsv session routines private
Hi all, This is a follow up patch according to the discussion of [FFmpeg-devel] [PATCH] qsv.c: making qsv session routines Hopefully this is the correct way to share internal functions between codecs and filters. At least other filters seems to do it this way ... Thanks, Sven 0001-make-qsv-functions-avpriv.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mov: always enable parsing for mp3
The heuristic for enabling it is not very reliable. Even if always
parsing should cause problems in some cases, it would be better to
fix the parser instead. (But no bad samples are known to me.)
Fixes trac 5047
---
libavformat/mov.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index cee037b..c6009cf 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3143,13 +3143,9 @@ static int mov_read_trak(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
break;
}
-// If the duration of the mp3 packets is not constant, then they could
need a parser
-if (st->codec->codec_id == AV_CODEC_ID_MP3
-&& sc->stts_count > 3
-&& sc->stts_count*10 > st->nb_frames
-&& sc->time_scale == st->codec->sample_rate) {
+if (st->codec->codec_id == AV_CODEC_ID_MP3)
st->need_parsing = AVSTREAM_PARSE_FULL;
-}
+
/* Do not need those anymore. */
av_freep(&sc->chunk_offsets);
av_freep(&sc->stsc_data);
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/crc: avoid needless space wastage of hardcoded crc table
On Sun, 29 Nov 2015 23:58:16 -0300
James Almer wrote:
> On 11/29/2015 11:45 PM, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sun, Nov 29, 2015 at 9:41 PM, Ganesh Ajjanagadde
> > wrote:
> >
> >> There was no reason AFAIK for making AV_CRC_24_IEEE 12. This simply
> >> resulted in wasted space under --enable-hardcoded-tables:
> >> dynamic: 1318672 libavutil/libavutil.so.55
> >> old: 1330680 libavutil/libavutil.so.55
> >> new: 1326488 libavutil/libavutil.so.55
> >>
> >> Minor version number is bumped.
> >>
> >> Signed-off-by: Ganesh Ajjanagadde
> >> ---
> >> libavutil/crc.h | 2 +-
> >> libavutil/version.h | 2 +-
> >> 2 files changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavutil/crc.h b/libavutil/crc.h
> >> index e86bf1d..61592df 100644
> >> --- a/libavutil/crc.h
> >> +++ b/libavutil/crc.h
> >> @@ -40,7 +40,7 @@ typedef enum {
> >> AV_CRC_32_IEEE,
> >> AV_CRC_32_IEEE_LE, /*< reversed bitorder version of AV_CRC_32_IEEE */
> >> AV_CRC_16_ANSI_LE, /*< reversed bitorder version of AV_CRC_16_ANSI */
> >> -AV_CRC_24_IEEE = 12,
> >> +AV_CRC_24_IEEE,
> >> AV_CRC_MAX, /*< Not part of public API! Do not use outside
> >> libavutil. */
> >> }AVCRCId;
> >
> >
> > I support the idea, but this breaks ABI. You need to do this under a
> > version bump, see libavutil/version.h for templates.
>
> One could argue no releases have been made since the last major bump, so
> breakages
> like this are unlikely to affect anyone. But then again, it's been months
> since said
> major bump.
> What's been chosen in previous bumps as the drawing line for ABI breakages?
> Some
> arbitrary amount of time after the last bump (like the month mentioned in
> APIChanges),
> or first release post bump?
Yes, I guess the phase for arbitrary ABI changes after a major bump
might be over.
There's apparently no reason to keep ABI compatibility within git. It's
the development tree after all, and for those who need ABI compat, we
have releases.
But it has been argued that keeping ABI compat makes ti easier to
cherry-pick patches into the release trees.
If we decide to allow breaking ABI in git is ok (maybe clearly
expressed in the commit message to avoid accidents), then I'd say the
major version numbers should be bumped after every major release.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 04/10] avfilter/af_compand: use hypot()
On 11/22/15, Ganesh Ajjanagadde wrote: > Signed-off-by: Ganesh Ajjanagadde > --- > libavfilter/af_compand.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavfilter/af_compand.c b/libavfilter/af_compand.c > index 3848d67..a64778e 100644 > --- a/libavfilter/af_compand.c > +++ b/libavfilter/af_compand.c > @@ -467,13 +467,13 @@ static int config_output(AVFilterLink *outlink) > L(2).b = (L(0).y - L(2).y) / (L(0).x - L(2).x); > > theta = atan2(L(2).y - L(4).y, L(2).x - L(4).x); > -len = sqrt(pow(L(2).x - L(4).x, 2.) + pow(L(2).y - L(4).y, 2.)); > +len = hypot(L(2).x - L(4).x, L(2).y - L(4).y); > r = FFMIN(radius, len); > L(3).x = L(2).x - r * cos(theta); > L(3).y = L(2).y - r * sin(theta); > > theta = atan2(L(0).y - L(2).y, L(0).x - L(2).x); > -len = sqrt(pow(L(0).x - L(2).x, 2.) + pow(L(0).y - L(2).y, 2.)); > +len = hypot(L(0).x - L(2).x, L(0).y - L(2).y); > r = FFMIN(radius, len / 2); > x = L(2).x + r * cos(theta); > y = L(2).y + r * sin(theta); > -- > 2.6.2 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ok ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
