Re: [FFmpeg-devel] [PATCH] libavformat/rtsp.c: Avoids duplicated slashes in the RTSP URL Signed-off-by: Frederic Pillonel
On Wed, Jan 23, 2019 at 08:11:48AM +, f...@gmx.ch wrote:
> From: Frederic Pillonel
>
> ---
> libavformat/rtsp.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index ceb770a..3cc9012f 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@ -548,9 +548,10 @@ static void sdp_parse_line(AVFormatContext *s,
> SDPParseState *s1,
> NULL, NULL, 0, p);
> if (proto[0] == '\0') {
> /* relative control URL */
> -if
> (rtsp_st->control_url[strlen(rtsp_st->control_url)-1]!='/')
> -av_strlcat(rtsp_st->control_url, "/",
> - sizeof(rtsp_st->control_url));
> +if
> (rtsp_st->control_url[strlen(rtsp_st->control_url)-1]!='/' &&
> +(strlen(p) > 0 && p[0]!='/'))
> +av_strlcat(rtsp_st->control_url, "/",
> +sizeof(rtsp_st->control_url));
is this actually correct ?
if the added path starts with a / shouldnt it be an absolute path ?
IIUC https://tools.ietf.org/html/rfc1808 needs to be followed here
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is to try to make unequal things equal.
-- Aristotle
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/3] avutil/attributes: add av_likely and av_unlikely
On Thu, Jan 24, 2019 at 06:08:57PM -0300, James Almer wrote: > On 1/24/2019 5:53 PM, Rostislav Pehlivanov wrote: > > On Thu, 24 Jan 2019 at 20:38, Marton Balint wrote: > > > >> Signed-off-by: Marton Balint > >> --- > >> doc/APIchanges | 3 +++ > >> libavutil/attributes.h | 8 > >> libavutil/version.h| 2 +- > >> 3 files changed, 12 insertions(+), 1 deletion(-) > >> > >> diff --git a/doc/APIchanges b/doc/APIchanges > >> index a39a3ff2ba..38b5b980a6 100644 > >> --- a/doc/APIchanges > >> +++ b/doc/APIchanges > >> @@ -15,6 +15,9 @@ libavutil: 2017-10-21 > >> > >> API changes, most recent first: > >> > >> +2019-01-xx - xx - lavu 56.27.100 - attributes.h > >> + Add av_likely and av_unlikely > >> + > >> 2019-01-08 - xx - lavu 56.26.100 - frame.h > >>Add AV_FRAME_DATA_REGIONS_OF_INTEREST > >> > >> diff --git a/libavutil/attributes.h b/libavutil/attributes.h > >> index ced108aa2c..60972e5109 100644 > >> --- a/libavutil/attributes.h > >> +++ b/libavutil/attributes.h > >> @@ -164,4 +164,12 @@ > >> #define av_noreturn > >> #endif > >> > >> +#if AV_GCC_VERSION_AT_LEAST(2,96) || defined(__clang__) > >> +# define av_likely(x) __builtin_expect(!!(x), 1) > >> +# define av_unlikely(x)__builtin_expect(!!(x), 0) > >> +#else > >> +# define av_likely(x) (x) > >> +# define av_unlikely(x)(x) > >> +#endif > >> + > >> #endif /* AVUTIL_ATTRIBUTES_H */ > >> diff --git a/libavutil/version.h b/libavutil/version.h > >> index 1fcdea95bf..12b4f9fc3a 100644 > >> --- a/libavutil/version.h > >> +++ b/libavutil/version.h > >> @@ -79,7 +79,7 @@ > >> */ > >> > >> #define LIBAVUTIL_VERSION_MAJOR 56 > >> -#define LIBAVUTIL_VERSION_MINOR 26 > >> +#define LIBAVUTIL_VERSION_MINOR 27 > >> #define LIBAVUTIL_VERSION_MICRO 100 > >> > >> #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \ > >> -- > >> 2.16.4 > >> > >> ___ > >> ffmpeg-devel mailing list > >> ffmpeg-devel@ffmpeg.org > >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > > > NAK, NAK, NAK. > > I will NAK the hell out of any patch that does that. They're completely > > unnecessary, they're commonly used by complete idiots who add them thinking > > their code will go faster (and it might - only on their antiquated GCC > > 3.1), they're religiously used by the same people and won't back down on > > using them and finally they're ugly when added to every single bloody > > branch and the people who maintain such code will demand they be added to > > every single bloody branch for no reason other that what I've just iterated > > on. > > The ONLY way I'll accept them is in platform-specific files, e.g. > > libavcodec/ppc/*, and even then only on non-x86 arches (which need them for > > having bad compilers with primitive processors having awful branch > > prediction) and even then I'd never accept their inclusioin into > > system-installed headers. > > What about hot loops with branches where you can use these as a hint for > the compiler to assume a specific outcome is highly unlikely to happen, > like alloc errors, corner cases in some codec, etc, which it simply has > no way to correctly guess at compile time? > > I don't think it should be NAKed because it's misused in other projects. > We're not other projects. We should instead simply ask the patch writer > to provide numbers that prove using it makes a difference in their code > with a recent version of GCC/Clang, and if it's negligible or within the > margin of error we'll simply ask to remove it to keep the code clean. if we want to ensure this, it can be enforced easily we have fate-source, that can check litterally for each av_(un)likely to contain a comment on the same line listing a non negligible performance effect. as in // branch hint increases speed by 5% OTOH, it may make more sense to gather branch statistics at runtime and include that in the next build without smudging the source thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avutil/attributes: add av_likely and av_unlikely
Signed-off-by: Marton Balint --- doc/APIchanges | 3 +++ libavutil/attributes.h | 8 libavutil/version.h| 2 +- 3 files changed, 12 insertions(+), 1 deletion(-) diff --git a/doc/APIchanges b/doc/APIchanges index a39a3ff2ba..38b5b980a6 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -15,6 +15,9 @@ libavutil: 2017-10-21 API changes, most recent first: +2019-01-xx - xx - lavu 56.27.100 - attributes.h + Add av_likely and av_unlikely + 2019-01-08 - xx - lavu 56.26.100 - frame.h Add AV_FRAME_DATA_REGIONS_OF_INTEREST diff --git a/libavutil/attributes.h b/libavutil/attributes.h index ced108aa2c..60972e5109 100644 --- a/libavutil/attributes.h +++ b/libavutil/attributes.h @@ -164,4 +164,12 @@ #define av_noreturn #endif +#if AV_GCC_VERSION_AT_LEAST(2,96) || defined(__clang__) +# define av_likely(x) __builtin_expect(!!(x), 1) +# define av_unlikely(x)__builtin_expect(!!(x), 0) +#else +# define av_likely(x) (x) +# define av_unlikely(x)(x) +#endif + #endif /* AVUTIL_ATTRIBUTES_H */ diff --git a/libavutil/version.h b/libavutil/version.h index 1fcdea95bf..12b4f9fc3a 100644 --- a/libavutil/version.h +++ b/libavutil/version.h @@ -79,7 +79,7 @@ */ #define LIBAVUTIL_VERSION_MAJOR 56 -#define LIBAVUTIL_VERSION_MINOR 26 +#define LIBAVUTIL_VERSION_MINOR 27 #define LIBAVUTIL_VERSION_MICRO 100 #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \ -- 2.16.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avformat/mpegts: cache PID discard values
discard_pid can be quite expensive, so let's cache it and recalculate it on
every packet start.
ffmpeg -y -i samples/MPEG-VOB/sdtv/RAI.ts -c copy -map 0:v:0 -map 0:a:0 -f
mpegts /dev/null
Before:
1685 decicycles in handle_packet, 523483 runs,805 skips
After:
883 decicycles in handle_packet, 523505 runs,783 skips
Signed-off-by: Marton Balint
---
libavformat/mpegts.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 300db110d4..b04fd7b4f4 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -91,6 +91,7 @@ struct MpegTSFilter {
int es_id;
int last_cc; /* last cc code (-1 if first packet) */
int64_t last_pcr;
+int discard;
enum MpegTSFilterType type;
union {
MpegTSPESFilter pes_filter;
@@ -2474,8 +2475,6 @@ static int handle_packet(MpegTSContext *ts, const uint8_t
*packet)
int64_t pos;
pid = AV_RB16(packet + 1) & 0x1fff;
-if (pid && discard_pid(ts, pid))
-return 0;
is_start = packet[1] & 0x40;
tss = ts->pids[pid];
if (ts->auto_guess && !tss && is_start) {
@@ -2484,6 +2483,10 @@ static int handle_packet(MpegTSContext *ts, const
uint8_t *packet)
}
if (!tss)
return 0;
+if (is_start)
+tss->discard = discard_pid(ts, pid);
+if (tss->discard)
+return 0;
ts->current_pid = pid;
afc = (packet[3] >> 4) & 3;
--
2.16.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avutil/attributes: add av_likely and av_unlikely
On 24/01/2019 20:53, Rostislav Pehlivanov wrote: > NAK, NAK, NAK. Seconded. Please, please, no. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] lavc/qsvdec: add function ff_qsv_map_picstruct()
On Mon, 2019-01-21 at 20:41 +0800, Zhong Li wrote:
> Signed-off-by: Zhong Li
> ---
> libavcodec/qsv.c | 18 ++
> libavcodec/qsv_internal.h | 2 ++
> 2 files changed, 20 insertions(+)
>
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> index bb0d795..224bc00 100644
> --- a/libavcodec/qsv.c
> +++ b/libavcodec/qsv.c
> @@ -196,6 +196,24 @@ int ff_qsv_find_surface_idx(QSVFramesContext
> *ctx, QSVFrame *frame)
> return AVERROR_BUG;
> }
>
> +enum AVFieldOrder ff_qsv_map_picstruct(int mfx_pic_struct)
> +{
> +enum AVFieldOrder field = AV_FIELD_UNKNOWN;
> +switch (mfx_pic_struct & 0xF) {
> +case MFX_PICSTRUCT_PROGRESSIVE:
> +field = AV_FIELD_PROGRESSIVE;
> +break;
> +case MFX_PICSTRUCT_FIELD_TFF:
> +field = AV_FIELD_TT;
> +break;
> +case MFX_PICSTRUCT_FIELD_BFF:
> +field = AV_FIELD_BB;
> +break;
> +}
> +
> +return field;
> +}
> +
> enum AVPictureType ff_qsv_map_pictype(int mfx_pic_type)
> {
> enum AVPictureType type;
> diff --git a/libavcodec/qsv_internal.h b/libavcodec/qsv_internal.h
> index 394c558..51c23d5 100644
> --- a/libavcodec/qsv_internal.h
> +++ b/libavcodec/qsv_internal.h
> @@ -94,6 +94,8 @@ int ff_qsv_profile_to_mfx(enum AVCodecID codec_id,
> int profile);
> int ff_qsv_map_pixfmt(enum AVPixelFormat format, uint32_t *fourcc);
> enum AVPictureType ff_qsv_map_pictype(int mfx_pic_type);
>
> +enum AVFieldOrder ff_qsv_map_picstruct(int mfx_pic_struct);
> +
> int ff_qsv_init_internal_session(AVCodecContext *avctx, mfxSession
> *session,
> const char *load_plugins);
>
Not sure why this is a separate patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] lavc/qsvdec: Add mjpeg decoder support
On Mon, 2019-01-21 at 20:41 +0800, Zhong Li wrote:
> Signed-off-by: Zhong Li
> ---
> Changelog | 1 +
> configure | 1 +
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c| 1 +
> libavcodec/qsvdec_other.c | 28 +++-
> 5 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/Changelog b/Changelog
> index 422d84e..bf76613 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -14,6 +14,7 @@ version :
> - vividas demuxer
> - hymt decoder
> - anlmdn filter
> +- Intel QSV-accelerated MJPEG decoding
>
>
> version 4.1:
> diff --git a/configure b/configure
> index 946f534..ac71ecf 100755
> --- a/configure
> +++ b/configure
> @@ -2981,6 +2981,7 @@ hevc_v4l2m2m_decoder_deps="v4l2_m2m
> hevc_v4l2_m2m"
> hevc_v4l2m2m_decoder_select="hevc_mp4toannexb_bsf"
> hevc_v4l2m2m_encoder_deps="v4l2_m2m hevc_v4l2_m2m"
> mjpeg_cuvid_decoder_deps="cuvid"
> +mjpeg_qsv_decoder_select="qsvdec"
> mjpeg_qsv_encoder_deps="libmfx"
> mjpeg_qsv_encoder_select="qsvenc"
> mjpeg_vaapi_encoder_deps="VAEncPictureParameterBufferJPEG"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 99799ce..df5912c 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -421,6 +421,7 @@ OBJS-$(CONFIG_METASOUND_DECODER) +=
> metasound.o metasound_data.o \
> OBJS-$(CONFIG_MICRODVD_DECODER)+= microdvddec.o ass.o
> OBJS-$(CONFIG_MIMIC_DECODER) += mimic.o
> OBJS-$(CONFIG_MJPEG_DECODER) += mjpegdec.o
> +OBJS-$(CONFIG_MJPEG_QSV_DECODER) += qsvdec_other.o
> OBJS-$(CONFIG_MJPEG_ENCODER) += mjpegenc.o
> mjpegenc_common.o \
> mjpegenc_huffman.o
> OBJS-$(CONFIG_MJPEGB_DECODER) += mjpegbdec.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 4755af7..32cca0c 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -756,6 +756,7 @@ extern AVCodec ff_hevc_videotoolbox_encoder;
> extern AVCodec ff_libkvazaar_encoder;
> extern AVCodec ff_mjpeg_cuvid_decoder;
> extern AVCodec ff_mjpeg_qsv_encoder;
> +extern AVCodec ff_mjpeg_qsv_decoder;
> extern AVCodec ff_mjpeg_vaapi_encoder;
> extern AVCodec ff_mpeg1_cuvid_decoder;
> extern AVCodec ff_mpeg2_cuvid_decoder;
> diff --git a/libavcodec/qsvdec_other.c b/libavcodec/qsvdec_other.c
> index 03251d2..ba490d4 100644
> --- a/libavcodec/qsvdec_other.c
> +++ b/libavcodec/qsvdec_other.c
> @@ -1,5 +1,5 @@
> /*
> - * Intel MediaSDK QSV based MPEG-2, VC-1 and VP8 decoders
> + * Intel MediaSDK QSV based MPEG-2, VC-1, VP8 and MJPEG decoders
> *
> * copyright (c) 2015 Anton Khirnov
> *
> @@ -255,3 +255,29 @@ AVCodec ff_vp8_qsv_decoder = {
> .wrapper_name = "qsv",
> };
> #endif
> +
> +#if CONFIG_MJPEG_QSV_DECODER
> +static const AVClass mjpeg_qsv_class = {
> +.class_name = "mjpeg_qsv",
> +.item_name = av_default_item_name,
> +.option = options,
> +.version= LIBAVUTIL_VERSION_INT,
> +};
> +
> +AVCodec ff_mjpeg_qsv_decoder = {
> +.name = "mjpeg_qsv",
> +.long_name = NULL_IF_CONFIG_SMALL("MJPEG video (Intel Quick
> Sync Video acceleration)"),
> +.priv_data_size = sizeof(QSVOtherContext),
> +.type = AVMEDIA_TYPE_VIDEO,
> +.id = AV_CODEC_ID_MJPEG,
> +.init = qsv_decode_init,
> +.decode = qsv_decode_frame,
> +.flush = qsv_decode_flush,
> +.close = qsv_decode_close,
> +.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_DR1 |
> AV_CODEC_CAP_AVOID_PROBING | AV_CODEC_CAP_HYBRID,
> +.priv_class = _qsv_class,
> +.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_NV12,
I believe that mediasdk jpeg decoder can also support RGB32 and YUY2 on
the output. Do you plan to add support later on?
> +AV_PIX_FMT_QSV,
> +AV_PIX_FMT_NONE
> },
> +};
> +#endif
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avutil/attributes: add av_likely and av_unlikely
On Thu, 24 Jan 2019, James Almer wrote: On 1/24/2019 5:53 PM, Rostislav Pehlivanov wrote: On Thu, 24 Jan 2019 at 20:38, Marton Balint wrote: Signed-off-by: Marton Balint --- doc/APIchanges | 3 +++ libavutil/attributes.h | 8 libavutil/version.h| 2 +- 3 files changed, 12 insertions(+), 1 deletion(-) diff --git a/doc/APIchanges b/doc/APIchanges index a39a3ff2ba..38b5b980a6 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -15,6 +15,9 @@ libavutil: 2017-10-21 API changes, most recent first: +2019-01-xx - xx - lavu 56.27.100 - attributes.h + Add av_likely and av_unlikely + 2019-01-08 - xx - lavu 56.26.100 - frame.h Add AV_FRAME_DATA_REGIONS_OF_INTEREST diff --git a/libavutil/attributes.h b/libavutil/attributes.h index ced108aa2c..60972e5109 100644 --- a/libavutil/attributes.h +++ b/libavutil/attributes.h @@ -164,4 +164,12 @@ #define av_noreturn #endif +#if AV_GCC_VERSION_AT_LEAST(2,96) || defined(__clang__) +# define av_likely(x) __builtin_expect(!!(x), 1) +# define av_unlikely(x)__builtin_expect(!!(x), 0) +#else +# define av_likely(x) (x) +# define av_unlikely(x)(x) +#endif + #endif /* AVUTIL_ATTRIBUTES_H */ diff --git a/libavutil/version.h b/libavutil/version.h index 1fcdea95bf..12b4f9fc3a 100644 --- a/libavutil/version.h +++ b/libavutil/version.h @@ -79,7 +79,7 @@ */ #define LIBAVUTIL_VERSION_MAJOR 56 -#define LIBAVUTIL_VERSION_MINOR 26 +#define LIBAVUTIL_VERSION_MINOR 27 #define LIBAVUTIL_VERSION_MICRO 100 #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \ -- 2.16.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel NAK, NAK, NAK. I will NAK the hell out of any patch that does that. They're completely unnecessary, they're commonly used by complete idiots who add them thinking their code will go faster (and it might - only on their antiquated GCC 3.1), they're religiously used by the same people and won't back down on using them and finally they're ugly when added to every single bloody branch and the people who maintain such code will demand they be added to every single bloody branch for no reason other that what I've just iterated on. The ONLY way I'll accept them is in platform-specific files, e.g. libavcodec/ppc/*, and even then only on non-x86 arches (which need them for having bad compilers with primitive processors having awful branch prediction) and even then I'd never accept their inclusioin into system-installed headers. What about hot loops with branches where you can use these as a hint for the compiler to assume a specific outcome is highly unlikely to happen, like alloc errors, corner cases in some codec, etc, which it simply has no way to correctly guess at compile time? I don't think it should be NAKed because it's misused in other projects. We're not other projects. We should instead simply ask the patch writer to provide numbers that prove using it makes a difference in their code with a recent version of GCC/Clang, and if it's negligible or within the margin of error we'll simply ask to remove it to keep the code clean. Well, the reason behind it is patch 3/3 where it matters accordig to my tests. I wonder if it is only my compiler version where it makes a difference. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/motion_est: remove duplicate function
On Thu, Jan 24, 2019 at 10:23:33PM +0100, Marton Balint wrote: > > > On Sun, 20 Jan 2019, Michael Niedermayer wrote: > > >On Sun, Jan 20, 2019 at 07:35:18PM +0100, Marton Balint wrote: > >> > >> > >>On Sun, 20 Jan 2019, Michael Niedermayer wrote: > >> > >>>On Sat, Jan 19, 2019 at 11:48:39PM +0100, Marton Balint wrote: > Signed-off-by: Marton Balint > --- > libavcodec/motion_est.c | 4 +-- > libavcodec/motion_est_template.c | 62 > +--- > 2 files changed, 3 insertions(+), 63 deletions(-) > >>> > >>>please check if the compiler optimizes the size constant out after this > >>>change > >> > >>The compiler inlines the function before and after the change as well. I > >>can't see notable changes in the disassembly of interlaced_search and > >>h263_mv4_search. Is this enough, or something else should be checked? I am > >>not sure how... > > > >If the inlined code is used with only one size value then its probably ok. > >you could also put some marker with asm() in the code where size is used > >and then look at the .s file generated if the size is optimized out or > >still read as a variable > > I checked the .s file and a constant is pushed to the stack as the size > parameter when funny_diamond_search is called in h263_mv4_search and > interlaced_search. > > So yes, the size parameter is still optimized as a constant in the touched > functions. i guess its ok then thanks for checking [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avformat/mpegts: use av_unlikely for detecting unknown streams
Strangely the previous commit caused a slowdown in overall performance and
this fixes it. I used gcc 7.3.1. Does anybody else see this?
time ffprobe -show_packets
samples/ffmpeg-bugs/trac/ticket6132/Samsung_HDR_-_Chasing_the_Light.ts >
/dev/null
Before:
real0m2,010s
user0m1,413s
sys 0m0,596s
After:
real0m1,948s
user0m1,355s
sys 0m0,592s
Signed-off-by: Marton Balint
---
libavformat/mpegts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index b04fd7b4f4..3003739b38 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2477,7 +2477,7 @@ static int handle_packet(MpegTSContext *ts, const uint8_t
*packet)
pid = AV_RB16(packet + 1) & 0x1fff;
is_start = packet[1] & 0x40;
tss = ts->pids[pid];
-if (ts->auto_guess && !tss && is_start) {
+if (av_unlikely(ts->auto_guess && !tss && is_start)) {
add_pes_stream(ts, pid, -1);
tss = ts->pids[pid];
}
--
2.16.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avutil/attributes: add av_likely and av_unlikely
On Thu, 24 Jan 2019 at 20:38, Marton Balint wrote: > Signed-off-by: Marton Balint > --- > doc/APIchanges | 3 +++ > libavutil/attributes.h | 8 > libavutil/version.h| 2 +- > 3 files changed, 12 insertions(+), 1 deletion(-) > > diff --git a/doc/APIchanges b/doc/APIchanges > index a39a3ff2ba..38b5b980a6 100644 > --- a/doc/APIchanges > +++ b/doc/APIchanges > @@ -15,6 +15,9 @@ libavutil: 2017-10-21 > > API changes, most recent first: > > +2019-01-xx - xx - lavu 56.27.100 - attributes.h > + Add av_likely and av_unlikely > + > 2019-01-08 - xx - lavu 56.26.100 - frame.h >Add AV_FRAME_DATA_REGIONS_OF_INTEREST > > diff --git a/libavutil/attributes.h b/libavutil/attributes.h > index ced108aa2c..60972e5109 100644 > --- a/libavutil/attributes.h > +++ b/libavutil/attributes.h > @@ -164,4 +164,12 @@ > #define av_noreturn > #endif > > +#if AV_GCC_VERSION_AT_LEAST(2,96) || defined(__clang__) > +# define av_likely(x) __builtin_expect(!!(x), 1) > +# define av_unlikely(x)__builtin_expect(!!(x), 0) > +#else > +# define av_likely(x) (x) > +# define av_unlikely(x)(x) > +#endif > + > #endif /* AVUTIL_ATTRIBUTES_H */ > diff --git a/libavutil/version.h b/libavutil/version.h > index 1fcdea95bf..12b4f9fc3a 100644 > --- a/libavutil/version.h > +++ b/libavutil/version.h > @@ -79,7 +79,7 @@ > */ > > #define LIBAVUTIL_VERSION_MAJOR 56 > -#define LIBAVUTIL_VERSION_MINOR 26 > +#define LIBAVUTIL_VERSION_MINOR 27 > #define LIBAVUTIL_VERSION_MICRO 100 > > #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \ > -- > 2.16.4 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel NAK, NAK, NAK. I will NAK the hell out of any patch that does that. They're completely unnecessary, they're commonly used by complete idiots who add them thinking their code will go faster (and it might - only on their antiquated GCC 3.1), they're religiously used by the same people and won't back down on using them and finally they're ugly when added to every single bloody branch and the people who maintain such code will demand they be added to every single bloody branch for no reason other that what I've just iterated on. The ONLY way I'll accept them is in platform-specific files, e.g. libavcodec/ppc/*, and even then only on non-x86 arches (which need them for having bad compilers with primitive processors having awful branch prediction) and even then I'd never accept their inclusioin into system-installed headers. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/motion_est: remove duplicate function
On Sun, 20 Jan 2019, Michael Niedermayer wrote: On Sun, Jan 20, 2019 at 07:35:18PM +0100, Marton Balint wrote: On Sun, 20 Jan 2019, Michael Niedermayer wrote: On Sat, Jan 19, 2019 at 11:48:39PM +0100, Marton Balint wrote: Signed-off-by: Marton Balint --- libavcodec/motion_est.c | 4 +-- libavcodec/motion_est_template.c | 62 +--- 2 files changed, 3 insertions(+), 63 deletions(-) please check if the compiler optimizes the size constant out after this change The compiler inlines the function before and after the change as well. I can't see notable changes in the disassembly of interlaced_search and h263_mv4_search. Is this enough, or something else should be checked? I am not sure how... If the inlined code is used with only one size value then its probably ok. you could also put some marker with asm() in the code where size is used and then look at the .s file generated if the size is optimized out or still read as a variable I checked the .s file and a constant is pushed to the stack as the size parameter when funny_diamond_search is called in h263_mv4_search and interlaced_search. So yes, the size parameter is still optimized as a constant in the touched functions. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] lavc/qsvdec: Replace current parser with MFXVideoDECODE_DecodeHeader()
On Thu, 2019-01-24 at 21:43 +, Rogozhkin, Dmitry V wrote:
> On Mon, 2019-01-21 at 20:41 +0800, Zhong Li wrote:
> > Using MSDK parser can improve qsv decoder pass rate in some cases
> > (E.g:
> > sps declares a wrong level_idc, smaller than it should be).
> > And it is necessary for adding new qsv decoders such as MJPEG and
> > VP9
> > since current parser can't provide enough information.
> > Actually using MFXVideoDECODE_DecodeHeader() was disscussed at
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/175734.html and
> > merged as commit 1acb19d,
> > but was overwritten when merged libav patches (commit: 1f26a23)
> > without any explain.
> >
> > Signed-off-by: Zhong Li
> > ---
> > libavcodec/qsvdec.c | 103
> >
> > libavcodec/qsvdec.h | 2 +
> > 2 files changed, 33 insertions(+), 72 deletions(-)
> >
> > diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> > index 4a0be81..013400b 100644
> > --- a/libavcodec/qsvdec.c
> > +++ b/libavcodec/qsvdec.c
> > @@ -120,7 +120,7 @@ static inline unsigned int qsv_fifo_size(const
> > AVFifoBuffer* fifo)
> > return av_fifo_size(fifo) / qsv_fifo_item_size();
> > }
> >
> > -static int qsv_decode_init(AVCodecContext *avctx, QSVContext *q)
> > +static int qsv_decode_init(AVCodecContext *avctx, QSVContext *q,
> > AVPacket *avpkt)
> > {
> > const AVPixFmtDescriptor *desc;
> > mfxSession session = NULL;
> > @@ -129,6 +129,17 @@ static int qsv_decode_init(AVCodecContext
> > *avctx, QSVContext *q)
> > int frame_width = avctx->coded_width;
> > int frame_height = avctx->coded_height;
> > int ret;
> > +mfxBitstream bs = { { { 0 } } };
> > +
> > +if (avpkt->size) {
> > +bs.Data = avpkt->data;
> > +bs.DataLength = avpkt->size;
> > +bs.MaxLength = bs.DataLength;
> > +bs.TimeStamp = avpkt->pts;
> > +if (avctx->field_order == AV_FIELD_PROGRESSIVE)
> > +bs.DataFlag |= MFX_BITSTREAM_COMPLETE_FRAME;
When this flag is passed mediasdk expect that "the bitstream buffer
contains a complete frame or complementary field pair of data for the
bitstream". So, this flag don't generally speaking relates to field
order type. Instead it notifies mediasdk how much data does bitstream
contains. I am not sure how ffmpeg deals with bitstream and breaks it
into packages. Can someone, please, clarify? I am particularly
interested in how very beginning of the bitsream is handled and how
SPS/PPS is being passed since this may have effect on the DecodeHeader
introduced below.
>
> +} else
> > +return AVERROR_INVALIDDATA;
> >
> > desc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
> > if (!desc)
> > @@ -174,32 +185,19 @@ static int qsv_decode_init(AVCodecContext
> > *avctx, QSVContext *q)
> > if (ret < 0)
> > return ret;
> >
> > -param.mfx.CodecId = ret;
> > -param.mfx.CodecProfile = ff_qsv_profile_to_mfx(avctx-
> > >codec_id,
> > avctx->profile);
> > -param.mfx.CodecLevel = avctx->level == FF_LEVEL_UNKNOWN ?
> > MFX_LEVEL_UNKNOWN : avctx->level;
> > -
> > -param.mfx.FrameInfo.BitDepthLuma = desc->comp[0].depth;
> > -param.mfx.FrameInfo.BitDepthChroma = desc->comp[0].depth;
> > -param.mfx.FrameInfo.Shift = desc->comp[0].depth > 8;
> > -param.mfx.FrameInfo.FourCC = q->fourcc;
> > -param.mfx.FrameInfo.Width = frame_width;
> > -param.mfx.FrameInfo.Height = frame_height;
> > -param.mfx.FrameInfo.ChromaFormat = MFX_CHROMAFORMAT_YUV420;
> > -
> > -switch (avctx->field_order) {
> > -case AV_FIELD_PROGRESSIVE:
> > -param.mfx.FrameInfo.PicStruct = MFX_PICSTRUCT_PROGRESSIVE;
> > -break;
> > -case AV_FIELD_TT:
> > -param.mfx.FrameInfo.PicStruct = MFX_PICSTRUCT_FIELD_TFF;
> > -break;
> > -case AV_FIELD_BB:
> > -param.mfx.FrameInfo.PicStruct = MFX_PICSTRUCT_FIELD_BFF;
> > -break;
> > -default:
> > -param.mfx.FrameInfo.PicStruct = MFX_PICSTRUCT_UNKNOWN;
> > -break;
> > -}
> > +param.mfx.CodecId = ret;
> > +ret = MFXVideoDECODE_DecodeHeader(q->session, , );
>
> This function may potentially return MFX_ERR_MORE_DATA if provided
> bitstream don't contain full header. I am not sure whether ffmpeg
> will
> guarantee that... And the decoding error reported by Artie suggests
> that something is wrong around this. That can be ffmpeg or mediasdk
> issue - need to check what was the data which ffmpeg really passed to
> DecodeHeader.
>
> > +if (ret < 0)
> > +return ff_qsv_print_error(avctx, ret,
> > +"Error decoding stream header");
> > +
> > +avctx->width= param.mfx.FrameInfo.CropW;
> > +avctx->height = param.mfx.FrameInfo.CropH;
> > +avctx->coded_width = param.mfx.FrameInfo.Width;
> > +avctx->coded_height = param.mfx.FrameInfo.Height;
> > +avctx->level=
[FFmpeg-devel] [PATCH] vf_showinfo: Fix timecode display
$subj - Indexing is wrong, off by one Kieran 0001-vf_showinfo-Fix-timecode-display.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avutil/attributes: add av_likely and av_unlikely
On 1/24/2019 5:53 PM, Rostislav Pehlivanov wrote: > On Thu, 24 Jan 2019 at 20:38, Marton Balint wrote: > >> Signed-off-by: Marton Balint >> --- >> doc/APIchanges | 3 +++ >> libavutil/attributes.h | 8 >> libavutil/version.h| 2 +- >> 3 files changed, 12 insertions(+), 1 deletion(-) >> >> diff --git a/doc/APIchanges b/doc/APIchanges >> index a39a3ff2ba..38b5b980a6 100644 >> --- a/doc/APIchanges >> +++ b/doc/APIchanges >> @@ -15,6 +15,9 @@ libavutil: 2017-10-21 >> >> API changes, most recent first: >> >> +2019-01-xx - xx - lavu 56.27.100 - attributes.h >> + Add av_likely and av_unlikely >> + >> 2019-01-08 - xx - lavu 56.26.100 - frame.h >>Add AV_FRAME_DATA_REGIONS_OF_INTEREST >> >> diff --git a/libavutil/attributes.h b/libavutil/attributes.h >> index ced108aa2c..60972e5109 100644 >> --- a/libavutil/attributes.h >> +++ b/libavutil/attributes.h >> @@ -164,4 +164,12 @@ >> #define av_noreturn >> #endif >> >> +#if AV_GCC_VERSION_AT_LEAST(2,96) || defined(__clang__) >> +# define av_likely(x) __builtin_expect(!!(x), 1) >> +# define av_unlikely(x)__builtin_expect(!!(x), 0) >> +#else >> +# define av_likely(x) (x) >> +# define av_unlikely(x)(x) >> +#endif >> + >> #endif /* AVUTIL_ATTRIBUTES_H */ >> diff --git a/libavutil/version.h b/libavutil/version.h >> index 1fcdea95bf..12b4f9fc3a 100644 >> --- a/libavutil/version.h >> +++ b/libavutil/version.h >> @@ -79,7 +79,7 @@ >> */ >> >> #define LIBAVUTIL_VERSION_MAJOR 56 >> -#define LIBAVUTIL_VERSION_MINOR 26 >> +#define LIBAVUTIL_VERSION_MINOR 27 >> #define LIBAVUTIL_VERSION_MICRO 100 >> >> #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \ >> -- >> 2.16.4 >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > NAK, NAK, NAK. > I will NAK the hell out of any patch that does that. They're completely > unnecessary, they're commonly used by complete idiots who add them thinking > their code will go faster (and it might - only on their antiquated GCC > 3.1), they're religiously used by the same people and won't back down on > using them and finally they're ugly when added to every single bloody > branch and the people who maintain such code will demand they be added to > every single bloody branch for no reason other that what I've just iterated > on. > The ONLY way I'll accept them is in platform-specific files, e.g. > libavcodec/ppc/*, and even then only on non-x86 arches (which need them for > having bad compilers with primitive processors having awful branch > prediction) and even then I'd never accept their inclusioin into > system-installed headers. What about hot loops with branches where you can use these as a hint for the compiler to assume a specific outcome is highly unlikely to happen, like alloc errors, corner cases in some codec, etc, which it simply has no way to correctly guess at compile time? I don't think it should be NAKed because it's misused in other projects. We're not other projects. We should instead simply ask the patch writer to provide numbers that prove using it makes a difference in their code with a recent version of GCC/Clang, and if it's negligible or within the margin of error we'll simply ask to remove it to keep the code clean. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] lavc/qsvdec: Replace current parser with MFXVideoDECODE_DecodeHeader()
On Mon, 2019-01-21 at 20:41 +0800, Zhong Li wrote:
> Using MSDK parser can improve qsv decoder pass rate in some cases
> (E.g:
> sps declares a wrong level_idc, smaller than it should be).
> And it is necessary for adding new qsv decoders such as MJPEG and VP9
> since current parser can't provide enough information.
> Actually using MFXVideoDECODE_DecodeHeader() was disscussed at
> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/175734.html and
> merged as commit 1acb19d,
> but was overwritten when merged libav patches (commit: 1f26a23)
> without any explain.
>
> Signed-off-by: Zhong Li
> ---
> libavcodec/qsvdec.c | 103
>
> libavcodec/qsvdec.h | 2 +
> 2 files changed, 33 insertions(+), 72 deletions(-)
>
> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> index 4a0be81..013400b 100644
> --- a/libavcodec/qsvdec.c
> +++ b/libavcodec/qsvdec.c
> @@ -120,7 +120,7 @@ static inline unsigned int qsv_fifo_size(const
> AVFifoBuffer* fifo)
> return av_fifo_size(fifo) / qsv_fifo_item_size();
> }
>
> -static int qsv_decode_init(AVCodecContext *avctx, QSVContext *q)
> +static int qsv_decode_init(AVCodecContext *avctx, QSVContext *q,
> AVPacket *avpkt)
> {
> const AVPixFmtDescriptor *desc;
> mfxSession session = NULL;
> @@ -129,6 +129,17 @@ static int qsv_decode_init(AVCodecContext
> *avctx, QSVContext *q)
> int frame_width = avctx->coded_width;
> int frame_height = avctx->coded_height;
> int ret;
> +mfxBitstream bs = { { { 0 } } };
> +
> +if (avpkt->size) {
> +bs.Data = avpkt->data;
> +bs.DataLength = avpkt->size;
> +bs.MaxLength = bs.DataLength;
> +bs.TimeStamp = avpkt->pts;
> +if (avctx->field_order == AV_FIELD_PROGRESSIVE)
> +bs.DataFlag |= MFX_BITSTREAM_COMPLETE_FRAME;
+} else
> +return AVERROR_INVALIDDATA;
>
> desc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
> if (!desc)
> @@ -174,32 +185,19 @@ static int qsv_decode_init(AVCodecContext
> *avctx, QSVContext *q)
> if (ret < 0)
> return ret;
>
> -param.mfx.CodecId = ret;
> -param.mfx.CodecProfile = ff_qsv_profile_to_mfx(avctx->codec_id,
> avctx->profile);
> -param.mfx.CodecLevel = avctx->level == FF_LEVEL_UNKNOWN ?
> MFX_LEVEL_UNKNOWN : avctx->level;
> -
> -param.mfx.FrameInfo.BitDepthLuma = desc->comp[0].depth;
> -param.mfx.FrameInfo.BitDepthChroma = desc->comp[0].depth;
> -param.mfx.FrameInfo.Shift = desc->comp[0].depth > 8;
> -param.mfx.FrameInfo.FourCC = q->fourcc;
> -param.mfx.FrameInfo.Width = frame_width;
> -param.mfx.FrameInfo.Height = frame_height;
> -param.mfx.FrameInfo.ChromaFormat = MFX_CHROMAFORMAT_YUV420;
> -
> -switch (avctx->field_order) {
> -case AV_FIELD_PROGRESSIVE:
> -param.mfx.FrameInfo.PicStruct = MFX_PICSTRUCT_PROGRESSIVE;
> -break;
> -case AV_FIELD_TT:
> -param.mfx.FrameInfo.PicStruct = MFX_PICSTRUCT_FIELD_TFF;
> -break;
> -case AV_FIELD_BB:
> -param.mfx.FrameInfo.PicStruct = MFX_PICSTRUCT_FIELD_BFF;
> -break;
> -default:
> -param.mfx.FrameInfo.PicStruct = MFX_PICSTRUCT_UNKNOWN;
> -break;
> -}
> +param.mfx.CodecId = ret;
> +ret = MFXVideoDECODE_DecodeHeader(q->session, , );
This function may potentially return MFX_ERR_MORE_DATA if provided
bitstream don't contain full header. I am not sure whether ffmpeg will
guarantee that... And the decoding error reported by Artie suggests
that something is wrong around this. That can be ffmpeg or mediasdk
issue - need to check what was the data which ffmpeg really passed to
DecodeHeader.
> +if (ret < 0)
> +return ff_qsv_print_error(avctx, ret,
> +"Error decoding stream header");
> +
> +avctx->width= param.mfx.FrameInfo.CropW;
> +avctx->height = param.mfx.FrameInfo.CropH;
> +avctx->coded_width = param.mfx.FrameInfo.Width;
> +avctx->coded_height = param.mfx.FrameInfo.Height;
> +avctx->level= param.mfx.CodecProfile;
> +avctx->profile = param.mfx.CodecLevel;
Typo here. You assign profile to level and level to profile.
> +avctx->field_order =
> ff_qsv_map_picstruct(param.mfx.FrameInfo.PicStruct);
>
> param.IOPattern = q->iopattern;
> param.AsyncDepth = q->async_depth;
> @@ -521,62 +519,22 @@ int ff_qsv_process_data(AVCodecContext *avctx,
> QSVContext *q,
> pkt->data, pkt->size, pkt->pts, pkt->dts,
> pkt->pos);
>
> -avctx->field_order = q->parser->field_order;
> /* TODO: flush delayed frames on reinit */
> -if (q->parser->format != q->orig_pix_fmt||
> -FFALIGN(q->parser->coded_width, 16) != FFALIGN(avctx-
> >coded_width, 16) ||
> -FFALIGN(q->parser->coded_height, 16) != FFALIGN(avctx-
> >coded_height, 16)) {
> +
> +if
Re: [FFmpeg-devel] [PATCH 3/3] avformat/mpegts: use av_unlikely for detecting unknown streams
2019-01-24 21:38 GMT+01:00, Marton Balint : > Strangely the previous commit caused a slowdown in overall performance > and this fixes it. I used gcc 7.3.1. Does anybody else see this? No, but since this command exists nearly immediately for me I see a 5% deviation even without your patch. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 2/3] lavc/libxavs2: use upper layer qp parameters first
> 在 2019年1月24日，下午11:16，hwrenx 写道：
>
> Signed-off-by: hwrenx
> ---
> libavcodec/libxavs2.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/libxavs2.c b/libavcodec/libxavs2.c
> index 2d29427..d5c4557 100644
> --- a/libavcodec/libxavs2.c
> +++ b/libavcodec/libxavs2.c
> @@ -109,8 +109,8 @@ static av_cold int xavs2_init(AVCodecContext *avctx)
> xavs2_opt_set2("RateControl", "%d", 1);
> xavs2_opt_set2("TargetBitRate", "%"PRId64"", avctx->bit_rate);
> xavs2_opt_set2("InitialQP", "%d", cae->initial_qp);
> -xavs2_opt_set2("MaxQP", "%d", cae->max_qp);
> -xavs2_opt_set2("MinQP", "%d", cae->min_qp);
> +xavs2_opt_set2("MaxQP", "%d", avctx->qmax >= 0 ? avctx->qmax
> : cae->max_qp);
> +xavs2_opt_set2("MinQP", "%d", avctx->qmin >= 0 ? avctx->qmin
> : cae->min_qp);
> } else {
> xavs2_opt_set2("InitialQP", "%d", cae->qp);
> }
> --
> 2.7.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
patchset LGTM too
Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avutil/attributes: add av_likely and av_unlikely
On Thu, Jan 24, 2019 at 11:06 PM Michael Niedermayer wrote: > > On Thu, Jan 24, 2019 at 06:08:57PM -0300, James Almer wrote: > > On 1/24/2019 5:53 PM, Rostislav Pehlivanov wrote: > > > On Thu, 24 Jan 2019 at 20:38, Marton Balint wrote: > > > > > >> Signed-off-by: Marton Balint > > >> --- > > >> doc/APIchanges | 3 +++ > > >> libavutil/attributes.h | 8 > > >> libavutil/version.h| 2 +- > > >> 3 files changed, 12 insertions(+), 1 deletion(-) > > >> > > >> diff --git a/doc/APIchanges b/doc/APIchanges > > >> index a39a3ff2ba..38b5b980a6 100644 > > >> --- a/doc/APIchanges > > >> +++ b/doc/APIchanges > > >> @@ -15,6 +15,9 @@ libavutil: 2017-10-21 > > >> > > >> API changes, most recent first: > > >> > > >> +2019-01-xx - xx - lavu 56.27.100 - attributes.h > > >> + Add av_likely and av_unlikely > > >> + > > >> 2019-01-08 - xx - lavu 56.26.100 - frame.h > > >>Add AV_FRAME_DATA_REGIONS_OF_INTEREST > > >> > > >> diff --git a/libavutil/attributes.h b/libavutil/attributes.h > > >> index ced108aa2c..60972e5109 100644 > > >> --- a/libavutil/attributes.h > > >> +++ b/libavutil/attributes.h > > >> @@ -164,4 +164,12 @@ > > >> #define av_noreturn > > >> #endif > > >> > > >> +#if AV_GCC_VERSION_AT_LEAST(2,96) || defined(__clang__) > > >> +# define av_likely(x) __builtin_expect(!!(x), 1) > > >> +# define av_unlikely(x)__builtin_expect(!!(x), 0) > > >> +#else > > >> +# define av_likely(x) (x) > > >> +# define av_unlikely(x)(x) > > >> +#endif > > >> + > > >> #endif /* AVUTIL_ATTRIBUTES_H */ > > >> diff --git a/libavutil/version.h b/libavutil/version.h > > >> index 1fcdea95bf..12b4f9fc3a 100644 > > >> --- a/libavutil/version.h > > >> +++ b/libavutil/version.h > > >> @@ -79,7 +79,7 @@ > > >> */ > > >> > > >> #define LIBAVUTIL_VERSION_MAJOR 56 > > >> -#define LIBAVUTIL_VERSION_MINOR 26 > > >> +#define LIBAVUTIL_VERSION_MINOR 27 > > >> #define LIBAVUTIL_VERSION_MICRO 100 > > >> > > >> #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, > > >> \ > > >> -- > > >> 2.16.4 > > >> > > >> ___ > > >> ffmpeg-devel mailing list > > >> ffmpeg-devel@ffmpeg.org > > >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > > > > > > > NAK, NAK, NAK. > > > I will NAK the hell out of any patch that does that. They're completely > > > unnecessary, they're commonly used by complete idiots who add them > > > thinking > > > their code will go faster (and it might - only on their antiquated GCC > > > 3.1), they're religiously used by the same people and won't back down on > > > using them and finally they're ugly when added to every single bloody > > > branch and the people who maintain such code will demand they be added to > > > every single bloody branch for no reason other that what I've just > > > iterated > > > on. > > > The ONLY way I'll accept them is in platform-specific files, e.g. > > > libavcodec/ppc/*, and even then only on non-x86 arches (which need them > > > for > > > having bad compilers with primitive processors having awful branch > > > prediction) and even then I'd never accept their inclusioin into > > > system-installed headers. > > > > What about hot loops with branches where you can use these as a hint for > > the compiler to assume a specific outcome is highly unlikely to happen, > > like alloc errors, corner cases in some codec, etc, which it simply has > > no way to correctly guess at compile time? > > > > I don't think it should be NAKed because it's misused in other projects. > > We're not other projects. We should instead simply ask the patch writer > > to provide numbers that prove using it makes a difference in their code > > with a recent version of GCC/Clang, and if it's negligible or within the > > margin of error we'll simply ask to remove it to keep the code clean. > > if we want to ensure this, it can be enforced easily > we have fate-source, that can check litterally for each av_(un)likely > to contain a comment on the same line listing a non negligible performance > effect. as in // branch hint increases speed by 5% I'm generally not a fan of these hints at all, since the majority of cases its just noise. The performance impact can vary extremely between compilers and CPUs used, and in average its probably minimal at best. Even if you comment it with some speed number, it'll most of the time be limited to one specific combination of compiler and CPU, and as such any documented numbers are mostly meaningless. Which is the entire problem with these likely/unlikely hints in the first place. If you want to enforce using them in places where it "matters", then how do you define that? One compiler on one system? Two compiler? Two systems? Two architectures even? You easily run into a huge potential for either endless bickering about numbers, or a lot of questionable changes with unreproducable "improvements" - ie. the abuse you see in every other project that
Re: [FFmpeg-devel] [PATCH 2/3] avformat/mpegts: cache PID discard values
2019-01-24 21:38 GMT+01:00, Marton Balint : > discard_pid can be quite expensive, so let's cache it and recalculate it on > every packet start. > > ffmpeg -y -i samples/MPEG-VOB/sdtv/RAI.ts -c copy -map 0:v:0 -map 0:a:0 > -f mpegts /dev/null I can reproduce a 30% overall speedup for this command line and your patch. (For a relatively low execution time around one second.) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat/mpegts: use av_unlikely for detecting unknown streams
On Fri, 25 Jan 2019, Carl Eugen Hoyos wrote: 2019-01-24 21:38 GMT+01:00, Marton Balint : Strangely the previous commit caused a slowdown in overall performance and this fixes it. I used gcc 7.3.1. Does anybody else see this? No, but since this command exists nearly immediately for me I see a 5% deviation even without your patch. Thanks for checking it. I tested my series on top of 1b126ec4087ab5d87d413116bee666495b0d2d3e, and can still reproduce the speedup on it. On the other hand, on current git head, I can no longer reproduce the speedup. Whatever this is, the fact that using av_unlikely fixed it is probably just luck. So considering the mixed feelings about av_(un)likely in general, I'll just drop patch 1 and 3. Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat/mpegts: use av_unlikely for detecting unknown streams
2019-01-25 2:03 GMT+01:00, Marton Balint : > > On Fri, 25 Jan 2019, Carl Eugen Hoyos wrote: > >> 2019-01-24 21:38 GMT+01:00, Marton Balint : >>> Strangely the previous commit caused a slowdown in overall performance >>> and this fixes it. I used gcc 7.3.1. Does anybody else see this? >> >> No, but since this command exists nearly immediately for me >> I see a 5% deviation even without your patch. > > Thanks for checking it. I tested my series on top of > 1b126ec4087ab5d87d413116bee666495b0d2d3e, and can still reproduce the > speedup on it. On the other hand, on current git head, I can no longer > reproduce the speedup. Whatever this is, the fact that using av_unlikely > fixed it is probably just luck. > > So considering the mixed feelings about av_(un)likely in general, I'll > just drop patch 1 and 3. I would love to test a command line where it makes a (very) clear difference, I wonder a little about the claim that it would help (measurably) on some systems but not others. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/acrossfade: allow skipping fade on inputs
On 23-01-2019 11:49 PM, Paul B Mahol wrote: On 1/23/19, Gyan wrote: On 23-01-2019 07:40 PM, Paul B Mahol wrote: On 1/23/19, Gyan wrote: On 23-01-2019 03:00 PM, Paul B Mahol wrote: On 1/23/19, Gyan wrote: Why? afade needs change too. If a user doesn't want to apply fade, then they can simply not add afade filter. This change is meant for users who want to combine two audio streams with overlap but don't want to apply fade to audio during overlap. I do not like such reasoning, also you changed afade too with this approach. That was to prevent an integer value of nb_curves-1 from being accepted. Anyway, revised patch attached, although I don't see how afade=c=nofade is useful. With previous patch it was hidden. Gyan Probably ok. Plan to push tonight. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] support rtmp_listen with rtmps
Signed-off-by: Chen Fisher
---
libavformat/rtmpproto.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index b741e421af..82b3688658 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -129,6 +129,8 @@ typedef struct RTMPContext {
char auth_params[500];
int do_reconnect;
int auth_tried;
+char* cert_file;
+char* key_file;
} RTMPContext;
#define PLAYER_KEY_OPEN_PART_LEN 30 ///< length of partial key used for
first client digest signing
@@ -2625,7 +2627,7 @@ static int rtmp_open(URLContext *s, const char *uri, int
flags, AVDictionary **o
}
}
-if (rt->listen && strcmp(proto, "rtmp")) {
+if (rt->listen && strcmp(proto, "rtmp") && strcmp(proto, "rtmps")) {
av_log(s, AV_LOG_ERROR, "rtmp_listen not available for %s\n",
proto);
return AVERROR(EINVAL);
@@ -2640,7 +2642,12 @@ static int rtmp_open(URLContext *s, const char *uri, int
flags, AVDictionary **o
/* open the tls connection */
if (port < 0)
port = RTMPS_DEFAULT_PORT;
-ff_url_join(buf, sizeof(buf), "tls", NULL, hostname, port, NULL);
+if (rt->listen)
+ ff_url_join(buf, sizeof(buf), "tls", NULL, hostname, port,
+ "?listen_timeout=%d=%s=%s",
+ rt->listen_timeout * 1000, rt->cert_file, rt->key_file);
+else
+ ff_url_join(buf, sizeof(buf), "tls", NULL, hostname, port, NULL);
} else if (!strcmp(proto, "rtmpe") || (!strcmp(proto, "rtmpte"))) {
if (!strcmp(proto, "rtmpte"))
av_dict_set(opts, "ffrtmpcrypt_tunneling", "1", 1);
@@ -3112,6 +3119,8 @@ static const AVOption rtmp_options[] = {
{"rtmp_listen", "Listen for incoming rtmp connections", OFFSET(listen),
AV_OPT_TYPE_INT, {.i64 = 0}, INT_MIN, INT_MAX, DEC, "rtmp_listen" },
{"listen", "Listen for incoming rtmp connections", OFFSET(listen),
AV_OPT_TYPE_INT, {.i64 = 0}, INT_MIN, INT_MAX, DEC, "rtmp_listen" },
{"timeout", "Maximum timeout (in seconds) to wait for incoming
connections. -1 is infinite. Implies -rtmp_listen 1", OFFSET(listen_timeout),
AV_OPT_TYPE_INT, {.i64 = -1}, INT_MIN, INT_MAX, DEC, "rtmp_listen" },
+{"cert_file", "Certificate file", OFFSET(cert_file), AV_OPT_TYPE_STRING,
{.str = NULL }, 0, 0, DEC|ENC},
+{"key_file", "Key file", OFFSET(key_file), AV_OPT_TYPE_STRING, {.str =
NULL }, 0, 0, DEC|ENC},
{ NULL },
};
--
2.17.2 (Apple Git-113)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavfilter/af_atempo: offset output frames' pts by first_frame_pts / tempo
Signed-off-by: Paweł Wegner
---
libavfilter/af_atempo.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
index bfdad7d76b..1245eae8c1 100644
--- a/libavfilter/af_atempo.c
+++ b/libavfilter/af_atempo.c
@@ -147,6 +147,8 @@ typedef struct ATempoContext {
uint8_t *dst_end;
uint64_t nsamples_in;
uint64_t nsamples_out;
+
+int64_t first_frame_pts;
} ATempoContext;
#define YAE_ATEMPO_MIN 0.5
@@ -994,6 +996,7 @@ static av_cold int init(AVFilterContext *ctx)
ATempoContext *atempo = ctx->priv;
atempo->format = AV_SAMPLE_FMT_NONE;
atempo->state = YAE_LOAD_FRAGMENT;
+atempo->first_frame_pts = AV_NOPTS_VALUE;
return 0;
}
@@ -1069,6 +1072,7 @@ static int push_samples(ATempoContext *atempo,
// adjust the PTS:
atempo->dst_buffer->pts =
+(atempo->first_frame_pts == AV_NOPTS_VALUE ? 0 :
atempo->first_frame_pts / atempo->tempo) +
av_rescale_q(atempo->nsamples_out,
(AVRational){ 1, outlink->sample_rate },
outlink->time_base);
@@ -1108,6 +1112,11 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*src_buffer)
atempo->dst = atempo->dst_buffer->data[0];
atempo->dst_end = atempo->dst + n_out * atempo->stride;
+
+if (atempo->first_frame_pts == AV_NOPTS_VALUE)
+atempo->first_frame_pts = av_rescale_q(atempo->dst_buffer->pts,
+ inlink->time_base,
+ outlink->time_base);
}
yae_apply(atempo, , src_end, >dst, atempo->dst_end);
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] libavdevice/v4l2enc: support additional v4l2 output formats
2019-01-24 3:55 GMT+01:00, james.hillia...@gmail.com
:
> From: James Hilliard
>
> Signed-off-by: James Hilliard
> ---
> libavdevice/v4l2enc.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/libavdevice/v4l2enc.c b/libavdevice/v4l2enc.c
> index faf6e07..f778208 100644
> --- a/libavdevice/v4l2enc.c
> +++ b/libavdevice/v4l2enc.c
> @@ -47,8 +47,7 @@ static av_cold int write_header(AVFormatContext *s1)
> }
>
> if (s1->nb_streams != 1 ||
> -s1->streams[0]->codecpar->codec_type != AVMEDIA_TYPE_VIDEO ||
> -s1->streams[0]->codecpar->codec_id != AV_CODEC_ID_RAWVIDEO) {
> +s1->streams[0]->codecpar->codec_type != AVMEDIA_TYPE_VIDEO) {
> av_log(s1, AV_LOG_ERROR,
> "V4L2 output device supports only a single raw video
> stream\n");
> return AVERROR(EINVAL);
> @@ -56,7 +55,7 @@ static av_cold int write_header(AVFormatContext *s1)
>
> par = s1->streams[0]->codecpar;
>
> -v4l2_pixfmt = ff_fmt_ff2v4l(par->format, AV_CODEC_ID_RAWVIDEO);
> +v4l2_pixfmt = ff_fmt_ff2v4l(AV_PIX_FMT_NONE,
> s1->streams[0]->codecpar->codec_id);
> if (!v4l2_pixfmt) { // XXX: try to force them one by one?
> av_log(s1, AV_LOG_ERROR, "Unknown V4L2 pixel format equivalent for
> %s\n",
> av_get_pix_fmt_name(par->format));
Please explain what this patch fixes.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/movenc: Mention video_track_timescale as option to fix the timescale.
2019-01-24 14:13 GMT+01:00, Gyan : > Or better, a viable timescale ceiling can be printed. Yes, this is exactly the reason why nothing was committed for several years. (Although printing the current scale is a very good idea that wasn't suggested so far.) > 3) If the offending track is audio, then nothing can be done, the > message should reflect that (and the muxer should quit). Please provide an example. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/movenc: Mention video_track_timescale as option to fix the timescale.
On 24-01-2019 05:25 PM, Carl Eugen Hoyos wrote:
ffmpeg | branch: master | Carl Eugen Hoyos | Thu Jan 24
12:52:50 2019 +0100| [406f8d9c9a10267299d6eefd0672bd4f4c9342b4] | committer: Carl
Eugen Hoyos
lavf/movenc: Mention video_track_timescale as option to fix the timescale.
Smarter improvements for this error message were suggested in the past
but this is certainly an improvement.
http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=406f8d9c9a10267299d6eefd0672bd4f4c9342b4
---
libavformat/movenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index adaff4c5e9..65be2968a1 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -2741,8 +2741,8 @@ static int mov_write_mdhd_tag(AVIOContext *pb,
MOVMuxContext *mov,
if (version != 0 && track->mode == MODE_MOV) {
av_log(NULL, AV_LOG_ERROR,
"FATAL error, file duration too long for timebase, this file will
not be\n"
- "playable with quicktime. Choose a different timebase or a
different\n"
- "container format\n");
+ "playable with QuickTime. Choose a different timebase with "
+ "-video_track_timescale or a different container format\n");
}
return 32;
A few comments:
1) Am I correct in thinking that after printing the error msg, the muxer
carries on? If so, the ffmpeg log will get populated with other
messages, and since this will likely be a very large file, the user may
never see the message for enough time (or at all) to register it.
Shouldn't we abort at this point?
2) The error message doesn't provide context for the message. QT only
supports 32 bits for duration, and track duration is too large to be
recorded. We should print the timescale, the duration, and explain the
limitation. And that the 'different timebase' (sic; --> timescale)
should be smaller. Or better, a viable timescale ceiling can be printed.
3) If the offending track is audio, then nothing can be done, the
message should reflect that (and the muxer should quit).
4) Unrelated to this commit, the returned size is 32 but the box size
may be 44. An oversight in a3a80ddc, I suppose.
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/movenc: Mention video_track_timescale as option to fix the timescale.
On 24-01-2019 07:05 PM, Carl Eugen Hoyos wrote: 2019-01-24 14:13 GMT+01:00, Gyan : Or better, a viable timescale ceiling can be printed. Yes, this is exactly the reason why nothing was committed for several years. (Although printing the current scale is a very good idea that wasn't suggested so far.) The ceiling should be (int) (INT32_MAX * track->timescale / track->duration ) (Shouldn't the value limit be UINT32_MAX?) 3) If the offending track is audio, then nothing can be done, the message should reflect that (and the muxer should quit). Please provide an example. I don't follow. The error msg only suggests to modify the timescale of video tracks. For audio, the timescale is fixed to the sampling rate and isn't selectable, so if there's an overflow there, there's no remedy. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/movenc: Mention video_track_timescale as option to fix the timescale.
2019-01-24 15:17 GMT+01:00, Gyan : [...] >>> 3) If the offending track is audio, then nothing can be done, the >>> message should reflect that (and the muxer should quit). >> >> Please provide an example. > > I don't follow. The error msg only suggests to modify the timescale of > video tracks. For audio, the timescale is fixed to the sampling rate and > isn't selectable, so if there's an overflow there, there's no remedy. So you did test a command line that triggered the error message for audio? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter/af_atempo: offset output frames' pts by first_frame_pts / tempo
On Thu, Jan 24, 2019 at 3:43 PM Pavel Koshevoy wrote:
> On Thu, Jan 24, 2019 at 5:49 AM Paweł Wegner
> wrote:
> >
> > Signed-off-by: Paweł Wegner
> > ---
> > libavfilter/af_atempo.c | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
> > index bfdad7d76b..1245eae8c1 100644
> > --- a/libavfilter/af_atempo.c
> > +++ b/libavfilter/af_atempo.c
> > @@ -147,6 +147,8 @@ typedef struct ATempoContext {
> > uint8_t *dst_end;
> > uint64_t nsamples_in;
> > uint64_t nsamples_out;
> > +
> > +int64_t first_frame_pts;
> > } ATempoContext;
> >
> > #define YAE_ATEMPO_MIN 0.5
> > @@ -994,6 +996,7 @@ static av_cold int init(AVFilterContext *ctx)
> > ATempoContext *atempo = ctx->priv;
> > atempo->format = AV_SAMPLE_FMT_NONE;
> > atempo->state = YAE_LOAD_FRAGMENT;
> > +atempo->first_frame_pts = AV_NOPTS_VALUE;
> > return 0;
> > }
> >
> > @@ -1069,6 +1072,7 @@ static int push_samples(ATempoContext *atempo,
> >
> > // adjust the PTS:
> > atempo->dst_buffer->pts =
> > +(atempo->first_frame_pts == AV_NOPTS_VALUE ? 0 :
> atempo->first_frame_pts / atempo->tempo) +
> > av_rescale_q(atempo->nsamples_out,
> > (AVRational){ 1, outlink->sample_rate },
> > outlink->time_base);
> > @@ -1108,6 +1112,11 @@ static int filter_frame(AVFilterLink *inlink,
> AVFrame *src_buffer)
> >
> > atempo->dst = atempo->dst_buffer->data[0];
> > atempo->dst_end = atempo->dst + n_out * atempo->stride;
> > +
> > +if (atempo->first_frame_pts == AV_NOPTS_VALUE)
> > +atempo->first_frame_pts =
> av_rescale_q(atempo->dst_buffer->pts,
> > +
> inlink->time_base,
> > +
> outlink->time_base);
> > }
> >
> > yae_apply(atempo, , src_end, >dst, atempo->dst_end);
> > --
> > 2.17.1
> >
>
>
> Probably okay. The reason I didn't do this to begin with is because
> this is an audio stream filter... and how the timeline of the stream
> was transformed up to the 1st frame is unknown. You are making the
> assumption that it should have been transformed using the same tempo
> parameter as current tempo, but (video) tempo can be varied at runtime
> prior to 1st audio frame, so pts_0' = pts_0 / tempo could be wrong.
>
> Anyway, I don't have a use case where this change would break
> something, so if this fixes something for you then it's fine.
This fixes seeking when I have video playback sped up in ffplay like this:
ffplay -vf "setpts=0.5 * PTS" -af "atempo=2" input
>
> Pavel.
> ___
> 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] libavfilter/af_atempo: offset output frames' pts by first_frame_pts / tempo
On 24-01-2019 08:18 PM, Paweł Wegner wrote: This fixes seeking when I have video playback sped up in ffplay like this: ffplay -vf "setpts=0.5 * PTS" -af "atempo=2" input The better way to run this is ffplay -vf "setpts=0.5 * (PTS - STARTPTS)" -af "atempo=2" input Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 3/3] lavc/libdavs2: fix parameter setting error
Signed-off-by: hwrenx
---
libavcodec/libdavs2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
index cf75656..0808721 100644
--- a/libavcodec/libdavs2.c
+++ b/libavcodec/libdavs2.c
@@ -45,9 +45,9 @@ static av_cold int davs2_init(AVCodecContext *avctx)
/* init the decoder */
cad->param.threads = avctx->thread_count;
cad->param.info_level = 0;
-cad->decoder= davs2_decoder_open(>param);
cad->param.disable_avx = !(cpu_flags & AV_CPU_FLAG_AVX &&
cpu_flags & AV_CPU_FLAG_AVX2);
+cad->decoder= davs2_decoder_open(>param);
if (!cad->decoder) {
av_log(avctx, AV_LOG_ERROR, "decoder created error.");
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 2/3] lavc/libxavs2: use upper layer qp parameters first
Signed-off-by: hwrenx
---
libavcodec/libxavs2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libxavs2.c b/libavcodec/libxavs2.c
index 2d29427..d5c4557 100644
--- a/libavcodec/libxavs2.c
+++ b/libavcodec/libxavs2.c
@@ -109,8 +109,8 @@ static av_cold int xavs2_init(AVCodecContext *avctx)
xavs2_opt_set2("RateControl", "%d", 1);
xavs2_opt_set2("TargetBitRate", "%"PRId64"", avctx->bit_rate);
xavs2_opt_set2("InitialQP", "%d", cae->initial_qp);
-xavs2_opt_set2("MaxQP", "%d", cae->max_qp);
-xavs2_opt_set2("MinQP", "%d", cae->min_qp);
+xavs2_opt_set2("MaxQP", "%d", avctx->qmax >= 0 ? avctx->qmax :
cae->max_qp);
+xavs2_opt_set2("MinQP", "%d", avctx->qmin >= 0 ? avctx->qmin :
cae->min_qp);
} else {
xavs2_opt_set2("InitialQP", "%d", cae->qp);
}
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 1/3] lavc/libxavs2: remove unused context parameter
Signed-off-by: hwrenx
---
libavcodec/libxavs2.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/libxavs2.c b/libavcodec/libxavs2.c
index 52c50a1..2d29427 100644
--- a/libavcodec/libxavs2.c
+++ b/libavcodec/libxavs2.c
@@ -46,7 +46,6 @@ typedef struct XAVS2EContext {
int min_qp;
int preset_level;
int log_level;
-int hierarchical_reference;
void *encoder;
char *xavs2_opts;
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter/af_atempo: offset output frames' pts by first_frame_pts / tempo
On 1/24/19, Paweł Wegner wrote:
> Signed-off-by: Paweł Wegner
> ---
> libavfilter/af_atempo.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
> index bfdad7d76b..1245eae8c1 100644
> --- a/libavfilter/af_atempo.c
> +++ b/libavfilter/af_atempo.c
> @@ -147,6 +147,8 @@ typedef struct ATempoContext {
> uint8_t *dst_end;
> uint64_t nsamples_in;
> uint64_t nsamples_out;
> +
> +int64_t first_frame_pts;
> } ATempoContext;
>
> #define YAE_ATEMPO_MIN 0.5
> @@ -994,6 +996,7 @@ static av_cold int init(AVFilterContext *ctx)
> ATempoContext *atempo = ctx->priv;
> atempo->format = AV_SAMPLE_FMT_NONE;
> atempo->state = YAE_LOAD_FRAGMENT;
> +atempo->first_frame_pts = AV_NOPTS_VALUE;
> return 0;
> }
>
> @@ -1069,6 +1072,7 @@ static int push_samples(ATempoContext *atempo,
>
> // adjust the PTS:
> atempo->dst_buffer->pts =
> +(atempo->first_frame_pts == AV_NOPTS_VALUE ? 0 :
> atempo->first_frame_pts / atempo->tempo) +
> av_rescale_q(atempo->nsamples_out,
> (AVRational){ 1, outlink->sample_rate },
> outlink->time_base);
> @@ -1108,6 +1112,11 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *src_buffer)
>
> atempo->dst = atempo->dst_buffer->data[0];
> atempo->dst_end = atempo->dst + n_out * atempo->stride;
> +
> +if (atempo->first_frame_pts == AV_NOPTS_VALUE)
> +atempo->first_frame_pts =
> av_rescale_q(atempo->dst_buffer->pts,
> + inlink->time_base,
> + outlink->time_base);
> }
>
> yae_apply(atempo, , src_end, >dst, atempo->dst_end);
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter/af_atempo: offset output frames' pts by first_frame_pts / tempo
On Thu, Jan 24, 2019 at 5:49 AM Paweł Wegner wrote:
>
> Signed-off-by: Paweł Wegner
> ---
> libavfilter/af_atempo.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
> index bfdad7d76b..1245eae8c1 100644
> --- a/libavfilter/af_atempo.c
> +++ b/libavfilter/af_atempo.c
> @@ -147,6 +147,8 @@ typedef struct ATempoContext {
> uint8_t *dst_end;
> uint64_t nsamples_in;
> uint64_t nsamples_out;
> +
> +int64_t first_frame_pts;
> } ATempoContext;
>
> #define YAE_ATEMPO_MIN 0.5
> @@ -994,6 +996,7 @@ static av_cold int init(AVFilterContext *ctx)
> ATempoContext *atempo = ctx->priv;
> atempo->format = AV_SAMPLE_FMT_NONE;
> atempo->state = YAE_LOAD_FRAGMENT;
> +atempo->first_frame_pts = AV_NOPTS_VALUE;
> return 0;
> }
>
> @@ -1069,6 +1072,7 @@ static int push_samples(ATempoContext *atempo,
>
> // adjust the PTS:
> atempo->dst_buffer->pts =
> +(atempo->first_frame_pts == AV_NOPTS_VALUE ? 0 :
> atempo->first_frame_pts / atempo->tempo) +
> av_rescale_q(atempo->nsamples_out,
> (AVRational){ 1, outlink->sample_rate },
> outlink->time_base);
> @@ -1108,6 +1112,11 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *src_buffer)
>
> atempo->dst = atempo->dst_buffer->data[0];
> atempo->dst_end = atempo->dst + n_out * atempo->stride;
> +
> +if (atempo->first_frame_pts == AV_NOPTS_VALUE)
> +atempo->first_frame_pts =
> av_rescale_q(atempo->dst_buffer->pts,
> + inlink->time_base,
> + outlink->time_base);
> }
>
> yae_apply(atempo, , src_end, >dst, atempo->dst_end);
> --
> 2.17.1
>
Probably okay. The reason I didn't do this to begin with is because
this is an audio stream filter... and how the timeline of the stream
was transformed up to the 1st frame is unknown. You are making the
assumption that it should have been transformed using the same tempo
parameter as current tempo, but (video) tempo can be varied at runtime
prior to 1st audio frame, so pts_0' = pts_0 / tempo could be wrong.
Anyway, I don't have a use case where this change would break
something, so if this fixes something for you then it's fine.
Pavel.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/movenc: Mention video_track_timescale as option to fix the timescale.
On 24-01-2019 08:11 PM, Carl Eugen Hoyos wrote: So you did test a command line that triggered the error message for audio? Not till now :) Ok, mostly not a problem (in terms of raising attention via the log), But exit code is shown as 0. And your modified message *is* shown for crafted cases like ffmpeg -f lavfi -t 10 -i testsrc2 -f lavfi -t 10 -i sine -af asetpts='if(lt(T,5),PTS,2147472648+PTS)' out.mov All encoded packets are shown as muxed. And like I said, exit code is 0. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter/af_atempo: offset output frames' pts by first_frame_pts / tempo
On Thu, Jan 24, 2019 at 8:01 AM Gyan wrote: > > > > On 24-01-2019 08:18 PM, Paweł Wegner wrote: > > > > This fixes seeking when I have video playback sped up in ffplay like this: > > ffplay -vf "setpts=0.5 * PTS" -af "atempo=2" input > > The better way to run this is > > ffplay -vf "setpts=0.5 * (PTS - STARTPTS)" -af "atempo=2" input > > yeah, why not just do this... no code changes required. I'd prefer it if atempo stayed simple. This way you can still use a separate pts transform filter to adjust audio pts if necessary and without hard-coding an assumption into atempo. Pavel. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/7] cbs: Add a function to make content of a unit writable
From a macro point of view, I like your general approach using tables.
It really simplifies everything a lot.
(Rereading my old approach I don't know why I totally forgot that
there is a generic way to know the size of the internal buffers
(namely size of the AVBufferRefs). Not thinking of this, I opted for
the approach where the size is derived from other fields which made
everything very ungeneric and ugly. Sorry for wasting your time with
my earlier approach.)
Mark Thompson:
> +static int cbs_clone_unit_content(AVBufferRef **clone_ref,
> + CodedBitstreamUnit *unit,
> + const CodedBitstreamUnitTypeDescriptor
> *desc)
If this function were accessible from cbs_h2645.c, it could be used to
solve the dangling pointers problem in cbs_h26n_replace_xps by
performing a deep copy if the parameter sets are not refcounted (as I
did in "Implement copy-functions for parameter sets").
> +{
> +uint8_t *src, *copy;
> +AVBufferRef **src_buf, **copy_buf;
> +int err, i = 0;
> +
> +av_assert0(unit->type == desc->unit_type);
> +av_assert0(unit->content);
> +src = unit->content;
> +
> +copy = av_malloc(desc->content_size);
> +if (!copy)
> +goto fail;
> +memcpy(copy, src, desc->content_size);
> +
> +for (i = 0; i < desc->nb_ref_offsets; i++) {
> +src_buf = (AVBufferRef**)(src + desc->ref_offsets[i]);
> +copy_buf = (AVBufferRef**)(copy + desc->ref_offsets[i]);
> +
> +if (!*src_buf)
> +continue;
> +
> +*copy_buf = av_buffer_ref(*src_buf);
> +if (!*copy_buf)
> +goto fail;
> +
> +err = av_buffer_make_writable(copy_buf);
> +if (err < 0) {
> +av_buffer_unref(copy_buf);
> +goto fail;
> +}
You make the internal reference buffers writable, but you forgot that
access to the data held in these buffers is not performed via
content->buf_ref->data, but via content->(pointer to data). These
pointers need to be updated, too; and the offsets of the pointers will
have to be added to the CodedBitstreamUnitTypeDescriptor.
> +}
> +
> +*clone_ref = av_buffer_create(copy, desc->content_size,
> + desc->content_free ? desc->content_free :
> + cbs_default_free_unit_content,
> + (void*)desc, 0);
> +if (!*clone_ref)
> +goto fail;
> +
> +return 0;
> +
> +fail:
> +for (--i; i >= 0; i--)
> +av_buffer_unref((AVBufferRef**)(copy + desc->ref_offsets[i]));
> +av_freep();
> +*clone_ref = NULL;
> +return AVERROR(ENOMEM);
> +}
> +
> +int ff_cbs_make_unit_writable(CodedBitstreamContext *ctx,
> + CodedBitstreamUnit *unit)
> +{
> +const CodedBitstreamUnitTypeDescriptor *desc;
> +AVBufferRef *ref;
> +int err;
> +
> +if (av_buffer_is_writable(unit->content_ref))
> +return 0;
This check has the implicit assumption that the content is refcounted;
is this intended?
> +/**
> + * Make the content of a unit writable so that internal fields can be
> + * modified.
> + *
> + * If there are no other references to the content of the unit, does
> + * nothing and returned success. Otherwise, it does a full clone of the
returns success.
> + * content (including any internal buffers) to make a new copy, and
> + * replaces the existing references inside the unit with that.
> + */
> +int ff_cbs_make_unit_writable(CodedBitstreamContext *ctx,
> + CodedBitstreamUnit *unit);
> +
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/7] cbs_h265: Use table-based alloc/free
Mark Thompson: > +CBS_UNIT_TYPE_POD(H264_NAL_AUD, H265RawAUD), Typo. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/acrossfade: allow skipping fade on inputs
On 24-01-2019 02:22 PM, Gyan wrote: On 23-01-2019 11:49 PM, Paul B Mahol wrote: On 1/23/19, Gyan wrote: On 23-01-2019 07:40 PM, Paul B Mahol wrote: On 1/23/19, Gyan wrote: On 23-01-2019 03:00 PM, Paul B Mahol wrote: On 1/23/19, Gyan wrote: Why? afade needs change too. If a user doesn't want to apply fade, then they can simply not add afade filter. This change is meant for users who want to combine two audio streams with overlap but don't want to apply fade to audio during overlap. I do not like such reasoning, also you changed afade too with this approach. That was to prevent an integer value of nb_curves-1 from being accepted. Anyway, revised patch attached, although I don't see how afade=c=nofade is useful. With previous patch it was hidden. Gyan Probably ok. Plan to push tonight. Pushed as 3224d6691cdc59ef0d31cdb35efac27494ff515b. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter/af_atempo: offset output frames' pts by first_frame_pts / tempo
On Thu, Jan 24, 2019 at 4:01 PM Gyan wrote: > > > On 24-01-2019 08:18 PM, Paweł Wegner wrote: > > > > This fixes seeking when I have video playback sped up in ffplay like > this: > > ffplay -vf "setpts=0.5 * PTS" -af "atempo=2" input > > The better way to run this is > > ffplay -vf "setpts=0.5 * (PTS - STARTPTS)" -af "atempo=2" input > This works fine, thanks; the patch can be discarded. > > Gyan > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [CLT2019] FFmpeg at Chemnitzer Linux-Tage
Hi, FFmpeg has been accepted for CLT 2019 in Chemnitz, Germany! This "Chemnitzer Linux Tage" will take place on 16th and 17th of March. You can find more details on their homepage: https://chemnitzer.linux-tage.de/2019/en/ We will man a booth with our staff and are happily waiting for our users to get in touch with us! If you're a developer and want to help us or just want to visit and check in at our booth, please let us know. Our CLT team currently registered: Carl Eugen Hoyos Thomas Volkert Alexander Strasser Thilo Borgmann We would like to encourage everyone visiting the CLT to bring us sample files and/or command lines that show suspicious or buggy behavior - this will be your change to get your bug fixed right away! See you in Chemnitz! -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
