Re: [FFmpeg-devel] [PATCH]configure: Make sure libpostproc can be found if -rpath-link doesn't work

[Michael Niedermayer]

On Sat, Dec 22, 2018 at 12:08:19AM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch fixes running fate with "--enable-shared --enable-gpl" on
> Solaris, the linker searches "libpostproc" in a directory"-link=libpostproc".
> Only tested on Solaris.
> 
> Please comment, Carl Eugen

>  configure |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> cb5e59b98712ca53aba4561f4d7fe365b3b1e2ff  
> 0001-configure-Make-sure-libpostproc-can-be-found-if-rpat.patch
> From d69f1fcee41e803e5208bbfabdeb37a19e73814b Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sat, 22 Dec 2018 00:04:43 +0100
> Subject: [PATCH] configure: Make sure libpostproc can be found if -rpath-link
>  doesn't work.
> 
> Solaris ld takes "-rpath-link=libpostproc" as indication to search in 
> "-link=libpostproc".
> ---
>  configure |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index 2205751..04d3417 100755
> --- a/configure
> +++ b/configure
> @@ -6535,7 +6535,7 @@ EOF
>  
>  # add some linker flags
>  check_ldflags -Wl,--warn-common
> -check_ldflags 
> -Wl,-rpath-link=libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample
> +check_ldflags 
> -Wl,-rpath-link=:libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample
>  enabled rpath && add_ldexeflags -Wl,-rpath,$libdir && add_ldsoflags 
> -Wl,-rpath,$libdir
>  test_ldflags -Wl,-Bsymbolic && append SHFLAGS -Wl,-Bsymbolic

theres a second similar use of rpath in git (in tools/target_dec_fuzzer.c)

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] dstdec: use appropriate alignment

[Michael Niedermayer]

On Fri, Dec 21, 2018 at 01:34:19PM +1100, Peter Ross wrote:
> this was a typo in my original patch. there is no requirement for 64-byte
> alignment here, and it does not affect decoder performance.
> ---
>  libavcodec/dstdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] fate: add dst decoder test

[Michael Niedermayer]

On Fri, Dec 21, 2018 at 01:32:03PM +1100, Peter Ross wrote:
> ---
> the dst sample file is 40 kilobytes.
> i don't have write access to fate-suite to upload it.
> 
> 
>  tests/fate/audio.mak   |  3 +++
>  tests/ref/fate/dsf-dst | 16 
>  2 files changed, 19 insertions(+)
>  create mode 100644 tests/ref/fate/dsf-dst

fails on linux x86-32

--- /home/michael/ffmpeg-git/ffmpeg/tests/ref/fate/dsf-dst  2018-12-22 
09:03:30.765501114 +0100
+++ tests/data/fate/dsf-dst 2018-12-22 09:42:30.905550414 +0100
@@ -4,13 +4,13 @@
 #sample_rate 0: 352800
 #channel_layout 0: 3
 #channel_layout_name 0: stereo
-0,  0,  0, 4704,18816, 0x16bbebad
-0,   4704,   4704, 4704,18816, 0x025d9312
+0,  0,  0, 4704,18816, 0xbce6ebab
+0,   4704,   4704, 4704,18816, 0x05da930e
 0,   9408,   9408, 4704,18816, 0xa8a84a1d
 0,  14112,  14112, 4704,18816, 0x44a24932
 0,  18816,  18816, 4704,18816, 0xb60580ae
 0,  23520,  23520, 4704,18816, 0xa23751ff
-0,  28224,  28224, 4704,18816, 0xcaee4a16
+0,  28224,  28224, 4704,18816, 0xcc6c4a18
 0,  32928,  32928, 4704,18816, 0xc19adb0e
-0,  37632,  37632, 4704,18816, 0xb7adec72
+0,  37632,  37632, 4704,18816, 0x4341ec6e
 0,  42336,  42336, 4704,18816, 0x6a7f3268
Test dsf-dst failed. Look at tests/data/fate/dsf-dst.err for details.
make: *** [fate-dsf-dst] Error 1

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add photocd decoder

[Paul B Mahol]

On 12/21/18, Steinar H. Gunderson  wrote:
> On Fri, Dec 21, 2018 at 05:07:45PM +0100, Paul B Mahol wrote:
>> The colors that PhotoCD uses predates color space definitions.
>
> Really? It looks fairly well-defined to me, though esoteric
> (the gamma ramp is basically like sRGB but with a much bigger constant,
> and the 8-bit Y'CbCr scaling seems unusual):
>
>   https://en.wikipedia.org/wiki/Photo_CD#Encoding
>
> FFmpeg doesn't have a good understanding of gamma (it rarely actually
> converts between different gamma ramps), but that's not a problem with
> PhotoCD per se. I can't find a good reason why FFmpeg could not be
> extended with conversions from the PhotoCD color space to sRGB, at least
> not if clipping out-of-gamut colors is acceptable.

I'm all ears.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/hlsenc: free varstreams after write all varstreams info

[Steven Liu]

fix ticket: 7631

Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 50 +-
 1 file changed, 33 insertions(+), 17 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index bdd2a113bd..e3cd6f375a 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2360,6 +2360,37 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 return ret;
 }
 
+static void hls_varstreams_free(struct AVFormatContext *s)
+{
+int i = 0;
+HLSContext *hls = s->priv_data;
+AVFormatContext *vtt_oc = NULL;
+VariantStream *vs = NULL;
+
+for (i = 0; i < hls->nb_varstreams; i++) {
+vs = &hls->var_streams[i];
+vtt_oc = vs->vtt_avf;
+
+av_freep(&vs->basename);
+av_freep(&vs->base_output_dirname);
+av_freep(&vs->fmp4_init_filename);
+if (vtt_oc) {
+av_freep(&vs->vtt_basename);
+av_freep(&vs->vtt_m3u8_name);
+avformat_free_context(vtt_oc);
+}
+
+hls_free_segments(vs->segments);
+hls_free_segments(vs->old_segments);
+av_freep(&vs->m3u8_name);
+av_freep(&vs->streams);
+av_freep(&vs->agroup);
+av_freep(&vs->ccgroup);
+av_freep(&vs->baseurl);
+}
+
+
+}
 static int hls_write_trailer(struct AVFormatContext *s)
 {
 HLSContext *hls = s->priv_data;
@@ -2451,30 +2482,15 @@ failed:
 vs->size = avio_tell(vs->vtt_avf->pb) - vs->start_pos;
 ff_format_io_close(s, &vtt_oc->pb);
 }
-av_freep(&vs->basename);
-av_freep(&vs->base_output_dirname);
 avformat_free_context(oc);
 
 vs->avf = NULL;
 hls_window(s, 1, vs);
-
-av_freep(&vs->fmp4_init_filename);
-if (vtt_oc) {
-av_freep(&vs->vtt_basename);
-av_freep(&vs->vtt_m3u8_name);
-avformat_free_context(vtt_oc);
-}
-
-hls_free_segments(vs->segments);
-hls_free_segments(vs->old_segments);
 av_free(old_filename);
-av_freep(&vs->m3u8_name);
-av_freep(&vs->streams);
-av_freep(&vs->agroup);
-av_freep(&vs->ccgroup);
-av_freep(&vs->baseurl);
 }
 
+hls_varstreams_free(s);
+
 for (i = 0; i < hls->nb_ccstreams; i++) {
 ClosedCaptionsStream *ccs = &hls->cc_streams[i];
 av_freep(&ccs->ccgroup);
-- 
2.15.1



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] avformat: add vividas demuxer

[Paul B Mahol]

On 12/22/18, Carl Eugen Hoyos  wrote:
> 2018-12-20 19:33 GMT+01:00, Paul B Mahol :
>> ffmpeg | branch: master | Paul B Mahol  | Mon Dec 10
>> 12:15:50 2018 +0100| [d06aae732c16bd4c490c6dfa35cc2a35129c640f] |
>> committer:
>> Paul B Mahol
>>
>> avformat: add vividas demuxer
>
> Crashes here on stream-copying a sample from
> http://samples.ffmpeg.org/archive/container/unknown/
>
> $ valgrind ffmpeg_g -i
> unknown+unknown+unknown+unknown+5064_cliplive5-16_2_644.viv -c copy -f
> null -
> ==23818==
> ffmpeg version N-92766-g6a87729 Copyright (c) 2000-2018 the FFmpeg
> developers
>   built with gcc 6.4.0 (GCC)
>   configuration: --enable-gpl --enable-libxml2 --enable-gnutls
> --enable-gmp --enable-version3 --enable-libx264
>   libavutil  56. 25.100 / 56. 25.100
>   libavcodec 58. 42.104 / 58. 42.104
>   libavformat58. 25.100 / 58. 25.100
>   libavdevice58.  6.101 / 58.  6.101
>   libavfilter 7. 46.101 /  7. 46.101
>   libswscale  5.  4.100 /  5.  4.100
>   libswresample   3.  4.100 /  3.  4.100
>   libpostproc55.  4.100 / 55.  4.100
> Input #0, vividas, from
> 'unknown+unknown+unknown+unknown+5064_cliplive5-16_2_644.viv':
>   Duration: N/A, start: 0.00, bitrate: N/A
> Stream #0:0: Video: vp6, yuv420p, 432x320, 25 tbr, 25 tbn, 25 tbc
> Stream #0:1: Audio: vorbis, 44100 Hz, stereo, fltp
> Output #0, null, to 'pipe:':
>   Metadata:
> encoder : Lavf58.25.100
> Stream #0:0: Video: vp6, yuv420p, 432x320, q=2-31, 25 tbr, 25 tbn, 25
> tbc
> Stream #0:1: Audio: vorbis, 44100 Hz, stereo, fltp
> Stream mapping:
>   Stream #0:0 -> #0:0 (copy)
>   Stream #0:1 -> #0:1 (copy)
> Press [q] to stop, [?] for help
> ==23818== Invalid read of size 8=N/A time=00:06:00.63 bitrate=N/A speed=
> 103x
> ==23818==at 0x6766CA: ffio_read_varlen (aviobuf.c:930)
> ==23818==by 0x79F932: viv_read_packet (vividas.c:621)
> ==23818==by 0x790A6D: ff_read_packet (utils.c:856)
> ==23818==by 0x793ED3: read_frame_internal (utils.c:1582)
> ==23818==by 0x795021: av_read_frame (utils.c:1779)
> ==23818==by 0x4A8C07: transcode (ffmpeg.c:4147)
> ==23818==by 0x486F82: main (ffmpeg.c:4891)
> ==23818==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
> ==23818==
> ==23818==
> ==23818== Process terminating with default action of signal 11 (SIGSEGV)

Can not reproduce.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH V5 0/2] Add libsvt HEVC encoder wrapper

[Jun Zhao]

The Scalable Video Technology for HEVC Encoder (SVT-HEVC Encoder) is an 
HEVC-compliant encoder library core that achieves excellent density-quality 
tradeoffs, and is highly optimized for Intel Xeon Scalable Processor and 
Xeon D processors. Intel open source SVT-HEVC encoder in: 
https://github.com/intel/SVT-HEVC.

This wrapper work with SVT-HEVC master branch, more information can get 
from https://github.com/intel/SVT-HEVC/blob/new_api/ffmpeg_plugin/.

For SVT-HEVC build, you can switch the branch to master, then run:

1. mkdir build && cd build && cmake ../ && make -j `nproc` && sudo make install
 
in the directory. (Yes, SVT-HEVC now support the full CMake style's 
build/install 
after the commit 
https://github.com/intel/SVT-HEVC/commit/f28d492971ef58dc655ccdc7d819cc18ddb45a2f)

For FFmpeg build. need to:
1. export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/lib and
   export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}:/usr/local/lib/pkgconfig before
   enable SVT-HEVC in FFmpeg.
2. in FFmpeg part, need to "--enable-libsvthevc" options in config step.

This patches based on Zhengxu, huang/hassene's hard work.

SVT-HEVC encoder have some interesting features compare with the exsting HEVC 
encoder.

- Multidimensional parallelism
a). Picture-based parallelism
b). Segment-based parallelism (scales over many CPU cores)
c). Will support tile-based parallelism soon

- Human Visual System(HVS)-optimized classification for
a). Data-efficient processsing
b). Computationally efficient partitioning and mode decision
c). Higher coding efficiency
 
- Resource adaptive scalability
a). Speed up factor vs HM 16 about 70 times (4K/60fps content, 
SVT-HEVC enable subjective quality mode with preset setting 
with M0(highest quality))
b). Outperformance the x265 encoder in CQP mode 

Some performance data:
- Real-time encoding of up to 1x 8Kp60/10-bit streams on the 
  Platinum 8180 with preset M11/subjective quality mode

- Real-time encoding of up to 2x 8Kp50/10-bit streams on the 
  Platinum 8180 with preset M12/subjective quality mode

- Real-time encoding of up to 4x 4Kp60/10-bit streams on the 
  Gold 6148 with preset M12/subjective quality mode

- Real-time encoding of up to 6x 4Kp60/10-bit streams on the 
   Platinum 8180 with preset M12/subjective quality mode

More performance/quality data will be public as a white paper as soon 
after the internal review finished.

