Re: [FFmpeg-devel] [PATCH] avcodec/exif: remove GetByteContext usage from avpriv_exif_decode_ifd()
On 10/24/17, James Almer wrote: > This prevents potential ABI issues with GetByteContext. > > Signed-off-by: James Almer > --- > libavcodec/exif.c | 16 +--- > libavcodec/exif.h | 6 -- > libavcodec/mjpegdec.c | 2 +- > libavcodec/webp.c | 2 +- > libavformat/avidec.c | 4 ++-- > 5 files changed, 21 insertions(+), 9 deletions(-) > lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/lossless_videodsp : add add_bytes AVX2
On 10/21/17, Martin Vignali wrote: > Hello, > > In attach patch to add AVX2 version for add_bytes > > 0001-libavcodec-lossless_videodsp-add-add_bytes-avx2-vers : > add AVX2 version > > pass fate-test for me (os 10.12, x86_64) > > checkasm result : (Kaby Lake) (run 10 times, and i took the fastest > version) > checkasm: all 2 tests passed > add_bytes_c: 108.7 > add_bytes_sse2: 26.5 > add_bytes_avx2: 15.5 > > > 0002-libavcodec-lossless_video_dsp-cosmetic-add-better-se: > only cosmetic > like the ref c function declaration in asm file is not consistent between > each asm file > i think a better separator for each function make the file easier to read > > also add the c declaration for add bytes in comment > > > Martin > Are you sure 32bit alignment is actually enforced? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/tak: remove GetBitContext usage from avpriv_tak_parse_streaminfo()
On 10/23/17, James Almer wrote: > This prevents potential ABI issues with GetBitContext. > > Signed-off-by: James Almer > --- > libavcodec/tak.c | 17 +++-- > libavcodec/tak.h | 8 ++-- > libavformat/takdec.c | 7 +-- > 3 files changed, 26 insertions(+), 6 deletions(-) > lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/bswapdsp : add AVX2 for bswap_buf
On 10/22/17, Martin Vignali wrote: > Hello, > > In attach patch in order to add an AVX2 version for bswap_buf > (swap uint32 in a buffer) > > Checkasm result (Kaby Lake 10.12) > bswap_buf_c: 122.8 > bswap_buf_sse2: 67.8 > bswap_buf_ssse3: 34.3 > bswap_buf_avx2: 21.0 > > > Pass checkasm and fate test for me > > > Martin > Jokyo Images > probably ok ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] cbs_mpeg2: Fix type for marker_bit reading
On Wed, Oct 25, 2017 at 12:42 AM, Mark Thompson wrote:
> On 24/10/17 23:34, Carl Eugen Hoyos wrote:
>> 2017-10-25 0:29 GMT+02:00 Mark Thompson :
>>> On 24/10/17 23:14, Carl Eugen Hoyos wrote:
2017-10-25 0:09 GMT+02:00 Mark Thompson :
> ffmpeg | branch: master | Mark Thompson | Tue Oct 24
> 22:56:48 2017 +0100| [5b2c71bb94d7cab23ee81b5c29388f5fadbcaf22] |
> committer: Mark Thompson
>
> cbs_mpeg2: Fix type for marker_bit reading
>
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=5b2c71bb94d7cab23ee81b5c29388f5fadbcaf22
> ---
>
> libavcodec/cbs_mpeg2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
> index d137762227..0cac29733e 100644
> --- a/libavcodec/cbs_mpeg2.c
> +++ b/libavcodec/cbs_mpeg2.c
> @@ -54,7 +54,7 @@
> xui(width, name, current->name)
>
> #define marker_bit() do { \
> -av_unused int one = 1; \
> +av_unused uint32_t one; \
> CHECK(ff_cbs_read_unsigned(ctx, rw, 1, "marker_bit", &one, 1,
> 1)); \
The commit message doesn't match the change / is this defined behaviour?
>>>
>>> It's only written and never read, so the initialisation isn't doing
>>> anything.
>>
>> I asked because I believe it was reported once that a static analyzer
>> protested
>> on passing uninitialized stuff - that was never going to be used - as
>> a parameter.
>> (But that may have been an uninitialized variable that was never used,
>> not a pointer.)
>
> I don't think pointers in general can be complained about in C without
> knowledge of the target function - consider that there are destination
> pointers all over the standard library which need not be initialised, like
> memcpy() or scanf().
>
As if static analyzers always care what you can and cannot do. :p
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] examples/avio_reading: return AVERROR_EOF at EOF.
Signed-off-by: Nicolas George
---
doc/examples/avio_reading.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/doc/examples/avio_reading.c b/doc/examples/avio_reading.c
index 02474e907a..7860fd5e2f 100644
--- a/doc/examples/avio_reading.c
+++ b/doc/examples/avio_reading.c
@@ -44,6 +44,8 @@ static int read_packet(void *opaque, uint8_t *buf, int
buf_size)
struct buffer_data *bd = (struct buffer_data *)opaque;
buf_size = FFMIN(buf_size, bd->size);
+if (!buf_size)
+return AVERROR_EOF;
printf("ptr:%p size:%zu\n", bd->ptr, bd->size);
/* copy internal buffer data to buf */
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] lavf/avio: temporarily accept 0 as EOF.
Print a warning to let applicatios fix their use.
After a deprecation period, check with a low-level assert.
Also make the constraint explicit in the doxygen comment.
Signed-off-by: Nicolas George
---
libavformat/avio.h| 2 ++
libavformat/aviobuf.c | 30 +-
libavformat/version.h | 3 +++
3 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/libavformat/avio.h b/libavformat/avio.h
index 19ecd96eb7..76ff7cd81e 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -452,6 +452,8 @@ void avio_free_directory_entry(AVIODirEntry **entry);
* @param write_flag Set to 1 if the buffer should be writable, 0 otherwise.
* @param opaque An opaque pointer to user-specific data.
* @param read_packet A function for refilling the buffer, may be NULL.
+ * For stream protocols, must never return 0 but rather
+ * a proper AVERROR code.
* @param write_packet A function for writing the buffer contents, may be NULL.
*The function may not change the input buffers content.
* @param seek A function for seeking to specified byte position, may be NULL.
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 3e9d774a13..bb5bcf7a14 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -524,6 +524,24 @@ void avio_write_marker(AVIOContext *s, int64_t time, enum
AVIODataMarkerType typ
s->last_time = time;
}
+static int read_packet_wrapper(AVIOContext *s, uint8_t *buf, int size)
+{
+int ret;
+
+if (!s->read_packet)
+return AVERROR_EOF;
+ret = s->read_packet(s->opaque, buf, size);
+#if FF_API_OLD_AVIO_EOF_0
+if (!ret && !s->max_packet_size) {
+av_log(s, AV_LOG_WARNING, "Invalid return value 0 for stream
protocol\n");
+ret = AVERROR_EOF;
+}
+#else
+av_assert2(ret || s->max_packet_size);
+#endif
+return ret;
+}
+
/* Input stream */
static void fill_buffer(AVIOContext *s)
@@ -562,10 +580,7 @@ static void fill_buffer(AVIOContext *s)
len = s->orig_buffer_size;
}
-if (s->read_packet)
-len = s->read_packet(s->opaque, dst, len);
-else
-len = AVERROR_EOF;
+len = read_packet_wrapper(s, dst, len);
if (len == AVERROR_EOF) {
/* do not modify buffer if EOF reached so that a seek back can
be done without rereading data */
@@ -638,10 +653,7 @@ int avio_read(AVIOContext *s, unsigned char *buf, int size)
if (len == 0 || s->write_flag) {
if((s->direct || size > s->buffer_size) && !s->update_checksum) {
// bypass the buffer and read data directly into buf
-if(s->read_packet)
-len = s->read_packet(s->opaque, buf, size);
-else
-len = AVERROR_EOF;
+len = read_packet_wrapper(s, buf, size);
if (len == AVERROR_EOF) {
/* do not modify buffer if EOF reached so that a seek back
can
be done without rereading data */
@@ -708,7 +720,7 @@ int avio_read_partial(AVIOContext *s, unsigned char *buf,
int size)
return -1;
if (s->read_packet && s->write_flag) {
-len = s->read_packet(s->opaque, buf, size);
+len = read_packet_wrapper(s, buf, size);
if (len > 0)
s->pos += len;
return len;
diff --git a/libavformat/version.h b/libavformat/version.h
index 0feb788c36..358ab91ab2 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -79,6 +79,9 @@
#ifndef FF_API_OLD_ROTATE_API
#define FF_API_OLD_ROTATE_API (LIBAVFORMAT_VERSION_MAJOR < 59)
#endif
+#ifndef FF_API_OLD_AVIO_EOF_0
+#define FF_API_OLD_AVIO_EOF_0 (LIBAVFORMAT_VERSION_MAJOR < 59)
+#endif
#ifndef FF_API_R_FRAME_RATE
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] lavf/aviobuf: return EINVAL when reading from a write-only context.
Signed-off-by: Nicolas George
---
libavformat/aviobuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Not related to the issue, but seems more correct.
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index bb5bcf7a14..dfe8437b18 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -534,7 +534,7 @@ static int read_packet_wrapper(AVIOContext *s, uint8_t
*buf, int size)
#if FF_API_OLD_AVIO_EOF_0
if (!ret && !s->max_packet_size) {
av_log(s, AV_LOG_WARNING, "Invalid return value 0 for stream
protocol\n");
-ret = AVERROR_EOF;
+ret = AVERROR(EINVAL);
}
#else
av_assert2(ret || s->max_packet_size);
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF
Le tridi 3 brumaire, an CCXXVI, Nicolas George a écrit : > As I said, I will try to find time to implement a correct workaround > tomorrow. Patch series posted. https://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/218482.html https://patchwork.ffmpeg.org/patch/5686/ Please confirm if it fixes the issue with your application. 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] NVENC - HEVC + WP
Am 25.10.2017 um 06:06 schrieb Yogender Gupta: One of the users had recently complained about encoding problems with HEVC encoding with WP (Weighted Prediction). This is a driver issue that has been identified, and shows up when using HEVC + WP + (PictureTimingSEI messages and or buffering period SEI messages). Recently the PictureTiming SEI message was turned on by default in the NVENC code in ffmpeg and the issue shows up when doing HEVC encodes with WP turned on. We have a driver fix that will come up in a later release, and users would be suggested to not enable weighted prediction with HEVC till a fixed driver version is available. Regards, Yogender Thanks for the heads up! WP is turned off by default, so I don't think we need to patch ffmpeg here. If some user shows up with this issue, I'll let them know what's going on. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] lavf/aviobuf: return EINVAL when reading from a write-only context.
On Wed, Oct 25, 2017 at 10:22 AM, Nicolas George wrote:
> Signed-off-by: Nicolas George
> ---
> libavformat/aviobuf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> Not related to the issue, but seems more correct.
>
>
> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> index bb5bcf7a14..dfe8437b18 100644
> --- a/libavformat/aviobuf.c
> +++ b/libavformat/aviobuf.c
> @@ -534,7 +534,7 @@ static int read_packet_wrapper(AVIOContext *s, uint8_t
> *buf, int size)
> #if FF_API_OLD_AVIO_EOF_0
> if (!ret && !s->max_packet_size) {
> av_log(s, AV_LOG_WARNING, "Invalid return value 0 for stream
> protocol\n");
> -ret = AVERROR_EOF;
> +ret = AVERROR(EINVAL);
> }
> #else
> av_assert2(ret || s->max_packet_size);
> --
I think you meant to change the other ret assignment?
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] lavf/aviobuf: return EINVAL when reading from a write-only context.
Le quartidi 4 brumaire, an CCXXVI, Hendrik Leppkes a écrit : > I think you meant to change the other ret assignment? You are entirely right. Locally swapped. Thanks for noticing. 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] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.
On Tue, Oct 24, 2017 at 06:42:54PM -0700, Thierry Foucu wrote:
> Changed the return value when no VOD were encoded in Mpeg4 bistream.
> And if we do have already a decoded frames and we are not in xvid_packed
> mode, output the existing decoded frame instead of nothing.
> ---
> libavcodec/h263dec.c | 9 -
> libavcodec/mpeg4videodec.c | 2 +-
> libavcodec/mpegutils.h | 1 +
> 3 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
> index c7cf4bc0c2..394a366f9c 100644
> --- a/libavcodec/h263dec.c
> +++ b/libavcodec/h263dec.c
> @@ -506,8 +506,15 @@ retry:
> s->height= avctx->coded_height;
> }
> }
> -if (ret == FRAME_SKIPPED)
> +if (ret == FRAME_SKIPPED || ret == FRAME_NOT_CODED) {
> +if (s->next_picture_ptr && ret == FRAME_NOT_CODED &&
> !s->divx_packed) {
> +if ((ret = av_frame_ref(pict, s->next_picture_ptr->f)) < 0) {
> +return ret;
> +}
> +*got_frame = 1;
> +}
> return get_consumed_bytes(s, buf_size);
> +}
>
> /* skip if the header was thrashed */
> if (ret < 0) {
> diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
> index 82c4f8fc8c..3a9ed12971 100644
> --- a/libavcodec/mpeg4videodec.c
> +++ b/libavcodec/mpeg4videodec.c
> @@ -2394,7 +2394,7 @@ static int decode_vop_header(Mpeg4DecContext *ctx,
> GetBitContext *gb)
> if (get_bits1(gb) != 1) {
> if (s->avctx->debug & FF_DEBUG_PICT_INFO)
> av_log(s->avctx, AV_LOG_ERROR, "vop not coded\n");
> -return FRAME_SKIPPED;
> +return FRAME_NOT_CODED;
> }
> if (ctx->new_pred)
> decode_new_pred(ctx, gb);
the return codes are documented currently:
* @return <0 if no VOP found (or a damaged one)
* FRAME_SKIPPED if a not coded VOP is found
* 0 if a VOP is found
you added a case but did not update all use cases
which seems to
lead to intermittent crashes (i cant say for sure as i failed to
reproduce one in a debugger or with any debuging code added)
Also returning frames for skiped frames when te match the previous
would slow the code down as more frames would need to be processed.
more so i think this is not the only codec that can skip frames
so any downstream problems will likely not be worked around by forcing
constant fps with frame duplication here
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is what and why we do it that matters, not just one of them.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: v4l2_m2m depends on pthreads
Fixes build with --disable-pthreads. --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index c86e578..76523c8 100755 --- a/configure +++ b/configure @@ -2780,7 +2780,7 @@ omx_rpi_select="omx" qsvdec_select="qsv" qsvenc_select="qsv" vaapi_encode_deps="vaapi" -v4l2_m2m_deps_any="linux_videodev2_h" +v4l2_m2m_deps="linux_videodev2_h pthreads" hwupload_cuda_filter_deps="cuda" scale_npp_filter_deps="cuda libnpp" -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avformat: deprecate getters and setters for AVFormatContext and AVStream fields
On 10/23/17, James Almer wrote:
> The fields can be accessed directly, so these are not needed anymore.
>
> Signed-off-by: James Almer
> ---
> libavformat/avformat.h | 30 +-
> libavformat/utils.c| 4
> libavformat/version.h | 3 +++
> 3 files changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 7594277f06..b2db234041 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -1213,11 +1213,22 @@ typedef struct AVStream {
> AVStreamInternal *internal;
> } AVStream;
>
> +#if FF_API_FORMAT_GET_SET
> +/**
> + * Accessors for some AVStream fields. These used to be provided for ABI
> + * compatibility, and do not need to be used anymore.
> + */
> +attribute_deprecated
> AVRational av_stream_get_r_frame_rate(const AVStream *s);
> +attribute_deprecated
> void av_stream_set_r_frame_rate(AVStream *s, AVRational r);
> -struct AVCodecParserContext *av_stream_get_parser(const AVStream *s);
> +attribute_deprecated
> char* av_stream_get_recommended_encoder_configuration(const AVStream *s);
> +attribute_deprecated
> void av_stream_set_recommended_encoder_configuration(AVStream *s, char
> *configuration);
> +#endif
> +
> +struct AVCodecParserContext *av_stream_get_parser(const AVStream *s);
>
> /**
> * Returns the pts of the last muxed packet + its duration
> @@ -1889,29 +1900,46 @@ typedef struct AVFormatContext {
> int max_streams;
> } AVFormatContext;
>
> +#if FF_API_FORMAT_GET_SET
> /**
> * Accessors for some AVFormatContext fields. These used to be provided for
> ABI
> * compatibility, and do not need to be used anymore.
> */
> +attribute_deprecated
> int av_format_get_probe_score(const AVFormatContext *s);
> +attribute_deprecated
> AVCodec * av_format_get_video_codec(const AVFormatContext *s);
> +attribute_deprecated
> void av_format_set_video_codec(AVFormatContext *s, AVCodec *c);
> +attribute_deprecated
> AVCodec * av_format_get_audio_codec(const AVFormatContext *s);
> +attribute_deprecated
> void av_format_set_audio_codec(AVFormatContext *s, AVCodec *c);
> +attribute_deprecated
> AVCodec * av_format_get_subtitle_codec(const AVFormatContext *s);
> +attribute_deprecated
> void av_format_set_subtitle_codec(AVFormatContext *s, AVCodec *c);
> +attribute_deprecated
> AVCodec * av_format_get_data_codec(const AVFormatContext *s);
> +attribute_deprecated
> void av_format_set_data_codec(AVFormatContext *s, AVCodec *c);
> +attribute_deprecated
> int av_format_get_metadata_header_padding(const AVFormatContext *s);
> +attribute_deprecated
> void av_format_set_metadata_header_padding(AVFormatContext *s, int c);
> +attribute_deprecated
> void *av_format_get_opaque(const AVFormatContext *s);
> +attribute_deprecated
> void av_format_set_opaque(AVFormatContext *s, void *opaque);
> +attribute_deprecated
> av_format_control_message av_format_get_control_message_cb(const
> AVFormatContext *s);
> +attribute_deprecated
> void av_format_set_control_message_cb(AVFormatContext *s,
> av_format_control_message callback);
> #if FF_API_OLD_OPEN_CALLBACKS
> attribute_deprecated AVOpenCallback av_format_get_open_cb(const
> AVFormatContext *s);
> attribute_deprecated void av_format_set_open_cb(AVFormatContext *s,
> AVOpenCallback callback);
> #endif
> +#endif
>
> /**
> * This function will cause global side data to be injected in the next
> packet
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 6dbc48d54d..8fd7b82c67 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -104,6 +104,7 @@ static int64_t wrap_timestamp(const AVStream *st,
> int64_t timestamp)
> return timestamp;
> }
>
> +#if FF_API_FORMAT_GET_SET
> MAKE_ACCESSORS(AVStream, stream, AVRational, r_frame_rate)
> MAKE_ACCESSORS(AVStream, stream, char *, recommended_encoder_configuration)
> MAKE_ACCESSORS(AVFormatContext, format, AVCodec *, video_codec)
> @@ -118,6 +119,7 @@ FF_DISABLE_DEPRECATION_WARNINGS
> MAKE_ACCESSORS(AVFormatContext, format, AVOpenCallback, open_cb)
> FF_ENABLE_DEPRECATION_WARNINGS
> #endif
> +#endif
>
> int64_t av_stream_get_end_pts(const AVStream *st)
> {
> @@ -215,10 +217,12 @@ static const AVCodec
> *find_probe_decoder(AVFormatContext *s, const AVStream *st,
> return codec;
> }
>
> +#if FF_API_FORMAT_GET_SET
> int av_format_get_probe_score(const AVFormatContext *s)
> {
> return s->probe_score;
> }
> +#endif
>
> /* an arbitrarily chosen "sane" max packet size -- 50M */
> #define SANE_CHUNK_SIZE (5000)
> diff --git a/libavformat/version.h b/libavformat/version.h
> index 0feb788c36..8765b59435 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@ -79,6 +79,9 @@
> #ifndef FF_API_OLD_ROTATE_API
> #define FF_API_OLD_ROTATE_API (LIBAVFORMAT_VERSION_MAJOR < 59)
> #endif
> +#ifndef FF_API_FORMAT_GET_SET
> +#define FF_API_FORMAT_GET_SET (LIBAVFORMAT_VE
Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs (requires feedback)
On Tue, Oct 24, 2017 at 8:56 PM, Michael Niedermayer wrote:
> On Tue, Oct 24, 2017 at 12:40:22PM -0400, Bjorn Roche wrote:
> > Support for transparencies in animated gifs requires modifying both
> > libavcodec/gif.c and libavformat/gif.c because both the graphics
> > control extension (handled by libavformat/gif.c) and the raw frame data
> > (handled by libavcodec/gif.c) must be changed. This is because
> > transparencies in GIF can be used both to create a transparent image,
> > and to provide optimization.
> >
> > How transparencies are interpreted in a given frame is controlled by
> > the “disposal method”, which must be set appropriately in the graphics
> > control extension.
> >
> > The “in place” disposal method is used when transparency indicates
> > optimization, and the “background” disposal method is used when
> > transparency is intended to be preserved. In order to support both
> > disposal methods, libavcodec/gif.c must signal to libavformat/gif.c
> > which disposal method is required for every frame. This is done with a
> > new side data type: AV_PKT_DATA_GIF_FRAME_DISPOSAL. This requires a
> > change to avcodec.h
> >
> > Unfortunately, the addition of a new side data type causes some of the
> > FATE tests to fail. This is not addressed here.
> >
> > This patch assumes paletteuse has already been patched to support
> > transparency. (e.g. lavfi/paletteuse: fix to support transparency)
> >
> > Feedback I definitely need:
> > - I’ve done a fair bit of testing, but I’m sure I missed some important
> > cases.
> > - I don’t know if/how to update the FATE tests.
> > ---
> > libavcodec/avcodec.h | 6 ++
> > libavcodec/gif.c | 196 ++
> +++--
> > libavformat/gif.c| 16 -
> > 3 files changed, 212 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index 52cc5b0ca0..82a5328ce1 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -1599,6 +1599,12 @@ enum AVPacketSideDataType {
> > */
> > AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
> >
> > +/**
> > + * The disposal method that should be used with the frame. If
> missing,
> > + * the frame will not be disposed. This contains exactly one byte.
> > + */
> > +AV_PKT_DATA_GIF_FRAME_DISPOSAL,
> > +
> > /**
> > * ATSC A53 Part 4 Closed Captions. This metadata should be
> associated with
> > * a video stream. A53 CC bitstream is stored as uint8_t in
> AVPacketSideData.data.
>
> you cannot add values in the middle of a public enum, that would
> change the ABI
>
Ah, thanks -- I thought that was internal only. Is it safe to add to the
end?
bjorn
--
Bjorn Roche
Sr. Video Pipeline Engineer
bj...@giphy.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Properly store sampling rate for FLAC in mp4
Hi, On Fri, Aug 25, 2017 at 7:29 PM, Michael Niedermayer wrote: > On Fri, Aug 25, 2017 at 01:25:23PM +0200, Jean-Yves Avenard wrote: > > From 9baa7166fa96ed6beac9146c7e3b4dcf425a67d0 Mon Sep 17 00:00:00 2001 > > From: Jean-Yves Avenard > > Date: Fri, 25 Aug 2017 13:11:28 +0200 > > Subject: [PATCH] Properly store sampling rate for FLAC in mp4 > > > > Fixes ticket #6609 > > > > Signed-off-by: Jean-Yves Avenard > > --- > > libavformat/movenc.c | 28 +--- > > 1 file changed, 25 insertions(+), 3 deletions(-) > > > > diff --git a/libavformat/movenc.c b/libavformat/movenc.c > > index 10b959ad02..aa4a9c962a 100644 > > --- a/libavformat/movenc.c > > +++ b/libavformat/movenc.c > > @@ -1028,9 +1028,31 @@ static int mov_write_audio_tag(AVFormatContext > > *s, AVIOContext *pb, MOVMuxContex > > avio_wb16(pb, 0); /* packet size (= 0) */ > > This patch is corrupted by line wraps / newlines > An uncorrupted version was attached to #6609: https://trac.ffmpeg.org/attachment/ticket/6609/0001-Properly-store-sampling-rate-for-FLAC-in-mp4.patch Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Properly store sampling rate for FLAC in mp4
hi
On 26 August 2017 at 12:08, Carl Eugen Hoyos wrote:
> 2017-08-25 13:25 GMT+02:00 Jean-Yves Avenard :
>
>> +if (track->par->codec_id == AV_CODEC_ID_FLAC) {
>
> Why does this only apply to flac?
>
Sorry, I had missed your reply.
The specification on how sampling rate is to be stored should it be
greater than INT16_MAX is a FLAC in ISOBMFF requirement:
https://git.xiph.org/?p=flac.git;a=blob;f=doc/isoflac.txt;h=574df9f54a779fca2e62c726703fc7be199d4c05;hb=refs/heads/master#l165
It definitely could be applied to other codecs, but I haven't seen
such requirements clearly defined.
ISOBMFF only defines that AudioSampleEntryV1 should be used instead,
in which case the sampling_rate is a 32 bits integer (ISO 14496-12
12.2.3.2)
JY
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Invalid behaviour of av_parser_parse2 with some content
Hi. According to the documentation of av_parser_parse2: https://www.ffmpeg.org/doxygen/trunk/group__lavc__parsing.html#ga691ca0258e91f99297e7726f56d8c247 "poutbuf_size set to size of parsed buffer or zero if not yet finished. " So we can expect that both poutbuf_size and poutbuf will be set upon av_parser_parse2 returning. However, looking at the code of some parser, such as the vp8 decoder: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vp8_parser.c;h=609f5077d1a1b2add1dd3e13f0508615428dafa0;hb=HEAD#l30 we can see that the vp8 parser will do return buf_size immediately under some circumstances (such as the size being to small, the sync code being invalid and so forth... but when doing so doesn't set the two out parameters. I believe this is a bug Either the documentation needs fixing, or the two out parameters needs to be set to poutbuf and poutbuf_size respectively as all data is to be consumed. An alternative would be to set them both to 0 if content is invalid (or too small) and as such we don't want the parser to output anything. Thanks JY ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Don't use _tzcnt instrinics with clang for windows w/o BMI.
On 25 October 2017 at 07:15, Dale Curtis wrote: > Technically _tzcnt* intrinsics are only available when the BMI > instruction set is present. However the instruction encoding > degrades to "rep bsf" on older processors. > > Clang for Windows debatably restricts the _tzcnt* instrinics behind > the __BMI__ architecture define, so check for its presence or > exclude the usage of these intrinics when clang is present. > > See also: > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183404.html > https://bugs.llvm.org/show_bug.cgi?id=30506 > http://lists.llvm.org/pipermail/cfe-dev/2016-October/051034.html > > Signed-off-by: Dale Curtis http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.
On 10/25/2017 2:42 AM, Thierry Foucu wrote: > Changed the return value when no VOD were encoded in Mpeg4 bistream. > And if we do have already a decoded frames and we are not in xvid_packed > mode, output the existing decoded frame instead of nothing. > --- > libavcodec/h263dec.c | 9 - > libavcodec/mpeg4videodec.c | 2 +- > libavcodec/mpegutils.h | 1 + > 3 files changed, 10 insertions(+), 2 deletions(-) Would this considerably slow down pathological files with a lot of NVOPs purposely inserted? For example, it use to be A Thing to use NVOPs to hack in "variable framerate" Xvid-in-avi encodes, by for example, setting the fps to 120 for a file with 24 and 30 fps sections, and padding the rest with NVOPs. Do we care about such files? (Probably not...) I can provide some samples, probably, if needed. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs (requires feedback)
On Wed, Oct 25, 2017 at 09:51:39AM -0400, Bjorn Roche wrote:
> On Tue, Oct 24, 2017 at 8:56 PM, Michael Niedermayer > wrote:
>
> > On Tue, Oct 24, 2017 at 12:40:22PM -0400, Bjorn Roche wrote:
> > > Support for transparencies in animated gifs requires modifying both
> > > libavcodec/gif.c and libavformat/gif.c because both the graphics
> > > control extension (handled by libavformat/gif.c) and the raw frame data
> > > (handled by libavcodec/gif.c) must be changed. This is because
> > > transparencies in GIF can be used both to create a transparent image,
> > > and to provide optimization.
> > >
> > > How transparencies are interpreted in a given frame is controlled by
> > > the “disposal method”, which must be set appropriately in the graphics
> > > control extension.
> > >
> > > The “in place” disposal method is used when transparency indicates
> > > optimization, and the “background” disposal method is used when
> > > transparency is intended to be preserved. In order to support both
> > > disposal methods, libavcodec/gif.c must signal to libavformat/gif.c
> > > which disposal method is required for every frame. This is done with a
> > > new side data type: AV_PKT_DATA_GIF_FRAME_DISPOSAL. This requires a
> > > change to avcodec.h
> > >
> > > Unfortunately, the addition of a new side data type causes some of the
> > > FATE tests to fail. This is not addressed here.
> > >
> > > This patch assumes paletteuse has already been patched to support
> > > transparency. (e.g. lavfi/paletteuse: fix to support transparency)
> > >
> > > Feedback I definitely need:
> > > - I’ve done a fair bit of testing, but I’m sure I missed some important
> > > cases.
> > > - I don’t know if/how to update the FATE tests.
> > > ---
> > > libavcodec/avcodec.h | 6 ++
> > > libavcodec/gif.c | 196 ++
> > +++--
> > > libavformat/gif.c| 16 -
> > > 3 files changed, 212 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > > index 52cc5b0ca0..82a5328ce1 100644
> > > --- a/libavcodec/avcodec.h
> > > +++ b/libavcodec/avcodec.h
> > > @@ -1599,6 +1599,12 @@ enum AVPacketSideDataType {
> > > */
> > > AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
> > >
> > > +/**
> > > + * The disposal method that should be used with the frame. If
> > missing,
> > > + * the frame will not be disposed. This contains exactly one byte.
> > > + */
> > > +AV_PKT_DATA_GIF_FRAME_DISPOSAL,
> > > +
> > > /**
> > > * ATSC A53 Part 4 Closed Captions. This metadata should be
> > associated with
> > > * a video stream. A53 CC bitstream is stored as uint8_t in
> > AVPacketSideData.data.
> >
> > you cannot add values in the middle of a public enum, that would
> > change the ABI
> >
>
> Ah, thanks -- I thought that was internal only. Is it safe to add to the
> end?
additions should be immedeatly before AV_PKT_DATA_NB
if this is insufficiently documented (seems so) then a patch improving
the documentation is welcome too
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Don't use _tzcnt instrinics with clang for windows w/o BMI.
On Thu, Oct 26, 2017 at 03:39:57AM +1100, Matt Oliver wrote: > On 25 October 2017 at 07:15, Dale Curtis wrote: > > > Technically _tzcnt* intrinsics are only available when the BMI > > instruction set is present. However the instruction encoding > > degrades to "rep bsf" on older processors. > > > > Clang for Windows debatably restricts the _tzcnt* instrinics behind > > the __BMI__ architecture define, so check for its presence or > > exclude the usage of these intrinics when clang is present. > > > > See also: > > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183404.html > > https://bugs.llvm.org/show_bug.cgi?id=30506 > > http://lists.llvm.org/pipermail/cfe-dev/2016-October/051034.html > > > > Signed-off-by: Dale Curtis > > LGTM will apply thanks [...] -- 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: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/wavenc: skip writing incorrect peak-of-peaks position value
On Tue, Oct 24, 2017 at 11:47:21AM +0200, Tobias Rapp wrote: > According to EBU tech 3285 supplement 3 the dwPosPeakOfPeaks field > should contain the absolute position to the maximum audio sample value, > but the current implementation writes the relative peak frame index > instead. > > Fix the issue by writing the "unknown" value (-1) for now until the > feature is implemented correctly. > > Previous version reviewed-by: Peter Bubestinger > Signed-off-by: Tobias Rapp > --- > v2: > - added version micro bump > - more code clean-up > > libavformat/version.h| 2 +- > libavformat/wavenc.c | 11 +-- > tests/ref/lavf/wav_peak | 2 +- > tests/ref/lavf/wav_peak_only | 2 +- > 4 files changed, 4 insertions(+), 13 deletions(-) will apply, thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc put mc 11, 31, 13 and 33 msa functions
On Tue, Oct 24, 2017 at 11:21:21AM +, Manojkumar Bhosale wrote: > LGTM will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. 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/mips: Improve avc chroma copy and avg vert mc msa functions
On Tue, Oct 24, 2017 at 11:21:32AM +, Manojkumar Bhosale wrote: > LGTM will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc bi weighted hv mc msa functions
On Tue, Oct 24, 2017 at 11:21:39AM +, Manojkumar Bhosale wrote: > LGTM will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] swscale: use dithering in DITHER_COPY only if not set -sws_dither none
On Tue, Oct 24, 2017 at 10:02:17AM +0200, Mateusz wrote: > This patch uses dithering in DITHER_COPY macro only if > it was not used option '-sws_dither none'. > With option '-sws_dither none' it uses downshift. > > For human eye dithering is OK, for video codecs not necessarily. > If user don't want to use dithering, we should respect that. > > Signed-off-by: Mateusz Brzostek > --- > libswscale/swscale_unscaled.c | 20 +++- > 1 file changed, 19 insertions(+), 1 deletion(-) will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/wavenc: skip writing incorrect peak-of-peaks position value
On Wed, Oct 25, 2017 at 07:55:52PM +0200, Michael Niedermayer wrote: > On Tue, Oct 24, 2017 at 11:47:21AM +0200, Tobias Rapp wrote: > > According to EBU tech 3285 supplement 3 the dwPosPeakOfPeaks field > > should contain the absolute position to the maximum audio sample value, > > but the current implementation writes the relative peak frame index > > instead. > > > > Fix the issue by writing the "unknown" value (-1) for now until the > > feature is implemented correctly. > > > > Previous version reviewed-by: Peter Bubestinger > > Signed-off-by: Tobias Rapp > > --- > > v2: > > - added version micro bump > > - more code clean-up > > > > libavformat/version.h| 2 +- > > libavformat/wavenc.c | 11 +-- > > tests/ref/lavf/wav_peak | 2 +- > > tests/ref/lavf/wav_peak_only | 2 +- > > 4 files changed, 4 insertions(+), 13 deletions(-) > > will apply, thanks rather LGTM, feel free to apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH RFC] libavdevice/decklink: Add support for EIA-708 output over SDI
On Fri, 6 Oct 2017, Devin Heitmueller wrote:
From: Devin Heitmueller
Hook in libklvanc and use it for output of EIA-708 captions over
SDI. The bulk of this patch is just general support for ancillary
data for the Decklink SDI module - the real work for construction
of the EIA-708 CDP and VANC line construction is done by libklvanc.
Libklvanc can be found at: https://github.com/stoth68000/libklvanc
Sorry for the delay, I had little time lately. In general I think it is OK
to put VANC functionality into a library, but libklvanc does not seem like
a very mature one, it has some pretty generic function names without
namespacing, e.g. "generate_vanc_line". Or it is using simple printf for
the dumper functions. You plan to work on these kind of issues to make
it more like a "stable" generic library?
Signed-off-by: Devin Heitmueller
---
configure | 3 ++
libavcodec/v210enc.c | 8 +++
libavdevice/decklink_common.h | 1 +
libavdevice/decklink_enc.cpp | 113 +++---
4 files changed, 119 insertions(+), 6 deletions(-)
diff --git a/configure b/configure
index 391c141e7a..18647896b1 100755
--- a/configure
+++ b/configure
@@ -238,6 +238,7 @@ External library support:
--enable-libgsm enable GSM de/encoding via libgsm [no]
--enable-libiec61883 enable iec61883 via libiec61883 [no]
--enable-libilbc enable iLBC de/encoding via libilbc [no]
+ --enable-libklvanc enable Kernel Labs VANC processing [no]
--enable-libkvazaar enable HEVC encoding via libkvazaar [no]
--enable-libmodplug enable ModPlug via libmodplug [no]
--enable-libmp3lame enable MP3 encoding via libmp3lame [no]
@@ -1603,6 +1604,7 @@ EXTERNAL_LIBRARY_LIST="
libgsm
libiec61883
libilbc
+libklvanc
libkvazaar
libmodplug
libmp3lame
@@ -6027,6 +6029,7 @@ enabled libx264 && { use_pkg_config libx264 x264
"stdint.h x264.h" x26
enabled libx265 && require_pkg_config libx265 x265 x265.h x265_api_get
&&
require_cpp_condition x265.h "X265_BUILD >= 68"
enabled libxavs && require libxavs "stdint.h xavs.h"
xavs_encoder_encode -lxavs
+enabled libklvanc && require libklvanc libklvanc/vanc.h
vanc_context_create -lklvanc
enabled libxvid && require libxvid xvid.h xvid_global -lxvidcore
enabled libzimg && require_pkg_config libzimg "zimg >= 2.3.0" zimg.h
zimg_get_api_version
enabled libzmq&& require_pkg_config libzmq libzmq zmq.h zmq_ctx_new
diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
index a6afbbfc41..44cc3c5c81 100644
--- a/libavcodec/v210enc.c
+++ b/libavcodec/v210enc.c
@@ -123,6 +123,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
int aligned_width = ((avctx->width + 47) / 48) * 48;
int stride = aligned_width * 8 / 3;
int line_padding = stride - ((avctx->width * 8 + 11) / 12) * 4;
+AVFrameSideData *side_data = NULL;
initializer seems unnecesarry.
int h, w, ret;
uint8_t *dst;
@@ -233,6 +234,13 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
}
}
+side_data = av_frame_get_side_data(pic, AV_FRAME_DATA_A53_CC);
+if (side_data && side_data->size) {
+uint8_t* buf = av_packet_new_side_data(pkt, AV_PKT_DATA_A53_CC,
side_data->size);
+if (buf)
+memcpy(buf, side_data->data, side_data->size);
else
return AVERROR(ENOMEM)?
+}
+
pkt->flags |= AV_PKT_FLAG_KEY;
*got_packet = 1;
return 0;
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 6b2525fb53..285a244000 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -78,6 +78,7 @@ struct decklink_ctx {
AVStream *audio_st;
AVStream *video_st;
AVStream *teletext_st;
+uint16_t cdp_sequence_num;
/* Options */
int list_devices;
diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index 81df563b3b..3049e936a9 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -38,16 +38,20 @@ extern "C" {
#include "decklink_common.h"
#include "decklink_enc.h"
-
+#if CONFIG_LIBKLVANC
+#include "libklvanc/vanc.h"
+#include "libklvanc/vanc-lines.h"
+#include "libklvanc/pixels.h"
+#endif
/* DeckLink callback class declaration */
class decklink_frame : public IDeckLinkVideoFrame
{
public:
decklink_frame(struct decklink_ctx *ctx, AVFrame *avframe, AVCodecID
codec_id, int height, int width) :
-_ctx(ctx), _avframe(avframe), _avpacket(NULL), _codec_id(codec_id),
_height(height), _width(width), _refs(1) { }
+_ctx(ctx), _avframe(avframe), _avpacket(NULL), _codec_id(codec_id),
_ancillary(NULL), _height(height), _width(width), _refs(1) { }
decklink_frame(struct decklink_ctx *ctx, AVPacket *avpacket, AVCodecID
codec_id, int height, int width) :
-_ctx(ctx), _avframe(NULL), _avpacket(avpacket), _codec_i
[FFmpeg-devel] [PATCH 2/2] lavf/tls_securetransport: build on iOS
From: Aman Gupta
This works as expected on iOS, except for the ca_file feature which
is disabled because SecItemImport is not available.
---
configure | 6 +-
libavformat/tls_securetransport.c | 4
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index c86e5788fa..a867077d66 100755
--- a/configure
+++ b/configure
@@ -2039,6 +2039,7 @@ SYSTEM_FUNCS="
posix_memalign
pthread_cancel
sched_getaffinity
+SecItemImport
SetConsoleTextAttribute
SetConsoleCtrlHandler
setmode
@@ -6164,9 +6165,12 @@ fi
enabled securetransport &&
check_func SecIdentityCreate "-Wl,-framework,CoreFoundation
-Wl,-framework,Security" &&
-check_lib securetransport "Security/SecureTransport.h Security/Security.h"
"SSLCreateContext SecItemImport" "-Wl,-framework,CoreFoundation
-Wl,-framework,Security" ||
+check_lib securetransport "Security/SecureTransport.h Security/Security.h"
"SSLCreateContext" "-Wl,-framework,CoreFoundation -Wl,-framework,Security" ||
disable securetransport
+enabled securetransport &&
+check_func SecItemImport "-Wl,-framework,CoreFoundation
-Wl,-framework,Security"
+
enabled schannel &&
check_func_headers "windows.h security.h" InitializeSecurityContext
-DSECURITY_WIN32 -lsecur32 &&
check_cpp_condition winerror.h "defined(SEC_I_CONTEXT_EXPIRED)" &&
diff --git a/libavformat/tls_securetransport.c
b/libavformat/tls_securetransport.c
index 9ea588ae3a..69672f7676 100644
--- a/libavformat/tls_securetransport.c
+++ b/libavformat/tls_securetransport.c
@@ -69,6 +69,9 @@ static int print_tls_error(URLContext *h, int ret)
static int import_pem(URLContext *h, char *path, CFArrayRef *array)
{
+#if !HAVE_SECITEMIMPORT
+return AVERROR_PATCHWELCOME;
+#else
AVIOContext *s = NULL;
CFDataRef data = NULL;
int64_t ret = 0;
@@ -124,6 +127,7 @@ end:
if (s)
avio_close(s);
return ret;
+#endif
}
static int load_ca(URLContext *h)
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] lavf/tls_securetransport: return buffered data first from tls_read
From: Aman Gupta
This fixes a deadlock while reading a chunked https response, if
multiple_requests=1 is also set. Without an EOF to signal the end of
the last chunk, tls_read gets stuck forever trying to read more data
than is available. This occurs with the http protocol reproducibly,
because http.c always reads 4kb at a time, and the last chunk of an
http response is often much smaller.
After this commit, tls_read always returns any buffered plaintext
first before attempting to read more encrypted data off the
underlying tcp socket.
---
libavformat/tls_securetransport.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavformat/tls_securetransport.c
b/libavformat/tls_securetransport.c
index bc8a32069e..9ea588ae3a 100644
--- a/libavformat/tls_securetransport.c
+++ b/libavformat/tls_securetransport.c
@@ -352,8 +352,12 @@ static int map_ssl_error(OSStatus status, size_t processed)
static int tls_read(URLContext *h, uint8_t *buf, int size)
{
TLSContext *c = h->priv_data;
-size_t processed = 0;
-int ret = SSLRead(c->ssl_context, buf, size, &processed);
+size_t available = 0, processed = 0;
+int ret;
+SSLGetBufferedReadSize(c->ssl_context, &available);
+if (available)
+size = FFMIN(available, size);
+ret = SSLRead(c->ssl_context, buf, size, &processed);
ret = map_ssl_error(ret, processed);
if (ret > 0)
return ret;
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.
Derek, On Wed, Oct 25, 2017 at 9:43 AM, Derek Buitenhuis < derek.buitenh...@gmail.com> wrote: > On 10/25/2017 2:42 AM, Thierry Foucu wrote: > > Changed the return value when no VOD were encoded in Mpeg4 bistream. > > And if we do have already a decoded frames and we are not in xvid_packed > > mode, output the existing decoded frame instead of nothing. > > --- > > libavcodec/h263dec.c | 9 - > > libavcodec/mpeg4videodec.c | 2 +- > > libavcodec/mpegutils.h | 1 + > > 3 files changed, 10 insertions(+), 2 deletions(-) > > Would this considerably slow down pathological files with a lot of > NVOPs purposely inserted? For example, it use to be A Thing to use > NVOPs to hack in "variable framerate" Xvid-in-avi encodes, by for > example, setting the fps to 120 for a file with 24 and 30 fps sections, > and padding the rest with NVOPs. > I tried using one of those files. Without the patch, the decoder will return only 29 frames With this patch, the decoder will return 1947 frames. The time of decoding the file were the same (with or without) I think where it may slow down, it's in case we transcode the file and we are not doing constant frame rate, then the encoder will have to encode 1947 frames instead of 24 frames. But for decoding it the same. > > Do we care about such files? (Probably not...) > > I can provide some samples, probably, if needed. > > - Derek > ___ > 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] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.
On Wed, Oct 25, 2017 at 4:59 AM, Michael Niedermayer wrote:
> On Tue, Oct 24, 2017 at 06:42:54PM -0700, Thierry Foucu wrote:
> > Changed the return value when no VOD were encoded in Mpeg4 bistream.
> > And if we do have already a decoded frames and we are not in xvid_packed
> > mode, output the existing decoded frame instead of nothing.
> > ---
> > libavcodec/h263dec.c | 9 -
> > libavcodec/mpeg4videodec.c | 2 +-
> > libavcodec/mpegutils.h | 1 +
> > 3 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
> > index c7cf4bc0c2..394a366f9c 100644
> > --- a/libavcodec/h263dec.c
> > +++ b/libavcodec/h263dec.c
> > @@ -506,8 +506,15 @@ retry:
> > s->height= avctx->coded_height;
> > }
> > }
> > -if (ret == FRAME_SKIPPED)
> > +if (ret == FRAME_SKIPPED || ret == FRAME_NOT_CODED) {
> > +if (s->next_picture_ptr && ret == FRAME_NOT_CODED &&
> !s->divx_packed) {
> > +if ((ret = av_frame_ref(pict, s->next_picture_ptr->f)) < 0)
> {
> > +return ret;
> > +}
> > +*got_frame = 1;
> > +}
> > return get_consumed_bytes(s, buf_size);
> > +}
> >
> > /* skip if the header was thrashed */
> > if (ret < 0) {
> > diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
> > index 82c4f8fc8c..3a9ed12971 100644
> > --- a/libavcodec/mpeg4videodec.c
> > +++ b/libavcodec/mpeg4videodec.c
> > @@ -2394,7 +2394,7 @@ static int decode_vop_header(Mpeg4DecContext
> *ctx, GetBitContext *gb)
> > if (get_bits1(gb) != 1) {
> > if (s->avctx->debug & FF_DEBUG_PICT_INFO)
> > av_log(s->avctx, AV_LOG_ERROR, "vop not coded\n");
> > -return FRAME_SKIPPED;
> > +return FRAME_NOT_CODED;
> > }
> > if (ctx->new_pred)
> > decode_new_pred(ctx, gb);
>
> the return codes are documented currently:
> * @return <0 if no VOP found (or a damaged one)
> * FRAME_SKIPPED if a not coded VOP is found
> * 0 if a VOP is found
>
> you added a case but did not update all use cases
>
>
I can update the text here. But i was waiting to get some idea if the patch
seems to be ok for all of you or not.
If the idea sounds ok, I will update it.
> which seems to
> lead to intermittent crashes (i cant say for sure as i failed to
> reproduce one in a debugger or with any debuging code added)
>
>
i tried some files here and could not get any crash so far. I used asan as
well to find out if something was wrong.
> Also returning frames for skiped frames when te match the previous
> would slow the code down as more frames would need to be processed.
> more so i think this is not the only codec that can skip frames
> so any downstream problems will likely not be worked around by forcing
> constant fps with frame duplication here
>
>
True, but the decoder does not return a frame, so the got_output is set to
false for those packets and in this case, we are not increasing the
ist->next_pts
So, in we do have a lot of n_vop frame at the end, we are not setting the
next_pts to them and when we are closing the filtergraph, we are setting
the EOF time to the last decoded frame. And so, we are not padding the
video to match the original timestamp/duration of the input.
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> It is what and why we do it that matters, not just one of them.
>
> ___
> 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] libavcodec/lossless_videodsp : add add_bytes AVX2
2017-10-25 9:43 GMT+02:00 Paul B Mahol :
> On 10/21/17, Martin Vignali wrote:
> > Hello,
> >
> > In attach patch to add AVX2 version for add_bytes
> >
> > 0001-libavcodec-lossless_videodsp-add-add_bytes-avx2-vers :
> > add AVX2 version
> >
> > pass fate-test for me (os 10.12, x86_64)
> >
> > checkasm result : (Kaby Lake) (run 10 times, and i took the fastest
> > version)
> > checkasm: all 2 tests passed
> > add_bytes_c: 108.7
> > add_bytes_sse2: 26.5
> > add_bytes_avx2: 15.5
> >
> >
> > 0002-libavcodec-lossless_video_dsp-cosmetic-add-better-se:
> > only cosmetic
> > like the ref c function declaration in asm file is not consistent between
> > each asm file
> > i think a better separator for each function make the file easier to read
> >
> > also add the c declaration for add bytes in comment
> >
> >
> > Martin
> >
>
> Are you sure 32bit alignment is actually enforced?
>
>
Hello,
I think, data used by add_bytes is always aligned
because dst and src, are start of a line of an AvFrame
More details :
the add_bytes func is used only by magicyuv and huffyuvdec
*in MagicYuv decoder*
uint8_t *b = p->data[0] + j * s->slice_height * p->linesize[0];
uint8_t *g = p->data[1] + j * s->slice_height * p->linesize[1];
uint8_t *r = p->data[2] + j * s->slice_height * p->linesize[2];
...
for (i = 0; i < height; i++) {
s->llviddsp.add_bytes(b, g, width);
s->llviddsp.add_bytes(r, g, width);
b += p->linesize[0];
g += p->linesize[1];
r += p->linesize[2];
*In Huffyuv Decoder*
add_bytes is call directly
or with a call to static void add_bytes(HYuvContext *s, uint8_t *dst,
uint8_t *src, int w)
*First use : *
add_bytes(s, dst, dst - fake_stride, w);
==>
uint8_t *dst = p->data[plane] + p->linesize[plane]*y;
and fake_stride is a multiple of linesize of the frame
*Second use :*
s->llviddsp.add_bytes(ydst, ydst - fake_ystride, width);
==> same idea here ydst is the start of a line
fake_ystride is a multiple of linesize
*Third use : *
s->llviddsp.add_bytes(ydst, ydst - fake_ystride, width);
if (!(s->flags & AV_CODEC_FLAG_GRAY)) {
s->llviddsp.add_bytes(udst, udst - fake_ustride, width2);
s->llviddsp.add_bytes(vdst, vdst - fake_vstride, width2);
==> Same idea here
*Last use : *
s->llviddsp.add_bytes(p->data[0] + p->linesize[0] * y, p->data[0] +
p->linesize[0] * y + fake_ystride, 4 * width);
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/utvideodsp : add avx2 version
2017-10-22 14:05 GMT+02:00 Martin Vignali : > Hello, > > In attach patch to add AVX2 version for the utvideodsp > > Checkasm result (Kaby Lake, os 10.12) > restore_rgb_planes_c: 8371.0 > restore_rgb_planes_sse2: 6583.7 > restore_rgb_planes_avx2: 3596.5 > > restore_rgb_planes10_c: 16735.7 > restore_rgb_planes10_sse2: 11478.5 > restore_rgb_planes10_avx2: 7193.7 > > > Pass fate test for me > > > 0001-checkasm-add-utvideodsp-test : > I'm not entirely sure of mine, for this checkasm, > > 0002-libavcodec-x86-utvideodsp-make-macro-for-func > Code reorganization > > 0003-libavcodec-utvideodsp-add-avx2-version-for-the-dsp > AVX2 version > > 0004-libavcodec-x86-utvideodsp.asm-cosmetic > Cosmetic > > Martin > Jokyo Images > > Following comments of Paul B Mahol in another thread Here too, data alignment "is made" with AVFrame->data / AVFrame->linesize these func are call with this code : c->utdsp.restore_rgb_planes(frame.f->data[2], frame.f->data[0], frame.f->data[1], frame.f->linesize[2], frame.f->linesize[0], frame.f->linesize[1], avctx->width, avctx->height); and c->utdsp.restore_rgb_planes10((uint16_t *)frame.f->data[2], (uint16_t *)frame.f->data[0], (uint16_t *)frame.f->data[1], frame.f->linesize[2] / 2, frame.f->linesize[0] / 2, frame.f->linesize[1] / 2, avctx->width, avctx->height); Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/lossless_videodsp : add add_bytes AVX2
On 10/25/17, Martin Vignali wrote: > 2017-10-25 9:43 GMT+02:00 Paul B Mahol : > >> On 10/21/17, Martin Vignali wrote: >> > Hello, >> > >> > In attach patch to add AVX2 version for add_bytes >> > >> > 0001-libavcodec-lossless_videodsp-add-add_bytes-avx2-vers : >> > add AVX2 version >> > >> > pass fate-test for me (os 10.12, x86_64) >> > >> > checkasm result : (Kaby Lake) (run 10 times, and i took the fastest >> > version) >> > checkasm: all 2 tests passed >> > add_bytes_c: 108.7 >> > add_bytes_sse2: 26.5 >> > add_bytes_avx2: 15.5 >> > >> > >> > 0002-libavcodec-lossless_video_dsp-cosmetic-add-better-se: >> > only cosmetic >> > like the ref c function declaration in asm file is not consistent >> > between >> > each asm file >> > i think a better separator for each function make the file easier to >> > read >> > >> > also add the c declaration for add bytes in comment >> > >> > >> > Martin >> > >> >> Are you sure 32bit alignment is actually enforced? >> >> > Hello, > > I think, data used by add_bytes is always aligned > because dst and src, are start of a line of an AvFrame Yes, but try width thats not multiple of 32. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/lossless_videodsp : add add_bytes AVX2
2017-10-25 21:53 GMT+02:00 Paul B Mahol : > On 10/25/17, Martin Vignali wrote: > > 2017-10-25 9:43 GMT+02:00 Paul B Mahol : > > > >> On 10/21/17, Martin Vignali wrote: > >> > Hello, > >> > > >> > In attach patch to add AVX2 version for add_bytes > >> > > >> > 0001-libavcodec-lossless_videodsp-add-add_bytes-avx2-vers : > >> > add AVX2 version > >> > > >> > pass fate-test for me (os 10.12, x86_64) > >> > > >> > checkasm result : (Kaby Lake) (run 10 times, and i took the fastest > >> > version) > >> > checkasm: all 2 tests passed > >> > add_bytes_c: 108.7 > >> > add_bytes_sse2: 26.5 > >> > add_bytes_avx2: 15.5 > >> > > >> > > >> > 0002-libavcodec-lossless_video_dsp-cosmetic-add-better-se: > >> > only cosmetic > >> > like the ref c function declaration in asm file is not consistent > >> > between > >> > each asm file > >> > i think a better separator for each function make the file easier to > >> > read > >> > > >> > also add the c declaration for add bytes in comment > >> > > >> > > >> > Martin > >> > > >> > >> Are you sure 32bit alignment is actually enforced? > >> > >> > > Hello, > > > > I think, data used by add_bytes is always aligned > > because dst and src, are start of a line of an AvFrame > > Yes, but try width thats not multiple of 32. > ___ > > Sorry, not sure i understand. following the doc, AVFrame->linesize, is multiple of max alignment and in the asm, loop will be repeat until, val < width Can you indicate me, the part, where you think, it's not ok ? Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/lossless_videodsp : add add_bytes AVX2
On 10/25/17, Martin Vignali wrote: > 2017-10-25 21:53 GMT+02:00 Paul B Mahol : > >> On 10/25/17, Martin Vignali wrote: >> > 2017-10-25 9:43 GMT+02:00 Paul B Mahol : >> > >> >> On 10/21/17, Martin Vignali wrote: >> >> > Hello, >> >> > >> >> > In attach patch to add AVX2 version for add_bytes >> >> > >> >> > 0001-libavcodec-lossless_videodsp-add-add_bytes-avx2-vers : >> >> > add AVX2 version >> >> > >> >> > pass fate-test for me (os 10.12, x86_64) >> >> > >> >> > checkasm result : (Kaby Lake) (run 10 times, and i took the fastest >> >> > version) >> >> > checkasm: all 2 tests passed >> >> > add_bytes_c: 108.7 >> >> > add_bytes_sse2: 26.5 >> >> > add_bytes_avx2: 15.5 >> >> > >> >> > >> >> > 0002-libavcodec-lossless_video_dsp-cosmetic-add-better-se: >> >> > only cosmetic >> >> > like the ref c function declaration in asm file is not consistent >> >> > between >> >> > each asm file >> >> > i think a better separator for each function make the file easier to >> >> > read >> >> > >> >> > also add the c declaration for add bytes in comment >> >> > >> >> > >> >> > Martin >> >> > >> >> >> >> Are you sure 32bit alignment is actually enforced? >> >> >> >> >> > Hello, >> > >> > I think, data used by add_bytes is always aligned >> > because dst and src, are start of a line of an AvFrame >> >> Yes, but try width thats not multiple of 32. >> ___ >> >> > Sorry, not sure i understand. > following the doc, AVFrame->linesize, is multiple of max alignment > > and in the asm, loop will be repeat until, val < width > > Can you indicate me, the part, where you think, it's not ok ? I dunno. You should test it with widths not divisible by 32. also try encoding cropped video. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/lossless_videodsp : add add_bytes AVX2
2017-10-25 22:08 GMT+02:00 Paul B Mahol : > On 10/25/17, Martin Vignali wrote: > > 2017-10-25 21:53 GMT+02:00 Paul B Mahol : > > > >> On 10/25/17, Martin Vignali wrote: > >> > 2017-10-25 9:43 GMT+02:00 Paul B Mahol : > >> > > >> >> On 10/21/17, Martin Vignali wrote: > >> >> > Hello, > >> >> > > >> >> > In attach patch to add AVX2 version for add_bytes > >> >> > > >> >> > 0001-libavcodec-lossless_videodsp-add-add_bytes-avx2-vers : > >> >> > add AVX2 version > >> >> > > >> >> > pass fate-test for me (os 10.12, x86_64) > >> >> > > >> >> > checkasm result : (Kaby Lake) (run 10 times, and i took the fastest > >> >> > version) > >> >> > checkasm: all 2 tests passed > >> >> > add_bytes_c: 108.7 > >> >> > add_bytes_sse2: 26.5 > >> >> > add_bytes_avx2: 15.5 > >> >> > > >> >> > > >> >> > 0002-libavcodec-lossless_video_dsp-cosmetic-add-better-se: > >> >> > only cosmetic > >> >> > like the ref c function declaration in asm file is not consistent > >> >> > between > >> >> > each asm file > >> >> > i think a better separator for each function make the file easier > to > >> >> > read > >> >> > > >> >> > also add the c declaration for add bytes in comment > >> >> > > >> >> > > >> >> > Martin > >> >> > > >> >> > >> >> Are you sure 32bit alignment is actually enforced? > >> >> > >> >> > >> > Hello, > >> > > >> > I think, data used by add_bytes is always aligned > >> > because dst and src, are start of a line of an AvFrame > >> > >> Yes, but try width thats not multiple of 32. > >> ___ > >> > >> > > Sorry, not sure i understand. > > following the doc, AVFrame->linesize, is multiple of max alignment > > > > and in the asm, loop will be repeat until, val < width > > > > Can you indicate me, the part, where you think, it's not ok ? > > I dunno. You should test it with widths not divisible by 32. > Tested with the fate sample : vsynth3-huffyuvbgra.avi (34x34) ./ffmpeg -i ./tests/data/fate/vsynth3-huffyuvbgra.avi -f framecrc - generate same crc than ./ffmpeg -i ./tests/data/fate/vsynth3-huffyuvbgra.avi -f framecrc - -cpuflags 0 > > also try encoding cropped video. > Are you sure, encoding cropped video, have a link to the decoding dsp func ? these patch only take care about the decoding func And the encoding func of huffyuvenc (in huffyuv add add/diff_bytes16 AVX2 discussion) and losslessencdsp (not made for now), have a test for alignment of dst and src Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/lossless_videodsp : add add_bytes AVX2
On 10/25/17, Martin Vignali wrote: > 2017-10-25 22:08 GMT+02:00 Paul B Mahol : > >> On 10/25/17, Martin Vignali wrote: >> > 2017-10-25 21:53 GMT+02:00 Paul B Mahol : >> > >> >> On 10/25/17, Martin Vignali wrote: >> >> > 2017-10-25 9:43 GMT+02:00 Paul B Mahol : >> >> > >> >> >> On 10/21/17, Martin Vignali wrote: >> >> >> > Hello, >> >> >> > >> >> >> > In attach patch to add AVX2 version for add_bytes >> >> >> > >> >> >> > 0001-libavcodec-lossless_videodsp-add-add_bytes-avx2-vers : >> >> >> > add AVX2 version >> >> >> > >> >> >> > pass fate-test for me (os 10.12, x86_64) >> >> >> > >> >> >> > checkasm result : (Kaby Lake) (run 10 times, and i took the >> >> >> > fastest >> >> >> > version) >> >> >> > checkasm: all 2 tests passed >> >> >> > add_bytes_c: 108.7 >> >> >> > add_bytes_sse2: 26.5 >> >> >> > add_bytes_avx2: 15.5 >> >> >> > >> >> >> > >> >> >> > 0002-libavcodec-lossless_video_dsp-cosmetic-add-better-se: >> >> >> > only cosmetic >> >> >> > like the ref c function declaration in asm file is not consistent >> >> >> > between >> >> >> > each asm file >> >> >> > i think a better separator for each function make the file easier >> to >> >> >> > read >> >> >> > >> >> >> > also add the c declaration for add bytes in comment >> >> >> > >> >> >> > >> >> >> > Martin >> >> >> > >> >> >> >> >> >> Are you sure 32bit alignment is actually enforced? >> >> >> >> >> >> >> >> > Hello, >> >> > >> >> > I think, data used by add_bytes is always aligned >> >> > because dst and src, are start of a line of an AvFrame >> >> >> >> Yes, but try width thats not multiple of 32. >> >> ___ >> >> >> >> >> > Sorry, not sure i understand. >> > following the doc, AVFrame->linesize, is multiple of max alignment >> > >> > and in the asm, loop will be repeat until, val < width >> > >> > Can you indicate me, the part, where you think, it's not ok ? >> >> I dunno. You should test it with widths not divisible by 32. >> > > Tested with the fate sample : vsynth3-huffyuvbgra.avi (34x34) > ./ffmpeg -i ./tests/data/fate/vsynth3-huffyuvbgra.avi -f framecrc - > > generate same crc than > ./ffmpeg -i ./tests/data/fate/vsynth3-huffyuvbgra.avi -f framecrc - > -cpuflags 0 > > >> >> also try encoding cropped video. >> > > Are you sure, encoding cropped video, have a link to the decoding dsp func ? > > these patch only take care about the decoding func > > > And the encoding func of huffyuvenc (in huffyuv add add/diff_bytes16 AVX2 > discussion) > and losslessencdsp (not made for now), have a test for alignment of dst and > src > > > Martin > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ok then ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.
This time to the list properly... woops. On 10/25/2017 7:38 PM, Thierry Foucu wrote: > I tried using one of those files. > Without the patch, the decoder will return only 29 frames > With this patch, the decoder will return 1947 frames. > The time of decoding the file were the same (with or without) Makes sense (because of reference counting). > I think where it may slow down, it's in case we transcode the file and we > are not doing constant frame rate, then the encoder will have to encode > 1947 frames instead of 24 frames. > But for decoding it the same. Yeah, that's what I thought might happen. However, thinking about it a bit more, these files are old and rare enough that we probably shouldn't care about such an edge case, and the decoder outputting duplicate frames is probably easier for the API user. So, no objection from me. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.
2017-10-25 20:38 GMT+02:00 Thierry Foucu : > Without the patch, the decoder will return only 29 frames Isn't that the correct and expected output? If you need cfr, you can request it. Once the frames are duplicated, you can't undo the file size multiplication. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Properly store sampling rate for FLAC in mp4
2017-10-25 16:52 GMT+02:00 Jean-Yves Avenard :
> hi
>
> On 26 August 2017 at 12:08, Carl Eugen Hoyos wrote:
>> 2017-08-25 13:25 GMT+02:00 Jean-Yves Avenard :
>>
>>> +if (track->par->codec_id == AV_CODEC_ID_FLAC) {
>>
>> Why does this only apply to flac?
>>
>
> Sorry, I had missed your reply.
>
> The specification on how sampling rate is to be stored should it be
> greater than INT16_MAX is a FLAC in ISOBMFF requirement:
>
> https://git.xiph.org/?p=flac.git;a=blob;f=doc/isoflac.txt;h=574df9f54a779fca2e62c726703fc7be199d4c05;hb=refs/heads/master#l165
>
> It definitely could be applied to other codecs, but I haven't seen
> such requirements clearly defined.
>
> ISOBMFF only defines that AudioSampleEntryV1 should be used instead,
> in which case the sampling_rate is a 32 bits integer (ISO 14496-12
> 12.2.3.2)
Not sure I understand:
In ticket #6609, I asked if this is a flac-only issue.
You answered: "The issue can be reproduced with any codec."
So why does your patch only fix the issue for flac?
Or do I misunderstand?
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] cbs_mpeg2: Fix type for marker_bit reading
2017-10-25 10:06 GMT+02:00 Hendrik Leppkes : > As if static analyzers always care what you can and cannot do. :p It was actually asan or ubsan iirc. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/jpeglsdec: Check for end of bitstream in ls_decode_line()
Fixes: 1773/clusterfuzz-testcase-minimized-4832523987189760
Fixes: Timeout
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/jpeglsdec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/jpeglsdec.c b/libavcodec/jpeglsdec.c
index cb2f89a88c..5308b744df 100644
--- a/libavcodec/jpeglsdec.c
+++ b/libavcodec/jpeglsdec.c
@@ -233,6 +233,9 @@ static inline void ls_decode_line(JLSState *state,
MJpegDecodeContext *s,
while (x < w) {
int err, pred;
+if (get_bits_left(&s->gb) <= 0)
+return;
+
/* compute gradients */
Ra = x ? R(dst, x - stride) : R(last, x);
Rb = R(last, x);
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/jpeglsdec: Check ilv for being a supported value
Fixes: 1773/clusterfuzz-testcase-minimized-4832523987189760
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/jpeglsdec.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/jpeglsdec.c b/libavcodec/jpeglsdec.c
index 64505321af..cb2f89a88c 100644
--- a/libavcodec/jpeglsdec.c
+++ b/libavcodec/jpeglsdec.c
@@ -443,6 +443,10 @@ int ff_jpegls_decode_picture(MJpegDecodeContext *s, int
near,
avpriv_report_missing_feature(s->avctx, "Sample interleaved images");
ret = AVERROR_PATCHWELCOME;
goto end;
+} else { /* unknown interleaving */
+avpriv_report_missing_feature(s->avctx, "Unknown interleaved images");
+ret = AVERROR_PATCHWELCOME;
+goto end;
}
if (s->xfrm && s->nb_components == 3) {
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Properly store sampling rate for FLAC in mp4
Hi,
On Wed, Oct 25, 2017 at 5:57 PM, Carl Eugen Hoyos
wrote:
> 2017-10-25 16:52 GMT+02:00 Jean-Yves Avenard :
> > hi
> >
> > On 26 August 2017 at 12:08, Carl Eugen Hoyos wrote:
> >> 2017-08-25 13:25 GMT+02:00 Jean-Yves Avenard :
> >>
> >>> +if (track->par->codec_id == AV_CODEC_ID_FLAC) {
> >>
> >> Why does this only apply to flac?
> >>
> >
> > Sorry, I had missed your reply.
> >
> > The specification on how sampling rate is to be stored should it be
> > greater than INT16_MAX is a FLAC in ISOBMFF requirement:
> >
> > https://git.xiph.org/?p=flac.git;a=blob;f=doc/isoflac.txt;h=
> 574df9f54a779fca2e62c726703fc7be199d4c05;hb=refs/heads/master#l165
> >
> > It definitely could be applied to other codecs, but I haven't seen
> > such requirements clearly defined.
> >
> > ISOBMFF only defines that AudioSampleEntryV1 should be used instead,
> > in which case the sampling_rate is a 32 bits integer (ISO 14496-12
> > 12.2.3.2)
>
> Not sure I understand:
> In ticket #6609, I asked if this is a flac-only issue.
> You answered: "The issue can be reproduced with any codec."
>
> So why does your patch only fix the issue for flac?
> Or do I misunderstand?
>
The extension for storing values greater than int16_max is only part of the
isobmff-flac spec, it's not generalized for other audio codecs. Using it
for other audio codecs may have unwanted results, which is why it's
flac-specific.
Do you want a comment in the source code to make this easier to understand
for future developers staring at this code?
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/crc: always use precalculated CRC tables for known polynomials
On Tue, Oct 24, 2017 at 6:05 PM, Michael Niedermayer wrote: > On Mon, Oct 23, 2017 at 10:36:21PM -0300, James Almer wrote: >> On 10/23/2017 10:24 PM, Michael Niedermayer wrote: >> > On Tue, Oct 24, 2017 at 01:39:03AM +0100, Mark Thompson wrote: >> >> On 24/10/17 00:52, Michael Niedermayer wrote: >> >>> Hi >> >>> >> >>> On Mon, Oct 23, 2017 at 04:43:19PM +0100, Mark Thompson wrote: >> On 23/10/17 03:56, Michael Niedermayer wrote: >> > the initialization should be thread safe as it never writes a different >> > value in the same spot >> >> This is not true; please be very careful with assumptions like this. >> >> The C standard calls this a data race and it is undefined behaviour. >> >>> >> >>> Thats interresting, we definitly do not want undefined behavior >> >>> can you quote the relevant parts of the C standard >> >>> which make writing the same value, a data race ? >> >>> >> >>> I was not aware of this if its true. >> >>> Also i dont immedeatly see this in the "latest" draft i am looking at >> >>> atm >> >>> >> >>> What i see is this: >> >>> 4 Two expression evaluations conflict if one of them modifies a memory >> >>> location and the >> >>> other one reads or modifies the same memory location. >> >>> ... >> >>> 25 The execution of a program contains a data race if it contains two >> >>> conflicting actions in >> >>>different threads, at least one of which is not atomic, and neither >> >>> happens before the >> >>>other. Any such data race results in undefined behavior. >> >>> >> >>> This seems carefully worded to not include writing the same value. >> >>> As "modification" implies change which does not occur when writing the >> >>> same value. >> >> >> >> All writes are modifications. >> >> >> >> See section 3.1 note 2: >> >> """ >> >> 3 NOTE 2 "Modify"€™ includes the case where the new value being stored >> >> is the same as the previous value. >> >> """ >> > >> > That resolves the difference between our interpretation >> > >> > thanks >> >> Should i push this, or does someone want to give ff_thread_once() a try? > > If ff_thread_once() is used outside init code, it should be benchmarked > as it may be a bad idea speed wise. > During init speed doesnt matter so ff_thread_once() there would be fine > but would require more changes to move it to init. Using my patch: Benchmark: make fate-lavf-png at pngenc.c:png_write_chunk old: 150640 decicycles in av_crc_get_table:first, 1 runs, 0 skips 1740 decicycles in av_crc_get_table, 1 runs, 0 skips 1390 decicycles in av_crc_get_table, 2 runs, 0 skips 945 decicycles in av_crc_get_table, 4 runs, 0 skips 720 decicycles in av_crc_get_table, 8 runs, 0 skips 592 decicycles in av_crc_get_table, 16 runs, 0 skips 536 decicycles in av_crc_get_table, 32 runs, 0 skips 510 decicycles in av_crc_get_table, 64 runs, 0 skips 497 decicycles in av_crc_get_table, 128 runs, 0 skips 494 decicycles in av_crc_get_table, 256 runs, 0 skips 479 decicycles in av_crc_get_table, 512 runs, 0 skips 454 decicycles in av_crc_get_table,1024 runs, 0 skips 434 decicycles in av_crc_get_table,2048 runs, 0 skips new: 235060 decicycles in av_crc_get_table:first, 1 runs, 0 skips 2900 decicycles in av_crc_get_table, 1 runs, 0 skips 2560 decicycles in av_crc_get_table, 2 runs, 0 skips 1825 decicycles in av_crc_get_table, 4 runs, 0 skips 1200 decicycles in av_crc_get_table, 8 runs, 0 skips 902 decicycles in av_crc_get_table, 16 runs, 0 skips 719 decicycles in av_crc_get_table, 32 runs, 0 skips 628 decicycles in av_crc_get_table, 64 runs, 0 skips 576 decicycles in av_crc_get_table, 128 runs, 0 skips 550 decicycles in av_crc_get_table, 256 runs, 0 skips 532 decicycles in av_crc_get_table, 512 runs, 0 skips 499 decicycles in av_crc_get_table,1024 runs, 0 skips 470 decicycles in av_crc_get_table,2048 runs, 0 skips Thank's. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.
On Wed, Oct 25, 2017 at 2:43 PM, Carl Eugen Hoyos wrote: > 2017-10-25 20:38 GMT+02:00 Thierry Foucu : > > > Without the patch, the decoder will return only 29 frames > > Isn't that the correct and expected output? > Not sure what you mean by correct. There are only 29 VOP encoded, and over 1900 N_VOP packets. If you just demux the sample file, you will get 1947 packets I used the Xvid decoder from http://svn.xvid.org/trunk/xvidcore/examples/xvid_decraw.c to decode the same file, and their decoder outputted 1947 frames. > > If you need cfr, you can request it. > true, but this works as long as you have 2 frames and you can cfr between them. But what if you have the last X second of the file with only N_VOP frames In this case, the decoder will not output frames and the transcoded file will be shorter by X second > Once the frames are duplicated, you can't undo the file > size multiplication. > > Carl Eugen > ___ > 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] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.
On Wed, Oct 25, 2017 at 04:21:28PM -0700, Thierry Foucu wrote: > On Wed, Oct 25, 2017 at 2:43 PM, Carl Eugen Hoyos > wrote: > > > 2017-10-25 20:38 GMT+02:00 Thierry Foucu : > > > > > Without the patch, the decoder will return only 29 frames > > > > Isn't that the correct and expected output? > > > > Not sure what you mean by correct. > There are only 29 VOP encoded, and over 1900 N_VOP packets. > If you just demux the sample file, you will get 1947 packets > > I used the Xvid decoder from > http://svn.xvid.org/trunk/xvidcore/examples/xvid_decraw.c > > to decode the same file, and their decoder outputted 1947 frames. > > > > > > If you need cfr, you can request it. > > > > true, but this works as long as you have 2 frames and you can cfr between > them. But what if you have the last X second of the file with only N_VOP > frames > In this case, the decoder will not output frames and the transcoded file > will be shorter by X second the decoder could output a final frame during decoder flush to make sure the last NVOPs duration is not lost [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.
On Wed, Oct 25, 2017 at 4:36 PM, Michael Niedermayer wrote: > On Wed, Oct 25, 2017 at 04:21:28PM -0700, Thierry Foucu wrote: > > On Wed, Oct 25, 2017 at 2:43 PM, Carl Eugen Hoyos > > wrote: > > > > > 2017-10-25 20:38 GMT+02:00 Thierry Foucu : > > > > > > > Without the patch, the decoder will return only 29 frames > > > > > > Isn't that the correct and expected output? > > > > > > > Not sure what you mean by correct. > > There are only 29 VOP encoded, and over 1900 N_VOP packets. > > If you just demux the sample file, you will get 1947 packets > > > > I used the Xvid decoder from > > http://svn.xvid.org/trunk/xvidcore/examples/xvid_decraw.c > > > > to decode the same file, and their decoder outputted 1947 frames. > > > > > > > > > > If you need cfr, you can request it. > > > > > > > true, but this works as long as you have 2 frames and you can cfr between > > them. But what if you have the last X second of the file with only N_VOP > > frames > > In this case, the decoder will not output frames and the transcoded file > > will be shorter by X second > > the decoder could output a final frame during decoder flush to make > sure the last NVOPs duration is not lost > Oh, that's sound interesting. Let me see if i understand the code enough to do exactly this. > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Those who are too smart to engage in politics are punished by being > governed by those who are dumber. -- Plato > > ___ > 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 2/2] avformat/hlsenc: fix missing first segment bug in fmp4 mode
fix ticket id: #6776
fix code logic error, need not check first segment.
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 55ce800c5a..caced6a3dd 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1080,15 +1080,16 @@ static int hls_window(AVFormatContext *s, int last)
avio_printf(out, ",BYTERANGE=\"%"PRId64"@%"PRId64"\"",
en->size, en->pos);
}
avio_printf(out, "\n");
-} else {
-if (hls->flags & HLS_ROUND_DURATIONS)
-avio_printf(out, "#EXTINF:%ld,\n", lrint(en->duration));
-else
-avio_printf(out, "#EXTINF:%f,\n", en->duration);
-if (byterange_mode)
-avio_printf(out, "#EXT-X-BYTERANGE:%"PRId64"@%"PRId64"\n",
-en->size, en->pos);
}
+
+if (hls->flags & HLS_ROUND_DURATIONS)
+avio_printf(out, "#EXTINF:%ld,\n", lrint(en->duration));
+else
+avio_printf(out, "#EXTINF:%f,\n", en->duration);
+if (byterange_mode)
+avio_printf(out, "#EXT-X-BYTERANGE:%"PRId64"@%"PRId64"\n",
+en->size, en->pos);
+
if (hls->flags & HLS_PROGRAM_DATE_TIME) {
time_t tt, wrongsecs;
int milli;
@@ -1113,11 +1114,10 @@ static int hls_window(AVFormatContext *s, int last)
avio_printf(out, "#EXT-X-PROGRAM-DATE-TIME:%s.%03d%s\n", buf0,
milli, buf1);
prog_date_time += en->duration;
}
-if (!((hls->segment_type == SEGMENT_TYPE_FMP4) && (en ==
hls->segments))) {
-if (hls->baseurl)
-avio_printf(out, "%s", hls->baseurl);
-avio_printf(out, "%s\n", en->filename);
-}
+
+if (hls->baseurl)
+avio_printf(out, "%s", hls->baseurl);
+avio_printf(out, "%s\n", en->filename);
}
if (last && (hls->flags & HLS_OMIT_ENDLIST)==0)
--
2.11.0 (Apple Git-81)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fix base_output_dirname is null when basename_size is 0 bug
fix ticket id: #6777
when use argument hls_segment_filename, the basename_size will be 0
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 418f153c6f..55ce800c5a 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1335,6 +1335,7 @@ static int hls_write_header(AVFormatContext *s)
AVDictionary *options = NULL;
int basename_size = 0;
int vtt_basename_size = 0;
+int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
if (hls->segment_type == SEGMENT_TYPE_FMP4) {
pattern = "%d.m4s";
@@ -1445,7 +1446,6 @@ static int hls_write_header(AVFormatContext *s)
}
if (av_strcasecmp(hls->fmp4_init_filename, "init.mp4")) {
-int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
hls->base_output_dirname = av_malloc(fmp4_init_filename_len);
if (!hls->base_output_dirname) {
ret = AVERROR(ENOMEM);
@@ -1453,19 +1453,25 @@ static int hls_write_header(AVFormatContext *s)
}
av_strlcpy(hls->base_output_dirname, hls->fmp4_init_filename,
fmp4_init_filename_len);
} else {
-hls->base_output_dirname = av_malloc(basename_size);
+if (basename_size > 0) {
+hls->base_output_dirname = av_malloc(basename_size);
+} else {
+hls->base_output_dirname =
av_malloc(strlen(hls->fmp4_init_filename));
+}
if (!hls->base_output_dirname) {
ret = AVERROR(ENOMEM);
goto fail;
}
-av_strlcpy(hls->base_output_dirname, s->filename, basename_size);
-p = strrchr(hls->base_output_dirname, '/');
+if (basename_size > 0) {
+av_strlcpy(hls->base_output_dirname, s->filename, basename_size);
+p = strrchr(hls->base_output_dirname, '/');
+}
if (p) {
*(p + 1) = '\0';
av_strlcat(hls->base_output_dirname, hls->fmp4_init_filename,
basename_size);
} else {
-av_strlcpy(hls->base_output_dirname, hls->fmp4_init_filename,
basename_size);
+av_strlcpy(hls->base_output_dirname, hls->fmp4_init_filename,
fmp4_init_filename_len);
}
}
--
2.11.0 (Apple Git-81)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Properly store sampling rate for FLAC in mp4
On Wed, Oct 25, 2017 at 06:48:06PM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Wed, Oct 25, 2017 at 5:57 PM, Carl Eugen Hoyos
> wrote:
>
> > 2017-10-25 16:52 GMT+02:00 Jean-Yves Avenard :
> > > hi
> > >
> > > On 26 August 2017 at 12:08, Carl Eugen Hoyos wrote:
> > >> 2017-08-25 13:25 GMT+02:00 Jean-Yves Avenard :
> > >>
> > >>> +if (track->par->codec_id == AV_CODEC_ID_FLAC) {
> > >>
> > >> Why does this only apply to flac?
> > >>
> > >
> > > Sorry, I had missed your reply.
> > >
> > > The specification on how sampling rate is to be stored should it be
> > > greater than INT16_MAX is a FLAC in ISOBMFF requirement:
> > >
> > > https://git.xiph.org/?p=flac.git;a=blob;f=doc/isoflac.txt;h=
> > 574df9f54a779fca2e62c726703fc7be199d4c05;hb=refs/heads/master#l165
> > >
> > > It definitely could be applied to other codecs, but I haven't seen
> > > such requirements clearly defined.
> > >
> > > ISOBMFF only defines that AudioSampleEntryV1 should be used instead,
> > > in which case the sampling_rate is a 32 bits integer (ISO 14496-12
> > > 12.2.3.2)
> >
> > Not sure I understand:
> > In ticket #6609, I asked if this is a flac-only issue.
> > You answered: "The issue can be reproduced with any codec."
> >
> > So why does your patch only fix the issue for flac?
> > Or do I misunderstand?
> >
>
> The extension for storing values greater than int16_max is only part of the
> isobmff-flac spec, it's not generalized for other audio codecs. Using it
> for other audio codecs may have unwanted results, which is why it's
> flac-specific.
>
> Do you want a comment in the source code to make this easier to understand
> for future developers staring at this code?
the question wasnt intended for me, but yes
[...]
--
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: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: fix mpeg2-ticket6677 faillures on some platforms
On Wed, Oct 25, 2017 at 01:45:22PM +0800, Zhong Li wrote: > Signed-off-by: Zhong Li > --- > tests/fate/video.mak | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/exif: remove GetByteContext usage from avpriv_exif_decode_ifd()
On 10/25/2017 4:32 AM, Paul B Mahol wrote: > On 10/24/17, James Almer wrote: >> This prevents potential ABI issues with GetByteContext. >> >> Signed-off-by: James Almer >> --- >> libavcodec/exif.c | 16 +--- >> libavcodec/exif.h | 6 -- >> libavcodec/mjpegdec.c | 2 +- >> libavcodec/webp.c | 2 +- >> libavformat/avidec.c | 4 ++-- >> 5 files changed, 21 insertions(+), 9 deletions(-) >> > > > lgtm Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/tak: remove GetBitContext usage from avpriv_tak_parse_streaminfo()
On 10/25/2017 4:37 AM, Paul B Mahol wrote: > On 10/23/17, James Almer wrote: >> This prevents potential ABI issues with GetBitContext. >> >> Signed-off-by: James Almer >> --- >> libavcodec/tak.c | 17 +++-- >> libavcodec/tak.h | 8 ++-- >> libavformat/takdec.c | 7 +-- >> 3 files changed, 26 insertions(+), 6 deletions(-) >> > > lgtm Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/wavenc: skip writing incorrect peak-of-peaks position value
On 25.10.2017 20:01, Michael Niedermayer wrote: On Wed, Oct 25, 2017 at 07:55:52PM +0200, Michael Niedermayer wrote: On Tue, Oct 24, 2017 at 11:47:21AM +0200, Tobias Rapp wrote: According to EBU tech 3285 supplement 3 the dwPosPeakOfPeaks field should contain the absolute position to the maximum audio sample value, but the current implementation writes the relative peak frame index instead. Fix the issue by writing the "unknown" value (-1) for now until the feature is implemented correctly. Previous version reviewed-by: Peter Bubestinger Signed-off-by: Tobias Rapp --- v2: - added version micro bump - more code clean-up libavformat/version.h| 2 +- libavformat/wavenc.c | 11 +-- tests/ref/lavf/wav_peak | 2 +- tests/ref/lavf/wav_peak_only | 2 +- 4 files changed, 4 insertions(+), 13 deletions(-) will apply, thanks rather LGTM, feel free to apply Applied, thanks for review. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Properly store sampling rate for FLAC in mp4
Hi On 25 October 2017 at 23:57, Carl Eugen Hoyos wrote: >> ISOBMFF only defines that AudioSampleEntryV1 should be used instead, >> in which case the sampling_rate is a 32 bits integer (ISO 14496-12 >> 12.2.3.2) > > Not sure I understand: > In ticket #6609, I asked if this is a flac-only issue. > You answered: "The issue can be reproduced with any codec." The issue can be reproduced with every codec. That is, every mp4 file with an audio sampling rate greater than INT16_MAX will have 0 for the sample_rate value. This will prevent those generated files to be played in Firefox for example. A sampling rate of 0 being treated as invalid. This is why I answered that the problem could be reproduce with any codecs. It is a problem with all audio codec when used with FFmpeg generated mp4. However, only the flac-in-isobmff defines on what to do. If we were to generalize the fix to other codec, then those files wouldn't be spec compliant either (though it's my belief it would be better if it were). > > So why does your patch only fix the issue for flac? > Or do I misunderstand? Only the flac-in-isobmff clearly states what to do under those circumstances. For the other format, there's no specific documentation on what should be done for how to store sampling rate value greater than 16 bits. ISOBMFF spec itself define an AudioSampleEntryV1 box instead which has the sampling rate store on 32 bits instead. FFmpeg doesn't support AudioSampleEntryV1 So the special fix for flac is one poor man's attempt to make things better without having to implement a much more complex fix. (That and few players supports AudioSampleEntryV1 either) Hope this help clarify the problem at hand better. Sorry if I didn't make things clearer earlier. JY ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
