Re: [FFmpeg-devel] [PATCH v1 1/1] vaapi_hevc: Fix double-free issue.
> -Original Message- > From: Fu, Linjie > Sent: 2019年3月21日 20:20 > To: FFmpeg development discussions and patches > > Cc: Yan, FengX ; Lin, Decai > Subject: RE: [FFmpeg-devel] [PATCH v1 1/1] vaapi_hevc: Fix double-free > issue. > > > -Original Message- > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > > Of Decai Lin > > Sent: Thursday, March 21, 2019 17:30 > > To: ffmpeg-devel@ffmpeg.org > > Cc: Yan, FengX ; Lin, Decai > > Subject: [FFmpeg-devel] [PATCH v1 1/1] vaapi_hevc: Fix double-free issue. > > > > From: "Yan, FengX" > > > > Signed-off-by: Yan, FengX > > Signed-off-by: Decai Lin > > --- > > libavcodec/vaapi_hevc.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c index > > 19aabcd..373ffc4 100644 > > --- a/libavcodec/vaapi_hevc.c > > +++ b/libavcodec/vaapi_hevc.c > > @@ -271,7 +271,7 @@ static int vaapi_hevc_end_frame(AVCodecContext > > *avctx) > > > > ret = ff_vaapi_decode_issue(avctx, &pic->pic); > > if (ret < 0) > > -goto fail; > > +return ret; > > > > return 0; > > fail: > > I believe this should match the behavior in vaapi_h264/mpeg4/.../vc1.c, and > remove the redundant ff_vaapi_decode_cancel in vaapi_hevc_end_frame(). > > --Linjie Hello Linjie, there is little different between vaapi_hevc and other vaapi codecs. vaapi_hevc has an extra code block to handle slice buffer before ff_vaapi_decode_issue() , and if it's failed to handle, the buffers have to be destroyed separately. So the calling of ff_vaapi_decode_cancel() here is a must for hevc. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v9 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper
Friday, March 22, 2019 7:52 AM, Carl Eugen:
> +if (avctx->pix_fmt == AV_PIX_FMT_YUV420P10LE) {
> +av_log(avctx, AV_LOG_DEBUG , "Encoder 10 bits depth
> + input\n");
> +
> +// Encoding the source frames of the compressed 10-bit format
> +// supported by SVT-HEVC requires an extra conversion operation
> +// from yuv420p10le to that format. Disable it for now in ffmpeg.
>Sorry for the misunderstanding:
>What happens now (with this patch) if the user provides AV_PIX_FMT_YUV420P10LE
>to this FFmpeg encoder?
>And what should ideally happen?
It works fine functionally. And we will save the extra step's cost time a
little after we figures out how to and where to add the compressed format
support in ffmpeg later.
> +
> +param->compressedTenBitFormat = 0;
> +ten_bits = 1;
> +}
>Why doesn't this block set param->encoderBitDepth?
Modified. Thanks for the good catch.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with
subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v9 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper
Signed-off-by: Zhengxu Huang
Signed-off-by: Hassene Tmar
Signed-off-by: Jun Zhao
Signed-off-by: Jing Sun
---
configure| 4 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/libsvt_hevc.c | 501 +++
4 files changed, 507 insertions(+)
create mode 100644 libavcodec/libsvt_hevc.c
diff --git a/configure b/configure
index 938ff10..2aabac4 100755
--- a/configure
+++ b/configure
@@ -264,6 +264,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]
@@ -1784,6 +1785,7 @@ EXTERNAL_LIBRARY_LIST="
libspeex
libsrt
libssh
+libsvthevc
libtensorflow
libtesseract
libtheora
@@ -3173,6 +3175,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"
@@ -6209,6 +6212,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 15c43a8..c93e545 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -987,6 +987,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 b26aeca..e93f66f 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -703,6 +703,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..819979a
--- /dev/null
+++ b/libavcodec/libsvt_hevc.c
@@ -0,0 +1,501 @@
+/*
+* 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"
+
+typedef enum eos_status {
+EOS_NOT_REACHED = 0,
+EOS_REACHED,
+EOS_TOTRIGGER
+}EOS_STATUS;
+
+typedef struct SvtContext {
+AVClass *class;
+
+EB_H265_ENC_CONFIGURATION enc_params;
+EB_COMPONENTTYPE *svt_handle;
+EB_BUFFERHEADERTYPE in_buf;
+EOS_STATUS eos_flag;
+
+// User options.
+int vui_info;
+
Re: [FFmpeg-devel] [PATCH v7] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.
On Thu, Mar 21, 2019 at 11:09:21AM -0400, Shaofei Wang wrote: > It enabled MULTIPLE SIMPLE filter graph concurrency, which bring above about > 4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration > > Below are some test cases and comparison as reference. > (Hardware platform: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz) > (Software: Intel iHD driver - 16.9.00100, CentOS 7) > > For 1:N transcode by GPU acceleration with vaapi: > ./ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi \ > -hwaccel_output_format vaapi \ > -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \ > -vf "scale_vaapi=1280:720" -c:v h264_vaapi -f null /dev/null \ > -vf "scale_vaapi=720:480" -c:v h264_vaapi -f null /dev/null > > test results: > 2 encoders 5 encoders 10 encoders > Improved 6.1%6.9% 5.5% > > For 1:N transcode by GPU acceleration with QSV: > ./ffmpeg -hwaccel qsv -c:v h264_qsv \ > -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \ > -vf "scale_qsv=1280:720:format=nv12" -c:v h264_qsv -f null /dev/null \ > -vf "scale_qsv=720:480:format=nv12" -c:v h264_qsv -f null /dev/null > > test results: > 2 encoders 5 encoders 10 encoders > Improved 6% 4% 15% > > For Intel GPU acceleration case, 1 decode to N scaling, by QSV: > ./ffmpeg -hwaccel qsv -c:v h264_qsv \ > -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \ > -vf "scale_qsv=1280:720:format=nv12,hwdownload" -pix_fmt nv12 -f null > /dev/null \ > -vf "scale_qsv=720:480:format=nv12,hwdownload" -pix_fmt nv12 -f null > /dev/null > > test results: > 2 scale 5 scale 10 scale > Improved 12% 21%21% > > For CPU only 1 decode to N scaling: > ./ffmpeg -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \ > -vf "scale=1280:720" -pix_fmt nv12 -f null /dev/null \ > -vf "scale=720:480" -pix_fmt nv12 -f null /dev/null > > test results: > 2 scale 5 scale 10 scale > Improved 25%107% 148% > > Signed-off-by: Wang, Shaofei > Reviewed-by: Michael Niedermayer > Reviewed-by: Mark Thompson > --- > The patch will only effect on multiple SIMPLE filter graphs pipeline, > Passed fate and refine the possible data race, > AFL tested, without introducing extra crashs/hangs: > > american fuzzy lop 2.52b (ffmpeg_g) > > ┌─ process timing ─┬─ overall results > ─┐ > │run time : 0 days, 9 hrs, 48 min, 48 sec │ cycles done : 0 > │ > │ last new path : 0 days, 0 hrs, 0 min, 0 sec│ total paths : > 1866 │ > │ last uniq crash : none seen yet │ uniq crashes : 0 > │ > │ last uniq hang : 0 days, 9 hrs, 19 min, 23 sec │ uniq hangs : > 35 │ > ├─ cycle progress ┬─ map coverage > ─┴───┤ > │ now processing : 0 (0.00%) │map density : 24.91% / 36.60% > │ > │ paths timed out : 0 (0.00%) │ count coverage : 2.40 bits/tuple > │ > ├─ stage progress ┼─ findings in depth > ┤ > │ now trying : calibration │ favored paths : 1 (0.05%) > │ > │ stage execs : 0/8 (0.00%) │ new edges on : 1100 (58.95%) > │ > │ total execs : 123k │ total crashes : 0 (0 unique) > │ > │ exec speed : 3.50/sec (...)│ total tmouts : 52 (47 unique) > │ > ├─ fuzzing strategy yields ───┴───┬─ path geometry > ┤ > │ bit flips : 0/0, 0/0, 0/0 │levels : 2 > │ > │ byte flips : 0/0, 0/0, 0/0 │ pending : 1866 > │ > │ arithmetics : 0/0, 0/0, 0/0 │ pend fav : 1 > │ > │ known ints : 0/0, 0/0, 0/0 │ own finds : 1862 > │ > │ dictionary : 0/0, 0/0, 0/0 │ imported : n/a > │ > │ havoc : 0/0, 0/0 │ stability : > 76.69% │ > │trim : 0.00%/1828, n/a > ├┘ > └─┘ [cpu000: > 59%] > > fftools/ffmpeg.c | 172 > +-- > fftools/ffmpeg.h | 13 + > 2 files changed, 169 insertions(+), 16 deletions(-) This changes the output for some cases like: ./ffmpeg -y -i mm-short.mpg -flags +aic -qscale 2 -vcodec h263p -t 1 -qscale 10 old.avi -rw-r- 1 michael michael 86434 Mar 22 01:07 new.avi -rw-r- 1 michael michael 86402 Mar 22 01:07 old.avi i assume this is unintended [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "I am not trying to be anyone's saviour, I'm trying to think about the future an
[FFmpeg-devel] [PATCH v2] avformat/rtsp: Add https tunneling support
Add https based tunneling for RTSP/RTP. Tested on Axis and Bosch cameras.
Https is widely used for security consideration.
---
libavformat/rtsp.c | 8 ++--
libavformat/rtsp.h | 1 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index ae8811234a..4661654967 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -87,6 +87,7 @@ const AVOption ff_rtsp_options[] = {
{ "tcp", "TCP", 0, AV_OPT_TYPE_CONST, {.i64 = 1 <<
RTSP_LOWER_TRANSPORT_TCP}, 0, 0, DEC|ENC, "rtsp_transport" }, \
{ "udp_multicast", "UDP multicast", 0, AV_OPT_TYPE_CONST, {.i64 = 1 <<
RTSP_LOWER_TRANSPORT_UDP_MULTICAST}, 0, 0, DEC, "rtsp_transport" },
{ "http", "HTTP tunneling", 0, AV_OPT_TYPE_CONST, {.i64 = (1 <<
RTSP_LOWER_TRANSPORT_HTTP)}, 0, 0, DEC, "rtsp_transport" },
+{ "https", "HTTPS tunneling", 0, AV_OPT_TYPE_CONST, {.i64 = (1 <<
RTSP_LOWER_TRANSPORT_HTTPS )}, 0, 0, DEC, "rtsp_transport" },
RTSP_FLAG_OPTS("rtsp_flags", "set RTSP flags"),
{ "listen", "wait for incoming connections", 0, AV_OPT_TYPE_CONST, {.i64 =
RTSP_FLAG_LISTEN}, 0, 0, DEC, "rtsp_flags" },
{ "prefer_tcp", "try RTP via TCP first, if available", 0,
AV_OPT_TYPE_CONST, {.i64 = RTSP_FLAG_PREFER_TCP}, 0, 0, DEC|ENC, "rtsp_flags" },
@@ -1669,6 +1670,7 @@ int ff_rtsp_connect(AVFormatContext *s)
RTSPMessageHeader reply1, *reply = &reply1;
int lower_transport_mask = 0;
int default_port = RTSP_DEFAULT_PORT;
+int https_tunnel = 0;
char real_challenge[64] = "";
struct sockaddr_storage peer;
socklen_t peer_len = sizeof(peer);
@@ -1687,7 +1689,9 @@ int ff_rtsp_connect(AVFormatContext *s)
s->max_delay = s->iformat ? DEFAULT_REORDERING_DELAY : 0;
rt->control_transport = RTSP_MODE_PLAIN;
-if (rt->lower_transport_mask & (1 << RTSP_LOWER_TRANSPORT_HTTP)) {
+if (rt->lower_transport_mask & ((1 << RTSP_LOWER_TRANSPORT_HTTP) |
+(1 << RTSP_LOWER_TRANSPORT_HTTPS))) {
+https_tunnel = !!(rt->lower_transport_mask & (1 <<
RTSP_LOWER_TRANSPORT_HTTPS));
rt->lower_transport_mask = 1 << RTSP_LOWER_TRANSPORT_TCP;
rt->control_transport = RTSP_MODE_TUNNEL;
}
@@ -1741,7 +1745,7 @@ redirect:
char sessioncookie[17];
char headers[1024];
-ff_url_join(httpname, sizeof(httpname), "http", auth, host, port,
"%s", path);
+ff_url_join(httpname, sizeof(httpname), https_tunnel ? "https" :
"http", auth, host, port, "%s", path);
snprintf(sessioncookie, sizeof(sessioncookie), "%08x%08x",
av_get_random_seed(), av_get_random_seed());
diff --git a/libavformat/rtsp.h b/libavformat/rtsp.h
index 9a7f366b39..b49278fc20 100644
--- a/libavformat/rtsp.h
+++ b/libavformat/rtsp.h
@@ -42,6 +42,7 @@ enum RTSPLowerTransport {
RTSP_LOWER_TRANSPORT_HTTP = 8, /**< HTTP tunneled - not a proper
transport mode as such,
only for use via AVOptions */
+RTSP_LOWER_TRANSPORT_HTTPS, /**< HTTPS tunneled */
RTSP_LOWER_TRANSPORT_CUSTOM = 16, /**< Custom IO - not a public
option for
lower_transport_mask,
but set in the SDP demuxer
based
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v9 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper
2019-03-21 5:10 GMT+01:00, Jing Sun :
> +if (avctx->pix_fmt == AV_PIX_FMT_YUV420P10LE) {
> +av_log(avctx, AV_LOG_DEBUG , "Encoder 10 bits depth input\n");
> +
> +// Encoding the source frames of the compressed 10-bit format
> +// supported by SVT-HEVC requires an extra conversion operation
> +// from yuv420p10le to that format. Disable it for now in ffmpeg.
Sorry for the misunderstanding:
What happens now (with this patch) if the user provides
AV_PIX_FMT_YUV420P10LE to this FFmpeg encoder?
And what should ideally happen?
> +
> +param->compressedTenBitFormat = 0;
> +ten_bits = 1;
> +}
Why doesn't this block set param->encoderBitDepth?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1 2/2] avformat/rtsp.h: Add https tunneling support for RTSP
On Thu, Mar 21, 2019 at 3:59 PM Carl Eugen Hoyos wrote:
> 2019-03-21 23:24 GMT+01:00, Jun Li :
> > Add new enum for RTSP/RTP HTTPS tunneling. Tested on Axis and
> > Bosch cameras.
> > ---
> > libavformat/rtsp.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/rtsp.h b/libavformat/rtsp.h
> > index 9a7f366b39..b49278fc20 100644
> > --- a/libavformat/rtsp.h
> > +++ b/libavformat/rtsp.h
> > @@ -42,6 +42,7 @@ enum RTSPLowerTransport {
> > RTSP_LOWER_TRANSPORT_HTTP = 8, /**< HTTP tunneled - not a
> > proper
> > transport mode as such,
> > only for use via
> AVOptions
> > */
> > +RTSP_LOWER_TRANSPORT_HTTPS, /**< HTTPS tunneled */
>
> You cannot use the define that you add in patch 2/2 already
> in an earlier patch.
>
> Please merge the patches, thank you, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Thanks Carl. I thought every patch should only contain single file change.
So here do I need to switch the 2 commits order, or merge two file changes
into one patch ?
Thanks.
Best Regards,
-Jun
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1 2/2] avformat/rtsp.h: Add https tunneling support for RTSP
2019-03-21 23:24 GMT+01:00, Jun Li :
> Add new enum for RTSP/RTP HTTPS tunneling. Tested on Axis and
> Bosch cameras.
> ---
> libavformat/rtsp.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/rtsp.h b/libavformat/rtsp.h
> index 9a7f366b39..b49278fc20 100644
> --- a/libavformat/rtsp.h
> +++ b/libavformat/rtsp.h
> @@ -42,6 +42,7 @@ enum RTSPLowerTransport {
> RTSP_LOWER_TRANSPORT_HTTP = 8, /**< HTTP tunneled - not a
> proper
> transport mode as such,
> only for use via AVOptions
> */
> +RTSP_LOWER_TRANSPORT_HTTPS, /**< HTTPS tunneled */
You cannot use the define that you add in patch 2/2 already
in an earlier patch.
Please merge the patches, thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] avcodec/proresenc (aw and ks) : use correct bitstream version in frame header
On 3/21/19, James Almer wrote: > On 3/21/2019 5:33 PM, Paul B Mahol wrote: >> On 3/16/19, Martin Vignali wrote: >>> Hello >>> >>> Patch in attach change bitstream version in prores frame header >>> (based on RDD36) >>> 0 for 422 >>> 1 for 444 with ou without alpha >>> >>> 001 : Fix for prores_aw (update 444 fate test) >>> 002 : Fix for prores_ks (no fate update because 444 is not tested for ks >>> encoder) >>> >>> Pass fate for me (x86_64 macos) >>> >>> Martin >>> >> >> Very nice of you committing patch without review. > > I don't know what you're talking about, because he didn't commit this patch. > > And there are nicer ways to show disapproval. I'm very nice, but this way anybody can commit any statements in logs. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavd/v4l2: Return FFERROR_REDO when receiving a frame of unexpected size
Hi Marton, hi Nicolas! On 2019-03-21 10:07 +0100, Nicolas George wrote: > Marton Balint (12019-03-21): > > Maybe just set the packet corrupt flag and log an error, but return the > > partial buffer? > > I think it may be the best solution. But it would be interesting to know > how the tools react to it. I agree that it might be the most sophisticated solution. But it is not so clear how this would work out with ffmpeg and all other client apps. It might also be more tricky/involved to implement correctly. Personally I don't want to invest much more time into this ATM. I would really like to achieve to prevent aborting the capture in case of a frame once in a while being returned too short. I believe it would be a big win that can hopefully be implemented without causing harm. After considering the 3 variants I have implemented so far I am now at the following conclusion: 1. Return AVERROR(EAGAIN) => this is not an option because it is not expected when using blocking mode 2. Return FFERROR_REDO => this could be used, but has the not completely unlikely downside to not return to the caller for a very long time. That is in the case the driver starts emitting too short frames in a row for a long time. 3. Return zero-sized packets => This works and is consistent with how we handle frames flagged to be corrupted (V4L2_BUF_FLAG_ERROR). See commit 28f20d2ff487aa589643d8f70eaf614b78839685 . Choosing from the above 3 options, IMHO 3 is the best. If someone decides to improve it at a later point, one could improve the V4L2_BUF_FLAG_ERROR case too. Do you think that going with 3 now is fine? If yes I would send that patch for review. Thanks for your comments! Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v1 1/2] avformat/rtsp.c: Add https tunneling support
Add https based tunneling for RTSP/RTP. Tested on Axis and Bosch cameras.
Https is widely used for security consideration.
---
libavformat/rtsp.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index ae8811234a..4661654967 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -87,6 +87,7 @@ const AVOption ff_rtsp_options[] = {
{ "tcp", "TCP", 0, AV_OPT_TYPE_CONST, {.i64 = 1 <<
RTSP_LOWER_TRANSPORT_TCP}, 0, 0, DEC|ENC, "rtsp_transport" }, \
{ "udp_multicast", "UDP multicast", 0, AV_OPT_TYPE_CONST, {.i64 = 1 <<
RTSP_LOWER_TRANSPORT_UDP_MULTICAST}, 0, 0, DEC, "rtsp_transport" },
{ "http", "HTTP tunneling", 0, AV_OPT_TYPE_CONST, {.i64 = (1 <<
RTSP_LOWER_TRANSPORT_HTTP)}, 0, 0, DEC, "rtsp_transport" },
+{ "https", "HTTPS tunneling", 0, AV_OPT_TYPE_CONST, {.i64 = (1 <<
RTSP_LOWER_TRANSPORT_HTTPS )}, 0, 0, DEC, "rtsp_transport" },
RTSP_FLAG_OPTS("rtsp_flags", "set RTSP flags"),
{ "listen", "wait for incoming connections", 0, AV_OPT_TYPE_CONST, {.i64 =
RTSP_FLAG_LISTEN}, 0, 0, DEC, "rtsp_flags" },
{ "prefer_tcp", "try RTP via TCP first, if available", 0,
AV_OPT_TYPE_CONST, {.i64 = RTSP_FLAG_PREFER_TCP}, 0, 0, DEC|ENC, "rtsp_flags" },
@@ -1669,6 +1670,7 @@ int ff_rtsp_connect(AVFormatContext *s)
RTSPMessageHeader reply1, *reply = &reply1;
int lower_transport_mask = 0;
int default_port = RTSP_DEFAULT_PORT;
+int https_tunnel = 0;
char real_challenge[64] = "";
struct sockaddr_storage peer;
socklen_t peer_len = sizeof(peer);
@@ -1687,7 +1689,9 @@ int ff_rtsp_connect(AVFormatContext *s)
s->max_delay = s->iformat ? DEFAULT_REORDERING_DELAY : 0;
rt->control_transport = RTSP_MODE_PLAIN;
-if (rt->lower_transport_mask & (1 << RTSP_LOWER_TRANSPORT_HTTP)) {
+if (rt->lower_transport_mask & ((1 << RTSP_LOWER_TRANSPORT_HTTP) |
+(1 << RTSP_LOWER_TRANSPORT_HTTPS))) {
+https_tunnel = !!(rt->lower_transport_mask & (1 <<
RTSP_LOWER_TRANSPORT_HTTPS));
rt->lower_transport_mask = 1 << RTSP_LOWER_TRANSPORT_TCP;
rt->control_transport = RTSP_MODE_TUNNEL;
}
@@ -1741,7 +1745,7 @@ redirect:
char sessioncookie[17];
char headers[1024];
-ff_url_join(httpname, sizeof(httpname), "http", auth, host, port,
"%s", path);
+ff_url_join(httpname, sizeof(httpname), https_tunnel ? "https" :
"http", auth, host, port, "%s", path);
snprintf(sessioncookie, sizeof(sessioncookie), "%08x%08x",
av_get_random_seed(), av_get_random_seed());
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v1 2/2] avformat/rtsp.h: Add https tunneling support for RTSP
Add new enum for RTSP/RTP HTTPS tunneling. Tested on Axis and
Bosch cameras.
---
libavformat/rtsp.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/rtsp.h b/libavformat/rtsp.h
index 9a7f366b39..b49278fc20 100644
--- a/libavformat/rtsp.h
+++ b/libavformat/rtsp.h
@@ -42,6 +42,7 @@ enum RTSPLowerTransport {
RTSP_LOWER_TRANSPORT_HTTP = 8, /**< HTTP tunneled - not a proper
transport mode as such,
only for use via AVOptions */
+RTSP_LOWER_TRANSPORT_HTTPS, /**< HTTPS tunneled */
RTSP_LOWER_TRANSPORT_CUSTOM = 16, /**< Custom IO - not a public
option for
lower_transport_mask,
but set in the SDP demuxer
based
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/flvdec: added support for KUX container
2019-03-21 21:41 GMT+01:00, Swaraj Hota : > The title is in unicode so I guess we can just encode it to utf8. > I can write a simple C code to do that. > What should I change in the patch though regarding this? > Can you give me more details on what exactly to implement? There is metadata in FFmpeg, for example the tag "title" is known and shown by "ffmpeg -i". You can use av_dict_set() (as done elsewhere in flvdec.c) to set the tag "title" to whatever is in the unicode block we both see. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCHv2] FATE: Add test for HEVC files that claim to have two first slices
2019-03-21 16:33 GMT+01:00, Derek Buitenhuis : > On 21/03/2019 15:29, Derek Buitenhuis wrote: >> Definitely sure it's covered within this command, and file's number of >> packets. >> >> Easy to verify: Run the fate test with your patch reverted, and it >> deadlocks. > > Scratch that. I was mistaken, it doesn't work with the trimmed file... I tested the following again: $ dd if=nal_header_deadlock.mp4 of=nal_header_deadlock_cut.mp4 bs=100k count=5 $ md5sum nal_header_deadlock_cut.mp4 58b637d5500c2911d8cfe99fee86cb04 nal_header_deadlock_cut.mp4 This file hangs with 3ac474892, the last commit before James's fix. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] mxf file support
tor 2019-03-21 klockan 18:48 + skrev Yufei He: > Hi > > It seems FFmpeg supports reading all kinds of mxf files from Sony and > Panasonics. it's very good to find that FFmpeg can support Sony XAVC > QuadHD files and find the essence data is actually H.264. > > Our customers have a lot of high data rate mxf files from Sony and > Panasonics. They need transcode those files to streaming files like > .ts,.mp4, etc. Here it sounds like you you want to demux Sony XAVC MXFs.. > Does FFmpeg supports writing Sony XAVC mxf files ? and here it sounds like you want to mux them. It's certainly possible to ape whatever peculiaritites Sony has for its MXF muxer, I've done similar things with MXF in the past. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCHv3] FATE: Add test for HEVC files that claim to have two first slices
On 3/21/2019 6:30 PM, Michael Niedermayer wrote: > On Thu, Mar 21, 2019 at 01:19:48PM -0300, James Almer wrote: >> On 3/21/2019 12:38 PM, Derek Buitenhuis wrote: >>> This makes sure we don't regress on >>> 70c8c8a818f39bc262565ec29fae2baffb3e1660. >>> >>> Signed-off-by: Derek Buitenhuis >>> --- >>> Same sample link as v2. >> >> Tried to upload it, but i'm still having the same issues as last time. >> Someone else will have to. > > hmm, was that rsync specific ? if so you could login and wget the file > > about this specific file, > derek should have write access to samples as well No, i tried to ssh to the main repo, a test dry run push, and it gave me the same error as ssh rsync did a couple months ago. This is within an Arch Linux VM, freshly rebuilt and all. I can ssh just fine from my native Windows host, so I don't know if it's a configuration issue, VMWare or what, but the remote server simply doesn't like the connections i try to establish. Guess i'll have to see if i can use msys2's rsync for this without making a mess. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCHv3] FATE: Add test for HEVC files that claim to have two first slices
On Thu, Mar 21, 2019 at 01:19:48PM -0300, James Almer wrote: > On 3/21/2019 12:38 PM, Derek Buitenhuis wrote: > > This makes sure we don't regress on > > 70c8c8a818f39bc262565ec29fae2baffb3e1660. > > > > Signed-off-by: Derek Buitenhuis > > --- > > Same sample link as v2. > > Tried to upload it, but i'm still having the same issues as last time. > Someone else will have to. hmm, was that rsync specific ? if so you could login and wget the file about this specific file, derek should have write access to samples as well [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/flvdec: added support for KUX container
The title is in unicode so I guess we can just encode it to utf8. I can write a simple C code to do that. What should I change in the patch though regarding this? Can you give me more details on what exactly to implement? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] avcodec/proresenc (aw and ks) : use correct bitstream version in frame header
On 3/21/2019 5:33 PM, Paul B Mahol wrote: > On 3/16/19, Martin Vignali wrote: >> Hello >> >> Patch in attach change bitstream version in prores frame header >> (based on RDD36) >> 0 for 422 >> 1 for 444 with ou without alpha >> >> 001 : Fix for prores_aw (update 444 fate test) >> 002 : Fix for prores_ks (no fate update because 444 is not tested for ks >> encoder) >> >> Pass fate for me (x86_64 macos) >> >> Martin >> > > Very nice of you committing patch without review. I don't know what you're talking about, because he didn't commit this patch. And there are nicer ways to show disapproval. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] avcodec/proresenc (aw and ks) : use correct bitstream version in frame header
On 3/16/19, Martin Vignali wrote: > Hello > > Patch in attach change bitstream version in prores frame header > (based on RDD36) > 0 for 422 > 1 for 444 with ou without alpha > > 001 : Fix for prores_aw (update 444 fate test) > 002 : Fix for prores_ks (no fate update because 444 is not tested for ks > encoder) > > Pass fate for me (x86_64 macos) > > Martin > Very nice of you committing patch without review. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] mxf file support
Hi It seems FFmpeg supports reading all kinds of mxf files from Sony and Panasonics. it's very good to find that FFmpeg can support Sony XAVC QuadHD files and find the essence data is actually H.264. Our customers have a lot of high data rate mxf files from Sony and Panasonics. They need transcode those files to streaming files like .ts,.mp4, etc. Does FFmpeg supports writing Sony XAVC mxf files ? Thanks. Yufei. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/cbs_av1: fix range of values for Mastering Display Color Volume Metadata OBUs
Signed-off-by: James Almer
---
libavcodec/cbs_av1_syntax_template.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/cbs_av1_syntax_template.c
b/libavcodec/cbs_av1_syntax_template.c
index 48f4fab514..93bba1e5ad 100644
--- a/libavcodec/cbs_av1_syntax_template.c
+++ b/libavcodec/cbs_av1_syntax_template.c
@@ -1637,15 +1637,15 @@ static int
FUNC(metadata_hdr_mdcv)(CodedBitstreamContext *ctx, RWContext *rw,
int err, i;
for (i = 0; i < 3; i++) {
-fcs(16, primary_chromaticity_x[i], 0, 5, 1, i);
-fcs(16, primary_chromaticity_y[i], 0, 5, 1, i);
+fbs(16, primary_chromaticity_x[i], 1, i);
+fbs(16, primary_chromaticity_y[i], 1, i);
}
-fc(16, white_point_chromaticity_x, 0, 5);
-fc(16, white_point_chromaticity_y, 0, 5);
+fb(16, white_point_chromaticity_x);
+fb(16, white_point_chromaticity_y);
fc(32, luminance_max, 1, MAX_UINT_BITS(32));
-fc(32, luminance_min, 0, current->luminance_max >> 6);
+fc(32, luminance_min, 0, (current->luminance_max << 6) - 1);
return 0;
}
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] aac variable encoding
Hi On transcoding from 1080p .ts files to .mp4 files with my m264 codec, audio of the output .mp4 files stutters. We found audio of the stuttering files is vbr. I did not set aac encoding bitrate. somehow it becomes vbr when I use my m264 codec on transcoding 1080p files. It works well for 1080i .ts files and all .mp4 and .mov files, and aac audio of the output files is cbr. So the problem is why aac encoding becomes vbr. Command I use is: ./ffmpeg -i TS/TSv2m2641080p30mcbr.ts -vsync 0 -vcodec m264 -b:v 10M 8_ff.mp4 Thanks. Yufei. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3] FATE: Add test for HEVC files that claim to have two first slices
On 21/03/2019 16:19, James Almer wrote: > FATE_HEVC-$(call DEMDEC, MOV, HEVC) Changed locally. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3] FATE: Add test for HEVC files that claim to have two first slices
On 3/21/2019 12:38 PM, Derek Buitenhuis wrote: > This makes sure we don't regress on 70c8c8a818f39bc262565ec29fae2baffb3e1660. > > Signed-off-by: Derek Buitenhuis > --- > Same sample link as v2. Tried to upload it, but i'm still having the same issues as last time. Someone else will have to. > > Also of note: I'm only adding the -t arg because FATE doesn't seem to have > a good way to allow ffmpeg to return a non-zero error code, but also have > the test pass. > --- > tests/fate/hevc.mak | 3 +++ > tests/ref/fate/hevc-two-first-slice | 39 + > 2 files changed, 42 insertions(+) > create mode 100644 tests/ref/fate/hevc-two-first-slice > > diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak > index db3ea19340..8f9ed6d925 100644 > --- a/tests/fate/hevc.mak > +++ b/tests/fate/hevc.mak > @@ -253,6 +253,9 @@ fate-hevc-extradata-reload: CMD = framemd5 -i > $(TARGET_SAMPLES)/hevc/extradata-r > fate-hevc-monochrome-crop: CMD = probeframes -show_entries > frame=width,height:stream=width,height > $(TARGET_SAMPLES)/hevc/hevc-monochrome.hevc > FATE_HEVC_FFPROBE-$(call DEMDEC, HEVC, HEVC) += fate-hevc-monochrome-crop > > +fate-hevc-two-first-slice: CMD = threads=2 framemd5 -i > $(TARGET_SAMPLES)/hevc/two_first_slice.mp4 -sws_flags bitexact -t 00:02.00 -an > +FATE_HEVC += fate-hevc-two-first-slice FATE_HEVC-$(call DEMDEC, MOV, HEVC) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] FATE: Add test for HEVC files that claim to have two first slices
On 21/03/2019 15:29, Derek Buitenhuis wrote: > Definitely sure it's covered within this command, and file's number of > packets. > > Easy to verify: Run the fate test with your patch reverted, and it deadlocks. Scratch that. I was mistaken, it doesn't work with the trimmed file... Re-testing, and re-sending. Also had two lines staged but not amended... woops. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv3] FATE: Add test for HEVC files that claim to have two first slices
This makes sure we don't regress on 70c8c8a818f39bc262565ec29fae2baffb3e1660. Signed-off-by: Derek Buitenhuis --- Same sample link as v2. Also of note: I'm only adding the -t arg because FATE doesn't seem to have a good way to allow ffmpeg to return a non-zero error code, but also have the test pass. --- tests/fate/hevc.mak | 3 +++ tests/ref/fate/hevc-two-first-slice | 39 + 2 files changed, 42 insertions(+) create mode 100644 tests/ref/fate/hevc-two-first-slice diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak index db3ea19340..8f9ed6d925 100644 --- a/tests/fate/hevc.mak +++ b/tests/fate/hevc.mak @@ -253,6 +253,9 @@ fate-hevc-extradata-reload: CMD = framemd5 -i $(TARGET_SAMPLES)/hevc/extradata-r fate-hevc-monochrome-crop: CMD = probeframes -show_entries frame=width,height:stream=width,height $(TARGET_SAMPLES)/hevc/hevc-monochrome.hevc FATE_HEVC_FFPROBE-$(call DEMDEC, HEVC, HEVC) += fate-hevc-monochrome-crop +fate-hevc-two-first-slice: CMD = threads=2 framemd5 -i $(TARGET_SAMPLES)/hevc/two_first_slice.mp4 -sws_flags bitexact -t 00:02.00 -an +FATE_HEVC += fate-hevc-two-first-slice + FATE_SAMPLES_AVCONV += $(FATE_HEVC-yes) FATE_SAMPLES_FFPROBE += $(FATE_HEVC_FFPROBE-yes) diff --git a/tests/ref/fate/hevc-two-first-slice b/tests/ref/fate/hevc-two-first-slice new file mode 100644 index 00..586b8ef5c3 --- /dev/null +++ b/tests/ref/fate/hevc-two-first-slice @@ -0,0 +1,39 @@ +#format: frame checksums +#version: 2 +#hash: MD5 +#tb 0: 1/15 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 1920x1080 +#sar 0: 0/1 +#stream#, dts,pts, duration, size, hash +0, 0, 0,1, 3110400, c88154281ada839d3f209b0eab012577 +0, 1, 1,1, 3110400, a2623ba4639cf246b803c08e7233112f +0, 2, 2,1, 3110400, 9208fcdb16664e91ada77d15cc29ace9 +0, 3, 3,1, 3110400, 62a5afb0c4d189b831c8cca033a396e0 +0, 4, 4,1, 3110400, a8f208f1323e9c14181549d480055e3c +0, 5, 5,1, 3110400, 3a66c0ab75362a73eebb9ef668bee3da +0, 6, 6,1, 3110400, 8096734441fe76d8f7bba8384029b1be +0, 7, 7,1, 3110400, ee8db0610de85f015ec76a0c14475ab8 +0, 8, 8,1, 3110400, f52df359246a4ac396dfc74f75285347 +0, 9, 9,1, 3110400, 8fb6ddd74e4b71c7596e90d47e50d8f1 +0, 10, 10,1, 3110400, 70542a3ac5df77437c3d8097d19315c2 +0, 11, 11,1, 3110400, 20bdf9399f6752578c574248627c3a9f +0, 12, 12,1, 3110400, a8b564575af5d72a2cc6d566e99e0176 +0, 13, 13,1, 3110400, 0d4ace74eb6b452ea9cb2cc72371794a +0, 14, 14,1, 3110400, d9736a1e47da6541306cbf8496d97635 +0, 15, 15,1, 3110400, 49bc2b608000c7d545fa362418035277 +0, 16, 16,1, 3110400, bd64e9d545c666f818ea1af791ac4201 +0, 17, 17,1, 3110400, 75b86260724937fdeddf47e1f28530a1 +0, 18, 18,1, 3110400, 7df76be996e2c652da048e690e45313f +0, 19, 19,1, 3110400, 057b9a27f76c9205fe7f378c7e4fe1b4 +0, 20, 20,1, 3110400, 08241ea9c8d27bd14117ca07485a9892 +0, 21, 21,1, 3110400, 7d5f4d4e043d6f3e794d1222046cb9cf +0, 22, 22,1, 3110400, dfb6916da415ff5323a1925cc329c8e2 +0, 23, 23,1, 3110400, 574730243f89b4824a313ea1b690e31b +0, 24, 24,1, 3110400, 63054e31f52171dda84faa201523dc3b +0, 25, 25,1, 3110400, d8ba349a9a5a6f38527e47f5519fd335 +0, 26, 26,1, 3110400, e653543eb8a8a49147676a91bafbdec8 +0, 27, 27,1, 3110400, b3194aced03ff1bc4d65560792eeab98 +0, 28, 28,1, 3110400, 6ba07b8fd8422b3c14976062f5468fab +0, 29, 29,1, 3110400, bf8359596ddfd9fdbc243fc2fee56669 -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] FATE: Add test for HEVC files that claim to have two first slices
On 21/03/2019 15:26, James Almer wrote: > Are you sure the faulty packet is the third one? When i debugged this > the one that reproduced the issue was the 31st. Or is this a cut sample > starting from the faulty RAP? Definitely sure it's covered within this command, and file's number of packets. Easy to verify: Run the fate test with your patch reverted, and it deadlocks. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] FATE: Add test for HEVC files that claim to have two first slices
On 3/21/2019 11:48 AM, Derek Buitenhuis wrote: > This makes sure we don't regress on 70c8c8a818f39bc262565ec29fae2baffb3e1660. > > Signed-off-by: Derek Buitenhuis > --- > Sample: http://chromashift.org/two_first_slice.mp4 (Trimmed to 500KiB like > Carl requested). > MD5: 58b637d5500c2911d8cfe99fee86cb04 > --- > tests/fate/hevc.mak | 3 +++ > tests/ref/fate/hevc-two-first-slice | 12 > 2 files changed, 15 insertions(+) > create mode 100644 tests/ref/fate/hevc-two-first-slice > > diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak > index db3ea19340..5ec6e279b9 100644 > --- a/tests/fate/hevc.mak > +++ b/tests/fate/hevc.mak > @@ -253,6 +253,9 @@ fate-hevc-extradata-reload: CMD = framemd5 -i > $(TARGET_SAMPLES)/hevc/extradata-r > fate-hevc-monochrome-crop: CMD = probeframes -show_entries > frame=width,height:stream=width,height > $(TARGET_SAMPLES)/hevc/hevc-monochrome.hevc > FATE_HEVC_FFPROBE-$(call DEMDEC, HEVC, HEVC) += fate-hevc-monochrome-crop > > +hevc-two-first-slice: CMD = threads=2 framemd5 -i > $(TARGET_SAMPLES)/hevc/two_first_slice.mp4 -sws_flags bitexact -t 00:00.20 -an > +FATE_HEVC += hevc-two-first-slice > + > FATE_SAMPLES_AVCONV += $(FATE_HEVC-yes) > FATE_SAMPLES_FFPROBE += $(FATE_HEVC_FFPROBE-yes) > > diff --git a/tests/ref/fate/hevc-two-first-slice > b/tests/ref/fate/hevc-two-first-slice > new file mode 100644 > index 00..8ce7a066c7 > --- /dev/null > +++ b/tests/ref/fate/hevc-two-first-slice > @@ -0,0 +1,12 @@ > +#format: frame checksums > +#version: 2 > +#hash: MD5 > +#tb 0: 1/15 > +#media_type 0: video > +#codec_id 0: rawvideo > +#dimensions 0: 1920x1080 > +#sar 0: 0/1 > +#stream#, dts,pts, duration, size, hash > +0, 0, 0,1, 3110400, > c88154281ada839d3f209b0eab012577 > +0, 1, 1,1, 3110400, > a2623ba4639cf246b803c08e7233112f > +0, 2, 2,1, 3110400, > 9208fcdb16664e91ada77d15cc29ace9 Are you sure the faulty packet is the third one? When i debugged this the one that reproduced the issue was the 31st. Or is this a cut sample starting from the faulty RAP? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Thu, 21 Mar 2019 at 18:17, Jean-Baptiste Kempf wrote: > > > On Thu, 21 Mar 2019, at 16:14, Ali KIZIL wrote: > > I think the source code itself doesn't violate GPL. It use an external > lib, > > just like drivers. > > Drivers have a GPL exception. > external libraries do not. > > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > > NewTek can only get off the hook by releasing their libraries under the GPL. The damage done prior cannot be reversed by a plain takedown of the infringing SDK version. What message does that send to these profiting off similar violations in the community? Abuse the GPL, get a slap on the wrist, rinse, wash and repeat? Based on prevailing factors surrounding this case, this is the most logical outcome. It's not necessarily fair, but its' logical. For these tilted by its' removal, fork FFmpeg, revert the commit and carry on, but let us avoid ad hominems. Be excellent to each other. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Thu, 21 Mar 2019 at 17:54, Maksym Veremeyenko wrote: > On 20.03.2019 22:13, Dennis Mungai wrote: > [...] > > The primary agitator here seems to be kierank: > > https://trac.ffmpeg.org/ticket/7589?cversion=0&cnum_hist=10#comment:5 > > > > What undisclosed history do you have with Newtek (see the reference to > > "Andrew") above that isn't disclosed above? > > Secondly, you're quite influential in the broadcast industry: > > https://www.obe.tv/author/obe/ > > > > There's an aura of hostility around this commit, and whatever that is > seems > > to have spilled over into this. > > dropping NDI from ffmpeg can make more efforts to > https://www.obe.tv/portfolio/interface-conversion/# ? > > -- > Maksym Veremeyenko > > > For all we know, (a). Kieran is an independent developer. Whatever history he may have with NDI is undisclosed. Whatever vendetta / ill intent he may hold against NDI still remains irrelevant to the breach of the GPL, as shown in (b). (b). Here's where NDI really nailed their fate in the coffin: >ffmpeg -L NewTek NDI Copyright (C)2015-2018 NewTek, inc. v3.7.1.0 ffmpeg version 4.0 Copyright (c) 2000-2018 the FFmpeg developers built with Microsoft (R) C/C++ Optimizing Compiler Version 18.00.40629 for x64 configuration: --toolchain=msvc --prefix=/d/Builds/User/Cary/ffmpeg/build --bindir=/d/Builds/User/Cary/ffmpeg/build/bin/x64/release --datadir=/d/Builds/User/Cary/ffmpeg/build/bin/x64/release/ffpresets --incdir=/d/Builds/User/Cary/ffmpeg/build/include --libdir=/d/Builds/User/Cary/ffmpeg/build/lib/x64/release --shlibdir=/d/Builds/User/Cary/ffmpeg/build/bin/x64/release --disable-shared --enable-static --disable-postproc --disable-ffplay --enable-debug --enable-optimizations --optflags='-O2 -Oy- -Oi' --extra-cflags='-GS -analyze- -Gy -Zc:wchar_t -Zc:forScope -Gm- -fp:precise -WX- -Gd -MD -EHsc -we4013 -DX264_API_IMPORTS' --extra-ldflags='-NXCOMPAT -DYNAMICBASE -DEBUG -OPT:REF -OPT:ICF ' --enable-zlib --enable-libmfx --enable-libndi_newtek --enable-nonfree --enable-libx264 --enable-gpl libavutil 56. 14.100 / 56. 14.100 libavcodec 58. 18.100 / 58. 18.100 libavformat58. 12.100 / 58. 12.100 libavdevice58. 3.100 / 58. 3.100 libavfilter 7. 16.100 / 7. 16.100 libswscale 5. 1.100 / 5. 1.100 libswresample 3. 1.100 / 3. 1.100 This version of ffmpeg has nonfree parts compiled in. Therefore it is not legally redistributable. This is their offending ticket: https://trac.ffmpeg.org/ticket/7589 It is self evident that Newtek sabotaged themselves here, and that counts against them. Kieran's actions cannot be construed as an extension of assumptions made in (a), but rather, maintenance duty. -Dennis. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Thu, 21 Mar 2019, at 16:14, Ali KIZIL wrote: > I think the source code itself doesn't violate GPL. It use an external lib, > just like drivers. Drivers have a GPL exception. external libraries do not. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Thu, Mar 21, 2019, 5:54 PM Maksym Veremeyenko wrote: > On 20.03.2019 22:13, Dennis Mungai wrote: > [...] > > The primary agitator here seems to be kierank: > > https://trac.ffmpeg.org/ticket/7589?cversion=0&cnum_hist=10#comment:5 > > > > What undisclosed history do you have with Newtek (see the reference to > > "Andrew") above that isn't disclosed above? > > Secondly, you're quite influential in the broadcast industry: > > https://www.obe.tv/author/obe/ > > > > There's an aura of hostility around this commit, and whatever that is > seems > > to have spilled over into this. > > dropping NDI from ffmpeg can make more efforts to > https://www.obe.tv/portfolio/interface-conversion/# ? > > -- > Maksym Veremeyenko > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel Unfortunately, I had the same feeling. I use NDI for SDI to/from IP conversation at contribution encoding against J2K at zero cost, which is also compatible with NDI equipments. I wasn't brave enough like Maksyn to spread the word. I think the source code itself doesn't violate GPL. It use an external lib, just like drivers. Newtek stopped distributing the binary. I don't understand how removing source code from FFmpeg repo punishes Newtek. It just discourage developers and took users out of notice for some days. Anyone can make an external repo with a patch to apply to use it back at a point where this removal is still under questioning. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On 20.03.2019 22:13, Dennis Mungai wrote: [...] The primary agitator here seems to be kierank: https://trac.ffmpeg.org/ticket/7589?cversion=0&cnum_hist=10#comment:5 What undisclosed history do you have with Newtek (see the reference to "Andrew") above that isn't disclosed above? Secondly, you're quite influential in the broadcast industry: https://www.obe.tv/author/obe/ There's an aura of hostility around this commit, and whatever that is seems to have spilled over into this. dropping NDI from ffmpeg can make more efforts to https://www.obe.tv/portfolio/interface-conversion/# ? -- Maksym Veremeyenko ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2] FATE: Add test for HEVC files that claim to have two first slices
This makes sure we don't regress on 70c8c8a818f39bc262565ec29fae2baffb3e1660. Signed-off-by: Derek Buitenhuis --- Sample: http://chromashift.org/two_first_slice.mp4 (Trimmed to 500KiB like Carl requested). MD5: 58b637d5500c2911d8cfe99fee86cb04 --- tests/fate/hevc.mak | 3 +++ tests/ref/fate/hevc-two-first-slice | 12 2 files changed, 15 insertions(+) create mode 100644 tests/ref/fate/hevc-two-first-slice diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak index db3ea19340..5ec6e279b9 100644 --- a/tests/fate/hevc.mak +++ b/tests/fate/hevc.mak @@ -253,6 +253,9 @@ fate-hevc-extradata-reload: CMD = framemd5 -i $(TARGET_SAMPLES)/hevc/extradata-r fate-hevc-monochrome-crop: CMD = probeframes -show_entries frame=width,height:stream=width,height $(TARGET_SAMPLES)/hevc/hevc-monochrome.hevc FATE_HEVC_FFPROBE-$(call DEMDEC, HEVC, HEVC) += fate-hevc-monochrome-crop +hevc-two-first-slice: CMD = threads=2 framemd5 -i $(TARGET_SAMPLES)/hevc/two_first_slice.mp4 -sws_flags bitexact -t 00:00.20 -an +FATE_HEVC += hevc-two-first-slice + FATE_SAMPLES_AVCONV += $(FATE_HEVC-yes) FATE_SAMPLES_FFPROBE += $(FATE_HEVC_FFPROBE-yes) diff --git a/tests/ref/fate/hevc-two-first-slice b/tests/ref/fate/hevc-two-first-slice new file mode 100644 index 00..8ce7a066c7 --- /dev/null +++ b/tests/ref/fate/hevc-two-first-slice @@ -0,0 +1,12 @@ +#format: frame checksums +#version: 2 +#hash: MD5 +#tb 0: 1/15 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 1920x1080 +#sar 0: 0/1 +#stream#, dts,pts, duration, size, hash +0, 0, 0,1, 3110400, c88154281ada839d3f209b0eab012577 +0, 1, 1,1, 3110400, a2623ba4639cf246b803c08e7233112f +0, 2, 2,1, 3110400, 9208fcdb16664e91ada77d15cc29ace9 -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/hlsenc: add var_stream_map NAME field string parameter
Use "a:0,agroup:aud_low,default:Yes,name:Chinese,language:CHN
a:1,agroup:aud_low,language:ENG
a:2,agroup:aud_high,default:Yes,name:Chinese,language:CHN
a:3,agroup:aud_high,language:ENG
v:0,agroup:aud_low v:1,agroup:aud_high"
to create master m3u8 list.
Result:
EXTM3U
EXT-X-VERSION:3
EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="group_aud_low",NAME="Chinese",DEFAULT=YES,LANGUAGE="CHN",URI="out_0.m3u8"
EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="group_aud_low",NAME="audio_1",DEFAULT=NO,LANGUAGE="ENG",URI="out_1.m3u8"
EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="group_aud_high",NAME="Chinese",DEFAULT=YES,LANGUAGE="CHN",URI="out_2.m3u8"
EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="group_aud_high",NAME="audio_3",DEFAULT=NO,LANGUAGE="ENG",URI="out_3.m3u8"
EXT-X-STREAM-INF:BANDWIDTH=1170400,RESOLUTION=640x480,CODECS="avc1.64001e,mp4a.40.2",AUDIO="group_aud_low"
out_4.m3u8
EXT-X-STREAM-INF:BANDWIDTH=3440800,RESOLUTION=640x480,CODECS="avc1.64001e,mp4a.40.2",AUDIO="group_aud_high"
out_5.m3u8
Signed-off-by: Zenon Mousmoulas
---
doc/muxers.texi | 6 --
libavformat/dashenc.c | 2 +-
libavformat/hlsenc.c | 14 +++---
libavformat/hlsplaylist.c | 6 --
libavformat/hlsplaylist.h | 2 +-
5 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index aac7d94edf..57d1432827 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -988,7 +988,7 @@ By default, a single hls variant containing all the encoded
streams is created.
@example
ffmpeg -re -i in.ts -b:a:0 32k -b:a:1 64k -b:v:0 1000k \
-map 0:a -map 0:a -map 0:v -f hls \
- -var_stream_map "a:0,agroup:aud_low,default:yes,language=ENG
a:1,agroup:aud_low,language:CHN v:0,agroup:aud_low" \
+ -var_stream_map "a:0,agroup:aud_low,default:yes,name:English,language:ENG
a:1,agroup:aud_low,language:CHN v:0,agroup:aud_low" \
-master_pl_name master.m3u8 \
http://example.com/live/out_%v.m3u8
@end example
@@ -997,7 +997,9 @@ addition to the #EXT-X-STREAM-INF tag for each variant
stream in the master
playlist, #EXT-X-MEDIA tag is also added for the two audio only variant streams
and they are mapped to the one video only variant streams with audio group name
'aud_low', and the audio group have default stat is NO or YES, and one audio
-have and language is named ENG, the other audio language is named CHN.
+have and language is named ENG, the other audio language is named CHN. The
first
+audio is named English, overriding the default which is derived from the
variant
+stream index.
By default, a single hls variant containing all the encoded streams is created.
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 1b74bce060..06dc9f3143 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1016,7 +1016,7 @@ static int write_manifest(AVFormatContext *s, int final)
continue;
get_hls_playlist_name(playlist_file, sizeof(playlist_file), NULL,
i);
ff_hls_write_audio_rendition(c->m3u8_out, (char *)audio_group,
- playlist_file, NULL, i, is_default);
+ playlist_file, NULL, i, NULL,
is_default);
max_audio_bitrate = FFMAX(st->codecpar->bit_rate +
os->muxer_overhead, max_audio_bitrate);
if (!av_strnstr(audio_codec_str, os->codec_str,
sizeof(audio_codec_str))) {
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 5f9a200c6e..813ac37368 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -154,6 +154,7 @@ typedef struct VariantStream {
unsigned int nb_streams;
int m3u8_created; /* status of media play-list creation */
int is_default; /* default status of audio group */
+char *name; /* audio name */
char *language; /* audio lauguage name */
char *agroup; /* audio group name */
char *ccgroup; /* closed caption group name */
@@ -1262,7 +1263,9 @@ static int create_master_playlist(AVFormatContext *s,
goto fail;
}
-ff_hls_write_audio_rendition(hls->m3u8_out, vs->agroup, m3u8_rel_name,
vs->language, i, hls->has_default_key ? vs->is_default : 1);
+ff_hls_write_audio_rendition(hls->m3u8_out, vs->agroup, m3u8_rel_name,
+ vs->language, i, vs->name,
+ hls->has_default_key ? vs->is_default :
1);
av_freep(&m3u8_rel_name);
}
@@ -1830,7 +1833,7 @@ static int parse_variant_stream_mapstring(AVFormatContext
*s)
/**
* Expected format for var_stream_map string is as below:
* "a:0,v:0 a:1,v:1"
- * "a:0,agroup:a0,default:1,language:ENG a:1,agroup:a1,defalut:0
v:0,agroup:a0 v:1,agroup:a1"
+ * "a:0,agroup:a0,default:1,name:English,language:ENG
a:1,agroup:a1,default:0 v:0,agroup:a0 v:1,agroup:a1"
* This string specifies how to group the audio, video and subtitle streams
* into different variant streams. The variant
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Thu, 21 Mar 2019 at 12:52, Jean-Baptiste Kempf wrote: > On Thu, 21 Mar 2019, at 07:35, Dennis Mungai wrote: > > And apparently calling out specific parties involved in this was > translated > > as an ad hominem attack. > > Single-outing one person, when you don't know half of the discussion is > not a nice way of interacting within this project. > Especially when you accuse another developer of the project, and claim > they do what they do to profit from it for business reasons. > > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > My sincerest apologies. > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Thu, 21 Mar 2019 at 16:56, Jean-Baptiste Kempf wrote: > On Thu, 21 Mar 2019, at 12:48, Ronald S. Bultje wrote: > > So that's nvidia stuff (npp/cuda) and blackmagic. (I'm filtering out the > > various ssl/aac components because they may be GPL-incompatible, but they > > are opensource.) > > I explained the case for those 2 cases. > I've asked for clarifications to BlackMagic on the header weirdness. > I'll ask Bradley about the compiler part. > > > I'm not mentioning quicksync because it's not in the nonfree list, but I > > want to mention that our wiki does mention the use of closed-source code > > [1]. I don't know what to make of this... > > libmfx is open source and loads the drivers, at least on Windows. > > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > The right step for Newtek at this point should be to release the NDI libraries under the GPL. Intent does not erase impact. At one point, they deliberately violated the GPL. Posting an unrefistributable build, then removing it after coming under pressure, isn’t a fix. The only way to regain the rights to use works authored under the GPL should be to release their libraries as such, or forever forfeit integration with the likes of ffmpeg. Their removal is justified. For these with doubts, go through ticket 7589. See the notes on that ffmpeg build. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Thu, 21 Mar 2019, at 12:48, Ronald S. Bultje wrote: > So that's nvidia stuff (npp/cuda) and blackmagic. (I'm filtering out the > various ssl/aac components because they may be GPL-incompatible, but they > are opensource.) I explained the case for those 2 cases. I've asked for clarifications to BlackMagic on the header weirdness. I'll ask Bradley about the compiler part. > I'm not mentioning quicksync because it's not in the nonfree list, but I > want to mention that our wiki does mention the use of closed-source code > [1]. I don't know what to make of this... libmfx is open source and loads the drivers, at least on Windows. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Thu, 21 Mar 2019, at 12:29, Maksym Veremeyenko wrote: > >> when do you plan to remove nVidia and BlackmagicDesign parts that is > >> /closed source and userland/ ? > > > > 0) addressing me directly like that is unfair, and unjust; > > i just extrapolated your main statement *The work was removed because So extrapolation. So basically, you put words in my mouth that I did not say. Just to smear at me. Very nice and fair. > > notably when NDI was not removed by me. > > you supported it And I explained why. Many times. With legal arguments; not with "you do that because you don't like this company" or "you do that because you don't like me". > [...] > > 3b) > > Decklink headers are open source, but are normally distributed in a package > > that is not open-source. > > Whether the license of the headers is stronger than the package license is > > not clear. It is also not clear if someone who agreed to the package > > license can redistribute those headers to the other people? > > GPL code that runtime load close-source proprietary library... Please start reading the arguments instead of twisting them and start reading the GPL. I suggest the end of paragraph 3, about the exception for libraries. NDI is not addressing system libraries and drivers. The exception does not hold for them. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/latmenc: Error out for unsupported codecs.
On 3/21/2019 6:06 AM, Nicolas George wrote:
> Carl Eugen Hoyos (12019-03-20):
>> +if (par->codec_id != AV_CODEC_ID_AAC && par->codec_id !=
>> AV_CODEC_ID_MP4ALS) {
>> +av_log(ctx, AV_LOG_ERROR, "Only AAC, LATM and ALS are supported\n");
>> +return AVERROR_INVALIDDATA;
>> +}
>
> I think EINVAL is more correct in this kind of case: EINVAL for invalid
> parameters from the application, INVALIDDATA for invalid data from the
> files. A quick grep shows it is not the only place this is done like
> that. I do not think it is urgent to fix it, just keep it in mind for
> later if you agree.
>
> Regards,
You're absolutely right, this is an EINVAL error.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v1 1/1] vaapi_hevc: Fix double-free issue.
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Decai Lin > Sent: Thursday, March 21, 2019 17:30 > To: ffmpeg-devel@ffmpeg.org > Cc: Yan, FengX ; Lin, Decai > Subject: [FFmpeg-devel] [PATCH v1 1/1] vaapi_hevc: Fix double-free issue. > > From: "Yan, FengX" > > Signed-off-by: Yan, FengX > Signed-off-by: Decai Lin > --- > libavcodec/vaapi_hevc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c > index 19aabcd..373ffc4 100644 > --- a/libavcodec/vaapi_hevc.c > +++ b/libavcodec/vaapi_hevc.c > @@ -271,7 +271,7 @@ static int vaapi_hevc_end_frame(AVCodecContext > *avctx) > > ret = ff_vaapi_decode_issue(avctx, &pic->pic); > if (ret < 0) > -goto fail; > +return ret; > > return 0; > fail: I believe this should match the behavior in vaapi_h264/mpeg4/.../vc1.c, and remove the redundant ff_vaapi_decode_cancel in vaapi_hevc_end_frame(). --Linjie ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
Hi, On Thu, Mar 21, 2019 at 7:31 AM Nicolas George wrote: > Maksym Veremeyenko (12019-03-21): > > i just extrapolated your main statement *The work was removed because the > > library is 100% closed source and userland.* that should be applied to > any > > parts of ffmpeg... or not? > > Please stop being shifty: what parts of FFmpeg precisely are you > suggesting to remove? > Presumably everything in EXTERNAL_LIBRARY_NONFREE_LIST and EXTERNAL_LIBRARY_NONFREE_LIST which is actually closed-source? So that's nvidia stuff (npp/cuda) and blackmagic. (I'm filtering out the various ssl/aac components because they may be GPL-incompatible, but they are opensource.) I'm not mentioning quicksync because it's not in the nonfree list, but I want to mention that our wiki does mention the use of closed-source code [1]. I don't know what to make of this... Ronald [1] https://trac.ffmpeg.org/wiki/Hardware/QuickSync - search for "Licence status of i965 VAAPI driver" [typo!] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
Maksym Veremeyenko (12019-03-21): > i am just trying to get attention on way and reason of how code was removed > and floating reasons from to remove... Then please stop your whataboutism. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On 21.03.2019 13:31, Nicolas George wrote: Maksym Veremeyenko (12019-03-21): i just extrapolated your main statement *The work was removed because the library is 100% closed source and userland.* that should be applied to any parts of ffmpeg... or not? Please stop being shifty: what parts of FFmpeg precisely are you suggesting to remove? i am just trying to get attention on way and reason of how code was removed and floating reasons from to remove... somebody says it was removed because of *library is 100% closed source and userland.*, somebody says it because license violation case, somebody just blame NewTek. it was applied to code without any strong objection, patches that implement runtime-library loading was rejected... and now: *lets drop it!* -- Maksym Veremeyenko ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
Maksym Veremeyenko (12019-03-21): > i just extrapolated your main statement *The work was removed because the > library is 100% closed source and userland.* that should be applied to any > parts of ffmpeg... or not? Please stop being shifty: what parts of FFmpeg precisely are you suggesting to remove? Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On 20.03.2019 21:36, Jean-Baptiste Kempf wrote: On Wed, 20 Mar 2019, at 18:03, Maksym Veremeyenko wrote: On 20.03.2019 17:37, Jean-Baptiste Kempf wrote: On Wed, 20 Mar 2019, at 16:35, Martin Vignali wrote: [...] We don't talk about a contribution remove for technical reason. But a contributor's work remove in order to try to annoy a licence violator. Absolutely not. The work was removed because the library is 100% closed source and userland. when do you plan to remove nVidia and BlackmagicDesign parts that is /closed source and userland/ ? 0) addressing me directly like that is unfair, and unjust; i just extrapolated your main statement *The work was removed because the library is 100% closed source and userland.* that should be applied to any parts of ffmpeg... or not? notably when NDI was not removed by me. you supported it [...] 3b) Decklink headers are open source, but are normally distributed in a package that is not open-source. Whether the license of the headers is stronger than the package license is not clear. It is also not clear if someone who agreed to the package license can redistribute those headers to the other people? GPL code that runtime load close-source proprietary library... -- Maksym Veremeyenko ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Wed, Mar 20, 2019 at 05:41:31PM -0400, Ronald S. Bultje wrote: > Hi, > > On Wed, Mar 20, 2019 at 4:15 PM Gyan wrote: > > > > > > > On 21-03-2019 01:32 AM, Marton Balint wrote: > > > > > > > > > On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > > > > >> On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote: > > >>> On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote: > > >>> > > >>> > On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote: > > >>> >> As I described in similar threads before, whether or not the > > >>> project want >> closed source support for NDI is a subjective issue, > > >>> please start a vote >> about the removal of libndi if you want to > > >>> seek this through. > > >>> > > > >>> > The removal of libndi is actually done and committed. > > >>> > > >>> That is just sad an unfair. > > >> > > >> Sad, maybe. > > >> Unfair, I disagree. If NDI wants to be in, they know what to do. > > > > > > It is unfair towards the people who expressied disapproval, yet this > > > change was committed without neither vote nor consensus. > > > > +1. This was a political decision, not a technical one. A formal(-ish) > > survey should have happened on the ML. > > > > I agree we need a formal vote on this. I would like to set a wider project > policy w.r.t. closed-source software integration, this is just one instance > of a more general issue. I think there should have been a vote before pushing a commit as there where FFmpeg developers objecting to it. Ignoring people causes nothing good. Had there been a vote people would be alot less upset about it as everyones oppinion would be counted equally It makes me unhappy that one FFmpeg developer apparently decided to leave the project already because of this. I think we should fix this, make a proper policy, with a proper vote and then hopefully noone feels the need to leave. > > Who wants to organize it? Thilo organized the last vote, maybe he wants to do it ? but if noone else wants to do it i can do one too if people want and there is consensus who can vote If i search for "open source vote free" on google it points to vote.heliosvoting.org as first hit this seems rather basic but for simple yes/no questions it could work maybe someone has a better suggestion we could use for more complex future cases that is multiple choice votes in teh future (schulze STV / CPO-STV for multiwinner or ScottishSTV (used by SPI), schulze method (used by debian) for one winner of N choices would be nice to have) Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf: Constify the probe function argument
2019-03-21 11:21 GMT+01:00, Tomas Härdin : > tor 2019-03-21 klockan 01:20 +0100 skrev Carl Eugen Hoyos: >> Hi! >> >> Attached patch makes the only argument to the common probe() function >> const. > > Looks good to me. Passes FATE. Patch applied. Thank you both, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf: Constify the probe function argument
tor 2019-03-21 klockan 01:20 +0100 skrev Carl Eugen Hoyos: > Hi! > > Attached patch makes the only argument to the common probe() function > const. Looks good to me. Passes FATE. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] News: Removal of libndi
On Thu, 21 Mar 2019, at 07:35, Dennis Mungai wrote: > And apparently calling out specific parties involved in this was translated > as an ad hominem attack. Single-outing one person, when you don't know half of the discussion is not a nice way of interacting within this project. Especially when you accuse another developer of the project, and claim they do what they do to profit from it for business reasons. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v1 1/1] vaapi_hevc: Fix double-free issue.
From: "Yan, FengX" Signed-off-by: Yan, FengX Signed-off-by: Decai Lin --- libavcodec/vaapi_hevc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c index 19aabcd..373ffc4 100644 --- a/libavcodec/vaapi_hevc.c +++ b/libavcodec/vaapi_hevc.c @@ -271,7 +271,7 @@ static int vaapi_hevc_end_frame(AVCodecContext *avctx) ret = ff_vaapi_decode_issue(avctx, &pic->pic); if (ret < 0) -goto fail; +return ret; return 0; fail: -- 1.8.3.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/v4l2: Return FFERROR_REDO when receiving a frame of unexpected size
Marton Balint (12019-03-21): > Maybe just set the packet corrupt flag and log an error, but return the > partial buffer? I think it may be the best solution. But it would be interesting to know how the tools react to it. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/latmenc: Error out for unsupported codecs.
Carl Eugen Hoyos (12019-03-20):
> +if (par->codec_id != AV_CODEC_ID_AAC && par->codec_id !=
> AV_CODEC_ID_MP4ALS) {
> +av_log(ctx, AV_LOG_ERROR, "Only AAC, LATM and ALS are supported\n");
> +return AVERROR_INVALIDDATA;
> +}
I think EINVAL is more correct in this kind of case: EINVAL for invalid
parameters from the application, INVALIDDATA for invalid data from the
files. A quick grep shows it is not the only place this is done like
that. I do not think it is urgent to fix it, just keep it in mind for
later if you agree.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf: Constify the probe function argument
On Thu, 21 Mar 2019 01:20:21 +0100 Carl Eugen Hoyos wrote: > Hi! > > Attached patch makes the only argument to the common probe() function const. > > Please comment, Carl Eugen LGTM - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 resend] swscale/ppc: VSX-optimize yuv2rgb_full
./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 \
-s 1200x1440 -f null -vframes 100 -pix_fmt $i -nostats \
-cpuflags 0 -v error -
This uses 32-bit mul, so POWER8 only.
The following output formats get about 4.5x speedup:
rgb24
39980 UNITS in yuv2packed1, 32768 runs, 0 skips
8774 UNITS in yuv2packed1, 32768 runs, 0 skips
bgr24
40069 UNITS in yuv2packed1, 32768 runs, 0 skips
8772 UNITS in yuv2packed1, 32766 runs, 2 skips
rgba
39759 UNITS in yuv2packed1, 32768 runs, 0 skips
8681 UNITS in yuv2packed1, 32767 runs, 1 skips
bgra
39729 UNITS in yuv2packed1, 32768 runs, 0 skips
8696 UNITS in yuv2packed1, 32766 runs, 2 skips
argb
39766 UNITS in yuv2packed1, 32768 runs, 0 skips
8672 UNITS in yuv2packed1, 32766 runs, 2 skips
bgra
39784 UNITS in yuv2packed1, 32768 runs, 0 skips
8659 UNITS in yuv2packed1, 32767 runs, 1 skips
Signed-off-by: Lauri Kasanen
---
libswscale/ppc/swscale_vsx.c | 291 +++
1 file changed, 291 insertions(+)
v2: HAVE_POWER8 from ifdef to if
Resending due to mail client troubles
diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index 01eb46c..062ab0d 100644
--- a/libswscale/ppc/swscale_vsx.c
+++ b/libswscale/ppc/swscale_vsx.c
@@ -422,6 +422,248 @@ yuv2NBPSX(16, BE, 1, 16, int32_t)
yuv2NBPSX(16, LE, 0, 16, int32_t)
#endif
+static av_always_inline void
+yuv2rgb_full_1_vsx_template(SwsContext *c, const int16_t *buf0,
+ const int16_t *ubuf[2], const int16_t *vbuf[2],
+ const int16_t *abuf0, uint8_t *dest, int dstW,
+ int uvalpha, int y, enum AVPixelFormat target,
+ int hasAlpha)
+{
+const int16_t *ubuf0 = ubuf[0], *vbuf0 = vbuf[0];
+const int16_t *ubuf1 = ubuf[1], *vbuf1 = vbuf[1];
+vector int16_t vy, vu, vv, A = vec_splat_s16(0), tmp16;
+vector int32_t vy32_l, vy32_r, vu32_l, vu32_r, vv32_l, vv32_r, tmp32,
tmp32_2;
+vector int32_t R_l, R_r, G_l, G_r, B_l, B_r;
+vector uint16_t rd16, gd16, bd16;
+vector uint8_t rd, bd, gd, ad, out0, out1, tmp8;
+const vector uint16_t zero16 = vec_splat_u16(0);
+const vector int32_t y_offset = vec_splats(c->yuv2rgb_y_offset);
+const vector int32_t y_coeff = vec_splats(c->yuv2rgb_y_coeff);
+const vector int32_t y_add = vec_splats(1 << 21);
+const vector int32_t v2r_coeff = vec_splats(c->yuv2rgb_v2r_coeff);
+const vector int32_t v2g_coeff = vec_splats(c->yuv2rgb_v2g_coeff);
+const vector int32_t u2g_coeff = vec_splats(c->yuv2rgb_u2g_coeff);
+const vector int32_t u2b_coeff = vec_splats(c->yuv2rgb_u2b_coeff);
+const vector int32_t rgbclip = vec_splats(1 << 30);
+const vector int32_t zero32 = vec_splat_s32(0);
+const vector uint32_t shift2 = vec_splat_u32(2);
+const vector uint32_t shift22 = vec_splats(22U);
+const vector uint16_t sub7 = vec_splats((uint16_t) (128 << 7));
+const vector uint16_t sub8 = vec_splats((uint16_t) (128 << 8));
+const vector int16_t mul4 = vec_splat_s16(4);
+const vector int16_t mul8 = vec_splat_s16(8);
+const vector int16_t add64 = vec_splat_s16(64);
+const vector uint16_t shift7 = vec_splat_u16(7);
+const vector int16_t max255 = vec_splat_s16(255);
+int i;
+
+// Various permutations
+const vector uint8_t perm3rg0 = (vector uint8_t) {0x0, 0x10, 0,
+ 0x1, 0x11, 0,
+ 0x2, 0x12, 0,
+ 0x3, 0x13, 0,
+ 0x4, 0x14, 0,
+ 0x5 };
+const vector uint8_t perm3rg1 = (vector uint8_t) { 0x15, 0,
+ 0x6, 0x16, 0,
+ 0x7, 0x17, 0 };
+const vector uint8_t perm3tb0 = (vector uint8_t) {0x0, 0x1, 0x10,
+ 0x3, 0x4, 0x11,
+ 0x6, 0x7, 0x12,
+ 0x9, 0xa, 0x13,
+ 0xc, 0xd, 0x14,
+ 0xf };
+const vector uint8_t perm3tb1 = (vector uint8_t) { 0x0, 0x15,
+ 0x2, 0x3, 0x16,
+ 0x5, 0x6, 0x17 };
+
+for (i = 0; i < dstW; i += 8) { // The x86 asm also overwrites padding
bytes.
+vy = vec_ld(0, &buf0[i]);
+vy32_l = vec_unpackh(vy);
+vy32_r = vec_unpackl(vy);
+vy32_l = vec_sl(vy32_l, shift2);
+vy32_r = vec_sl(vy32_r, shift2);
+
+vu = vec_ld(0, &ubuf0[i]);
+vv = vec_ld(0, &vbuf0[i]);
+
