Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.
On Wed, Jul 6, 2016 at 4:37 AM, Dan Parrot wrote: > Finish providing SIMD versions for POWER8 VSX of functions in > libswscale/input.c That should allow trac ticket #5570 to be closed. > The speedups obtained for the functions are: > > abgrToA_c 1.19 > bgr24ToUV_c 1.23 > bgr24ToUV_half_c1.37 > bgr24ToY_c_vsx 1.43 > nv12ToUV_c 1.05 > nv21ToUV_c 1.06 > planar_rgb_to_uv1.25 > planar_rgb_to_y 1.26 > rgb24ToUV_c 1.11 > rgb24ToUV_half_c1.10 > rgb24ToY_c 0.92 > rgbaToA_c 0.88 > uyvyToUV_c 1.05 > uyvyToY_c 1.15 > yuy2ToUV_c 1.07 > yuy2ToY_c 1.17 > yvy2ToUV_c 1.05 SIMD implementations that in the best case improve the speed by 43% (and in some cases is *slower*) seem barely worth it. One would expect a proper SIMD implementation to offer 100% or higher increases, at least thats the general expectation on x86 with SSE/AVX. So the question here is - is thats VSX being bad, or the intrinsics being bad? How would the speedup be in proper hand-written ASM? If hand-written ASM can give us the usual 100-200% improvements we would expect from SIMD, then this is what should generally be favored. Also, one further thought: From the commit message, it sounds like you might only be doing this for the bounty in #5570, do you plan to maintain these optimizations in the future? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] hwcontext: add a QSV implementation
Signed-off-by: nablet developer
---
libavutil/Makefile | 3 +
libavutil/hwcontext.c | 3 +
libavutil/hwcontext.h | 1 +
libavutil/hwcontext_internal.h | 1 +
libavutil/hwcontext_qsv.c | 791 +
libavutil/hwcontext_qsv.h | 52 +++
6 files changed, 851 insertions(+)
create mode 100644 libavutil/hwcontext_qsv.c
create mode 100644 libavutil/hwcontext_qsv.h
diff --git a/libavutil/Makefile b/libavutil/Makefile
index 1e06176..7385ec2 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -35,6 +35,7 @@ HEADERS = adler32.h
\
hwcontext.h \
hwcontext_cuda.h \
hwcontext_dxva2.h \
+ hwcontext_qsv.h \
hwcontext_vaapi.h \
hwcontext_vdpau.h \
imgutils.h\
@@ -154,6 +155,7 @@ OBJS-$(!HAVE_ATOMICS_NATIVE)+= atomic.o
\
OBJS-$(CONFIG_CUDA) += hwcontext_cuda.o
OBJS-$(CONFIG_DXVA2)+= hwcontext_dxva2.o
+OBJS-$(CONFIG_LIBMFX) += hwcontext_qsv.o
OBJS-$(CONFIG_LZO) += lzo.o
OBJS-$(CONFIG_OPENCL) += opencl.o opencl_internal.o
OBJS-$(CONFIG_VAAPI)+= hwcontext_vaapi.o
@@ -166,6 +168,7 @@ SLIBOBJS-$(HAVE_GNU_WINDRES)+= avutilres.o
SKIPHEADERS-$(CONFIG_CUDA) += hwcontext_cuda.h
SKIPHEADERS-$(CONFIG_DXVA2)+= hwcontext_dxva2.h
+SKIPHEADERS-$(CONFIG_LIBMFX) += hwcontext_qsv.h
SKIPHEADERS-$(CONFIG_VAAPI)+= hwcontext_vaapi.h
SKIPHEADERS-$(CONFIG_VDPAU)+= hwcontext_vdpau.h
SKIPHEADERS-$(HAVE_ATOMICS_GCC)+= atomic_gcc.h
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index 1e9e913..81b6911 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -32,6 +32,9 @@ static const HWContextType *hw_table[] = {
#if CONFIG_CUDA
&ff_hwcontext_type_cuda,
#endif
+#if CONFIG_LIBMFX
+&ff_hwcontext_type_qsv,
+#endif
#if CONFIG_DXVA2
&ff_hwcontext_type_dxva2,
#endif
diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
index 4e9da02..5e2af09 100644
--- a/libavutil/hwcontext.h
+++ b/libavutil/hwcontext.h
@@ -29,6 +29,7 @@ enum AVHWDeviceType {
AV_HWDEVICE_TYPE_CUDA,
AV_HWDEVICE_TYPE_VAAPI,
AV_HWDEVICE_TYPE_DXVA2,
+AV_HWDEVICE_TYPE_QSV,
};
typedef struct AVHWDeviceInternal AVHWDeviceInternal;
diff --git a/libavutil/hwcontext_internal.h b/libavutil/hwcontext_internal.h
index cf832fe..079e42b 100644
--- a/libavutil/hwcontext_internal.h
+++ b/libavutil/hwcontext_internal.h
@@ -101,6 +101,7 @@ struct AVHWFramesInternal {
extern const HWContextType ff_hwcontext_type_cuda;
extern const HWContextType ff_hwcontext_type_dxva2;
+extern const HWContextType ff_hwcontext_type_qsv;
extern const HWContextType ff_hwcontext_type_vaapi;
extern const HWContextType ff_hwcontext_type_vdpau;
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
new file mode 100644
index 000..13be5b0
--- /dev/null
+++ b/libavutil/hwcontext_qsv.c
@@ -0,0 +1,791 @@
+/*
+ * 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 FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+
+#include
+
+#include "config.h"
+
+#if CONFIG_VAAPI
+#include "hwcontext_vaapi.h"
+#endif
+#if CONFIG_DXVA2
+#include "hwcontext_dxva2.h"
+#endif
+
+#include "buffer.h"
+#include "common.h"
+#include "hwcontext.h"
+#include "hwcontext_internal.h"
+#include "hwcontext_qsv.h"
+#include "mem.h"
+#include "pixfmt.h"
+#include "pixdesc.h"
+#include "time.h"
+
+typedef struct QSVDevicePriv {
+AVBufferRef *child_device_ctx;
+} QSVDevicePriv;
+
+typedef struct QSVDeviceContext {
+mfxHDL handle;
+mfxHandleType handle_type;
+mfxVersion ver;
+mfxIMPL impl;
+
+enum AVHWDeviceType child_device_type;
+enum AVPixelFormat child_pi
[FFmpeg-devel] [PATCH] hwcontext: add a QSV implementation
add hwcontext_qsv (Intel QuickSync Video) implementation basically it's adapted patch from libav (https://lists.libav.org/pipermail/libav-devel/2016-May/077126.html) hwcontext_qsv is needed for VPP filter (which cannot use API functions from libavcodec) nablet developer (1): hwcontext: add a QSV implementation libavutil/Makefile | 3 + libavutil/hwcontext.c | 3 + libavutil/hwcontext.h | 1 + libavutil/hwcontext_internal.h | 1 + libavutil/hwcontext_qsv.c | 791 + libavutil/hwcontext_qsv.h | 52 +++ 6 files changed, 851 insertions(+) create mode 100644 libavutil/hwcontext_qsv.c create mode 100644 libavutil/hwcontext_qsv.h -- 1.8.3.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] core infrastructure badge for FFmpeg
Ganesh Ajjanagadde mit.edu> writes: > > No question, it would be better if tests would be added quicker ... > > I do not doubt this, but at the moment we do not enforce it. > Do you see any trouble in enforcing this requirement from > major release to next major release? I am against adding such a "hard" requirement. I believe we have filters that are impossible / very difficult to test. [...] > >> 17. There MUST be no unpatched vulnerabilities of > >> medium or high severity that have been publicly > >> known for more than 60 days. > >> Do we guarantee this? (What is "medium or high severity"? I only remember now that concat protocol was "low" and that we fixed it after a few days.) I am sorry if I completely misunderstand this sentence but I am 100% sure we do not guarantee that we fix future vulnerabilities within a given time. (on the contrary, see our license) Additionally, I suspect there is no open source project that can guarantee this. In case I do understand the above sentence correctly, I believe we should not try to apply (read "phony"). Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hwcontext: add a QSV implementation
nablet developer nablet.com> writes: > hwcontext_qsv is needed for VPP filter (which cannot use API > functions from libavcodec) Why not? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hwcontext: add a QSV implementation
On Wed, Jul 6, 2016 at 9:08 AM, nablet developer wrote: > add hwcontext_qsv (Intel QuickSync Video) implementation > basically it's adapted patch from libav > (https://lists.libav.org/pipermail/libav-devel/2016-May/077126.html) If you take a patch from libav, you need to maintain proper authorship information. Also please outline what has changed from the original, if anything. We try to keep all the hwcontext things as close to libav as possible to make future enhancements easier. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hwcontext: add a QSV implementation
> On 06 Jul 2016, at 15:48, Hendrik Leppkes wrote: > > On Wed, Jul 6, 2016 at 9:08 AM, nablet developer wrote: >> add hwcontext_qsv (Intel QuickSync Video) implementation >> basically it's adapted patch from libav >> (https://lists.libav.org/pipermail/libav-devel/2016-May/077126.html) > > If you take a patch from libav, you need to maintain proper authorship > information. how is it usually done? commit message, comment block or something else? > Also please outline what has changed from the original, if anything. > We try to keep all the hwcontext things as close to libav as possible > to make future enhancements easier. patch is identical except copyright headers of hwcontext_qsv.c / hwcontext_qsv.h (first 17 lines) which are changed to the typical ffmpeg copyright. > > - Hendrik > ___ > 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] hwcontext: add a QSV implementation
existing API functions like ff_qsv_init_internal_session / ff_qsv_close_internal_session are private to libavcodec and are not exported (since they are ff_ prefixed) first attempt was to move API functions from libavcodec to libavutil, but it was rejected and instead it was suggested to use existing generic hwcontext approach instead of adding QSV specific API > On 06 Jul 2016, at 15:40, Carl Eugen Hoyos wrote: > > nablet developer nablet.com> writes: > >> hwcontext_qsv is needed for VPP filter (which cannot use API >> functions from libavcodec) > > Why not? > > Carl Eugen > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] core infrastructure badge for FFmpeg
On Wed, Jul 06, 2016 at 08:02:55AM +, Carl Eugen Hoyos wrote: > Ganesh Ajjanagadde mit.edu> writes: > > > > No question, it would be better if tests would be added quicker ... > > > > I do not doubt this, but at the moment we do not enforce it. > > Do you see any trouble in enforcing this requirement from > > major release to next major release? > > I am against adding such a "hard" requirement. > I believe we have filters that are impossible / very > difficult to test. > > [...] > > > >> 17. There MUST be no unpatched vulnerabilities of > > >> medium or high severity that have been publicly > > >> known for more than 60 days. > > >> Do we guarantee this? > > (What is "medium or high severity"? I only remember now > that concat protocol was "low" and that we fixed it after > a few days.) > > I am sorry if I completely misunderstand this sentence > but I am 100% sure we do not guarantee that we fix future > vulnerabilities within a given time. > (on the contrary, see our license) > > Additionally, I suspect there is no open source project > that can guarantee this. > > In case I do understand the above sentence correctly, I > believe we should not try to apply (read "phony"). btw, theres also a example if some questions feel ambigous: https://bestpractices.coreinfrastructure.org/projects/1 for "There MUST be no unpatched vulnerabilities of medium or high severity that have been publicly known for more than 60 days. [vulnerabilities_fixed_60_days]" The example lists "No such vulnerabilities at this time." as a passing comment thus i do not think this point is about any gurantees or future [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] core infrastructure badge for FFmpeg
Michael Niedermayer niedermayer.cc> writes: > thus i do not think this point is about any gurantees or future So I misunderstood. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] libavcodec/dnxhd: added dnxhr profiles
On 6 July 2016 at 03:46, Mark Reid wrote:
> ---
> libavcodec/avcodec.h| 7 +++
> libavcodec/codec_desc.c | 1 +
> libavcodec/dnxhddec.c | 20
> libavcodec/profiles.c | 10 ++
> libavcodec/profiles.h | 1 +
> 5 files changed, 39 insertions(+)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 39713ed..8f84fd0 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3165,6 +3165,13 @@ typedef struct AVCodecContext {
> #define FF_PROFILE_MPEG2_AAC_LOW 128
> #define FF_PROFILE_MPEG2_AAC_HE 131
>
> +#define FF_PROFILE_DNXHD 0
> +#define FF_PROFILE_DNXHR_LB 1
> +#define FF_PROFILE_DNXHR_SQ 2
> +#define FF_PROFILE_DNXHR_HQ 3
> +#define FF_PROFILE_DNXHR_HQX 4
> +#define FF_PROFILE_DNXHR_444 5
> +
> #define FF_PROFILE_DTS 20
> #define FF_PROFILE_DTS_ES 30
> #define FF_PROFILE_DTS_96_24 40
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 9d94b72..e6b8bbc 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -665,6 +665,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
> .name = "dnxhd",
> .long_name = NULL_IF_CONFIG_SMALL("VC3/DNxHD"),
> .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
> +.profiles = NULL_IF_CONFIG_SMALL(ff_dnxhd_profiles),
> },
> {
> .id= AV_CODEC_ID_THP,
> diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
> index 1808080..33dfec2 100644
> --- a/libavcodec/dnxhddec.c
> +++ b/libavcodec/dnxhddec.c
> @@ -33,6 +33,7 @@
> #include "dnxhddata.h"
> #include "idctdsp.h"
> #include "internal.h"
> +#include "profiles.h"
> #include "thread.h"
>
> typedef struct RowContext {
> @@ -567,6 +568,23 @@ static int dnxhd_decode_row(AVCodecContext *avctx,
> void *data,
> return 0;
> }
>
> +static int dnxhd_get_profile(int cid)
> +{
> +switch(cid) {
> +case 1270:
> +return FF_PROFILE_DNXHR_444;
> +case 1271:
> +return FF_PROFILE_DNXHR_HQX;
> +case 1272:
> +return FF_PROFILE_DNXHR_HQ;
> +case 1273:
> +return FF_PROFILE_DNXHR_SQ;
> +case 1274:
> +return FF_PROFILE_DNXHR_LB;
> +}
> +return FF_PROFILE_DNXHD;
> +}
> +
> static int dnxhd_decode_frame(AVCodecContext *avctx, void *data,
>int *got_frame, AVPacket *avpkt)
> {
> @@ -600,6 +618,7 @@ decode_coding_unit:
> }
>
> avctx->pix_fmt = ctx->pix_fmt;
> +avctx->profile = dnxhd_get_profile(ctx->cid);
> ret = ff_set_dimensions(avctx, ctx->width, ctx->height);
> if (ret < 0)
> return ret;
> @@ -692,4 +711,5 @@ AVCodec ff_dnxhd_decoder = {
> .capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS |
>AV_CODEC_CAP_SLICE_THREADS,
> .init_thread_copy =
> ONLY_IF_THREADS_ENABLED(dnxhd_decode_init_thread_copy),
> +.profiles = NULL_IF_CONFIG_SMALL(ff_dnxhd_profiles),
> };
> diff --git a/libavcodec/profiles.c b/libavcodec/profiles.c
> index da745e1..07fb6d6 100644
> --- a/libavcodec/profiles.c
> +++ b/libavcodec/profiles.c
> @@ -46,6 +46,16 @@ const AVProfile ff_dca_profiles[] = {
> { FF_PROFILE_UNKNOWN },
> };
>
> +const AVProfile ff_dnxhd_profiles[] = {
> + { FF_PROFILE_DNXHD, "DNXHD"},
> + { FF_PROFILE_DNXHR_LB, "DNXHR LB"},
> + { FF_PROFILE_DNXHR_SQ, "DNXHR SQ"},
> + { FF_PROFILE_DNXHR_HQ, "DNXHR HQ" },
> + { FF_PROFILE_DNXHR_HQX, "DNXHR HQX"},
> + { FF_PROFILE_DNXHR_444, "DNXHR 444"},
> + { FF_PROFILE_UNKNOWN },
> +};
> +
> const AVProfile ff_h264_profiles[] = {
> { FF_PROFILE_H264_BASELINE, "Baseline" },
> { FF_PROFILE_H264_CONSTRAINED_BASELINE, "Constrained Baseline" },
> diff --git a/libavcodec/profiles.h b/libavcodec/profiles.h
> index c86c683..eb18b40 100644
> --- a/libavcodec/profiles.h
> +++ b/libavcodec/profiles.h
> @@ -23,6 +23,7 @@
>
> extern const AVProfile ff_aac_profiles[];
> extern const AVProfile ff_dca_profiles[];
> +extern const AVProfile ff_dnxhd_profiles[];
> extern const AVProfile ff_h264_profiles[];
> extern const AVProfile ff_hevc_profiles[];
> extern const AVProfile ff_jpeg2000_profiles[];
> --
> 2.7.3
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
This looks fine to me.
Have you checked that you can still retrieve the profile from libavformat
for the mov muxer?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] add split_by_time flag for support splite mpegts segment at non-keyframe
support split hls segment at duration set by hls_time
after the patch , the ffmpeg can split the mpegts for hls by hls_time
parameter
[root@localhost ffmpeg]# ./ffmpeg -i /root/facebook.mp4 -v quiet -c copy -f
hls -hls_time 3 -hls_flags split_by_time -bsf:v h264_mp4toannexb
-hls_list_size 20 -t 30 output_afterpatch.m3u8
[root@localhost ffmpeg]#
[root@localhost ffmpeg]#
[root@localhost ffmpeg]# cat output_afterpatch.m3u8
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:3.04,
output_afterpatch0.ts
#EXTINF:3.16,
output_afterpatch1.ts
#EXTINF:2.84,
output_afterpatch2.ts
#EXTINF:3.16,
output_afterpatch3.ts
#EXTINF:2.88,
output_afterpatch4.ts
#EXTINF:3.08,
output_afterpatch5.ts
#EXTINF:2.92,
output_afterpatch6.ts
#EXTINF:3.12,
output_afterpatch7.ts
#EXTINF:2.88,
output_afterpatch8.ts
#EXTINF:2.96,
output_afterpatch9.ts
#EXTINF:-0.04,
output_afterpatch10.ts
#EXT-X-ENDLIST
support split hls segment at duration set by hls_time
Signed-off-by: LiuQi
---
libavformat/hlsenc.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index a9fa5d8..5dc518d 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -62,6 +62,7 @@ typedef enum HLSFlags {
HLS_ROUND_DURATIONS = (1 << 2),
HLS_DISCONT_START = (1 << 3),
HLS_OMIT_ENDLIST = (1 << 4),
+HLS_SPLIT_BY_TIME = (1 << 5),
} HLSFlags;
typedef enum {
@@ -813,7 +814,7 @@ static int hls_write_packet(AVFormatContext *s,
AVPacket *pkt)
if (hls->has_video) {
can_split = st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
-pkt->flags & AV_PKT_FLAG_KEY;
+((pkt->flags & AV_PKT_FLAG_KEY) || (hls->flags &
HLS_SPLIT_BY_TIME));
is_ref_pkt = st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO;
}
if (pkt->pts == AV_NOPTS_VALUE)
@@ -923,6 +924,7 @@ static const AVOption options[] = {
{"round_durations", "round durations in m3u8 to whole numbers", 0,
AV_OPT_TYPE_CONST, {.i64 = HLS_ROUND_DURATIONS }, 0, UINT_MAX, E,
"flags"},
{"discont_start", "start the playlist with a discontinuity tag", 0,
AV_OPT_TYPE_CONST, {.i64 = HLS_DISCONT_START }, 0, UINT_MAX, E, "flags"},
{"omit_endlist", "Do not append an endlist when ending stream", 0,
AV_OPT_TYPE_CONST, {.i64 = HLS_OMIT_ENDLIST }, 0, UINT_MAX, E, "flags"},
+{"split_by_time", "split the hls segment by time which user set by
hls_time", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SPLIT_BY_TIME }, 0, UINT_MAX,
E, "flags"},
{"use_localtime", "set filename expansion with strftime at segment
creation", OFFSET(use_localtime), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
{"use_localtime_mkdir", "create last directory component in
strftime-generated filename", OFFSET(use_localtime_mkdir),
AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
{"hls_playlist_type", "set the HLS playlist type", OFFSET(pl_type),
AV_OPT_TYPE_INT, {.i64 = PLAYLIST_TYPE_NONE }, 0, PLAYLIST_TYPE_NB-1, E,
"pl_type" },
--
1.7.1
0001-add-split_by_time-flag-for-support-splite-mpegts-seg.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] core infrastructure badge for FFmpeg
06.07.2016, 04:03, "Carl Eugen Hoyos" : > Ganesh Ajjanagadde mit.edu> writes: > >> > No question, it would be better if tests would be added quicker ... >> >> I do not doubt this, but at the moment we do not enforce it. >> Do you see any trouble in enforcing this requirement from >> major release to next major release? > > I am against adding such a "hard" requirement. > I believe we have filters that are impossible / very > difficult to test. I do not understand what is so difficult about testing filters. Yes, if floating point is used, we can't simply test bit-exactness, but one can simply use some similarity meaure, right? [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] core infrastructure badge for FFmpeg
On 04 Jul, Ganesh Ajjanagadde wrote : > https://bestpractices.coreinfrastructure.org/. Tbh, this is pure BS/PR, as we've seen for VLC. But why not... But, you could at least be a bit more truthful when filling it: - the buildsystem is not common tools, since you have your own configure (it's a SUGGESTED thing anyway) - the new functionnality testing is only done in libavcodec, - half of the links given are over github, which is not FLOSS and is just a mirror... And other on ffmpeg.org - you do not use SEMVER (it's a SUGGESTED improvement too) - everything related to external users should be N/A and not "met", (I doubt they mean trac here) - you allow /dev/random, as a silent fallback over urandom, I doubt this is secure, or fullfills their requirement. - where is written the policy that coverity must be run on each release? - the dynamic analysis is done by 3rd parties, it should be mentionned, especially since it's just a SUGGESTED point. With my kindest regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] core infrastructure badge for FFmpeg
On Wed, Jul 06, 2016 at 07:18:08AM -0400, Ganesh Ajjanagadde wrote: > 06.07.2016, 04:03, "Carl Eugen Hoyos" : > > Ganesh Ajjanagadde mit.edu> writes: > > > >> > No question, it would be better if tests would be added quicker ... > >> > >> I do not doubt this, but at the moment we do not enforce it. > >> Do you see any trouble in enforcing this requirement from > >> major release to next major release? > > > > I am against adding such a "hard" requirement. > > I believe we have filters that are impossible / very > > difficult to test. > > I do not understand what is so difficult about testing filters. > Yes, if floating point is used, we can't simply test bit-exactness, > but one can simply use some similarity meaure, right? yes, would require a reference to compare agaist in the fate samples though [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] core infrastructure badge for FFmpeg
06.07.2016, 07:48, "Jean-Baptiste Kempf" : > On 04 Jul, Ganesh Ajjanagadde wrote : >> https://bestpractices.coreinfrastructure.org/. > > Tbh, this is pure BS/PR, as we've seen for VLC. But why not... > > But, you could at least be a bit more truthful when filling it: > - the buildsystem is not common tools, since you have your own > configure (it's a SUGGESTED thing anyway) As far as I know, shell script is a common tool available on POSIX platforms. > - the new functionnality testing is only done in libavcodec, I did not assert to the contrary, but it is certainly an "informal" policy per the dev docs. I did acknowledge the lack of tests in certain places such as libavfilter. > - half of the links given are over github, which is not FLOSS and is > just a mirror... And other on ffmpeg.org So what? There is no requirement that the links must be posted on FLOSS sites, whatever that means which you conveniently leave unspecified. The purpose of the mirror here is just as a reference point, and can always be changed. There is some lack of consistency in link usage, I am going to change it. > - you do not use SEMVER (it's a SUGGESTED improvement too) I thought we did, since that is what I assumed the chicanery regarding major, minor, etc was all about. Will amend. > - everything related to external users should be N/A and not "met", > (I doubt they mean trac here) Please be more explicit here. What is wrong with trac as a link for a bug tracker? > - you allow /dev/random, as a silent fallback over urandom, I doubt > this is secure, or fullfills their requirement. Be explicit, if you say it is insecure, give an example of a platform where it is, and report to ffmpeg-secur...@ffmpeg.org. If true, then yes, this must be removed. > - where is written the policy that coverity must be run on each release? No policy, but Michael did say that "we do run coverity around the release time generally". From my experience over the last 6 months, Coverity was run at least once before each release. If there was an instance where it was not, sure, I will remove it. > - the dynamic analysis is done by 3rd parties, it should be mentionned, > especially since it's just a SUGGESTED point. Ok, will change. > > With my kindest regards, > > -- > Jean-Baptiste Kempf > http://www.jbkempf.com/ - +33 672 704 734 > Sent from my Electronic Device > ___ > 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] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.
On Wed, 2016-07-06 at 09:07 +0200, Hendrik Leppkes wrote: > On Wed, Jul 6, 2016 at 4:37 AM, Dan Parrot wrote: > > Finish providing SIMD versions for POWER8 VSX of functions in > > libswscale/input.c That should allow trac ticket #5570 to be closed. > > The speedups obtained for the functions are: > > > > abgrToA_c 1.19 > > bgr24ToUV_c 1.23 > > bgr24ToUV_half_c1.37 > > bgr24ToY_c_vsx 1.43 > > nv12ToUV_c 1.05 > > nv21ToUV_c 1.06 > > planar_rgb_to_uv1.25 > > planar_rgb_to_y 1.26 > > rgb24ToUV_c 1.11 > > rgb24ToUV_half_c1.10 > > rgb24ToY_c 0.92 > > rgbaToA_c 0.88 > > uyvyToUV_c 1.05 > > uyvyToY_c 1.15 > > yuy2ToUV_c 1.07 > > yuy2ToY_c 1.17 > > yvy2ToUV_c 1.05 > > SIMD implementations that in the best case improve the speed by 43% > (and in some cases is *slower*) seem barely worth it. One would expect > a proper SIMD implementation to offer 100% or higher increases, at > least thats the general expectation on x86 with SSE/AVX. It sounds like you have either forgotten or never learned a very basic principle of computer architecture. I recommend the text by Patterson and Hennessey. The principle is Amdahl's Law. Before you start throwing numbers around, make sure you understand what was being parallelized. > So the question here is - is thats VSX being bad, or the intrinsics > being bad? How would the speedup be in proper hand-written ASM? > If hand-written ASM can give us the usual 100-200% improvements we would > expect from SIMD, then this is what should generally be favored. I am not got to write assembly just so you get a nice fuzzy feeling. If that's a deal-breaker, so be it. > Also, one further thought: > From the commit message, it sounds like you might only be doing this > for the bounty in #5570, do you plan to maintain these optimizations > in the future? Unless you are a mind reader, STFU about my motivation in writing code. One other thing: why didn't this come up when the earlier patch was submitted and applied? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] core infrastructure badge for FFmpeg
On 06 Jul, Ganesh Ajjanagadde wrote : > > But, you could at least be a bit more truthful when filling it: > > - the buildsystem is not common tools, since you have your own > > configure (it's a SUGGESTED thing anyway) > > As far as I know, shell script is a common tool available on POSIX platforms. This is not what they mean: They mention "For example, Maven, Ant, cmake, the autotools, make, or rake". Else, they would mention shell script, since it's the base of many of those tools. A custom script is not a common build system tool. > > - the new functionnality testing is only done in libavcodec, > > I did not assert to the contrary, but it is certainly an "informal" policy > per the dev docs. > I did acknowledge the lack of tests in certain places such as libavfilter. Not only libavfilter. > > - half of the links given are over github, which is not FLOSS and is > > just a mirror... And other on ffmpeg.org > > So what? There is no requirement that the links must be posted on FLOSS sites, > whatever that means which you conveniently leave unspecified. > > The purpose of the mirror here is just as a reference point, and can always > be changed. > There is some lack of consistency in link usage, I am going to change it. I just mean that this is not coherent. Especially on something that is not controlled by you. > > - you do not use SEMVER (it's a SUGGESTED improvement too) > > I thought we did, since that is what I assumed the chicanery regarding major, > minor, etc was all about. > Will amend. SEMVER is stupid anyway. > > - everything related to external users should be N/A and not "met", > > (I doubt they mean trac here) > > Please be more explicit here. What is wrong with trac as a link for a bug > tracker? Good cryptographic practices, questions 8 and 9 should be "N/A", not "met": you don't store users credential, as you say in the comment. > > - where is written the policy that coverity must be run on each release? > > No policy, but Michael did say that "we do run coverity around the release > time generally". > From my experience over the last 6 months, Coverity was run at least once > before each release. > If there was an instance where it was not, sure, I will remove it. "said" and "policy" are different things, notably for MUST items. -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.
On Wed, Jul 06, 2016 at 07:28:27AM -0500, Dan Parrot wrote: [...] > > Also, one further thought: > > From the commit message, it sounds like you might only be doing this > > for the bounty in #5570, do you plan to maintain these optimizations > > in the future? > > Unless you are a mind reader, STFU about my motivation in writing code. > It's probably not a good idea for the project to accept a thousand lines of code for a niche architecture which no one is going to maintain, that's why the question was asked. swscale might get some improvements in the future, and the people doing eventual refactorings will probably be blocked into doing it because the project is known for keeping this kind of stuff in forever. And of course, they probably won't have an easy way of testing if there is no maintainer to give them a hand. Finally, given the hostile reaction and the very relative speed up, it doesn't look like this contribution is going to benefit the project. This is my personal opinion, which might not be shared by the other developers. Regards, -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Submitting patches.
Is there a FAQ or other documentation on how to submit patches? There's a compiler warning that's driving me nuts and I'd like to clean it up if I can. Thank you, Mike ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] core infrastructure badge for FFmpeg
On Wed, Jul 6, 2016 at 2:51 PM, Jean-Baptiste Kempf wrote: > On 06 Jul, Ganesh Ajjanagadde wrote : >> > But, you could at least be a bit more truthful when filling it: >> > - the buildsystem is not common tools, since you have your own >> >configure (it's a SUGGESTED thing anyway) >> >> As far as I know, shell script is a common tool available on POSIX platforms. > > This is not what they mean: > They mention "For example, Maven, Ant, cmake, the autotools, make, or > rake". Else, they would mention shell script, since it's the base of > many of those tools. > A custom script is not a common build system tool. Well we do use make to build! :) - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter/af_hdcd.c: Collect HDCD stats and report
On 7/5/16, Burt P. wrote: > Attached is the fourth version of this patch. I've reworked it > a bit to make it cleaner and provide more interesting/useful > information. Also, I've updated the documentation. > This includes the fix to low-level gain adjustment. > > Thanks. > lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Submitting patches.
On Wed, Jul 6, 2016 at 2:55 PM, Mike Lieman wrote: > Is there a FAQ or other documentation on how to submit patches? There's a > compiler warning that's driving me nuts and I'd like to clean it up if I > can. > http://ffmpeg.org/developer.html#Submitting-patches Its really not all that complicated. Clone the git repository, make your change and commit it with a useful message (ideally explaining reasoning and all that - might not apply when fixing compiler warnigns), and use git send-email or git format-patch to send it to this ML. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] core infrastructure badge for FFmpeg
06.07.2016, 08:51, "Jean-Baptiste Kempf" : > On 06 Jul, Ganesh Ajjanagadde wrote : >> > But, you could at least be a bit more truthful when filling it: >> > - the buildsystem is not common tools, since you have your own >> > configure (it's a SUGGESTED thing anyway) >> >> As far as I know, shell script is a common tool available on POSIX >> platforms. > > This is not what they mean: > They mention "For example, Maven, Ant, cmake, the autotools, make, or > rake". Else, they would mention shell script, since it's the base of > many of those tools. > A custom script is not a common build system tool. How configure.ac that gets fed into autotools etc is acceptable and configure is not is beyond me. As for their meaning, I don't know. >> > - the new functionnality testing is only done in libavcodec, >> >> I did not assert to the contrary, but it is certainly an "informal" policy >> per the dev docs. >> I did acknowledge the lack of tests in certain places such as libavfilter. > > Not only libavfilter. So you want me to change from "libavfilter" to "everything except libavcodec"? Note that it is anyway marked as "not met". >> > - half of the links given are over github, which is not FLOSS and is >> > just a mirror... And other on ffmpeg.org >> >> So what? There is no requirement that the links must be posted on FLOSS >> sites, >> whatever that means which you conveniently leave unspecified. >> >> The purpose of the mirror here is just as a reference point, and can >> always be changed. >> There is some lack of consistency in link usage, I am going to change it. > > I just mean that this is not coherent. Especially on something that is > not controlled by you. Changed, all gratuitous github links have been amended. Thanks. >> > - you do not use SEMVER (it's a SUGGESTED improvement too) >> >> I thought we did, since that is what I assumed the chicanery regarding >> major, minor, etc was all about. >> Will amend. > > SEMVER is stupid anyway. Amended. >> > - everything related to external users should be N/A and not "met", >> > (I doubt they mean trac here) >> >> Please be more explicit here. What is wrong with trac as a link for a bug >> tracker? > > Good cryptographic practices, questions 8 and 9 should be "N/A", not > "met": you don't store users credential, as you say in the comment. So you are saying that regarding RNG, Q9 is referring to internal use by the project infrastructure? Otherwise I don't see how it is "N/A"; it is either met or not. >> > - where is written the policy that coverity must be run on each release? >> >> No policy, but Michael did say that "we do run coverity around the release >> time generally". >> From my experience over the last 6 months, Coverity was run at least once >> before each release. >> If there was an instance where it was not, sure, I will remove it. > > "said" and "policy" are different things, notably for MUST items. Ok, changed to "not met" for now. > -- > Jean-Baptiste Kempf > http://www.jbkempf.com/ - +33 672 704 734 > Sent from my Electronic Device > ___ > 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] core infrastructure badge for FFmpeg
On 06 Jul, Ganesh Ajjanagadde wrote : > > A custom script is not a common build system tool. > > How configure.ac that gets fed into autotools etc is acceptable and configure > is not is beyond me. > As for their meaning, I don't know. Ask them. But, even if your configure is good, it's not a common tool for builds (SUGGESTED anyway.) > > Not only libavfilter. > > So you want me to change from "libavfilter" to "everything except libavcodec"? > Note that it is anyway marked as "not met". I'd say so, yes. > > Good cryptographic practices, questions 8 and 9 should be "N/A", not > > "met": you don't store users credential, as you say in the comment. > > So you are saying that regarding RNG, Q9 is referring to internal use by the > project infrastructure? > Otherwise I don't see how it is "N/A"; it is either met or not. No, I am speaking about the 2 questions about storing users credential. FFmpeg does not do it, because these questions are related to (web)servers. But it seems it was changed already in the meantime. With my kindest regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mediacodecdec_h264: properly convert extradata to annex-b
On Tue, Jul 05, 2016 at 09:47:51AM +0200, Benoit Fouet wrote:
> Hi,
>
> On 04/07/2016 10:12, Matthieu Bouron wrote:
> > From: Matthieu Bouron
> >
> > H264ParamSets has its SPS/PPS stored raw (SODB) and needs to be
> > converted to NAL units before sending them to MediaCodec.
> >
> > This patch adds the missing convertion of the SPS/PPS from SOBP to RBSP
> > which makes the resulting NAL units correct.
> >
> > Fixes codec initialization on Nexus 4 and Nexus 7.
> > ---
> > libavcodec/mediacodecdec_h264.c | 69
> > +
> > 1 file changed, 56 insertions(+), 13 deletions(-)
> >
> > diff --git a/libavcodec/mediacodecdec_h264.c
> > b/libavcodec/mediacodecdec_h264.c
> > index 0664e49..f07c7cc 100644
> > --- a/libavcodec/mediacodecdec_h264.c
> > +++ b/libavcodec/mediacodecdec_h264.c
> > @@ -65,6 +65,54 @@ static av_cold int
> > mediacodec_decode_close(AVCodecContext *avctx)
> > return 0;
> > }
> > +static int h264_ps_to_nalu(const uint8_t *src, int src_size, uint8_t
> > **out, int *out_size)
> > +{
> > +int i;
> > +int ret = 0;
> > +uint8_t *p = NULL;
> > +static const uint8_t nalu_header[] = { 0x00, 0x00, 0x00, 0x01 };
> > +
> > +if (!out) {
> > +return AVERROR(EINVAL);
> > +}
> > +
>
> out_size should also be checked
>
> > +*out_size = sizeof(nalu_header) + src_size;
> > +*out = p = av_malloc(*out_size);
> > +if (!*out) {
> > +return AVERROR(ENOMEM);
> > +}
> > +
>
> nit: the size affectation could be done once the allocation is OK.
>
> > +memcpy(p, nalu_header, sizeof(nalu_header));
> > +memcpy(p + sizeof(nalu_header), src, src_size);
> > +
> > +/* Escape 0x00, 0x00, 0x0{0-3} pattern */
> > +for (i = 4; i < *out_size; i++) {
> > +if (i < *out_size - 3 &&
> > +p[i + 0] == 0 &&
> > +p[i + 1] == 0 &&
> > +p[i + 2] <= 3) {
> > +uint8_t *new;
> > +
> > +*out_size += 1;
> > +new = av_realloc(*out, *out_size);
> > +if (!new) {
> > +ret = AVERROR(ENOMEM);
> > +goto done;
> > +}
> > +*out = p = new;
> > +
> > +i = i + 3;
> > +memmove(p + i, p + i - 1, *out_size - i);
> > +p[i - 1] = 0x03;
> > +}
> > +}
> > +done:
> > +if (ret < 0)
> > +av_freep(out);
> > +
> > +return ret;
> > +}
> > +
> > static av_cold int mediacodec_decode_init(AVCodecContext *avctx)
> > {
> > int i;
> > @@ -112,24 +160,19 @@ static av_cold int
> > mediacodec_decode_init(AVCodecContext *avctx)
> > }
> > if (pps && sps) {
> > -static const uint8_t nal_headers[] = { 0x00, 0x00, 0x00, 0x01 };
> > -
> > uint8_t *data = NULL;
> > -size_t data_size = sizeof(nal_headers) + FFMAX(sps->data_size,
> > pps->data_size);
> > +size_t data_size = 0;
> > -data = av_mallocz(data_size);
> > -if (!data) {
> > -ret = AVERROR(ENOMEM);
> > +if ((ret = h264_ps_to_nalu(sps->data, sps->data_size, &data,
> > &data_size)) < 0) {
> > goto done;
> > }
> > +ff_AMediaFormat_setBuffer(format, "csd-0", (void*)data, data_size);
> > +av_freep(&data);
> > -memcpy(data, nal_headers, sizeof(nal_headers));
> > -memcpy(data + sizeof(nal_headers), sps->data, sps->data_size);
> > -ff_AMediaFormat_setBuffer(format, "csd-0", (void*)data,
> > sizeof(nal_headers) + sps->data_size);
> > -
> > -memcpy(data + sizeof(nal_headers), pps->data, pps->data_size);
> > -ff_AMediaFormat_setBuffer(format, "csd-1", (void*)data,
> > sizeof(nal_headers) + pps->data_size);
> > -
> > +if ((ret = h264_ps_to_nalu(pps->data, pps->data_size, &data,
> > &data_size)) < 0) {
> > +goto done;
> > +}
> > +ff_AMediaFormat_setBuffer(format, "csd-1", (void*)data, data_size);
> > av_freep(&data);
> > } else {
> > av_log(avctx, AV_LOG_ERROR, "Could not extract PPS/SPS from
> > extradata");
>
> LGTM otherwise
Patch updated (taking into accounts your comments) and pushed.
Thanks for the review,
Matthieu
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.
Hi,
On Tue, Jul 5, 2016 at 10:37 PM, Dan Parrot wrote:
> rgb24ToY_c 0.92
OK, so let's be data-driven from now on, I really don't like this
name-calling and stuff. Your speedup on average is close to 1, so let's
compare this to x86. I ran this patch:
diff --git a/libswscale/hscale.c b/libswscale/hscale.c
index eca0635..5d0b39d 100644
--- a/libswscale/hscale.c
+++ b/libswscale/hscale.c
@@ -105,7 +105,9 @@ static int lum_convert(SwsContext *c,
SwsFilterDescriptor *desc, int sliceY, int
uint8_t * dst = desc->dst->plane[0].line[i];
if (c->lumToYV12) {
+START_TIMER
c->lumToYV12(dst, src[0], src[1], src[2], srcW, pal);
+STOP_TIMER("rgb24toy");
} else if (c->readLumPlanar) {
c->readLumPlanar(dst, src, srcW, c->input_rgb2yuv_table);
}
And then I ran these commandlines:
$ ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt
yuv420p -f null -vframes 100 -v error -nostats - 2>&1 | tail -n1
13890 decicycles in rgb24toy, 65428 runs,108 skips
$ ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -cpuflags 0 -s hd1080 -i /dev/zero
-pix_fmt yuv420p -f null -vframes 100 -v error -nostats - 2>&1 | tail -n1
62186 decicycles in rgb24toy, 65497 runs, 39 skips
As you can see, I get a ~4x speedup in this function from the SIMD from an
AVX function (ff_rgb24ToY_avx) instead of the C equivalent (rgb24ToY_c),
which has a register width of 16 bytes (i.e. not avx2). For PPC64, which
has equal register width in its altivec instruction set, I'd expect a
roughly equal speedup.
I now want to figure out why you're not seeing a ~4x speedup in your
altivec/ppc64 implementation of rgb24ToY, and hopefully that can serve as a
template for understanding why in general, you're not seeing any speedups.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.
On 06/07/16 13:28, Dan Parrot wrote: > On Wed, 2016-07-06 at 09:07 +0200, Hendrik Leppkes wrote: >> On Wed, Jul 6, 2016 at 4:37 AM, Dan Parrot wrote: >>> Finish providing SIMD versions for POWER8 VSX of functions in >>> libswscale/input.c That should allow trac ticket #5570 to be closed. >>> The speedups obtained for the functions are: >>> >>> abgrToA_c 1.19 >>> bgr24ToUV_c 1.23 >>> bgr24ToUV_half_c1.37 >>> bgr24ToY_c_vsx 1.43 >>> nv12ToUV_c 1.05 >>> nv21ToUV_c 1.06 >>> planar_rgb_to_uv1.25 >>> planar_rgb_to_y 1.26 >>> rgb24ToUV_c 1.11 >>> rgb24ToUV_half_c1.10 >>> rgb24ToY_c 0.92 >>> rgbaToA_c 0.88 >>> uyvyToUV_c 1.05 >>> uyvyToY_c 1.15 >>> yuy2ToUV_c 1.07 >>> yuy2ToY_c 1.17 >>> yvy2ToUV_c 1.05 >> >> SIMD implementations that in the best case improve the speed by 43% >> (and in some cases is *slower*) seem barely worth it. One would expect >> a proper SIMD implementation to offer 100% or higher increases, at >> least thats the general expectation on x86 with SSE/AVX. > It sounds like you have either forgotten or never learned a very basic > principle of computer architecture. I recommend the text by Patterson > and Hennessey. The principle is Amdahl's Law. Before you start throwing > numbers around, make sure you understand what was being parallelized. Right, it's being parallelised to 4x or 8x SIMD in vector registers. If the computation is processor-bound, we would expect a gain close to that, minus a bit of overhead for awkwardness around rearranging the data (generally 2x or more, but dependent on the exact cases). The bits of code I looked at appear to cleanly implement that, so I am surprised that the improvement does not match what we expect. Some possible explanations for this: * There is some problem with the code. It looks clean and sensible to me, though I am not an expert on PPC. Maybe there is some large state-transition hazard which I am not aware of, similar to problems with mixing AVX and SSE on Intel? * The computation is actually bounded by something other than the CPU. For example, memory - that seems unlikely, but I guess it's possible. Can we measure that to rule it out? * The compiler is doing a bad job with the intrinsics. Do we believe that any other compiler would do better, and can we test with that one instead? If so, perhaps we could whitelist compilers known to do sensible things with these intrinsics and keep the vanilla C implementation on others. I imagine there are more possibilities. It's more the fact that the results are not as expected and include some regressions which makes me want to understand what is going on, not that I believe that the code itself necessarily contains any issues. >> So the question here is - is thats VSX being bad, or the intrinsics >> being bad? How would the speedup be in proper hand-written ASM? >> If hand-written ASM can give us the usual 100-200% improvements we would >> expect from SIMD, then this is what should generally be favored. > I am not got to write assembly just so you get a nice fuzzy feeling. If > that's a deal-breaker, so be it. Assembly is not directly relevant, though if it would be possible to write some for one of the important cases (rgb24toY, say) then it could form a useful comparison to determine what is going on with the intrinsic implementation. >> Also, one further thought: >> From the commit message, it sounds like you might only be doing this >> for the bounty in #5570, do you plan to maintain these optimizations >> in the future? > > Unless you are a mind reader, STFU about my motivation in writing code. Your direct motivation is not relevant, but your intent or not to maintain this code in future is. A sensible first implementation with little real gain (as this appears to be from what I can tell so far) is I think reasonable to accept if further work to improve it is intended to happen in future, but if we do not anticipate that then some orphaned code fragments with no clear benefit are unlikely to be a useful thing to have in the tree. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.
Hi,
ok, so let's review your implementation of rgb24toY:
On Tue, Jul 5, 2016 at 10:37 PM, Dan Parrot wrote:
> +static void rgb24ToY_c_vsx(uint8_t *_dst, const uint8_t *src, const
> uint8_t *unused1, const uint8_t *unused2,
> + int width, uint32_t *rgb2yuv)
> +{
> +//START_TIMER;
>
OK, we have to start with basics here (why didn't anyone review this
properly?):
- remove commented code (START_TIMER)
- this is not a c function, so it should not have a _c suffix or _c as part
of its suffix. Please rename to rgb24ToY_vsx.
Performance basics:
- it is _really_ important to do _identical_ speed comparisons between C
and SIMD. Therefore, the START/STOP_TIMER should be in the caller (i.e. in
hscale.c where it calls lumToYV12()), not in the callee.
> +for (i = 0; i < width_adj; i += 8) {
> +v_rd0 = vec_vsx_ld(0, (unsigned char *)src_addr);
> +v_rd1 = vec_vsx_ld(0, (unsigned char *)(src_addr + 16));
> +src_addr += 24;
> +
> +for (j = 0; j < 2; j++) {
> +v_tmpr = vec_perm(v_rd0, v_rd0, ((vector unsigned char)
> + {0, 3, 6, 9, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0}));
> +v_tmpg = vec_perm(v_rd0, v_rd0, ((vector unsigned char)
> + {1, 4, 7, 10, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0}));
> +v_tmpb = vec_perm(v_rd0, v_rd0, ((vector unsigned char)
> + {2, 5, 8, 11, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0}));
> +
> +v_rd0 = vec_perm(v_rd0, v_rd1, ((vector unsigned char)
> +{12, 13, 14, 15, 16, 17, 18,
> 19, 20, 21, 22, 23, 0, 0, 0, 0}));
>
Why are you loading 24 bytes (8 pixels), using only 12 bytes (4 pixels) in
your inner loop, and then shifting your pixels within the register to "make
it work"? The proper way to do this is to:
- hand-unroll the code so the inner loop handles all 8 pixels (24 bytes)
without this vec_perm
- load only 4 pixels so you don't need to vec_perm
In both cases, you should not have this vec_perm here. As cute as it looks,
data manipulation (like shuffling - which is what vec_perm does) should be
minimized or removed entirely for optimal simd code.
+v_tmp_s = vec_unpackh((vector signed char)v_tmpr);
> +v_tmp_s = vec_and(v_tmp_s, vec_splats((short)0x0ff));
> +v_r = vec_unpackh(v_tmp_s);
> +v_tmp_s = vec_unpackh((vector signed char)v_tmpg);
> +v_tmp_s = vec_and(v_tmp_s, vec_splats((short)0x0ff));
> +v_g = vec_unpackh(v_tmp_s);
> +v_tmp_s = vec_unpackh((vector signed char)v_tmpb);
> +v_tmp_s = vec_and(v_tmp_s, vec_splats((short)0x0ff));
> +v_b = vec_unpackh(v_tmp_s);
>
vec_splats should be outside the loop.
Shuffling like vec_unpackh should be done as part of the vec_perm. Multiple
permutations on the same data are never a good idea, particularly with
free-form reshuffling instructions like vec_perm which can go essentially
form any to any. Don't forget that 12 out of 16 bytes in v_tmpr/g/b are
unused, so you might just as well do something useful with them.
> +vector unsigned v_opr1 =
> vec_splats((unsigned)(RGB2YUV_SHIFT-1));
> +vector unsigned v_opr2 =
> vec_splats((unsigned)(RGB2YUV_SHIFT-7));
> +vector unsigned v_opr3 =
> vec_splats((unsigned)(RGB2YUV_SHIFT-6));
>
vec_splats outside loop.
> +v_rslt = v_ry*v_r + v_gy*v_g + v_by*v_b;
>
Is this SIMD'ed? Can you show disassembly? I wouldn't be surprised if the
compiler screws this up.
Which multiply instructions exist (at word level) for ppc64/vsx? Can you
interleave and multiply (like x86 pmaddwd)? In that case, the interleave
should be done as part of the vec_perm also. See x86 SIMD for examples
(input.asm).
> +v_rslt += vec_sl(vec_splats((int)32), v_opr1);
> +v_rslt += vec_sl(vec_splats((int)1), v_opr2);
>
vec_splats outside loop.
> +v_rslt = vec_sr(v_rslt, v_opr3);
> +
> +v_tmp_s = vec_pack(v_rslt, v_rslt);
>
So here's why the x86 code unrolls to 8 pixels per iteration: it saves a
store. But that only helps if you actually pack 2 sets of 4 pixels - and
ideally interleave the instructions doing the 4 pixels per iteration in the
inner loop. You should do that here also.
> +v_dst = vec_sld(v_dst, v_tmp_s, 8);
> +}
> +v_dst = vec_sld(v_dst, v_dst, 8);
>
The vec_slds should be merged.
> +//STOP_TIMER("rgb24ToY_c_vsx");
>
Remove commented code.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.
Hi, On Wed, Jul 6, 2016 at 10:14 AM, Ronald S. Bultje wrote: > +v_rslt += vec_sl(vec_splats((int)32), v_opr1); >> +v_rslt += vec_sl(vec_splats((int)1), v_opr2); >> > > vec_splats outside loop. > While we're at it, is the += SIMD'ed? And why aren't v_opr1/2 merged in a single variable to save an add? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/libx265: Support gray encoding
On Thursday 12 May 2016 05:40:36 pm Derek Buitenhuis wrote: > On 5/12/2016 4:18 PM, Carl Eugen Hoyos wrote: > > The feature is not new (and the necessary define in the header > > was always there) but it did not work (at least for some > > revisions). > > How should I proceed? > > Hmm. > > I'm not really a fan of bumping up the required x265 version, > since it has been stable for a good amount of time now... > > One option is to add something like: > if (VERSION < SOMEVERSION) > goto fail; Pushed with such a check. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Submitting patches.
On Wed, 6 Jul 2016 15:03:07 +0200, Hendrik Leppkes wrote: > http://ffmpeg.org/developer.html#Submitting-patches Also see: http://ffmpeg.org/git-howto.html ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/exr : add support for gray and gray A file
On 7/5/16, Martin Vignali wrote: > 2016-06-28 0:05 GMT+02:00 Martin Vignali : > >> Hello, >> >> in attach a patch to add support for Y and YA exr file >> (ticket #5621) >> >> sample can be found in this ticket, >> https://trac.ffmpeg.org/ticket/5621 >> >> or in the official samples >> >> http://download.savannah.nongnu.org/releases/openexr/openexr-images-1.7.0.tar.gz >> >> pass exr fate test. >> >> >> The second patch is only indent. >> >> >> Comments welcome >> >> Martin >> Jokyo Images >> > > > Ping > lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add split_by_time flag for support splite mpegts segment at non-keyframe
On Wed, Jul 06, 2016 at 05:57:57PM +0800, Steven Liu wrote: > support split hls segment at duration set by hls_time > > after the patch , the ffmpeg can split the mpegts for hls by hls_time > parameter > > [root@localhost ffmpeg]# ./ffmpeg -i /root/facebook.mp4 -v quiet -c copy -f > hls -hls_time 3 -hls_flags split_by_time -bsf:v h264_mp4toannexb > -hls_list_size 20 -t 30 output_afterpatch.m3u8 > [root@localhost ffmpeg]# > [root@localhost ffmpeg]# > [root@localhost ffmpeg]# cat output_afterpatch.m3u8 > #EXTM3U > #EXT-X-VERSION:3 > #EXT-X-TARGETDURATION:4 > #EXT-X-MEDIA-SEQUENCE:0 > #EXTINF:3.04, > output_afterpatch0.ts > #EXTINF:3.16, > output_afterpatch1.ts > #EXTINF:2.84, > output_afterpatch2.ts > #EXTINF:3.16, > output_afterpatch3.ts > #EXTINF:2.88, > output_afterpatch4.ts > #EXTINF:3.08, > output_afterpatch5.ts > #EXTINF:2.92, > output_afterpatch6.ts > #EXTINF:3.12, > output_afterpatch7.ts > #EXTINF:2.88, > output_afterpatch8.ts > #EXTINF:2.96, > output_afterpatch9.ts > #EXTINF:-0.04, > output_afterpatch10.ts > #EXT-X-ENDLIST > > > support split hls segment at duration set by hls_time > > Signed-off-by: LiuQi > --- > libavformat/hlsenc.c |4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) missing update to the documentation [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter/af_hdcd.c: Collect HDCD stats and report
On Wed, Jul 06, 2016 at 03:01:00PM +0200, Paul B Mahol wrote: > On 7/5/16, Burt P. wrote: > > Attached is the fourth version of this patch. I've reworked it > > a bit to make it cleaner and provide more interesting/useful > > information. Also, I've updated the documentation. > > This includes the fix to low-level gain adjustment. > > > > Thanks. > > > > lgtm applied thanks [...] -- 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: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Outreachy 2016 december
Hi all The next Outreachy round starts soon FFmpeg has till august 22 IIUC (https://www.gnome.org/outreachy/) to express interrest to participate. We need an admin and backup admins. They need to create the wiki page(s) for this round, and make sure the pages are in shape by the time applicants start pouring in. make sure applicants questions (like "[FFmpeg-devel] need guidance") get awnsered recruite mentors, secure funding (as in confirming with the community and stefano that SPI/FFIS funding can be used for one slot or find another sponsor) contact the Outreachy admins and express that FFmpeg wants to participate, ... Reply to any questions the outreachy admins have Make sure that during the project nothing goes wrong like a mentor disappearing and if something goes wrong deal with it -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/exr : add support for gray and gray A file
On Wed, Jul 06, 2016 at 09:12:54PM +0200, Paul B Mahol wrote: > On 7/5/16, Martin Vignali wrote: > > 2016-06-28 0:05 GMT+02:00 Martin Vignali : > > > >> Hello, > >> > >> in attach a patch to add support for Y and YA exr file > >> (ticket #5621) > >> > >> sample can be found in this ticket, > >> https://trac.ffmpeg.org/ticket/5621 > >> > >> or in the official samples > >> > >> http://download.savannah.nongnu.org/releases/openexr/openexr-images-1.7.0.tar.gz > >> > >> pass exr fate test. > >> > >> > >> The second patch is only indent. > >> > >> > >> Comments welcome > >> > >> Martin > >> Jokyo Images > >> > > > > > > Ping > > > > lgtm applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] libavcodec/dnxhd: added dnxhr profiles
On Wed, Jul 6, 2016 at 2:31 AM, Rostislav Pehlivanov
wrote:
> On 6 July 2016 at 03:46, Mark Reid wrote:
>
>> ---
>> libavcodec/avcodec.h| 7 +++
>> libavcodec/codec_desc.c | 1 +
>> libavcodec/dnxhddec.c | 20
>> libavcodec/profiles.c | 10 ++
>> libavcodec/profiles.h | 1 +
>> 5 files changed, 39 insertions(+)
>>
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index 39713ed..8f84fd0 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -3165,6 +3165,13 @@ typedef struct AVCodecContext {
>> #define FF_PROFILE_MPEG2_AAC_LOW 128
>> #define FF_PROFILE_MPEG2_AAC_HE 131
>>
>> +#define FF_PROFILE_DNXHD 0
>> +#define FF_PROFILE_DNXHR_LB 1
>> +#define FF_PROFILE_DNXHR_SQ 2
>> +#define FF_PROFILE_DNXHR_HQ 3
>> +#define FF_PROFILE_DNXHR_HQX 4
>> +#define FF_PROFILE_DNXHR_444 5
>> +
>> #define FF_PROFILE_DTS 20
>> #define FF_PROFILE_DTS_ES 30
>> #define FF_PROFILE_DTS_96_24 40
>> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
>> index 9d94b72..e6b8bbc 100644
>> --- a/libavcodec/codec_desc.c
>> +++ b/libavcodec/codec_desc.c
>> @@ -665,6 +665,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
>> .name = "dnxhd",
>> .long_name = NULL_IF_CONFIG_SMALL("VC3/DNxHD"),
>> .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
>> +.profiles = NULL_IF_CONFIG_SMALL(ff_dnxhd_profiles),
>> },
>> {
>> .id= AV_CODEC_ID_THP,
>> diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
>> index 1808080..33dfec2 100644
>> --- a/libavcodec/dnxhddec.c
>> +++ b/libavcodec/dnxhddec.c
>> @@ -33,6 +33,7 @@
>> #include "dnxhddata.h"
>> #include "idctdsp.h"
>> #include "internal.h"
>> +#include "profiles.h"
>> #include "thread.h"
>>
>> typedef struct RowContext {
>> @@ -567,6 +568,23 @@ static int dnxhd_decode_row(AVCodecContext *avctx,
>> void *data,
>> return 0;
>> }
>>
>> +static int dnxhd_get_profile(int cid)
>> +{
>> +switch(cid) {
>> +case 1270:
>> +return FF_PROFILE_DNXHR_444;
>> +case 1271:
>> +return FF_PROFILE_DNXHR_HQX;
>> +case 1272:
>> +return FF_PROFILE_DNXHR_HQ;
>> +case 1273:
>> +return FF_PROFILE_DNXHR_SQ;
>> +case 1274:
>> +return FF_PROFILE_DNXHR_LB;
>> +}
>> +return FF_PROFILE_DNXHD;
>> +}
>> +
>> static int dnxhd_decode_frame(AVCodecContext *avctx, void *data,
>>int *got_frame, AVPacket *avpkt)
>> {
>> @@ -600,6 +618,7 @@ decode_coding_unit:
>> }
>>
>> avctx->pix_fmt = ctx->pix_fmt;
>> +avctx->profile = dnxhd_get_profile(ctx->cid);
>> ret = ff_set_dimensions(avctx, ctx->width, ctx->height);
>> if (ret < 0)
>> return ret;
>> @@ -692,4 +711,5 @@ AVCodec ff_dnxhd_decoder = {
>> .capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS |
>>AV_CODEC_CAP_SLICE_THREADS,
>> .init_thread_copy =
>> ONLY_IF_THREADS_ENABLED(dnxhd_decode_init_thread_copy),
>> +.profiles = NULL_IF_CONFIG_SMALL(ff_dnxhd_profiles),
>> };
>> diff --git a/libavcodec/profiles.c b/libavcodec/profiles.c
>> index da745e1..07fb6d6 100644
>> --- a/libavcodec/profiles.c
>> +++ b/libavcodec/profiles.c
>> @@ -46,6 +46,16 @@ const AVProfile ff_dca_profiles[] = {
>> { FF_PROFILE_UNKNOWN },
>> };
>>
>> +const AVProfile ff_dnxhd_profiles[] = {
>> + { FF_PROFILE_DNXHD, "DNXHD"},
>> + { FF_PROFILE_DNXHR_LB, "DNXHR LB"},
>> + { FF_PROFILE_DNXHR_SQ, "DNXHR SQ"},
>> + { FF_PROFILE_DNXHR_HQ, "DNXHR HQ" },
>> + { FF_PROFILE_DNXHR_HQX, "DNXHR HQX"},
>> + { FF_PROFILE_DNXHR_444, "DNXHR 444"},
>> + { FF_PROFILE_UNKNOWN },
>> +};
>> +
>> const AVProfile ff_h264_profiles[] = {
>> { FF_PROFILE_H264_BASELINE, "Baseline" },
>> { FF_PROFILE_H264_CONSTRAINED_BASELINE, "Constrained Baseline" },
>> diff --git a/libavcodec/profiles.h b/libavcodec/profiles.h
>> index c86c683..eb18b40 100644
>> --- a/libavcodec/profiles.h
>> +++ b/libavcodec/profiles.h
>> @@ -23,6 +23,7 @@
>>
>> extern const AVProfile ff_aac_profiles[];
>> extern const AVProfile ff_dca_profiles[];
>> +extern const AVProfile ff_dnxhd_profiles[];
>> extern const AVProfile ff_h264_profiles[];
>> extern const AVProfile ff_hevc_profiles[];
>> extern const AVProfile ff_jpeg2000_profiles[];
>> --
>> 2.7.3
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> This looks fine to me.
> Have you checked that you can still retrieve the profile from libavformat
> for the mov muxer?
Yes, the profiles come through mov muxer. but I think I've come up
with something even simpler now, without needing a profile. So I'll
drop this for now and send a new patch.
___
ffmpeg-devel mailing list
ffmp
[FFmpeg-devel] [PATCH v3] libavformat/movenc: add dnxhr compatibility for apple players
Hi, This version drops the need for profiles completely. Muxing also works of 12bit formats as well. https://dl.dropboxusercontent.com/u/170952/ffmpeg_samples/mxf/UHD/lb_uhd.mxf https://dl.dropboxusercontent.com/u/170952/ffmpeg_samples/mxf/UHD/hqx_uhd.mxf ffmpeg -i lb_uhd.mxf -vcodec copy out.mov Mark Reid (1): libavformat/movenc: add dnxhr compatibility for apple players libavcodec/dnxhddec.c | 3 +++ libavformat/movenc.c | 19 ++- 2 files changed, 17 insertions(+), 5 deletions(-) -- 2.7.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3] libavformat/movenc: add dnxhr compatibility for apple players
---
libavcodec/dnxhddec.c | 3 +++
libavformat/movenc.c | 19 ++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 1808080..b310e3e 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -204,6 +204,9 @@ static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame
*frame,
}
cid = AV_RB32(buf + 0x28);
+if (cid >= 1270 || cid <= 1274)
+ctx->avctx->codec_tag = MKTAG('A','V','d','h');
+
if ((ret = dnxhd_init_vlc(ctx, cid, bitdepth)) < 0)
return ret;
if (ctx->mbaff && ctx->cid_table->cid != 1260)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index d614933..7906f83 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -32,6 +32,7 @@
#include "isom.h"
#include "avc.h"
#include "libavcodec/ac3_parser.h"
+#include "libavcodec/dnxhddata.h"
#include "libavcodec/get_bits.h"
#include "libavcodec/put_bits.h"
#include "libavcodec/vc1_common.h"
@@ -1070,11 +1071,7 @@ static int mov_write_avid_tag(AVIOContext *pb, MOVTrack
*track)
int cid;
if (track->vos_data && track->vos_len > 0x29) {
-if (track->vos_data[0] == 0x00 &&
-track->vos_data[1] == 0x00 &&
-track->vos_data[2] == 0x02 &&
-track->vos_data[3] == 0x80 &&
-(track->vos_data[4] == 0x01 || track->vos_data[4] == 0x02)) {
+if (avpriv_dnxhd_parse_header_prefix(track->vos_data) != 0) {
/* looks like a DNxHD bit stream */
interlaced = (track->vos_data[5] & 2);
cid = AV_RB32(track->vos_data + 0x28);
@@ -1099,6 +1096,18 @@ static int mov_write_avid_tag(AVIOContext *pb, MOVTrack
*track)
}
avio_wb32(pb, 0); /* unknown */
+if (track->tag == MKTAG('A','V','d','h')) {
+avio_wb32(pb, 32);
+ffio_wfourcc(pb, "ADHR");
+ffio_wfourcc(pb, "0001");
+avio_wb32(pb, cid);
+avio_wb32(pb, 0); /* unknown */
+avio_wb32(pb, 1); /* unknown */
+avio_wb32(pb, 0); /* unknown */
+avio_wb32(pb, 0); /* unknown */
+return 0;
+}
+
avio_wb32(pb, 24); /* size */
ffio_wfourcc(pb, "APRG");
ffio_wfourcc(pb, "APRG");
--
2.7.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Start of SCTE-35 support [PATCH]
Hi, This patch starts the work on SCTE-35 support; for now it just detects SCTE-35 and if present sends the data to a dummy function. Since it's my first contribution to ffmpeg I preferred to start small and continue working as small pieces of work are accepted or commented. Carlos 0001-SCTE-extraction-from-mpegts.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add split_by_time flag for support splite mpegts segment at non-keyframe
2016-07-07 3:54 GMT+08:00 Michael Niedermayer : > On Wed, Jul 06, 2016 at 05:57:57PM +0800, Steven Liu wrote: > > support split hls segment at duration set by hls_time > > > > after the patch , the ffmpeg can split the mpegts for hls by hls_time > > parameter > > > > [root@localhost ffmpeg]# ./ffmpeg -i /root/facebook.mp4 -v quiet -c > copy -f > > hls -hls_time 3 -hls_flags split_by_time -bsf:v h264_mp4toannexb > > -hls_list_size 20 -t 30 output_afterpatch.m3u8 > > [root@localhost ffmpeg]# > > [root@localhost ffmpeg]# > > [root@localhost ffmpeg]# cat output_afterpatch.m3u8 > > #EXTM3U > > #EXT-X-VERSION:3 > > #EXT-X-TARGETDURATION:4 > > #EXT-X-MEDIA-SEQUENCE:0 > > #EXTINF:3.04, > > output_afterpatch0.ts > > #EXTINF:3.16, > > output_afterpatch1.ts > > #EXTINF:2.84, > > output_afterpatch2.ts > > #EXTINF:3.16, > > output_afterpatch3.ts > > #EXTINF:2.88, > > output_afterpatch4.ts > > #EXTINF:3.08, > > output_afterpatch5.ts > > #EXTINF:2.92, > > output_afterpatch6.ts > > #EXTINF:3.12, > > output_afterpatch7.ts > > #EXTINF:2.88, > > output_afterpatch8.ts > > #EXTINF:2.96, > > output_afterpatch9.ts > > #EXTINF:-0.04, > > output_afterpatch10.ts > > #EXT-X-ENDLIST > > > > > > support split hls segment at duration set by hls_time > > > > Signed-off-by: LiuQi > > --- > > libavformat/hlsenc.c |4 +++- > > 1 files changed, 3 insertions(+), 1 deletions(-) > > missing update to the documentation > > Update the documentation. 0001-add-split_by_time-flag-for-support-splite-mpegts-seg.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/4] Updates for the Ogg muxer to more strictly follow RFC 5334
As the subject says, this patchset aims to make our Ogg muxer more compliant with the latest RFC[1], which is almost eight years old by now. [1] https://tools.ietf.org/html/rfc5334 James Almer (4): avformat/oggenc: make flac the default for oga muxer avformat/oggenc: use audio/ogg mimetype for ogg muxer avformat/oggenc: allow Vorbis audio only with the ogg muxer avformat: add an Ogg Video muxer configure| 1 + libavformat/allformats.c | 1 + libavformat/oggenc.c | 28 ++-- 3 files changed, 24 insertions(+), 6 deletions(-) -- 2.9.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] avformat/oggenc: make Vorbis audio the only default for ogg muxer
While not enforced, RFC 5334 mentions that the .ogg extension should
be used for Vorbis audio files only.
Signed-off-by: James Almer
---
This patch turns the ogg muxer into an audio only muxer to follow
the RFC's recommendation. The next patch in the set adds a new ogv
muxer to properly deal with video files.
I doubt anyone out there tries to mux theora video using the .ogg
extension (even ffmpeg2theora seems to default to .ogv), so it's
unlikely it will affect people's normal workflow.
But if someone is against it then this patch can either be dropped
or changed to only remove flac from the defaults. That way video
can still be muxed.
I personally prefer to apply this patch as is, though.
libavformat/oggenc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavformat/oggenc.c b/libavformat/oggenc.c
index fee4c7f..2dcab15 100644
--- a/libavformat/oggenc.c
+++ b/libavformat/oggenc.c
@@ -669,9 +669,7 @@ AVOutputFormat ff_ogg_muxer = {
#endif
,
.priv_data_size= sizeof(OGGContext),
-.audio_codec = CONFIG_LIBVORBIS_ENCODER ?
- AV_CODEC_ID_VORBIS : AV_CODEC_ID_FLAC,
-.video_codec = AV_CODEC_ID_THEORA,
+.audio_codec = AV_CODEC_ID_VORBIS,
.write_header = ogg_write_header,
.write_packet = ogg_write_packet,
.write_trailer = ogg_write_trailer,
--
2.9.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] avformat/oggenc: use audio/ogg mimetype for ogg muxer
RFC 5334 states that the application/ogg mimetype must include an
Ogg Skeleton stream[1], something we don't currently support.
[1] https://tools.ietf.org/html/rfc5334#section-10.1
Signed-off-by: James Almer
---
libavformat/oggenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/oggenc.c b/libavformat/oggenc.c
index fe1f34d..fee4c7f 100644
--- a/libavformat/oggenc.c
+++ b/libavformat/oggenc.c
@@ -659,7 +659,7 @@ OGG_CLASS(ogg, Ogg)
AVOutputFormat ff_ogg_muxer = {
.name = "ogg",
.long_name = NULL_IF_CONFIG_SMALL("Ogg"),
-.mime_type = "application/ogg",
+.mime_type = "audio/ogg",
.extensions= "ogg,ogv"
#if !CONFIG_SPX_MUXER
",spx"
--
2.9.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] avformat/oggenc: make flac the default for oga muxer
While not enforced, RFC 5334[1] recommends to use the .oga extension
for all audio codecs except Vorbis (.ogg) and Speex (.spx)
RFC 7845[2] also adds Opus (.opus) to this list.
[1] https://tools.ietf.org/html/rfc5334#section-10.3
[2] https://tools.ietf.org/html/rfc7845#section-9
Signed-off-by: James Almer
---
libavformat/oggenc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavformat/oggenc.c b/libavformat/oggenc.c
index f998af3..fe1f34d 100644
--- a/libavformat/oggenc.c
+++ b/libavformat/oggenc.c
@@ -688,8 +688,7 @@ AVOutputFormat ff_oga_muxer = {
.mime_type = "audio/ogg",
.extensions= "oga",
.priv_data_size= sizeof(OGGContext),
-.audio_codec = CONFIG_LIBVORBIS_ENCODER ?
- AV_CODEC_ID_VORBIS : AV_CODEC_ID_FLAC,
+.audio_codec = AV_CODEC_ID_FLAC,
.write_header = ogg_write_header,
.write_packet = ogg_write_packet,
.write_trailer = ogg_write_trailer,
--
2.9.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] avformat: add an Ogg Video muxer
RFC 5334 recommendens this extension to go alongside the video/ogg
mimetype for video files, with or without audio and subtitles [1].
[1] https://tools.ietf.org/html/rfc5334#section-10.2
Signed-off-by: James Almer
---
TODO: Version bump and changelog entry.
configure| 1 +
libavformat/allformats.c | 1 +
libavformat/oggenc.c | 21 -
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 126d0d6..14dde90 100755
--- a/configure
+++ b/configure
@@ -2854,6 +2854,7 @@ nut_muxer_select="riffenc"
nuv_demuxer_select="riffdec"
oga_muxer_select="ogg_muxer"
ogg_demuxer_select="dirac_parse"
+ogv_muxer_select="ogg_muxer"
opus_muxer_select="ogg_muxer"
psp_muxer_select="mov_muxer"
rtp_demuxer_select="sdp_demuxer"
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index d490cc4..418dfff 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -225,6 +225,7 @@ void av_register_all(void)
REGISTER_DEMUXER (NUV, nuv);
REGISTER_MUXER (OGA, oga);
REGISTER_MUXDEMUX(OGG, ogg);
+REGISTER_MUXER (OGV, ogv);
REGISTER_MUXDEMUX(OMA, oma);
REGISTER_MUXER (OPUS, opus);
REGISTER_DEMUXER (PAF, paf);
diff --git a/libavformat/oggenc.c b/libavformat/oggenc.c
index 2dcab15..1acde18 100644
--- a/libavformat/oggenc.c
+++ b/libavformat/oggenc.c
@@ -660,7 +660,7 @@ AVOutputFormat ff_ogg_muxer = {
.name = "ogg",
.long_name = NULL_IF_CONFIG_SMALL("Ogg"),
.mime_type = "audio/ogg",
-.extensions= "ogg,ogv"
+.extensions= "ogg"
#if !CONFIG_SPX_MUXER
",spx"
#endif
@@ -695,6 +695,25 @@ AVOutputFormat ff_oga_muxer = {
};
#endif
+#if CONFIG_OGV_MUXER
+OGG_CLASS(ogv, Ogg video)
+AVOutputFormat ff_ogv_muxer = {
+.name = "ogv",
+.long_name = NULL_IF_CONFIG_SMALL("Ogg Video"),
+.mime_type = "video/ogg",
+.extensions= "ogv",
+.priv_data_size= sizeof(OGGContext),
+.audio_codec = CONFIG_LIBVORBIS_ENCODER ?
+ AV_CODEC_ID_VORBIS : AV_CODEC_ID_FLAC,
+.video_codec = AV_CODEC_ID_THEORA,
+.write_header = ogg_write_header,
+.write_packet = ogg_write_packet,
+.write_trailer = ogg_write_trailer,
+.flags = AVFMT_TS_NEGATIVE | AVFMT_ALLOW_FLUSH,
+.priv_class= &ogv_muxer_class,
+};
+#endif
+
#if CONFIG_SPX_MUXER
OGG_CLASS(spx, Ogg Speex)
AVOutputFormat ff_spx_muxer = {
--
2.9.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [GSoC] MLP/TrueHD encoder
Hi,
This is an update for the TrueHD encoder gsoc project. Any input from the
community about work done till now, or for plans ahead, is most welcome :)
The MLP encoder (patch attached) works without any lossless check errors now on
most samples I've tested on, both for mono and stereo.
Here's the changelog from ramiro's original version of the encoder:
https://github.com/jailuthra/FFmpeg/compare/33c37b86...b4eb87c
The current plan is:
* Support encoding TrueHD bitstreams through mlpenc.c, just like it's done
in mlpdec.c
* Add multi-channel support
* Add FATE tests?
* Send the patch for review and merge
Also while testing how to implement multi-channel support, I noticed that the
LFE channel encoding was not lossless for most samples. Any suggestions on how
to fix this would be helpful.
Cheers,
Jai Luthra (darkapex)
From c73ea99b3cc1759f586eb9d19a4b8b46340e8823 Mon Sep 17 00:00:00 2001
From: Jai Luthra
Date: Wed, 2 Mar 2016 23:08:41 +0530
Subject: [PATCH] mlpenc: Add working encoder
Changes from ramiro's original work:
* Fixing lossless check failures
* Adding support for mono (support for more channels will come soon)
* Removed unused bitcount functions
* Fixing variable length array usages
* Minor updates to use new api
Signed-off-by: Jai Luthra
---
libavcodec/Makefile|1 +
libavcodec/alacenc.c |4 +-
libavcodec/allcodecs.c |2 +-
libavcodec/flacenc.c |3 +-
libavcodec/lpc.c | 13 +-
libavcodec/lpc.h |2 +-
libavcodec/mlp.c | 14 +
libavcodec/mlp.h | 38 +
libavcodec/mlpenc.c| 2470
libavcodec/ra144enc.c |2 +-
10 files changed, 2539 insertions(+), 10 deletions(-)
create mode 100644 libavcodec/mlpenc.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 46dd9e1..d72a48e 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -358,6 +358,7 @@ OBJS-$(CONFIG_MJPEG_ENCODER) += mjpegenc.o mjpegenc_common.o
OBJS-$(CONFIG_MJPEGB_DECODER) += mjpegbdec.o
OBJS-$(CONFIG_MJPEG_VAAPI_ENCODER) += vaapi_encode_mjpeg.o
OBJS-$(CONFIG_MLP_DECODER) += mlpdec.o mlpdsp.o
+OBJS-$(CONFIG_MLP_ENCODER) += mlpenc.o
OBJS-$(CONFIG_MMVIDEO_DECODER) += mmvideo.o
OBJS-$(CONFIG_MOTIONPIXELS_DECODER)+= motionpixels.o
OBJS-$(CONFIG_MOVTEXT_DECODER) += movtextdec.o ass.o
diff --git a/libavcodec/alacenc.c b/libavcodec/alacenc.c
index 9ac35f1..6a887ff 100644
--- a/libavcodec/alacenc.c
+++ b/libavcodec/alacenc.c
@@ -38,6 +38,7 @@
#define DEFAULT_MAX_PRED_ORDER6
#define DEFAULT_MIN_PRED_ORDER4
#define ALAC_MAX_LPC_PRECISION9
+#define ALAC_MIN_LPC_SHIFT0
#define ALAC_MAX_LPC_SHIFT9
#define ALAC_CHMODE_LEFT_RIGHT0
@@ -171,7 +172,8 @@ static void calc_predictor_params(AlacEncodeContext *s, int ch)
s->max_prediction_order,
ALAC_MAX_LPC_PRECISION, coefs, shift,
FF_LPC_TYPE_LEVINSON, 0,
- ORDER_METHOD_EST, ALAC_MAX_LPC_SHIFT, 1);
+ ORDER_METHOD_EST, ALAC_MIN_LPC_SHIFT,
+ ALAC_MAX_LPC_SHIFT, 1);
s->lpc[ch].lpc_order = opt_order;
s->lpc[ch].lpc_quant = shift[opt_order-1];
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 6d0a7e7..f6a99e9 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -410,7 +410,7 @@ void avcodec_register_all(void)
REGISTER_DECODER(MACE3, mace3);
REGISTER_DECODER(MACE6, mace6);
REGISTER_DECODER(METASOUND, metasound);
-REGISTER_DECODER(MLP, mlp);
+REGISTER_ENCDEC (MLP, mlp);
REGISTER_DECODER(MP1, mp1);
REGISTER_DECODER(MP1FLOAT, mp1float);
REGISTER_ENCDEC (MP2, mp2);
diff --git a/libavcodec/flacenc.c b/libavcodec/flacenc.c
index a91ed19..e0f0880 100644
--- a/libavcodec/flacenc.c
+++ b/libavcodec/flacenc.c
@@ -43,6 +43,7 @@
#define MAX_PARTITION_ORDER 8
#define MAX_PARTITIONS (1 << MAX_PARTITION_ORDER)
#define MAX_LPC_PRECISION 15
+#define MIN_LPC_SHIFT 0
#define MAX_LPC_SHIFT 15
enum CodingMode {
@@ -883,7 +884,7 @@ static int encode_residual_ch(FlacEncodeContext *s, int ch)
opt_order = ff_lpc_calc_coefs(&s->lpc_ctx, smp, n, min_order, max_order,
s->options.lpc_coeff_precision, coefs, shift, s->options.lpc_type,
s->options.lpc_passes, omethod,
- MAX_LPC_SHIFT, 0);
+ MIN_LPC_SHIFT, MAX_LPC_SHIFT, 0);
if (omethod == ORDER_METHOD_2LEVEL ||
omethod == ORDER_METHOD_4LEVEL ||
diff --git a/libavcodec/lpc.c b/libavcodec/lpc.c
index 052aeaa..f8da1e1 100644
--- a/libavcodec/lpc.c
++
[FFmpeg-devel] Start of SCTE-35 support [PATCH]
Hi,
Apologies for resending - gmail sent the first attempt as a binary attachment.
This patch starts the work on SCTE-35 support; for now it just detects
SCTE-35 and if present sends the data to a dummy function. Since it's
my first contribution to ffmpeg I preferred to start small and
continue working as small pieces of work are accepted or commented.
Carlos
From c0166b6d74945ef3f2121e97215c1455f9408eaf Mon Sep 17 00:00:00 2001
From: Carlos
Date: Mon, 11 Jan 2016 23:27:37 -0800
Subject: [PATCH] SCTE extraction from mpegts
Signed-off-by: carlos
---
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 6 ++
libavformat/mpegts.c| 42 --
3 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 39713ed..3a3c2fc 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -628,6 +628,7 @@ enum AVCodecID {
/* other specific kind of codecs (generally used for attachments) */
AV_CODEC_ID_FIRST_UNKNOWN = 0x18000, ///< A dummy ID
pointing at the start of various fake codecs.
AV_CODEC_ID_TTF = 0x18000,
+AV_CODEC_ID_SCTE_35,
AV_CODEC_ID_BINTEXT= 0x18800,
AV_CODEC_ID_XBIN,
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 9d94b72..59fd261 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -2949,6 +2949,12 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("binary data"),
.mime_types= MT("application/octet-stream"),
},
+{
+.id= AV_CODEC_ID_SCTE_35,
+.type = AVMEDIA_TYPE_DATA,
+.name = "scte_35",
+.long_name = NULL_IF_CONFIG_SMALL("SCTE 35 Message Queue"),
+},
/* deprecated codec ids */
};
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index b31d233..467f1de 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -57,6 +57,7 @@ enum MpegTSFilterType {
MPEGTS_PES,
MPEGTS_SECTION,
MPEGTS_PCR,
+MPEGTS_DATA,
};
typedef struct MpegTSFilter MpegTSFilter;
@@ -510,6 +511,11 @@ static MpegTSFilter
*mpegts_open_pcr_filter(MpegTSContext *ts, unsigned int pid)
return mpegts_open_filter(ts, pid, MPEGTS_PCR);
}
+static MpegTSFilter *mpegts_open_data_filter(MpegTSContext *ts,
unsigned int pid)
+{
+return mpegts_open_filter(ts, pid, MPEGTS_DATA);
+}
+
static void mpegts_close_filter(MpegTSContext *ts, MpegTSFilter *filter)
{
int pid;
@@ -705,6 +711,7 @@ static const StreamType ISO_types[] = {
{ 0x21, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_JPEG2000 },
{ 0x24, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_HEVC },
{ 0x42, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_CAVS },
+{ 0x86, AVMEDIA_TYPE_DATA, AV_CODEC_ID_SCTE_35},
{ 0xd1, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_DIRAC },
{ 0xea, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_VC1},
{ 0 },
@@ -872,6 +879,13 @@ static void reset_pes_packet_state(PESContext *pes)
av_buffer_unref(&pes->buffer);
}
+static void new_data_packet(const uint8_t *buffer, int len, AVPacket *pkt)
+{
+av_init_packet(pkt);
+pkt->data = buffer;
+pkt->size = len;
+}
+
static int new_pes_packet(PESContext *pes, AVPacket *pkt)
{
char *sd;
@@ -1975,6 +1989,19 @@ static void pmt_cb(MpegTSFilter *filter, const
uint8_t *section, int section_len
pes->st->id = pes->pid;
}
st = pes->st;
+} else if (stream_type == 0x86 && prog_reg_desc == AV_RL32("CUEI")) {
+int idx = ff_find_stream_index(ts->stream, pid);
+if (idx >= 0) {
+st = ts->stream->streams[idx];
+} else {
+st = avformat_new_stream(ts->stream, NULL);
+if (!st)
+goto out;
+st->id = pid;
+st->codecpar->codec_type = AVMEDIA_TYPE_DATA;
+mpegts_find_stream_type(st, stream_type, ISO_types);
+mpegts_open_data_filter(ts, pid);
+}
} else if (stream_type != 0x13) {
if (ts->pids[pid])
mpegts_close_filter(ts, ts->pids[pid]); // wrongly
added sdt filter probably
@@ -2317,15 +2344,16 @@ static int handle_packet(MpegTSContext *ts,
const uint8_t *packet)
}
}
}
-
-} else {
+} else if (tss->type == MPEGTS_DATA) {
+p++;
+new_data_packet(p,p_end - p, ts->pkt);
+ts->stop_parse = 1;
+} else if (tss->type == MPEGTS_PES) {
int ret;
// Note: The position here points actually behind the current packet.
-if (tss->type == MPEGTS_PES) {
-if ((ret = tss->u.pes_filter.pes_cb(tss, p, p_end - p, is_start,
+if ((ret = tss->u.pes_filter.pes_cb(tss, p, p_end - p, is_start,
pos -
ts->raw_packet_size)) < 0)
-return ret;
-}
+
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
On Fri, Jul 1, 2016 at 3:03 PM, Ronald S. Bultje wrote: > Hi, > > On Fri, Jul 1, 2016 at 5:27 PM, Vignesh Venkatasubramanian < > vigneshv-at-google@ffmpeg.org> wrote: > >> On Fri, Jul 1, 2016 at 12:48 PM, Ronald S. Bultje >> wrote: >> > Hi, >> > >> > On Fri, Jul 1, 2016 at 3:29 PM, Ronald S. Bultje >> wrote: >> > >> >> Hi, >> >> >> >> On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian < >> >> vigneshv-at-google@ffmpeg.org> wrote: >> >> >> >>> On Fri, Jul 1, 2016 at 11:06 AM, James Almer >> wrote: >> >>> > On 7/1/2016 2:53 PM, Ronald S. Bultje wrote: >> >>> >> Hi, >> >>> >> >> >>> >> On Fri, Jul 1, 2016 at 1:40 PM, James Zern < >> >>> jzern-at-google@ffmpeg.org> >> >>> >> wrote: >> >>> >> >> >>> >>> On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos < >> ceho...@ag.or.at> >> >>> >>> wrote: >> >>> > Do we have decoder support (for either vp8 or vp9) for these >> files? >> >>> >> >>> No, only encoding and muxing. >> >>> >>> >> >>> >>> Seems like a feature request, but no reason to block this one if >> the >> >>> >>> vp8 one is here. >> >>> >> >> >>> >> >> >>> >> I'm not sure I have an opinion on this... But it feels strange to >> allow >> >>> >> encoding of content we cannot decode. Being ffmpeg, how do we >> recommend >> >>> >> people handle the files created with this feature, if not by using >> >>> ffmpeg >> >>> >> itself? >> >>> >> >>> One plausible reason is that Chrome can decode this. So it will be >> >>> useful for people who already have ffmpeg in their pipelines and want >> >>> to create such files. And like James Almer mentioned, this isn't a >> >>> first. VP8 Alpha has been this way too. >> >> >> >> >> >> The fact that something is the way it is, does not prove that it is >> >> therefore right, or that we should therefore continue doing it that way >> in >> >> other cases. >> >> >> >> So you're suggesting that it is perfectly fine for people to use Chrome >> as >> >> decoder if FFmpeg is the encoder. What if people don't have Chrome >> >> installed? Or what if they want a way of UI-less batch-processing such >> >> files, e.g. what if a service like Youtube/Vimeo wants to allow upload >> of >> >> vp8a/vp9a files without invoking Chrome for decoding? >> >> >> > >> > Additional evidence in [1], [2]. >> > >> > There absolutely seems to be interest in support for vp8a/vp9a decoding >> > outside Chrome. I'm not saying you should implement it in all multimedia >> > frameworks ever created in human history, but doing it in one of them >> (e.g. >> > ffmpeg, since it already supports encoding) certainly sounds helpful? >> > >> >> I'm not saying alpha decoder shouldn't ever be implemented in ffmpeg. >> I'm just saying that it shouldn't be a reason to block this patch. :) >> Sorry if i wasn't clear before. > > > I totally understand that you would think that, since it means you don't > have to do anything :). > > But there's an issue with this thinking. We're essentially already the > dumping ground for anything multimedia-related nowadays. After all, we > maintain it and keep it working (assuming basic tests), things couldn't get > much easier than that, right? But is it actually useful to anyone? I mean > not just useful for you, but useful to a wider set of people, at least in > theory. > > If there's no decoder, I would claim that the wider utility of this thing > is essentially zero. And that's somewhat of a concern. > > So, how do we get a decoder? vp8a suggests that just waiting for one to > spontaneously combust out of thin air just doesn't work. So I'm suggesting > you provide us with one. It's ok if it uses libvpx instead of ffvp8/9. > Since vp8a encoding is already in, I won't ask for a vp8a decoder either. > I'm just asking for a vp9a decoder. It might even be OK if it's implemented > on top of ffmpeg instead of inside libavcodec (I'm not sure how others feel > about this), i.e. just something that invokes libavformat to parse a webm > file, create two decoders to get the yuv and a planes, and then merge them > together into a yuva420p picture. I'm just asking for something _small_ and > _simple_ (i.e. not "Chrome") that we can point users to when they ask "how > do I decode vp9a files". > > I asked on IRC (#ffmpeg-devel) and several people concurred: > > jamrial: so … I’m looking for a second opinion here, like, an > independent one… am I being too hard on these guys for saying “an encoder > needs a decoder”? > BBB: I do tend to agree that in general it goes dec->enc, or both at > the same time. be it a fully lavc decoder or just utilizing a decoder > library > BBB: no, you're not being hard > > So it seems I'm not entirely alone in this opinion within the ffmpeg > developer community. > Alright, i have a working patch for the decoder locally (i will push that to the ML shortly). In the meantime, let's please unblock this. It worked this time as it wasn't too complex, but i'm not sure if conditioning patches like this is always a good idea. :) > Ronald >
Re: [FFmpeg-devel] [PATCH v3] libavformat/movenc: add dnxhr compatibility for apple players
On Wed, Jul 6, 2016 at 3:41 PM, Mark Reid wrote: > --- > libavcodec/dnxhddec.c | 3 +++ > libavformat/movenc.c | 19 ++- > 2 files changed, 17 insertions(+), 5 deletions(-) > > diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c > index 1808080..b310e3e 100644 > --- a/libavcodec/dnxhddec.c > +++ b/libavcodec/dnxhddec.c > @@ -204,6 +204,9 @@ static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame > *frame, > } > > cid = AV_RB32(buf + 0x28); > +if (cid >= 1270 || cid <= 1274) oops, this should be: if (cid >= 1270 && cid <= 1274) use attached patch instead v3-0001-libavformat-movenc-add-dnxhr-compatibility-for-ap.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
