Re: [FFmpeg-devel] Building with all threading disabled still results in avutil-55.dll dependency on pthreadGC-3.dll
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf Of Gregory J Wolfe > Sent: Thursday, November 17, 2016 2:10 PM > To: ffmpeg-devel@ffmpeg.org > Subject: [FFmpeg-devel] Building with all threading disabled still results > in avutil-55.dll dependency on pthreadGC-3.dll > > I am building FFmpeg using msys/MinGW on Windows 7 for use on > Windows systems. I **want** the resulting DLLs to have threading > enabled, but no matter what I do the avutil DLL has a dependency on > MinGW library pthreadGC-3.dll. For deployment purposes we do not > want the destination system to have to have any MinGW components > installed. Even the following configuration does not eliminate this > dependency (config.log attached): > > ../configure --enable-shared --disable-static --enable-memalign-hack - > -enable-libmp3lame --enable-libopenh264 --extra-ldflags=-static-libgcc > --disable-iconv --enable-nvenc --disable-w32threads --disable- > pthreads > > Even though all threading support has been (theoretically) disabled, > the dependency walker shows that the avutil DLL depends on the > following symbols: > > _sched_affinitycpucount > _sched_affinitycpuzero > sched_getaffinity > > I tried using -static as an additional CFLAG/LDFLAG, but then configure > command does not find the libopenh264 DLL. So I think what I need to > do is to modify the compile/link commands for the avutil DLL ONLY > such that it statically links in threading support. Is this possible through > the configure command? Any other suggestions out there? Found the answer to the easy question. In libavutil/cpu.c, all of the thread related code should be surrounded by #if HAVE_THREADS, so that if all thread support is disabled the code will not attempt to query how may processors there are, etc. On to the more difficult question of removing the dependency when threading is desired ... > > Greg Wolfe > Kodak Alaris > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Building with all threading disabled still results in avutil-55.dll dependency on pthreadGC-3.dll
> > -Original Message- > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] > On > > Behalf Of Gregory J Wolfe > > Sent: Thursday, November 17, 2016 2:10 PM > > To: ffmpeg-devel@ffmpeg.org > > Subject: [FFmpeg-devel] Building with all threading disabled still > results > > in avutil-55.dll dependency on pthreadGC-3.dll > > > > I am building FFmpeg using msys/MinGW on Windows 7 for use on > > Windows systems. I **want** the resulting DLLs to have threading > > enabled, but no matter what I do the avutil DLL has a dependency on > > MinGW library pthreadGC-3.dll. For deployment purposes we do not > > want the destination system to have to have any MinGW > components > > installed. Even the following configuration does not eliminate this > > dependency (config.log attached): > > > > ../configure --enable-shared --disable-static --enable-memalign-hack > - > > -enable-libmp3lame --enable-libopenh264 --extra-ldflags=-static- > libgcc > > --disable-iconv --enable-nvenc --disable-w32threads --disable- > > pthreads > > > > Even though all threading support has been (theoretically) disabled, > > the dependency walker shows that the avutil DLL depends on the > > following symbols: > > > > _sched_affinitycpucount > > _sched_affinitycpuzero > > sched_getaffinity > > > > I tried using -static as an additional CFLAG/LDFLAG, but then > configure > > command does not find the libopenh264 DLL. So I think what I need > to > > do is to modify the compile/link commands for the avutil DLL ONLY > > such that it statically links in threading support. Is this possible > through > > the configure command? Any other suggestions out there? > > Found the answer to the easy question. In libavutil/cpu.c, all of the > thread > related code should be surrounded by #if HAVE_THREADS, so that if all > thread support is disabled the code will not attempt to query how may > processors there are, etc. > > On to the more difficult question of removing the dependency when > threading is desired ... > Found the solution to the hard question, again in libavutil/cpu.c. When both configuration macros HAVE_SCHED_GETAFFINITY (GNU) and HAVE_GETPROCESSAFFINITYMASK (Windows) are set to 1, AND HAVE_W32THREADS is set to 1, then the number of CPUs should be obtained using the Windows system call, not the GNU system call. Otherwise you get dependencies on both the Windows and the GNU threading libraries, which is clearly not what is wanted. Will send patch within the next day or two. > > > > Greg Wolfe > > Kodak Alaris ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Avoid creating unecessary dependencies on thread libraries.
(1) Multi-threading support requires knowing the number of CPUs available.
When building with MinGW on a Windows system, both gcc and Windows run
time functions are available to get this information. However, when Windows
threading has been selected, the Windows function should be used, not the
gcc function. This avoids creating an unnecessary dependency on the gcc
thread library.
(2) When ALL threading support is disabled, the build should not create a
dependency on ANY thread library.
Signed-off-by: Gregory J. Wolfe
---
libavutil/cpu.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index f5785fc..3843778 100644
--- a/libavutil/cpu.c
+++ b/libavutil/cpu.c
@@ -258,10 +258,15 @@ int av_cpu_count(void)
static volatile int printed;
int nb_cpus = 1;
+#if HAVE_THREADS
#if HAVE_WINRT
SYSTEM_INFO sysinfo;
#endif
-#if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT)
+// if HAVE_W32THREADS and HAVE_GETPROCESSAFFINITYMASK, we will use
+// Windows GetProcessAffinityMask() instead of gcc library function
+// sched_getaffinity(). This avoids creating a dependency on the gcc
+// thread library that we don't need/want.
+#if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT) && !(HAVE_W32THREADS &&
HAVE_GETPROCESSAFFINITYMASK)
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
@@ -286,6 +291,7 @@ int av_cpu_count(void)
GetNativeSystemInfo(&sysinfo);
nb_cpus = sysinfo.dwNumberOfProcessors;
#endif
+#endif
if (!printed) {
av_log(NULL, AV_LOG_DEBUG, "detected %d logical cores\n", nb_cpus);
--
2.5.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Avoid creating unecessary dependencies on thread libraries.
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf Of wm4
> Sent: Monday, November 21, 2016 10:05 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] Avoid creating unecessary
> dependencies on thread libraries.
>
> On Mon, 21 Nov 2016 09:58:33 -0500
> "Gregory J. Wolfe" wrote:
>
> > (1) Multi-threading support requires knowing the number of CPUs
> available.
> > When building with MinGW on a Windows system, both gcc and
> Windows run
> > time functions are available to get this information. However, when
> Windows
> > threading has been selected, the Windows function should be used,
> not the
> > gcc function. This avoids creating an unnecessary dependency on
> the gcc
> > thread library.
> >
> > (2) When ALL threading support is disabled, the build should not
> create a
> > dependency on ANY thread library.
> >
> > Signed-off-by: Gregory J. Wolfe
> > ---
> > libavutil/cpu.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/cpu.c b/libavutil/cpu.c
> > index f5785fc..3843778 100644
> > --- a/libavutil/cpu.c
> > +++ b/libavutil/cpu.c
> > @@ -258,10 +258,15 @@ int av_cpu_count(void)
> > static volatile int printed;
> >
> > int nb_cpus = 1;
> > +#if HAVE_THREADS
> > #if HAVE_WINRT
> > SYSTEM_INFO sysinfo;
> > #endif
> > -#if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT)
> > +// if HAVE_W32THREADS and HAVE_GETPROCESSAFFINITYMASK,
> we will use
> > +// Windows GetProcessAffinityMask() instead of gcc library
> function
> > +// sched_getaffinity(). This avoids creating a dependency on the
> gcc
> > +// thread library that we don't need/want.
> > +#if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT) &&
> !(HAVE_W32THREADS && HAVE_GETPROCESSAFFINITYMASK)
> > cpu_set_t cpuset;
> >
> > CPU_ZERO(&cpuset);
> > @@ -286,6 +291,7 @@ int av_cpu_count(void)
> > GetNativeSystemInfo(&sysinfo);
> > nb_cpus = sysinfo.dwNumberOfProcessors;
> > #endif
> > +#endif
> >
> > if (!printed) {
> > av_log(NULL, AV_LOG_DEBUG, "detected %d logical cores\n",
> nb_cpus);
>
> Wouldn't it be better to move the HAVE_GETPROCESSAFFINITYMASK
> case
> above HAVE_SCHED_GETAFFINITY, and avoid making the ifdeffery
> mess
> worse? GetProcessAffinityMask is available on every supported
> Windows
> and could as well be replaced by "ifdef _WIN32" instead.
>
Yeah, I had the same thought. For the first go around I opted for the
solution that moved around the least code, not knowing for sure if
I might cause some undesirable side effects by reordering the existing
code. I can easily redo the patch if we're in agreement on this point.
> Also, technically you might have to stop the configure script to stop
> linking to libpthread. I'm not sure what exactly stops it from doing
> that in your case.
The result I observed was that the resulting avutil.dll did NOT have
a dependency on the gcc run time. My interpretation of this is that
if you link against a library, but don't reference any symbols in it, then
it's as if you never linked against it in the first place.
Greg W.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Avoid creating unecessary dependencies on thread libraries.
(1) Multi-threading support requires knowing the number of CPUs available.
When building with MinGW on a Windows system, both Windows and gcc run
time functions are available to get this information. If available,
the Windows function should be used, not the gcc function. This avoids
creating an unnecessary dependency on the gcc thread library.
(2) When ALL threading support is disabled, the build should not create a
dependency on ANY thread library.
Signed-off-by: Gregory J. Wolfe
---
libavutil/cpu.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index f5785fc..a55921a 100644
--- a/libavutil/cpu.c
+++ b/libavutil/cpu.c
@@ -258,20 +258,25 @@ int av_cpu_count(void)
static volatile int printed;
int nb_cpus = 1;
+#if HAVE_THREADS
#if HAVE_WINRT
SYSTEM_INFO sysinfo;
#endif
-#if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT)
+// if HAVE_GETPROCESSAFFINITYMASK, we will use Windows
+// GetProcessAffinityMask() over gcc library function
+// sched_getaffinity(). This avoids creating a dependency
+// on the gcc thread library that we don't need/want.
+#if HAVE_GETPROCESSAFFINITYMASK
+DWORD_PTR proc_aff, sys_aff;
+if (GetProcessAffinityMask(GetCurrentProcess(), &proc_aff, &sys_aff))
+nb_cpus = av_popcount64(proc_aff);
+#elif HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT)
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
if (!sched_getaffinity(0, sizeof(cpuset), &cpuset))
nb_cpus = CPU_COUNT(&cpuset);
-#elif HAVE_GETPROCESSAFFINITYMASK
-DWORD_PTR proc_aff, sys_aff;
-if (GetProcessAffinityMask(GetCurrentProcess(), &proc_aff, &sys_aff))
-nb_cpus = av_popcount64(proc_aff);
#elif HAVE_SYSCTL && defined(HW_NCPU)
int mib[2] = { CTL_HW, HW_NCPU };
size_t len = sizeof(nb_cpus);
@@ -286,6 +291,7 @@ int av_cpu_count(void)
GetNativeSystemInfo(&sysinfo);
nb_cpus = sysinfo.dwNumberOfProcessors;
#endif
+#endif
if (!printed) {
av_log(NULL, AV_LOG_DEBUG, "detected %d logical cores\n", nb_cpus);
--
2.5.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Avoid creating unecessary dependencies on thread libraries.
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf Of Carl Eugen Hoyos > Sent: Monday, November 21, 2016 8:12 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] Avoid creating unecessary > dependencies on thread libraries. > > 2016-11-21 19:52 GMT+01:00 Gregory J. Wolfe > : > > > (2) When ALL threading support is disabled, the build should not > create a > > dependency on ANY thread library. > > If this done through "#if HAVE_THREADS", it would be preferable to > split the patches imo. > > Carl Eugen Back from Thanksgiving holiday. Will split patch into two and resubmit. Greg W. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] No thread library dependencies when threading support is disabled.
When ALL threading support is disabled, the build should not create
a dependency on ANY thread library.
Signed-off-by: Gregory J. Wolfe
---
libavutil/cpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index 73317c4..1803f6f 100644
--- a/libavutil/cpu.c
+++ b/libavutil/cpu.c
@@ -260,6 +260,7 @@ int av_cpu_count(void)
static volatile int printed;
int nb_cpus = 1;
+#if HAVE_THREADS
#if HAVE_WINRT
SYSTEM_INFO sysinfo;
#endif
@@ -288,6 +289,7 @@ int av_cpu_count(void)
GetNativeSystemInfo(&sysinfo);
nb_cpus = sysinfo.dwNumberOfProcessors;
#endif
+#endif
if (!printed) {
av_log(NULL, AV_LOG_DEBUG, "detected %d logical cores\n", nb_cpus);
--
2.5.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Avoid MinGW/Windows dependency on gcc thread library.
Multi-threading support requires knowing the number of CPUs available.
When building with MinGW on a Windows system, both Windows and gcc run
time functions are available to get this information. If available,
the Windows function should be used, not the gcc function. This avoids
creating an unnecessary dependency on the gcc thread library.
Signed-off-by: Gregory J. Wolfe
---
libavutil/cpu.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index 1803f6f..6ebc7ce 100644
--- a/libavutil/cpu.c
+++ b/libavutil/cpu.c
@@ -264,17 +264,21 @@ int av_cpu_count(void)
#if HAVE_WINRT
SYSTEM_INFO sysinfo;
#endif
-#if HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT)
+// if HAVE_GETPROCESSAFFINITYMASK, we will use Windows
+// GetProcessAffinityMask() over gcc library function
+// sched_getaffinity(). This avoids creating a dependency
+// on the gcc thread library that we don't need/want.
+#if HAVE_GETPROCESSAFFINITYMASK
+DWORD_PTR proc_aff, sys_aff;
+if (GetProcessAffinityMask(GetCurrentProcess(), &proc_aff, &sys_aff))
+nb_cpus = av_popcount64(proc_aff);
+#elif HAVE_SCHED_GETAFFINITY && defined(CPU_COUNT)
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
if (!sched_getaffinity(0, sizeof(cpuset), &cpuset))
nb_cpus = CPU_COUNT(&cpuset);
-#elif HAVE_GETPROCESSAFFINITYMASK
-DWORD_PTR proc_aff, sys_aff;
-if (GetProcessAffinityMask(GetCurrentProcess(), &proc_aff, &sys_aff))
-nb_cpus = av_popcount64(proc_aff);
#elif HAVE_SYSCTL && defined(HW_NCPU)
int mib[2] = { CTL_HW, HW_NCPU };
size_t len = sizeof(nb_cpus);
--
2.5.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Define ETIMEDOUT in fifo_muxer.c for MinGW/Windows fate build.
Fate failed to build in the MinGW/Windows environment because macro ETIMEDOUT was undefined. When this condition is detected, the code now includes <_ptw32.h>, which defines the symbol. Signed-off-by: Gregory J. Wolfe --- libavformat/tests/fifo_muxer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavformat/tests/fifo_muxer.c b/libavformat/tests/fifo_muxer.c index 9659198..b579e48 100644 --- a/libavformat/tests/fifo_muxer.c +++ b/libavformat/tests/fifo_muxer.c @@ -25,6 +25,9 @@ #include "libavutil/avassert.h" #include "libavformat/avformat.h" #include "libavformat/url.h" +#ifndef ETIMEDOUT +#include <_ptw32.h> +#endif #define MAX_TST_PACKETS 128 #define SLEEPTIME_50_MS 5 -- 2.5.1.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Allow client to enable/disable openh264 load balancing.
The libopenh264 library allows the client to enable or disable
load balancing when running multi-threaded. When enabled, the
slice sizes are dynamically adjusted in order to use the
multiple threads more efficiently. However, this can also lead
to valid but slightly different results from run to run.
Disabling load balancing prevents dynamic slice adjustment and
yields repeatable results when running multi-threaded, which can
be important when running test cases.
Signed-off-by: Gregory J. Wolfe
---
libavcodec/libopenh264enc.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 648f59b..5aa1596 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -47,6 +47,9 @@ typedef struct SVCContext {
int skip_frames;
int skipped;
int cabac;
+#if OPENH264_VER_AT_LEAST(1, 6)
+int load_balancing;
+#endif
} SVCContext;
#define OFFSET(x) offsetof(SVCContext, x)
@@ -71,6 +74,9 @@ static const AVOption options[] = {
{ "max_nal_size", "set maximum NAL size in bytes", OFFSET(max_nal_size),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
{ "allow_skip_frames", "allow skipping frames to hit the target bitrate",
OFFSET(skip_frames), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
{ "cabac", "Enable cabac", OFFSET(cabac), AV_OPT_TYPE_INT, { .i64 = 0 },
0, 1, VE },
+#if OPENH264_VER_AT_LEAST(1, 6)
+{ "load_balancing", "enable/disable load balancing",
OFFSET(load_balancing), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, VE },
+#endif
{ NULL }
};
@@ -150,6 +156,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
param.iLoopFilterDisableIdc = !s->loopfilter;
param.iEntropyCodingModeFlag = 0;
param.iMultipleThreadIdc = avctx->thread_count;
+#if OPENH264_VER_AT_LEAST(1, 6)
+param.bUseLoadBalancing = s->load_balancing;
+#endif
if (s->profile && !strcmp(s->profile, "main"))
param.iEntropyCodingModeFlag = 1;
else if (!s->profile && s->cabac)
--
2.5.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Save FFmpeg colorspace info in openh264 video files.
As of version 1.6, libopenh264 saves (in the output video file)
information about the color primaries, transfer characteristics,
and color matrix used when the video pixel data was created.
This patch sets the required libopenh264 data structures using
the FFmpeg colorspace information so that video players will
know how to properly decode video files created using FFmpeg
and libopenh264.
Signed-off-by: Gregory J. Wolfe
---
libavcodec/libopenh264enc.c | 52 +
1 file changed, 52 insertions(+)
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 5aa1596..6de7790 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -206,6 +206,58 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
}
+#if OPENH264_VER_AT_LEAST(1, 6)
+// set video signal type information
+param.sSpatialLayers[0].bVideoSignalTypePresent = true;
+param.sSpatialLayers[0].uiVideoFormat = VF_UNDEF;
+param.sSpatialLayers[0].bFullRange = (avctx->color_range ==
AVCOL_RANGE_JPEG);
+param.sSpatialLayers[0].bColorDescriptionPresent = true;
+switch ( avctx->color_primaries )
+{
+case AVCOL_PRI_BT709:param.sSpatialLayers[0].uiColorPrimaries =
CP_BT709; break;
+case AVCOL_PRI_UNSPECIFIED: param.sSpatialLayers[0].uiColorPrimaries =
CP_UNDEF; break;
+case AVCOL_PRI_BT470M: param.sSpatialLayers[0].uiColorPrimaries =
CP_BT470M; break;
+case AVCOL_PRI_BT470BG: param.sSpatialLayers[0].uiColorPrimaries =
CP_BT470BG; break;
+case AVCOL_PRI_SMPTE170M:param.sSpatialLayers[0].uiColorPrimaries =
CP_SMPTE170M; break;
+case AVCOL_PRI_SMPTE240M:param.sSpatialLayers[0].uiColorPrimaries =
CP_SMPTE240M; break;
+case AVCOL_PRI_FILM: param.sSpatialLayers[0].uiColorPrimaries =
CP_FILM; break;
+case AVCOL_PRI_BT2020: param.sSpatialLayers[0].uiColorPrimaries =
CP_BT2020; break;
+default: param.sSpatialLayers[0].uiColorPrimaries =
CP_UNDEF; break;
+}
+switch ( avctx->color_trc )
+{
+case AVCOL_TRC_BT709:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT709; break;
+case AVCOL_TRC_UNSPECIFIED:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_UNDEF; break;
+case AVCOL_TRC_GAMMA22:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT470M; break;
+case AVCOL_TRC_GAMMA28:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT470BG; break;
+case AVCOL_TRC_SMPTE170M:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_SMPTE170M; break;
+case AVCOL_TRC_SMPTE240M:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_SMPTE240M; break;
+case AVCOL_TRC_LINEAR:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LINEAR; break;
+case AVCOL_TRC_LOG:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LOG100; break;
+case AVCOL_TRC_LOG_SQRT:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LOG316; break;
+case AVCOL_TRC_IEC61966_2_4:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_IEC61966_2_4; break;
+case AVCOL_TRC_BT1361_ECG:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT1361E; break;
+case AVCOL_TRC_IEC61966_2_1:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_IEC61966_2_1; break;
+case AVCOL_TRC_BT2020_10:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT2020_10; break;
+case AVCOL_TRC_BT2020_12:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT2020_12; break;
+default:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_UNDEF; break;
+}
+switch ( avctx->colorspace )
+{
+case AVCOL_SPC_RGB: param.sSpatialLayers[0].uiColorMatrix =
CM_GBR; break;
+case AVCOL_SPC_BT709:param.sSpatialLayers[0].uiColorMatrix =
CM_BT709; break;
+case AVCOL_SPC_UNSPECIFIED: param.sSpatialLayers[0].uiColorMatrix =
CM_UNDEF; break;
+case AVCOL_SPC_FCC: param.sSpatialLayers[0].uiColorMatrix =
CM_FCC; break;
+case AVCOL_SPC_BT470BG: param.sSpatialLayers[0].uiColorMatrix =
CM_BT470BG; break;
+case AVCOL_SPC_SMPTE170M:param.sSpatialLayers[0].uiColorMatrix =
CM_SMPTE170M; break;
+case AVCOL_SPC_SMPTE240M:param.sSpatialLayers[0].uiColorMatrix =
CM_SMPTE240M; break;
+case AVCOL_SPC_YCOCG:param.sSpatialLayers[0].uiColorMatrix =
CM_YCGCO; break;
+case AVCOL_SPC_BT2020_NCL: param.sSpatialLayers[0].uiColorMatrix =
CM_BT2020NC; break;
+case AVCOL_SPC_BT2020_CL:param.sSpatialLayers[0].uiColorMatrix =
CM_BT2020C; break;
+default: param.sSpatialLayers[0].uiColorMatrix =
CM_UNDEF; break;
+}
+#endif
+
if ((*s->encoder)->InitializeExt(s->encoder, ¶m) != cmResultSuccess) {
av_log(avctx, AV_L
Re: [FFmpeg-devel] [PATCH] Allow client to enable/disable openh264 load balancing.
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf Of Moritz Barsnick
> Sent: Tuesday, November 29, 2016 7:15 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] Allow client to enable/disable
> openh264 load balancing.
>
> On Mon, Nov 28, 2016 at 16:29:01 -0500, Gregory J. Wolfe wrote:
> > +#if OPENH264_VER_AT_LEAST(1, 6)
> > +{ "load_balancing", "enable/disable load balancing",
> OFFSET(load_balancing), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, VE },
> > +#endif
>
> This could use a documentation update.
Not sure exactly what you mean by "documentation update". Some
comments in the code, or more verbosity than "enable/disable load
balancing"? Please elaborate.
>
> And since documentation isn't built conditionally, the option could be
> made available unconditionally, and this:
>
> > +#if OPENH264_VER_AT_LEAST(1, 6)
> > +param.bUseLoadBalancing = s->load_balancing;
> > +#endif
>
> be made to print a warning in an #else .. #endif case. (Perhaps make
> the AV_OPT_TYPE_BOOL option default to -1 in order to detect
> whether it
> was set.)
WRT "default to -1", original intent was to have the default value match
the libopenh264 internal default value. What should happen if the value
is not set?
>
> Just suggesting,
> Moritz
More than happy to enhance this patch, waiting for clarification.
Greg W.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Define ETIMEDOUT in fifo_muxer.c for MinGW/Windows fate build.
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf Of Daniel Verkamp > Sent: Monday, November 28, 2016 7:51 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] Define ETIMEDOUT in > fifo_muxer.c for MinGW/Windows fate build. > > On Mon, Nov 28, 2016 at 1:22 PM, Gregory J. Wolfe > wrote: > > Fate failed to build in the MinGW/Windows environment because > > macro ETIMEDOUT was undefined. When this condition is detected, > > the code now includes <_ptw32.h>, which defines the symbol. > > > > Signed-off-by: Gregory J. Wolfe > > --- > > libavformat/tests/fifo_muxer.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/libavformat/tests/fifo_muxer.c > b/libavformat/tests/fifo_muxer.c > > index 9659198..b579e48 100644 > > --- a/libavformat/tests/fifo_muxer.c > > +++ b/libavformat/tests/fifo_muxer.c > > @@ -25,6 +25,9 @@ > > #include "libavutil/avassert.h" > > #include "libavformat/avformat.h" > > #include "libavformat/url.h" > > +#ifndef ETIMEDOUT > > +#include <_ptw32.h> > > +#endif > > Should this maybe be including libavformat/network.h, which already > has a workaround using the winsock definitions? > Borrowed code from network.h to get the same result. Will submit a new patch to replace the original one. Please retest with your MinGW-w64 installation. > My local MinGW-w64 installation doesn't have a _ptw32.h file. > > Thanks, > -- Daniel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Define ETIMEDOUT in fifo_muxer.c for MinGW/Windows fate build.
Fate failed to build in the MinGW/Windows environment because macro ETIMEDOUT was undefined. When this condition is detected, the code now defines this symbol the same way it's done in libavformat/network.h. Signed-off-by: Gregory J. Wolfe --- libavformat/tests/fifo_muxer.c | 12 1 file changed, 12 insertions(+) diff --git a/libavformat/tests/fifo_muxer.c b/libavformat/tests/fifo_muxer.c index 9659198..97f798f 100644 --- a/libavformat/tests/fifo_muxer.c +++ b/libavformat/tests/fifo_muxer.c @@ -25,6 +25,18 @@ #include "libavutil/avassert.h" #include "libavformat/avformat.h" #include "libavformat/url.h" +#ifndef ETIMEDOUT +#if HAVE_WINSOCK2_H +#include +#include +#define ETIMEDOUT WSAETIMEDOUT +#else /* HAVE_WINSOCK2_H */ +#include +#include +#include +#include +#endif /* HAVE_WINSOCK2_H */ +#endif /* ifndef ETIMEDOUT */ #define MAX_TST_PACKETS 128 #define SLEEPTIME_50_MS 5 -- 2.5.1.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Define ETIMEDOUT in fifo_muxer.c for MinGW/Windows fate build.
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf Of James Almer > Sent: Wednesday, November 30, 2016 5:18 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] Define ETIMEDOUT in > fifo_muxer.c for MinGW/Windows fate build. > > On 11/30/2016 7:02 PM, Gregory J. Wolfe wrote: > > Fate failed to build in the MinGW/Windows environment because > > macro ETIMEDOUT was undefined. When this condition is detected, > > the code now defines this symbol the same way it's done in > > libavformat/network.h. > > > > Signed-off-by: Gregory J. Wolfe > > --- > > libavformat/tests/fifo_muxer.c | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git a/libavformat/tests/fifo_muxer.c > b/libavformat/tests/fifo_muxer.c > > index 9659198..97f798f 100644 > > --- a/libavformat/tests/fifo_muxer.c > > +++ b/libavformat/tests/fifo_muxer.c > > @@ -25,6 +25,18 @@ > > #include "libavutil/avassert.h" > > #include "libavformat/avformat.h" > > #include "libavformat/url.h" > > +#ifndef ETIMEDOUT > > +#if HAVE_WINSOCK2_H > > +#include > > +#include > > +#define ETIMEDOUT WSAETIMEDOUT > > Why are you duplicating this code instead of simply including > network.h? My reasoning is that all that is needed in fifo_muxer.c is that ETIMEDOUT be defined. It does not need EVERYTHING that is in network.h (otherwise it would have already included it). Given my limited familiarity with FFmpeg source code, I did not want to introduce unneeded dependencies, but if you folks don't think that's an issue, fine with me (it is a BIG issue for our software development team). So should I submit a revised patch, or, given that the revised patch would add only a single line of code, would it be easier for you guys to make the fix directly? Greg W. > > > +#else /* HAVE_WINSOCK2_H */ > > +#include > > +#include > > +#include > > +#include > > +#endif /* HAVE_WINSOCK2_H */ > > +#endif /* ifndef ETIMEDOUT */ > > > > #define MAX_TST_PACKETS 128 > > #define SLEEPTIME_50_MS 5 > > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Define ETIMEDOUT in fifo_muxer.c for MinGW/Windows fate build.
Now includes libavformat/network.h to define ETIMEDOUT. Signed-off-by: Gregory J. Wolfe --- libavformat/tests/fifo_muxer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/tests/fifo_muxer.c b/libavformat/tests/fifo_muxer.c index 9659198..dc62965 100644 --- a/libavformat/tests/fifo_muxer.c +++ b/libavformat/tests/fifo_muxer.c @@ -25,6 +25,7 @@ #include "libavutil/avassert.h" #include "libavformat/avformat.h" #include "libavformat/url.h" +#include "libavformat/network.h" #define MAX_TST_PACKETS 128 #define SLEEPTIME_50_MS 5 -- 2.5.1.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Allow client to enable/disable openh264 load balancing.
The libopenh264 library allows the client to enable or disable
load balancing when running multi-threaded. When enabled, the
slice sizes are dynamically adjusted in order to use the
multiple threads more efficiently. However, this can also lead
to valid but slightly different results from run to run.
Disabling load balancing prevents dynamic slice adjustment and
yields repeatable results when running multi-threaded, which can
be important when running test cases.
Signed-off-by: Gregory J. Wolfe
---
libavcodec/libopenh264enc.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 648f59b..e84de27 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -47,6 +47,7 @@ typedef struct SVCContext {
int skip_frames;
int skipped;
int cabac;
+int load_balancing;
} SVCContext;
#define OFFSET(x) offsetof(SVCContext, x)
@@ -71,6 +72,7 @@ static const AVOption options[] = {
{ "max_nal_size", "set maximum NAL size in bytes", OFFSET(max_nal_size),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
{ "allow_skip_frames", "allow skipping frames to hit the target bitrate",
OFFSET(skip_frames), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
{ "cabac", "Enable cabac", OFFSET(cabac), AV_OPT_TYPE_INT, { .i64 = 0 },
0, 1, VE },
+{ "load_balancing", "enable/disable dynamic slice adjustment for efficient
use of multiple threads; if enabled, can produce valid but slightly different
results from run to run", OFFSET(load_balancing), AV_OPT_TYPE_BOOL, { .i64 = -1
}, 0, 1, VE },
{ NULL }
};
@@ -150,6 +152,12 @@ FF_ENABLE_DEPRECATION_WARNINGS
param.iLoopFilterDisableIdc = !s->loopfilter;
param.iEntropyCodingModeFlag = 0;
param.iMultipleThreadIdc = avctx->thread_count;
+#if OPENH264_VER_AT_LEAST(1, 6)
+param.bUseLoadBalancing = s->load_balancing; // default is
enabled; -1 means not specified by client
+#else
+if ( s->load_balancing != -1 )
+av_log(avctx, AV_LOG_WARNING, "load_balancing = %d specified, but not
supported prior to libopenh264 v1.6\n", s->load_balancing);
+#endif
if (s->profile && !strcmp(s->profile, "main"))
param.iEntropyCodingModeFlag = 1;
else if (!s->profile && s->cabac)
--
2.5.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Save FFmpeg colorspace info in openh264 video files.
As of version 1.6, libopenh264 saves (in the output video file)
information about the color primaries, transfer characteristics,
and color matrix used when the video pixel data was created.
This patch sets the required libopenh264 data structures using
the FFmpeg colorspace information so that video players will
know how to properly decode video files created using FFmpeg
and libopenh264.
Signed-off-by: Gregory J. Wolfe
---
libavcodec/libopenh264enc.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index e84de27..3b019b8 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -205,6 +205,55 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
}
+#if OPENH264_VER_AT_LEAST(1, 6)
+// set video signal type information
+param.sSpatialLayers[0].bVideoSignalTypePresent = true;
+param.sSpatialLayers[0].uiVideoFormat = VF_UNDEF; // default; choices are
VF_: COMPONENT, PAL, NTSC, SECAM, MAC, UNDEF
+param.sSpatialLayers[0].bFullRange = avctx->color_range ==
AVCOL_RANGE_JPEG;
+param.sSpatialLayers[0].bColorDescriptionPresent = true;
+switch (avctx->color_primaries) {
+case AVCOL_PRI_BT709:param.sSpatialLayers[0].uiColorPrimaries
= CP_BT709; break;
+case AVCOL_PRI_UNSPECIFIED: param.sSpatialLayers[0].uiColorPrimaries
= CP_UNDEF; break;
+case AVCOL_PRI_BT470M: param.sSpatialLayers[0].uiColorPrimaries
= CP_BT470M;break;
+case AVCOL_PRI_BT470BG: param.sSpatialLayers[0].uiColorPrimaries
= CP_BT470BG; break;
+case AVCOL_PRI_SMPTE170M:param.sSpatialLayers[0].uiColorPrimaries
= CP_SMPTE170M; break;
+case AVCOL_PRI_SMPTE240M:param.sSpatialLayers[0].uiColorPrimaries
= CP_SMPTE240M; break;
+case AVCOL_PRI_FILM: param.sSpatialLayers[0].uiColorPrimaries
= CP_FILM; break;
+case AVCOL_PRI_BT2020: param.sSpatialLayers[0].uiColorPrimaries
= CP_BT2020;break;
+default: param.sSpatialLayers[0].uiColorPrimaries
= CP_UNDEF; break;
+}
+switch (avctx->color_trc) {
+case AVCOL_TRC_BT709:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT709;break;
+case AVCOL_TRC_UNSPECIFIED:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_UNDEF;break;
+case AVCOL_TRC_GAMMA22:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT470M; break;
+case AVCOL_TRC_GAMMA28:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT470BG; break;
+case AVCOL_TRC_SMPTE170M:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_SMPTE170M;break;
+case AVCOL_TRC_SMPTE240M:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_SMPTE240M;break;
+case AVCOL_TRC_LINEAR:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LINEAR; break;
+case AVCOL_TRC_LOG:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LOG100; break;
+case AVCOL_TRC_LOG_SQRT:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LOG316; break;
+case AVCOL_TRC_IEC61966_2_4:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_IEC61966_2_4; break;
+case AVCOL_TRC_BT1361_ECG:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT1361E; break;
+case AVCOL_TRC_IEC61966_2_1:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_IEC61966_2_1; break;
+case AVCOL_TRC_BT2020_10:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT2020_10;break;
+case AVCOL_TRC_BT2020_12:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT2020_12;break;
+default:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_UNDEF;break;
+}
+switch (avctx->colorspace) {
+case AVCOL_SPC_RGB: param.sSpatialLayers[0].uiColorMatrix
= CM_GBR; break;
+case AVCOL_SPC_BT709:param.sSpatialLayers[0].uiColorMatrix
= CM_BT709; break;
+case AVCOL_SPC_UNSPECIFIED: param.sSpatialLayers[0].uiColorMatrix
= CM_UNDEF; break;
+case AVCOL_SPC_FCC: param.sSpatialLayers[0].uiColorMatrix
= CM_FCC; break;
+case AVCOL_SPC_BT470BG: param.sSpatialLayers[0].uiColorMatrix
= CM_BT470BG; break;
+case AVCOL_SPC_SMPTE170M:param.sSpatialLayers[0].uiColorMatrix
= CM_SMPTE170M; break;
+case AVCOL_SPC_SMPTE240M:param.sSpatialLayers[0].uiColorMatrix
= CM_SMPTE240M; break;
+case AVCOL_SPC_YCOCG:param.sSpatialLayers[0].uiColorMatrix
= CM_YCGCO; break;
+case AVCOL_SPC_BT2020_NCL: param.sSpatialLayers[0].uiColorMatrix
=
Re: [FFmpeg-devel] [PATCH] Save FFmpeg colorspace info in openh264 video files.
> > +switch (avctx->color_primaries) {
> > +case AVCOL_PRI_BT709:
> param.sSpatialLayers[0].uiColorPrimaries = CP_BT709; break;
> > +case AVCOL_PRI_UNSPECIFIED:
> param.sSpatialLayers[0].uiColorPrimaries = CP_UNDEF; break;
>
> [ignore]
> Please align vertically.
> [/ignore]
> Is it possible to convince gmail to always use a fixed-width font?
> The patch looks ugly here on gmail but I suspect it was aligned nicely...
>
> Thank you, Carl Eugen
I verified that my original edited file was aligned using vim. Also,
I copied/pasted the code lines from your reply into notepad and
THAT is also aligned.
Greg W.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Save FFmpeg colorspace info in openh264 video files.
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf Of James Almer
> Sent: Friday, December 02, 2016 9:31 AM
>
> On 12/1/2016 6:26 PM, Gregory J. Wolfe wrote:
> > As of version 1.6, libopenh264 saves (in the output video file)
> > information about the color primaries, transfer characteristics,
> > and color matrix used when the video pixel data was created.
> > This patch sets the required libopenh264 data structures using
> > the FFmpeg colorspace information so that video players will
> > know how to properly decode video files created using FFmpeg
> > and libopenh264.
> >
> > Signed-off-by: Gregory J. Wolfe
> > ---
> > libavcodec/libopenh264enc.c | 49
> +
> > 1 file changed, 49 insertions(+)
> >
> > diff --git a/libavcodec/libopenh264enc.c
> b/libavcodec/libopenh264enc.c
> > index e84de27..3b019b8 100644
> > --- a/libavcodec/libopenh264enc.c
> > +++ b/libavcodec/libopenh264enc.c
> > @@ -205,6 +205,55 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > }
> > }
> >
> > +#if OPENH264_VER_AT_LEAST(1, 6)
> > +// set video signal type information
> > +param.sSpatialLayers[0].bVideoSignalTypePresent = true;
> > +param.sSpatialLayers[0].uiVideoFormat = VF_UNDEF; // default;
> choices are VF_: COMPONENT, PAL, NTSC, SECAM, MAC, UNDEF
> > +param.sSpatialLayers[0].bFullRange = avctx->color_range ==
> AVCOL_RANGE_JPEG;
> > +param.sSpatialLayers[0].bColorDescriptionPresent = true;
> > +switch (avctx->color_primaries) {
> > +case AVCOL_PRI_BT709:
> param.sSpatialLayers[0].uiColorPrimaries = CP_BT709; break;
> > +case AVCOL_PRI_UNSPECIFIED:
> param.sSpatialLayers[0].uiColorPrimaries = CP_UNDEF; break;
> > +case AVCOL_PRI_BT470M:
> param.sSpatialLayers[0].uiColorPrimaries = CP_BT470M;break;
> > +case AVCOL_PRI_BT470BG:
> param.sSpatialLayers[0].uiColorPrimaries = CP_BT470BG; break;
> > +case AVCOL_PRI_SMPTE170M:
> param.sSpatialLayers[0].uiColorPrimaries = CP_SMPTE170M;
> break;
> > +case AVCOL_PRI_SMPTE240M:
> param.sSpatialLayers[0].uiColorPrimaries = CP_SMPTE240M;
> break;
> > +case AVCOL_PRI_FILM:
> param.sSpatialLayers[0].uiColorPrimaries = CP_FILM; break;
> > +case AVCOL_PRI_BT2020:
> param.sSpatialLayers[0].uiColorPrimaries = CP_BT2020;break;
> > +default: param.sSpatialLayers[0].uiColorPrimaries
> > =
> CP_UNDEF; break;
> > +}
> > +switch (avctx->color_trc) {
> > +case AVCOL_TRC_BT709:
> param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT709;
> break;
> > +case AVCOL_TRC_UNSPECIFIED:
> param.sSpatialLayers[0].uiTransferCharacteristics = TRC_UNDEF;
> break;
> > +case AVCOL_TRC_GAMMA22:
> param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT470M;
> break;
> > +case AVCOL_TRC_GAMMA28:
> param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT470BG;
> break;
> > +case AVCOL_TRC_SMPTE170M:
> param.sSpatialLayers[0].uiTransferCharacteristics = TRC_SMPTE170M;
> break;
> > +case AVCOL_TRC_SMPTE240M:
> param.sSpatialLayers[0].uiTransferCharacteristics = TRC_SMPTE240M;
> break;
> > +case AVCOL_TRC_LINEAR:
> param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LINEAR;
> break;
> > +case AVCOL_TRC_LOG:
> param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LOG100;
> break;
> > +case AVCOL_TRC_LOG_SQRT:
> param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LOG316;
> break;
> > +case AVCOL_TRC_IEC61966_2_4:
> param.sSpatialLayers[0].uiTransferCharacteristics = TRC_IEC61966_2_4;
> break;
> > +case AVCOL_TRC_BT1361_ECG:
> param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT1361E;
> break;
> > +case AVCOL_TRC_IEC61966_2_1:
> param.sSpatialLayers[0].uiTransferCharacteristics = TRC_IEC61966_2_1;
> break;
> > +case AVCOL_TRC_BT2020_10:
> param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT2020_10;
> break;
> > +case AVCOL_TRC_BT2020_12:
> param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT2020_12;
> break;
> > +default:
> param.sSpatialLayers[0].uiTransferCharacteristics = TRC_UNDEF;
> break;
> > +}
> > +switch (avctx->colorspace) {
> > +case AVCOL_SPC_RGB:
> param.sSpatialLayers[0].uiColorMatrix = CM_GBR; break;
> > +case AVCOL_SPC_BT709:
> param.sSpatialLayers[0].uiColorMa
[FFmpeg-devel] [PATCH] Save FFmpeg colorspace info in openh264 video files.
As of version 1.6, libopenh264 saves (in the output video file)
information about the color primaries, transfer characteristics,
and color matrix used when the video pixel data was created.
This patch sets the required libopenh264 data structures using
the FFmpeg colorspace information so that video players will
know how to properly decode video files created using FFmpeg
and libopenh264.
Signed-off-by: Gregory J. Wolfe
---
libavcodec/libopenh264enc.c | 61 +
1 file changed, 61 insertions(+)
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index e84de27..d8a7ea3 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -205,6 +205,67 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
}
+#if OPENH264_VER_AT_LEAST(1, 6)
+// set video signal type information
+param.sSpatialLayers[0].bVideoSignalTypePresent = true;
+param.sSpatialLayers[0].uiVideoFormat = VF_UNDEF; // default; choices are
VF_: COMPONENT, PAL, NTSC, SECAM, MAC, UNDEF
+param.sSpatialLayers[0].bFullRange = avctx->color_range ==
AVCOL_RANGE_JPEG;
+param.sSpatialLayers[0].bColorDescriptionPresent = true;
+// These switches are intended to filter out all but the values supported
by libopenh264.
+// An unsupported value causes the associated quantity to be set to
"unspecified" and a
+// warning message to be issued.
+switch (avctx->color_primaries) {
+case AVCOL_PRI_BT709:param.sSpatialLayers[0].uiColorPrimaries
= CP_BT709; break;
+case AVCOL_PRI_UNSPECIFIED: param.sSpatialLayers[0].uiColorPrimaries
= CP_UNDEF; break;
+case AVCOL_PRI_BT470M: param.sSpatialLayers[0].uiColorPrimaries
= CP_BT470M;break;
+case AVCOL_PRI_BT470BG: param.sSpatialLayers[0].uiColorPrimaries
= CP_BT470BG; break;
+case AVCOL_PRI_SMPTE170M:param.sSpatialLayers[0].uiColorPrimaries
= CP_SMPTE170M; break;
+case AVCOL_PRI_SMPTE240M:param.sSpatialLayers[0].uiColorPrimaries
= CP_SMPTE240M; break;
+case AVCOL_PRI_FILM: param.sSpatialLayers[0].uiColorPrimaries
= CP_FILM; break;
+case AVCOL_PRI_BT2020: param.sSpatialLayers[0].uiColorPrimaries
= CP_BT2020;break;
+default: param.sSpatialLayers[0].uiColorPrimaries
= CP_UNDEF;
+av_log(avctx, AV_LOG_WARNING, "Unsupported color primaries value %d
was specified;"
+" color primaries value has been set to \"unspecified\"\n",
avctx->color_primaries);
+break;
+}
+switch (avctx->color_trc) {
+case AVCOL_TRC_BT709:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT709;break;
+case AVCOL_TRC_UNSPECIFIED:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_UNDEF;break;
+case AVCOL_TRC_GAMMA22:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT470M; break;
+case AVCOL_TRC_GAMMA28:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT470BG; break;
+case AVCOL_TRC_SMPTE170M:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_SMPTE170M;break;
+case AVCOL_TRC_SMPTE240M:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_SMPTE240M;break;
+case AVCOL_TRC_LINEAR:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LINEAR; break;
+case AVCOL_TRC_LOG:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LOG100; break;
+case AVCOL_TRC_LOG_SQRT:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LOG316; break;
+case AVCOL_TRC_IEC61966_2_4:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_IEC61966_2_4; break;
+case AVCOL_TRC_BT1361_ECG:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT1361E; break;
+case AVCOL_TRC_IEC61966_2_1:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_IEC61966_2_1; break;
+case AVCOL_TRC_BT2020_10:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT2020_10;break;
+case AVCOL_TRC_BT2020_12:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT2020_12;break;
+default:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_UNDEF;
+av_log(avctx, AV_LOG_WARNING, "Unsupported transfer characteristics
value %d was specified;"
+" transfer characteristics value has been set to
\"unspecified\"\n", avctx->color_trc);
+break;
+}
+switch (avctx->colorspace) {
+case AVCOL_SPC_RGB: param.sSpatialLayers[0].uiColorMatrix
= CM_GBR; break;
+case AVCOL_SPC_BT709:param.sSpatialLayers[0].uiColorMatrix
= CM_BT709; break;
+case AVCOL_SPC_UNSPECIFIED: param.sSpatia
Re: [FFmpeg-devel] [PATCH] Allow client to enable/disable openh264 load balancing.
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf Of Michael Niedermayer > Sent: Tuesday, December 13, 2016 2:28 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] Allow client to enable/disable > openh264 load balancing. > > On Thu, Dec 01, 2016 at 03:52:55PM -0500, Gregory J. Wolfe wrote: > > The libopenh264 library allows the client to enable or disable > > load balancing when running multi-threaded. When enabled, the > > slice sizes are dynamically adjusted in order to use the > > multiple threads more efficiently. However, this can also lead > > to valid but slightly different results from run to run. > > Disabling load balancing prevents dynamic slice adjustment and > > yields repeatable results when running multi-threaded, which can > > be important when running test cases. > > > > Signed-off-by: Gregory J. Wolfe > > --- > > libavcodec/libopenh264enc.c | 8 > > 1 file changed, 8 insertions(+) > > Commit messages should start with the part that is changes like > libavcodec/libopenh264enc: ... > > please see the developer docs, if you haven't read them Sorry about that. Before submitting I carefully reviewed the "Submitting patches" and "patch submission checklist" sections, but neglected to also go back and review the "Development Policy" section where it talks about "area changed: ..." in the commit message. Will fix and resubmit. Suggestion: Add to the patch checklist section a reference back to this information (to remind infrequent patch submitters like me who forget stuff from the last time we submitted a patch). Greg W. > > thx > > [...] > -- > Michael GnuPG fingerprint: > 9FF2128B147EF6730BADF133611EC787040B0FAB ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec/libopenh264enc: Allow client to enable/disable openh264 load balancing.
The libopenh264 library allows the client to enable or disable
load balancing when running multi-threaded. When enabled, the
slice sizes are dynamically adjusted in order to use the
multiple threads more efficiently. However, this can also lead
to valid but slightly different results from run to run.
Disabling load balancing prevents dynamic slice adjustment and
yields repeatable results when running multi-threaded, which can
be important when running test cases.
Signed-off-by: Gregory J. Wolfe
---
libavcodec/libopenh264enc.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 648f59b..e84de27 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -47,6 +47,7 @@ typedef struct SVCContext {
int skip_frames;
int skipped;
int cabac;
+int load_balancing;
} SVCContext;
#define OFFSET(x) offsetof(SVCContext, x)
@@ -71,6 +72,7 @@ static const AVOption options[] = {
{ "max_nal_size", "set maximum NAL size in bytes", OFFSET(max_nal_size),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
{ "allow_skip_frames", "allow skipping frames to hit the target bitrate",
OFFSET(skip_frames), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
{ "cabac", "Enable cabac", OFFSET(cabac), AV_OPT_TYPE_INT, { .i64 = 0 },
0, 1, VE },
+{ "load_balancing", "enable/disable dynamic slice adjustment for efficient
use of multiple threads; if enabled, can produce valid but slightly different
results from run to run", OFFSET(load_balancing), AV_OPT_TYPE_BOOL, { .i64 = -1
}, 0, 1, VE },
{ NULL }
};
@@ -150,6 +152,12 @@ FF_ENABLE_DEPRECATION_WARNINGS
param.iLoopFilterDisableIdc = !s->loopfilter;
param.iEntropyCodingModeFlag = 0;
param.iMultipleThreadIdc = avctx->thread_count;
+#if OPENH264_VER_AT_LEAST(1, 6)
+param.bUseLoadBalancing = s->load_balancing; // default is
enabled; -1 means not specified by client
+#else
+if ( s->load_balancing != -1 )
+av_log(avctx, AV_LOG_WARNING, "load_balancing = %d specified, but not
supported prior to libopenh264 v1.6\n", s->load_balancing);
+#endif
if (s->profile && !strcmp(s->profile, "main"))
param.iEntropyCodingModeFlag = 1;
else if (!s->profile && s->cabac)
--
2.5.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec/libopenh264enc: Save FFmpeg colorspace info in openh264 video files.
As of version 1.6, libopenh264 saves (in the output video file)
information about the color primaries, transfer characteristics,
and color matrix used when the video pixel data was created.
This patch sets the required libopenh264 data structures using
the FFmpeg colorspace information so that video players will
know how to properly decode video files created using FFmpeg
and libopenh264.
Signed-off-by: Gregory J. Wolfe
---
libavcodec/libopenh264enc.c | 61 +
1 file changed, 61 insertions(+)
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index e84de27..d8a7ea3 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -205,6 +205,67 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
}
+#if OPENH264_VER_AT_LEAST(1, 6)
+// set video signal type information
+param.sSpatialLayers[0].bVideoSignalTypePresent = true;
+param.sSpatialLayers[0].uiVideoFormat = VF_UNDEF; // default; choices are
VF_: COMPONENT, PAL, NTSC, SECAM, MAC, UNDEF
+param.sSpatialLayers[0].bFullRange = avctx->color_range ==
AVCOL_RANGE_JPEG;
+param.sSpatialLayers[0].bColorDescriptionPresent = true;
+// These switches are intended to filter out all but the values supported
by libopenh264.
+// An unsupported value causes the associated quantity to be set to
"unspecified" and a
+// warning message to be issued.
+switch (avctx->color_primaries) {
+case AVCOL_PRI_BT709:param.sSpatialLayers[0].uiColorPrimaries
= CP_BT709; break;
+case AVCOL_PRI_UNSPECIFIED: param.sSpatialLayers[0].uiColorPrimaries
= CP_UNDEF; break;
+case AVCOL_PRI_BT470M: param.sSpatialLayers[0].uiColorPrimaries
= CP_BT470M;break;
+case AVCOL_PRI_BT470BG: param.sSpatialLayers[0].uiColorPrimaries
= CP_BT470BG; break;
+case AVCOL_PRI_SMPTE170M:param.sSpatialLayers[0].uiColorPrimaries
= CP_SMPTE170M; break;
+case AVCOL_PRI_SMPTE240M:param.sSpatialLayers[0].uiColorPrimaries
= CP_SMPTE240M; break;
+case AVCOL_PRI_FILM: param.sSpatialLayers[0].uiColorPrimaries
= CP_FILM; break;
+case AVCOL_PRI_BT2020: param.sSpatialLayers[0].uiColorPrimaries
= CP_BT2020;break;
+default: param.sSpatialLayers[0].uiColorPrimaries
= CP_UNDEF;
+av_log(avctx, AV_LOG_WARNING, "Unsupported color primaries value %d
was specified;"
+" color primaries value has been set to \"unspecified\"\n",
avctx->color_primaries);
+break;
+}
+switch (avctx->color_trc) {
+case AVCOL_TRC_BT709:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT709;break;
+case AVCOL_TRC_UNSPECIFIED:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_UNDEF;break;
+case AVCOL_TRC_GAMMA22:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT470M; break;
+case AVCOL_TRC_GAMMA28:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT470BG; break;
+case AVCOL_TRC_SMPTE170M:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_SMPTE170M;break;
+case AVCOL_TRC_SMPTE240M:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_SMPTE240M;break;
+case AVCOL_TRC_LINEAR:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LINEAR; break;
+case AVCOL_TRC_LOG:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LOG100; break;
+case AVCOL_TRC_LOG_SQRT:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LOG316; break;
+case AVCOL_TRC_IEC61966_2_4:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_IEC61966_2_4; break;
+case AVCOL_TRC_BT1361_ECG:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT1361E; break;
+case AVCOL_TRC_IEC61966_2_1:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_IEC61966_2_1; break;
+case AVCOL_TRC_BT2020_10:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT2020_10;break;
+case AVCOL_TRC_BT2020_12:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT2020_12;break;
+default:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_UNDEF;
+av_log(avctx, AV_LOG_WARNING, "Unsupported transfer characteristics
value %d was specified;"
+" transfer characteristics value has been set to
\"unspecified\"\n", avctx->color_trc);
+break;
+}
+switch (avctx->colorspace) {
+case AVCOL_SPC_RGB: param.sSpatialLayers[0].uiColorMatrix
= CM_GBR; break;
+case AVCOL_SPC_BT709:param.sSpatialLayers[0].uiColorMatrix
= CM_BT709; break;
+case AVCOL_SPC_UNSPECIFIED: param.sSpatia
[FFmpeg-devel] AAC decoder handles start of audio stream differently (2.6.2 vs. current git)
I am in the process of upgrading our FFmpeg from 2.6.2 to the latest git. One test I ran extracts audio from an AAC stream to a WAV file. When I examine the audio using Audacity, the stream extracted using the latest git is 1600 samples shorter, with the missing samples being from the beginning of the audio stream. Coincidentally, the first audio time stamp in the original audio stream is -1600 samples. So does 2.6.2 have a bug that is fixed in the latest git, or was a bug introduced into the latest git since 2.6.2? Below is the console output from the two test runs (built using MinGW, running on Windows 7). Note that our actual usage is by direct calls to the FFmpeg libraries (I get the same result): % ffmpeg.exe -i F:\VideoTestFiles\StillMation\Ironman2.mov C:\Temp\Ironman2_2.6.2.wav ffmpeg version 2.6.2 Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.8.1 (GCC) configuration: --enable-shared --disable-static --enable-memalign-hack --enable-libmp3lame --enable-libopenh264 --extra-ldflags=-static-libgcc --disable-iconv --enable-nvenc --enable-nonfree libavutil 54. 20.100 / 54. 20.100 libavcodec 56. 26.100 / 56. 26.100 libavformat56. 25.101 / 56. 25.101 libavdevice56. 4.100 / 56. 4.100 libavfilter 5. 11.102 / 5. 11.102 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 1.100 / 1. 1.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'F:\VideoTestFiles\StillMation\Ironman2.mov': Metadata: major_brand : qt minor_version : 512 compatible_brands: qt encoder : Lavf55.50.100 Duration: 00:00:20.21, start: 0.03, bitrate: 146801 kb/s Stream #0:0(eng): Video: qtrle (rle / 0x20656C72), bgra, 1920x1080, 146673 kb/s, 24 fps, 24 tbr, 12288 tbn, 12288 tbc (default) Metadata: handler_name: DataHandler encoder : Lavc55.71.100 qtrle timecode: 00:00:00:00 Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default) Metadata: handler_name: DataHandler Stream #0:2(eng): Data: none (tmcd / 0x64636D74), 0 kb/s Metadata: handler_name: DataHandler timecode: 00:00:00:00 Output #0, wav, to 'C:\Temp\Ironman2_2.6.2.wav': Metadata: major_brand : qt minor_version : 512 compatible_brands: qt ISFT: Lavf56.25.101 Stream #0:0(eng): Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s16, 1536 kb/s (default) Metadata: handler_name: DataHandler encoder : Lavc56.26.100 pcm_s16le Stream mapping: Stream #0:1 -> #0:0 (aac (native) -> pcm_s16le (native)) Press [q] to stop, [?] for help size=3776kB time=00:00:20.13 bitrate=1536.0kbits/s video:0kB audio:3776kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.002017% % ffmpeg.exe -i F:\VideoTestFiles\StillMation\Ironman2.mov C:\Temp\Ironman2_Latest.wav ffmpeg version 3.0.git Copyright (c) 2000-2016 the FFmpeg developers built with gcc 4.8.1 (GCC) configuration: --enable-shared --disable-static --enable-memalign-hack --enable-libmp3lame --enable-libopenh264 --extra-ldflags=-static-libgcc --disable-iconv --enable-nvenc --enable-nonfree libavutil 55. 20.100 / 55. 20.100 libavcodec 57. 34.101 / 57. 34.101 libavformat57. 34.100 / 57. 34.100 libavdevice57. 0.101 / 57. 0.101 libavfilter 6. 41.101 / 6. 41.101 libswscale 4. 1.100 / 4. 1.100 libswresample 2. 0.101 / 2. 0.101 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'F:\VideoTestFiles\StillMation\Ironman2.mov': Metadata: major_brand : qt minor_version : 512 compatible_brands: qt encoder : Lavf55.50.100 Duration: 00:00:20.21, start: 0.00, bitrate: 146801 kb/s Stream #0:0(eng): Video: qtrle (rle / 0x20656C72), bgra, 1920x1080, 146673 kb/s, 24 fps, 24 tbr, 12288 tbn (default) Metadata: handler_name: DataHandler encoder : Lavc55.71.100 qtrle timecode: 00:00:00:00 Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default) Metadata: handler_name: DataHandler Stream #0:2(eng): Data: none (tmcd / 0x64636D74), 0 kb/s Metadata: handler_name: DataHandler timecode: 00:00:00:00 [wav @ 00492420] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead. Output #0, wav, to 'C:\Temp\Ironman2_Latest.wav': Metadata: major_brand : qt minor_version : 512 compatible_brands: qt ISFT: Lavf57.34.100 Stream #0:0(eng): Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s16, 1536 kb/s (default) Metadata: handler_name: DataHandler encoder : Lavc57.34.101 pcm_s16le Stream mapping: Stream #0:1 -> #0:0 (aac (native) -> pcm_s16le (native)) Press [q] to stop, [?] for help size=3770kB time=00:00:
Re: [FFmpeg-devel] AAC decoder handles start of audio stream differently (2.6.2 vs. current git)
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Hendrik Leppkes > Sent: Monday, May 09, 2016 5:27 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] AAC decoder handles start of audio stream > differently (2.6.2 vs. current git) > > On Mon, May 9, 2016 at 11:20 PM, Gregory J Wolfe > wrote: > > I am in the process of upgrading our FFmpeg from 2.6.2 to the latest > > git. One test I ran extracts audio from an AAC stream to a WAV file. > > When I examine the audio using Audacity, the stream extracted using > > the latest git is 1600 samples shorter, with the missing samples being > > from the beginning of the audio stream. Coincidentally, the first > > audio time stamp in the original audio stream is -1600 samples. So > > does 2.6.2 have a bug that is fixed in the latest git, or was a bug > > introduced into the latest git since 2.6.2? > > > > It is common for AAC to have padding at the beginning of the stream to > prime the decoder, those samples being dropped is the proper way to do > this. > And your timestamp seems to confirm this. > > So sounds like latest ffmpeg is doing it right to me. > > - Hendrik OK, thanks, that makes sense. The codec info says that the audio sample delay is 1024 samples. So maybe that's the minimum amount, and in this case the author/original software that created the audio stream used 1600 samples because it works out to exactly 1/30 second. Greg Wolfe, Kodak Alaris ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/libopenh264enc: update to openh264 1.6
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Hendrik Leppkes > Sent: Saturday, May 21, 2016 3:25 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] lavc/libopenh264enc: update to > openh264 1.6 > > On Mon, Mar 7, 2016 at 6:05 PM, Stefano Sabatini > wrote: > > In particular, the slice mode API was changed in commit: > > > > commit 33c378f7b791310e4cb64b53e2bb8f3f3bded105 > > Author: sijchen > > Date: Tue Nov 10 09:50:06 2015 -0800 > > > > change API for slicing part for easier usage (the UseLoadBalancing flag > > is > still under working) > > > > This fixes compilation with latest version of openh264. > > --- > > From the author of this wrapper: > > [20:23:22] just fwiw, the openh264 patch that somebody just > sent, for fixing compilation with 1.6 (which is not released) is just > awful. it changes defaults for lots of options, it changes names for > options, etc, all in one single patch (which breaks compilation with > any earlier version) > [20:23:47] if one wants to add support for 1.6, it shouldn't > break support for earlier versions. and 1.6 isn't released, so the > actual api for that version may still change > [20:24:06] so I would just tell people to stick it and not try > to "support" an unreleased version which is still open for changes > > I agree with this assessment, dropping support for any and all > released versions of the library in favor of a unreleased > in-development version seems bad. > Can't we support both, and address his comments about changing the > options etc? > > - Hendrik FWIW, we at Kodak Alaris are actively using openh264 1.6 (OK so it's not officially released) with FFmpeg. I have manually applied the 1.6 related patches, AND I have an FFmpeg change (soon to be submitted) to support other new capabilities in 1.6. What I would like to see is openh264 1.6 become an official release (soon!), with interface changes conditionally compiled so as not to break builds using older versions. Also, perhaps the pre-1.6 options could be transparently mapped into the new 1.6 options so that there would be a smooth transition. If it would help move this along, I will tentatively volunteer to the do some or all of the work. Greg W., Kodak Alaris ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 3.1 name
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf Of Michael Niedermayer > Sent: Thursday, June 23, 2016 5:01 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: [FFmpeg-devel] FFmpeg 3.1 name > > Hi all > > what shall FFmpeg 3.1 be called ? > > I still have these ideas from past suggestions: > Von Neumann, Einstein, lorentz, poincaré, desitter, de broglie, Gauss, > Galois, Viterbi, Darwin > > Are there other suggestions? > Is something preferred ? > > In absence of any preferrance ill pick something randomly > > Thanks > > -- > Michael GnuPG fingerprint: > 9FF2128B147EF6730BADF133611EC787040B0FAB > Maybe to start a new tradition/policy, and since this will be sort of a June release, I googled famous scientists with birthdays in June. Based on that here are some suggestions, with birthdays/summaries below: Cassini, Crick, Stephenson, Paul, Cousteau, Maxwell, Coulomb, Rutan, Pascal, Turing, Kelvin, Mayer. My pick would be Rutan. - June 8, 1625 Giovanni Cassini, French astronomer who discovered the moons of Saturn - June 8, 1916 Francis Crick, British molecular biologist, physicist, and neuroscientist who co-discovered DNA structure - June 9, 1781 George Stephenson, English inventor of the first steam locomotive engine for railroads - June 9, 1915 Les Paul, American inventor who founded Les Paul guitar, and invented sound-on-sound, the eight-track recorder, over-dubbing, the electronic reverb effect, multi-track tape recording, and the Les Paul electric guitar - June 11, 1910 Jacques-Yves Cousteau, French oceanic explorer who invented diving gear - June 13, 1831 James Clerk Maxwell, Scottish physicist who discovered the electro-magnetic field - June 14, 1736 Charles-Augustin de Coulomb, French physicist who wrote Coulomb's Law and invented the torsion balance - June 17, - 1943 Burt Rutan, American aerospace engineer who invented light, strong, unusual-looking, energy-efficient aircraft designed Voyager first plane to fly around the world without stopping or refueling - June 19, 1623 Blaise Pascal, French mathematician and physicist who invented an early calculator - June 23, 1912 - Alan Turing, mathematician and computer theory pioneer, who invented the Turing Machine - June 26, 1824 William Thomson Kelvin, British physicist who invented the Kelvin Scale - June 28, 1906 - Maria Goeppert Mayer, American atomic physicist, who proposed the nuclear shell model of the atomic nucleus, Nobel Prize 1963 Greg Wolfe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 3.1 name
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf Of Wang Bin > Sent: Thursday, June 23, 2016 10:02 PM > Subject: Re: [FFmpeg-devel] FFmpeg 3.1 name > > What about choosing a scientist who was born in FFmpeg release > month? Don't want it to look like I'm trying to steal someone else's idea; I sent my suggestion in before I saw this reply. GOOD IDEA! See my later reply for suggestions! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Setting the frame rate in libavcodec/libopenh264enc.c
We have been using Cisco's libopenh264 as part of FFmpeg with good results. However, function svc_encode_init() in libavcodec/libopenh264enc.c appears to be setting the frame rate incorrectly. The line of code in question looks like: param.fMaxFrameRate = avctx->time_base.den / avctx->time_base.num; Since fMaxFrameRate is of type float, shouldn't this be something like: param.fMaxFrameRate = avctx->time_base.den / (double)avctx->time_base.num; Or is there some reason why the frame rate should get truncated to an integer? Greg Wolfe, Kodak Alaris (formerly part of Eastman Kodak) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add AVOptions for libopenh264 encoder message log level and log function.
By default, the libopenh264 encoder logs error and warning messages to
stderr. However, libopenh264 also provides a SetOption() function that
allows the client to set the message logging level (e.g., error, warning,
debug) and a client-supplied message logging function (whose signature
must conform to libopenh264 type WelsTraceCallback).
To enable this from the FFmpeg level, file libopenh264enc.c has been
modified to add AVOption entries OPTION_TRACEL_LEVEL (log level)
and OPTION_TRACE_CALLBACK (log function). The names are derived from
the enumerator values ENCODER_OPTION_TRACE_LEVEL and
ENCODER_OPTION_TRACE_CALLBACK which are passed to SetOption(). While
they are somewhat verbose, they are very likely unique across encoders.
Some FFmpeg command line examples. To disable all libopenh264 messages:
ffmpeg ... -OPTION_TRACE_LEVEL quiet
To enable only error messages:
ffmpeg ... -OPTION_TRACE_LEVEL error
The OPTION_TRACE_CALLBACK option can obviously not be used from the
command line since it requires the address of a function. When used
programmatically, the function address must be converted to a string
representation of the function address as a signed 64-bit integer.
The function signature defined by libopenh264 type WelsTraceCallback
can be found in source file codec/api/svc/codec_api.h. The default
implementation used by libopenh264 is function welsStderrTrace(), and
can be found in source file codec/common/source/welsCodecTrace.cpp.
Signed-off-by: Gregory J. Wolfe
---
libavcodec/libopenh264enc.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index b315e8b..146bbaf 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -37,6 +37,9 @@ typedef struct SVCContext {
int slice_mode;
int loopfilter;
char *profile;
+int OPTION_TRACE_LEVEL;
+int64_t OPTION_TRACE_CALLBACK; // message logging function, type is
+// actually WelsTraceCallback
} SVCContext;
#define OPENH264_VER_AT_LEAST(maj, min) \
@@ -52,6 +55,17 @@ static const AVOption options[] = {
{ "auto", "Automatic number of slices according to number of threads", 0,
AV_OPT_TYPE_CONST, { .i64 = SM_AUTO_SLICE }, 0, 0, VE, "slice_mode" },
{ "loopfilter", "Enable loop filter", OFFSET(loopfilter), AV_OPT_TYPE_INT,
{ .i64 = 1 }, 0, 1, VE },
{ "profile", "Set profile restrictions", OFFSET(profile),
AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
+{ "OPTION_TRACE_LEVEL", "Message logging level",
OFFSET(OPTION_TRACE_LEVEL), AV_OPT_TYPE_INT, { .i64 = WELS_LOG_DEFAULT },
WELS_LOG_QUIET, WELS_LOG_RESV, VE, "OPTION_TRACE_LEVEL" },
+{ "default", "default libopenh264 message logging", 0, AV_OPT_TYPE_CONST,
{ .i64 = WELS_LOG_DEFAULT }, 0, 0, VE, "OPTION_TRACE_LEVEL" },
+{ "quiet", "quiet mode", 0, AV_OPT_TYPE_CONST, { .i64 = WELS_LOG_QUIET },
0, 0, VE, "OPTION_TRACE_LEVEL" },
+{ "error", "log error messages", 0, AV_OPT_TYPE_CONST, { .i64 =
WELS_LOG_ERROR }, 0, 0, VE, "OPTION_TRACE_LEVEL" },
+{ "warning", "log warning+err messages", 0, AV_OPT_TYPE_CONST, { .i64 =
WELS_LOG_WARNING }, 0, 0, VE, "OPTION_TRACE_LEVEL" },
+{ "info", "log informational+wrn+err messages", 0, AV_OPT_TYPE_CONST, {
.i64 = WELS_LOG_INFO }, 0, 0, VE, "OPTION_TRACE_LEVEL" },
+{ "debug", "log debug+inf+wrn+err messages", 0, AV_OPT_TYPE_CONST, { .i64
= WELS_LOG_DEBUG }, 0, 0, VE, "OPTION_TRACE_LEVEL" },
+{ "detail", "log detail+dbg+inf+wrn+err messages", 0, AV_OPT_TYPE_CONST, {
.i64 = WELS_LOG_DETAIL }, 0, 0, VE, "OPTION_TRACE_LEVEL" },
+// for OPTION_TRACE_CALLBACK, default value of 0 means do not change;
otherwise, it is the
+// address of the WelsTraceCallback message logging function, passed in as
an int64_t
+{ "OPTION_TRACE_CALLBACK", "Message logging function, 0 means do not
change", OFFSET(OPTION_TRACE_CALLBACK), AV_OPT_TYPE_INT64, { .i64 = 0 },
INT64_MIN, INT64_MAX, VE, "OPTION_TRACE_CALLBACK" },
{ NULL }
};
@@ -89,6 +103,14 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)
av_log(avctx, AV_LOG_ERROR, "Unable to create encoder\n");
return AVERROR_UNKNOWN;
}
+// set message logging options
+// message logging level
+
(*s->encoder)->SetOption(s->encoder,ENCODER_OPTION_TRACE_LEVEL,&s->OPTION_TRACE_LEVEL);
+if ( s->OPTION_TRACE_CALLBACK )
+{//set message logging function
+WelsTraceCallback OPTION_TRACE_CALLBACK = (WelsTraceCallback)
((uintptr_t)s->OPTION_TRACE_CALLBACK);
+
(*s->encoder)->SetOption(s->encoder,ENCODER_OPTION_TRACE_CALLBACK,(void
*)&OPTION_TRACE_CALLBACK);
+}//set message logging function
(*s->encoder)->GetDefaultParams(s->encoder, ¶m);
--
1.8.5.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add AVOptions for libopenh264 encoder message log level and log function.
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Paul B Mahol
> Sent: Wednesday, September 02, 2015 1:15 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] Add AVOptions for libopenh264
> encoder message log level and log function.
>
> Dana 2. 9. 2015. 19:10 osoba "Gregory J. Wolfe" <
> gregory.wo...@kodakalaris.com> napisala je:
> >
> > By default, the libopenh264 encoder logs error and warning messages to
> > stderr. However, libopenh264 also provides a SetOption() function
> > that allows the client to set the message logging level (e.g., error,
> > warning,
> > debug) and a client-supplied message logging function (whose signature
> > must conform to libopenh264 type WelsTraceCallback).
> >
> > To enable this from the FFmpeg level, file libopenh264enc.c has been
> > modified to add AVOption entries OPTION_TRACEL_LEVEL (log level) and
> > OPTION_TRACE_CALLBACK (log function). The names are derived from the
> > enumerator values ENCODER_OPTION_TRACE_LEVEL and
> > ENCODER_OPTION_TRACE_CALLBACK which are passed to SetOption().
> While
> > they are somewhat verbose, they are very likely unique across encoders.
> >
> > Some FFmpeg command line examples. To disable all libopenh264
> messages:
> >
> > ffmpeg ... -OPTION_TRACE_LEVEL quiet
> >
> > To enable only error messages:
> >
> > ffmpeg ... -OPTION_TRACE_LEVEL error
> >
> > The OPTION_TRACE_CALLBACK option can obviously not be used from the
> > command line since it requires the address of a function. When used
> > programmatically, the function address must be converted to a string
> > representation of the function address as a signed 64-bit integer.
> >
> > The function signature defined by libopenh264 type WelsTraceCallback
> > can be found in source file codec/api/svc/codec_api.h. The default
> > implementation used by libopenh264 is function welsStderrTrace(), and
> > can be found in source file codec/common/source/welsCodecTrace.cpp.
>
> Why this doesnt make use of av_log functions?
The libopenh264 library requires its own specific signature for the log function
that you give to it. If the client so desires, he/she can create a message
logging function with the required libopenh264 signature that then invokes
av_log. Note that libopenh264 already formats its messages using its own
prefix strings, similar to what FFmpeg does.
>
> CAPS LOCK OPTIONS ARE UNACCEPTABLE
>
I'm guessing that you're objecting to the command line switch values like
-OPTION_TRACE_LEVEL. I did not want to use something like loglevel
since it is already used by FFmpeg. libopenh264 uses its own
enumerator values for its message logging level, so I simply
tried to come up with something that would not conflict with any existing
AVOptions. Do the AVOption keywords have to be unique across all
formats/encoders/decoders? Please supply some guidance as to
requirements/restrictions and I will be happy to update the patch.
> >
> > Signed-off-by: Gregory J. Wolfe
> > ---
> > libavcodec/libopenh264enc.c | 22 ++
> > 1 file changed, 22 insertions(+)
> >
> > diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
> > index b315e8b..146bbaf 100644
> > --- a/libavcodec/libopenh264enc.c
> > +++ b/libavcodec/libopenh264enc.c
> > @@ -37,6 +37,9 @@ typedef struct SVCContext {
> > int slice_mode;
> > int loopfilter;
> > char *profile;
> > +int OPTION_TRACE_LEVEL;
> > +int64_t OPTION_TRACE_CALLBACK; // message logging function, type is
> > +// actually WelsTraceCallback
> > } SVCContext;
> >
> > #define OPENH264_VER_AT_LEAST(maj, min) \ @@ -52,6 +55,17 @@
> static
> > const AVOption options[] = {
> > { "auto", "Automatic number of slices according to number of
> threads", 0, AV_OPT_TYPE_CONST, { .i64 = SM_AUTO_SLICE }, 0, 0, VE,
> "slice_mode" },
> > { "loopfilter", "Enable loop filter", OFFSET(loopfilter),
> AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, VE },
> > { "profile", "Set profile restrictions", OFFSET(profile),
> AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
> > +{ "OPTION_TRACE_LEVEL", "Message logging level",
> OFFSET(OPTION_TRACE_LEVEL), AV_OPT_TYPE_INT, { .i64 =
> WELS_LOG_DEFAULT }, WELS_LOG_QUIET, WELS_LOG_RESV, VE,
> "OPTION_TRACE_LEVEL" },
> > +{ "default", "default libopenh264 message logging", 0,
>
Re: [FFmpeg-devel] [PATCH] Add AVOptions for libopenh264 encoder message log level and log function.
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of wm4 > Sent: Wednesday, September 02, 2015 2:28 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] Add AVOptions for libopenh264 > encoder message log level and log function. > > On Wed, 2 Sep 2015 17:36:30 + > Gregory J Wolfe wrote: > > > > -Original Message- > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > > > Behalf Of Paul B Mahol > > > Sent: Wednesday, September 02, 2015 1:15 PM > > > To: FFmpeg development discussions and patches > > > Subject: Re: [FFmpeg-devel] [PATCH] Add AVOptions for libopenh264 > > > encoder message log level and log function. > > > > > > Dana 2. 9. 2015. 19:10 osoba "Gregory J. Wolfe" < > > > gregory.wo...@kodakalaris.com> napisala je: > > > > > > > > By default, the libopenh264 encoder logs error and warning > > > > messages to stderr. However, libopenh264 also provides a > > > > SetOption() function that allows the client to set the message > > > > logging level (e.g., error, warning, > > > > debug) and a client-supplied message logging function (whose > > > > signature must conform to libopenh264 type WelsTraceCallback). > > > > > > > > To enable this from the FFmpeg level, file libopenh264enc.c has > > > > been modified to add AVOption entries OPTION_TRACEL_LEVEL (log > > > > level) and OPTION_TRACE_CALLBACK (log function). The names are > > > > derived from the enumerator values ENCODER_OPTION_TRACE_LEVEL > and > > > > ENCODER_OPTION_TRACE_CALLBACK which are passed to SetOption(). > > > While > > > > they are somewhat verbose, they are very likely unique across > encoders. > > > > > > > > Some FFmpeg command line examples. To disable all libopenh264 > > > messages: > > > > > > > > ffmpeg ... -OPTION_TRACE_LEVEL quiet > > > > > > > > To enable only error messages: > > > > > > > > ffmpeg ... -OPTION_TRACE_LEVEL error > > > > > > > > The OPTION_TRACE_CALLBACK option can obviously not be used from > > > > the command line since it requires the address of a function. > > > > When used programmatically, the function address must be converted > > > > to a string representation of the function address as a signed 64-bit > integer. > > > > > > > > The function signature defined by libopenh264 type > > > > WelsTraceCallback can be found in source file > > > > codec/api/svc/codec_api.h. The default implementation used by > > > > libopenh264 is function welsStderrTrace(), and can be found in source > file codec/common/source/welsCodecTrace.cpp. > > > > > > Why this doesnt make use of av_log functions? > > > > The libopenh264 library requires its own specific signature for the > > log function that you give to it. If the client so desires, he/she > > can create a message logging function with the required libopenh264 > > signature that then invokes av_log. Note that libopenh264 already > > formats its messages using its own prefix strings, similar to what FFmpeg > does. > > > > > > > > CAPS LOCK OPTIONS ARE UNACCEPTABLE > > > > > +1 > > > I'm guessing that you're objecting to the command line switch values > > like -OPTION_TRACE_LEVEL. I did not want to use something like > > loglevel since it is already used by FFmpeg. libopenh264 uses its own > > enumerator values for its message logging level, so I simply tried to > > come up with something that would not conflict with any existing > > AVOptions. Do the AVOption keywords have to be unique across all > > formats/encoders/decoders? Please supply some guidance as to > > requirements/restrictions and I will be happy to update the patch. > > I don't see the slightest point in this. You could setup a callback which in > turn > calls av_log(). This would be quite sane. It'd just work, and the user doesn't > have to set an obscure encoder-specific option to get expected behavior. I'm > not sure what you're objecting here. Is it maybe that the libopenh264 > callback doesn't have a log level parameter? > > In addition to being extremely roundabout to the user (as opposed to using > av_log), OPTION_TRACE_CALLBACK is also missing documentation. > What signature does it have? I think I see what you're
Re: [FFmpeg-devel] [PATCH] lavc/libopenh264enc: apply minor consistency fixes to options text
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Stefano Sabatini
> Sent: Tuesday, September 08, 2015 11:52 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/libopenh264enc: apply minor
> consistency fixes to options text
>
> On date Tuesday 2015-09-08 16:41:57 +0200, Clément Bœsch encoded:
> > On Tue, Sep 08, 2015 at 03:59:58PM +0200, Stefano Sabatini wrote:
> > > ---
> > > libavcodec/libopenh264enc.c | 12 ++--
> > > 1 file changed, 6 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/libavcodec/libopenh264enc.c
> > > b/libavcodec/libopenh264enc.c index b315e8b..84a9cb1 100644
> > > --- a/libavcodec/libopenh264enc.c
> > > +++ b/libavcodec/libopenh264enc.c
> > > @@ -46,12 +46,12 @@ typedef struct SVCContext { #define OFFSET(x)
> > > offsetof(SVCContext, x) #define VE AV_OPT_FLAG_VIDEO_PARAM |
> > > AV_OPT_FLAG_ENCODING_PARAM static const AVOption options[] = {
> > > -{ "slice_mode", "Slice mode", OFFSET(slice_mode),
> AV_OPT_TYPE_INT, { .i64 = SM_AUTO_SLICE }, SM_SINGLE_SLICE,
> SM_RESERVED, VE, "slice_mode" },
> > > -{ "fixed", "A fixed number of slices", 0, AV_OPT_TYPE_CONST, { .i64 =
> SM_FIXEDSLCNUM_SLICE }, 0, 0, VE, "slice_mode" },
> > > -{ "rowmb", "One slice per row of macroblocks", 0,
> AV_OPT_TYPE_CONST, { .i64 = SM_ROWMB_SLICE }, 0, 0, VE, "slice_mode" },
> > > -{ "auto", "Automatic number of slices according to number of
> threads", 0, AV_OPT_TYPE_CONST, { .i64 = SM_AUTO_SLICE }, 0, 0, VE,
> "slice_mode" },
> > > -{ "loopfilter", "Enable loop filter", OFFSET(loopfilter),
> AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, VE },
> > > -{ "profile", "Set profile restrictions", OFFSET(profile),
> AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
> >
> > > +{ "slice_mode", "set lice mode", OFFSET(slice_mode),
"set lice mode" probably should be "set slice mode".
> > > + AV_OPT_TYPE_INT, { .i64 = SM_AUTO_SLICE }, SM_SINGLE_SLICE,
> > > + SM_RESERVED, VE, "slice_mode" },
> >
> > slice
>
> Locally fixed.
>
> > > +{ "fixed", "a fixed number of slices", 0, AV_OPT_TYPE_CONST, {
> > > .i64
> = SM_FIXEDSLCNUM_SLICE }, 0, 0, VE, "slice_mode" },
> > > +{ "rowmb", "one slice per row of macroblocks", 0,
> AV_OPT_TYPE_CONST, { .i64 = SM_ROWMB_SLICE }, 0, 0, VE, "slice_mode" },
> > > +{ "auto", "automatic number of slices according to number of
> threads", 0, AV_OPT_TYPE_CONST, { .i64 = SM_AUTO_SLICE }, 0, 0, VE,
> "slice_mode" },
> > > +{ "loopfilter", "enable loop filter", OFFSET(loopfilter),
> AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, VE },
> > > +{ "profile", "set profile restrictions", OFFSET(profile),
> > > + AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
> > > { NULL }
> > > };
> >
> > rest LGTM
>
> Will push soon, thanks.
> --
> FFmpeg = Fabulous and Friendly Merciful Powered Epic Geisha
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Use av_log() to log messages from the libopenh264 encoder.
File libopenh264enc.c has been modified so that the encoder uses av_log()
to log messages (error, warning, info, etc.) instead of logging them
directly to stderr. At the time the encoder is created, the current
libav log level is mapped to an equivalent libopenh264 log level. This
log level, and a message logging function that invokes av_log() to
actually log messages, are then set on the encoder.
Signed-off-by: Gregory J. Wolfe
---
libavcodec/libopenh264enc.c | 90 +
1 file changed, 90 insertions(+)
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 4ae..44ad251 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -59,6 +59,72 @@ static const AVClass class = {
"libopenh264enc", av_default_item_name, options, LIBAVUTIL_VERSION_INT
};
+// Convert libav log level to equivalent libopenh264 log level. Given the
+// conversions below, you must set the libav log level to something greater
+// than AV_LOG_DEBUG if you want to see WELS_LOG_DETAIL messages.
+static int libav_to_libopenh264_log_level (
+int libav_log_level
+)
+{
+int equiv_libopenh264_log_level;
+if ( libav_log_level > AV_LOG_DEBUG )
+equiv_libopenh264_log_level = WELS_LOG_DETAIL; // > AV_LOG_DEBUG;
this is EXTREMELY detailed
+else if ( libav_log_level >= AV_LOG_DEBUG )
+equiv_libopenh264_log_level = WELS_LOG_DEBUG;// AV_LOG_DEBUG
+else if ( libav_log_level >= AV_LOG_INFO )
+equiv_libopenh264_log_level = WELS_LOG_INFO; // AV_LOG_INFO,
AV_LOG_VERBOSE
+else if ( libav_log_level >= AV_LOG_WARNING )
+equiv_libopenh264_log_level = WELS_LOG_WARNING; // AV_LOG_WARNING
+else if ( libav_log_level >= AV_LOG_ERROR )
+equiv_libopenh264_log_level = WELS_LOG_ERROR;// AV_LOG_ERROR
+else
+equiv_libopenh264_log_level = WELS_LOG_QUIET;// AV_LOG_QUIET,
AV_LOG_PANIC, AV_LOG_FATAL
+return equiv_libopenh264_log_level;
+}
+
+// Convert libopenh264 log level to equivalent libav log level.
+static int libopenh264_to_libav_log_level (
+int libopenh264_log_level
+)
+{
+int equiv_libav_log_level;
+if ( libopenh264_log_level >= WELS_LOG_DETAIL )
+equiv_libav_log_level = AV_LOG_DEBUG + 1; // WELS_LOG_DETAIL
+else if ( libopenh264_log_level >= WELS_LOG_DEBUG )
+equiv_libav_log_level = AV_LOG_DEBUG; // WELS_LOG_DEBUG
+else if ( libopenh264_log_level >= WELS_LOG_INFO )
+equiv_libav_log_level = AV_LOG_INFO;// WELS_LOG_INFO
+else if ( libopenh264_log_level >= WELS_LOG_WARNING )
+equiv_libav_log_level = AV_LOG_WARNING; // WELS_LOG_WARNING
+else if ( libopenh264_log_level >= WELS_LOG_ERROR )
+equiv_libav_log_level = AV_LOG_ERROR; // WELS_LOG_ERROR
+else
+equiv_libav_log_level = AV_LOG_QUIET; // WELS_LOG_QUIET
+return equiv_libav_log_level;
+}
+
+// This function will be provided to the libopenh264 library. The function
will be called
+// when libopenh264 wants to log a message (error, warning, info, etc.). The
signature for
+// this function (defined in .../codec/api/svc/codec_api.h) is:
+//
+//typedef void (*WelsTraceCallback) (void* ctx, int level, const char*
string);
+
+static void libopenh264_trace_callback (
+void * ctx,
+int level,
+char const *msg
+)
+{
+// The message will be logged only if the requested EQUIVALENT libav log
level is
+// less than or equal to the current libav log level. Note, however, that
before
+// this function is called, welsCodecTrace::CodecTrace() will have already
discarded
+// the message (and this function will not be called) if the requested
libopenh264
+// log level "level" is greater than the current libopenh264 log level.
+int equiv_libav_log_level = libopenh264_to_libav_log_level(level);
+if ( equiv_libav_log_level <= av_log_get_level() )
+av_log((AVCodecContext *) ctx, equiv_libav_log_level, "%s\n", msg);
+}
+
static av_cold int svc_encode_close(AVCodecContext *avctx)
{
SVCContext *s = avctx->priv_data;
@@ -73,6 +139,8 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)
SVCContext *s = avctx->priv_data;
SEncParamExt param = { 0 };
int err = AVERROR_UNKNOWN;
+int equiv_libopenh264_log_level;
+WelsTraceCallback callback_function;
// Mingw GCC < 4.7 on x86_32 uses an incorrect/buggy ABI for the
WelsGetCodecVersion
// function (for functions returning larger structs), thus skip the check
in those
@@ -90,6 +158,28 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)
return AVERROR_UNKNOWN;
}
+// Set libopenh264 message logging level for this instance of the encoder
using
+// the current libav lo
