Re: [FFmpeg-devel] [PATCH] avfilter/af_loudnorm: correctly initialize PTS
On 2/4/18, Muhammad Faiz wrote: > On Sat, Feb 3, 2018 at 9:22 PM, Niklas Haas wrote: >> From: Niklas Haas >> >> Right now, the PTS always starts out as 0, which causes problems on a >> seek or when inserting this filter mid-stream. >> >> Initialize it instead to AV_NOPTS_VALUE and copy the PTS from the first >> frame instead if this is the case. >> --- >> libavfilter/af_loudnorm.c | 5 - >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/libavfilter/af_loudnorm.c b/libavfilter/af_loudnorm.c >> index a7f11cbe6e..314b25fa39 100644 >> --- a/libavfilter/af_loudnorm.c >> +++ b/libavfilter/af_loudnorm.c >> @@ -431,6 +431,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame >> *in) >> av_frame_copy_props(out, in); >> } >> >> +if (s->pts == AV_NOPTS_VALUE) >> +s->pts = in->pts; >> + >> out->pts = s->pts; >> src = (const double *)in->data[0]; >> dst = (double *)out->data[0]; >> @@ -763,7 +766,7 @@ static int config_input(AVFilterLink *inlink) >> inlink->partial_buf_size = frame_size(inlink->sample_rate, 3000); >> } >> >> -s->pts = >> +s->pts = AV_NOPTS_VALUE; >> s->buf_index = >> s->prev_buf_index = >> s->limiter_buf_index = 0; >> -- >> 2.16.1 > > Output pts ideally should be based on input pts in all cases > (not only in the first pts case), because input pts may be non-monotonic. That have nothing to do with this patch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Adding mkdir option for img2enc (4th attempt)
On 17/01/2018 11:15, Carl Eugen Hoyos wrote:
2018-01-17 11:56 GMT+01:00 Dr. Alan Barclay :
Attached in a further patch - adding the error checks.
Please merge this patch into your previous patch.
Both patches updated.
Alan.
And please avoid top-posting here, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
Dr. Alan Barclay
Electric Scribe Ltd.
118 Stanley Street
Aberdeen AB10 6UQ, U.K.
+44 1224 591779 office
+44 7803 606485 mobile
a...@escribe.co.uk
From 79d3ef8419e806abbc6c55fc563d04a6879feb15 Mon Sep 17 00:00:00 2001
From: "Dr. Alan Barclay"
Date: Sun, 4 Feb 2018 12:07:55 +
Subject: [PATCH 1/2] Move mkdir_p(), renamed ff_mkdir_p(), from hlsenc.c to
utils.c.
---
libavformat/hlsenc.c | 37 ++---
libavformat/internal.h | 7 +++
libavformat/utils.c| 33 +
3 files changed, 42 insertions(+), 35 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index cc13c94e97..a51248ec02 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -225,39 +225,6 @@ typedef struct HLSContext {
AVIOContext *sub_m3u8_out;
} HLSContext;
-static int mkdir_p(const char *path) {
-int ret = 0;
-char *temp = av_strdup(path);
-char *pos = temp;
-char tmp_ch = '\0';
-
-if (!path || !temp) {
-return -1;
-}
-
-if (!strncmp(temp, "/", 1) || !strncmp(temp, "\\", 1)) {
-pos++;
-} else if (!strncmp(temp, "./", 2) || !strncmp(temp, ".\\", 2)) {
-pos += 2;
-}
-
-for ( ; *pos != '\0'; ++pos) {
-if (*pos == '/' || *pos == '\\') {
-tmp_ch = *pos;
-*pos = '\0';
-ret = mkdir(temp, 0755);
-*pos = tmp_ch;
-}
-}
-
-if ((*(pos - 1) != '/') || (*(pos - 1) != '\\')) {
-ret = mkdir(temp, 0755);
-}
-
-av_free(temp);
-return ret;
-}
-
static int hlsenc_io_open(AVFormatContext *s, AVIOContext **pb, char *filename,
AVDictionary **options) {
HLSContext *hls = s->priv_data;
@@ -1504,7 +1471,7 @@ static int hls_start(AVFormatContext *s, VariantStream
*vs)
return AVERROR(ENOMEM);
}
dir = av_dirname(fn_copy);
-if (mkdir_p(dir) == -1 && errno != EEXIST) {
+if (ff_mkdir_p(dir) == -1 && errno != EEXIST) {
av_log(oc, AV_LOG_ERROR, "Could not create directory %s
with use_localtime_mkdir\n", dir);
av_free(fn_copy);
return AVERROR(errno);
@@ -1730,7 +1697,7 @@ static int format_name(char *buf, int buf_len, int index)
}
dir = av_dirname(mod_buf_dup);
-if (mkdir_p(dir) == -1 && errno != EEXIST) {
+if (ff_mkdir_p(dir) == -1 && errno != EEXIST) {
ret = AVERROR(errno);
goto fail;
}
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 1e2a3e05a1..2e8fa85d08 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -703,4 +703,11 @@ int ff_unlock_avformat(void);
*/
void ff_format_set_url(AVFormatContext *s, char *url);
+/**
+ * Make the specified directory.
+ *
+ * @param path path for directory
+ */
+int ff_mkdir_p(const char *path);
+
#endif /* AVFORMAT_INTERNAL_H */
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 28ea071409..11bacdf1b4 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -5658,3 +5658,36 @@ FF_DISABLE_DEPRECATION_WARNINGS
FF_ENABLE_DEPRECATION_WARNINGS
#endif
}
+
+int ff_mkdir_p(const char *path) {
+int ret = 0;
+char *temp = av_strdup(path);
+char *pos = temp;
+char tmp_ch = '\0';
+
+if (!path || !temp) {
+return -1;
+}
+
+if (!strncmp(temp, "/", 1) || !strncmp(temp, "\\", 1)) {
+pos++;
+} else if (!strncmp(temp, "./", 2) || !strncmp(temp, ".\\", 2)) {
+pos += 2;
+}
+
+for ( ; *pos != '\0'; ++pos) {
+if (*pos == '/' || *pos == '\\') {
+tmp_ch = *pos;
+*pos = '\0';
+ret = mkdir(temp, 0755);
+*pos = tmp_ch;
+}
+}
+
+if ((*(pos - 1) != '/') || (*(pos - 1) != '\\')) {
+ret = mkdir(temp, 0755);
+}
+
+av_free(temp);
+return ret;
+}
--
2.11.0
From 0b35e014cf36499f0b4b5e064b7f0ce71287649a Mon Sep 17 00:00:00 2001
From: "Dr. Alan Barclay"
Date: Sun, 4 Feb 2018 12:21:51 +
Subject: [PATCH 2/2] Adding mkdir option for img2enc.
---
libavformat/img2enc.c | 16
1 file changed, 16 insertions(+)
diff --git a/libavformat/img2enc.c b/libavformat/img2enc.c
index a09cc8ec50..8f3fd98018 100644
--- a/libavformat/img2enc.c
+++ b/libavformat/img2enc.c
@@ -42,6 +42,7 @@ typedef struct VideoMuxData {
char target[4][1024];
int update;
int use_strftime;
+int use_mkdir;
int frame_pts;
Re: [FFmpeg-devel] [PATCH V3] example/vaapi_transcode: Add a VA-API transcode example.
On 29/01/18 02:59, Jun Zhao wrote: > V3: - Add error check when av_buffer_ref fail > - Fix exec encode/write but output file hasn't been open lead to crash > issue > - Add build check > V2: - deduce output format from file extension, because VP8/VP9 encoder > need to a muxer (e,g ivf or/and mp4). > Tested, LGTM, applied. Thanks, - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/me_cmp: remove ff_me_cmp_init_static()
On Sun, Feb 4, 2018 at 9:26 AM, James Almer wrote: > On 2/3/2018 7:51 PM, Muhammad Faiz wrote: >> Precalculate and constify ff_square_tab. >> >> Signed-off-by: Muhammad Faiz >> --- >> libavcodec/me_cmp.c | 51 >> +--- >> libavcodec/me_cmp.h | 4 +--- >> libavcodec/mpegvideo_enc.c | 2 +- >> libavcodec/mpegvideoencdsp.c | 2 +- >> libavcodec/snowenc.c | 2 +- >> libavcodec/utils.c | 13 --- >> 6 files changed, 43 insertions(+), 31 deletions(-) >> >> diff --git a/libavcodec/me_cmp.c b/libavcodec/me_cmp.c >> index 5e34a11593..67a5bb5c71 100644 >> --- a/libavcodec/me_cmp.c >> +++ b/libavcodec/me_cmp.c >> @@ -22,6 +22,7 @@ >> >> #include "libavutil/attributes.h" >> #include "libavutil/internal.h" >> +#include "libavutil/thread.h" > > Unused? Fixed locally. Thank's. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/af_loudnorm: correctly initialize PTS
On Sun, Feb 4, 2018 at 3:32 PM, Paul B Mahol wrote: > On 2/4/18, Muhammad Faiz wrote: >> On Sat, Feb 3, 2018 at 9:22 PM, Niklas Haas wrote: >>> From: Niklas Haas >>> >>> Right now, the PTS always starts out as 0, which causes problems on a >>> seek or when inserting this filter mid-stream. >>> >>> Initialize it instead to AV_NOPTS_VALUE and copy the PTS from the first >>> frame instead if this is the case. >>> --- >>> libavfilter/af_loudnorm.c | 5 - >>> 1 file changed, 4 insertions(+), 1 deletion(-) >>> >>> diff --git a/libavfilter/af_loudnorm.c b/libavfilter/af_loudnorm.c >>> index a7f11cbe6e..314b25fa39 100644 >>> --- a/libavfilter/af_loudnorm.c >>> +++ b/libavfilter/af_loudnorm.c >>> @@ -431,6 +431,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame >>> *in) >>> av_frame_copy_props(out, in); >>> } >>> >>> +if (s->pts == AV_NOPTS_VALUE) >>> +s->pts = in->pts; >>> + >>> out->pts = s->pts; >>> src = (const double *)in->data[0]; >>> dst = (double *)out->data[0]; >>> @@ -763,7 +766,7 @@ static int config_input(AVFilterLink *inlink) >>> inlink->partial_buf_size = frame_size(inlink->sample_rate, 3000); >>> } >>> >>> -s->pts = >>> +s->pts = AV_NOPTS_VALUE; >>> s->buf_index = >>> s->prev_buf_index = >>> s->limiter_buf_index = 0; >>> -- >>> 2.16.1 >> >> Output pts ideally should be based on input pts in all cases >> (not only in the first pts case), because input pts may be non-monotonic. > > That have nothing to do with this patch. Of course, if ideal fix isn't trivial, this fix is enough. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 2/7] lavf/rtp: replace linked list with array
On Sat, Feb 3, 2018 at 2:44 AM, Josh de Kock wrote:
> ---
> libavformat/allformats.c | 4 --
> libavformat/rdt.c| 9 +---
> libavformat/rdt.h| 5 --
> libavformat/rtpdec.c | 138
> ++-
> libavformat/rtpdec.h | 25 +++--
> 5 files changed, 100 insertions(+), 81 deletions(-)
>
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index ec84096..83ed766 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -282,10 +282,6 @@ static void register_all(void)
> REGISTER_DEMUXER (SDR2, sdr2);
> REGISTER_DEMUXER (SDS, sds);
> REGISTER_DEMUXER (SDX, sdx);
> -#if CONFIG_RTPDEC
> -ff_register_rtp_dynamic_payload_handlers();
> -ff_register_rdt_dynamic_payload_handlers();
> -#endif
> REGISTER_DEMUXER (SEGAFILM, segafilm);
> REGISTER_MUXER (SEGMENT, segment);
> REGISTER_MUXER (SEGMENT, stream_segment);
> diff --git a/libavformat/rdt.c b/libavformat/rdt.c
> index b69827f..31a32ff 100644
> --- a/libavformat/rdt.c
> +++ b/libavformat/rdt.c
> @@ -554,7 +554,7 @@ rdt_close_context (PayloadContext *rdt)
> }
>
> #define RDT_HANDLER(n, s, t) \
> -static RTPDynamicProtocolHandler rdt_ ## n ## _handler = { \
> +RTPDynamicProtocolHandler ff_rdt_ ## n ## _handler = { \
> .enc_name = s, \
> .codec_type = t, \
> .codec_id = AV_CODEC_ID_NONE, \
> @@ -570,10 +570,3 @@ RDT_HANDLER(live_audio, "x-pn-multirate-realaudio-live",
> AVMEDIA_TYPE_AUDIO);
> RDT_HANDLER(video, "x-pn-realvideo",AVMEDIA_TYPE_VIDEO);
> RDT_HANDLER(audio, "x-pn-realaudio",AVMEDIA_TYPE_AUDIO);
>
> -void ff_register_rdt_dynamic_payload_handlers(void)
> -{
> -ff_register_dynamic_payload_handler(&rdt_video_handler);
> -ff_register_dynamic_payload_handler(&rdt_audio_handler);
> -ff_register_dynamic_payload_handler(&rdt_live_video_handler);
> -ff_register_dynamic_payload_handler(&rdt_live_audio_handler);
> -}
> diff --git a/libavformat/rdt.h b/libavformat/rdt.h
> index ce6026f..2480565 100644
> --- a/libavformat/rdt.h
> +++ b/libavformat/rdt.h
> @@ -60,11 +60,6 @@ void ff_rdt_calc_response_and_checksum(char response[41],
> char chksum[9],
> const char *challenge);
>
> /**
> - * Register RDT-related dynamic payload handlers with our cache.
> - */
> -void ff_register_rdt_dynamic_payload_handlers(void);
> -
> -/**
> * Add subscription information to Subscribe parameter string.
> *
> * @param cmd string to write the subscription information into.
> diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
> index 4acb1ca..6499e27 100644
> --- a/libavformat/rtpdec.c
> +++ b/libavformat/rtpdec.c
> @@ -69,88 +69,104 @@ static RTPDynamicProtocolHandler t140_dynamic_handler =
> { /* RFC 4103 */
> .codec_id = AV_CODEC_ID_TEXT,
> };
>
> -static RTPDynamicProtocolHandler *rtp_first_dynamic_payload_handler = NULL;
> +extern RTPDynamicProtocolHandler ff_rdt_video_handler;
> +extern RTPDynamicProtocolHandler ff_rdt_audio_handler;
> +extern RTPDynamicProtocolHandler ff_rdt_live_video_handler;
> +extern RTPDynamicProtocolHandler ff_rdt_live_audio_handler;
> +
> +static const RTPDynamicProtocolHandler *rtp_dynamic_protocol_handler_list[]
> = {
> +/* rtp */
> +&ff_ac3_dynamic_handler,
> +&ff_amr_nb_dynamic_handler,
> +&ff_amr_wb_dynamic_handler,
> +&ff_dv_dynamic_handler,
> +&ff_g726_16_dynamic_handler,
> +&ff_g726_24_dynamic_handler,
> +&ff_g726_32_dynamic_handler,
> +&ff_g726_40_dynamic_handler,
> +&ff_g726le_16_dynamic_handler,
> +&ff_g726le_24_dynamic_handler,
> +&ff_g726le_32_dynamic_handler,
> +&ff_g726le_40_dynamic_handler,
> +&ff_h261_dynamic_handler,
> +&ff_h263_1998_dynamic_handler,
> +&ff_h263_2000_dynamic_handler,
> +&ff_h263_rfc2190_dynamic_handler,
> +&ff_h264_dynamic_handler,
> +&ff_hevc_dynamic_handler,
> +&ff_ilbc_dynamic_handler,
> +&ff_jpeg_dynamic_handler,
> +&ff_mp4a_latm_dynamic_handler,
> +&ff_mp4v_es_dynamic_handler,
> +&ff_mpeg_audio_dynamic_handler,
> +&ff_mpeg_audio_robust_dynamic_handler,
> +&ff_mpeg_video_dynamic_handler,
> +&ff_mpeg4_generic_dynamic_handler,
> +&ff_mpegts_dynamic_handler,
> +&ff_ms_rtp_asf_pfa_handler,
> +&ff_ms_rtp_asf_pfv_handler,
> +&ff_qcelp_dynamic_handler,
> +&ff_qdm2_dynamic_handler,
> +&ff_qt_rtp_aud_handler,
> +&ff_qt_rtp_vid_handler,
> +&ff_quicktime_rtp_aud_handler,
> +&ff_quicktime_rtp_vid_handler,
> +&ff_rfc4175_rtp_handler,
> +&ff_svq3_dynamic_handler,
> +&ff_theora_dynamic_handler,
> +&ff_vc2hq_dynamic_handler,
> +&ff_vorbis_dynamic_handler,
> +&ff_vp8_dynamic_handler,
> +&ff_vp9_dynamic_handler,
> +&gsm_dynamic_handler,
> +&l24_dynamic_handler,
> +&opus_dynamic_handler,
> +
Re: [FFmpeg-devel] [PATCH v4 7/7] lavc/bsf: make BSF iteration the same as other iterators
Muhammad Faiz (2018-02-04): > What about av*iterate(int index)? I like the idea of an index better than the other options evoked, especially the linked-list-like APIs. It is also more similar to the APIs for enumerated types. Another option would be to return the whole list in a mallocated array, in a single call. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/me_cmp: remove ff_me_cmp_init_static()
On Sun, Feb 04, 2018 at 05:51:13AM +0700, Muhammad Faiz wrote:
> Precalculate and constify ff_square_tab.
>
> Signed-off-by: Muhammad Faiz
> ---
> libavcodec/me_cmp.c | 51
> +---
> libavcodec/me_cmp.h | 4 +---
> libavcodec/mpegvideo_enc.c | 2 +-
> libavcodec/mpegvideoencdsp.c | 2 +-
> libavcodec/snowenc.c | 2 +-
> libavcodec/utils.c | 13 ---
> 6 files changed, 43 insertions(+), 31 deletions(-)
>
> diff --git a/libavcodec/me_cmp.c b/libavcodec/me_cmp.c
> index 5e34a11593..67a5bb5c71 100644
> --- a/libavcodec/me_cmp.c
> +++ b/libavcodec/me_cmp.c
> @@ -22,6 +22,7 @@
>
> #include "libavutil/attributes.h"
> #include "libavutil/internal.h"
> +#include "libavutil/thread.h"
> #include "avcodec.h"
> #include "copy_block.h"
> #include "simple_idct.h"
> @@ -29,13 +30,47 @@
> #include "mpegvideo.h"
> #include "config.h"
>
> -uint32_t ff_square_tab[512] = { 0, };
> +/* (i - 256) * (i - 256) */
> +const uint32_t ff_square_tab[512] = {
Is the first element used ?
If not (and i suspect so) then uint16_t could be used
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Observe your enemies, for they first find out your faults. -- Antisthenes
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16
On Thu, Feb 01, 2018 at 01:43:00PM +0100, Jerome Martinez wrote:
> Add support for 16-bit/component RGB with Alpha encoding and decoding in
> FFV1, both RGBA64 and GBRAP16 for encoding, GBRAP16 for decoding.
>
> Resulting bitstream was tested about lossless encoding/decoding by the
> compression from DPX to FFV1 then decompression from FFV1 to DPX, see
> commands below (resulting framemd5 hashes are all same).
> Resulting bitstream is decodable by another decoder (with same resulting
> framemd5 hash).
> Resulting bitstream passed through a conformance checker compared to current
> FFV1 specification IETF draft.
>
> About the patch:
> - some modified lines are not used (the ones not used when f->use32bit is
> 1), but it makes the code more coherent (especially because decode_rgb_frame
> signature is same for both 16-bit and 32-bit version) and prepares the
> support of RGBA with 10/12/14 bits/component.
> - GBRAP16 was chosen for decoding because GBRP16 is already used when no
> alpha, and the code is more prepared for planar pix_fmt when bit depth is
> >8.
> - "s->transparency = desc->nb_components == 4 || desc->nb_components == 2;"
> is a copy of a line a bit above about the detection of transparency, I
> preferred to reuse it as is even if "YA" 16-bit/component is not (yet)
> supported.
>
> FFmpeg commands used for tests:
> ./ffmpeg -i in.dpx -c:v ffv1 out.mkv
> ./ffmpeg -i in.dpx -pix_fmt gbrap16 -strict -2 -c:v ffv1 out2.mkv
> ./ffmpeg -i out.mkv out.dpx
>
> ./ffmpeg -i in.dpx -f framemd5 in.dpx.framemd5
> ./ffmpeg -i out.mkv -pix_fmt rgba64be -f framemd5 out.mkv.framemd5
> ./ffmpeg -i out2.mkv -pix_fmt rgba64be -f framemd5 out2.mkv.framemd5
> ./ffmpeg -i out.dpx -f framemd5 out.dpx.framemd5
>
> Test file used (renamed to in.dpx):
> https://mediaarea.net/temp/uncropped_DPX_4K_16bit_Overscan15pros.dpx
>
> Jérôme
>
[...]
> diff --git a/libavcodec/ffv1enc_template.c b/libavcodec/ffv1enc_template.c
> index b7eea0dd70..2763082540 100644
> --- a/libavcodec/ffv1enc_template.c
> +++ b/libavcodec/ffv1enc_template.c
> @@ -122,8 +122,8 @@ static av_always_inline int
> RENAME(encode_line)(FFV1Context *s, int w,
> return 0;
> }
>
> -static int RENAME(encode_rgb_frame)(FFV1Context *s, const uint8_t *src[3],
> -int w, int h, const int stride[3])
> +static int RENAME(encode_rgb_frame)(FFV1Context *s, const uint8_t *src[4],
> +int w, int h, const int stride[4])
> {
> int x, y, p, i;
> const int ring_size = s->context_model ? 3 : 2;
> @@ -152,14 +152,18 @@ static int RENAME(encode_rgb_frame)(FFV1Context *s,
> const uint8_t *src[3],
> r = (v >> 16) & 0xFF;
> a = v >> 24;
> } else if (packed) {
> -const uint16_t *p = ((const uint16_t*)(src[0] + x*6 +
> stride[0]*y));
> +const uint16_t *p = ((const uint16_t*)(src[0] + x*(3 +
> s->transparency)*2 + stride[0]*y));
> r = p[0];
> g = p[1];
> b = p[2];
> +if (s->transparency)
transparency should possibly be moved into a local variable
> + a = p[3];
> } else if (sizeof(TYPE) == 4) {
> g = *((const uint16_t *)(src[0] + x*2 + stride[0]*y));
> b = *((const uint16_t *)(src[1] + x*2 + stride[1]*y));
> r = *((const uint16_t *)(src[2] + x*2 + stride[2]*y));
> +if (s->transparency)
> +a = *((const uint16_t *)(src[3] + x*2 + stride[2]*y));
^
this looks wrong
also what speed effect do thes changes to the inner loop have ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The educated differ from the uneducated as much as the living from the
dead. -- 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] rtsp: rename certain options after a deprecation period
On Thu, 25 Jan 2018 19:00:43 +0100
wm4 wrote:
> The names inherently clash with the meanings of the HTTP libavformat
> protocol options. Rename them after a deprecation period to make them
> compatible with the HTTP ones.
> ---
> I see no better way that wouldn't require more effort than justified.
> The incompatible semantics of the "timeout" option while still clashing
> with the HTTP one caused major problems to me as API user, and I'm
> hoping that this will solve itself in 2 years.
> ---
> doc/APIchanges| 5 +
> libavformat/rtsp.c| 9 +
> libavformat/version.h | 5 -
> 3 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 59e3b20c08..bf8664c799 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,11 @@ libavutil: 2017-10-21
>
> API changes, most recent first:
>
> +2018-01-xx - xxx - lavf 58.7.100 - avformat.h
> + Deprecate the current names of the RTSP "timeout", "stimeout", "user-agent"
> + options. Once the deprecation is over, "timeout" will be renamed to
> + "listen_timeout", "stimeout" to "timeout", and "user-agent" to
> "user_agent".
> +
> 2018-01-xx - xxx - lavf 58.6.100 - avformat.h
>Add AVFMTCTX_UNSEEKABLE (for HLS demuxer).
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index cf7cdb2f2b..bed5f1ea11 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@ -93,10 +93,19 @@ const AVOption ff_rtsp_options[] = {
> RTSP_MEDIATYPE_OPTS("allowed_media_types", "set media types to accept
> from the server"),
> { "min_port", "set minimum local UDP port", OFFSET(rtp_port_min),
> AV_OPT_TYPE_INT, {.i64 = RTSP_RTP_PORT_MIN}, 0, 65535, DEC|ENC },
> { "max_port", "set maximum local UDP port", OFFSET(rtp_port_max),
> AV_OPT_TYPE_INT, {.i64 = RTSP_RTP_PORT_MAX}, 0, 65535, DEC|ENC },
> +#if FF_API_OLD_RTSP_OPTIONS
> { "timeout", "set maximum timeout (in seconds) to wait for incoming
> connections (-1 is infinite, imply flag listen)", OFFSET(initial_timeout),
> AV_OPT_TYPE_INT, {.i64 = -1}, INT_MIN, INT_MAX, DEC },
> { "stimeout", "set timeout (in microseconds) of socket TCP I/O
> operations", OFFSET(stimeout), AV_OPT_TYPE_INT, {.i64 = 0}, INT_MIN, INT_MAX,
> DEC },
> +#else
> +{ "listen_timeout", "set maximum timeout (in seconds) to wait for
> incoming connections (-1 is infinite, imply flag listen)",
> OFFSET(initial_timeout), AV_OPT_TYPE_INT, {.i64 = -1}, INT_MIN, INT_MAX, DEC
> },
> +{ "timeout", "set timeout (in microseconds) of socket TCP I/O
> operations", OFFSET(stimeout), AV_OPT_TYPE_INT, {.i64 = 0}, INT_MIN, INT_MAX,
> DEC },
> +#endif
> COMMON_OPTS(),
> +#if FF_API_OLD_RTSP_OPTIONS
> { "user-agent", "override User-Agent header", OFFSET(user_agent),
> AV_OPT_TYPE_STRING, {.str = LIBAVFORMAT_IDENT}, 0, 0, DEC },
> +#else
> +{ "user_agent", "override User-Agent header", OFFSET(user_agent),
> AV_OPT_TYPE_STRING, {.str = LIBAVFORMAT_IDENT}, 0, 0, DEC },
> +#endif
> { NULL },
> };
>
> diff --git a/libavformat/version.h b/libavformat/version.h
> index 5ff8a89ae0..4285e925cf 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@ -32,7 +32,7 @@
> // Major bumping may affect Ticket5467, 5421, 5451(compatibility with
> Chromium)
> // Also please add any ticket numbers that you believe might be affected here
> #define LIBAVFORMAT_VERSION_MAJOR 58
> -#define LIBAVFORMAT_VERSION_MINOR 6
> +#define LIBAVFORMAT_VERSION_MINOR 7
> #define LIBAVFORMAT_VERSION_MICRO 100
>
> #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
> @@ -85,6 +85,9 @@
> #ifndef FF_API_LAVF_FFSERVER
> #define FF_API_LAVF_FFSERVER(LIBAVFORMAT_VERSION_MAJOR < 59)
> #endif
> +#ifndef FF_API_OLD_RTSP_OPTIONS
> +#define FF_API_OLD_RTSP_OPTIONS (LIBAVFORMAT_VERSION_MAJOR < 59)
> +#endif
>
>
> #ifndef FF_API_R_FRAME_RATE
Pushed, with James Almer's change request added.
Anyone is free to add a fancy new timeout system on top of this, it
doesn't conflict.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] id3v2: fix unsynchronization
On Tue, 30 Jan 2018 13:43:25 +0100
wm4 wrote:
> The ID3v2 "unsynchronization scheme" requires replacing any 0xFF 0x00
> sequences with 0xFF. This has to be done on every byte of the source
> data, while the current code skipped a byte after a replacement. This
> meant 0xFF 0x00 0xFF 00 was translated to 0xFF 0xFF 0x00 instead of 0xFF
> 0xFF. It feels a bit messy to do this correctly with the avio use. But
> fortunately, this translation can be done in-place, so we can just do it
> in memory.
>
> Inspired by what taglib does.
> ---
> Sample (which had corrupted cover art, displays fine with the fix):
> https://0x0.st/sbQ9.bin (unfortunately a bit too large for FATE)
> ---
> libavformat/id3v2.c | 26 ++
> 1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
> index b80178d67a..f7de26a1d8 100644
> --- a/libavformat/id3v2.c
> +++ b/libavformat/id3v2.c
> @@ -976,19 +976,21 @@ static void id3v2_parse(AVIOContext *pb, AVDictionary
> **metadata,
> }
> }
> if (unsync || tunsync) {
> -int64_t end = avio_tell(pb) + tlen;
> -uint8_t *b;
> -
> -b = buffer;
> -while (avio_tell(pb) < end && b - buffer < tlen &&
> !pb->eof_reached) {
> -*b++ = avio_r8(pb);
> -if (*(b - 1) == 0xff && avio_tell(pb) < end - 1 &&
> -b - buffer < tlen &&
> -!pb->eof_reached ) {
> -uint8_t val = avio_r8(pb);
> -*b++ = val ? val : avio_r8(pb);
> -}
> +uint8_t *b = buffer;
> +uint8_t *t = buffer;
> +uint8_t *end = t + tlen;
> +
> +if (avio_read(pb, buffer, tlen) != tlen) {
> +av_log(s, AV_LOG_ERROR, "Failed to read tag data\n");
> +goto seek;
> }
> +
> +while (t != end) {
> +*b++ = *t++;
> +if (t != end && t[-1] == 0xff && !t[0])
> +t++;
> +}
> +
> ffio_init_context(&pb_local, buffer, b - buffer, 0, NULL,
> NULL, NULL,
>NULL);
> tlen = b - buffer;
Pushed, with a note about the old Libav commit added.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] gitignore: add OpenCL generated kernels
Signed-off-by: Rostislav Pehlivanov --- .gitignore | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.gitignore b/.gitignore index 0e57cb0b4c..c4135b252d 100644 --- a/.gitignore +++ b/.gitignore @@ -36,3 +36,5 @@ /lcov/ /src /mapfile +/libavfilter/opencl/unsharp.c +/libavfilter/opencl/overlay.c -- 2.16.1.315.g94e5d3ead4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec
On Sat, Jan 20, 2018 at 11:20:22PM +, Rostislav Pehlivanov wrote: > On 20 January 2018 at 17:26, Aurelien Jacobs wrote: > > > On Sun, Jan 14, 2018 at 10:54:34PM +0100, Carl Eugen Hoyos wrote: > > > 2018-01-14 14:06 GMT+01:00 Aurelien Jacobs : > > > > > > > Well, here is an updated patch which uses codec tags for the decoder > > and > > > > profile for the encoder. > > > > > > Sorry but I object to this patch: > > > We should not invent codec_tags. > > > > OK, I understand, and I agree. > > > > But now we are in an interlocking situation. > > We have 2 solutions to handle aptX vs. aptX HD but those 2 solutions have > > been rejected by 2 different person. > > > > Do anybody have a 3rd solution, that everyone would accept ? > > > > And if not, how do we resolve this ? > > Is there any policy nowadays to handle this kind of interlocking ? > > > > Fine, I see no choice but to use multiple codec IDs for aptxhd since the > format really provides you with nothing bitstream wise to determine what it > is. Even game codecs have a bit or two for version. OK. Good. Now, will someone push the original patchset ? Or should I rebase it and submt it again ? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] gitignore: add OpenCL generated kernels
On Sun, Feb 4, 2018 at 3:55 PM, Rostislav Pehlivanov wrote: > Signed-off-by: Rostislav Pehlivanov > --- > .gitignore | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/.gitignore b/.gitignore > index 0e57cb0b4c..c4135b252d 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -36,3 +36,5 @@ > /lcov/ > /src > /mapfile > +/libavfilter/opencl/unsharp.c > +/libavfilter/opencl/overlay.c We use directory specific .gitignore files now, so please create a new one in that folder. Additionally, maybe a pattern would be nicer then adding any future filter? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/me_cmp: remove ff_me_cmp_init_static()
On Sun, Feb 4, 2018 at 2:47 PM, Michael Niedermayer
wrote:
> On Sun, Feb 04, 2018 at 05:51:13AM +0700, Muhammad Faiz wrote:
>> Precalculate and constify ff_square_tab.
>>
>> Signed-off-by: Muhammad Faiz
>> ---
>> libavcodec/me_cmp.c | 51
>> +---
>> libavcodec/me_cmp.h | 4 +---
>> libavcodec/mpegvideo_enc.c | 2 +-
>> libavcodec/mpegvideoencdsp.c | 2 +-
>> libavcodec/snowenc.c | 2 +-
>> libavcodec/utils.c | 13 ---
>> 6 files changed, 43 insertions(+), 31 deletions(-)
>>
>> diff --git a/libavcodec/me_cmp.c b/libavcodec/me_cmp.c
>> index 5e34a11593..67a5bb5c71 100644
>> --- a/libavcodec/me_cmp.c
>> +++ b/libavcodec/me_cmp.c
>> @@ -22,6 +22,7 @@
>>
>> #include "libavutil/attributes.h"
>> #include "libavutil/internal.h"
>> +#include "libavutil/thread.h"
>> #include "avcodec.h"
>> #include "copy_block.h"
>> #include "simple_idct.h"
>> @@ -29,13 +30,47 @@
>> #include "mpegvideo.h"
>> #include "config.h"
>>
>> -uint32_t ff_square_tab[512] = { 0, };
>> +/* (i - 256) * (i - 256) */
>> +const uint32_t ff_square_tab[512] = {
>
> Is the first element used ?
> If not (and i suspect so) then uint16_t could be used
Any changes to the table and the change to making it static should
really be separate changes though.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 7/7] lavc/bsf: make BSF iteration the same as other iterators
On Sun, Feb 04, 2018 at 02:46:09PM +0100, Nicolas George wrote: > Muhammad Faiz (2018-02-04): > > What about av*iterate(int index)? This makes no sense, it's then not an API for iteration of components. > > I like the idea of an index better than the other options evoked, > especially the linked-list-like APIs. It is also more similar to the > APIs for enumerated types. If we were to add in APIs which allowed you to register external components again, this idea wouldn't work well as indexes wouldn't necessarily correspond to the component which it previously did after you register extra components. The main benefit of the opaque pointers is the flexibility of how components are stored/represented internally, and being able to change/extend it with no API changes (only additions). Sure there is the question of 'how efficient is it?', but it's not really a relevant question considering how frequently the iteration functions are called (not much relative to other parts of the library where efficiency is more crucial). > Another option would be to return the whole list in a mallocated array, > in a single call. When has exposing more internals ever ended up going well? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 7/7] lavc/bsf: make BSF iteration the same as other iterators
Josh de Kock (2018-02-04): > If we were to add in APIs which allowed you to register external components > again, this idea wouldn't work well as indexes wouldn't necessarily correspond > to the component which it previously did after you register extra components. That is not a problem if the documentation states "index change when components are registered". > > Another option would be to return the whole list in a mallocated array, > > in a single call. > When has exposing more internals ever ended up going well? This suggestion does not expose any internal at all. Are you sure you read it correctly? Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 7/7] lavc/bsf: make BSF iteration the same as other iterators
On Sun, 4 Feb 2018 22:29:10 +0100 Nicolas George wrote: > Josh de Kock (2018-02-04): > > If we were to add in APIs which allowed you to register external components > > again, this idea wouldn't work well as indexes wouldn't necessarily > > correspond > > to the component which it previously did after you register extra > > components. > > That is not a problem if the documentation states "index change when > components are registered". > > > > Another option would be to return the whole list in a mallocated array, > > > in a single call. > > When has exposing more internals ever ended up going well? > > This suggestion does not expose any internal at all. Are you sure you > read it correctly? It would require that all future implementations use an array, until we deprecate and introduce new APIs again. I suggest we stay focused, instead of getting nothing done again due to bikeshedding. Let's just go with the current naming/signature? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 7/7] lavc/bsf: make BSF iteration the same as other iterators
Josh de Kock (2018-02-04): > The main benefit of the opaque pointers is the flexibility of how components > are stored/represented internally, and being able to change/extend it with > no API changes (only additions). Sure there is the question of 'how efficient > is it?', but it's not really a relevant question considering how frequently > the iteration functions are called (not much relative to other parts of the > library where efficiency is more crucial). Sorry, I forgot to answer that part. Using an index has the same good properties. And so does returning the list at once (I ask again: did you read the suggestion properly? It is not about returning an internal array containing the list, it is about building a new array to return it to the caller; it exposes no internal at all.) Therefore, this argument cannot be use to decide between the three possibilities. Using an iterator with an opaque pointer has the drawback of forcing the iteration order: always in order, always from the beginning. It also has the drawback of requiring documentation on the validity of the opaque pointer. This is an API we intend to keep for a long time, we should try to pick the best one, the one that gathers the most consensus. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec
On Sun, Feb 04, 2018 at 04:07:26PM +0100, Aurelien Jacobs wrote: > On Sat, Jan 20, 2018 at 11:20:22PM +, Rostislav Pehlivanov wrote: > > On 20 January 2018 at 17:26, Aurelien Jacobs wrote: > > > > > On Sun, Jan 14, 2018 at 10:54:34PM +0100, Carl Eugen Hoyos wrote: > > > > 2018-01-14 14:06 GMT+01:00 Aurelien Jacobs : > > > > > > > > > Well, here is an updated patch which uses codec tags for the decoder > > > and > > > > > profile for the encoder. > > > > > > > > Sorry but I object to this patch: > > > > We should not invent codec_tags. > > > > > > OK, I understand, and I agree. > > > > > > But now we are in an interlocking situation. > > > We have 2 solutions to handle aptX vs. aptX HD but those 2 solutions have > > > been rejected by 2 different person. > > > > > > Do anybody have a 3rd solution, that everyone would accept ? > > > > > > And if not, how do we resolve this ? > > > Is there any policy nowadays to handle this kind of interlocking ? > > > > > > > Fine, I see no choice but to use multiple codec IDs for aptxhd since the > > format really provides you with nothing bitstream wise to determine what it > > is. Even game codecs have a bit or two for version. > > OK. Good. > Now, will someone push the original patchset ? I think you should be able to push it yourself if there are no review comments remaining you are listed in MAINTAINERS for some parts and i see a "ajacobs" for ffmpeg so you should have git write access > Or should I rebase it and submt it again ? > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- 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: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/utvideodec: Fix bytes left check in decode_frame()
On Fri, Feb 02, 2018 at 11:18:28PM +0100, Michael Niedermayer wrote: > Fixes: out of array read > Fixes: poc-2017.avi > > Found-by: GwanYeong Kim > Signed-off-by: Michael Niedermayer > --- > libavcodec/utvideodec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" 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] avcodec/huffyuvdec: Check input buffer size
On Thu, Feb 01, 2018 at 02:36:16AM +0100, Michael Niedermayer wrote: > On Wed, Jan 31, 2018 at 07:56:06PM +0100, Paul B Mahol wrote: > > On 1/31/18, Michael Niedermayer wrote: > > > Fixes: Timeout > > > Fixes: 5487/clusterfuzz-testcase-4696837035393024 > > > > > > Found-by: continuous fuzzing process > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > > Signed-off-by: Michael Niedermayer > > > --- > > > libavcodec/huffyuvdec.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c > > > index 979c4b9d5c..66357bfb40 100644 > > > --- a/libavcodec/huffyuvdec.c > > > +++ b/libavcodec/huffyuvdec.c > > > @@ -919,6 +919,9 @@ static int decode_frame(AVCodecContext *avctx, void > > > *data, int *got_frame, > > > AVFrame *const p = data; > > > int table_size = 0, ret; > > > > > > +if (buf_size < (width * height + 7)/8) > > > +return AVERROR_INVALIDDATA; > > > + > > > > Are you sure this is enough? > > I dont know if thats the only way the decoder can be made to waste > large amounts of CPU with little input data > > I do belive it stops this specific class of issues though > > > > > > Something similar you had already posted long ago. > > for other decoders, yes. Did i forget a patch for huffyuv ? i will apply this in a few days unless someone has objections or sees some possible imrpovment [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Adding mkdir option for img2enc (4th attempt)
On Sun, Feb 04, 2018 at 12:51:59PM +, Dr. Alan Barclay wrote:
> On 17/01/2018 11:15, Carl Eugen Hoyos wrote:
> >2018-01-17 11:56 GMT+01:00 Dr. Alan Barclay :
> >
> >>Attached in a further patch - adding the error checks.
> >
> >Please merge this patch into your previous patch.
>
> Both patches updated.
>
> Alan.
>
> >And please avoid top-posting here, Carl Eugen
> >___
> >ffmpeg-devel mailing list
> >ffmpeg-devel@ffmpeg.org
> >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
[...]
> diff --git a/libavformat/internal.h b/libavformat/internal.h
> index 1e2a3e05a1..2e8fa85d08 100644
> --- a/libavformat/internal.h
> +++ b/libavformat/internal.h
> @@ -703,4 +703,11 @@ int ff_unlock_avformat(void);
> */
> void ff_format_set_url(AVFormatContext *s, char *url);
>
> +/**
> + * Make the specified directory.
> + *
> + * @param path path for directory
> + */
> +int ff_mkdir_p(const char *path);
the return code and its relation to errno should be documented or better
the function should return the error code like all other functions in ffmpeg
and not depend on errno
also the relation of pathes and url needs to be documented
is a "file://..." working or should it be a file path
[...]
> img2enc.c | 16
> 1 file changed, 16 insertions(+)
> 020db7642303243c3e0170376d0826158e44616f
> 0002-Adding-mkdir-option-for-img2enc.patch
> From 0b35e014cf36499f0b4b5e064b7f0ce71287649a Mon Sep 17 00:00:00 2001
> From: "Dr. Alan Barclay"
> Date: Sun, 4 Feb 2018 12:21:51 +
> Subject: [PATCH 2/2] Adding mkdir option for img2enc.
update to doc/muxers.texi is missing
>
> ---
> libavformat/img2enc.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/libavformat/img2enc.c b/libavformat/img2enc.c
> index a09cc8ec50..8f3fd98018 100644
> --- a/libavformat/img2enc.c
> +++ b/libavformat/img2enc.c
> @@ -42,6 +42,7 @@ typedef struct VideoMuxData {
> char target[4][1024];
> int update;
> int use_strftime;
> +int use_mkdir;
> int frame_pts;
> const char *muxer;
> int use_rename;
> @@ -114,6 +115,20 @@ static int write_packet(AVFormatContext *s, AVPacket
> *pkt)
> img->img_number, img->path);
> return AVERROR(EINVAL);
> }
> +if (img->use_mkdir) {
> +const char *temp_path;
> +char *temp_filename = av_strdup(filename);
> +if (!temp_filename) {
> +return AVERROR(ENOMEM);
> +}
> +temp_path = av_dirname(temp_filename);
> +if (ff_mkdir_p(temp_path) == -1 && errno != EEXIST) {
> +av_log(s, AV_LOG_ERROR, "Could not create directory %s\n",
> temp_path);
> +av_free(temp_filename);
> +return AVERROR(errno);
> +}
> +av_free(temp_filename);
> +}
> for (i = 0; i < 4; i++) {
> snprintf(img->tmp[i], sizeof(img->tmp[i]), "%s.tmp", filename);
> av_strlcpy(img->target[i], filename, sizeof(img->target[i]));
> @@ -212,6 +227,7 @@ static const AVOption muxoptions[] = {
> { "update", "continuously overwrite one file", OFFSET(update),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
> { "start_number", "set first number in the sequence",
> OFFSET(img_number), AV_OPT_TYPE_INT, { .i64 = 1 }, 0, INT_MAX, ENC },
> { "strftime", "use strftime for filename", OFFSET(use_strftime),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
> +{ "mkdir","make sub-dirs as required", OFFSET(use_mkdir),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
> { "frame_pts","use current frame pts for filename",
> OFFSET(frame_pts), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
> { "atomic_writing", "write files atomically (using temporary files and
> renames)", OFFSET(use_rename), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
> { NULL },
> --
> 2.11.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Democracy is the form of government in which you can choose your dictator
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavfi/avfiltergraph: Do not return ENOMEM if filter is missing
Hi! OOM is unlikely as a failure for avfilter_graph_alloc_filter(), the patch avoids a surprising error if a filter was not found. Please comment, Carl Eugen From 6587726a5e96570bb54e49ccf0b7fd6d94b929c8 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Mon, 5 Feb 2018 01:43:08 +0100 Subject: [PATCH] lavfi/avfiltergraph: Do not return ENOMEM if filterchain init failed. A more likely reason is that the filter was not found. --- libavfilter/avfiltergraph.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c index 4cc6892..7ccd895 100644 --- a/libavfilter/avfiltergraph.c +++ b/libavfilter/avfiltergraph.c @@ -147,7 +147,7 @@ int avfilter_graph_create_filter(AVFilterContext **filt_ctx, const AVFilter *fil *filt_ctx = avfilter_graph_alloc_filter(graph_ctx, filt, name); if (!*filt_ctx) -return AVERROR(ENOMEM); +return -1; ret = avfilter_init_str(*filt_ctx, args); if (ret < 0) -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavfi/avfiltergraph: Do not return ENOMEM if filter is missing
On 2/4/2018 10:33 PM, Carl Eugen Hoyos wrote: > Hi! > > OOM is unlikely as a failure for avfilter_graph_alloc_filter(), the > patch avoids a surprising error if a filter was not found. > > Please comment, Carl Eugen > > > 0001-lavfi-avfiltergraph-Do-not-return-ENOMEM-if-filterch.patch > > > From 6587726a5e96570bb54e49ccf0b7fd6d94b929c8 Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos > Date: Mon, 5 Feb 2018 01:43:08 +0100 > Subject: [PATCH] lavfi/avfiltergraph: Do not return ENOMEM if filterchain > init failed. > > A more likely reason is that the filter was not found. > --- > libavfilter/avfiltergraph.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c > index 4cc6892..7ccd895 100644 > --- a/libavfilter/avfiltergraph.c > +++ b/libavfilter/avfiltergraph.c > @@ -147,7 +147,7 @@ int avfilter_graph_create_filter(AVFilterContext > **filt_ctx, const AVFilter *fil > > *filt_ctx = avfilter_graph_alloc_filter(graph_ctx, filt, name); > if (!*filt_ctx) > -return AVERROR(ENOMEM); > +return -1; -1 is not acceptable for a public function that states it returns an AVERROR value on failure. If the issue is that avfilter_graph_alloc_filter() may fail because of both OOM and an invalid value for filter, then I'm more inclined to use AVERROR_UNKNOWN here instead. That being said, based on the above the return value of avfilter_graph_alloc_filter() should have never been an AVFilterContext, but an int instead. Maybe a new function that returns a proper AVERROR value should be added. AVERROR(ENOMEM), AVERROR(EINVAL), AVERROR_FILTER_NOT_FOUND, or whatever corresponds depending on the type of failure. > > ret = avfilter_init_str(*filt_ctx, args); > if (ret < 0) > -- 1.7.10.4 > > > > ___ > 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]lavfi/avfiltergraph: Do not return ENOMEM if filter is missing
On 2/4/2018 11:05 PM, James Almer wrote: > On 2/4/2018 10:33 PM, Carl Eugen Hoyos wrote: >> Hi! >> >> OOM is unlikely as a failure for avfilter_graph_alloc_filter(), the >> patch avoids a surprising error if a filter was not found. >> >> Please comment, Carl Eugen >> >> >> 0001-lavfi-avfiltergraph-Do-not-return-ENOMEM-if-filterch.patch >> >> >> From 6587726a5e96570bb54e49ccf0b7fd6d94b929c8 Mon Sep 17 00:00:00 2001 >> From: Carl Eugen Hoyos >> Date: Mon, 5 Feb 2018 01:43:08 +0100 >> Subject: [PATCH] lavfi/avfiltergraph: Do not return ENOMEM if filterchain >> init failed. >> >> A more likely reason is that the filter was not found. >> --- >> libavfilter/avfiltergraph.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c >> index 4cc6892..7ccd895 100644 >> --- a/libavfilter/avfiltergraph.c >> +++ b/libavfilter/avfiltergraph.c >> @@ -147,7 +147,7 @@ int avfilter_graph_create_filter(AVFilterContext >> **filt_ctx, const AVFilter *fil >> >> *filt_ctx = avfilter_graph_alloc_filter(graph_ctx, filt, name); >> if (!*filt_ctx) >> -return AVERROR(ENOMEM); >> +return -1; > > -1 is not acceptable for a public function that states it returns an > AVERROR value on failure. > If the issue is that avfilter_graph_alloc_filter() may fail because of > both OOM and an invalid value for filter, then I'm more inclined to use > AVERROR_UNKNOWN here instead. > > That being said, based on the above the return value of > avfilter_graph_alloc_filter() should have never been an AVFilterContext, > but an int instead. > Maybe a new function that returns a proper AVERROR value should be > added. AVERROR(ENOMEM), AVERROR(EINVAL), AVERROR_FILTER_NOT_FOUND, or > whatever corresponds depending on the type of failure. Of course, assuming the actual reason of failure in avfilter_graph_alloc_filter is important only in avfilter_graph_create_filter and not really in any other situation, then an internal ff_graph_alloc_filter function could be added instead of a new public function for the above purpose. > >> >> ret = avfilter_init_str(*filt_ctx, args); >> if (ret < 0) >> -- 1.7.10.4 >> >> >> >> ___ >> 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] rtsp: rename certain options after a deprecation period
2018-02-04 15:24 GMT+01:00 wm4 :
> On Thu, 25 Jan 2018 19:00:43 +0100
> wm4 wrote:
>
>> The names inherently clash with the meanings of the HTTP libavformat
>> protocol options. Rename them after a deprecation period to make them
>> compatible with the HTTP ones.
>> ---
>> I see no better way that wouldn't require more effort than justified.
>> The incompatible semantics of the "timeout" option while still clashing
>> with the HTTP one caused major problems to me as API user, and I'm
>> hoping that this will solve itself in 2 years.
>> ---
>> doc/APIchanges| 5 +
>> libavformat/rtsp.c| 9 +
>> libavformat/version.h | 5 -
>> 3 files changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index 59e3b20c08..bf8664c799 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -15,6 +15,11 @@ libavutil: 2017-10-21
>>
>> API changes, most recent first:
>>
>> +2018-01-xx - xxx - lavf 58.7.100 - avformat.h
>> + Deprecate the current names of the RTSP "timeout", "stimeout",
>> "user-agent"
>> + options. Once the deprecation is over, "timeout" will be renamed to
>> + "listen_timeout", "stimeout" to "timeout", and "user-agent" to
>> "user_agent".
>> +
>> 2018-01-xx - xxx - lavf 58.6.100 - avformat.h
>>Add AVFMTCTX_UNSEEKABLE (for HLS demuxer).
>>
>> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
>> index cf7cdb2f2b..bed5f1ea11 100644
>> --- a/libavformat/rtsp.c
>> +++ b/libavformat/rtsp.c
>> @@ -93,10 +93,19 @@ const AVOption ff_rtsp_options[] = {
>> RTSP_MEDIATYPE_OPTS("allowed_media_types", "set media types to accept
>> from the server"),
>> { "min_port", "set minimum local UDP port", OFFSET(rtp_port_min),
>> AV_OPT_TYPE_INT, {.i64 = RTSP_RTP_PORT_MIN}, 0, 65535, DEC|ENC },
>> { "max_port", "set maximum local UDP port", OFFSET(rtp_port_max),
>> AV_OPT_TYPE_INT, {.i64 = RTSP_RTP_PORT_MAX}, 0, 65535, DEC|ENC },
>> +#if FF_API_OLD_RTSP_OPTIONS
>> { "timeout", "set maximum timeout (in seconds) to wait for incoming
>> connections (-1 is infinite, imply flag listen)", OFFSET(initial_timeout),
>> AV_OPT_TYPE_INT, {.i64 = -1}, INT_MIN, INT_MAX, DEC },
>> { "stimeout", "set timeout (in microseconds) of socket TCP I/O
>> operations", OFFSET(stimeout), AV_OPT_TYPE_INT, {.i64 = 0}, INT_MIN,
>> INT_MAX, DEC },
>> +#else
>> +{ "listen_timeout", "set maximum timeout (in seconds) to wait for
>> incoming connections (-1 is infinite, imply flag listen)",
>> OFFSET(initial_timeout), AV_OPT_TYPE_INT, {.i64 = -1}, INT_MIN, INT_MAX, DEC
>> },
>> +{ "timeout", "set timeout (in microseconds) of socket TCP I/O
>> operations", OFFSET(stimeout), AV_OPT_TYPE_INT, {.i64 = 0}, INT_MIN,
>> INT_MAX, DEC },
>> +#endif
>> COMMON_OPTS(),
>> +#if FF_API_OLD_RTSP_OPTIONS
>> { "user-agent", "override User-Agent header", OFFSET(user_agent),
>> AV_OPT_TYPE_STRING, {.str = LIBAVFORMAT_IDENT}, 0, 0, DEC },
>> +#else
>> +{ "user_agent", "override User-Agent header", OFFSET(user_agent),
>> AV_OPT_TYPE_STRING, {.str = LIBAVFORMAT_IDENT}, 0, 0, DEC },
>> +#endif
>> { NULL },
>> };
>>
>> diff --git a/libavformat/version.h b/libavformat/version.h
>> index 5ff8a89ae0..4285e925cf 100644
>> --- a/libavformat/version.h
>> +++ b/libavformat/version.h
>> @@ -32,7 +32,7 @@
>> // Major bumping may affect Ticket5467, 5421, 5451(compatibility with
>> Chromium)
>> // Also please add any ticket numbers that you believe might be affected
>> here
>> #define LIBAVFORMAT_VERSION_MAJOR 58
>> -#define LIBAVFORMAT_VERSION_MINOR 6
>> +#define LIBAVFORMAT_VERSION_MINOR 7
>> #define LIBAVFORMAT_VERSION_MICRO 100
>>
>> #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
>> @@ -85,6 +85,9 @@
>> #ifndef FF_API_LAVF_FFSERVER
>> #define FF_API_LAVF_FFSERVER(LIBAVFORMAT_VERSION_MAJOR < 59)
>> #endif
>> +#ifndef FF_API_OLD_RTSP_OPTIONS
>> +#define FF_API_OLD_RTSP_OPTIONS (LIBAVFORMAT_VERSION_MAJOR < 59)
>> +#endif
>>
>>
>> #ifndef FF_API_R_FRAME_RATE
>
> Pushed, with James Almer's change request added.
This is completely unacceptable:
Why are you constantly breaking developer rules?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] fail to seek key video packet
>> > I use following command to test ffmpeg-2.8.1: >> >> This list is for development of ffmpeg, not for user support or bug reports. >> >> Use the ffmpeg-user list for user support, and http://trac.ffmpeg.org/ >> to report bugs. > >And please don't expect anyone to help debug issues with ffmpeg-2.8.1, >or even accept a bug report against it. I think the latest ffmpeg may have the same bug. FFmpeg-devel can check the issue and fix it if it is. Thanks! B.R. Andrew At 2018-02-03 06:53:26, "Moritz Barsnick" wrote: >On Fri, Feb 02, 2018 at 12:02:29 -0300, James Almer wrote: >> > I use following command to test ffmpeg-2.8.1: >> >> This list is for development of ffmpeg, not for user support or bug reports. >> >> Use the ffmpeg-user list for user support, and http://trac.ffmpeg.org/ >> to report bugs. > >And please don't expect anyone to help debug issues with ffmpeg-2.8.1, >or even accept a bug report against it. > >Moritz >___ >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] [PATCH] avformat/mov: add VP8 codec support
fix ticket: 7000
Signed-off-by: Steven Liu
---
libavformat/isom.c | 1 +
libavformat/mov.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index 9d9f85885b..95dceaa50b 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -187,6 +187,7 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
{ AV_CODEC_ID_H264, MKTAG('a', 'v', 'l', 'g') }, /* Panasonic P2 AVC-LongG
*/
{ AV_CODEC_ID_VP9, MKTAG('v', 'p', '0', '9') }, /* VP9 */
+{ AV_CODEC_ID_VP8, MKTAG('v', 'p', '0', '8') }, /* VP8 */
{ AV_CODEC_ID_MPEG1VIDEO, MKTAG('m', '1', 'v', ' ') },
{ AV_CODEC_ID_MPEG1VIDEO, MKTAG('m', '1', 'v', '1') }, /* Apple MPEG-1
Camcorder */
diff --git a/libavformat/mov.c b/libavformat/mov.c
index d16b431e03..767f196bb0 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2398,6 +2398,7 @@ static int mov_finalize_stsd_codec(MOVContext *c,
AVIOContext *pb,
case AV_CODEC_ID_MPEG1VIDEO:
case AV_CODEC_ID_VC1:
case AV_CODEC_ID_VP9:
+case AV_CODEC_ID_VP8:
st->need_parsing = AVSTREAM_PARSE_FULL;
break;
default:
--
2.15.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