V5: - Change the config options (didn't need to enable-gpl for BSD+Patent,
  it's can compatible with LGPL2+, thanks Xavier correct this part),
  now just need to "--enable-libsvthevc" option.
- Refine the code as the FFmpeg community's comments
  (https://patchwork.ffmpeg.org/patch/11347/, Tks Mark great review)
- Add force_idr option.
- Update the docs part as current implement (Tks Gyan review the docs part) 


V4: - Add more options support and update related docs (profile/aud/tile/...)
- Rebase the docs in general.texi based on Gyan's review
- Refine the encoder.texi part as Gyan's suggestion

V3: - Merge Changelog patch to new wrapper(Tks Moritz/Carl's review)

V2: - Refine the error handle (Tks Steven/James's review).
- Add docs part (Tks Steven/Moritz's review).
- Use named parameters in options.
- Follow FFmpeg coding style and Changelog.

V1: - Add libsvt hevc encoder wrapper and a Changelog entry.

Jun Zhao (2):
  lavc/svt_hevc: add libsvt hevc encoder wrapper.
  doc: Add libsvt_hevc encoder docs

 Changelog|1 +
 configure|4 +
 doc/encoders.texi|  145 +
 doc/general.texi |   15 ++
 libavcodec/Makefile  |1 +
 libavcodec/allcodecs.c   |1 +
 libavcodec/libsvt_hevc.c |  526 ++
 7 files changed, 693 insertions(+), 0 deletions(-)
 create mode 100644 libavcodec/libsvt_hevc.c

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH V5 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper.

[Jun Zhao]

base on patch by Huang, Zhengxu from https://github.com/intel/SVT-HEVC

Signed-off-by: Huang, Zhengxu 
Signed-off-by: hassene 
Signed-off-by: Jun Zhao 
---
 Changelog|1 +
 configure|4 +
 libavcodec/Makefile  |1 +
 libavcodec/allcodecs.c   |1 +
 libavcodec/libsvt_hevc.c |  526 ++
 5 files changed, 533 insertions(+), 0 deletions(-)
 create mode 100644 libavcodec/libsvt_hevc.c

diff --git a/Changelog b/Changelog
index 4945efb..12a9266 100644
--- a/Changelog
+++ b/Changelog
@@ -12,6 +12,7 @@ version :
 - PCM-DVD encoder
 - GIF parser
 - vividas demuxer
+- add SVT(Scalable Video Technology) HEVC encoder
 
 
 version 4.1:
diff --git a/configure b/configure
index 2205751..5e14df9 100755
--- a/configure
+++ b/configure
@@ -263,6 +263,7 @@ External library support:
   --enable-libspeexenable Speex de/encoding via libspeex [no]
   --enable-libsrt  enable Haivision SRT protocol via libsrt [no]
   --enable-libssh  enable SFTP protocol via libssh [no]
+  --enable-libsvthevc  enable HEVC encoding via svt [no]
   --enable-libtensorflow   enable TensorFlow as a DNN module backend
for DNN based filters like sr [no]
   --enable-libtesseractenable Tesseract, needed for ocr filter [no]
@@ -1745,6 +1746,7 @@ EXTERNAL_LIBRARY_LIST="
 libspeex
 libsrt
 libssh
+libsvthevc
 libtensorflow
 libtesseract
 libtheora
@@ -3131,6 +3133,7 @@ libshine_encoder_select="audio_frame_queue"
 libspeex_decoder_deps="libspeex"
 libspeex_encoder_deps="libspeex"
 libspeex_encoder_select="audio_frame_queue"
+libsvt_hevc_encoder_deps="libsvthevc"
 libtheora_encoder_deps="libtheora"
 libtwolame_encoder_deps="libtwolame"
 libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
@@ -6154,6 +6157,7 @@ enabled libsoxr   && require libsoxr soxr.h 
soxr_create -lsoxr
 enabled libssh&& require_pkg_config libssh libssh libssh/sftp.h 
sftp_init
 enabled libspeex  && require_pkg_config libspeex speex speex/speex.h 
speex_decoder_init
 enabled libsrt&& require_pkg_config libsrt "srt >= 1.3.0" 
srt/srt.h srt_socket
+enabled libsvthevc&& require_pkg_config libsvthevc SvtHevcEnc EbApi.h 
EbInitHandle
 enabled libtensorflow && require libtensorflow tensorflow/c/c_api.h 
TF_Version -ltensorflow
 enabled libtesseract  && require_pkg_config libtesseract tesseract 
tesseract/capi.h TessBaseAPICreate
 enabled libtheora && require libtheora theora/theoraenc.h th_info_init 
-ltheoraenc -ltheoradec -logg
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index d53b8ff..bd46866 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -983,6 +983,7 @@ OBJS-$(CONFIG_LIBOPUS_ENCODER)+= libopusenc.o 
libopus.o \
 OBJS-$(CONFIG_LIBSHINE_ENCODER)   += libshine.o
 OBJS-$(CONFIG_LIBSPEEX_DECODER)   += libspeexdec.o
 OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
+OBJS-$(CONFIG_LIBSVT_HEVC_ENCODER)+= libsvt_hevc.o
 OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
 OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
 OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) += libvo-amrwbenc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index d70646e..094ee3c 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -699,6 +699,7 @@ extern AVCodec ff_librsvg_decoder;
 extern AVCodec ff_libshine_encoder;
 extern AVCodec ff_libspeex_encoder;
 extern AVCodec ff_libspeex_decoder;
+extern AVCodec ff_libsvt_hevc_encoder;
 extern AVCodec ff_libtheora_encoder;
 extern AVCodec ff_libtwolame_encoder;
 extern AVCodec ff_libvo_amrwbenc_encoder;
diff --git a/libavcodec/libsvt_hevc.c b/libavcodec/libsvt_hevc.c
new file mode 100644
index 000..42720c0
--- /dev/null
+++ b/libavcodec/libsvt_hevc.c
@@ -0,0 +1,526 @@
+/*
+* Scalable Video Technology for HEVC encoder library plugin
+*
+* Copyright (c) 2018 Intel Corporation
+*
+* This file is part of FFmpeg.
+*
+* FFmpeg is free software; you can redistribute it and/or
+* modify it under the terms of the GNU Lesser General Public
+* License as published by the Free Software Foundation; either
+* version 2.1 of the License, or (at your option) any later version.
+*
+* FFmpeg is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+* Lesser General Public License for more details.
+*
+* You should have received a copy of the GNU Lesser General Public
+* License along with this program; if not, write to the Free Software
+* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+*/
+
+#include "EbErrorCodes.h"
+#include "EbTime.h"
+#include "EbApi.h"
+
+#include "libavutil/common.h"
+#include "libavutil/frame.h"
+#include "libavutil/opt.h"
+
+#include "internal.h"
+#include "avcodec.h"
+

[FFmpeg-devel] [PATCH V5 2/2] doc: Add libsvt_hevc encoder docs

[Jun Zhao]

Add docs for libsvt_hevc encoder in encoders.texi and general.texi

Signed-off-by: Jun Zhao 
Signed-off-by: Huang, Zhengxu 
Signed-off-by: hassene 
---
 doc/encoders.texi |  145 +
 doc/general.texi  |   15 ++
 2 files changed, 160 insertions(+), 0 deletions(-)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 3d5b9fc..8f3db53 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1569,6 +1569,151 @@ Set maximum NAL size in bytes.
 Allow skipping frames to hit the target bitrate if set to 1.
 @end table
 
+@section libsvt_hevc
+
+Intel Scalable Video Technology HEVC encoder wrapper.
+
+This encoder requires the presence of the headers and
+library during configuration. You need to explicitly configure the
+build with @code{--enable-libsvthevc}. The library is detected using
+@command{pkg-config}.
+
+For more information about the library see
+@url{https://github.com/intel/SVT-HEVC.git}.
+
+@subsection Options
+
+The following FFmpeg global options affect the configurations of the
+libsvt_hevc encoder.
+
+@table @option
+@item b  (@emph{bitrate})
+Set the bitrate (as a number of bits per second). Default is 7M.
+
+@item g  / @option{gop_size}
+Set the GOP size..
+
+@item flags +cgop
+Enable closed GOP.
+
+@item qmin (@emph{min-q})
+Defaults 10
+
+@item qmax (@emph{max-q})
+Defaults 48
+
+Set minimum/maximum quantisation values.  Valid range is from 0 to 51
+(Only used when bit rate control mode @option{rc} is set to 0(cqp) mode.
+Has to be qmax > = qmin).
+
+@item profile (@emph{profile})
+Set profile restrictions. Can assume one of the following possible values:
+
+Default is 2 (main10).
+
+@table @samp
+@item main
+main profile
+@item main10
+main10 profile
+@end table
+
+@item level
+
+@option{profile} sets the value of @emph{profile_idc} and the 
@emph{constraint_set*_flag}s.
+@option{level} sets the value of @emph{level_idc}.
+
+@end table
+
+The encoder also has its own specific options:
+
+@table @option
+@item vui
+Enables or disables the vui structure in the HEVC elementary
+bitstream. 0 = Off, 1 = On. Default is 1 (On).
+
+@item aud (@emph{aud})
+Enable use of access unit delimiters when set to 1. Default is 0 (Off).
+
+@item hielevel
+Set hierarchical prediction levels. Can assume one of the following possible 
values:
+
+Default is 4 (4level).
+
+@table @samp
+@item flat
+none hierarchy level
+@item 2level
+2-level hierarchy
+@item 3level
+3-level hierarchy
+@item 4level
+4-level hierarchy
+@end table
+
+@item la_depth
+Set look-ahead depth, depending on bit rate control mode @option{rc}, when
+bit rate control mode is set to vbr it's best to set this parameter to be
+equal to the intra period value (such is the default set by the encoder),
+when cqp is chosen, then a look ahead is recommended. The range is from 
@var{0-256}.
+
+@item preset
+A preset defining the quality vs density tradeoff point that the
+encoding is to be performed at.(e.g. 0 is the highest quality mode,
+12 is the highest density mode). The range is from @var{0-12}. Default is 9.
+
+@item tier
+Set @emph{general_tier_flag}.  This may affect the level chosen for the stream
+if it is not explicitly specified. Can assume one of the following possible 
values:
+
+Default is 1 (main).
+
+@table @samp
+@item main
+main tier
+@item high
+high tier
+@end table
+
+@item rc
+Set bit rate control mode. Can assume one of the following possible values:
+
+Default is 0 (cqp).
+
+@table @samp
+@item cqp
+Constant QP (CQP) mode
+@item vbr
+Variable Bit Rate (VBR) mode
+@end table
+
+@item qp
+Initial quantization parameter for the intra pictures used when
+@option{rc} is cqp mode. The range is from @var{0-51}. Default is 32.
+
+@item sc_detection
+Enables or disables the scene change detection algorithm. Default is 0 
(disable).
+
+@item tune
+Set quality tuning mode. Can assume one of the following possible values:
+
+Default is 1 (objective).
+
+@table @samp
+@item subjective
+Subjective quality mode
+@item objective
+Objective quality mode for PSNR / SSIM benchmarking
+@end table
+
+@item bl_mode
+Enables or disables Random Access Prediction. Default is 0 (disable).
+
+@item forced-idr
+Normally, when forcing a I-frame type, the encoder can select any type
+of I-frame. This option forces it to choose an IDR-frame.
+@end table
+
 @section libtheora
 
 libtheora Theora encoder wrapper.
diff --git a/doc/general.texi b/doc/general.texi
index 2bc33d1..c2f29d5 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -126,6 +126,21 @@ The dispatcher is open source and can be downloaded from
 with the @code{--enable-libmfx} option and @code{pkg-config} needs to be able 
to
 locate the dispatcher's @code{.pc} files.
 
+@section Intel SVT-HEVC
+
+FFmpeg can make use of the SVT-HEVC library for HEVC encoding.
+
+Go to @url{https://github.com/intel/SVT-HEVC.git} and follow the instructions
+for installing the library. Then pass @code{--enable-libsvthevc} to configure 
to
+enable it.
+

Re: [FFmpeg-devel] [FFmpeg-cvslog] avformat: add vividas demuxer

[Carl Eugen Hoyos]

2018-12-22 10:06 GMT+01:00, Paul B Mahol :
> On 12/22/18, Carl Eugen Hoyos  wrote:
>> 2018-12-20 19:33 GMT+01:00, Paul B Mahol :
>>> ffmpeg | branch: master | Paul B Mahol  | Mon Dec 10
>>> 12:15:50 2018 +0100| [d06aae732c16bd4c490c6dfa35cc2a35129c640f] |
>>> committer:
>>> Paul B Mahol
>>>
>>> avformat: add vividas demuxer
>>
>> Crashes here on stream-copying a sample from
>> http://samples.ffmpeg.org/archive/container/unknown/
>>
>> $ valgrind ffmpeg_g -i
>> unknown+unknown+unknown+unknown+5064_cliplive5-16_2_644.viv -c copy -f
>> null -
>> ==23818==
>> ffmpeg version N-92766-g6a87729 Copyright (c) 2000-2018 the FFmpeg
>> developers
>>   built with gcc 6.4.0 (GCC)
>>   configuration: --enable-gpl --enable-libxml2 --enable-gnutls
>> --enable-gmp --enable-version3 --enable-libx264
>>   libavutil  56. 25.100 / 56. 25.100
>>   libavcodec 58. 42.104 / 58. 42.104
>>   libavformat58. 25.100 / 58. 25.100
>>   libavdevice58.  6.101 / 58.  6.101
>>   libavfilter 7. 46.101 /  7. 46.101
>>   libswscale  5.  4.100 /  5.  4.100
>>   libswresample   3.  4.100 /  3.  4.100
>>   libpostproc55.  4.100 / 55.  4.100
>> Input #0, vividas, from
>> 'unknown+unknown+unknown+unknown+5064_cliplive5-16_2_644.viv':
>>   Duration: N/A, start: 0.00, bitrate: N/A
>> Stream #0:0: Video: vp6, yuv420p, 432x320, 25 tbr, 25 tbn, 25 tbc
>> Stream #0:1: Audio: vorbis, 44100 Hz, stereo, fltp
>> Output #0, null, to 'pipe:':
>>   Metadata:
>> encoder : Lavf58.25.100
>> Stream #0:0: Video: vp6, yuv420p, 432x320, q=2-31, 25 tbr, 25 tbn, 25
>> tbc
>> Stream #0:1: Audio: vorbis, 44100 Hz, stereo, fltp
>> Stream mapping:
>>   Stream #0:0 -> #0:0 (copy)
>>   Stream #0:1 -> #0:1 (copy)
>> Press [q] to stop, [?] for help
>> ==23818== Invalid read of size 8=N/A time=00:06:00.63 bitrate=N/A speed=
>> 103x
>> ==23818==at 0x6766CA: ffio_read_varlen (aviobuf.c:930)
>> ==23818==by 0x79F932: viv_read_packet (vividas.c:621)
>> ==23818==by 0x790A6D: ff_read_packet (utils.c:856)
>> ==23818==by 0x793ED3: read_frame_internal (utils.c:1582)
>> ==23818==by 0x795021: av_read_frame (utils.c:1779)
>> ==23818==by 0x4A8C07: transcode (ffmpeg.c:4147)
>> ==23818==by 0x486F82: main (ffmpeg.c:4891)
>> ==23818==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
>> ==23818==
>> ==23818==
>> ==23818== Process terminating with default action of signal 11 (SIGSEGV)
>
> Can not reproduce.

Still reproducible with e9909fe1 here, also reproducible with
different compiler.

$ md5sum unknown+unknown+unknown+unknown+5064_cliplive5-16_2_644.viv
cd6466d1c8260ed200d73af2ba000d44
unknown+unknown+unknown+unknown+5064_cliplive5-16_2_644.viv
$ valgrind ffmpeg_g -i
unknown+unknown+unknown+unknown+5064_cliplive5-16_2_644.viv -c copy -f
null -
==3362== Memcheck, a memory error detector
==3362== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==3362== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==3362== Command: ffmpeg_g -i
unknown+unknown+unknown+unknown+5064_cliplive5-16_2_644.viv -c copy -f
null -
==3362==
ffmpeg version N-92770-ge9909fe Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 6.4.0 (GCC)
  configuration: --enable-gpl --enable-libxml2 --enable-gnutls
--enable-gmp --enable-version3 --enable-libx264
  libavutil  56. 25.100 / 56. 25.100
  libavcodec 58. 42.104 / 58. 42.104
  libavformat58. 25.100 / 58. 25.100
  libavdevice58.  6.101 / 58.  6.101
  libavfilter 7. 46.101 /  7. 46.101
  libswscale  5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
  libpostproc55.  4.100 / 55.  4.100
Input #0, vividas, from
'unknown+unknown+unknown+unknown+5064_cliplive5-16_2_644.viv':
  Duration: N/A, start: 0.00, bitrate: N/A
Stream #0:0: Video: vp6, yuv420p, 432x320, 25 tbr, 25 tbn, 25 tbc
Stream #0:1: Audio: vorbis, 44100 Hz, stereo, fltp
Output #0, null, to 'pipe:':
  Metadata:
encoder : Lavf58.25.100
Stream #0:0: Video: vp6, yuv420p, 432x320, q=2-31, 25 tbr, 25 tbn, 25 tbc
Stream #0:1: Audio: vorbis, 44100 Hz, stereo, fltp
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
==3362== Invalid read of size 8
==3362==at 0x6766CA: ffio_read_varlen (aviobuf.c:930)
==3362==by 0x79F932: viv_read_packet (vividas.c:622)
==3362==by 0x790A6D: ff_read_packet (utils.c:856)
==3362==by 0x793ED3: read_frame_internal (utils.c:1582)
==3362==by 0x795021: av_read_frame (utils.c:1779)
==3362==by 0x4A8C07: transcode (ffmpeg.c:4147)
==3362==by 0x486F82: main (ffmpeg.c:4891)
==3362==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
==3362==
==3362==
==3362== Process terminating with default action of signal 11 (SIGSEGV)
==3362==  Access not within mapped region at address 0x18
==3362==at 0x6766CA: ffio_read_varlen (aviobuf.c:930)
==3362==by 0x79F932: viv_read_packet (vividas.c:622)
==3362==by 0x790A6D: 

Re: [FFmpeg-devel] [PATCH V5 0/2] Add libsvt HEVC encoder wrapper

[Carl Eugen Hoyos]

2018-12-22 10:15 GMT+01:00, Jun Zhao :
> The Scalable Video Technology for HEVC Encoder (SVT-HEVC Encoder) is an

> HEVC-compliant encoder library core that achieves excellent density-quality

I don't find it ideal that FFmpeg git claims that an Intel encoder
does something "excellent" - unrelated to our actual opinion.
Please rephrase.

> tradeoffs, and is highly optimized for Intel Xeon Scalable Processor and

(and while there, also remove / change "highly optimized")

> Xeon D processors. Intel open source SVT-HEVC encoder in:
> https://github.com/intel/SVT-HEVC.

> This wrapper work with SVT-HEVC master branch, more information can get
> from https://github.com/intel/SVT-HEVC/blob/new_api/ffmpeg_plugin/.

This is irrelevant:
If SVT is another example of a library that does not plan some kind
of api stability, we should not merge your patch.
If api stability is to be expected, the sentence is not necessary.

> For SVT-HEVC build, you can switch the branch to master, then run:

This should not be part of the commit message here.

[...]

Please either:
Add some quality metrics in the email.
Or:
Explain that the license (and the fact that the encoder is not terrible)
is sufficient reason to merge.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] zmbvenc: don't sum the entropy when blocks are equal

[Tomas Härdin]

tor 2018-12-20 klockan 17:46 + skrev Matthew Fearnley:
> > On Thu, 20 Dec 2018 at 16:30, Tomas Härdin  wrote:
> 
> > I have a feeling this could be sped up further by just doing *xored =
> > histogram[0] == ZMBV_BLOCK*ZMBV_BLOCK after the loops, if [PATCH 3/4]
> > is applied before this. Computing both histogram and xored in the loop
> > seems pointless.
> > 
> 
> You're right, that speedup didn't occur to me.  It makes the logic a bit
> more tenuous, but it would be more efficient.

Eh, I wouldn't really call "we have xored data to output if and only if
number of zeroes < number of pixel" fairly easy to grasp. A comment
might be good tho

> Note that bw,bh aren't guaranteed to equal ZMBV_BLOCK, so `histogram[0] ==
> bw*bh` would have to be used to guard against those (literal) edge cases.

Right, yes. But if we have block sizes other than ZMBV_BLOCK^2 then we
need score tables for those sizes too.

/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] zmbvenc: use unsigned values for score calculations

[Tomas Härdin]

tor 2018-12-20 klockan 17:48 + skrev Matthew Fearnley:
> > On Thu, 20 Dec 2018 at 16:30, Tomas Härdin  wrote:
> 
> > Trivial enough. You could probably roll many or even all of these
> > patches together
> > 
> 
> Thanks for your feedback.  I was reluctant to submit so many patches, but I
> worried at the time that combining them would require an overly long commit
> message.  Maybe I'm being too verbose though...
> What's the best way to submit a combined patch - from a Patchwork/mailing
> list perspective?

How large a patch should be is somewhat arbitrary. I tend to try to
keep each patch related to a single "concept". And of course separating
 cosmetic and functional changes

It's mostly the having to have PATCH 3/4 before PATCH 1/4 prompting
this suggestion. Or maybe rolling them together

The primary reason for making nice patches it for making runs of git-
bisect easier

/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/hlsenc: fix broken -hls_flags +temp_file

[Ronak Patel]

> On Dec 16, 2018, at 10:31 PM, Steven Liu  wrote:
> 
> Aleksey Skripka  于2018年12月14日周五 下午10:58写道：
>> 
>> 
>> From e85edcc4d8b0312c7871f78ed0859ec7436be460 Mon Sep 17 00:00:00 2001
>> From: Aleksey Skripka 
>> Date: Fri, 14 Dec 2018 14:48:31 +
>> Subject: [PATCH] libavformat/hlsenc: fix broken -hls_flags +temp_file
>> 
>> 1. fix addressing '->flags' while assigning 'use_temp_file'.
>> 2. before 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6 playlist file was always 
>> created via .tmp for 'file' proto, now not. keep old behavior.
>> 3. rename logic in hls_write_packet() incorrectly placed (in fMP4-only 
>> code), thus not renaming files for mpegts.
>> 4. needless av_free() call.

Hi Aleksey,

Just wanted to make sure this wouldn’t affect standard VOD use cases running on 
a file on disk. We have some really gigantic audio files and we can’t sustain 
fragmentation times over a few minutes. Taking a week to fragment something is 
not acceptable.

I hope we don’t make temp files in those cases. Did you test that on the 
command line?

Ronak



>> ---
>> libavformat/hlsenc.c | 23 +++
>> 1 file changed, 7 insertions(+), 16 deletions(-)
>> 
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index bdd2a11..70eee19 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -1358,7 +1358,7 @@ static int hls_window(AVFormatContext *s, int last, 
>> VariantStream *vs)
>> char temp_filename[1024];
>> int64_t sequence = FFMAX(hls->start_sequence, vs->sequence - 
>> vs->nb_entries);
>> const char *proto = avio_find_protocol_name(s->url);
>> -int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & 
>> HLS_TEMP_FILE);
>> +int use_temp_file = proto && !strcmp(proto, "file");
>> static unsigned warned_non_file;
>> char *key_uri = NULL;
>> char *iv_string = NULL;
>> @@ -1478,7 +1478,7 @@ static int hls_start(AVFormatContext *s, VariantStream 
>> *vs)
>> AVFormatContext *vtt_oc = vs->vtt_avf;
>> AVDictionary *options = NULL;
>> const char *proto = avio_find_protocol_name(s->url);
>> -int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & 
>> HLS_TEMP_FILE);
>> +int use_temp_file = proto && !strcmp(proto, "file") && (c->flags & 
>> HLS_TEMP_FILE);
>> char *filename, iv_string[KEYSIZE*2 + 1];
>> int err = 0;
>> 
>> @@ -2143,7 +2143,7 @@ static int hls_write_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>> int stream_index = 0;
>> int range_length = 0;
>> const char *proto = avio_find_protocol_name(s->url);
>> -int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & 
>> HLS_TEMP_FILE);
>> +int use_temp_file = proto && !strcmp(proto, "file") && (hls->flags & 
>> HLS_TEMP_FILE);
>> uint8_t *buffer = NULL;
>> VariantStream *vs = NULL;
>> AVDictionary *options = NULL;
>> @@ -2266,7 +2266,6 @@ static int hls_write_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>> if (hls->flags & HLS_SINGLE_FILE) {
>> ret = flush_dynbuf(vs, &range_length);
>> if (ret < 0) {
>> -av_free(old_filename);
>> return ret;
>> }
>> vs->size = range_length;
>> @@ -2284,20 +2283,12 @@ static int hls_write_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>> return ret;
>> }
>> ff_format_io_close(s, &vs->out);
>> -
>> -// rename that segment from .tmp to the real one
>> -if (use_temp_file && oc->url[0]) {
>> -hls_rename_temp_file(s, oc);
>> -av_free(old_filename);
>> -old_filename = av_strdup(vs->avf->url);
>> -
>> -if (!old_filename) {
>> -return AVERROR(ENOMEM);
>> -}
>> -}
>> }
>> }
>> 
>> +if (use_temp_file && oc->url[0] && !(hls->flags & HLS_SINGLE_FILE))
>> +hls_rename_temp_file(s, oc);
>> +
>> old_filename = av_strdup(vs->avf->url);
>> if (!old_filename) {
>> return AVERROR(ENOMEM);
>> @@ -2367,7 +2358,7 @@ static int hls_write_trailer(struct AVFormatContext *s)
>> AVFormatContext *vtt_oc = NULL;
>> char *old_filename = NULL;
>> const char *proto = avio_find_protocol_name(s->url);
>> -int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & 
>> HLS_TEMP_FILE);
>> +int use_temp_file = proto && !strcmp(proto, "file") && (hls->flags & 
>> HLS_TEMP_FILE);
>> int i;
>> int ret = 0;
>> VariantStream *vs = NULL;
>> --
>> 1.8.3.1
>> 
>> --
>> Aleksey Skripka
>> 
>> 
>> 
>>> On 14 Dec 2018, at 17:21, Steven Liu  wrote:
>>> 
>>> 
>>> 
> On Dec 14, 2018, at 19:23, Aleksey Skripka  wrote:
> 
> 
> On 14 Dec 2018, at 13:10, Liu Steven  wrote:
> 
> 
> 
>> 在 2018年12月14日，下午5:27，Aleksey Skripka  写道：
>> 
>> greetings!
>> 
>>>

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: free varstreams after write all varstreams info

[Jan Ekström]

On Sat, Dec 22, 2018 at 10:55 AM Steven Liu  wrote:
>
> fix ticket: 7631
>
> Signed-off-by: Steven Liu 
> ---
>  libavformat/hlsenc.c | 50 +-
>  1 file changed, 33 insertions(+), 17 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index bdd2a113bd..e3cd6f375a 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2360,6 +2360,37 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  return ret;
>  }
>
> +static void hls_varstreams_free(struct AVFormatContext *s)
> +{

I think you only use the AVFormatContext to get the HLSContext, and
you already have that pointer in hls_write_trailer.

Thus I think you could just make this function take in a HLSContext *hls.

Also the function could be something like "hls_free_variant_streams",
but this is just an opinion.

> +int i = 0;
> +HLSContext *hls = s->priv_data;
> +AVFormatContext *vtt_oc = NULL;
> +VariantStream *vs = NULL;
> +
> +for (i = 0; i < hls->nb_varstreams; i++) {

As far as I asked on IRC, we're OK with declaring iterators in a for
loop, so it can be "int i = 0;"

> +vs = &hls->var_streams[i];
> +vtt_oc = vs->vtt_avf;
> +

Also asked if things utilized within a for loop can have their own
variables declared at the top of the loop.
Thus the AVFormatContext and VariantStream can be declared here.

> +av_freep(&vs->basename);
> +av_freep(&vs->base_output_dirname);
> +av_freep(&vs->fmp4_init_filename);
> +if (vtt_oc) {
> +av_freep(&vs->vtt_basename);
> +av_freep(&vs->vtt_m3u8_name);
> +avformat_free_context(vtt_oc);
> +}
> +
> +hls_free_segments(vs->segments);
> +hls_free_segments(vs->old_segments);
> +av_freep(&vs->m3u8_name);
> +av_freep(&vs->streams);
> +av_freep(&vs->agroup);
> +av_freep(&vs->ccgroup);
> +av_freep(&vs->baseurl);

I also wonder if you should separate actual per-variant stream freeing
into its own function which takes a VariantStream *vs in?

> +}
> +
> +
> +}

Leave one empty line after the function, and no need for empty lines
at the end of the function inside of it.

F.ex.
{
for (...) {
}
}

following_function {
...

>  static int hls_write_trailer(struct AVFormatContext *s)
>  {
>  HLSContext *hls = s->priv_data;
> @@ -2451,30 +2482,15 @@ failed:
>  vs->size = avio_tell(vs->vtt_avf->pb) - vs->start_pos;
>  ff_format_io_close(s, &vtt_oc->pb);
>  }
> -av_freep(&vs->basename);
> -av_freep(&vs->base_output_dirname);
>  avformat_free_context(oc);
>
>  vs->avf = NULL;
>  hls_window(s, 1, vs);
> -
> -av_freep(&vs->fmp4_init_filename);
> -if (vtt_oc) {
> -av_freep(&vs->vtt_basename);
> -av_freep(&vs->vtt_m3u8_name);
> -avformat_free_context(vtt_oc);
> -}
> -
> -hls_free_segments(vs->segments);
> -hls_free_segments(vs->old_segments);
>  av_free(old_filename);
> -av_freep(&vs->m3u8_name);
> -av_freep(&vs->streams);
> -av_freep(&vs->agroup);
> -av_freep(&vs->ccgroup);
> -av_freep(&vs->baseurl);
>  }
>
> +hls_varstreams_free(s);
> +
>  for (i = 0; i < hls->nb_ccstreams; i++) {
>  ClosedCaptionsStream *ccs = &hls->cc_streams[i];
>  av_freep(&ccs->ccgroup);
> --
> 2.15.1
>

Initial quick look.

Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avformat/hls.c: Fix memory leak

[Valery Kot]

Ping...
Any maintainer willing to review/push straightforward one-liner patch?

> Thus 59MB leak in an hour! And keeps growing...

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: free varstreams after write all varstreams info

[Steven Liu]

> On Dec 22, 2018, at 22:26, Jan Ekström  wrote:
> 
> On Sat, Dec 22, 2018 at 10:55 AM Steven Liu  wrote:
>> 
>> fix ticket: 7631
>> 
>> Signed-off-by: Steven Liu 
>> ---
>> libavformat/hlsenc.c | 50 +-
>> 1 file changed, 33 insertions(+), 17 deletions(-)
>> 
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index bdd2a113bd..e3cd6f375a 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -2360,6 +2360,37 @@ static int hls_write_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>> return ret;
>> }
>> 
>> +static void hls_varstreams_free(struct AVFormatContext *s)
>> +{
> 
> I think you only use the AVFormatContext to get the HLSContext, and
> you already have that pointer in hls_write_trailer.
> 
> Thus I think you could just make this function take in a HLSContext *hls.
Okay.
> 
> Also the function could be something like "hls_free_variant_streams",
> but this is just an opinion.
good opinion.
> 
>> +int i = 0;
>> +HLSContext *hls = s->priv_data;
>> +AVFormatContext *vtt_oc = NULL;
>> +VariantStream *vs = NULL;
>> +
>> +for (i = 0; i < hls->nb_varstreams; i++) {
> 
> As far as I asked on IRC, we're OK with declaring iterators in a for
> loop, so it can be "int i = 0;”
I think the better declared the i at the start block of this function.
> 
>> +vs = &hls->var_streams[i];
>> +vtt_oc = vs->vtt_avf;
>> +
> 
> Also asked if things utilized within a for loop can have their own
> variables declared at the top of the loop.
> Thus the AVFormatContext and VariantStream can be declared here.
> 
>> +av_freep(&vs->basename);
>> +av_freep(&vs->base_output_dirname);
>> +av_freep(&vs->fmp4_init_filename);
>> +if (vtt_oc) {
>> +av_freep(&vs->vtt_basename);
>> +av_freep(&vs->vtt_m3u8_name);
>> +avformat_free_context(vtt_oc);
>> +}
>> +
>> +hls_free_segments(vs->segments);
>> +hls_free_segments(vs->old_segments);
>> +av_freep(&vs->m3u8_name);
>> +av_freep(&vs->streams);
>> +av_freep(&vs->agroup);
>> +av_freep(&vs->ccgroup);
>> +av_freep(&vs->baseurl);
> 
> I also wonder if you should separate actual per-variant stream freeing
> into its own function which takes a VariantStream *vs in?
Okay,
> 
>> +}
>> +
>> +
>> +}
> 
> Leave one empty line after the function, and no need for empty lines
> at the end of the function inside of it.
> 
> F.ex.
> {
>for (...) {
>}
> }
> 
> following_function {
>...
> 
>> static int hls_write_trailer(struct AVFormatContext *s)
>> {
>> HLSContext *hls = s->priv_data;
>> @@ -2451,30 +2482,15 @@ failed:
>> vs->size = avio_tell(vs->vtt_avf->pb) - vs->start_pos;
>> ff_format_io_close(s, &vtt_oc->pb);
>> }
>> -av_freep(&vs->basename);
>> -av_freep(&vs->base_output_dirname);
>> avformat_free_context(oc);
>> 
>> vs->avf = NULL;
>> hls_window(s, 1, vs);
>> -
>> -av_freep(&vs->fmp4_init_filename);
>> -if (vtt_oc) {
>> -av_freep(&vs->vtt_basename);
>> -av_freep(&vs->vtt_m3u8_name);
>> -avformat_free_context(vtt_oc);
>> -}
>> -
>> -hls_free_segments(vs->segments);
>> -hls_free_segments(vs->old_segments);
>> av_free(old_filename);
>> -av_freep(&vs->m3u8_name);
>> -av_freep(&vs->streams);
>> -av_freep(&vs->agroup);
>> -av_freep(&vs->ccgroup);
>> -av_freep(&vs->baseurl);
>> }
>> 
>> +hls_varstreams_free(s);
>> +
>> for (i = 0; i < hls->nb_ccstreams; i++) {
>> ClosedCaptionsStream *ccs = &hls->cc_streams[i];
>> av_freep(&ccs->ccgroup);
>> --
>> 2.15.1
>> 
> 
> Initial quick look.

New patch will come.

> 
> Jan
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks
Steven





___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: free varstreams after write all varstreams info

[Steven Liu]

> On Dec 22, 2018, at 23:02, Steven Liu  wrote:
> 
> 
> 
>> On Dec 22, 2018, at 22:26, Jan Ekström  wrote:
>> 
>> On Sat, Dec 22, 2018 at 10:55 AM Steven Liu  wrote:
>>> 
>>> fix ticket: 7631
>>> 
>>> Signed-off-by: Steven Liu 
>>> ---
>>> libavformat/hlsenc.c | 50 +-
>>> 1 file changed, 33 insertions(+), 17 deletions(-)
>>> 
>>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>>> index bdd2a113bd..e3cd6f375a 100644
>>> --- a/libavformat/hlsenc.c
>>> +++ b/libavformat/hlsenc.c
>>> @@ -2360,6 +2360,37 @@ static int hls_write_packet(AVFormatContext *s, 
>>> AVPacket *pkt)
>>>return ret;
>>> }
>>> 
>>> +static void hls_varstreams_free(struct AVFormatContext *s)
>>> +{
>> 
>> I think you only use the AVFormatContext to get the HLSContext, and
>> you already have that pointer in hls_write_trailer.
>> 
>> Thus I think you could just make this function take in a HLSContext *hls.
> Okay.
>> 
>> Also the function could be something like "hls_free_variant_streams",
>> but this is just an opinion.
> good opinion.
>> 
>>> +int i = 0;
>>> +HLSContext *hls = s->priv_data;
>>> +AVFormatContext *vtt_oc = NULL;
>>> +VariantStream *vs = NULL;
>>> +
>>> +for (i = 0; i < hls->nb_varstreams; i++) {
>> 
>> As far as I asked on IRC, we're OK with declaring iterators in a for
>> loop, so it can be "int i = 0;”
> I think the better declared the i at the start block of this function.
>> 
>>> +vs = &hls->var_streams[i];
>>> +vtt_oc = vs->vtt_avf;
>>> +
>> 
>> Also asked if things utilized within a for loop can have their own
>> variables declared at the top of the loop.
>> Thus the AVFormatContext and VariantStream can be declared here.
>> 
>>> +av_freep(&vs->basename);
>>> +av_freep(&vs->base_output_dirname);
>>> +av_freep(&vs->fmp4_init_filename);
>>> +if (vtt_oc) {
>>> +av_freep(&vs->vtt_basename);
>>> +av_freep(&vs->vtt_m3u8_name);
>>> +avformat_free_context(vtt_oc);
>>> +}
>>> +
>>> +hls_free_segments(vs->segments);
>>> +hls_free_segments(vs->old_segments);
>>> +av_freep(&vs->m3u8_name);
>>> +av_freep(&vs->streams);
>>> +av_freep(&vs->agroup);
>>> +av_freep(&vs->ccgroup);
>>> +av_freep(&vs->baseurl);
>> 
>> I also wonder if you should separate actual per-variant stream freeing
>> into its own function which takes a VariantStream *vs in?
> Okay,
Ah, sorry, my mistake, i think this takes a HLSContext is better than 
VariantStream, move the for loop into the function,
That should better than call function in loop, because call function will push 
stack, and out function will pop stack,
So 
void function {
for (i = 0; i < n; i++);
}
is better than
for (i = 0; i< n; i++) {
function();
}
the VariantStream is member in the HLSContext.
>> 
>>> +}
>>> +
>>> +
>>> +}
>> 
>> Leave one empty line after the function, and no need for empty lines
>> at the end of the function inside of it.
>> 
>> F.ex.
>> {
>>   for (...) {
>>   }
>> }
>> 
>> following_function {
>>   ...
>> 
>>> static int hls_write_trailer(struct AVFormatContext *s)
>>> {
>>>HLSContext *hls = s->priv_data;
>>> @@ -2451,30 +2482,15 @@ failed:
>>>vs->size = avio_tell(vs->vtt_avf->pb) - vs->start_pos;
>>>ff_format_io_close(s, &vtt_oc->pb);
>>>}
>>> -av_freep(&vs->basename);
>>> -av_freep(&vs->base_output_dirname);
>>>avformat_free_context(oc);
>>> 
>>>vs->avf = NULL;
>>>hls_window(s, 1, vs);
>>> -
>>> -av_freep(&vs->fmp4_init_filename);
>>> -if (vtt_oc) {
>>> -av_freep(&vs->vtt_basename);
>>> -av_freep(&vs->vtt_m3u8_name);
>>> -avformat_free_context(vtt_oc);
>>> -}
>>> -
>>> -hls_free_segments(vs->segments);
>>> -hls_free_segments(vs->old_segments);
>>>av_free(old_filename);
>>> -av_freep(&vs->m3u8_name);
>>> -av_freep(&vs->streams);
>>> -av_freep(&vs->agroup);
>>> -av_freep(&vs->ccgroup);
>>> -av_freep(&vs->baseurl);
>>>}
>>> 
>>> +hls_varstreams_free(s);
>>> +
>>>for (i = 0; i < hls->nb_ccstreams; i++) {
>>>ClosedCaptionsStream *ccs = &hls->cc_streams[i];
>>>av_freep(&ccs->ccgroup);
>>> --
>>> 2.15.1
>>> 
>> 
>> Initial quick look.
> 
> New patch will come.
> 
>> 
>> Jan
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> Thanks
> Steven

Thanks
Steven





___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] zmbvenc: don't sum the entropy when blocks are equal

[Matthew Fearnley]

> On 22 Dec 2018, at 12:11, Tomas Härdin  wrote:
> 
> tor 2018-12-20 klockan 17:46 + skrev Matthew Fearnley:
 On Thu, 20 Dec 2018 at 16:30, Tomas Härdin  wrote:
>>> 
>>> I have a feeling this could be sped up further by just doing *xored =
>>> histogram[0] == ZMBV_BLOCK*ZMBV_BLOCK after the loops, if [PATCH 3/4]
>>> is applied before this. Computing both histogram and xored in the loop
>>> seems pointless.
>>> 
>> 
>> You're right, that speedup didn't occur to me.  It makes the logic a bit
>> more tenuous, but it would be more efficient.
> 
> Eh, I wouldn't really call "we have xored data to output if and only if
> number of zeroes < number of pixel" fairly easy to grasp. A comment
> might be good tho
Agreed.
Just have to get the patch order sorted out now somehow.
>> Note that bw,bh aren't guaranteed to equal ZMBV_BLOCK, so `histogram[0] ==
>> bw*bh` would have to be used to guard against those (literal) edge cases.
> 
> Right, yes. But if we have block sizes other than ZMBV_BLOCK^2 then we
> need score tables for those sizes too.
I’ve thought about that a bit. I wondered if it would be worth it given:
- the extra code, memory and logic needed
- it would only improve the edge blocks
- the existing score table isn’t catastrophically bad for short blocks, and 
would still favour blocks with more common pixels.

It would be better from a correctness perspective though, and effects on 
running time should be negligible.

I can work on a patch, see how it looks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2] avformat/hlsenc: free variant streams after write all variant streams info

[Steven Liu]

fix ticket: 7631

Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 48 +++-
 1 file changed, 31 insertions(+), 17 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index bdd2a113bd..d96b9eb179 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2360,6 +2360,34 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 return ret;
 }
 
+static void hls_free_variant_streams(struct HLSContext *hls)
+{
+int i = 0;
+AVFormatContext *vtt_oc = NULL;
+VariantStream *vs = NULL;
+
+for (i = 0; i < hls->nb_varstreams; i++) {
+vs = &hls->var_streams[i];
+vtt_oc = vs->vtt_avf;
+
+av_freep(&vs->basename);
+av_freep(&vs->base_output_dirname);
+av_freep(&vs->fmp4_init_filename);
+if (vtt_oc) {
+av_freep(&vs->vtt_basename);
+av_freep(&vs->vtt_m3u8_name);
+}
+
+hls_free_segments(vs->segments);
+hls_free_segments(vs->old_segments);
+av_freep(&vs->m3u8_name);
+av_freep(&vs->streams);
+av_freep(&vs->agroup);
+av_freep(&vs->ccgroup);
+av_freep(&vs->baseurl);
+}
+}
+
 static int hls_write_trailer(struct AVFormatContext *s)
 {
 HLSContext *hls = s->priv_data;
@@ -2450,31 +2478,17 @@ failed:
 av_write_trailer(vtt_oc);
 vs->size = avio_tell(vs->vtt_avf->pb) - vs->start_pos;
 ff_format_io_close(s, &vtt_oc->pb);
+avformat_free_context(vtt_oc);
 }
-av_freep(&vs->basename);
-av_freep(&vs->base_output_dirname);
 avformat_free_context(oc);
 
 vs->avf = NULL;
 hls_window(s, 1, vs);
-
-av_freep(&vs->fmp4_init_filename);
-if (vtt_oc) {
-av_freep(&vs->vtt_basename);
-av_freep(&vs->vtt_m3u8_name);
-avformat_free_context(vtt_oc);
-}
-
-hls_free_segments(vs->segments);
-hls_free_segments(vs->old_segments);
 av_free(old_filename);
-av_freep(&vs->m3u8_name);
-av_freep(&vs->streams);
-av_freep(&vs->agroup);
-av_freep(&vs->ccgroup);
-av_freep(&vs->baseurl);
 }
 
+hls_free_variant_streams(hls);
+
 for (i = 0; i < hls->nb_ccstreams; i++) {
 ClosedCaptionsStream *ccs = &hls->cc_streams[i];
 av_freep(&ccs->ccgroup);
-- 
2.15.1



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] zmbvenc: Prevent memory/math overflows in block_cmp()

[Matthew Fearnley]

> On 20 Dec 2018, at 16:30, Tomas Härdin  wrote:
> 
> ons 2018-12-19 klockan 22:00 + skrev matthew.w.fearn...@gmail.com:
>>> From: Matthew Fearnley 
>> 
>> score_tab[] was only declared/initialised for elements 0..255, but with
>> block sizes set to 16*16, it was possible to reach 256.
>> 
>> This limit could also be overflowed in the histogram, because it was
>> declared with a uint8_t type.
>> 
>> This can be fixed, and also allow different ZMBV_BLOCK sizes, by making
>> score_tab[] with (ZMBV_BLOCK*ZMBV_BLOCK+1) elements, and declaring
>> histogram[] to use a uint16_t type.
>> 
>> Note: the maximum block size possible for PAL8 is 255*255 bytes, which is 
>> close
>> to the uint16_t limit.  To support full-colour pixel formats, a uint32_t 
>> could
>> potentially be required.
> 
> So a potential future encoder improvement would be to try different
> block sizes? Could be a fun project for someone, like a GSoC
> qualification task

Yeah. The header allows for block dimensions up to 255, and the width and 
height can be different from each other.

They can technically be changed in each keyframe header, but I’ve not tested 
how the decoder handles that..

>> @@ -69,7 +69,7 @@ static inline int block_cmp(ZmbvEncContext *c, uint8_t 
>> *src, int stride,
>>  {
>>  int sum = 0;
>>  int i, j;
>> -uint8_t histogram[256] = {0};
>> +uint16_t histogram[256] = {0};
>>  
>>  /* build frequency histogram of byte values for src[] ^ src2[] */
>>  *xored = 0;
>> @@ -285,7 +285,9 @@ static av_cold int encode_init(AVCodecContext *avctx)
>>  int i;
>>  int lvl = 9;
>>  
>> -for(i=1; i<256; i++)
>> +/* entropy score table for block_cmp() */
>> +c->score_tab[0] = 0;
>> +for(i = 1; i <= ZMBV_BLOCK * ZMBV_BLOCK; i++)
>>  c->score_tab[i] = -i * log2(i / (double)(ZMBV_BLOCK * ZMBV_BLOCK)) 
>> * 256;
> 
> It strikes me that due to the uint8_t overflow the old code actually
> worked correctly, but only incidentally..

It’s almost ingenious, the way it manages that. I almost didn’t want to change 
it..

> Looks good!

Thanks :)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] avformat/mxfdec: fix error check in macro

[Michael Niedermayer]

On Sat, Dec 15, 2018 at 10:18:18AM +0100, Hendrik Leppkes wrote:
> On Sat, Dec 15, 2018 at 9:50 AM Paul B Mahol  wrote:
> >
> > On 12/15/18, James Almer  wrote:
> > >> ffmpeg | branch: master | Paul B Mahol  > >> > | Thu Dec 13 23:51:02
> > >> 2018 +0100| [e5a0013c4a6248fe7e2a651db1fda6b9bb2cd743] | committer: Paul 
> > >> B
> > >> Mahol
> > >>
> > >> avformat/mxfdec: fix error check in macro
> > >>
> > >> Fixes #6750.
> > >>
> > >> >/http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=e5a0013c4a6248fe7e2a651db1fda6b9bb2cd743
> > >> /---
> > >>
> > >>  libavformat/mxfdec.c | 2 +-
> > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > >> index 887645d28b..f5e3a736e5 100644
> > >> --- a/libavformat/mxfdec.c
> > >> +++ b/libavformat/mxfdec.c
> > >> @@ -2590,7 +2590,7 @@ static int64_t mxf_timestamp_to_int64(uint64_t
> > >> timestamp)
> > >>
> > >>  #define SET_TS_METADATA(pb, name, var, str) do { \
> > >>  var = avio_rb64(pb); \
> > >> -if ((ret = avpriv_dict_set_timestamp(&s->metadata, name,
> > >> mxf_timestamp_to_int64(var)) < 0)) \
> > >> +if ((ret = avpriv_dict_set_timestamp(&s->metadata, name,
> > >> mxf_timestamp_to_int64(var))) < 0) \
> > >>  return ret; \
> > >>  } while (0)
> > >
> > > This broke several mxf tests.
> > >
> > > copy-trac4914
> > > lavf-mxf
> > > lavf-mxf_d10
> > > lavf-mxf_dv25
> > > lavf-mxf_dvcpro50
> > > lavf-mxf_opatom
> > > lavf-mxf_opatom_audio
> >
> > Can not reproduce. Is this MSVS only thing?
> 
> Its not MSVS, but apparently Windows. I wonder if either gmtime_r or

this reproduces on mingw64+wine too btw

@@ -1,49 +1,2 @@
 b37c4d5693cdb5b9ed9b33501ffb682a *tests/data/fate/copy-trac4914.mxf
 561721 tests/data/fate/copy-trac4914.mxf
-#tb 0: 1001/3
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 480x270
-#sar 0: 1/1
-#tb 1: 1/48000
-#media_type 1: audio
-#codec_id 1: pcm_s16le
-#sample_rate 1: 48000
-#channel_layout 1: 3
-#channel_layout_name 1: stereo
-0,  0,  0,1,   259200, 0xf36957da
-1,  0,  0, 1602, 6408, 0x1dd7b37c
-0,  1,  1,1,   259200, 0x29a1f586
-1,   1602,   1602, 1601, 6404, 0xb6854846
-1,   3203,   3203, 1602, 6408, 0x4d3ea85e
-0,  2,  2,1,   259200, 0x5578d9c3
-0,  3,  3,1,   259200, 0x83938b61
-1,   4805,   4805, 1601, 6404, 0x5eb15a6d
-1,   6406,   6406, 1602, 6408, 0x059d21a0
-0,  4,  4,1,   259200, 0xa6ce7618
-0,  5,  5,1,   259200, 0x4892a0f5
-1,   8008,   8008, 1602, 6408, 0xd8352572
-0,  6,  6,1,   259200, 0x921c6051
-1,   9610,   9610, 1601, 6404, 0xf69be875
-1,  11211,  11211, 1602, 6408, 0x41e75601
-0,  7,  7,1,   259200, 0x618c0026
-0,  8,  8,1,   259200, 0xdbc3ca4d
-1,  12813,  12813, 1601, 6404, 0x75e3196d
-1,  14414,  14414, 1602, 6408, 0xb46bad29
-0,  9,  9,1,   259200, 0xf088c731
-0, 10, 10,1,   259200, 0xce77ddee
-1,  16016,  16016, 1602, 6408, 0x41e6ceac
-0, 11, 11,1,   259200, 0x798565eb
-1,  17618,  17618, 1601, 6404, 0x2258734e
-1,  19219,  19219, 1602, 6408, 0xc46d9103
-0, 12, 12,1,   259200, 0x57185dc8
-0, 13, 13,1,   259200, 0x607a9086
-1,  20821,  20821, 1601, 6404, 0xd7c07892
-1,  22422,  22422, 1602, 6408, 0x2aaad91d
-0, 14, 14,1,   259200, 0x59bd5c34
-0, 15, 15,1,   259200, 0xadb1da77
-1,  24024,  24024, 1602, 6408, 0x69bfb643
-0, 16, 16,1,   259200, 0x1f7d7b14
-1,  25626,  25626, 1601, 6404, 0x0e644904
-1,  27227,  27227, 1602, 6408, 0x06e92ea2
-0, 17, 17,1,   259200, 0xcdd45467
Test copy-trac4914 failed. Look at tests/data/fate/copy-trac4914.err for 
details.

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] zmbvenc: use unsigned values for score calculations

[Matthew Fearnley]

> On 22 Dec 2018, at 12:15, Tomas Härdin  wrote:
> 
> tor 2018-12-20 klockan 17:48 + skrev Matthew Fearnley:
> On Thu, 20 Dec 2018 at 16:30, Tomas Härdin  wrote:
>>> 
>>> Trivial enough. You could probably roll many or even all of these
>>> patches together
>> 
>> Thanks for your feedback.  I was reluctant to submit so many patches, but I
>> worried at the time that combining them would require an overly long commit
>> message.  Maybe I'm being too verbose though...
>> What's the best way to submit a combined patch - from a Patchwork/mailing
>> list perspective?
> 
> How large a patch should be is somewhat arbitrary. I tend to try to
> keep each patch related to a single "concept". And of course separating
> cosmetic and functional changes
> 
> It's mostly the having to have PATCH 3/4 before PATCH 1/4 prompting
> this suggestion. Or maybe rolling them together

If I roll the patches together (and include the additional suggestions in PATCH 
1), would it be best to just email a new patch, and have these closed?

Still struggling with general procedure here a bit...
Thanks for bearing with me.

Matthew
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] avformat/mxfdec: fix error check in macro

[Paul B Mahol]

On 12/22/18, Michael Niedermayer  wrote:
> On Sat, Dec 15, 2018 at 10:18:18AM +0100, Hendrik Leppkes wrote:
>> On Sat, Dec 15, 2018 at 9:50 AM Paul B Mahol  wrote:
>> >
>> > On 12/15/18, James Almer  wrote:
>> > >> ffmpeg | branch: master | Paul B Mahol > > >> > | Thu Dec 13
>> > >> 23:51:02
>> > >> 2018 +0100| [e5a0013c4a6248fe7e2a651db1fda6b9bb2cd743] | committer:
>> > >> Paul B
>> > >> Mahol
>> > >>
>> > >> avformat/mxfdec: fix error check in macro
>> > >>
>> > >> Fixes #6750.
>> > >>
>> > >> >/http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=e5a0013c4a6248fe7e2a651db1fda6b9bb2cd743
>> > >> /---
>> > >>
>> > >>  libavformat/mxfdec.c | 2 +-
>> > >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> > >>
>> > >> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
>> > >> index 887645d28b..f5e3a736e5 100644
>> > >> --- a/libavformat/mxfdec.c
>> > >> +++ b/libavformat/mxfdec.c
>> > >> @@ -2590,7 +2590,7 @@ static int64_t mxf_timestamp_to_int64(uint64_t
>> > >> timestamp)
>> > >>
>> > >>  #define SET_TS_METADATA(pb, name, var, str) do { \
>> > >>  var = avio_rb64(pb); \
>> > >> -if ((ret = avpriv_dict_set_timestamp(&s->metadata, name,
>> > >> mxf_timestamp_to_int64(var)) < 0)) \
>> > >> +if ((ret = avpriv_dict_set_timestamp(&s->metadata, name,
>> > >> mxf_timestamp_to_int64(var))) < 0) \
>> > >>  return ret; \
>> > >>  } while (0)
>> > >
>> > > This broke several mxf tests.
>> > >
>> > > copy-trac4914
>> > > lavf-mxf
>> > > lavf-mxf_d10
>> > > lavf-mxf_dv25
>> > > lavf-mxf_dvcpro50
>> > > lavf-mxf_opatom
>> > > lavf-mxf_opatom_audio
>> >
>> > Can not reproduce. Is this MSVS only thing?
>>
>> Its not MSVS, but apparently Windows. I wonder if either gmtime_r or
>
> this reproduces on mingw64+wine too btw
>
> @@ -1,49 +1,2 @@
>  b37c4d5693cdb5b9ed9b33501ffb682a *tests/data/fate/copy-trac4914.mxf
>  561721 tests/data/fate/copy-trac4914.mxf
> -#tb 0: 1001/3
> -#media_type 0: video
> -#codec_id 0: rawvideo
> -#dimensions 0: 480x270
> -#sar 0: 1/1
> -#tb 1: 1/48000
> -#media_type 1: audio
> -#codec_id 1: pcm_s16le
> -#sample_rate 1: 48000
> -#channel_layout 1: 3
> -#channel_layout_name 1: stereo
> -0,  0,  0,1,   259200, 0xf36957da
> -1,  0,  0, 1602, 6408, 0x1dd7b37c
> -0,  1,  1,1,   259200, 0x29a1f586
> -1,   1602,   1602, 1601, 6404, 0xb6854846
> -1,   3203,   3203, 1602, 6408, 0x4d3ea85e
> -0,  2,  2,1,   259200, 0x5578d9c3
> -0,  3,  3,1,   259200, 0x83938b61
> -1,   4805,   4805, 1601, 6404, 0x5eb15a6d
> -1,   6406,   6406, 1602, 6408, 0x059d21a0
> -0,  4,  4,1,   259200, 0xa6ce7618
> -0,  5,  5,1,   259200, 0x4892a0f5
> -1,   8008,   8008, 1602, 6408, 0xd8352572
> -0,  6,  6,1,   259200, 0x921c6051
> -1,   9610,   9610, 1601, 6404, 0xf69be875
> -1,  11211,  11211, 1602, 6408, 0x41e75601
> -0,  7,  7,1,   259200, 0x618c0026
> -0,  8,  8,1,   259200, 0xdbc3ca4d
> -1,  12813,  12813, 1601, 6404, 0x75e3196d
> -1,  14414,  14414, 1602, 6408, 0xb46bad29
> -0,  9,  9,1,   259200, 0xf088c731
> -0, 10, 10,1,   259200, 0xce77ddee
> -1,  16016,  16016, 1602, 6408, 0x41e6ceac
> -0, 11, 11,1,   259200, 0x798565eb
> -1,  17618,  17618, 1601, 6404, 0x2258734e
> -1,  19219,  19219, 1602, 6408, 0xc46d9103
> -0, 12, 12,1,   259200, 0x57185dc8
> -0, 13, 13,1,   259200, 0x607a9086
> -1,  20821,  20821, 1601, 6404, 0xd7c07892
> -1,  22422,  22422, 1602, 6408, 0x2aaad91d
> -0, 14, 14,1,   259200, 0x59bd5c34
> -0, 15, 15,1,   259200, 0xadb1da77
> -1,  24024,  24024, 1602, 6408, 0x69bfb643
> -0, 16, 16,1,   259200, 0x1f7d7b14
> -1,  25626,  25626, 1601, 6404, 0x0e644904
> -1,  27227,  27227, 1602, 6408, 0x06e92ea2
> -0, 17, 17,1,   259200, 0xcdd45467
> Test copy-trac4914 failed. Look at tests/data/fate/copy-trac4914.err for
> details.
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Democracy is the form of government in which you can choose your dictator
>

I do not have windows to fix unrelated bug that previous code keep
hidden, and I'm not paid to fix this mess.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] avformat/mxfdec: fix error check in macro

[James Almer]

On 12/22/2018 12:50 PM, Michael Niedermayer wrote:
> On Sat, Dec 15, 2018 at 10:18:18AM +0100, Hendrik Leppkes wrote:
>> On Sat, Dec 15, 2018 at 9:50 AM Paul B Mahol  wrote:
>>>
>>> On 12/15/18, James Almer  wrote:
> ffmpeg | branch: master | Paul B Mahol  > | Thu Dec 13 23:51:02
> 2018 +0100| [e5a0013c4a6248fe7e2a651db1fda6b9bb2cd743] | committer: Paul B
> Mahol
>
> avformat/mxfdec: fix error check in macro
>
> Fixes #6750.
>
>> /http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=e5a0013c4a6248fe7e2a651db1fda6b9bb2cd743
> /---
>
>  libavformat/mxfdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index 887645d28b..f5e3a736e5 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -2590,7 +2590,7 @@ static int64_t mxf_timestamp_to_int64(uint64_t
> timestamp)
>
>  #define SET_TS_METADATA(pb, name, var, str) do { \
>  var = avio_rb64(pb); \
> -if ((ret = avpriv_dict_set_timestamp(&s->metadata, name,
> mxf_timestamp_to_int64(var)) < 0)) \
> +if ((ret = avpriv_dict_set_timestamp(&s->metadata, name,
> mxf_timestamp_to_int64(var))) < 0) \
>  return ret; \
>  } while (0)

 This broke several mxf tests.

 copy-trac4914
 lavf-mxf
 lavf-mxf_d10
 lavf-mxf_dv25
 lavf-mxf_dvcpro50
 lavf-mxf_opatom
 lavf-mxf_opatom_audio
>>>
>>> Can not reproduce. Is this MSVS only thing?
>>
>> Its not MSVS, but apparently Windows. I wonder if either gmtime_r or
> 
> this reproduces on mingw64+wine too btw
> 
> @@ -1,49 +1,2 @@
>  b37c4d5693cdb5b9ed9b33501ffb682a *tests/data/fate/copy-trac4914.mxf
>  561721 tests/data/fate/copy-trac4914.mxf
> -#tb 0: 1001/3
> -#media_type 0: video
> -#codec_id 0: rawvideo
> -#dimensions 0: 480x270
> -#sar 0: 1/1
> -#tb 1: 1/48000
> -#media_type 1: audio
> -#codec_id 1: pcm_s16le
> -#sample_rate 1: 48000
> -#channel_layout 1: 3
> -#channel_layout_name 1: stereo
> -0,  0,  0,1,   259200, 0xf36957da
> -1,  0,  0, 1602, 6408, 0x1dd7b37c
> -0,  1,  1,1,   259200, 0x29a1f586
> -1,   1602,   1602, 1601, 6404, 0xb6854846
> -1,   3203,   3203, 1602, 6408, 0x4d3ea85e
> -0,  2,  2,1,   259200, 0x5578d9c3
> -0,  3,  3,1,   259200, 0x83938b61
> -1,   4805,   4805, 1601, 6404, 0x5eb15a6d
> -1,   6406,   6406, 1602, 6408, 0x059d21a0
> -0,  4,  4,1,   259200, 0xa6ce7618
> -0,  5,  5,1,   259200, 0x4892a0f5
> -1,   8008,   8008, 1602, 6408, 0xd8352572
> -0,  6,  6,1,   259200, 0x921c6051
> -1,   9610,   9610, 1601, 6404, 0xf69be875
> -1,  11211,  11211, 1602, 6408, 0x41e75601
> -0,  7,  7,1,   259200, 0x618c0026
> -0,  8,  8,1,   259200, 0xdbc3ca4d
> -1,  12813,  12813, 1601, 6404, 0x75e3196d
> -1,  14414,  14414, 1602, 6408, 0xb46bad29
> -0,  9,  9,1,   259200, 0xf088c731
> -0, 10, 10,1,   259200, 0xce77ddee
> -1,  16016,  16016, 1602, 6408, 0x41e6ceac
> -0, 11, 11,1,   259200, 0x798565eb
> -1,  17618,  17618, 1601, 6404, 0x2258734e
> -1,  19219,  19219, 1602, 6408, 0xc46d9103
> -0, 12, 12,1,   259200, 0x57185dc8
> -0, 13, 13,1,   259200, 0x607a9086
> -1,  20821,  20821, 1601, 6404, 0xd7c07892
> -1,  22422,  22422, 1602, 6408, 0x2aaad91d
> -0, 14, 14,1,   259200, 0x59bd5c34
> -0, 15, 15,1,   259200, 0xadb1da77
> -1,  24024,  24024, 1602, 6408, 0x69bfb643
> -0, 16, 16,1,   259200, 0x1f7d7b14
> -1,  25626,  25626, 1601, 6404, 0x0e644904
> -1,  27227,  27227, 1602, 6408, 0x06e92ea2
> -0, 17, 17,1,   259200, 0xcdd45467
> Test copy-trac4914 failed. Look at tests/data/fate/copy-trac4914.err for 
> details.

As i said gmtime_r() is what's failing, and it's used by both the muxer
and demuxer. Only Cygwin seems to work, probably because it uses its own
C libraries.

If the code can't be simplified to remove the gmtime_r() usage, then
both modules should perhaps just skip writing/reading the modification
date metadata tag. And for that matter, shouldn't such tag be written or
not depending on the bitexact flag?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] avformat/mxfdec: fix error check in macro

[Michael Niedermayer]

On Sat, Dec 22, 2018 at 01:02:17PM -0300, James Almer wrote:
> On 12/22/2018 12:50 PM, Michael Niedermayer wrote:
> > On Sat, Dec 15, 2018 at 10:18:18AM +0100, Hendrik Leppkes wrote:
> >> On Sat, Dec 15, 2018 at 9:50 AM Paul B Mahol  wrote:
> >>>
> >>> On 12/15/18, James Almer  wrote:
> > ffmpeg | branch: master | Paul B Mahol  > > | Thu Dec 13 
> > 23:51:02
> > 2018 +0100| [e5a0013c4a6248fe7e2a651db1fda6b9bb2cd743] | committer: 
> > Paul B
> > Mahol
> >
> > avformat/mxfdec: fix error check in macro
> >
> > Fixes #6750.
> >
> >> /http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=e5a0013c4a6248fe7e2a651db1fda6b9bb2cd743
> > /---
> >
> >  libavformat/mxfdec.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index 887645d28b..f5e3a736e5 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -2590,7 +2590,7 @@ static int64_t mxf_timestamp_to_int64(uint64_t
> > timestamp)
> >
> >  #define SET_TS_METADATA(pb, name, var, str) do { \
> >  var = avio_rb64(pb); \
> > -if ((ret = avpriv_dict_set_timestamp(&s->metadata, name,
> > mxf_timestamp_to_int64(var)) < 0)) \
> > +if ((ret = avpriv_dict_set_timestamp(&s->metadata, name,
> > mxf_timestamp_to_int64(var))) < 0) \
> >  return ret; \
> >  } while (0)
> 
>  This broke several mxf tests.
> 
>  copy-trac4914
>  lavf-mxf
>  lavf-mxf_d10
>  lavf-mxf_dv25
>  lavf-mxf_dvcpro50
>  lavf-mxf_opatom
>  lavf-mxf_opatom_audio
> >>>
> >>> Can not reproduce. Is this MSVS only thing?
> >>
> >> Its not MSVS, but apparently Windows. I wonder if either gmtime_r or
> > 
> > this reproduces on mingw64+wine too btw
> > 
> > @@ -1,49 +1,2 @@
> >  b37c4d5693cdb5b9ed9b33501ffb682a *tests/data/fate/copy-trac4914.mxf
> >  561721 tests/data/fate/copy-trac4914.mxf
> > -#tb 0: 1001/3
> > -#media_type 0: video
> > -#codec_id 0: rawvideo
> > -#dimensions 0: 480x270
> > -#sar 0: 1/1
> > -#tb 1: 1/48000
> > -#media_type 1: audio
> > -#codec_id 1: pcm_s16le
> > -#sample_rate 1: 48000
> > -#channel_layout 1: 3
> > -#channel_layout_name 1: stereo
> > -0,  0,  0,1,   259200, 0xf36957da
> > -1,  0,  0, 1602, 6408, 0x1dd7b37c
> > -0,  1,  1,1,   259200, 0x29a1f586
> > -1,   1602,   1602, 1601, 6404, 0xb6854846
> > -1,   3203,   3203, 1602, 6408, 0x4d3ea85e
> > -0,  2,  2,1,   259200, 0x5578d9c3
> > -0,  3,  3,1,   259200, 0x83938b61
> > -1,   4805,   4805, 1601, 6404, 0x5eb15a6d
> > -1,   6406,   6406, 1602, 6408, 0x059d21a0
> > -0,  4,  4,1,   259200, 0xa6ce7618
> > -0,  5,  5,1,   259200, 0x4892a0f5
> > -1,   8008,   8008, 1602, 6408, 0xd8352572
> > -0,  6,  6,1,   259200, 0x921c6051
> > -1,   9610,   9610, 1601, 6404, 0xf69be875
> > -1,  11211,  11211, 1602, 6408, 0x41e75601
> > -0,  7,  7,1,   259200, 0x618c0026
> > -0,  8,  8,1,   259200, 0xdbc3ca4d
> > -1,  12813,  12813, 1601, 6404, 0x75e3196d
> > -1,  14414,  14414, 1602, 6408, 0xb46bad29
> > -0,  9,  9,1,   259200, 0xf088c731
> > -0, 10, 10,1,   259200, 0xce77ddee
> > -1,  16016,  16016, 1602, 6408, 0x41e6ceac
> > -0, 11, 11,1,   259200, 0x798565eb
> > -1,  17618,  17618, 1601, 6404, 0x2258734e
> > -1,  19219,  19219, 1602, 6408, 0xc46d9103
> > -0, 12, 12,1,   259200, 0x57185dc8
> > -0, 13, 13,1,   259200, 0x607a9086
> > -1,  20821,  20821, 1601, 6404, 0xd7c07892
> > -1,  22422,  22422, 1602, 6408, 0x2aaad91d
> > -0, 14, 14,1,   259200, 0x59bd5c34
> > -0, 15, 15,1,   259200, 0xadb1da77
> > -1,  24024,  24024, 1602, 6408, 0x69bfb643
> > -0, 16, 16,1,   259200, 0x1f7d7b14
> > -1,  25626,  25626, 1601, 6404, 0x0e644904
> > -1,  27227,  27227, 1602, 6408, 0x06e92ea2
> > -0, 17, 17,1,   259200, 0xcdd45467
> > Test copy-trac4914 failed. Look at tests/data/fate/copy-trac4914.err for 
> > details.
> 
> As i said gmtime_r() is what's failing, and it's used by both the muxer
> and demuxer. Only Cygwin seems to work, probably because it uses its own
> C libraries.

yes, i did just run into this when testing my postproc patch accross
platforms, (test fails, looking at what/why, finding thread, reportin

Re: [FFmpeg-devel] [PATCH V5 0/2] Add libsvt HEVC encoder wrapper

[Jean-Baptiste Kempf]

Hello,

On Sat, 22 Dec 2018, at 13:02, Carl Eugen Hoyos wrote:
> > HEVC-compliant encoder library core that achieves excellent density-quality
> 
> I don't find it ideal that FFmpeg git claims that an Intel encoder
> does something "excellent" - unrelated to our actual opinion.
> Please rephrase.

My understanding from the testing we've done, is that SVT is a good encoder for 
live cases, but clearly not excellent in all cases, notably the VOD scenarios 
that are often used with FFmpeg.

> > tradeoffs, and is highly optimized for Intel Xeon Scalable Processor and
> 
> (and while there, also remove / change "highly optimized")

Yep, mention AVX-512, not the marketing terms.

> > Xeon D processors. Intel open source SVT-HEVC encoder in:
> > https://github.com/intel/SVT-HEVC.
> 
> > This wrapper work with SVT-HEVC master branch, more information can get
> > from https://github.com/intel/SVT-HEVC/blob/new_api/ffmpeg_plugin/.
> 
> This is irrelevant:
> If SVT is another example of a library that does not plan some kind
> of api stability, we should not merge your patch.
> If api stability is to be expected, the sentence is not necessary.

API will be stable, from my understandings, but not soon.


-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avformat/hls.c: Fix memory leak

[Derek Buitenhuis]

On 22/12/2018 14:54, Valery Kot wrote:
> Ping...
> Any maintainer willing to review/push straightforward one-liner patch?
> 
>> Thus 59MB leak in an hour! And keeps growing...

Can you add to the commit message to explain what exactly is
changed and why? 'Fix leak' isn't very useful.

Cheers,
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] avformat/mxfdec: fix error check in macro

[Marton Balint]

On Sat, 22 Dec 2018, Michael Niedermayer wrote:


On Sat, Dec 22, 2018 at 01:02:17PM -0300, James Almer wrote:

On 12/22/2018 12:50 PM, Michael Niedermayer wrote:

On Sat, Dec 15, 2018 at 10:18:18AM +0100, Hendrik Leppkes wrote:

On Sat, Dec 15, 2018 at 9:50 AM Paul B Mahol  wrote:


On 12/15/18, James Almer  wrote:

ffmpeg | branch: master | Paul B Mahol http://ffmpeg.org/mailman/listinfo/ffmpeg-cvslog>> | Thu Dec 13 23:51:02
2018 +0100| [e5a0013c4a6248fe7e2a651db1fda6b9bb2cd743] | committer: Paul B
Mahol

avformat/mxfdec: fix error check in macro

Fixes #6750.


/http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=e5a0013c4a6248fe7e2a651db1fda6b9bb2cd743

/---

 libavformat/mxfdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 887645d28b..f5e3a736e5 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2590,7 +2590,7 @@ static int64_t mxf_timestamp_to_int64(uint64_t
timestamp)

 #define SET_TS_METADATA(pb, name, var, str) do { \
 var = avio_rb64(pb); \
-if ((ret = avpriv_dict_set_timestamp(&s->metadata, name,
mxf_timestamp_to_int64(var)) < 0)) \
+if ((ret = avpriv_dict_set_timestamp(&s->metadata, name,
mxf_timestamp_to_int64(var))) < 0) \
 return ret; \
 } while (0)


This broke several mxf tests.

copy-trac4914
lavf-mxf
lavf-mxf_d10
lavf-mxf_dv25
lavf-mxf_dvcpro50
lavf-mxf_opatom
lavf-mxf_opatom_audio


Can not reproduce. Is this MSVS only thing?


Its not MSVS, but apparently Windows. I wonder if either gmtime_r or


this reproduces on mingw64+wine too btw

@@ -1,49 +1,2 @@
 b37c4d5693cdb5b9ed9b33501ffb682a *tests/data/fate/copy-trac4914.mxf
 561721 tests/data/fate/copy-trac4914.mxf
-#tb 0: 1001/3
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 480x270
-#sar 0: 1/1
-#tb 1: 1/48000
-#media_type 1: audio
-#codec_id 1: pcm_s16le
-#sample_rate 1: 48000
-#channel_layout 1: 3
-#channel_layout_name 1: stereo
-0,  0,  0,1,   259200, 0xf36957da
-1,  0,  0, 1602, 6408, 0x1dd7b37c
-0,  1,  1,1,   259200, 0x29a1f586
-1,   1602,   1602, 1601, 6404, 0xb6854846
-1,   3203,   3203, 1602, 6408, 0x4d3ea85e
-0,  2,  2,1,   259200, 0x5578d9c3
-0,  3,  3,1,   259200, 0x83938b61
-1,   4805,   4805, 1601, 6404, 0x5eb15a6d
-1,   6406,   6406, 1602, 6408, 0x059d21a0
-0,  4,  4,1,   259200, 0xa6ce7618
-0,  5,  5,1,   259200, 0x4892a0f5
-1,   8008,   8008, 1602, 6408, 0xd8352572
-0,  6,  6,1,   259200, 0x921c6051
-1,   9610,   9610, 1601, 6404, 0xf69be875
-1,  11211,  11211, 1602, 6408, 0x41e75601
-0,  7,  7,1,   259200, 0x618c0026
-0,  8,  8,1,   259200, 0xdbc3ca4d
-1,  12813,  12813, 1601, 6404, 0x75e3196d
-1,  14414,  14414, 1602, 6408, 0xb46bad29
-0,  9,  9,1,   259200, 0xf088c731
-0, 10, 10,1,   259200, 0xce77ddee
-1,  16016,  16016, 1602, 6408, 0x41e6ceac
-0, 11, 11,1,   259200, 0x798565eb
-1,  17618,  17618, 1601, 6404, 0x2258734e
-1,  19219,  19219, 1602, 6408, 0xc46d9103
-0, 12, 12,1,   259200, 0x57185dc8
-0, 13, 13,1,   259200, 0x607a9086
-1,  20821,  20821, 1601, 6404, 0xd7c07892
-1,  22422,  22422, 1602, 6408, 0x2aaad91d
-0, 14, 14,1,   259200, 0x59bd5c34
-0, 15, 15,1,   259200, 0xadb1da77
-1,  24024,  24024, 1602, 6408, 0x69bfb643
-0, 16, 16,1,   259200, 0x1f7d7b14
-1,  25626,  25626, 1601, 6404, 0x0e644904
-1,  27227,  27227, 1602, 6408, 0x06e92ea2
-0, 17, 17,1,   259200, 0xcdd45467
Test copy-trac4914 failed. Look at tests/data/fate/copy-trac4914.err for 
details.


As i said gmtime_r() is what's failing, and it's used by both the muxer
and demuxer. Only Cygwin seems to work, probably because it uses its own
C libraries.


yes, i did just run into this when testing my postproc patch accross
platforms, (test fails, looking at what/why, finding thread, reporting ...)


I'll take a look at this.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/avio: fix avio_feof documentation

[Marton Balint]

On Sat, 15 Dec 2018, Marton Balint wrote:




On Sun, 9 Dec 2018, Marton Balint wrote:


It has been this way too long to change behaviour, so let's change the docs
instead.

Signed-off-by: Marton Balint 
---
libavformat/avio.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavformat/avio.h b/libavformat/avio.h
index 75912ce6be..dcb8dcdf93 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -236,7 +236,7 @@ typedef struct AVIOContext {
int (*write_packet)(void *opaque, uint8_t *buf, int buf_size);
int64_t (*seek)(void *opaque, int64_t offset, int whence);
int64_t pos;/**< position in the file of the current buffer 

*/

-int eof_reached;/**< true if eof reached */
+int eof_reached;/**< true if was unable to read due to error 

or eof */

int write_flag; /**< true if open for writing */
int max_packet_size;
unsigned long checksum;
@@ -566,8 +566,8 @@ static av_always_inline int64_t avio_tell(AVIOContext 

*s)

int64_t avio_size(AVIOContext *s);

/**
- * feof() equivalent for AVIOContext.
- * @return non zero if and only if end of file
+ * Similar to feof() but also returns nonzero on read errors.
+ * @return non zero if and only if at end of file or a read error happened 

when reading.

 */
int avio_feof(AVIOContext *s);


Will apply soon.


Applied.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] avformat/mxfdec: fix error check in macro

[Michael Niedermayer]

On Sat, Dec 22, 2018 at 07:06:13PM +0100, Marton Balint wrote:
> 
> 
> On Sat, 22 Dec 2018, Michael Niedermayer wrote:
> 
> >On Sat, Dec 22, 2018 at 01:02:17PM -0300, James Almer wrote:
> >>On 12/22/2018 12:50 PM, Michael Niedermayer wrote:
> >>>On Sat, Dec 15, 2018 at 10:18:18AM +0100, Hendrik Leppkes wrote:
> On Sat, Dec 15, 2018 at 9:50 AM Paul B Mahol  wrote:
> >
> >On 12/15/18, James Almer  wrote:
> >>>ffmpeg | branch: master | Paul B Mahol  >>>> | Thu Dec 13 
> >>>23:51:02
> >>>2018 +0100| [e5a0013c4a6248fe7e2a651db1fda6b9bb2cd743] | committer: 
> >>>Paul B
> >>>Mahol
> >>>
> >>>avformat/mxfdec: fix error check in macro
> >>>
> >>>Fixes #6750.
> >>>
> /http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=e5a0013c4a6248fe7e2a651db1fda6b9bb2cd743
> >>>/---
> >>>
> >>> libavformat/mxfdec.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>>diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> >>>index 887645d28b..f5e3a736e5 100644
> >>>--- a/libavformat/mxfdec.c
> >>>+++ b/libavformat/mxfdec.c
> >>>@@ -2590,7 +2590,7 @@ static int64_t mxf_timestamp_to_int64(uint64_t
> >>>timestamp)
> >>>
> >>> #define SET_TS_METADATA(pb, name, var, str) do { \
> >>> var = avio_rb64(pb); \
> >>>-if ((ret = avpriv_dict_set_timestamp(&s->metadata, name,
> >>>mxf_timestamp_to_int64(var)) < 0)) \
> >>>+if ((ret = avpriv_dict_set_timestamp(&s->metadata, name,
> >>>mxf_timestamp_to_int64(var))) < 0) \
> >>> return ret; \
> >>> } while (0)
> >>
> >>This broke several mxf tests.
> >>
> >>copy-trac4914
> >>lavf-mxf
> >>lavf-mxf_d10
> >>lavf-mxf_dv25
> >>lavf-mxf_dvcpro50
> >>lavf-mxf_opatom
> >>lavf-mxf_opatom_audio
> >
> >Can not reproduce. Is this MSVS only thing?
> 
> Its not MSVS, but apparently Windows. I wonder if either gmtime_r or
> >>>
> >>>this reproduces on mingw64+wine too btw
> >>>
> >>>@@ -1,49 +1,2 @@
> >>> b37c4d5693cdb5b9ed9b33501ffb682a *tests/data/fate/copy-trac4914.mxf
> >>> 561721 tests/data/fate/copy-trac4914.mxf
> >>>-#tb 0: 1001/3
> >>>-#media_type 0: video
> >>>-#codec_id 0: rawvideo
> >>>-#dimensions 0: 480x270
> >>>-#sar 0: 1/1
> >>>-#tb 1: 1/48000
> >>>-#media_type 1: audio
> >>>-#codec_id 1: pcm_s16le
> >>>-#sample_rate 1: 48000
> >>>-#channel_layout 1: 3
> >>>-#channel_layout_name 1: stereo
> >>>-0,  0,  0,1,   259200, 0xf36957da
> >>>-1,  0,  0, 1602, 6408, 0x1dd7b37c
> >>>-0,  1,  1,1,   259200, 0x29a1f586
> >>>-1,   1602,   1602, 1601, 6404, 0xb6854846
> >>>-1,   3203,   3203, 1602, 6408, 0x4d3ea85e
> >>>-0,  2,  2,1,   259200, 0x5578d9c3
> >>>-0,  3,  3,1,   259200, 0x83938b61
> >>>-1,   4805,   4805, 1601, 6404, 0x5eb15a6d
> >>>-1,   6406,   6406, 1602, 6408, 0x059d21a0
> >>>-0,  4,  4,1,   259200, 0xa6ce7618
> >>>-0,  5,  5,1,   259200, 0x4892a0f5
> >>>-1,   8008,   8008, 1602, 6408, 0xd8352572
> >>>-0,  6,  6,1,   259200, 0x921c6051
> >>>-1,   9610,   9610, 1601, 6404, 0xf69be875
> >>>-1,  11211,  11211, 1602, 6408, 0x41e75601
> >>>-0,  7,  7,1,   259200, 0x618c0026
> >>>-0,  8,  8,1,   259200, 0xdbc3ca4d
> >>>-1,  12813,  12813, 1601, 6404, 0x75e3196d
> >>>-1,  14414,  14414, 1602, 6408, 0xb46bad29
> >>>-0,  9,  9,1,   259200, 0xf088c731
> >>>-0, 10, 10,1,   259200, 0xce77ddee
> >>>-1,  16016,  16016, 1602, 6408, 0x41e6ceac
> >>>-0, 11, 11,1,   259200, 0x798565eb
> >>>-1,  17618,  17618, 1601, 6404, 0x2258734e
> >>>-1,  19219,  19219, 1602, 6408, 0xc46d9103
> >>>-0, 12, 12,1,   259200, 0x57185dc8
> >>>-0, 13, 13,1,   259200, 0x607a9086
> >>>-1,  20821,  20821, 1601, 6404, 0xd7c07892
> >>>-1,  22422,  22422, 1602, 6408, 0x2aaad91d
> >>>-0, 14, 14,1,   259200, 0x59bd5c34
> >>>-0, 15, 15,1,   259200, 0xadb1da77
> >>>-1,  24024,  24024, 1602, 6408, 0x69bfb643
> >>>-0, 16, 16,1,   259200, 0x1f7d7b14
> >>>-1,  25626,  25626, 1601, 6404, 0x0e644904
> >>>-1,  27227,  27227, 1602, 6408, 0x06e92ea2
> >>>-0, 17, 17,1,   259200, 0xcdd45467
> >>>Test copy-trac4914 failed. Look at tests/data/fate/copy-trac4914.err for 
> >>>details.
> >>
> >>As i said gmtime_r() is what's failing, and it's used 

Re: [FFmpeg-devel] [PATCH] avformat/mpegts: unset DTS/PTS for subtitle PES packets if PCR not available

[Jan Ekström]

On Fri, Dec 21, 2018 at 9:04 PM Jan Ekström  wrote:
>
> On Wed, Dec 19, 2018 at 8:56 PM Michael Niedermayer
>  wrote:
> >
> > On Sat, Dec 15, 2018 at 08:50:41PM +0200, Jan Ekström wrote:
> > > Fixes issues when a subtitle packet is received before PCR for the
> > > program has been received, leading to wildly jumping timestamps
> > > on the lavf client side as well as in the re-ordering logic.
> > >
> > > This usually happens in case of multiplexes where the PCR of a
> > > program is not taken into account with subtitle tracks' DTS/PTS.
> > > ---
> > >  libavformat/mpegts.c | 11 +++
> > >  1 file changed, 11 insertions(+)
> >
> > For the record, so this is not lost on IRC and causes misunderstandings
> >  JEEB, if you prefer the simple solution iam fine with that too 
> > but i might (if i find time) rewrite it to do the buffering so the 
> > timestamps arent lost in the cases this affects
> >
>
> As Michael is OK with this, If there are no further comments, I will
> push this tomorrow morning.
>
> As a reminder of what this improves:
> Sample: 
> https://kuroko.fushizen.eu/samples/2018-04-04-funky_teletext_mux.cut.ts
>
> Steps to show difference:
> 1. ffprobe -of json -show_packets -show_programs - > before.json
> 2. ffprobe -of json -show_packets -show_programs - > after.json
> 3. git diff --no-index before.json after.json
>
> Example of a failing ffmpeg.c command line without these changes
> (requires the libzvbi teletext decoder to be enabled):
> ffmpeg -fix_sub_duration -txt_format text -v verbose -i
> 2018-04-04-funky_teletext_mux.cut.ts -c:v mpeg4 -c:a aac -c:s ass
> out.mkv
>
> This works after this patch is applied and the incorrect timestamp is
> no longer there in the first teletext subtitle packet.
>
> Jan

Applied to master.

Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/mxfdec: Do not process zero modified_date timestamp.

[Michael Niedermayer]

This causes windows to fail as the timestamp is outside its supported range
Fixes regression & fate

Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index f5e3a736e5..6e96107498 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2590,7 +2590,7 @@ static int64_t mxf_timestamp_to_int64(uint64_t timestamp)
 
 #define SET_TS_METADATA(pb, name, var, str) do { \
 var = avio_rb64(pb); \
-if ((ret = avpriv_dict_set_timestamp(&s->metadata, name, 
mxf_timestamp_to_int64(var))) < 0) \
+if (var && (ret = avpriv_dict_set_timestamp(&s->metadata, name, 
mxf_timestamp_to_int64(var))) < 0) \
 return ret; \
 } while (0)
 
-- 
2.20.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: Do not process zero modified_date timestamp.

[Marton Balint]

On Sat, 22 Dec 2018, Michael Niedermayer wrote:


This causes windows to fail as the timestamp is outside its supported range
Fixes regression & fate


LGTM, exactly my patch.

Thanks,
Marton




Signed-off-by: Michael Niedermayer 
---
libavformat/mxfdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index f5e3a736e5..6e96107498 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2590,7 +2590,7 @@ static int64_t mxf_timestamp_to_int64(uint64_t timestamp)

#define SET_TS_METADATA(pb, name, var, str) do { \
var = avio_rb64(pb); \
-if ((ret = avpriv_dict_set_timestamp(&s->metadata, name, 
mxf_timestamp_to_int64(var))) < 0) \
+if (var && (ret = avpriv_dict_set_timestamp(&s->metadata, name, 
mxf_timestamp_to_int64(var))) < 0) \
return ret; \
} while (0)

--
2.20.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: Do not process zero modified_date timestamp.

[James Almer]

On 12/22/2018 3:44 PM, Michael Niedermayer wrote:
> This causes windows to fail as the timestamp is outside its supported range
> Fixes regression & fate
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mxfdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index f5e3a736e5..6e96107498 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -2590,7 +2590,7 @@ static int64_t mxf_timestamp_to_int64(uint64_t 
> timestamp)
>  
>  #define SET_TS_METADATA(pb, name, var, str) do { \
>  var = avio_rb64(pb); \
> -if ((ret = avpriv_dict_set_timestamp(&s->metadata, name, 
> mxf_timestamp_to_int64(var))) < 0) \
> +if (var && (ret = avpriv_dict_set_timestamp(&s->metadata, name, 
> mxf_timestamp_to_int64(var))) < 0) \
>  return ret; \
>  } while (0)

This fixes the crash in the demuxer, but what about the muxing behavior?
The mxf files with zero as modified_date timestamp were created by our
muxer, also because gmtime_r() returns NULL in it. Is 0 within the valid
range for it? Can the modified_date tag be skipped if gmtime_r() fails,
or is an obligatory metadata tag in the spec?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: Do not process zero modified_date timestamp.

[Marton Balint]

On Sat, 22 Dec 2018, James Almer wrote:


On 12/22/2018 3:44 PM, Michael Niedermayer wrote:

This causes windows to fail as the timestamp is outside its supported range
Fixes regression & fate

Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index f5e3a736e5..6e96107498 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2590,7 +2590,7 @@ static int64_t mxf_timestamp_to_int64(uint64_t timestamp)

 #define SET_TS_METADATA(pb, name, var, str) do { \
 var = avio_rb64(pb); \
-if ((ret = avpriv_dict_set_timestamp(&s->metadata, name, 
mxf_timestamp_to_int64(var))) < 0) \
+if (var && (ret = avpriv_dict_set_timestamp(&s->metadata, name, 
mxf_timestamp_to_int64(var))) < 0) \
 return ret; \
 } while (0)


This fixes the crash in the demuxer, but what about the muxing behavior?
The mxf files with zero as modified_date timestamp were created by our
muxer, also because gmtime_r() returns NULL in it. Is 0 within the valid
range for it? Can the modified_date tag be skipped if gmtime_r() fails,
or is an obligatory metadata tag in the spec?


According to spec, 0 means unknown, and yes, it is required.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: Do not process zero modified_date timestamp.

[James Almer]

On 12/22/2018 4:00 PM, Marton Balint wrote:
> 
> 
> On Sat, 22 Dec 2018, James Almer wrote:
> 
>> On 12/22/2018 3:44 PM, Michael Niedermayer wrote:
>>> This causes windows to fail as the timestamp is outside its supported
>>> range
>>> Fixes regression & fate
>>>
>>> Signed-off-by: Michael Niedermayer 
>>> ---
>>>  libavformat/mxfdec.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
>>> index f5e3a736e5..6e96107498 100644
>>> --- a/libavformat/mxfdec.c
>>> +++ b/libavformat/mxfdec.c
>>> @@ -2590,7 +2590,7 @@ static int64_t mxf_timestamp_to_int64(uint64_t
>>> timestamp)
>>>
>>>  #define SET_TS_METADATA(pb, name, var, str) do { \
>>>  var = avio_rb64(pb); \
>>> -    if ((ret = avpriv_dict_set_timestamp(&s->metadata, name,
>>> mxf_timestamp_to_int64(var))) < 0) \
>>> +    if (var && (ret = avpriv_dict_set_timestamp(&s->metadata, name,
>>> mxf_timestamp_to_int64(var))) < 0) \
>>>  return ret; \
>>>  } while (0)
>>
>> This fixes the crash in the demuxer, but what about the muxing behavior?
>> The mxf files with zero as modified_date timestamp were created by our
>> muxer, also because gmtime_r() returns NULL in it. Is 0 within the valid
>> range for it? Can the modified_date tag be skipped if gmtime_r() fails,
>> or is an obligatory metadata tag in the spec?
> 
> According to spec, 0 means unknown, and yes, it is required.
> 
> Regards,
> Marton

Ok, thanks. Patch LGTM as well then.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] postproc/postprocess_template: remove FF_REG_sp from clobber list

[Michael Niedermayer]

On Thu, Dec 20, 2018 at 10:04:21PM -0300, James Almer wrote:
> On 12/20/2018 8:56 PM, Michael Niedermayer wrote:
> > On Thu, Dec 20, 2018 at 06:54:12PM -0300, James Almer wrote:
> >> On 12/20/2018 6:40 PM, Michael Niedermayer wrote:
> >>> Future gcc may no longer support this
> >>>
> >>> Signed-off-by: Michael Niedermayer 
> >>> ---
> >>>  libpostproc/postprocess_template.c | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/libpostproc/postprocess_template.c 
> >>> b/libpostproc/postprocess_template.c
> >>> index 485eb5cfc0..b0adfd168c 100644
> >>> --- a/libpostproc/postprocess_template.c
> >>> +++ b/libpostproc/postprocess_template.c
> >>> @@ -1317,7 +1317,7 @@ DERING_CORE((%0, %1, 8)   ,(%%FF_REGd, %1, 
> >>> 4),%%mm2,%%mm4,%%mm0,%%mm3,%%mm5,
> >>>  "1:\n\t"
> >>>  : : "r" (src), "r" ((x86_reg)stride), "m" (c->pQPb), 
> >>> "m"(c->pQPb2), "q"(tmp)
> >>>NAMED_CONSTRAINTS_ADD(deringThreshold,b00,b02,b08)
> >>> -: "%"FF_REG_a, "%"FF_REG_d, "%"FF_REG_sp
> >>> +: "%"FF_REG_a, "%"FF_REG_d
> >>>  );
> >>>  #else // HAVE_7REGS && (TEMPLATE_PP_MMXEXT || TEMPLATE_PP_3DNOW)
> >>>  int y;
> >>
> >> The set compiles with gcc 9 now, so LGTM if tested. Should be backported
> >> to supported releases as well.
> > 
> > ive tested it locally on x86 32&64 but not with gcc 9, it would be ideal
> > if someone tests this with gcc 9 beyond compilation
> > 
> > this should use the code, the "31" can be varied to test different 
> > "strength"
> > -vf 'pp=de/fq|31'
> > 
> > thx
> 
> Tested it with gcc 9. Doesn't crash and the output is bitexact to what i
> get with gcc 8.

applied

thx
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add photocd decoder

[Steinar H. Gunderson]

On Sat, Dec 22, 2018 at 09:53:16AM +0100, Paul B Mahol wrote:
>> FFmpeg doesn't have a good understanding of gamma (it rarely actually
>> converts between different gamma ramps), but that's not a problem with
>> PhotoCD per se. I can't find a good reason why FFmpeg could not be
>> extended with conversions from the PhotoCD color space to sRGB, at least
>> not if clipping out-of-gamut colors is acceptable.
> I'm all ears.

I happen to have a library that does all of this stuff... :-)
(https://movit.sesse.net/)

I don't think FFmpeg really wants to link in Movit for a variety of reasons,
and in this case, PhotoCD is nominally Rec. 709, so you don't actually need
a colorspace transform. This means that the only steps you really need would
be:

 1. Decode the YCC to RGB. Allow for out-of-0..255 (ideally float, but
FFmpeg probably wants to use int16 or something similar instead).
 2. Convert to linear gamma (either float, or 16-bit fixed point) using the
inverse of the function mentioned in Wikipedia.
 3. Convert back from linear gamma to sRGB or Rec. 709 gamma.
 4. Clip to 0..1, then scale to 0..255.

Step 2, 3, 4 can probably be collapsed into a LUT that can be applied three
times (the channels are independent, since the RGB color space is the same).

If you're not happy with blown highlights (colors that clip), it's a much
harder problem.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add photocd decoder

[Paul B Mahol]

On 12/22/18, Steinar H. Gunderson  wrote:
> On Sat, Dec 22, 2018 at 09:53:16AM +0100, Paul B Mahol wrote:
>>> FFmpeg doesn't have a good understanding of gamma (it rarely actually
>>> converts between different gamma ramps), but that's not a problem with
>>> PhotoCD per se. I can't find a good reason why FFmpeg could not be
>>> extended with conversions from the PhotoCD color space to sRGB, at least
>>> not if clipping out-of-gamut colors is acceptable.
>> I'm all ears.
>
> I happen to have a library that does all of this stuff... :-)
> (https://movit.sesse.net/)
>
> I don't think FFmpeg really wants to link in Movit for a variety of reasons,
> and in this case, PhotoCD is nominally Rec. 709, so you don't actually need
> a colorspace transform. This means that the only steps you really need would
> be:
>
>  1. Decode the YCC to RGB. Allow for out-of-0..255 (ideally float, but
> FFmpeg probably wants to use int16 or something similar instead).
>  2. Convert to linear gamma (either float, or 16-bit fixed point) using the
> inverse of the function mentioned in Wikipedia.
>  3. Convert back from linear gamma to sRGB or Rec. 709 gamma.
>  4. Clip to 0..1, then scale to 0..255.
>
> Step 2, 3, 4 can probably be collapsed into a LUT that can be applied three
> times (the channels are independent, since the RGB color space is the same).
>
> If you're not happy with blown highlights (colors that clip), it's a much
> harder problem.

I can not accept internal conversion to RGB. This is subsampled format
after all.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add photocd decoder

[Steinar H. Gunderson]

On Sat, Dec 22, 2018 at 09:04:26PM +0100, Paul B Mahol wrote:
> I can not accept internal conversion to RGB. This is subsampled format
> after all.

Well, it's not Y'CbCr, so if so, you'd need to add a new AVPixelFormat value
(e.g. AV_PIX_FMT_YCC420P). I'm not sure what applications would do with it
except convert it to RGB, though. (You can't convert subsampled YCC to
subsampled Y'CbCr without upsampling, converting and then subsampling again,
which is obviously lossy.)

/* Steinar */
-- 
Homepage: https://www.sesse.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add photocd decoder

[Paul B Mahol]

On 12/22/18, Steinar H. Gunderson  wrote:
> On Sat, Dec 22, 2018 at 09:04:26PM +0100, Paul B Mahol wrote:
>> I can not accept internal conversion to RGB. This is subsampled format
>> after all.
>
> Well, it's not Y'CbCr, so if so, you'd need to add a new AVPixelFormat value
> (e.g. AV_PIX_FMT_YCC420P). I'm not sure what applications would do with it
> except convert it to RGB, though. (You can't convert subsampled YCC to
> subsampled Y'CbCr without upsampling, converting and then subsampling again,
> which is obviously lossy.)

Unacceptable, I'm not adding another yuv420p variant.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add photocd decoder

[Steinar H. Gunderson]

On Sat, Dec 22, 2018 at 09:18:11PM +0100, Paul B Mahol wrote:
> Unacceptable, I'm not adding another yuv420p variant.

Well, if returning YCC as YCC is unacceptable, and converting YCC to RGB is
unacceptable, I believe your only choices are:

  1. Try to convert YCC to Y'CbCr ignoring the gamma curve, which will return
 images that look wrong and cannot be repaired by reasonable means.
  2. Return YCC mislabeled as something else, which will look even more wrong.
  3. Don't include PhotoCD support in FFmpeg.

I don't know if any of these options are acceptable to you.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add photocd decoder

[Paul B Mahol]

On 12/22/18, Steinar H. Gunderson  wrote:
> On Sat, Dec 22, 2018 at 09:18:11PM +0100, Paul B Mahol wrote:
>> Unacceptable, I'm not adding another yuv420p variant.
>
> Well, if returning YCC as YCC is unacceptable, and converting YCC to RGB is
> unacceptable, I believe your only choices are:
>
>   1. Try to convert YCC to Y'CbCr ignoring the gamma curve, which will
> return
>  images that look wrong and cannot be repaired by reasonable means.
>   2. Return YCC mislabeled as something else, which will look even more
> wrong.
>   3. Don't include PhotoCD support in FFmpeg.
>

4. Leave user to do conversion as he wish.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add photocd decoder

[Steinar H. Gunderson]

On Sat, Dec 22, 2018 at 09:32:35PM +0100, Paul B Mahol wrote:
>>   2. Return YCC mislabeled as something else, which will look even more 
>> wrong.
> 4. Leave user to do conversion as he wish.

That's essentially the same as #2, no?

/* Steinar */
-- 
Homepage: https://www.sesse.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: Do not process zero modified_date timestamp.

[Michael Niedermayer]

On Sat, Dec 22, 2018 at 04:23:54PM -0300, James Almer wrote:
> On 12/22/2018 4:00 PM, Marton Balint wrote:
> > 
> > 
> > On Sat, 22 Dec 2018, James Almer wrote:
> > 
> >> On 12/22/2018 3:44 PM, Michael Niedermayer wrote:
> >>> This causes windows to fail as the timestamp is outside its supported
> >>> range
> >>> Fixes regression & fate
> >>>
> >>> Signed-off-by: Michael Niedermayer 
> >>> ---
> >>>  libavformat/mxfdec.c | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> >>> index f5e3a736e5..6e96107498 100644
> >>> --- a/libavformat/mxfdec.c
> >>> +++ b/libavformat/mxfdec.c
> >>> @@ -2590,7 +2590,7 @@ static int64_t mxf_timestamp_to_int64(uint64_t
> >>> timestamp)
> >>>
> >>>  #define SET_TS_METADATA(pb, name, var, str) do { \
> >>>  var = avio_rb64(pb); \
> >>> -    if ((ret = avpriv_dict_set_timestamp(&s->metadata, name,
> >>> mxf_timestamp_to_int64(var))) < 0) \
> >>> +    if (var && (ret = avpriv_dict_set_timestamp(&s->metadata, name,
> >>> mxf_timestamp_to_int64(var))) < 0) \
> >>>  return ret; \
> >>>  } while (0)
> >>
> >> This fixes the crash in the demuxer, but what about the muxing behavior?
> >> The mxf files with zero as modified_date timestamp were created by our
> >> muxer, also because gmtime_r() returns NULL in it. Is 0 within the valid
> >> range for it? Can the modified_date tag be skipped if gmtime_r() fails,
> >> or is an obligatory metadata tag in the spec?
> > 
> > According to spec, 0 means unknown, and yes, it is required.
> > 
> > Regards,
> > Marton
> 
> Ok, thanks. Patch LGTM as well then.

will apply

thanks to everyone

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH V5 0/2] Add libsvt HEVC encoder wrapper

[Carl Eugen Hoyos]

2018-12-22 17:57 GMT+01:00, Jean-Baptiste Kempf :

> On Sat, 22 Dec 2018, at 13:02, Carl Eugen Hoyos wrote:

>> > This wrapper work with SVT-HEVC master branch, more information can get
>> > from https://github.com/intel/SVT-HEVC/blob/new_api/ffmpeg_plugin/.
>>
>> This is irrelevant:
>> If SVT is another example of a library that does not plan some kind
>> of api stability, we should not merge your patch.
>> If api stability is to be expected, the sentence is not necessary.
>
> API will be stable, from my understandings, but not soon.

If this is correct - I have no idea - the patch should be sent again
once the api is believed to be stable.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]configure: Make sure libpostproc can be found if -rpath-link doesn't work

[Carl Eugen Hoyos]

2018-12-22 9:35 GMT+01:00, Michael Niedermayer :
> On Sat, Dec 22, 2018 at 12:08:19AM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes running fate with "--enable-shared --enable-gpl" on
>> Solaris, the linker searches "libpostproc" in a
>> directory"-link=libpostproc".
>> Only tested on Solaris.
>>
>> Please comment, Carl Eugen
>
>>  configure |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> cb5e59b98712ca53aba4561f4d7fe365b3b1e2ff
>> 0001-configure-Make-sure-libpostproc-can-be-found-if-rpat.patch
>> From d69f1fcee41e803e5208bbfabdeb37a19e73814b Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Sat, 22 Dec 2018 00:04:43 +0100
>> Subject: [PATCH] configure: Make sure libpostproc can be found if
>> -rpath-link
>>  doesn't work.
>>
>> Solaris ld takes "-rpath-link=libpostproc" as indication to search in
>> "-link=libpostproc".
>> ---
>>  configure |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/configure b/configure
>> index 2205751..04d3417 100755
>> --- a/configure
>> +++ b/configure
>> @@ -6535,7 +6535,7 @@ EOF
>>
>>  # add some linker flags
>>  check_ldflags -Wl,--warn-common
>> -check_ldflags
>> -Wl,-rpath-link=libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample
>> +check_ldflags
>> -Wl,-rpath-link=:libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample
>>  enabled rpath && add_ldexeflags -Wl,-rpath,$libdir && add_ldsoflags
>> -Wl,-rpath,$libdir
>>  test_ldflags -Wl,-Bsymbolic && append SHFLAGS -Wl,-Bsymbolic
>
> theres a second similar use of rpath in git (in tools/target_dec_fuzzer.c)

New patch attached.

Thank you, Carl Eugen
From d69f1fcee41e803e5208bbfabdeb37a19e73814b Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 22 Dec 2018 00:04:43 +0100
Subject: [PATCH] configure: Make sure libpostproc can be found if -rpath-link
 doesn't work.

Solaris ld takes "-rpath-link=libpostproc" as indication to search in "-link=libpostproc".
---
 configure |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 2205751..04d3417 100755
--- a/configure
+++ b/configure
@@ -6535,7 +6535,7 @@ EOF
 
 # add some linker flags
 check_ldflags -Wl,--warn-common
-check_ldflags -Wl,-rpath-link=libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample
+check_ldflags -Wl,-rpath-link=:libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample
 enabled rpath && add_ldexeflags -Wl,-rpath,$libdir && add_ldsoflags -Wl,-rpath,$libdir
 test_ldflags -Wl,-Bsymbolic && append SHFLAGS -Wl,-Bsymbolic
 
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index a94d5e6..2a6d525 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -30,7 +30,7 @@
   * build the fuzz target.
 Choose the value of FFMPEG_CODEC (e.g. AV_CODEC_ID_DVD_SUBTITLE) and
 choose one of FUZZ_FFMPEG_VIDEO, FUZZ_FFMPEG_AUDIO, FUZZ_FFMPEG_SUBTITLE.
-clang -fsanitize=address -fsanitize-coverage=trace-pc-guard,trace-cmp tools/target_dec_fuzzer.c -o target_dec_fuzzer -I.   -DFFMPEG_CODEC=AV_CODEC_ID_MPEG1VIDEO -DFUZZ_FFMPEG_VIDEO ../../libfuzzer/libFuzzer.a   -Llibavcodec -Llibavdevice -Llibavfilter -Llibavformat -Llibavresample -Llibavutil -Llibpostproc -Llibswscale -Llibswresample -Wl,--as-needed -Wl,-z,noexecstack -Wl,--warn-common -Wl,-rpath-link=libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample -lavdevice -lavfilter -lavformat -lavcodec -lswresample -lswscale -lavutil -ldl -lxcb -lxcb-shm -lxcb -lxcb-xfixes  -lxcb -lxcb-shape -lxcb -lX11 -lasound -lm -lbz2 -lz -pthread
+clang -fsanitize=address -fsanitize-coverage=trace-pc-guard,trace-cmp tools/target_dec_fuzzer.c -o target_dec_fuzzer -I.   -DFFMPEG_CODEC=AV_CODEC_ID_MPEG1VIDEO -DFUZZ_FFMPEG_VIDEO ../../libfuzzer/libFuzzer.a   -Llibavcodec -Llibavdevice -Llibavfilter -Llibavformat -Llibavresample -Llibavutil -Llibpostproc -Llibswscale -Llibswresample -Wl,--as-needed -Wl,-z,noexecstack -Wl,--warn-common -Wl,-rpath-link=:libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample -lavdevice -lavfilter -lavformat -lavcodec -lswresample -lswscale -lavutil -ldl -lxcb -lxcb-shm -lxcb -lxcb-xfixes  -lxcb -lxcb-shape -lxcb -lX11 -lasound -lm -lbz2 -lz -pthread
   * create a corpus directory and put some samples there (empty dir is ok too):
 mkdir CORPUS && cp some-files CORPUS

-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavf/vividas: Do not increase extradata_size after allocation

[Carl Eugen Hoyos]

Hi!

Attached patch can avoid a crash in avcodec_parameters_from_context()
if extradata_size was increased after allocation.

Please comment, Carl Eugen
From 37ca1caa949902ec209c7c779b2c5b0ca3d3a3e6 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 23 Dec 2018 00:34:57 +0100
Subject: [PATCH] lavf/vividas: Do not increase extradata_size after allocation.

Avoids a crash in avcodec_parameters_from_context().
---
 libavformat/vividas.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/vividas.c b/libavformat/vividas.c
index e199b05..00a1a0f 100644
--- a/libavformat/vividas.c
+++ b/libavformat/vividas.c
@@ -392,7 +392,8 @@ static void track_header(VividasDemuxContext *viv, AVFormatContext *s,  uint8_t
 offset += data_len[j];
 }
 
-st->codecpar->extradata_size = offset;
+if (offset < st->codecpar->extradata_size)
+st->codecpar->extradata_size = offset;
 }
 }
 
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] GCC 8.2.0 compiler-warnings on ffmpeg-N-92765-g2744d6b

[Reino Wijnsma]

Hello ffmpeg-devel,

I can't code in C, so to still contribute to this project I'd like to report 
the warnings I got while compiling ffmpeg-N-92765-g2744d6b on Windows using 
Cygwin, MinGW 6.0.0 and GCC 8.2.0.

configure options:
> Configuring ffmpeg_git as ./configure --arch=x86 --target-os=mingw32 
> --cross-prefix=/cygdrive/m/ffmpeg-windows-build-helpers-master/ffmpeg_local_builds/sandbox/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-
>  --pkg-config=pkg-config --pkg-config-flags=--static --extra-version=Reino 
> --enable-gray --enable-version3 --disable-debug --disable-doc 
> --disable-htmlpages --disable-manpages --disable-podpages --disable-txtpages 
> --disable-w32threads --enable-avisynth --enable-frei0r --enable-filter=frei0r 
> --enable-gmp --enable-gpl --enable-libaom --enable-libass --enable-libbluray 
> --enable-libbs2b --enable-libcaca --extra-cflags=-DCACA_STATIC 
> --enable-libfdk-aac --enable-libflite --enable-libfontconfig 
> --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm 
> --enable-libilbc --enable-libmp3lame --enable-libmysofa 
> --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 
> --enable-libopenmpt --enable-libopus --enable-librubberband --enable-libsnappy
> --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame 
> --extra-cflags=-DLIBTWOLAME_STATIC --enable-libvidstab 
> --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwebp 
> --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxml2 
> --enable-libxvid --enable-libzimg --enable-libzvbi --enable-mbedtls 
> --extra-cflags=-march=pentium3 --extra-cflags=-mtune=athlon-xp 
> --extra-cflags=-O2 --extra-cflags=-mfpmath=sse --extra-cflags=-msse 
> --enable-static --disable-shared 
> --prefix=/cygdrive/m/ffmpeg-windows-build-helpers-master/ffmpeg_local_builds/sandbox/cross_compilers/mingw-w64-i686/i686-w64-mingw32.

Warnings (other than [-Wdeprecated-declarations]):
> CClibavformat/aadec.o
> libavformat/aadec.c: In function 'aa_read_header':
> libavformat/aadec.c:115:13: warning: 'strncpy' output may be truncated 
> copying 63 bytes from a string of length 127 [-Wstringop-truncation]
>  strncpy(codec_name, val, sizeof(codec_name) - 1);
>  ^~~~
> CClibavformat/dashdec.o
> In function 'parse_manifest_representation',
> inlined from 'parse_manifest_adaptationset' at 
> libavformat/dashdec.c:1144:19,
> inlined from 'parse_manifest' at libavformat/dashdec.c:1331:17:
> libavformat/dashdec.c:1059:13: warning: 'strncpy' specified bound 20 equals 
> destination size [-Wstringop-truncation]
>  strncpy(rep->id, rep_id_val ? rep_id_val : "", sizeof(rep->id));
>  ^~~
> CClibavformat/hls.o
> In function 'new_rendition',
> inlined from 'parse_playlist' at libavformat/hls.c:787:13:
> libavformat/hls.c:515:13: warning: 'strncpy' output may be truncated copying 
> between 2 and 62 bytes from a string of length 63 [-Wstringop-truncation]
>  strncpy(rend->language + langlen + 1, info->assoc_language,
>  ^~~
>  sizeof(rend->language) - langlen - 2);
>  ~
> CClibavformat/hlsenc.o
> libavformat/hlsenc.c: In function 'get_default_pattern_localtime_fmt':
> libavformat/hlsenc.c:1678:63: warning: unknown conversion type character 's' 
> in format [-Wformat=]
>  return (HAVE_LIBC_MSVCRT || !strftime(b, sizeof(b), "%s", p) || 
> !strcmp(b, "%s")) ? "-%Y%m%d%H%M%S.m4s" : "-%s.m4s";
>^
> libavformat/hlsenc.c:1680:59: warning: unknown conversion type character 's' 
> in format [-Wformat=]
>  return (HAVE_LIBC_MSVCRT || !strftime(b, sizeof(b), "%s", p) || 
> !strcmp(b, "%s")) ? "-%Y%m%d%H%M%S.ts" : "-%s.ts";
>^
> CClibavformat/os_support.o
> libavformat/os_support.c: In function 'ff_poll':
> libavformat/os_support.c:248:23: warning: comparison of unsigned expression < 
> 0 is always false [-Wtype-limits]
>  if (fds[i].fd < 0)
>^
> CClibavformat/protocols.o
> libavformat/protocols.c: In function 'avio_enum_protocols':
> libavformat/protocols.c:98:7: warning: assignment discards 'const' qualifier 
> from pointer target type [-Wdiscarded-qualifiers]
>  p = p ? p + 1 : url_protocols;
>^
> X86ASMlibavcodec/x86/proresdsp.o
> STRIPlibavcodec/x86/proresdsp.o
> /cygdrive/m/ffmpeg-windows-build-helpers-master/ffmpeg_local_builds/sandbox/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-strip:
>  error: the input file 'libavcodec/x86/proresdsp.o' has no sections
> make: [ffbuild/common.mak:83: libavcodec/x86/proresdsp.o] Error 1 (ignored)
> X86ASMl

[FFmpeg-devel] [PATCH 1/3] avformat/mxfdec: replace obsolete comment

[Marton Balint]

We no longer use strftime directly but use av_timegm to get an int64_t 
timestamp.

Signed-off-by: Marton Balint 
---
 libavformat/mxfdec.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 6e96107498..d78f8ad2e4 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2563,9 +2563,7 @@ static int64_t mxf_timestamp_to_int64(uint64_t timestamp)
 time.tm_min  = (timestamp >> 16 & 0xFF);
 time.tm_sec  = (timestamp >> 8  & 0xFF);
 
-/* msvcrt versions of strftime calls the invalid parameter handler
- * (aborting the process if one isn't set) if the parameters are out
- * of range. */
+/* Clip values for legacy reasons. Maybe we should return error instead? */
 time.tm_mon  = av_clip(time.tm_mon,  0, 11);
 time.tm_mday = av_clip(time.tm_mday, 1, 31);
 time.tm_hour = av_clip(time.tm_hour, 0, 23);
-- 
2.16.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/3] avformat/mxfenc: support writing subsecond precision timestamps

[Marton Balint]

Signed-off-by: Marton Balint 
---
 libavformat/mxfenc.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 5e7bd212dc..032ee3bf3d 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -2332,8 +2332,9 @@ static int mxf_parse_mpeg2_frame(AVFormatContext *s, 
AVStream *st,
 return !!sc->codec_ul;
 }
 
-static uint64_t mxf_parse_timestamp(time_t timestamp)
+static uint64_t mxf_parse_timestamp(int64_t timestamp64)
 {
+time_t timestamp = timestamp64 / 100;
 struct tm tmbuf;
 struct tm *time = gmtime_r(×tamp, &tmbuf);
 if (!time)
@@ -2343,7 +2344,8 @@ static uint64_t mxf_parse_timestamp(time_t timestamp)
(uint64_t) time->tm_mday   << 32 |
   time->tm_hour   << 24 |
   time->tm_min<< 16 |
-  time->tm_sec<< 8;
+  time->tm_sec<< 8  |
+  (timestamp64 % 100) / 4000;
 }
 
 static void mxf_gen_umid(AVFormatContext *s)
@@ -2580,7 +2582,7 @@ static int mxf_write_header(AVFormatContext *s)
 sc->order = AV_RB32(sc->track_essence_element_key+12);
 }
 
-if (ff_parse_creation_time_metadata(s, ×tamp, 1) > 0)
+if (ff_parse_creation_time_metadata(s, ×tamp, 0) > 0)
 mxf->timestamp = mxf_parse_timestamp(timestamp);
 mxf->duration = -1;
 
-- 
2.16.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/3] avformat/mxfdec: support subsecond precision of decoded timestamps

[Marton Balint]

Signed-off-by: Marton Balint 
---
 libavformat/mxfdec.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index d78f8ad2e4..0553adcb06 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2556,12 +2556,14 @@ fail_and_free:
 static int64_t mxf_timestamp_to_int64(uint64_t timestamp)
 {
 struct tm time = { 0 };
+int msecs;
 time.tm_year = (timestamp >> 48) - 1900;
 time.tm_mon  = (timestamp >> 40 & 0xFF) - 1;
 time.tm_mday = (timestamp >> 32 & 0xFF);
 time.tm_hour = (timestamp >> 24 & 0xFF);
 time.tm_min  = (timestamp >> 16 & 0xFF);
 time.tm_sec  = (timestamp >> 8  & 0xFF);
+msecs= (timestamp & 0xFF) * 4;
 
 /* Clip values for legacy reasons. Maybe we should return error instead? */
 time.tm_mon  = av_clip(time.tm_mon,  0, 11);
@@ -2569,8 +2571,9 @@ static int64_t mxf_timestamp_to_int64(uint64_t timestamp)
 time.tm_hour = av_clip(time.tm_hour, 0, 23);
 time.tm_min  = av_clip(time.tm_min,  0, 59);
 time.tm_sec  = av_clip(time.tm_sec,  0, 59);
+msecs= av_clip(msecs, 0, 999);
 
-return (int64_t)av_timegm(&time) * 100;
+return (int64_t)av_timegm(&time) * 100 + msecs * 1000;
 }
 
 #define SET_STR_METADATA(pb, name, str) do { \
-- 
2.16.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCHv2 1/4] avformat/concatdec: always allow seeking to start

[Marton Balint]

Signed-off-by: Marton Balint 
---
 libavformat/concatdec.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index bbe13136fa..3ed95a4538 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -692,6 +692,13 @@ static int real_seek(AVFormatContext *avf, int stream,
 
 left  = 0;
 right = cat->nb_files;
+
+/* Always support seek to start */
+if (ts <= 0)
+right = 1;
+else if (!cat->seekable)
+return AVERROR(ESPIPE); /* XXX: can we use it? */
+
 while (right - left > 1) {
 int mid = (left + right) / 2;
 if (ts < cat->files[mid].start_time)
@@ -728,8 +735,6 @@ static int concat_seek(AVFormatContext *avf, int stream,
 AVFormatContext *cur_avf_saved = cat->avf;
 int ret;
 
-if (!cat->seekable)
-return AVERROR(ESPIPE); /* XXX: can we use it? */
 if (flags & (AVSEEK_FLAG_BYTE | AVSEEK_FLAG_FRAME))
 return AVERROR(ENOSYS);
 cat->avf = NULL;
-- 
2.16.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] GCC 8.2.0 compiler-warnings on ffmpeg-N-92765-g2744d6b

[Carl Eugen Hoyos]

2018-12-23 0:58 GMT+01:00, Reino Wijnsma :

> I can't code in C, so to still contribute to this project I'd like to report
> the warnings I got while compiling ffmpeg-N-92765-g2744d6b

All developers see these warnings, no reason to report them.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavf/vividas: Support demuxing on big-endian hardware

[Carl Eugen Hoyos]

Hi!

Attached patch fixes demuxing vividas on big-endian hardware.

Please comment, Carl Eugen
From 283fbd058772b40848eae48191d1d5faa5b543d5 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 23 Dec 2018 01:34:55 +0100
Subject: [PATCH] lavf/vividas: Support demuxing on big-endian hardware.

---
 libavformat/vividas.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/vividas.c b/libavformat/vividas.c
index e199b05..9be48bb 100644
--- a/libavformat/vividas.c
+++ b/libavformat/vividas.c
@@ -130,7 +130,7 @@ static void xor_block(void *p1, void *p2, unsigned size, int key, unsigned *key_
 size >>= 2;
 
 while (size > 0) {
-*d2 = *d1 ^ k;
+*d2 = *d1 ^ (HAVE_BIGENDIAN ? av_bswap32(k) : k);
 k += key;
 d1++;
 d2++;
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avformat/hls.c: Fix memory leak

[Steven Liu]

Valery Kot  于2018年12月22日周六 下午10:54写道：
>
> Ping...
> Any maintainer willing to review/push straightforward one-liner patch?
>
> > Thus 59MB leak in an hour! And keeps growing...

Testing.
will response after one or two days, you can attention the comment by Derek,


Thanks Valery


Steven
>
> ___
> 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