Re: [FFmpeg-devel] [PATCH] lavc/mediacodecdec_h264: add missing NAL headers to SPS/PPS buffers
On Tue, Jun 28, 2016 at 12:31:33PM +0200, Matthieu Bouron wrote:
> From: Matthieu Bouron
>
> Fixes regression introduced by 0cd5e281df3f69c1ed8f2a72a5bcbf9691e1b5d5.
> ---
> libavcodec/mediacodecdec_h264.c | 21 +++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/mediacodecdec_h264.c b/libavcodec/mediacodecdec_h264.c
> index eb63ab5..3776b67 100644
> --- a/libavcodec/mediacodecdec_h264.c
> +++ b/libavcodec/mediacodecdec_h264.c
> @@ -112,8 +112,25 @@ static av_cold int mediacodec_decode_init(AVCodecContext
> *avctx)
> }
>
> if (pps && sps) {
> -ff_AMediaFormat_setBuffer(format, "csd-0", (void*)sps->data,
> sps->data_size);
> -ff_AMediaFormat_setBuffer(format, "csd-1", (void*)pps->data,
> pps->data_size);
> +uint8_t nal_headers[] = { 0x00, 0x00, 0x00, 0x01 };
> +
> +uint8_t *data = NULL;
> +size_t data_size = FFMAX(sps->data_size, pps->data_size) +
> sizeof(nal_headers);
> +
> +data = av_mallocz(data_size);
> +if (!data) {
> +ret = AVERROR(ENOMEM);
> +goto done;
> +}
> +
> +memcpy(data, nal_headers, sizeof(nal_headers));
> +memcpy(data + sizeof(nal_headers), sps->data, sps->data_size);
> +ff_AMediaFormat_setBuffer(format, "csd-0", (void*)data,
> sps->data_size + sizeof(nal_headers));
> +
> +memcpy(data + sizeof(nal_headers), pps->data, pps->data_size);
> +ff_AMediaFormat_setBuffer(format, "csd-1", (void*)data,
> pps->data_size + sizeof(nal_headers));
> +
> +av_freep(&data);
> } else {
> av_log(avctx, AV_LOG_ERROR, "Could not extract PPS/SPS from
> extradata");
> ret = AVERROR_INVALIDDATA;
Pushed to master and release/3.1 branch a slightly different version
(which adds static const to the nal_headers declaration).
To bring more context, the regression introduced by
0cd5e281df3f69c1ed8f2a72a5bcbf9691e1b5d5 prevented the decoders of Samsung
devices to work.
Matthieu
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/drawutils: change to support native endian only
On Tue, Jun 28, 2016 at 5:45 PM, Michael Niedermayer wrote: > On Tue, Jun 28, 2016 at 04:07:31PM +0700, Muhammad Faiz wrote: >> On Mon, Jun 27, 2016 at 6:02 PM, Michael Niedermayer >> wrote: >> > On Mon, Jun 27, 2016 at 04:46:16PM +0700, Muhammad Faiz wrote: >> >> previously support little endian only because of fate problem >> >> generally native endian code is faster >> >> >> >> require 'tests/fate-run: support both le/be formats on pixfmts' >> >> need someone tests it on BE machine >> >> >> >> Signed-off-by: Muhammad Faiz >> >> --- >> >> libavfilter/drawutils.c | 43 -- >> >> libavfilter/vf_lut.c| 81 >> >> + >> >> 2 files changed, 62 insertions(+), 62 deletions(-) >> > >> > breaks fate on big endian (mips) >> > >> > Test filter-pixfmts-pad failed. Look at >> > tests/data/fate/filter-pixfmts-pad.err for details. >> > make: *** [fate-filter-pixfmts-pad] Error 1 >> > make: *** Waiting for unfinished jobs >> > --- tests/ref/fate/filter-pixfmts-lut 2016-06-26 18:25:32.960458744 +0200 >> > +++ tests/data/fate/filter-pixfmts-lut 2016-06-27 12:48:19.049852682 +0200 >> > @@ -3,38 +3,38 @@ >> > bgr24 fa43e3b2abfde8d9e60e157a9acc553d >> > bgra4e2e689897ee7a8e42b16234597bab35 >> > rgb24 a356171207723a580e7d277078072005 >> > -rgb48le 5c7dd8575836d18c91e09f1915cf9aa9 >> > +rgb48be d9a7669cab9159c7f28dc92387fab304 >> > rgba7bc854c2698b78af3e9159a19c2d9d21 >> > -rgba64le3a087ecab583d1930220592731f282b4 >> > +rgba64be612546f91b274bcc8c314386ba410c3d >> > yuv410p 51b39a0e33f108e652457a26667319ea >> > yuv411p 9204c5af92aef4922a05f58c1f6c095e >> > yuv420p 7c43bb0cae8dee633375c89295598508 >> > -yuv420p10le 1352712dd31cce78bd5441294004cf85 >> > -yuv420p12le c66f82da9fda458ba3abda057c58e591 >> > -yuv420p14le e45cb5e2a75bf6143da0b55004767f78 >> > -yuv420p16le eff54782c51770edfd6b84c958ac7120 >> > -yuv420p9le 4a6776b3379f12ad45caee8072a13695 >> > +yuv420p10be 4ef2f621258d77ef242e37e39b636f7c >> > +yuv420p12be bfb9f581c3749fd102f5bbd2065ad67a >> > +yuv420p14be 999d29d713e52f61a5eea1765c57e660 >> > +yuv420p16be a8ff20f5a96ba42fa5968bda64e160bd >> > +yuv420p9be 862db8509f9cbaa7fd542851047a50fc >> > yuv422p 67df35da0c35e54882492b2365438254 >> > -yuv422p10le 0158371a800294015def7f0ef66c78ea >> > -yuv422p12le bc49d3863ffb89658a17bf8c4fe773b0 >> > -yuv422p14le b55cb791d286b0b3391fe7481785e5b3 >> > -yuv422p16le fc3b2ba889ffaf1633000fc774307c33 >> > -yuv422p9le 6e2a42ae36ed5e8b5112987639728af5 >> > +yuv422p10be 384f3f8757ecdcb87e0f5225f92ee244 >> > +yuv422p12be b6bac207d387098f22b2f3613d668d30 >> > +yuv422p14be 48b83f5ecc7931cbab467801934bbf87 >> > +yuv422p16be be0db4de9820408fd6770cdcea0535f9 >> > +yuv422p9be f2486947acf0e98977cbec23c79871b3 >> > yuv440p 5e41adcfc27be4369afd217b61b2ffe3 >> > -yuv440p10le 8b49714bba268fb4a79b5a84223ad17a >> > -yuv440p12le 15ab4f453238bd9c13b18af81e22f060 >> > +yuv440p10be cbcbbbdbe4a1dc041bee11b757be89d7 >> > +yuv440p12be 7603fda62bd9cb383e7d82af0bf5fefd >> > yuv444p a2b58590aef88db2c1f14a1a3a3b0359 >> > -yuv444p10le c076c20fc808f95b34adb88aca442f48 >> > -yuv444p12le af8d4dd88169d5cffc2f3fce6333a94c >> > -yuv444p14le 93367133e25d088d4535199ed1f1ed58 >> > -yuv444p16le 800940feec14365ccd9b4863e38f6991 >> > -yuv444p9le c120044350852c4cd16a302dd1ceda79 >> > +yuv444p10be a3481fe5e95190749f2ac3288ad686c3 >> > +yuv444p12be 118c1d1f8270cebec8554972adde05da >> > +yuv444p14be 6671cff7f64e9f9bc1dceb3d31a69c00 >> > +yuv444p16be 27effaa1096361ffb6b69d1d0e8a35d6 >> > +yuv444p9be dcd44e88c9424d5666ac950f4e3e19e4 >> > yuva420p518a380bf1af60ef2ecf4754eec088e9 >> > -yuva420p16le72ad4fa535b007d122666ce103ef9c8b >> > +yuva420p16beaaa6db0ce07716dab15782dfbad5aca9 >> > yuva422p7110ac2e37377b05b6fc5ad967dfabb5 >> > -yuva422p16lee2867210660ada5784a60b4339ac52c0 >> > +yuva422p16bef5c06d197a1096314553b1d89f43d96f >> > yuva444p642f3958f141dece9e99407945e2ef43 >> > -yuva444p16leab04ba8acbe38085b0df650d82065eb0 >> > +yuva444p16be5337a7c64bd26a675d4a2bb8881e6fcb >> > yuvj420p65bc7c7f06a6221155ca7f9cfca4 >> > yuvj422pff5baffefc8ffe4547653092fd7da200 >> > yuvj440pef3f27270e60ac06582e3ac7c2f3e6fa >> >> Did you apply 'tests/fate-run: support both le/be formats on pixfmts' first? > > i forgot the 2nd patch > but it doesnt work with it either: > > --- /home/michael/ffmpeg-git/ffmpeg/tests/ref/fate/filter-pixfmts-pad > 2016-06-28 11:55:47.679606503 +0200 > +++ t
Re: [FFmpeg-devel] [PATCH] tests/fate-run: support both le/be formats on pixfmts
On Mon, Jun 27, 2016 at 3:53 PM, Muhammad Faiz wrote:
> On Mon, Jun 27, 2016 at 3:28 PM, Hendrik Leppkes wrote:
>> On Mon, Jun 27, 2016 at 10:12 AM, Muhammad Faiz wrote:
>>> On Mon, Jun 27, 2016 at 2:59 PM, Hendrik Leppkes
>>> wrote:
On Mon, Jun 27, 2016 at 9:52 AM, Muhammad Faiz wrote:
> regardless of the actual supported formats of tested filters
> allowing filters to support only native endian formats
>
> Signed-off-by: Muhammad Faiz
> ---
> tests/fate-run.sh | 7 ++-
> tests/ref/fate/filter-pixfmts-lut | 22 ++
> tests/ref/fate/filter-pixfmts-pad | 32
> 3 files changed, 60 insertions(+), 1 deletion(-)
>
> diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> index c898695..066970c 100755
> --- a/tests/fate-run.sh
> +++ b/tests/fate-run.sh
> @@ -232,7 +232,12 @@ pixfmts(){
> $showfiltfmts scale | awk -F '[ \r]' '/^OUTPUT/{ fmt=substr($3, 5);
> print fmt }' | sort >$scale_out_fmts
> comm -12 $scale_in_fmts $scale_out_fmts >$scale_exclude_fmts
>
> -$showfiltfmts $filter | awk -F '[ \r]' '/^INPUT/{ fmt=substr($3, 5);
> print fmt }' | sort >$in_fmts
> +$showfiltfmts $filter | awk -F '[ \r]' \
> +'/^INPUT/{ fmt=substr($3, 5);
> +print fmt;
> +print gensub(/(be)$/, "le", "g", fmt);
> +print gensub(/(le)$/, "be", "g", fmt);
> +}' | sort >$in_fmts
> pix_fmts=$(comm -12 $scale_exclude_fmts $in_fmts)
>
This doesn't really test anything new, does it?
Just adds one more scaling step to convert endianness for some filters.
>>>
>>> No, it doesn't of course.
>>> Just for example: a filter support yuv420p10le on LE machine,
>>> yuv420p10be on BE machine
>>> fate will test both yuv420p10le/yuv420p10be
>>
>> I would argue it doesn't add anything then but extra runtime, unless
>> I'm missing something.
>> The endian conversion is lossless, so even if we test LE on a BE
>> system the result is still accurate.
>
> Yes, It will be slower. But, in case of filters that support both le/be,
> this is required. Checking whether a filter supports native only or
> supports both
> isn't trivial (for me).
>
> Another nice feature is that if someone decides to support
> both le/be, the fate-ref already exists.
>
> Thank's
Need someone test this on BE machine
Thank's
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] ffplay: Fix usage of private lavfi API
--- ffplay.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ffplay.c b/ffplay.c index f28e087..b0702eb 100644 --- a/ffplay.c +++ b/ffplay.c @@ -2725,7 +2725,7 @@ static int stream_component_open(VideoState *is, int stream_index) goto fail; link = is->out_audio_filter->inputs[0]; sample_rate= link->sample_rate; -nb_channels= link->channels; +nb_channels= avfilter_link_get_channels(link); channel_layout = link->channel_layout; } #else -- 2.9.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/3] Correct (non-public) ABI breakage since 3.0
The field in AVFilterLink is private, but a lot of applications, ffplay included, still accessed some of them. So this series first fixes ffplay, and then moves the new fields in AVFilterLink and AVFilterContext to the end of their structs. For AVFilterLink this should be unproblematic, as it's private API. It only makes it so that updating to a future 3.1.1 with these fixes included does not break applications linked against 3.0. The field in AVFilterContext is a bit more problematic. It is not marked as private, and should never have been added in the middle of the struct in the first place. Moving it now _will_ break ffmpeg/ffplay from 3.1.0 linked against the updated libraries. Nothing external seems to be accessing the fields after the hw_device_ctx, so it's more then questionable if it should be moved. Timo Rothenpieler (3): ffplay: Fix usage of private lavfi API lavfi: Move new field to the end of AVFilterLink lavfi: Move new field to the end of AVFilterContext ffplay.c | 2 +- libavfilter/avfilter.h | 26 +- 2 files changed, 14 insertions(+), 14 deletions(-) -- 2.9.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] lavfi: Move new field to the end of AVFilterContext
---
libavfilter/avfilter.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
index 8a7f791..757b81a 100644
--- a/libavfilter/avfilter.h
+++ b/libavfilter/avfilter.h
@@ -344,6 +344,13 @@ struct AVFilterContext {
*/
AVFilterInternal *internal;
+struct AVFilterCommand *command_queue;
+
+char *enable_str; ///< enable expression string
+void *enable; ///< parsed expression (AVExpr*)
+double *var_values; ///< variable values for the enable
expression
+int is_disabled;///< the enabled state from the last
expression evaluation
+
/**
* For filters which will create hardware frames, sets the device the
* filter should create them in. All other filters will ignore this field:
@@ -352,13 +359,6 @@ struct AVFilterContext {
* hardware context information.
*/
AVBufferRef *hw_device_ctx;
-
-struct AVFilterCommand *command_queue;
-
-char *enable_str; ///< enable expression string
-void *enable; ///< parsed expression (AVExpr*)
-double *var_values; ///< variable values for the enable
expression
-int is_disabled;///< the enabled state from the last
expression evaluation
};
/**
--
2.9.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] lavfi: Move new field to the end of AVFilterLink
Even though this is not part of the public API, some external
applications access fields after it, thus breaking after updating from
ffmpeg 3.0 or earlier.
Since it is not public, it can be freely moved to the end to avoid
that problem in the future.
---
libavfilter/avfilter.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
index 79227a7..8a7f791 100644
--- a/libavfilter/avfilter.h
+++ b/libavfilter/avfilter.h
@@ -474,12 +474,6 @@ struct AVFilterLink {
AVRational frame_rate;
/**
- * For hwaccel pixel formats, this should be a reference to the
- * AVHWFramesContext describing the frames.
- */
-AVBufferRef *hw_frames_ctx;
-
-/**
* Buffer partially filled with samples to achieve a fixed/minimum size.
*/
AVFrame *partial_buf;
@@ -550,6 +544,12 @@ struct AVFilterLink {
* cleared when a frame is filtered.
*/
int frame_wanted_out;
+
+/**
+ * For hwaccel pixel formats, this should be a reference to the
+ * AVHWFramesContext describing the frames.
+ */
+AVBufferRef *hw_frames_ctx;
};
/**
--
2.9.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] lavfi: Move new field to the end of AVFilterLink
On Wed, Jun 29, 2016 at 11:58:02AM +0200, Timo Rothenpieler wrote: > Even though this is not part of the public API, some external > applications access fields after it, thus breaking after updating from > ffmpeg 3.0 or earlier. > Since it is not public, it can be freely moved to the end to avoid > that problem in the future. > --- > libavfilter/avfilter.h | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) LGTM please also backport to release/3.1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] ffplay: Fix usage of private lavfi API
On Wed, Jun 29, 2016 at 11:58:01AM +0200, Timo Rothenpieler wrote: > --- > ffplay.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM also please backport to release/3.1 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] lavfi: Move new field to the end of AVFilterContext
On Wed, Jun 29, 2016 at 11:58:03AM +0200, Timo Rothenpieler wrote: > --- > libavfilter/avfilter.h | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) This has to be documented in APIChanges i think [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] fate/webp : add test to improve cover of lossless
Hello, in attach patch to add a new test for lossless webp one with direct decoding argb the second with rgb24 pix_fmt. the crc of this test is the same than the CRC of the sample lena-rgb24 of png tests. sample can be found here : https://we.tl/XA18TMKjzg and need to be put inside ./fate-suite/webp this sample add cover for theses functions of the webp decoder : parse_transform_predictor parse_transform_color apply_color_transform apply_predictor_transform apply_subtract_green_transform decode_entropy_image Martin Jokyo Images From f9f310cd5c1beaaf4f326a5f8a4c132e088d0a38 Mon Sep 17 00:00:00 2001 From: Martin Vignali Date: Wed, 29 Jun 2016 12:41:11 +0200 Subject: [PATCH] fate/webp : add test for lossless picture to improve cover --- tests/fate/image.mak| 6 ++ tests/ref/fate/webp-rgb-lena-lossless | 6 ++ tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 6 ++ 3 files changed, 18 insertions(+) create mode 100644 tests/ref/fate/webp-rgb-lena-lossless create mode 100644 tests/ref/fate/webp-rgb-lena-lossless-rgb24 diff --git a/tests/fate/image.mak b/tests/fate/image.mak index dab982f..500da48 100644 --- a/tests/fate/image.mak +++ b/tests/fate/image.mak @@ -358,6 +358,12 @@ fate-tiff: $(FATE_TIFF-yes) FATE_WEBP += fate-webp-rgb-lossless fate-webp-rgb-lossless: CMD = framecrc -i $(TARGET_SAMPLES)/webp/rgb_lossless.webp +FATE_WEBP += fate-webp-rgb-lena-lossless +fate-webp-rgb-lena-lossless: CMD = framecrc -i $(TARGET_SAMPLES)/webp/rgb_lena_lossless.webp + +FATE_WEBP += fate-webp-rgb-lena-lossless-rgb24 +fate-webp-rgb-lena-lossless-rgb24: CMD = framecrc -i $(TARGET_SAMPLES)/webp/rgb_lena_lossless.webp -pix_fmt rgb24 + FATE_WEBP += fate-webp-rgba-lossless fate-webp-rgba-lossless: CMD = framecrc -i $(TARGET_SAMPLES)/webp/rgba_lossless.webp diff --git a/tests/ref/fate/webp-rgb-lena-lossless b/tests/ref/fate/webp-rgb-lena-lossless new file mode 100644 index 000..c00715a --- /dev/null +++ b/tests/ref/fate/webp-rgb-lena-lossless @@ -0,0 +1,6 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 128x128 +#sar 0: 0/1 +0, 0, 0,1,65536, 0xdfcd01ae diff --git a/tests/ref/fate/webp-rgb-lena-lossless-rgb24 b/tests/ref/fate/webp-rgb-lena-lossless-rgb24 new file mode 100644 index 000..7f8f550 --- /dev/null +++ b/tests/ref/fate/webp-rgb-lena-lossless-rgb24 @@ -0,0 +1,6 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 128x128 +#sar 0: 0/1 +0, 0, 0,1,49152, 0xe0013dee -- 1.9.3 (Apple Git-50) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/h264_slice: move au_pps_id and current_sps_id assignment earlier
From: Clément Bœsch
This will simplify the next merge commit from Libav.
---
libavcodec/h264_slice.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 474400b..0b5079c 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1202,6 +1202,9 @@ int ff_h264_decode_slice_header(H264Context *h,
H264SliceContext *sl)
pps = h->ps.pps;
sps = h->ps.sps;
+h->au_pps_id = pps_id;
+h->current_sps_id = h->ps.pps->sps_id;
+
must_reinit = (h->context_initialized &&
( 16*sps->mb_width != h->avctx->coded_width
|| 16*sps->mb_height * (2 - sps->frame_mbs_only_flag) !=
h->avctx->coded_height
@@ -1782,9 +1785,6 @@ int ff_h264_decode_slice_header(H264Context *h,
H264SliceContext *sl)
(sl->ref_list[j][i].reference & 3);
}
-h->au_pps_id = pps_id;
-h->current_sps_id = h->ps.pps->sps_id;
-
if (h->avctx->debug & FF_DEBUG_PICT_INFO) {
av_log(h->avctx, AV_LOG_DEBUG,
"slice:%d %s mb:%d %c%s%s pps:%u frame:%d poc:%d/%d ref:%d/%d
qp:%d loop:%d:%d:%d weight:%d%s %s\n",
--
2.9.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] how to download specific track data of a m3u8 content?
thanks, seems the right clue to follow. I don't know much about ffmpeg, after went through avplay.c. I think I should do the following steps 1. discard all stream by default. refer to decode_thread() for (i = 0; i < ic->nb_streams; i++) ic->streams[i]->discard = AVDISCARD_ALL; 2. enable the desired stream only refer to stream_component_open() ic->streams[stream_index]->discard = AVDISCARD_DEFAULT; thanks for your help. 2016-06-29 10:01 GMT+08:00 Steven Liu : > 2016-06-29 8:36 GMT+08:00 aihua zhao : > > > thanks. > > > > Yes, readahead the list is must. > > but during playback, I found ffmpeg downloads each content of the list > > -- av_read_frame() returns me each content with different stream_index. > > I'm expecting av_read_frame() returns me the interested stream only. > > I haven't found a way to do so; or said, is there ffmpeg interface to > > specify a dedicate stream (stream_index) to download. > > > > i'm looking into hls.c; there is recheck_discard_flags(), seems it is > > designed to do some policy like this. > > but I haven't found one top level interface of ffmpeg for it. > > recheck_discard_flags() is called once only during hls_read_packet() when > > c->first_packet is set -- this flag is set in hls_read_header() only. > > > > > > 2016-06-28 22:22 GMT+08:00 Steven Liu : > > > > > 2016-06-28 14:26 GMT+08:00 aihua zhao : > > > > > > > Hi Experts: > > > > > > > > I use ffmpeg to parse/demux media content, and created a player > basing > > on > > > > it. > > > > > > > > here is a m3u8 content: > > > > > > > > > > > > > > http://asp.cntv.lxdns.com/asp/hls/main/0303000a/3/default/438eb7a818b246c187e72f1cd4e1bc4c/main.m3u8 > > > > < > > > > > > > > > > http://asp.cntv.lxdns.com/asp/hls/main/0303000a/3/default/438eb7a818b246c187e72f1cd4e1bc4c/main.m3u8?maxbr=1200 > > > > > > > > > there are three video track in it. > > > > > > > > I found all video/audio tracks are downloaded during playback, and I > > can > > > > switch different track on the fly. > > > > however, it consumes much bandwidth since all tracks are downloaded. > > > > > > > > even when I append bandwidth to the url; still the same result: > > > > > > > > > > > > > > http://asp.cntv.lxdns.com/asp/hls/main/0303000a/3/default/438eb7a818b246c187e72f1cd4e1bc4c/main.m3u8?maxbr=1200 > > > > > > > > Is there any way to download the specified track only to save > > bandwidth? > > > > > > > > thanks > > > > > > > > > > Hi Aihua Zhao, > > > > > > If you haven't read the m3u8 file and parse the playlist, and > read > > > the sub m3u8 playlist, how do you get the info of the mpegts? > > > > > > So it's must readahead the list and list all of the track for > > choose. > > you mean the function looks like "stream_cycle_channel" in ffplay? > > > ___ > 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] lavc/h264_slice: move au_pps_id and current_sps_id assignment earlier
On Wed, Jun 29, 2016 at 12:52:18PM +0200, Clément Bœsch wrote:
> From: Clément Bœsch
>
> This will simplify the next merge commit from Libav.
> ---
> libavcodec/h264_slice.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
all files i tried still work with this patch
they also all work if i remove both fields entirely
as in:
commit 14492a72ca13f31a816e97481d9989a6ac6c792f
Author: Michael Niedermayer
Date: Wed Jun 29 13:37:02 2016 +0200
remove au pps
Signed-off-by: Michael Niedermayer
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index f7239ea..8206753 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1139,12 +1139,6 @@ int ff_h264_decode_slice_header(H264Context *h,
H264SliceContext *sl)
pps_id);
return AVERROR_INVALIDDATA;
}
-if (h->au_pps_id >= 0 && pps_id != h->au_pps_id) {
-av_log(h->avctx, AV_LOG_ERROR,
- "PPS change from %d to %d forbidden\n",
- h->au_pps_id, pps_id);
-return AVERROR_INVALIDDATA;
-}
pps = (const PPS*)h->ps.pps_list[pps_id]->data;
@@ -1201,7 +1195,7 @@ int ff_h264_decode_slice_header(H264Context *h,
H264SliceContext *sl)
pps = h->ps.pps;
sps = h->ps.sps;
-h->au_pps_id = pps_id;
+
must_reinit = (h->context_initialized &&
( 16*sps->mb_width != h->avctx->coded_width
commit e08fcc0c7e227bf2d42ebeb4b5c797bd39d8a6ce
Author: Michael Niedermayer
Date: Wed Jun 29 13:36:15 2016 +0200
remvoe current_sps_id
Signed-off-by: Michael Niedermayer
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 0b5079c..f7239ea 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1171,8 +1171,7 @@ int ff_h264_decode_slice_header(H264Context *h,
H264SliceContext *sl)
}
}
-if (h->ps.sps != (const SPS*)h->ps.sps_list[h->ps.pps->sps_id]->data ||
-pps->sps_id != h->current_sps_id) {
+if (h->ps.sps != (const SPS*)h->ps.sps_list[h->ps.pps->sps_id]->data) {
if (!first_slice) {
av_log(h->avctx, AV_LOG_ERROR,
@@ -1203,7 +1202,6 @@ int ff_h264_decode_slice_header(H264Context *h,
H264SliceContext *sl)
sps = h->ps.sps;
h->au_pps_id = pps_id;
-h->current_sps_id = h->ps.pps->sps_id;
must_reinit = (h->context_initialized &&
( 16*sps->mb_width != h->avctx->coded_width
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/h264_slice: move au_pps_id and current_sps_id assignment earlier
On Wed, Jun 29, 2016 at 01:56:25PM +0200, Michael Niedermayer wrote: > On Wed, Jun 29, 2016 at 12:52:18PM +0200, Clément Bœsch wrote: > > From: Clément Bœsch > > > > This will simplify the next merge commit from Libav. > > --- > > libavcodec/h264_slice.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > all files i tried still work with this patch > they also all work if i remove both fields entirely > as in: > So the security relevant samples do not cause harm anymore? If so then please apply these patches (with the removal of the field in the context) -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] lavfi: Move new field to the end of AVFilterContext
> This has to be documented in APIChanges i think Adding that field was documented there originally. It came in as a merge from libav in 8688d3a, and should have been merged to the end of the struct there. Technically it was an ABI break, but nothing seems to be affected by it. So I'm not exactly sure what to do about it. Moving it to the end now will break ffmpeg/ffplay built from 3.1.0 or current master when using libraries from 3.1.1 or post-merge master. It might be better to fix this now before 3.1 gains wider adoption, maybe releasing 3.1.1 or even 3.1.0.1 a bit ahead of schedule. Does it still need an APIChanges entry, even though the addition was already documented there and this is an ABI-Only change? signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/h264_slice: move au_pps_id and current_sps_id assignment earlier
On Wed, Jun 29, 2016 at 02:00:32PM +0200, Clément Bœsch wrote: > On Wed, Jun 29, 2016 at 01:56:25PM +0200, Michael Niedermayer wrote: > > On Wed, Jun 29, 2016 at 12:52:18PM +0200, Clément Bœsch wrote: > > > From: Clément Bœsch > > > > > > This will simplify the next merge commit from Libav. > > > --- > > > libavcodec/h264_slice.c | 6 +++--- > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > all files i tried still work with this patch > > they also all work if i remove both fields entirely > > as in: > > > > So the security relevant samples do not cause harm anymore? > > If so then please apply these patches (with the removal of the field in > the context) done [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] lavfi: Move new field to the end of AVFilterContext
On Wed, Jun 29, 2016 at 02:43:52PM +0200, Timo Rothenpieler wrote: > > This has to be documented in APIChanges i think > > Adding that field was documented there originally. > It came in as a merge from libav in 8688d3a, and should have been merged > to the end of the struct there. > Technically it was an ABI break, but nothing seems to be affected by it. > > So I'm not exactly sure what to do about it. > Moving it to the end now will break ffmpeg/ffplay built from 3.1.0 or > current master when using libraries from 3.1.1 or post-merge master. > > It might be better to fix this now before 3.1 gains wider adoption, > maybe releasing 3.1.1 or even 3.1.0.1 a bit ahead of schedule. > > Does it still need an APIChanges entry, even though the addition was > already documented there and this is an ABI-Only change? the pragmatic choice is certainly to document it somewhere Distribution package maintainers who did package 3.1 need to know there is a ABI fix in 3.1.1 so they can set depends & conflicts accordingly, what they need to do is to make sure ffmpeg/ffplay 3.1 conflicts with libavfilter from 3.1.1 The ABI was defined by 3.0 and 3.1 should not have broken that, no matter how slightly [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavfi: Move new field to the end of AVFilterContext
This fixes an accidental ABI break introduced at 8688d3a.
---
doc/APIchanges | 8
libavfilter/avfilter.h | 14 +++---
libavfilter/version.h | 4 ++--
3 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 6dd5ad7..47106c2 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,14 @@ libavutil: 2015-08-28
API changes, most recent first:
+2016-06-29 - xxx - lavfi 6.47.100 - avfilter.h
+ Fix accidental ABI breakage in AVFilterContext.
+ ABI was broken in 8688d3a, lavfi 6.42.100 and released as ffmpeg 3.1.
+
+ Because of this, ffmpeg and ffplay built against lavfi>=6.42.100 will not be
+ compatible with lavfi>=6.47.100. Potentially also affects other users of
+ libavfilter if they are using one of the affected fields.
+
8< - FFmpeg 3.1 was cut here 8< -
2016-06-26 - 481f320 / 1c9e861 - lavu 55.27.100 / 55.13.0 - hwcontext.h
diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
index 8a7f791..757b81a 100644
--- a/libavfilter/avfilter.h
+++ b/libavfilter/avfilter.h
@@ -344,6 +344,13 @@ struct AVFilterContext {
*/
AVFilterInternal *internal;
+struct AVFilterCommand *command_queue;
+
+char *enable_str; ///< enable expression string
+void *enable; ///< parsed expression (AVExpr*)
+double *var_values; ///< variable values for the enable
expression
+int is_disabled;///< the enabled state from the last
expression evaluation
+
/**
* For filters which will create hardware frames, sets the device the
* filter should create them in. All other filters will ignore this field:
@@ -352,13 +359,6 @@ struct AVFilterContext {
* hardware context information.
*/
AVBufferRef *hw_device_ctx;
-
-struct AVFilterCommand *command_queue;
-
-char *enable_str; ///< enable expression string
-void *enable; ///< parsed expression (AVExpr*)
-double *var_values; ///< variable values for the enable
expression
-int is_disabled;///< the enabled state from the last
expression evaluation
};
/**
diff --git a/libavfilter/version.h b/libavfilter/version.h
index 1924cfe..6d56dad 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -30,8 +30,8 @@
#include "libavutil/version.h"
#define LIBAVFILTER_VERSION_MAJOR 6
-#define LIBAVFILTER_VERSION_MINOR 46
-#define LIBAVFILTER_VERSION_MICRO 102
+#define LIBAVFILTER_VERSION_MINOR 47
+#define LIBAVFILTER_VERSION_MICRO 100
#define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
LIBAVFILTER_VERSION_MINOR, \
--
2.9.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Changed metadata print option to accept general urls
From: Sami Hult
NOTE
This is a new patch against the latest master branch. It fixes an error in code
where "file:-" was directed to file descriptor 2 instead of 1.
I changed mode=print file handling of metadata filter to accept any ffmpeg url.
This way multiple streams can for example be silencedetected and the result
directed to different outputs.
Example:
ffmpeg -i test.wav -filter_complex
"silencedetect=n=-40dB:d=0.1,ametadata=mode=print:file='pipe\:4'" -f null â
4> test.txt
has the same effect as
ffmpeg -i test.wav -filter_complex
"silencedetect=n=-40dB:d=0.1,ametadata=mode=print:file=test.txt" -f null â
Signed-off-by: Sami Hult
---
Changelog| 1 +
doc/filters.texi | 23 +--
libavfilter/f_metadata.c | 49
3 files changed, 47 insertions(+), 26 deletions(-)
diff --git a/Changelog b/Changelog
index 4a85925..8541091 100644
--- a/Changelog
+++ b/Changelog
@@ -48,6 +48,7 @@ version 3.1:
- 10-bit depth support in native utvideo decoder
- libutvideo wrapper removed
- YUY2 Lossless Codec decoder
+- Changed metadata print option to accept general urls
version 3.0:
diff --git a/doc/filters.texi b/doc/filters.texi
index 3cf3d7c..dba3a5c 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -9375,13 +9375,14 @@ Float representation of @code{value} from metadata key.
@item VALUE2
Float representation of @code{value} as supplied by user in @code{value}
option.
-@end table
@item file
-If specified in @code{print} mode, output is written to the named file. When
-filename equals "-" data is written to standard output.
-If @code{file} option is not set, output is written to the log with AV_LOG_INFO
-loglevel.
+If specified in @code{print} mode, output is written to the named file.
Instead of
+plain filename any writable url can be specified. Filename ``-'' is a shorthand
+for standard output. If @code{file} option is not set, output is written to
the log
+with AV_LOG_INFO loglevel.
+@end table
+
@end table
@subsection Examples
@@ -9391,8 +9392,18 @@ loglevel.
Print all metadata values for frames with key @code{lavfi.singnalstats.YDIF}
with values
between 0 and 1.
@example
-@end example
signalstats,metadata=print:key=lavfi.signalstats.YDIF:value=0:function=expr:expr='between(VALUE1,0,1)'
+@end example
+@item
+Print silencedetect output to file @file{metadata.txt}.
+@example
+silencedetect,ametadata=mode=print:file=metadata.txt
+@end example
+@item
+Direct all metadata to a pipe with file descriptor 4.
+@example
+metadata=mode=print:file='pipe\:4'
+@end example
@end itemize
@section mpdecimate
diff --git a/libavfilter/f_metadata.c b/libavfilter/f_metadata.c
index ab07ccf..cac2e93 100644
--- a/libavfilter/f_metadata.c
+++ b/libavfilter/f_metadata.c
@@ -31,6 +31,7 @@
#include "libavutil/internal.h"
#include "libavutil/opt.h"
#include "libavutil/timestamp.h"
+#include "libavformat/avio.h"
#include "avfilter.h"
#include "audio.h"
#include "formats.h"
@@ -80,7 +81,7 @@ typedef struct MetadataContext {
AVExpr *expr;
double var_values[VAR_VARS_NB];
-FILE *file;
+AVIOContext* avio_context;
char *file_str;
int (*compare)(struct MetadataContext *s,
@@ -180,8 +181,11 @@ static void print_file(AVFilterContext *ctx, const char
*msg, ...)
va_list argument_list;
va_start(argument_list, msg);
-if (msg)
-vfprintf(s->file, msg, argument_list);
+if (msg) {
+char buf[128];
+vsnprintf(buf, sizeof(buf), msg, argument_list);
+avio_put_str(s->avio_context, buf);
+}
va_end(argument_list);
}
@@ -236,25 +240,30 @@ static av_cold int init(AVFilterContext *ctx)
}
}
-if (s->file_str) {
-if (!strcmp(s->file_str, "-")) {
-s->file = stdout;
-} else {
-s->file = fopen(s->file_str, "w");
-if (!s->file) {
-int err = AVERROR(errno);
-char buf[128];
-av_strerror(err, buf, sizeof(buf));
-av_log(ctx, AV_LOG_ERROR, "Could not open file %s: %s\n",
- s->file_str, buf);
-return err;
-}
-}
+if (s->mode == METADATA_PRINT && s->file_str) {
s->print = print_file;
} else {
s->print = print_log;
}
+s->avio_context = NULL;
+if (s->file_str) {
+printf("Filename: %s", s->file_str);
+if (!strcmp("-", s->file_str)) {
+ret = avio_open(&s->avio_context, "pipe:1", AVIO_FLAG_WRITE);
+} else {
+ret = avio_open(&s->avio_context, s->file_str, AVIO_FLAG_WRITE);
+}
+
+if (ret < 0) {
+char buf[128];
+av_strerror(ret, buf, sizeof(buf));
+av_log(ctx, AV_LOG_ERROR, "Could not open %s: %s\n",
+ s->file_str, buf);
+return ret;
+}
+}
+
return 0;
}
@@ -262,9 +271,9 @@
Re: [FFmpeg-devel] [PATCH] lavfi: Move new field to the end of AVFilterContext
On Wed, Jun 29, 2016 at 03:24:22PM +0200, Timo Rothenpieler wrote: > This fixes an accidental ABI break introduced at 8688d3a. > --- > doc/APIchanges | 8 > libavfilter/avfilter.h | 14 +++--- > libavfilter/version.h | 4 ++-- > 3 files changed, 17 insertions(+), 9 deletions(-) should(1) be ok (as there was no version bump between 3.1 and master, otherwise it would be more tricky as we dont want 1 version to mean different things in master and 3.1) (1) Iam not sure APIchanges, RELEASE_NOTES or Changelog is the best place, iam fine with any of them ... [...] -- 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] lavfi: Move new field to the end of AVFilterContext
> (1) Iam not sure APIchanges, RELEASE_NOTES or Changelog is the best > place, iam fine with any of them ... APIchanges seems like the place where a distribution maintainer would most likely look for something like this to me. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fate/h264: add test for skip-nointra and skip-nokey
--- tests/fate/h264.mak |3 +++ tests/ref/fate/h264-skip-nointra | 54 ++ tests/ref/fate/h264-skip-nokey | 54 ++ 3 files changed, 111 insertions(+) create mode 100644 tests/ref/fate/h264-skip-nointra create mode 100644 tests/ref/fate/h264-skip-nokey diff --git a/tests/fate/h264.mak b/tests/fate/h264.mak index 4ae1305..9b388bb 100644 --- a/tests/fate/h264.mak +++ b/tests/fate/h264.mak @@ -209,6 +209,7 @@ FATE_H264-$(call DEMDEC, MATROSKA, H264) += fate-h264-direct-bff FATE_H264-$(call DEMDEC, FLV, H264) += fate-h264-brokensps-2580 FATE_H264-$(call DEMDEC, MXF, H264) += fate-h264-xavc-4389 FATE_H264-$(call DEMDEC, MOV, H264) += fate-h264-attachment-631 +FATE_H264-$(call DEMDEC, MPEGTS, H264) += fate-h264-skip-nokey fate-h264-skip-nointra FATE_H264_FFPROBE-$(call DEMDEC, MATROSKA, H264) += fate-h264-dts_5frames FATE_SAMPLES_AVCONV += $(FATE_H264-yes) @@ -412,6 +413,8 @@ fate-h264-direct-bff: CMD = framecrc -i $(TARGET_SAM fate-h264-brokensps-2580: CMD = framecrc -i $(TARGET_SAMPLES)/h264/brokensps.flv -vf format=yuv420p,scale=w=192:h=144 -sws_flags bitexact+bilinear fate-h264-xavc-4389: CMD = framecrc -i $(TARGET_SAMPLES)/h264/SonyXAVC_LongGOP_green_pixelation_early_Frames.MXF -pix_fmt yuv422p10le fate-h264-attachment-631: CMD = framecrc -i $(TARGET_SAMPLES)/h264/attachment631-small.mp4 -an -max_error_rate 0.95 +fate-h264-skip-nokey: CMD = framecrc -skip_frame nokey -i $(TARGET_SAMPLES)/h264/h264_intra_first-small.ts +fate-h264-skip-nointra: CMD = framecrc -skip_frame nointra -i $(TARGET_SAMPLES)/h264/h264_intra_first-small.ts fate-h264-invalid-ref-mod:CMD = framecrc -i $(TARGET_SAMPLES)/h264/h264refframeregression.mp4 -an -frames 10 -pix_fmt yuv420p10le fate-h264-unescaped-extradata:CMD = framecrc -i $(TARGET_SAMPLES)/h264/unescaped_extradata.mp4 -an -frames 10 diff --git a/tests/ref/fate/h264-skip-nointra b/tests/ref/fate/h264-skip-nointra new file mode 100644 index 000..40b5bb2 --- /dev/null +++ b/tests/ref/fate/h264-skip-nointra @@ -0,0 +1,54 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 1920x1080 +#sar 0: 1/1 +#tb 1: 1/48000 +#media_type 1: audio +#codec_id 1: pcm_s16le +#sample_rate 1: 48000 +#channel_layout 1: 3 +1, 0, 0, 1152, 4608, 0x +1, 1152, 1152, 1152, 4608, 0x +1, 2304, 2304, 1152, 4608, 0x +1, 3456, 3456, 1152, 4608, 0x +1, 4608, 4608, 1152, 4608, 0x +1, 5760, 5760, 1152, 4608, 0x +1, 6912, 6912, 1152, 4608, 0x +1, 8064, 8064, 1152, 4608, 0x +1, 9216, 9216, 1152, 4608, 0x +1, 10368, 10368, 1152, 4608, 0x +1, 11520, 11520, 1152, 4608, 0x +1, 12672, 12672, 1152, 4608, 0x +1, 13824, 13824, 1152, 4608, 0x +1, 14976, 14976, 1152, 4608, 0x +1, 16128, 16128, 1152, 4608, 0x +1, 17280, 17280, 1152, 4608, 0x +1, 18432, 18432, 1152, 4608, 0x +1, 19584, 19584, 1152, 4608, 0x +1, 20736, 20736, 1152, 4608, 0x +1, 21888, 21888, 1152, 4608, 0x +1, 23040, 23040, 1152, 4608, 0x +1, 24192, 24192, 1152, 4608, 0x +1, 25344, 25344, 1152, 4608, 0x +1, 26496, 26496, 1152, 4608, 0x +1, 27648, 27648, 1152, 4608, 0x +1, 28800, 28800, 1152, 4608, 0x +1, 29952, 29952, 1152, 4608, 0x +1, 31104, 31104, 1152, 4608, 0x +1, 32256, 32256, 1152, 4608, 0x +1, 33408, 33408, 1152, 4608, 0x +1, 34560, 34560, 1152, 4608, 0x +1, 35712, 35712, 1152, 4608, 0x +1, 36864, 36864, 1152, 4608, 0x +1, 38016, 38016, 1152, 4608, 0x +1, 39168, 39168, 1152, 4608, 0x +1, 40320, 40320, 1152, 4608, 0x +1, 41472, 41472, 1152, 4608, 0x +1, 42624, 42624, 1152, 4608, 0x +1, 43776, 43776, 1152, 4608, 0x +1, 44928, 44928, 1152, 4608, 0x +1, 46080, 46080, 1152, 4608, 0x +1, 47232, 47232, 1152, 4608, 0x +1
[FFmpeg-devel] [PATCH] fate: add test for asetnsamples
Hi there, Here is a new test, in this case for asetnsamples. From 350347097df129b82ec5d0d7ed59085f44acc605 Mon Sep 17 00:00:00 2001 From: Petru Rares Sincraian Date: Wed, 29 Jun 2016 16:26:19 +0200 Subject: [PATCH] fate: add test for asetnsamples --- tests/fate/filter-audio.mak| 5 + tests/ref/fate/filter-asetnsamples | 522 + 2 files changed, 527 insertions(+) create mode 100644 tests/ref/fate/filter-asetnsamples diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak index 2bdb644..9ea7f8a 100644 --- a/tests/fate/filter-audio.mak +++ b/tests/fate/filter-audio.mak @@ -68,6 +68,11 @@ fate-filter-alimiter: tests/data/asynth-44100-2.wav fate-filter-alimiter: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav fate-filter-alimiter: CMD = framecrc -i $(SRC) -af alimiter=level_in=1:level_out=2:limit=0.2 +FATE_AFILTER-$(call FILTERDEMDECENCMUX, ASETNSAMPLES, WAV, PCM_S16LE, PCM_S16LE, WAV) += fate-filter-asetnsamples +fate-filter-asetnsamples: tests/data/asynth-44100-2.wav +fate-filter-asetnsamples: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav +fate-filter-asetnsamples: CMD = framecrc -i $(SRC) -af asetnsamples=512:p=1 + tests/data/hls-list.m3u8: TAG = GEN tests/data/hls-list.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data $(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \ diff --git a/tests/ref/fate/filter-asetnsamples b/tests/ref/fate/filter-asetnsamples new file mode 100644 index 000..5e246ec --- /dev/null +++ b/tests/ref/fate/filter-asetnsamples @@ -0,0 +1,522 @@ +#tb 0: 1/44100 +#media_type 0: audio +#codec_id 0: pcm_s16le +#sample_rate 0: 44100 +#channel_layout 0: 3 +0, 0, 0, 512, 2048, 0xd2dbf701 +0,512,512, 512, 2048, 0xdb22f7bf +0, 1024, 1024, 512, 2048, 0x82a103be +0, 1536, 1536, 512, 2048, 0xa3c707d8 +0, 2048, 2048, 512, 2048, 0x8aaafb8f +0, 2560, 2560, 512, 2048, 0x4bdafefb +0, 3072, 3072, 512, 2048, 0x75a3e833 +0, 3584, 3584, 512, 2048, 0xc130091c +0, 4096, 4096, 512, 2048, 0x99d8f36d +0, 4608, 4608, 512, 2048, 0xaf6efa15 +0, 5120, 5120, 512, 2048, 0xff5f0506 +0, 5632, 5632, 512, 2048, 0xcba4fb5b +0, 6144, 6144, 512, 2048, 0x729309c6 +0, 6656, 6656, 512, 2048, 0x63cdeb09 +0, 7168, 7168, 512, 2048, 0x386cfccb +0, 7680, 7680, 512, 2048, 0x602100c8 +0, 8192, 8192, 512, 2048, 0x3573f565 +0, 8704, 8704, 512, 2048, 0x47b9fce7 +0, 9216, 9216, 512, 2048, 0xd1e90b7a +0, 9728, 9728, 512, 2048, 0xf4c3ef77 +0, 10240, 10240, 512, 2048, 0x59ebfe3f +0, 10752, 10752, 512, 2048, 0x02d4f161 +0, 11264, 11264, 512, 2048, 0xbbf5ff05 +0, 11776, 11776, 512, 2048, 0xe26a047c +0, 12288, 12288, 512, 2048, 0x5452f02b +0, 12800, 12800, 512, 2048, 0x961e1056 +0, 13312, 13312, 512, 2048, 0x9192f803 +0, 13824, 13824, 512, 2048, 0x08d7ff49 +0, 14336, 14336, 512, 2048, 0x7c64ee03 +0, 14848, 14848, 512, 2048, 0xd303f4ff +0, 15360, 15360, 512, 2048, 0xda5902be +0, 15872, 15872, 512, 2048, 0x4096fe6b +0, 16384, 16384, 512, 2048, 0x178e016a +0, 16896, 16896, 512, 2048, 0x046700ac +0, 17408, 17408, 512, 2048, 0x5f20f4ad +0, 17920, 17920, 512, 2048, 0x40e2f093 +0, 18432, 18432, 512, 2048, 0x5c37fccd +0, 18944, 18944, 512, 2048, 0x9f85f963 +0, 19456, 19456, 512, 2048, 0x69461038 +0, 19968, 19968, 512, 2048, 0x1ff1ef4f +0, 20480, 20480, 512, 2048, 0x409304fc +0, 20992, 20992, 512, 2048, 0x36d3fe47 +0, 21504, 21504, 512, 2048, 0xea01f367 +0, 22016, 22016, 512, 2048, 0x11f5fd01 +0, 22528, 22528, 512, 2048, 0x6da5 +0, 23040, 23040, 512, 2048, 0x7eec0d62 +0, 23552, 23552, 512, 2048, 0xb47bfb93 +0, 24064, 24064, 512, 2048, 0x87b8f7a3 +0, 24576, 24576, 512, 2048, 0xcba0fefb +0, 25088, 25088, 512, 2048, 0xa02efb77 +0, 25600, 25600, 512, 2048, 0x1030ecf1 +0, 26112, 26112, 512, 2048, 0xef7f08f4 +0, 26624, 26624, 512, 2048, 0x8d4efa1d +0, 27136, 27136, 512, 2048, 0xe88b070c +0, 27648, 27648, 512, 2048, 0x229cf957 +0, 28160, 28160, 512, 2048, 0xf7f2f3ed +0, 28672, 28672,
Re: [FFmpeg-devel] [PATCH] lavfi: Move new field to the end of AVFilterContext
On Wed, Jun 29, 2016 at 03:47:12PM +0200, Timo Rothenpieler wrote: > > (1) Iam not sure APIchanges, RELEASE_NOTES or Changelog is the best > > place, iam fine with any of them ... > > APIchanges seems like the place where a distribution maintainer would > most likely look for something like this to me. ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate/h264: add test for skip-nointra and skip-nokey
On Wed, Jun 29, 2016 at 03:47:20PM +0200, Michael Niedermayer wrote: > --- > tests/fate/h264.mak |3 +++ > tests/ref/fate/h264-skip-nointra | 54 > ++ > tests/ref/fate/h264-skip-nokey | 54 > ++ > 3 files changed, 111 insertions(+) > create mode 100644 tests/ref/fate/h264-skip-nointra > create mode 100644 tests/ref/fate/h264-skip-nokey applied so future merges can more easily be tested [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] git: ignore test binaries
From e514644033781cb431641ae088482f5a8aa2de42 Mon Sep 17 00:00:00 2001 From: Benoit Fouet Date: Wed, 29 Jun 2016 17:53:50 +0200 Subject: [PATCH] git: ignore test binaries --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 524fb73..670d1d2 100644 --- a/.gitignore +++ b/.gitignore @@ -19,6 +19,7 @@ *.swp *.ver *_g +*-test \#* .\#* /.config -- 2.9.0.37.g6d523a3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] git: ignore test binaries
On Wed, Jun 29, 2016 at 05:54:37PM +0200, Benoit Fouet wrote: > > From e514644033781cb431641ae088482f5a8aa2de42 Mon Sep 17 00:00:00 2001 > From: Benoit Fouet > Date: Wed, 29 Jun 2016 17:53:50 +0200 > Subject: [PATCH] git: ignore test binaries > > --- > .gitignore | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/.gitignore b/.gitignore > index 524fb73..670d1d2 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -19,6 +19,7 @@ > *.swp > *.ver > *_g > +*-test > \#* > .\#* > /.config You shouldn't have any, they moved somewhere else without the -test suffix (with the exception of fate api tests which have the proper entry in their own .gitignore) Maybe previously built programs? -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] git: ignore test binaries
Hi, On 29/06/2016 17:57, Clément Bœsch wrote: On Wed, Jun 29, 2016 at 05:54:37PM +0200, Benoit Fouet wrote: From e514644033781cb431641ae088482f5a8aa2de42 Mon Sep 17 00:00:00 2001 From: Benoit Fouet Date: Wed, 29 Jun 2016 17:53:50 +0200 Subject: [PATCH] git: ignore test binaries --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 524fb73..670d1d2 100644 --- a/.gitignore +++ b/.gitignore @@ -19,6 +19,7 @@ *.swp *.ver *_g +*-test \#* .\#* /.config You shouldn't have any, they moved somewhere else without the -test suffix (with the exception of fate api tests which have the proper entry in their own .gitignore) Maybe previously built programs? indeed, dropped. Thanks, -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.
This patch addresses Trac ticket #5570. The optimized functions are in file
libswscale/ppc/input_vsx.c. Each optimized function name is a concatenation of
the
corresponding name in libswscale/input.c with suffix _vsx.
---
libswscale/ppc/Makefile | 1 +
libswscale/ppc/input_vsx.c| 437 ++
libswscale/swscale.c | 3 +
libswscale/swscale_internal.h | 1 +
4 files changed, 442 insertions(+)
create mode 100644 libswscale/ppc/input_vsx.c
diff --git a/libswscale/ppc/Makefile b/libswscale/ppc/Makefile
index d1b596e..2482893 100644
--- a/libswscale/ppc/Makefile
+++ b/libswscale/ppc/Makefile
@@ -1,3 +1,4 @@
OBJS += ppc/swscale_altivec.o \
+ppc/input_vsx.o \
ppc/yuv2rgb_altivec.o \
ppc/yuv2yuv_altivec.o \
diff --git a/libswscale/ppc/input_vsx.c b/libswscale/ppc/input_vsx.c
new file mode 100644
index 000..d977a32
--- /dev/null
+++ b/libswscale/ppc/input_vsx.c
@@ -0,0 +1,437 @@
+/*
+ * Copyright (C) 2016 Dan Parrot
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+#include
+#include
+
+#include "libavutil/avutil.h"
+#include "libavutil/bswap.h"
+#include "libavutil/cpu.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/mathematics.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/avassert.h"
+#include "config.h"
+#include "libswscale/rgb2rgb.h"
+#include "libswscale/swscale.h"
+#include "libswscale/swscale_internal.h"
+
+#if HAVE_VSX
+
+static void abgrToA_c_vsx(uint8_t *_dst, const uint8_t *src, const uint8_t
*unused1, const uint8_t *unused2,
+ int width, uint32_t *unused)
+{
+int16_t *dst = (int16_t *)_dst;
+int i, width_adj, frag_len;
+
+uintptr_t src_addr = (uintptr_t)src;
+uintptr_t dst_addr = (uintptr_t)dst;
+
+// compute integral number of vector-length items and length of final
fragment
+width_adj = width >> 3;
+width_adj = width_adj << 3;
+frag_len = width - width_adj;
+
+for ( i = 0; i < width_adj; i += 8) {
+vector int v_rd0 = vec_vsx_ld(0, (int *)src_addr);
+vector int v_rd1 = vec_vsx_ld(0, (int *)(src_addr + 16));
+
+v_rd0 = vec_and(v_rd0, vec_splats(0x0ff));
+v_rd1 = vec_and(v_rd1, vec_splats(0x0ff));
+
+v_rd0 = vec_sl(v_rd0, vec_splats((unsigned)6));
+v_rd1 = vec_sl(v_rd1, vec_splats((unsigned)6));
+
+vector int v_dst = vec_perm(v_rd0, v_rd1, ((vector unsigned char)
+ {0, 1, 4, 5, 8, 9, 12, 13,
16, 17, 20, 21, 24, 25, 28, 29}));
+vec_vsx_st((vector unsigned char)v_dst, 0, (unsigned char *)dst_addr);
+
+src_addr += 32;
+dst_addr += 16;
+}
+
+for (i=width_adj; i< width_adj + frag_len; i++) {
+dst[i]= src[4*i]<<6;
+}
+}
+
+static void rgbaToA_c_vsx(uint8_t *_dst, const uint8_t *src, const uint8_t
*unused1, const uint8_t *unused2,
+ int width, uint32_t *unused)
+{
+int16_t *dst = (int16_t *)_dst;
+int i, width_adj, frag_len;
+
+uintptr_t src_addr = (uintptr_t)src;
+uintptr_t dst_addr = (uintptr_t)dst;
+
+// compute integral number of vector-length items and length of final
fragment
+width_adj = width >> 3;
+width_adj = width_adj << 3;
+frag_len = width - width_adj;
+
+for ( i = 0; i < width_adj; i += 8) {
+vector int v_rd0 = vec_vsx_ld(0, (int *)src_addr);
+vector int v_rd1 = vec_vsx_ld(0, (int *)(src_addr + 16));
+
+v_rd0 = vec_sld(v_rd0, v_rd0, 13);
+v_rd1 = vec_sld(v_rd1, v_rd1, 13);
+
+v_rd0 = vec_and(v_rd0, vec_splats(0x0ff));
+v_rd1 = vec_and(v_rd1, vec_splats(0x0ff));
+
+v_rd0 = vec_sl(v_rd0, vec_splats((unsigned)6));
+v_rd1 = vec_sl(v_rd1, vec_splats((unsigned)6));
+
+vector int v_dst = vec_perm(v_rd0, v_rd1, ((vector unsigned char)
+ {0, 1, 4, 5, 8, 9, 12, 13,
16, 17, 20, 21, 24, 25, 28, 29}));
+vec_vsx_st((vector unsigned char)v_dst, 0, (unsigned char *)dst_addr);
+
+
[FFmpeg-devel] Lossless SilenceRemove Filter
I'm not sure where to post this message, but this list seemed the most appropriate. It seems like a better way to go about removing non-digital silence would be to convert each sample to float or double, then compare that to the max dB considered silence, then store the starting offset and ending offsets based on those values from the original audio, and export just what's in between those. tl;dr output the original samples from an offset, instead of outputting the float samples used in the comparison. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add test for asetnsamples
On Wed, Jun 29, 2016 at 02:40:51PM +, Petru Rares Sincraian wrote: > Hi there, > > > Here is a new test, in this case for asetnsamples. > fate/filter-audio.mak|5 > ref/fate/filter-asetnsamples | 522 > +++ > 2 files changed, 527 insertions(+) > e63ac397b0e3ce8ac030f94768085d7ca4344ae9 > 0001-fate-add-test-for-asetnsamples.patch > From 350347097df129b82ec5d0d7ed59085f44acc605 Mon Sep 17 00:00:00 2001 > From: Petru Rares Sincraian > Date: Wed, 29 Jun 2016 16:26:19 +0200 > Subject: [PATCH] fate: add test for asetnsamples > > --- > tests/fate/filter-audio.mak| 5 + > tests/ref/fate/filter-asetnsamples | 522 > + > 2 files changed, 527 insertions(+) > create mode 100644 tests/ref/fate/filter-asetnsamples applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 02/10] diracdsp: add dequantization SIMD
On 27 June 2016 at 22:38, James Almer wrote:
> On 6/27/2016 8:53 AM, Rostislav Pehlivanov wrote:
> > I've attached another patch which should work fine now.
> > I did this after the put_signed_rect so it does require the first patch,
> > but if this patch is okay I'll amend and tidy things before I push.
> > For some reason changing dstq to be stored at r4 or r3 broke it and I've
> no
> > idea why. Neither is used after loading m2 and m3. Should work on x86_32
> > now, but I'm wondering why I can't save that register.
>
> [...]
>
> > diff --git a/libavcodec/x86/diracdsp.asm b/libavcodec/x86/diracdsp.asm
> > index c5cc530..4bc8b2d 100644
> > --- a/libavcodec/x86/diracdsp.asm
> > +++ b/libavcodec/x86/diracdsp.asm
> > @@ -266,9 +266,45 @@ HPEL_FILTER sse2
> > ADD_OBMC 32, sse2
> > ADD_OBMC 16, sse2
> >
> > -%if ARCH_X86_64 == 1
> > INIT_XMM sse4
> >
> > +; void dequant_subband_32(uint8_t *src, uint8_t *dst, ptrdiff_t stride,
> const int qf, const int qs, int tot_v, int tot_h)
> > +cglobal dequant_subband_32, 7, 8, 4, src, dst, stride, qf, qs, tot_v,
> tot_h
>
> x86_32 has 8 gprs but you can only use 7 as the last one is reserved
> to keep the stack pointer.
>
> > +
> > +movd m2, qfd
> > +movd m3, qsd
> > +SPLATD m2
> > +SPLATD m3
> > +movr4, tot_hq
> > +movr7, dstq
> > +
> > +.loop_v:
> > +movtot_hq, r4
> > +movdstq, r7
> > +
> > +.loop_h:
> > +movu m0, [srcq]
> > +
> > +pabsd m1, m0
> > +pmulld m1, m2
> > +paddd m1, m3
> > +psrld m1, 2
> > +psignd m1, m0
> > +
> > +movu [dstq], m1
> > +
> > +addsrcq, mmsize
> > +adddstq, mmsize
> > +subtot_hd, 4
> > +jg .loop_h
> > +
> > +addr7, strideq
> > +dectot_vd
> > +jg .loop_v
> > +
> > +RET
>
> I'm not sure why you say using r3 instead of r7 here didn't work for
> you. I just tried it (after applying all patches up to 6/10) and fate
> at least still passes, on both x86_64 and x86_32.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Odd, works fine now. I guess it just needed a clean build.
Attached a working patch.
I'd like to get some feedback on the other patches before I push though,
particularly the Golomb reader.
From 4ed0be9216175d5f394a1176596e6cbd5eee7b9a Mon Sep 17 00:00:00 2001
From: Rostislav Pehlivanov
Date: Thu, 23 Jun 2016 18:06:56 +0100
Subject: [PATCH] diracdsp: add dequantization SIMD
Currently unused, to be used in the following commits.
Signed-off-by: Rostislav Pehlivanov
---
libavcodec/diracdsp.c | 24
libavcodec/diracdsp.h | 4
libavcodec/x86/diracdsp.asm| 38 +-
libavcodec/x86/diracdsp_init.c | 7 +--
4 files changed, 70 insertions(+), 3 deletions(-)
diff --git a/libavcodec/diracdsp.c b/libavcodec/diracdsp.c
index ab8d149..cd1209e 100644
--- a/libavcodec/diracdsp.c
+++ b/libavcodec/diracdsp.c
@@ -189,6 +189,27 @@ static void add_rect_clamped_c(uint8_t *dst, const uint16_t *src, int stride,
}
}
+#define DEQUANT_SUBBAND(PX)\
+static void dequant_subband_ ## PX ## _c(uint8_t *src, uint8_t *dst, ptrdiff_t stride, \
+ const int qf, const int qs, int tot_v, int tot_h) \
+{ \
+int i, y; \
+for (y = 0; y < tot_v; y++) { \
+PX c, sign, *src_r = (PX *)src, *dst_r = (PX *)dst;\
+for (i = 0; i < tot_h; i++) { \
+c = *src_r++; \
+sign = FFSIGN(c)*(!!c);\
+c = (FFABS(c)*qf + qs) >> 2; \
+*dst_r++ = c*sign; \
+} \
+src += tot_h << (sizeof(PX) >> 1); \
+dst += stride; \
+} \
+}
+
+DEQUANT_SUBBAND(int16_t)
+DEQUANT_SUBBAND(int32_t)
+
#define PIXFUNC(PFX, WIDTH) \
c->PFX ## _dirac_pixels_tab[WIDTH>>4][0] = ff_ ## PFX ## _dirac_pixels ## WIDTH ## _c; \
c->PFX ## _dirac_pixels_tab[WIDTH>>4][1] = ff_ ## PFX ## _dirac_pixels ## W
Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.
Here are execution times of SIMD and non-SIMD functions. The times were obtained using SystemTap probes at functions' entry and return points. The dataset used was fate-filter-pixfmts-scale. SIMD versions have suffix _vsx: yuy2ToY_c_vsx. no. of calls: 864. min: 1880 ns. avg: 2014 ns. max: 29844 ns. total: 1740366 ns. yuy2ToY_c. no. of calls: 864. min: 2326 ns. avg: 2451 ns. max: 15950 ns. total: 2118226 ns. yvy2ToUV_c_vsx. no. of calls: 288. min: 1891 ns. avg: 1989 ns. max: 13644 ns. total: 573038 ns. yvy2ToUV_c. no. of calls: 288. min: 2089 ns. avg: 2131 ns. max: 2462 ns. total: 613813 ns. rgbaToA_c_vsx. no. of calls: 1152. min: 1975 ns. avg: 2123 ns. max: 31356 ns. total: 2446276 ns. rgbaToA_c. no. of calls: 1152. min: 2368 ns. avg: 2448 ns. max: 12496 ns. total: 2820401 ns. uyvyToUV_c_vsx. no. of calls: 288. min: 1901 ns. avg: 1932 ns. max: 2122 ns. total: 556697 ns. uyvyToUV_c. no. of calls: 288. min: 2088 ns. avg: 2129 ns. max: 2370 ns. total: 613202 ns. uyvyToY_c_vsx. no. of calls: 576. min: 1877 ns. avg: 1956 ns. max: 15821 ns. total: 1127222 ns. uyvyToY_c. no. of calls: 576. min: 2325 ns. avg: 2408 ns. max: 15332 ns. total: 1387168 ns. nv12ToUV_c_vsx. no. of calls: 144. min: 1869 ns. avg: 2006 ns. max: 15480 ns. total: 288867 ns. nv12ToUV_c. no. of calls: 144. min: 2101 ns. avg: 2273 ns. max: 19774 ns. total: 327432 ns. abgrToA_c_vsx. no. of calls: 1152. min: 1949 ns. avg: 2060 ns. max: 15496 ns. total: 2373206 ns. abgrToA_c. no. of calls: 1152. min: 2374 ns. avg: 2471 ns. max: 52452 ns. total: 2847044 ns. yuy2ToUV_c_vsx. no. of calls: 288. min: 1873 ns. avg: 1972 ns. max: 16608 ns. total: 568154 ns. yuy2ToUV_c. no. of calls: 288. min: 2087 ns. avg: 2123 ns. max: 2252 ns. total: 611621 ns. nv21ToUV_c_vsx. no. of calls: 144. min: 1879 ns. avg: 2019 ns. max: 14290 ns. total: 290860 ns. nv21ToUV_c. no. of calls: 144. min: 2098 ns. avg: 2233 ns. max: 14750 ns. total: 321692 ns. = ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 02/13] lavf: update auto-bsf to new BSF API
Hello Michael,
On 06/29/2016 04:53 AM, Michael Niedermayer wrote:
On Tue, Jun 28, 2016 at 01:33:13PM +0200, Nicolas George wrote:
Le primidi 11 messidor, an CCXXIV, Nicolas George a écrit :
Well, looking at the code, I am thinking that the current design is flawed:
the extra alloc in ff_bsf_get_packet() seems completely useless, and could
be removed as is without any other change in the current code, because all
current filters are 1:1, it would be different for future 1:N filters. Maybe
implementing ff_bsf_peek_packet() and using it to replace
ff_bsf_get_packet() in 1:1 cases would do the trick.
I have checked that the following quick-and-dirty changes pass FATE. Making
it in shape (testing filters not covered by FATE, making future-proof) would
take time that I would like to spend on lavfi right now. But it proves the
overhead can be reduced easily.
applying only the attached patch causes
./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -vbsf noise file.avi
to
...
Segmentation fault
valgrind is also unhappy
I think Nicolas has not meant the patch to be really used - he suggested
to create separate ff_bsf_peek_packet function which would just pass
pointer to packet from internal bsf structure and do not allocate new
packet structure each time the pointer to existing one is passed. In
this case caller must not free the packet - just dereference it.
Try attached patch(es) - valgrind seems quite happy.
Regards,
Jan
>From 05755a7f36fd8d0b135288d47dd51e11f93ca488 Mon Sep 17 00:00:00 2001
From: Jan Sebechlebsky
Date: Wed, 29 Jun 2016 19:41:37 +0200
Subject: [PATCH 1/2] avcodec/bsf: Add ff_bsf_peek_packet function
This functions allows to reuse packet in internal bsf
structure and saves extra allocation.
Signed-off-by: Jan Sebechlebsky
---
libavcodec/bsf.c | 16
libavcodec/bsf.h | 8
2 files changed, 24 insertions(+)
diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c
index 88b7f29..1c2e5b6 100644
--- a/libavcodec/bsf.c
+++ b/libavcodec/bsf.c
@@ -217,3 +217,19 @@ int ff_bsf_get_packet(AVBSFContext *ctx, AVPacket **pkt)
return 0;
}
+
+int ff_bsf_peek_packet(AVBSFContext *ctx, AVPacket **pkt)
+{
+AVBSFInternal *in = ctx->internal;
+
+if (in->eof)
+return AVERROR_EOF;
+
+if (!ctx->internal->buffer_pkt->data &&
+!ctx->internal->buffer_pkt->side_data_elems)
+return AVERROR(EAGAIN);
+
+*pkt = ctx->internal->buffer_pkt;
+
+return 0;
+}
diff --git a/libavcodec/bsf.h b/libavcodec/bsf.h
index 3435df5..ecad3a6 100644
--- a/libavcodec/bsf.h
+++ b/libavcodec/bsf.h
@@ -28,6 +28,14 @@
*/
int ff_bsf_get_packet(AVBSFContext *ctx, AVPacket **pkt);
+/**
+ * Called by bitstream filters to get packet for filtering.
+ * This function should be preferred in 1:1 bitstream filters.
+ * Caller must not free the packet, but is responsible for
+ * dereferencing it.
+ */
+int ff_bsf_peek_packet(AVBSFContext *ctx, AVPacket **pkt);
+
const AVClass *ff_bsf_child_class_next(const AVClass *prev);
#endif /* AVCODEC_BSF_H */
--
1.9.1
>From 3f917440555aad67d3c213e94499812f225c79d1 Mon Sep 17 00:00:00 2001
From: Jan Sebechlebsky
Date: Wed, 29 Jun 2016 19:46:43 +0200
Subject: [PATCH 2/2] avcodec/noise_bsf: Use ff_bsf_peek_packet function
Use of ff_bsf_peek_packet saves one malloc operation
compared to ff_bsf_get_packet.
Signed-off-by: Jan Sebechlebsky
---
libavcodec/noise_bsf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/noise_bsf.c b/libavcodec/noise_bsf.c
index 0aebee1..9c21f7b 100644
--- a/libavcodec/noise_bsf.c
+++ b/libavcodec/noise_bsf.c
@@ -44,7 +44,7 @@ static int noise(AVBSFContext *ctx, AVPacket *out)
if (amount <= 0)
return AVERROR(EINVAL);
-ret = ff_bsf_get_packet(ctx, &in);
+ret = ff_bsf_peek_packet(ctx, &in);
if (ret < 0)
return ret;
@@ -66,7 +66,7 @@ static int noise(AVBSFContext *ctx, AVPacket *out)
fail:
if (ret < 0)
av_packet_unref(out);
-av_packet_free(&in);
+av_packet_unref(in);
return ret;
}
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] avfilter/lut: change to support native endian only
previously support little endian only because of fate problem
generally native endian code is faster
require 'tests/fate-run: support both le/be formats on pixfmts'
need someone tests it on BE machine
Signed-off-by: Muhammad Faiz
---
libavfilter/vf_lut.c | 85 +++-
1 file changed, 38 insertions(+), 47 deletions(-)
diff --git a/libavfilter/vf_lut.c b/libavfilter/vf_lut.c
index 5148663..75960b5 100644
--- a/libavfilter/vf_lut.c
+++ b/libavfilter/vf_lut.c
@@ -69,6 +69,7 @@ typedef struct LutContext {
int is_16bit;
int step;
int negate_alpha; /* only used by negate */
+int color_mask;
} LutContext;
#define Y 0
@@ -115,18 +116,18 @@ static av_cold void uninit(AVFilterContext *ctx)
AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUVA444P, \
AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ420P, \
AV_PIX_FMT_YUVJ440P, \
-AV_PIX_FMT_YUV444P9LE, AV_PIX_FMT_YUV422P9LE, AV_PIX_FMT_YUV420P9LE, \
-AV_PIX_FMT_YUV444P10LE, AV_PIX_FMT_YUV422P10LE, AV_PIX_FMT_YUV420P10LE,
AV_PIX_FMT_YUV440P10LE, \
-AV_PIX_FMT_YUV444P12LE, AV_PIX_FMT_YUV422P12LE, AV_PIX_FMT_YUV420P12LE,
AV_PIX_FMT_YUV440P12LE, \
-AV_PIX_FMT_YUV444P14LE, AV_PIX_FMT_YUV422P14LE, AV_PIX_FMT_YUV420P14LE, \
-AV_PIX_FMT_YUV444P16LE, AV_PIX_FMT_YUV422P16LE, AV_PIX_FMT_YUV420P16LE, \
-AV_PIX_FMT_YUVA444P16LE, AV_PIX_FMT_YUVA422P16LE, AV_PIX_FMT_YUVA420P16LE
+AV_PIX_FMT_YUV444P9, AV_PIX_FMT_YUV422P9, AV_PIX_FMT_YUV420P9, \
+AV_PIX_FMT_YUV444P10, AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV420P10,
AV_PIX_FMT_YUV440P10, \
+AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV422P12, AV_PIX_FMT_YUV420P12,
AV_PIX_FMT_YUV440P12, \
+AV_PIX_FMT_YUV444P14, AV_PIX_FMT_YUV422P14, AV_PIX_FMT_YUV420P14, \
+AV_PIX_FMT_YUV444P16, AV_PIX_FMT_YUV422P16, AV_PIX_FMT_YUV420P16, \
+AV_PIX_FMT_YUVA444P16, AV_PIX_FMT_YUVA422P16, AV_PIX_FMT_YUVA420P16
#define RGB_FORMATS \
AV_PIX_FMT_ARGB, AV_PIX_FMT_RGBA, \
AV_PIX_FMT_ABGR, AV_PIX_FMT_BGRA, \
AV_PIX_FMT_RGB24,AV_PIX_FMT_BGR24,\
-AV_PIX_FMT_RGB48LE, AV_PIX_FMT_RGBA64LE
+AV_PIX_FMT_RGB48, AV_PIX_FMT_RGBA64
static const enum AVPixelFormat yuv_pix_fmts[] = { YUV_FORMATS,
AV_PIX_FMT_NONE };
static const enum AVPixelFormat rgb_pix_fmts[] = { RGB_FORMATS,
AV_PIX_FMT_NONE };
@@ -226,32 +227,32 @@ static int config_props(AVFilterLink *inlink)
case AV_PIX_FMT_YUVA420P:
case AV_PIX_FMT_YUVA422P:
case AV_PIX_FMT_YUVA444P:
-case AV_PIX_FMT_YUV420P9LE:
-case AV_PIX_FMT_YUV422P9LE:
-case AV_PIX_FMT_YUV444P9LE:
-case AV_PIX_FMT_YUVA420P9LE:
-case AV_PIX_FMT_YUVA422P9LE:
-case AV_PIX_FMT_YUVA444P9LE:
-case AV_PIX_FMT_YUV420P10LE:
-case AV_PIX_FMT_YUV422P10LE:
-case AV_PIX_FMT_YUV440P10LE:
-case AV_PIX_FMT_YUV444P10LE:
-case AV_PIX_FMT_YUVA420P10LE:
-case AV_PIX_FMT_YUVA422P10LE:
-case AV_PIX_FMT_YUVA444P10LE:
-case AV_PIX_FMT_YUV420P12LE:
-case AV_PIX_FMT_YUV422P12LE:
-case AV_PIX_FMT_YUV440P12LE:
-case AV_PIX_FMT_YUV444P12LE:
-case AV_PIX_FMT_YUV420P14LE:
-case AV_PIX_FMT_YUV422P14LE:
-case AV_PIX_FMT_YUV444P14LE:
-case AV_PIX_FMT_YUV420P16LE:
-case AV_PIX_FMT_YUV422P16LE:
-case AV_PIX_FMT_YUV444P16LE:
-case AV_PIX_FMT_YUVA420P16LE:
-case AV_PIX_FMT_YUVA422P16LE:
-case AV_PIX_FMT_YUVA444P16LE:
+case AV_PIX_FMT_YUV420P9:
+case AV_PIX_FMT_YUV422P9:
+case AV_PIX_FMT_YUV444P9:
+case AV_PIX_FMT_YUVA420P9:
+case AV_PIX_FMT_YUVA422P9:
+case AV_PIX_FMT_YUVA444P9:
+case AV_PIX_FMT_YUV420P10:
+case AV_PIX_FMT_YUV422P10:
+case AV_PIX_FMT_YUV440P10:
+case AV_PIX_FMT_YUV444P10:
+case AV_PIX_FMT_YUVA420P10:
+case AV_PIX_FMT_YUVA422P10:
+case AV_PIX_FMT_YUVA444P10:
+case AV_PIX_FMT_YUV420P12:
+case AV_PIX_FMT_YUV422P12:
+case AV_PIX_FMT_YUV440P12:
+case AV_PIX_FMT_YUV444P12:
+case AV_PIX_FMT_YUV420P14:
+case AV_PIX_FMT_YUV422P14:
+case AV_PIX_FMT_YUV444P14:
+case AV_PIX_FMT_YUV420P16:
+case AV_PIX_FMT_YUV422P16:
+case AV_PIX_FMT_YUV444P16:
+case AV_PIX_FMT_YUVA420P16:
+case AV_PIX_FMT_YUVA422P16:
+case AV_PIX_FMT_YUVA444P16:
min[Y] = 16 * (1 << (desc->comp[0].depth - 8));
min[U] = 16 * (1 << (desc->comp[1].depth - 8));
min[V] = 16 * (1 << (desc->comp[2].depth - 8));
@@ -261,8 +262,8 @@ static int config_props(AVFilterLink *inlink)
max[V] = 240 * (1 << (desc->comp[2].depth - 8));
max[A] = (1 << desc->comp[3].depth) - 1;
break;
-case AV_PIX_FMT_RGB48LE:
-case AV_PIX_FMT_RGBA64LE:
+case AV_PIX_FMT_RGB48:
+case AV_PIX_FMT_RGBA64:
min[0] = min[1] = min[2] = min[3] = 0;
max[0] = max[1] = max[2] = max[3] = 65535;
break;
@@ -271,6 +272,7 @@ static int config_props(AVFilt
Re: [FFmpeg-devel] [PATCH v2] avfilter/lut: change to support native endian only
On Thu, Jun 30, 2016 at 1:24 AM, Muhammad Faiz wrote:
> previously support little endian only because of fate problem
> generally native endian code is faster
>
> require 'tests/fate-run: support both le/be formats on pixfmts'
> need someone tests it on BE machine
>
> Signed-off-by: Muhammad Faiz
> ---
> libavfilter/vf_lut.c | 85
> +++-
> 1 file changed, 38 insertions(+), 47 deletions(-)
>
> diff --git a/libavfilter/vf_lut.c b/libavfilter/vf_lut.c
> index 5148663..75960b5 100644
> --- a/libavfilter/vf_lut.c
> +++ b/libavfilter/vf_lut.c
> @@ -69,6 +69,7 @@ typedef struct LutContext {
> int is_16bit;
> int step;
> int negate_alpha; /* only used by negate */
> +int color_mask;
> } LutContext;
>
> #define Y 0
> @@ -115,18 +116,18 @@ static av_cold void uninit(AVFilterContext *ctx)
> AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUVA444P, \
> AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ420P, \
> AV_PIX_FMT_YUVJ440P, \
> -AV_PIX_FMT_YUV444P9LE, AV_PIX_FMT_YUV422P9LE, AV_PIX_FMT_YUV420P9LE, \
> -AV_PIX_FMT_YUV444P10LE, AV_PIX_FMT_YUV422P10LE, AV_PIX_FMT_YUV420P10LE,
> AV_PIX_FMT_YUV440P10LE, \
> -AV_PIX_FMT_YUV444P12LE, AV_PIX_FMT_YUV422P12LE, AV_PIX_FMT_YUV420P12LE,
> AV_PIX_FMT_YUV440P12LE, \
> -AV_PIX_FMT_YUV444P14LE, AV_PIX_FMT_YUV422P14LE, AV_PIX_FMT_YUV420P14LE, \
> -AV_PIX_FMT_YUV444P16LE, AV_PIX_FMT_YUV422P16LE, AV_PIX_FMT_YUV420P16LE, \
> -AV_PIX_FMT_YUVA444P16LE, AV_PIX_FMT_YUVA422P16LE, AV_PIX_FMT_YUVA420P16LE
> +AV_PIX_FMT_YUV444P9, AV_PIX_FMT_YUV422P9, AV_PIX_FMT_YUV420P9, \
> +AV_PIX_FMT_YUV444P10, AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV420P10,
> AV_PIX_FMT_YUV440P10, \
> +AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV422P12, AV_PIX_FMT_YUV420P12,
> AV_PIX_FMT_YUV440P12, \
> +AV_PIX_FMT_YUV444P14, AV_PIX_FMT_YUV422P14, AV_PIX_FMT_YUV420P14, \
> +AV_PIX_FMT_YUV444P16, AV_PIX_FMT_YUV422P16, AV_PIX_FMT_YUV420P16, \
> +AV_PIX_FMT_YUVA444P16, AV_PIX_FMT_YUVA422P16, AV_PIX_FMT_YUVA420P16
>
> #define RGB_FORMATS \
> AV_PIX_FMT_ARGB, AV_PIX_FMT_RGBA, \
> AV_PIX_FMT_ABGR, AV_PIX_FMT_BGRA, \
> AV_PIX_FMT_RGB24,AV_PIX_FMT_BGR24,\
> -AV_PIX_FMT_RGB48LE, AV_PIX_FMT_RGBA64LE
> +AV_PIX_FMT_RGB48, AV_PIX_FMT_RGBA64
>
> static const enum AVPixelFormat yuv_pix_fmts[] = { YUV_FORMATS,
> AV_PIX_FMT_NONE };
> static const enum AVPixelFormat rgb_pix_fmts[] = { RGB_FORMATS,
> AV_PIX_FMT_NONE };
> @@ -226,32 +227,32 @@ static int config_props(AVFilterLink *inlink)
> case AV_PIX_FMT_YUVA420P:
> case AV_PIX_FMT_YUVA422P:
> case AV_PIX_FMT_YUVA444P:
> -case AV_PIX_FMT_YUV420P9LE:
> -case AV_PIX_FMT_YUV422P9LE:
> -case AV_PIX_FMT_YUV444P9LE:
> -case AV_PIX_FMT_YUVA420P9LE:
> -case AV_PIX_FMT_YUVA422P9LE:
> -case AV_PIX_FMT_YUVA444P9LE:
> -case AV_PIX_FMT_YUV420P10LE:
> -case AV_PIX_FMT_YUV422P10LE:
> -case AV_PIX_FMT_YUV440P10LE:
> -case AV_PIX_FMT_YUV444P10LE:
> -case AV_PIX_FMT_YUVA420P10LE:
> -case AV_PIX_FMT_YUVA422P10LE:
> -case AV_PIX_FMT_YUVA444P10LE:
> -case AV_PIX_FMT_YUV420P12LE:
> -case AV_PIX_FMT_YUV422P12LE:
> -case AV_PIX_FMT_YUV440P12LE:
> -case AV_PIX_FMT_YUV444P12LE:
> -case AV_PIX_FMT_YUV420P14LE:
> -case AV_PIX_FMT_YUV422P14LE:
> -case AV_PIX_FMT_YUV444P14LE:
> -case AV_PIX_FMT_YUV420P16LE:
> -case AV_PIX_FMT_YUV422P16LE:
> -case AV_PIX_FMT_YUV444P16LE:
> -case AV_PIX_FMT_YUVA420P16LE:
> -case AV_PIX_FMT_YUVA422P16LE:
> -case AV_PIX_FMT_YUVA444P16LE:
> +case AV_PIX_FMT_YUV420P9:
> +case AV_PIX_FMT_YUV422P9:
> +case AV_PIX_FMT_YUV444P9:
> +case AV_PIX_FMT_YUVA420P9:
> +case AV_PIX_FMT_YUVA422P9:
> +case AV_PIX_FMT_YUVA444P9:
> +case AV_PIX_FMT_YUV420P10:
> +case AV_PIX_FMT_YUV422P10:
> +case AV_PIX_FMT_YUV440P10:
> +case AV_PIX_FMT_YUV444P10:
> +case AV_PIX_FMT_YUVA420P10:
> +case AV_PIX_FMT_YUVA422P10:
> +case AV_PIX_FMT_YUVA444P10:
> +case AV_PIX_FMT_YUV420P12:
> +case AV_PIX_FMT_YUV422P12:
> +case AV_PIX_FMT_YUV440P12:
> +case AV_PIX_FMT_YUV444P12:
> +case AV_PIX_FMT_YUV420P14:
> +case AV_PIX_FMT_YUV422P14:
> +case AV_PIX_FMT_YUV444P14:
> +case AV_PIX_FMT_YUV420P16:
> +case AV_PIX_FMT_YUV422P16:
> +case AV_PIX_FMT_YUV444P16:
> +case AV_PIX_FMT_YUVA420P16:
> +case AV_PIX_FMT_YUVA422P16:
> +case AV_PIX_FMT_YUVA444P16:
> min[Y] = 16 * (1 << (desc->comp[0].depth - 8));
> min[U] = 16 * (1 << (desc->comp[1].depth - 8));
> min[V] = 16 * (1 << (desc->comp[2].depth - 8));
> @@ -261,8 +262,8 @@ static int config_props(AVFilterLink *inlink)
> max[V] = 240 * (1 << (desc->comp[2].depth - 8));
> max[A] = (1 << desc->comp[3].depth) - 1;
> break;
[FFmpeg-devel] [PATCH v3] avfilter/lut: change to support native endian only
previously support little endian only because of fate problem
generally native endian code is faster
require 'tests/fate-run: support both le/be formats on pixfmts'
need someone tests it on BE machine
Signed-off-by: Muhammad Faiz
---
libavfilter/vf_lut.c | 85 +++-
1 file changed, 38 insertions(+), 47 deletions(-)
diff --git a/libavfilter/vf_lut.c b/libavfilter/vf_lut.c
index 5148663..97f68ad 100644
--- a/libavfilter/vf_lut.c
+++ b/libavfilter/vf_lut.c
@@ -69,6 +69,7 @@ typedef struct LutContext {
int is_16bit;
int step;
int negate_alpha; /* only used by negate */
+int color_mask;
} LutContext;
#define Y 0
@@ -115,18 +116,18 @@ static av_cold void uninit(AVFilterContext *ctx)
AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUVA444P, \
AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ420P, \
AV_PIX_FMT_YUVJ440P, \
-AV_PIX_FMT_YUV444P9LE, AV_PIX_FMT_YUV422P9LE, AV_PIX_FMT_YUV420P9LE, \
-AV_PIX_FMT_YUV444P10LE, AV_PIX_FMT_YUV422P10LE, AV_PIX_FMT_YUV420P10LE,
AV_PIX_FMT_YUV440P10LE, \
-AV_PIX_FMT_YUV444P12LE, AV_PIX_FMT_YUV422P12LE, AV_PIX_FMT_YUV420P12LE,
AV_PIX_FMT_YUV440P12LE, \
-AV_PIX_FMT_YUV444P14LE, AV_PIX_FMT_YUV422P14LE, AV_PIX_FMT_YUV420P14LE, \
-AV_PIX_FMT_YUV444P16LE, AV_PIX_FMT_YUV422P16LE, AV_PIX_FMT_YUV420P16LE, \
-AV_PIX_FMT_YUVA444P16LE, AV_PIX_FMT_YUVA422P16LE, AV_PIX_FMT_YUVA420P16LE
+AV_PIX_FMT_YUV444P9, AV_PIX_FMT_YUV422P9, AV_PIX_FMT_YUV420P9, \
+AV_PIX_FMT_YUV444P10, AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV420P10,
AV_PIX_FMT_YUV440P10, \
+AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV422P12, AV_PIX_FMT_YUV420P12,
AV_PIX_FMT_YUV440P12, \
+AV_PIX_FMT_YUV444P14, AV_PIX_FMT_YUV422P14, AV_PIX_FMT_YUV420P14, \
+AV_PIX_FMT_YUV444P16, AV_PIX_FMT_YUV422P16, AV_PIX_FMT_YUV420P16, \
+AV_PIX_FMT_YUVA444P16, AV_PIX_FMT_YUVA422P16, AV_PIX_FMT_YUVA420P16
#define RGB_FORMATS \
AV_PIX_FMT_ARGB, AV_PIX_FMT_RGBA, \
AV_PIX_FMT_ABGR, AV_PIX_FMT_BGRA, \
AV_PIX_FMT_RGB24,AV_PIX_FMT_BGR24,\
-AV_PIX_FMT_RGB48LE, AV_PIX_FMT_RGBA64LE
+AV_PIX_FMT_RGB48, AV_PIX_FMT_RGBA64
static const enum AVPixelFormat yuv_pix_fmts[] = { YUV_FORMATS,
AV_PIX_FMT_NONE };
static const enum AVPixelFormat rgb_pix_fmts[] = { RGB_FORMATS,
AV_PIX_FMT_NONE };
@@ -226,32 +227,32 @@ static int config_props(AVFilterLink *inlink)
case AV_PIX_FMT_YUVA420P:
case AV_PIX_FMT_YUVA422P:
case AV_PIX_FMT_YUVA444P:
-case AV_PIX_FMT_YUV420P9LE:
-case AV_PIX_FMT_YUV422P9LE:
-case AV_PIX_FMT_YUV444P9LE:
-case AV_PIX_FMT_YUVA420P9LE:
-case AV_PIX_FMT_YUVA422P9LE:
-case AV_PIX_FMT_YUVA444P9LE:
-case AV_PIX_FMT_YUV420P10LE:
-case AV_PIX_FMT_YUV422P10LE:
-case AV_PIX_FMT_YUV440P10LE:
-case AV_PIX_FMT_YUV444P10LE:
-case AV_PIX_FMT_YUVA420P10LE:
-case AV_PIX_FMT_YUVA422P10LE:
-case AV_PIX_FMT_YUVA444P10LE:
-case AV_PIX_FMT_YUV420P12LE:
-case AV_PIX_FMT_YUV422P12LE:
-case AV_PIX_FMT_YUV440P12LE:
-case AV_PIX_FMT_YUV444P12LE:
-case AV_PIX_FMT_YUV420P14LE:
-case AV_PIX_FMT_YUV422P14LE:
-case AV_PIX_FMT_YUV444P14LE:
-case AV_PIX_FMT_YUV420P16LE:
-case AV_PIX_FMT_YUV422P16LE:
-case AV_PIX_FMT_YUV444P16LE:
-case AV_PIX_FMT_YUVA420P16LE:
-case AV_PIX_FMT_YUVA422P16LE:
-case AV_PIX_FMT_YUVA444P16LE:
+case AV_PIX_FMT_YUV420P9:
+case AV_PIX_FMT_YUV422P9:
+case AV_PIX_FMT_YUV444P9:
+case AV_PIX_FMT_YUVA420P9:
+case AV_PIX_FMT_YUVA422P9:
+case AV_PIX_FMT_YUVA444P9:
+case AV_PIX_FMT_YUV420P10:
+case AV_PIX_FMT_YUV422P10:
+case AV_PIX_FMT_YUV440P10:
+case AV_PIX_FMT_YUV444P10:
+case AV_PIX_FMT_YUVA420P10:
+case AV_PIX_FMT_YUVA422P10:
+case AV_PIX_FMT_YUVA444P10:
+case AV_PIX_FMT_YUV420P12:
+case AV_PIX_FMT_YUV422P12:
+case AV_PIX_FMT_YUV440P12:
+case AV_PIX_FMT_YUV444P12:
+case AV_PIX_FMT_YUV420P14:
+case AV_PIX_FMT_YUV422P14:
+case AV_PIX_FMT_YUV444P14:
+case AV_PIX_FMT_YUV420P16:
+case AV_PIX_FMT_YUV422P16:
+case AV_PIX_FMT_YUV444P16:
+case AV_PIX_FMT_YUVA420P16:
+case AV_PIX_FMT_YUVA422P16:
+case AV_PIX_FMT_YUVA444P16:
min[Y] = 16 * (1 << (desc->comp[0].depth - 8));
min[U] = 16 * (1 << (desc->comp[1].depth - 8));
min[V] = 16 * (1 << (desc->comp[2].depth - 8));
@@ -261,8 +262,8 @@ static int config_props(AVFilterLink *inlink)
max[V] = 240 * (1 << (desc->comp[2].depth - 8));
max[A] = (1 << desc->comp[3].depth) - 1;
break;
-case AV_PIX_FMT_RGB48LE:
-case AV_PIX_FMT_RGBA64LE:
+case AV_PIX_FMT_RGB48:
+case AV_PIX_FMT_RGBA64:
min[0] = min[1] = min[2] = min[3] = 0;
max[0] = max[1] = max[2] = max[3] = 65535;
break;
@@ -271,6 +272,7 @@ static int config_props(AVFilt
Re: [FFmpeg-devel] Adding new code
On Tue, 28 Jun 2016 11:00:22 +0300, Dan Shamir wrote: > Hi. A question > We have developed a new kind of video file and feel that ffmpeg is a good > tool to help spread usage for this format. > > How does the dev community feel about adding a new decoder/muxer format? I can't really answer that because you didn't provide any info about this format. What is the format designed for? Who would be interested in using it? How is it licensed? Can you provide some technical info and some sample files? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/5] avformat: Adding accessors for externally used AVStream fields which are after the public field list
Signed-off-by: Michael Niedermayer
---
libavformat/avformat.h |4
libavformat/utils.c| 21 +
2 files changed, 25 insertions(+)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 876f1e3..89f014b 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1224,6 +1224,10 @@ void av_stream_set_r_frame_rate(AVStream *s,
AVRational r);
struct AVCodecParserContext *av_stream_get_parser(const AVStream *s);
char* av_stream_get_recommended_encoder_configuration(const AVStream *s);
void av_stream_set_recommended_encoder_configuration(AVStream *s, char
*configuration);
+int64_t av_stream_get_cur_dts(AVStream *s);
+int64_t av_stream_get_first_dts(AVStream *s);
+int av_stream_get_pts_wrap_bits(AVStream *s);
+int64_t av_stream_get_codec_info_nb_frames(AVStream *s);
/**
* Returns the pts of the last muxed packet + its duration
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 6f343f2..5168816 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -132,6 +132,27 @@ struct AVCodecParserContext *av_stream_get_parser(const
AVStream *st)
return st->parser;
}
+int64_t av_stream_get_cur_dts(AVStream *s)
+{
+return s->cur_dts;
+}
+
+int64_t av_stream_get_first_dts(AVStream *s)
+{
+return s->first_dts;
+}
+
+int av_stream_get_pts_wrap_bits(AVStream *s)
+{
+return s->pts_wrap_bits;
+}
+
+int64_t av_stream_get_codec_info_nb_frames(AVStream *s)
+{
+return s->codec_info_nb_frames;
+}
+
+
void av_format_inject_global_side_data(AVFormatContext *s)
{
int i;
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/5] tools/uncoded_frame: Fix direct use of r_frame_rate
Signed-off-by: Michael Niedermayer
---
tools/uncoded_frame.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/uncoded_frame.c b/tools/uncoded_frame.c
index 3ca2ba4..f0def44 100644
--- a/tools/uncoded_frame.c
+++ b/tools/uncoded_frame.c
@@ -169,8 +169,8 @@ int main(int argc, char **argv)
switch (st->link->type) {
case AVMEDIA_TYPE_VIDEO:
st->stream->codec->codec_id = AV_CODEC_ID_RAWVIDEO;
-st->stream->avg_frame_rate =
-st->stream-> r_frame_rate =
av_buffersink_get_frame_rate(st->sink);
+st->stream->avg_frame_rate =
av_buffersink_get_frame_rate(st->sink);
+av_stream_set_r_frame_rate(st->stream, st->stream->avg_frame_rate);
st->stream->codec->width = st->link->w;
st->stream->codec->height = st->link->h;
st->stream->codec->sample_aspect_ratio =
st->link->sample_aspect_ratio;
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/5] ffmpeg: Fix direct use of AVStream fields
Signed-off-by: Michael Niedermayer
---
ffmpeg.c | 37 +++--
ffmpeg_opt.c |4 ++--
2 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index 9ffd833..c68461d 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -948,7 +948,7 @@ static void do_video_out(AVFormatContext *s,
filter->inputs[0]->frame_rate.den > 0)
duration = 1/(av_q2d(filter->inputs[0]->frame_rate) *
av_q2d(enc->time_base));
-if(ist && ist->st->start_time != AV_NOPTS_VALUE && ist->st->first_dts !=
AV_NOPTS_VALUE && ost->frame_rate.num)
+if(ist && ist->st->start_time != AV_NOPTS_VALUE &&
av_stream_get_first_dts(ist->st) != AV_NOPTS_VALUE && ost->frame_rate.num)
duration = FFMIN(duration, 1/(av_q2d(ost->frame_rate) *
av_q2d(enc->time_base)));
if (!ost->filters_script &&
@@ -2917,14 +2917,14 @@ static int transcode_init(void)
* overhead
*/
if(!strcmp(oc->oformat->name, "avi")) {
-if ( copy_tb<0 && ist->st->r_frame_rate.num
- && av_q2d(ist->st->r_frame_rate) >=
av_q2d(ist->st->avg_frame_rate)
- && 0.5/av_q2d(ist->st->r_frame_rate) >
av_q2d(ist->st->time_base)
- && 0.5/av_q2d(ist->st->r_frame_rate) >
av_q2d(dec_ctx->time_base)
+if ( copy_tb<0 && av_stream_get_r_frame_rate(ist->st).num
+ && av_q2d(av_stream_get_r_frame_rate(ist->st))
>= av_q2d(ist->st->avg_frame_rate)
+ &&
0.5/av_q2d(av_stream_get_r_frame_rate(ist->st)) > av_q2d(ist->st->time_base)
+ &&
0.5/av_q2d(av_stream_get_r_frame_rate(ist->st)) > av_q2d(dec_ctx->time_base)
&& av_q2d(ist->st->time_base) < 1.0/500 &&
av_q2d(dec_ctx->time_base) < 1.0/500
|| copy_tb==2){
-enc_ctx->time_base.num = ist->st->r_frame_rate.den;
-enc_ctx->time_base.den = 2*ist->st->r_frame_rate.num;
+enc_ctx->time_base.num =
av_stream_get_r_frame_rate(ist->st).den;
+enc_ctx->time_base.den =
2*av_stream_get_r_frame_rate(ist->st).num;
enc_ctx->ticks_per_frame = 2;
} else if ( copy_tb<0 &&
av_q2d(dec_ctx->time_base)*dec_ctx->ticks_per_frame >
2*av_q2d(ist->st->time_base)
&& av_q2d(ist->st->time_base) < 1.0/500
@@ -3032,7 +3032,7 @@ static int transcode_init(void)
sar = dec_ctx->sample_aspect_ratio;
ost->st->sample_aspect_ratio = enc_ctx->sample_aspect_ratio =
sar;
ost->st->avg_frame_rate = ist->st->avg_frame_rate;
-ost->st->r_frame_rate = ist->st->r_frame_rate;
+av_stream_set_r_frame_rate(ost->st,
av_stream_get_r_frame_rate(ist->st));
break;
case AVMEDIA_TYPE_SUBTITLE:
enc_ctx->width = dec_ctx->width;
@@ -3085,7 +3085,7 @@ static int transcode_init(void)
if (ist && !ost->frame_rate.num)
ost->frame_rate = ist->framerate;
if (ist && !ost->frame_rate.num)
-ost->frame_rate = ist->st->r_frame_rate;
+ost->frame_rate = av_stream_get_r_frame_rate(ist->st);
if (ist && !ost->frame_rate.num) {
ost->frame_rate = (AVRational){25, 1};
av_log(NULL, AV_LOG_WARNING,
@@ -3422,10 +3422,11 @@ static OutputStream *choose_output(void)
for (i = 0; i < nb_output_streams; i++) {
OutputStream *ost = output_streams[i];
-int64_t opts = ost->st->cur_dts == AV_NOPTS_VALUE ? INT64_MIN :
- av_rescale_q(ost->st->cur_dts, ost->st->time_base,
+int64_t cur_dts = av_stream_get_cur_dts(ost->st);
+int64_t opts = cur_dts == AV_NOPTS_VALUE ? INT64_MIN :
+ av_rescale_q(cur_dts, ost->st->time_base,
AV_TIME_BASE_Q);
-if (ost->st->cur_dts == AV_NOPTS_VALUE)
+if (cur_dts == AV_NOPTS_VALUE)
av_log(NULL, AV_LOG_DEBUG, "cur_dts is invalid (this is harmless
if it occurs once at the start per stream)\n");
if (!ost->finished && opts < opts_min) {
@@ -3873,7 +3874,7 @@ static int process_input(int file_index)
av_ts2timestr(input_files[ist->file_index]->ts_offset,
&AV_TIME_BASE_Q));
}
-if(!ist->wrap_correction_done && is->start_time != AV_NOPTS_VALUE &&
ist->st->pts_wrap_bits < 64){
+if(!ist->wrap_correction_done && is->start_time != AV_NOPTS_VALUE &&
av_stream_get_pts_wrap_bits(ist->st) < 64){
int64_t stime, stime2;
// Correcting starttime based on the enabled streams
// FIXME this ideally should be done before the first use of starttime
but we do not know which are the enabled streams at that poin
[FFmpeg-devel] [PATCH 4/5] avfilter/src_movie: Fix direct use of r_frame_rate
Signed-off-by: Michael Niedermayer --- libavfilter/src_movie.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavfilter/src_movie.c b/libavfilter/src_movie.c index 23dcb7b..0c4ef63 100644 --- a/libavfilter/src_movie.c +++ b/libavfilter/src_movie.c @@ -394,7 +394,7 @@ static int movie_config_output_props(AVFilterLink *outlink) case AVMEDIA_TYPE_VIDEO: outlink->w = c->width; outlink->h = c->height; -outlink->frame_rate = st->st->r_frame_rate; +outlink->frame_rate = av_stream_get_r_frame_rate(st->st); break; case AVMEDIA_TYPE_AUDIO: break; -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/5] ffprobe: Fix direct use of r_frame_rate
Signed-off-by: Michael Niedermayer
---
ffprobe.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ffprobe.c b/ffprobe.c
index b9c3760..e8da344 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -2324,7 +2324,7 @@ static int show_stream(WriterContext *w, AVFormatContext
*fmt_ctx, int stream_id
if (fmt_ctx->iformat->flags & AVFMT_SHOW_IDS) print_fmt("id", "0x%x",
stream->id);
else print_str_opt("id", "N/A");
-print_q("r_frame_rate", stream->r_frame_rate, '/');
+print_q("r_frame_rate", av_stream_get_r_frame_rate(stream), '/');
print_q("avg_frame_rate", stream->avg_frame_rate, '/');
print_q("time_base", stream->time_base, '/');
print_ts ("start_pts", stream->start_time);
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avformat: Adding accessors for externally used AVStream fields which are after the public field list
On Wed, Jun 29, 2016 at 09:36:39PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/avformat.h |4
> libavformat/utils.c| 21 +
> 2 files changed, 25 insertions(+)
>
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 876f1e3..89f014b 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -1224,6 +1224,10 @@ void av_stream_set_r_frame_rate(AVStream *s,
> AVRational r);
> struct AVCodecParserContext *av_stream_get_parser(const AVStream *s);
> char* av_stream_get_recommended_encoder_configuration(const AVStream *s);
> void av_stream_set_recommended_encoder_configuration(AVStream *s, char
> *configuration);
> +int64_t av_stream_get_cur_dts(AVStream *s);
> +int64_t av_stream_get_first_dts(AVStream *s);
> +int av_stream_get_pts_wrap_bits(AVStream *s);
> +int64_t av_stream_get_codec_info_nb_frames(AVStream *s);
>
> /**
> * Returns the pts of the last muxed packet + its duration
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 6f343f2..5168816 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -132,6 +132,27 @@ struct AVCodecParserContext *av_stream_get_parser(const
> AVStream *st)
> return st->parser;
> }
>
> +int64_t av_stream_get_cur_dts(AVStream *s)
> +{
> +return s->cur_dts;
> +}
> +
> +int64_t av_stream_get_first_dts(AVStream *s)
> +{
> +return s->first_dts;
> +}
> +
> +int av_stream_get_pts_wrap_bits(AVStream *s)
> +{
> +return s->pts_wrap_bits;
> +}
> +
> +int64_t av_stream_get_codec_info_nb_frames(AVStream *s)
> +{
> +return s->codec_info_nb_frames;
> +}
> +
> +
erm. how about we move them in the public fields instead?
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avformat: Adding accessors for externally used AVStream fields which are after the public field list
On Wed, Jun 29, 2016 at 09:41:50PM +0200, Clément Bœsch wrote:
> On Wed, Jun 29, 2016 at 09:36:39PM +0200, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/avformat.h |4
> > libavformat/utils.c| 21 +
> > 2 files changed, 25 insertions(+)
> >
> > diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> > index 876f1e3..89f014b 100644
> > --- a/libavformat/avformat.h
> > +++ b/libavformat/avformat.h
> > @@ -1224,6 +1224,10 @@ void av_stream_set_r_frame_rate(AVStream *s,
> > AVRational r);
> > struct AVCodecParserContext *av_stream_get_parser(const AVStream *s);
> > char* av_stream_get_recommended_encoder_configuration(const AVStream *s);
> > void av_stream_set_recommended_encoder_configuration(AVStream *s, char
> > *configuration);
> > +int64_t av_stream_get_cur_dts(AVStream *s);
> > +int64_t av_stream_get_first_dts(AVStream *s);
> > +int av_stream_get_pts_wrap_bits(AVStream *s);
> > +int64_t av_stream_get_codec_info_nb_frames(AVStream *s);
> >
> > /**
> > * Returns the pts of the last muxed packet + its duration
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index 6f343f2..5168816 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -132,6 +132,27 @@ struct AVCodecParserContext
> > *av_stream_get_parser(const AVStream *st)
> > return st->parser;
> > }
> >
> > +int64_t av_stream_get_cur_dts(AVStream *s)
> > +{
> > +return s->cur_dts;
> > +}
> > +
> > +int64_t av_stream_get_first_dts(AVStream *s)
> > +{
> > +return s->first_dts;
> > +}
> > +
> > +int av_stream_get_pts_wrap_bits(AVStream *s)
> > +{
> > +return s->pts_wrap_bits;
> > +}
> > +
> > +int64_t av_stream_get_codec_info_nb_frames(AVStream *s)
> > +{
> > +return s->codec_info_nb_frames;
> > +}
> > +
> > +
>
> erm. how about we move them in the public fields instead?
The 3.0 release has these fields in one location, the 3.1 release
has them in a different location because codecpar was added in the
middle. The fields are marked as private
To fix this we can either as in this patchset add accessors and
use
them in all applications (probably not just ours)
OR
we could move codecpar to the end of AVStream
OR
we could bump major abi version
what do people prefer ?
moving them into the pblic fields will not make them match where
they where in 3.0, which is the problem we have
[...]
--
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 1/5] avformat: Adding accessors for externally used AVStream fields which are after the public field list
On 6/29/2016 4:36 PM, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/avformat.h |4
> libavformat/utils.c| 21 +
> 2 files changed, 25 insertions(+)
>
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 876f1e3..89f014b 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -1224,6 +1224,10 @@ void av_stream_set_r_frame_rate(AVStream *s,
> AVRational r);
> struct AVCodecParserContext *av_stream_get_parser(const AVStream *s);
> char* av_stream_get_recommended_encoder_configuration(const AVStream *s);
> void av_stream_set_recommended_encoder_configuration(AVStream *s, char
> *configuration);
> +int64_t av_stream_get_cur_dts(AVStream *s);
> +int64_t av_stream_get_first_dts(AVStream *s);
> +int av_stream_get_pts_wrap_bits(AVStream *s);
> +int64_t av_stream_get_codec_info_nb_frames(AVStream *s);
>
> /**
> * Returns the pts of the last muxed packet + its duration
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 6f343f2..5168816 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -132,6 +132,27 @@ struct AVCodecParserContext *av_stream_get_parser(const
> AVStream *st)
> return st->parser;
> }
>
> +int64_t av_stream_get_cur_dts(AVStream *s)
> +{
> +return s->cur_dts;
> +}
> +
> +int64_t av_stream_get_first_dts(AVStream *s)
> +{
> +return s->first_dts;
> +}
> +
> +int av_stream_get_pts_wrap_bits(AVStream *s)
> +{
> +return s->pts_wrap_bits;
> +}
> +
> +int64_t av_stream_get_codec_info_nb_frames(AVStream *s)
> +{
> +return s->codec_info_nb_frames;
> +}
> +
> +
> void av_format_inject_global_side_data(AVFormatContext *s)
> {
> int i;
No more accessors, please. If these fields truly need to be used outside of
libavformat then move them above the private fields mark (alongside minor
bump and preferably some minimal doxy).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avformat: Adding accessors for externally used AVStream fields which are after the public field list
On Wed, Jun 29, 2016 at 05:07:52PM -0300, James Almer wrote:
> On 6/29/2016 4:36 PM, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/avformat.h |4
> > libavformat/utils.c| 21 +
> > 2 files changed, 25 insertions(+)
> >
> > diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> > index 876f1e3..89f014b 100644
> > --- a/libavformat/avformat.h
> > +++ b/libavformat/avformat.h
> > @@ -1224,6 +1224,10 @@ void av_stream_set_r_frame_rate(AVStream *s,
> > AVRational r);
> > struct AVCodecParserContext *av_stream_get_parser(const AVStream *s);
> > char* av_stream_get_recommended_encoder_configuration(const AVStream *s);
> > void av_stream_set_recommended_encoder_configuration(AVStream *s, char
> > *configuration);
> > +int64_t av_stream_get_cur_dts(AVStream *s);
> > +int64_t av_stream_get_first_dts(AVStream *s);
> > +int av_stream_get_pts_wrap_bits(AVStream *s);
> > +int64_t av_stream_get_codec_info_nb_frames(AVStream *s);
> >
> > /**
> > * Returns the pts of the last muxed packet + its duration
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index 6f343f2..5168816 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -132,6 +132,27 @@ struct AVCodecParserContext
> > *av_stream_get_parser(const AVStream *st)
> > return st->parser;
> > }
> >
> > +int64_t av_stream_get_cur_dts(AVStream *s)
> > +{
> > +return s->cur_dts;
> > +}
> > +
> > +int64_t av_stream_get_first_dts(AVStream *s)
> > +{
> > +return s->first_dts;
> > +}
> > +
> > +int av_stream_get_pts_wrap_bits(AVStream *s)
> > +{
> > +return s->pts_wrap_bits;
> > +}
> > +
> > +int64_t av_stream_get_codec_info_nb_frames(AVStream *s)
> > +{
> > +return s->codec_info_nb_frames;
> > +}
> > +
> > +
> > void av_format_inject_global_side_data(AVFormatContext *s)
> > {
> > int i;
>
> No more accessors, please. If these fields truly need to be used outside of
> libavformat then move them above the private fields mark (alongside minor
> bump and preferably some minimal doxy).
can you explain how this fixes the ABI breakage between 3.0 and 3.1?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avformat: Adding accessors for externally used AVStream fields which are after the public field list
On Wed, Jun 29, 2016 at 10:18 PM, Michael Niedermayer
wrote:
> On Wed, Jun 29, 2016 at 09:41:50PM +0200, Clément Bœsch wrote:
>> On Wed, Jun 29, 2016 at 09:36:39PM +0200, Michael Niedermayer wrote:
>> > Signed-off-by: Michael Niedermayer
>> > ---
>> > libavformat/avformat.h |4
>> > libavformat/utils.c| 21 +
>> > 2 files changed, 25 insertions(+)
>> >
>> > diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>> > index 876f1e3..89f014b 100644
>> > --- a/libavformat/avformat.h
>> > +++ b/libavformat/avformat.h
>> > @@ -1224,6 +1224,10 @@ void av_stream_set_r_frame_rate(AVStream *s,
>> > AVRational r);
>> > struct AVCodecParserContext *av_stream_get_parser(const AVStream *s);
>> > char* av_stream_get_recommended_encoder_configuration(const AVStream *s);
>> > void av_stream_set_recommended_encoder_configuration(AVStream *s, char
>> > *configuration);
>> > +int64_t av_stream_get_cur_dts(AVStream *s);
>> > +int64_t av_stream_get_first_dts(AVStream *s);
>> > +int av_stream_get_pts_wrap_bits(AVStream *s);
>> > +int64_t av_stream_get_codec_info_nb_frames(AVStream *s);
>> >
>> > /**
>> > * Returns the pts of the last muxed packet + its duration
>> > diff --git a/libavformat/utils.c b/libavformat/utils.c
>> > index 6f343f2..5168816 100644
>> > --- a/libavformat/utils.c
>> > +++ b/libavformat/utils.c
>> > @@ -132,6 +132,27 @@ struct AVCodecParserContext
>> > *av_stream_get_parser(const AVStream *st)
>> > return st->parser;
>> > }
>> >
>> > +int64_t av_stream_get_cur_dts(AVStream *s)
>> > +{
>> > +return s->cur_dts;
>> > +}
>> > +
>> > +int64_t av_stream_get_first_dts(AVStream *s)
>> > +{
>> > +return s->first_dts;
>> > +}
>> > +
>> > +int av_stream_get_pts_wrap_bits(AVStream *s)
>> > +{
>> > +return s->pts_wrap_bits;
>> > +}
>> > +
>> > +int64_t av_stream_get_codec_info_nb_frames(AVStream *s)
>> > +{
>> > +return s->codec_info_nb_frames;
>> > +}
>> > +
>> > +
>>
>> erm. how about we move them in the public fields instead?
>
> The 3.0 release has these fields in one location, the 3.1 release
> has them in a different location because codecpar was added in the
> middle. The fields are marked as private
>
> To fix this we can either as in this patchset add accessors and
> use
> them in all applications (probably not just ours)
>
> OR
>
> we could move codecpar to the end of AVStream
>
> OR
>
> we could bump major abi version
>
> what do people prefer ?
>
> moving them into the pblic fields will not make them match where
> they where in 3.0, which is the problem we have
>
They are already in the wrong position, and they are marked explicitly
as private fields, so any app using them is doing it wrong, we should
not break the actual public ABI to cater to that.
Moving codecpar now seems like a bad solution, as in contrast to these
fields, codecpar is full public API/ABI and is in a release already
(even if its only a few days old).
Adding new accessors will also not fix those old apps, since old
ffmpeg wouldnt have the accessor, so its no better then any other
solution, and since we stopped caring about ABI compat with libav, the
primary reason for them has also vanished.
So I would vote for moving private fields that should be public right
above the private marker and be done with it.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avformat: Adding accessors for externally used AVStream fields which are after the public field list
On Wed, Jun 29, 2016 at 10:27 PM, Michael Niedermayer
wrote:
> On Wed, Jun 29, 2016 at 05:07:52PM -0300, James Almer wrote:
>> On 6/29/2016 4:36 PM, Michael Niedermayer wrote:
>> > Signed-off-by: Michael Niedermayer
>> > ---
>> > libavformat/avformat.h |4
>> > libavformat/utils.c| 21 +
>> > 2 files changed, 25 insertions(+)
>> >
>> > diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>> > index 876f1e3..89f014b 100644
>> > --- a/libavformat/avformat.h
>> > +++ b/libavformat/avformat.h
>> > @@ -1224,6 +1224,10 @@ void av_stream_set_r_frame_rate(AVStream *s,
>> > AVRational r);
>> > struct AVCodecParserContext *av_stream_get_parser(const AVStream *s);
>> > char* av_stream_get_recommended_encoder_configuration(const AVStream *s);
>> > void av_stream_set_recommended_encoder_configuration(AVStream *s, char
>> > *configuration);
>> > +int64_t av_stream_get_cur_dts(AVStream *s);
>> > +int64_t av_stream_get_first_dts(AVStream *s);
>> > +int av_stream_get_pts_wrap_bits(AVStream *s);
>> > +int64_t av_stream_get_codec_info_nb_frames(AVStream *s);
>> >
>> > /**
>> > * Returns the pts of the last muxed packet + its duration
>> > diff --git a/libavformat/utils.c b/libavformat/utils.c
>> > index 6f343f2..5168816 100644
>> > --- a/libavformat/utils.c
>> > +++ b/libavformat/utils.c
>> > @@ -132,6 +132,27 @@ struct AVCodecParserContext
>> > *av_stream_get_parser(const AVStream *st)
>> > return st->parser;
>> > }
>> >
>> > +int64_t av_stream_get_cur_dts(AVStream *s)
>> > +{
>> > +return s->cur_dts;
>> > +}
>> > +
>> > +int64_t av_stream_get_first_dts(AVStream *s)
>> > +{
>> > +return s->first_dts;
>> > +}
>> > +
>> > +int av_stream_get_pts_wrap_bits(AVStream *s)
>> > +{
>> > +return s->pts_wrap_bits;
>> > +}
>> > +
>> > +int64_t av_stream_get_codec_info_nb_frames(AVStream *s)
>> > +{
>> > +return s->codec_info_nb_frames;
>> > +}
>> > +
>> > +
>> > void av_format_inject_global_side_data(AVFormatContext *s)
>> > {
>> > int i;
>>
>> No more accessors, please. If these fields truly need to be used outside of
>> libavformat then move them above the private fields mark (alongside minor
>> bump and preferably some minimal doxy).
>
> can you explain how this fixes the ABI breakage between 3.0 and 3.1?
>
There is nothing to fix, only private ABI is broken.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avutil/frame: Move new field to the end of AVFrame
This is a similar ABI fix to 1eb43af1a0e542ad83dcbf327197785d815fc42d
---
libavutil/frame.h | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 44adec4..2b5c332 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -428,12 +428,6 @@ typedef struct AVFrame {
enum AVChromaLocation chroma_location;
/**
- * For hwaccel-format frames, this should be a reference to the
- * AVHWFramesContext describing the frame.
- */
-AVBufferRef *hw_frames_ctx;
-
-/**
* frame timestamp estimated using various heuristics, in stream time base
* Code outside libavutil should access this field using:
* av_frame_get_best_effort_timestamp(frame)
@@ -524,6 +518,11 @@ typedef struct AVFrame {
*/
AVBufferRef *qp_table_buf;
#endif
+/**
+ * For hwaccel-format frames, this should be a reference to the
+ * AVHWFramesContext describing the frame.
+ */
+AVBufferRef *hw_frames_ctx;
} AVFrame;
/**
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/frame: Move new field to the end of AVFrame
On Wed, Jun 29, 2016 at 10:31 PM, Michael Niedermayer wrote: > This is a similar ABI fix to 1eb43af1a0e542ad83dcbf327197785d815fc42d All fields below this are documented as no direct access, and this struct layout is in a release already. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avformat: Adding accessors for externally used AVStream fields which are after the public field list
On Wed, Jun 29, 2016 at 10:28:27PM +0200, Hendrik Leppkes wrote:
> On Wed, Jun 29, 2016 at 10:18 PM, Michael Niedermayer
> wrote:
> > On Wed, Jun 29, 2016 at 09:41:50PM +0200, Clément Bœsch wrote:
> >> On Wed, Jun 29, 2016 at 09:36:39PM +0200, Michael Niedermayer wrote:
> >> > Signed-off-by: Michael Niedermayer
> >> > ---
> >> > libavformat/avformat.h |4
> >> > libavformat/utils.c| 21 +
> >> > 2 files changed, 25 insertions(+)
> >> >
> >> > diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> >> > index 876f1e3..89f014b 100644
> >> > --- a/libavformat/avformat.h
> >> > +++ b/libavformat/avformat.h
> >> > @@ -1224,6 +1224,10 @@ void av_stream_set_r_frame_rate(AVStream
> >> > *s, AVRational r);
> >> > struct AVCodecParserContext *av_stream_get_parser(const AVStream *s);
> >> > char* av_stream_get_recommended_encoder_configuration(const AVStream
> >> > *s);
> >> > void av_stream_set_recommended_encoder_configuration(AVStream *s, char
> >> > *configuration);
> >> > +int64_t av_stream_get_cur_dts(AVStream *s);
> >> > +int64_t av_stream_get_first_dts(AVStream *s);
> >> > +int av_stream_get_pts_wrap_bits(AVStream *s);
> >> > +int64_t av_stream_get_codec_info_nb_frames(AVStream *s);
> >> >
> >> > /**
> >> > * Returns the pts of the last muxed packet + its duration
> >> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> >> > index 6f343f2..5168816 100644
> >> > --- a/libavformat/utils.c
> >> > +++ b/libavformat/utils.c
> >> > @@ -132,6 +132,27 @@ struct AVCodecParserContext
> >> > *av_stream_get_parser(const AVStream *st)
> >> > return st->parser;
> >> > }
> >> >
> >> > +int64_t av_stream_get_cur_dts(AVStream *s)
> >> > +{
> >> > +return s->cur_dts;
> >> > +}
> >> > +
> >> > +int64_t av_stream_get_first_dts(AVStream *s)
> >> > +{
> >> > +return s->first_dts;
> >> > +}
> >> > +
> >> > +int av_stream_get_pts_wrap_bits(AVStream *s)
> >> > +{
> >> > +return s->pts_wrap_bits;
> >> > +}
> >> > +
> >> > +int64_t av_stream_get_codec_info_nb_frames(AVStream *s)
> >> > +{
> >> > +return s->codec_info_nb_frames;
> >> > +}
> >> > +
> >> > +
> >>
> >> erm. how about we move them in the public fields instead?
> >
> > The 3.0 release has these fields in one location, the 3.1 release
> > has them in a different location because codecpar was added in the
> > middle. The fields are marked as private
> >
> > To fix this we can either as in this patchset add accessors and
> > use
> > them in all applications (probably not just ours)
> >
> > OR
> >
> > we could move codecpar to the end of AVStream
> >
> > OR
> >
> > we could bump major abi version
> >
> > what do people prefer ?
> >
> > moving them into the pblic fields will not make them match where
> > they where in 3.0, which is the problem we have
> >
>
> They are already in the wrong position, and they are marked explicitly
> as private fields, so any app using them is doing it wrong, we should
> not break the actual public ABI to cater to that.
> Moving codecpar now seems like a bad solution, as in contrast to these
> fields, codecpar is full public API/ABI and is in a release already
> (even if its only a few days old).
>
> Adding new accessors will also not fix those old apps, since old
> ffmpeg wouldnt have the accessor,
Backporting the accessors is very simple
> so its no better then any other
> solution, and since we stopped caring about ABI compat with libav, the
> primary reason for them has also vanished.
> So I would vote for moving private fields that should be public right
> above the private marker and be done with it.
As this doesnt solve the ABI problem it would not help with this issue
or the distributions who want (but cannot) ship FFmpeg 3.1
Please tell me how you prefer the ABI issue with 3.0 / 3.1 to be
fixed
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- 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] avformat: Adding accessors for externally used AVStream fields which are after the public field list
On Wed, Jun 29, 2016 at 10:52 PM, Michael Niedermayer
wrote:
> On Wed, Jun 29, 2016 at 10:28:27PM +0200, Hendrik Leppkes wrote:
>> On Wed, Jun 29, 2016 at 10:18 PM, Michael Niedermayer
>> wrote:
>> > On Wed, Jun 29, 2016 at 09:41:50PM +0200, Clément Bœsch wrote:
>> >> On Wed, Jun 29, 2016 at 09:36:39PM +0200, Michael Niedermayer wrote:
>> >> > Signed-off-by: Michael Niedermayer
>> >> > ---
>> >> > libavformat/avformat.h |4
>> >> > libavformat/utils.c| 21 +
>> >> > 2 files changed, 25 insertions(+)
>> >> >
>> >> > diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>> >> > index 876f1e3..89f014b 100644
>> >> > --- a/libavformat/avformat.h
>> >> > +++ b/libavformat/avformat.h
>> >> > @@ -1224,6 +1224,10 @@ void av_stream_set_r_frame_rate(AVStream
>> >> > *s, AVRational r);
>> >> > struct AVCodecParserContext *av_stream_get_parser(const AVStream *s);
>> >> > char* av_stream_get_recommended_encoder_configuration(const AVStream
>> >> > *s);
>> >> > void av_stream_set_recommended_encoder_configuration(AVStream *s,
>> >> > char *configuration);
>> >> > +int64_t av_stream_get_cur_dts(AVStream *s);
>> >> > +int64_t av_stream_get_first_dts(AVStream *s);
>> >> > +int av_stream_get_pts_wrap_bits(AVStream *s);
>> >> > +int64_t av_stream_get_codec_info_nb_frames(AVStream *s);
>> >> >
>> >> > /**
>> >> > * Returns the pts of the last muxed packet + its duration
>> >> > diff --git a/libavformat/utils.c b/libavformat/utils.c
>> >> > index 6f343f2..5168816 100644
>> >> > --- a/libavformat/utils.c
>> >> > +++ b/libavformat/utils.c
>> >> > @@ -132,6 +132,27 @@ struct AVCodecParserContext
>> >> > *av_stream_get_parser(const AVStream *st)
>> >> > return st->parser;
>> >> > }
>> >> >
>> >> > +int64_t av_stream_get_cur_dts(AVStream *s)
>> >> > +{
>> >> > +return s->cur_dts;
>> >> > +}
>> >> > +
>> >> > +int64_t av_stream_get_first_dts(AVStream *s)
>> >> > +{
>> >> > +return s->first_dts;
>> >> > +}
>> >> > +
>> >> > +int av_stream_get_pts_wrap_bits(AVStream *s)
>> >> > +{
>> >> > +return s->pts_wrap_bits;
>> >> > +}
>> >> > +
>> >> > +int64_t av_stream_get_codec_info_nb_frames(AVStream *s)
>> >> > +{
>> >> > +return s->codec_info_nb_frames;
>> >> > +}
>> >> > +
>> >> > +
>> >>
>> >> erm. how about we move them in the public fields instead?
>> >
>> > The 3.0 release has these fields in one location, the 3.1 release
>> > has them in a different location because codecpar was added in the
>> > middle. The fields are marked as private
>> >
>> > To fix this we can either as in this patchset add accessors and
>> > use
>> > them in all applications (probably not just ours)
>> >
>> > OR
>> >
>> > we could move codecpar to the end of AVStream
>> >
>> > OR
>> >
>> > we could bump major abi version
>> >
>> > what do people prefer ?
>> >
>> > moving them into the pblic fields will not make them match where
>> > they where in 3.0, which is the problem we have
>> >
>>
>> They are already in the wrong position, and they are marked explicitly
>> as private fields, so any app using them is doing it wrong, we should
>> not break the actual public ABI to cater to that.
>> Moving codecpar now seems like a bad solution, as in contrast to these
>> fields, codecpar is full public API/ABI and is in a release already
>> (even if its only a few days old).
>>
>
>> Adding new accessors will also not fix those old apps, since old
>> ffmpeg wouldnt have the accessor,
>
> Backporting the accessors is very simple
>
>
>> so its no better then any other
>> solution, and since we stopped caring about ABI compat with libav, the
>> primary reason for them has also vanished.
>> So I would vote for moving private fields that should be public right
>> above the private marker and be done with it.
>
> As this doesnt solve the ABI problem it would not help with this issue
> or the distributions who want (but cannot) ship FFmpeg 3.1
>
> Please tell me how you prefer the ABI issue with 3.0 / 3.1 to be
> fixed
I prefer not to, since the public ABI is not broken.
We have many contexts with a public and private part, and we have
added public fields above the private marker before. Whats different
in 3.1 that this is a problem suddenly?
We all know ffmpeg.c and ffplay.c violate the API/ABI in some places,
that should be fixed, but is not something "new" to 3.1
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/frame: Move new field to the end of AVFrame
On 6/29/2016 5:31 PM, Michael Niedermayer wrote:
> This is a similar ABI fix to 1eb43af1a0e542ad83dcbf327197785d815fc42d
> ---
> libavutil/frame.h | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 44adec4..2b5c332 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -428,12 +428,6 @@ typedef struct AVFrame {
> enum AVChromaLocation chroma_location;
>
> /**
> - * For hwaccel-format frames, this should be a reference to the
> - * AVHWFramesContext describing the frame.
> - */
> -AVBufferRef *hw_frames_ctx;
> -
> -/**
> * frame timestamp estimated using various heuristics, in stream time
> base
> * Code outside libavutil should access this field using:
> * av_frame_get_best_effort_timestamp(frame)
> @@ -524,6 +518,11 @@ typedef struct AVFrame {
> */
> AVBufferRef *qp_table_buf;
> #endif
> +/**
> + * For hwaccel-format frames, this should be a reference to the
> + * AVHWFramesContext describing the frame.
> + */
> +AVBufferRef *hw_frames_ctx;
> } AVFrame;
>
> /**
>
As Hendrik said, every field below hw_frames_ctx is clearly stated as no direct
access. Library users should have not used any of those fields directly to begin
with. Any breakage product of the addition of a new public field moving the
offset of no direct access fields is their responsibility.
This is not something new. Private fields in public structs is something ffmpeg
and even libav has featured for years now.
This commit will break libavutil ABI from 3.1 to 3.1.1 by moving a public access
field around. In contrast, leaving things as is will keep everything from 3.0
onwards compatible if every field is properly accessed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] web: Remove recommandition to upgrade to 3.1
The 3.1 release has some minor ABI incompatibilities compared to 3.0 The fixes of moving struct members or adding getters are disliked bumping major soname also is disliked by the community In case a consensus is found about how to deal with the issue, the recommandition can be put back --- src/index |5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/src/index b/src/index index eb66060..a7bc1d3 100644 --- a/src/index +++ b/src/index @@ -88,10 +88,7 @@ YUY2 Lossless Codec decoder VideoToolbox H.264 encoder - -We strongly recommend users, distributors, and system integrators to -upgrade unless they use current git master. - + March 16th, 2016, Google Summer of Code -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf: mark stream as const pointer in av_stream_get_side_data()
On Mon, Jun 27, 2016 at 12:10:53PM +0200, Clément Bœsch wrote: > From: Clément Bœsch > > TODO: bump lavf minor > XXX: should i add a FF_API_NOCONST_GET_SIDE_DATA? > --- > libavformat/avformat.h | 2 +- > libavformat/utils.c| 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > ping -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] web/index: warn about tools from FFmpeg 3.0 being incompatible with 3.1
Signed-off-by: James Almer --- Suggestions about wording and such are of course welcome. src/index | 4 1 file changed, 4 insertions(+) diff --git a/src/index b/src/index index eb66060..b67d281 100644 --- a/src/index +++ b/src/index @@ -92,6 +92,10 @@ We strongly recommend users, distributors, and system integrators to upgrade unless they use current git master. + NOTE: Users of FFmpeg 3.1 should avoid running the CLI tools ffmpeg and ffprobe from the 3.0 release with libraries from this release due to a bug + making them binary incompatible. + It is for that matter strongly recommended to always update both libraries and tools at the same time. + March 16th, 2016, Google Summer of Code -- 2.8.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/frame: Move new field to the end of AVFrame
On 6/29/2016 10:31 PM, Michael Niedermayer wrote: > This is a similar ABI fix to 1eb43af1a0e542ad83dcbf327197785d815fc42d +1 for this. While it's true that all fields after it are not public API/ABI, a lot of software seems to misuse it, so to avoid too much trouble for now, this should be fixed. We should then talk about how to avoid such problems in the future, i.e. how to make private fields truely private. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/frame: Move new field to the end of AVFrame
On 6/29/2016 7:39 PM, Timo Rothenpieler wrote: > On 6/29/2016 10:31 PM, Michael Niedermayer wrote: >> This is a similar ABI fix to 1eb43af1a0e542ad83dcbf327197785d815fc42d > > +1 for this. > > While it's true that all fields after it are not public API/ABI, a lot > of software seems to misuse it, so to avoid too much trouble for now, > this should be fixed. How do you expect library users to start using the API correctly if every time they do something wrong we are the ones that rush to break our code just to adapt to their mistakes? > > We should then talk about how to avoid such problems in the future, i.e. > how to make private fields truely private. Yes, this is already decided. No direct access fields product of the old libav compat attempts will be turned public as required, and everything else will be shoved inside an opaque *internal struct, similar to existing ones. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/frame: Move new field to the end of AVFrame
>> While it's true that all fields after it are not public API/ABI, a lot >> of software seems to misuse it, so to avoid too much trouble for now, >> this should be fixed. > > How do you expect library users to start using the API correctly if every > time they do something wrong we are the ones that rush to break our code > just to adapt to their mistakes? During an actual major bump, where such breakage is expected. A lot of stuff gets it wrong, and it is indeed confusing, so putting all blame on API users seems wrong to me. Specially as this issue will block distributions from adapting 3.1. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/frame: Move new field to the end of AVFrame
On 6/29/2016 7:50 PM, Timo Rothenpieler wrote: >>> While it's true that all fields after it are not public API/ABI, a lot >>> of software seems to misuse it, so to avoid too much trouble for now, >>> this should be fixed. >> >> How do you expect library users to start using the API correctly if every >> time they do something wrong we are the ones that rush to break our code >> just to adapt to their mistakes? > > During an actual major bump, where such breakage is expected. > A lot of stuff gets it wrong, and it is indeed confusing, so putting all > blame on API users seems wrong to me. Specially as this issue will block > distributions from adapting 3.1. How? Just like they are updating to 3.1, they can update to the new versions of said library users with their api usage fixed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/frame: Move new field to the end of AVFrame
>> During an actual major bump, where such breakage is expected. >> A lot of stuff gets it wrong, and it is indeed confusing, so putting all >> blame on API users seems wrong to me. Specially as this issue will block >> distributions from adapting 3.1. > > How? Just like they are updating to 3.1, they can update to the new versions > of said library users with their api usage fixed. Well, they could do that. But a lot of them won't, and instead stay on ffmpeg 3.0, as it's the path of least resistance. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/frame: Move new field to the end of AVFrame
On Thu, Jun 30, 2016 at 12:50 AM, Timo Rothenpieler wrote: >>> While it's true that all fields after it are not public API/ABI, a lot >>> of software seems to misuse it, so to avoid too much trouble for now, >>> this should be fixed. >> >> How do you expect library users to start using the API correctly if every >> time they do something wrong we are the ones that rush to break our code >> just to adapt to their mistakes? > > During an actual major bump, where such breakage is expected. > A lot of stuff gets it wrong, and it is indeed confusing, so putting all > blame on API users seems wrong to me. Specially as this issue will block > distributions from adapting 3.1. Plenty previous releases moved fields that were marked as "no direct access", usually because libav added a new field above the ffmpeg-exclusive ones (like AVFrame.channels, which is a common candidate), and we didn't do such a song and dance to accomodate everyone. I asked this in other threads before - why this time? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web/index: warn about tools from FFmpeg 3.0 being incompatible with 3.1
James Almer gmail.com> writes: > + NOTE: Users of FFmpeg 3.1 should avoid running > the CLI tools ffmpeg and ffprobe from the 3.0 release with > libraries from this release Since nobody wants to do this, I don't think this warning is necessary. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/frame: Move new field to the end of AVFrame
On Thu, Jun 30, 2016 at 01:25:59AM +0200, Hendrik Leppkes wrote: > On Thu, Jun 30, 2016 at 12:50 AM, Timo Rothenpieler > wrote: > >>> While it's true that all fields after it are not public API/ABI, a lot > >>> of software seems to misuse it, so to avoid too much trouble for now, > >>> this should be fixed. > >> > >> How do you expect library users to start using the API correctly if every > >> time they do something wrong we are the ones that rush to break our code > >> just to adapt to their mistakes? > > > > During an actual major bump, where such breakage is expected. > > A lot of stuff gets it wrong, and it is indeed confusing, so putting all > > blame on API users seems wrong to me. Specially as this issue will block > > distributions from adapting 3.1. > > Plenty previous releases moved fields that were marked as "no direct > access", usually because libav added a new field above the > ffmpeg-exclusive ones (like AVFrame.channels, which is a common > candidate), and we didn't do such a song and dance to accomodate > everyone. > I asked this in other threads before - why this time? because it caused bugs this time which we could fix, previously either we couldnt fix them without breaking something else or noone was affected/reported anything or we did fix them [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web: Remove recommandition to upgrade to 3.1
Michael Niedermayer niedermayer.cc> writes: > -We strongly recommend users, distributors, and system integrators to > -upgrade unless they use current git master. This makes sense imo. Thank you for trying to fix the issues, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web: Remove recommandition to upgrade to 3.1
Hi, On Wed, Jun 29, 2016 at 8:13 PM, Carl Eugen Hoyos wrote: > Michael Niedermayer niedermayer.cc> writes: > > > -We strongly recommend users, distributors, and system integrators to > > -upgrade unless they use current git master. > > This makes sense imo. > > Thank you for trying to fix the issues, Carl Eugen For the record: there was some discussion related to this on IRC. Probably read that (maybe someone can c/p logs?) to prevent rehashing that discussion here. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web: Remove recommandition to upgrade to 3.1
Ronald S. Bultje gmail.com> writes: > For the record: there was some discussion related to this on IRC. Would you mind adding some relevant points here? I was under the impression that this mailing list is the main place for FFmpeg patch discussions, no? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/frame: Move new field to the end of AVFrame
Hendrik Leppkes gmail.com> writes: > Plenty previous releases moved fields that were marked as "no direct > access", usually because libav added a new field above the > ffmpeg-exclusive ones (like AVFrame.channels, which is a common > candidate), and we didn't do such a song and dance to accomodate > everyone. > I asked this in other threads before - why this time? I thought the difference is that for all other fields we offered accessors that the API users could use to access the fields. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/frame: Move new field to the end of AVFrame
On 6/29/2016 9:16 PM, Carl Eugen Hoyos wrote: > Hendrik Leppkes gmail.com> writes: > >> Plenty previous releases moved fields that were marked as "no direct >> access", usually because libav added a new field above the >> ffmpeg-exclusive ones (like AVFrame.channels, which is a common >> candidate), and we didn't do such a song and dance to accomodate >> everyone. > >> I asked this in other threads before - why this time? > > I thought the difference is that for all other fields > we offered accessors that the API users could use to > access the fields. > > Carl Eugen They have accessors. All the private fields in AVFrame have accessors. The issue is that at least three projects weren't using them, and things broke for them as soon as the private fields moved. This patch here attempts to break our ABI to accommodate the fact said projects weren't using the accessors, when the real solution for distros is to rebuild said packages targeting 3.1 and for those projects to use the accessors. One of them (Kodi) already fixed their code[1], for that matter. [1] https://github.com/xbmc/xbmc/pull/10043 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv4] lavf: add libopenmpt demuxer
Fixes ticket #5623
TODO: bump lavf minor
---
Changelog| 1 +
configure| 4 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/libopenmpt.c | 200 +++
5 files changed, 207 insertions(+)
create mode 100644 libavformat/libopenmpt.c
diff --git a/Changelog b/Changelog
index 99cdb80..67e433b 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest
within each release,
releases are sorted from youngest to oldest.
version :
+- libopenmpt demuxer
version 3.1:
diff --git a/configure b/configure
index 007c953..74f249f 100755
--- a/configure
+++ b/configure
@@ -245,6 +245,7 @@ External library support:
--enable-libopencv enable video filtering via libopencv [no]
--enable-libopenh264 enable H.264 encoding via OpenH264 [no]
--enable-libopenjpeg enable JPEG 2000 de/encoding via OpenJPEG [no]
+ --enable-libopenmpt enable decoding tracked files via libopenmpt [no]
--enable-libopus enable Opus de/encoding via libopus [no]
--enable-libpulseenable Pulseaudio input via libpulse [no]
--enable-librubberband enable rubberband needed for rubberband filter [no]
@@ -1505,6 +1506,7 @@ EXTERNAL_LIBRARY_LIST="
libopencv
libopenh264
libopenjpeg
+libopenmpt
libopus
libpulse
librtmp
@@ -2769,6 +2771,7 @@ libopencore_amrwb_decoder_deps="libopencore_amrwb"
libopenh264_encoder_deps="libopenh264"
libopenjpeg_decoder_deps="libopenjpeg"
libopenjpeg_encoder_deps="libopenjpeg"
+libopenmpt_demuxer_deps="libopenmpt"
libopus_decoder_deps="libopus"
libopus_encoder_deps="libopus"
libopus_encoder_select="audio_frame_queue"
@@ -5678,6 +5681,7 @@ enabled libopenjpeg && { check_lib
openjpeg-2.1/openjpeg.h opj_version -lo
check_lib openjpeg-1.5/openjpeg.h opj_version
-lopenjpeg -DOPJ_STATIC ||
check_lib openjpeg.h opj_version -lopenjpeg
-DOPJ_STATIC ||
die "ERROR: libopenjpeg not found"; }
+enabled libopenmpt&& require_pkg_config "libopenmpt >= 0.2.6557"
libopenmpt/libopenmpt.h openmpt_module_create
enabled libopus && require_pkg_config opus opus_multistream.h
opus_multistream_decoder_create
enabled libpulse && require_pkg_config libpulse pulse/pulseaudio.h
pa_context_new
enabled librtmp && require_pkg_config librtmp librtmp/rtmp.h
RTMP_Socket
diff --git a/libavformat/Makefile b/libavformat/Makefile
index c49f9de..6451c1c 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -527,6 +527,7 @@ OBJS-$(CONFIG_LIBGME_DEMUXER)+= libgme.o
OBJS-$(CONFIG_LIBMODPLUG_DEMUXER)+= libmodplug.o
OBJS-$(CONFIG_LIBNUT_DEMUXER)+= libnut.o
OBJS-$(CONFIG_LIBNUT_MUXER) += libnut.o
+OBJS-$(CONFIG_LIBOPENMPT_DEMUXER)+= libopenmpt.o
OBJS-$(CONFIG_LIBRTMP) += librtmp.o
OBJS-$(CONFIG_LIBSSH_PROTOCOL) += libssh.o
OBJS-$(CONFIG_LIBSMBCLIENT_PROTOCOL) += libsmbclient.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index d490cc4..58c33a6 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -375,6 +375,7 @@ void av_register_all(void)
REGISTER_DEMUXER (LIBGME, libgme);
REGISTER_DEMUXER (LIBMODPLUG, libmodplug);
REGISTER_MUXDEMUX(LIBNUT, libnut);
+REGISTER_DEMUXER (LIBOPENMPT, libopenmpt);
initialized = 1;
}
diff --git a/libavformat/libopenmpt.c b/libavformat/libopenmpt.c
new file mode 100644
index 000..c9e0a8e
--- /dev/null
+++ b/libavformat/libopenmpt.c
@@ -0,0 +1,200 @@
+/*
+ * Tracked MOD demuxer (libopenmpt)
+ * Copyright (c) 2016 Josh de Kock
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+
+#include "libavutil/avstring.h"
+#include "libavutil/opt.h"
+#include "avformat.h"
+#include "internal.h"
+
+typedef struct OpenMPTContext {
+const AVClass *class;
+openmpt_module *module;
+
+int channels;
+double duration;
+/* options */
+int sample_rate;
+int64_t layout;
+} OpenMPTContext;
+
+#define OFFSET(
Re: [FFmpeg-devel] [PATCH] web: Remove recommandition to upgrade to 3.1
On 6/29/2016 9:27 PM, Carl Eugen Hoyos wrote: > Ronald S. Bultje gmail.com> writes: > >> For the record: there was some discussion related to this on IRC. > > Would you mind adding some relevant points here? > I was under the impression that this mailing list > is the main place for FFmpeg patch discussions, no? > > Carl Eugen [18:37:47] <@BBB> we should recommend that people upgrade to 3.1 tools-and-libs-at-the-same-time [18:45:42] and i agree with BBB, instead of removing the recommendation, just make it clear that tools and libraries should ideally be updated at the same time and not mixed [18:48:11] jamrial, can you post a patch that changes thre recomandition to all libs/tools or changes the release notes ? [18:50:13] michaelni: alright I'm fine with this patch or the one i sent. I'm not going to block either. I think it's more important to see how will distros deal with mpv, kodi and chromium built targeting 3.0 not working using 3.1 libraries at runtime because they misuse the api. We could try to contact maintainers for some of them (The kind that will try to upgrade to 3.1 soon, like Arch) to let them know about this so they also update the three packages above alongside ffmpeg and don't go crazy trying to find why it doesn't work otherwise, or flood our bug tracker. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/frame: Move new field to the end of AVFrame
On 6/29/2016 9:47 PM, James Almer wrote: > On 6/29/2016 9:16 PM, Carl Eugen Hoyos wrote: >> Hendrik Leppkes gmail.com> writes: >> >>> Plenty previous releases moved fields that were marked as "no direct >>> access", usually because libav added a new field above the >>> ffmpeg-exclusive ones (like AVFrame.channels, which is a common >>> candidate), and we didn't do such a song and dance to accomodate >>> everyone. >> >>> I asked this in other threads before - why this time? >> >> I thought the difference is that for all other fields >> we offered accessors that the API users could use to >> access the fields. >> >> Carl Eugen > > They have accessors. All the private fields in AVFrame have accessors. > The issue is that at least three projects weren't using them, and things > broke for them as soon as the private fields moved. > > This patch here attempts to break our ABI to accommodate the fact said > projects weren't using the accessors, when the real solution for distros > is to rebuild said packages targeting 3.1 and for those projects to use > the accessors. > > One of them (Kodi) already fixed their code[1], for that matter. > > [1] https://github.com/xbmc/xbmc/pull/10043 For the record, if it really comes to it (distros not wanting to recompile or update the broken downstream packages, or more packages found misusing this api thus making adoption of 3.1 a PITA) I'm willing to concede and let this patch break the 3.1 ABI just so applications built against 3.0 can work with 3.1.1 libraries without the need to be recompiled. 3.1 is young and currently unused by distros, and 3.1.1 will already be incompatible with it because of the AVFilterContext breakage. And since we will after all bump all major versions with ffmpeg 3.2/4.0, the current position of this field will not matter anymore. But I'd very much prefer if we could for once not have to break our own code just so downstream projects can postpone (or never bother) fixing theirs. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
