[FFmpeg-devel] pngdsp add bytes padding
Hi,
While working on PNG DSP, I realized the filter up was doing extra
overflow checks on the bytes non multiple of the long word size. This
logic is present in both C and x86 ASM. Here is the current C code for
reference:
-- 8<
// 0x7f7f7f7f or 0x7f7f7f7f7f7f7f7f or whatever, depending on the cpu's native
arithmetic size
#define pb_7f (~0UL / 255 * 0x7f)
#define pb_80 (~0UL / 255 * 0x80)
static void add_bytes_l2_c(uint8_t *dst, uint8_t *src1, uint8_t *src2, int w)
{
long i;
for (i = 0; i <= w - (int) sizeof(long); i += sizeof(long)) {
long a = *(long *)(src1 + i);
long b = *(long *)(src2 + i);
*(long *)(dst + i) = ((a & pb_7f) + (b & pb_7f)) ^ ((a ^ b) & pb_80);
}
for (; i < w; i++)
dst[i] = src1[i] + src2[i];
}
-- 8<
The thing is, the buffers seem to be 0 padded to 16 (see
av_fast_padded_malloc() calls). I'm assuming there are cases where it's
not?
In any case, it looks like either the zero padding or the overflow checks
should go away. Removing the check will obviously make things much simpler but
I'm not sure that's possible.
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] pngdsp add bytes padding
On Thu, Feb 18, 2016 at 11:36:18AM +0100, Clément Bœsch wrote:
> Hi,
>
> While working on PNG DSP, I realized the filter up was doing extra
> overflow checks on the bytes non multiple of the long word size. This
> logic is present in both C and x86 ASM. Here is the current C code for
> reference:
>
> -- 8<
>
> // 0x7f7f7f7f or 0x7f7f7f7f7f7f7f7f or whatever, depending on the cpu's
> native arithmetic size
> #define pb_7f (~0UL / 255 * 0x7f)
> #define pb_80 (~0UL / 255 * 0x80)
>
> static void add_bytes_l2_c(uint8_t *dst, uint8_t *src1, uint8_t *src2, int w)
> {
> long i;
> for (i = 0; i <= w - (int) sizeof(long); i += sizeof(long)) {
> long a = *(long *)(src1 + i);
> long b = *(long *)(src2 + i);
> *(long *)(dst + i) = ((a & pb_7f) + (b & pb_7f)) ^ ((a ^ b) & pb_80);
> }
> for (; i < w; i++)
> dst[i] = src1[i] + src2[i];
> }
>
> -- 8<
>
> The thing is, the buffers seem to be 0 padded to 16 (see
> av_fast_padded_malloc() calls). I'm assuming there are cases where it's
> not?
isnt dst the AVFrame in one call ?
so that this would write over width if it wrote beyond ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No great genius has ever existed without some touch of madness. -- Aristotle
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Question about "make distclean" after "git pull"
L'octidi 28 pluviôse, an CCXXIV, Nicolas George a écrit : > There may > have been cases where forgetting distclean would cause bugs more subtle than > that, but I do not remember the specifics. Just found one: .d files contained the full path of headers for an old version of libvpx that I just removed, they caused the compiler to still use them for some reason, and that caused ABI incompatibility with the lib. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Question about "make distclean" after "git pull"
On 02/18/2016 12:45 PM, Nicolas George wrote: L'octidi 28 pluviôse, an CCXXIV, Nicolas George a écrit : There may have been cases where forgetting distclean would cause bugs more subtle than that, but I do not remember the specifics. Just found one: .d files contained the full path of headers for an old version of libvpx that I just removed, they caused the compiler to still use them for some reason, and that caused ABI incompatibility with the lib. Regards, Ouch. Thanks for the "use case". Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avformat: add ff_reshuffle_raw_rgb()
On Wed, Feb 17, 2016 at 04:28:22PM +0100, Nicolas George wrote: > Le nonidi 29 pluviôse, an CCXXIV, Michael Niedermayer a écrit : > > +int ff_reshuffle_raw_rgb(AVFormatContext *s, AVPacket **ppkt, > > AVCodecContext *enc, int expected_stride); > > A little doxy to tell us what it actually does would be nice. > > > \ No newline at end of file > > Just in case you did not notice this. both fixed applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill hundred thousands of 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] [PATCH 2/3] avformat/avienc: Split avi_write_packet_internal() out
On Wed, Feb 17, 2016 at 02:02:20PM +0100, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavformat/avienc.c | 19 +-- > 1 file changed, 17 insertions(+), 2 deletions(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sws/aarch64: add {nv12, nv21, yuv420p, yuv422p}_to_{argb, rgba, abgr, rgba}_neon
Clément Bœsch pkh.me> writes: > It's not tested on real hardware (qemu only), so I have > no idea about performance. I can test this on real hardware if you can provide (exact) command lines. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sws/aarch64: add {nv12, nv21, yuv420p, yuv422p}_to_{argb, rgba, abgr, rgba}_neon
On Thu, Feb 18, 2016 at 01:00:10PM +, Carl Eugen Hoyos wrote: > Clément Bœsch pkh.me> writes: > > > It's not tested on real hardware (qemu only), so I have > > no idea about performance. > > I can test this on real hardware if you can provide > (exact) command lines. > for ifmt in nv12 nv21 yuv420p yuv422p; do for ofmt in argb rgba abgr bgra; do ./ffmpeg -f lavfi -i testsrc2=d=10 -vf format=$ifmt,format=$ofmt -f null - done done -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sws/aarch64: add {nv12, nv21, yuv420p, yuv422p}_to_{argb, rgba, abgr, rgba}_neon
On Thu, Feb 18, 2016 at 02:40:06PM +0100, Clément Bœsch wrote: > On Thu, Feb 18, 2016 at 01:00:10PM +, Carl Eugen Hoyos wrote: > > Clément Bœsch pkh.me> writes: > > > > > It's not tested on real hardware (qemu only), so I have > > > no idea about performance. > > > > I can test this on real hardware if you can provide > > (exact) command lines. > > > > for ifmt in nv12 nv21 yuv420p yuv422p; do > for ofmt in argb rgba abgr bgra; do > ./ffmpeg -f lavfi -i testsrc2=d=10 -vf format=$ifmt,format=$ofmt -f > null - > done > done This will unfortunately involve more converts (testsrc fmt -> ifmt) so it won't really give you much hint. You probably want to test with sth like av_gettime() before and after the ff_##ifmt##_to_##ofmt##_neon_##precision() calls in libswscale/aarch64/swscale_unscaled.c -- 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] [PATCH] lavf/options_table: mark use_wallclock_as_timestamps as boolean
It was probably forgotten to convert this to AV_OPT_TYPE_BOOL, because that's how it is actually used. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/options_table: mark use_wallclock_as_timestamps as boolean
It is only used in a boolean context. Also clarify its documentation.
Signed-off-by: Moritz Barsnick
---
doc/formats.texi| 2 +-
libavformat/options_table.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/formats.texi b/doc/formats.texi
index 617cda5..f79ebe2 100644
--- a/doc/formats.texi
+++ b/doc/formats.texi
@@ -147,7 +147,7 @@ a packet for each stream, regardless of the maximum
timestamp
difference between the buffered packets.
@item use_wallclock_as_timestamps @var{integer} (@emph{input})
-Use wallclock as timestamps.
+Use wallclock as timestamps if set to 1. Default is 0.
@item avoid_negative_ts @var{integer} (@emph{output})
diff --git a/libavformat/options_table.h b/libavformat/options_table.h
index 8926fe5..74923d8 100644
--- a/libavformat/options_table.h
+++ b/libavformat/options_table.h
@@ -78,7 +78,7 @@ static const AVOption avformat_options[] = {
{"careful","consider things that violate the spec, are fast to check and
have not been seen in the wild as errors", 0, AV_OPT_TYPE_CONST, {.i64 =
AV_EF_CAREFUL }, INT_MIN, INT_MAX, D, "err_detect"},
{"compliant", "consider all spec non compliancies as errors", 0,
AV_OPT_TYPE_CONST, {.i64 = AV_EF_COMPLIANT }, INT_MIN, INT_MAX, D,
"err_detect"},
{"aggressive", "consider things that a sane encoder shouldn't do as an error",
0, AV_OPT_TYPE_CONST, {.i64 = AV_EF_AGGRESSIVE }, INT_MIN, INT_MAX, D,
"err_detect"},
-{"use_wallclock_as_timestamps", "use wallclock as timestamps",
OFFSET(use_wallclock_as_timestamps), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX-1,
D},
+{"use_wallclock_as_timestamps", "use wallclock as timestamps",
OFFSET(use_wallclock_as_timestamps), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, D},
{"skip_initial_bytes", "set number of bytes to skip before reading header and
frames", OFFSET(skip_initial_bytes), AV_OPT_TYPE_INT64, {.i64 = 0}, 0,
INT64_MAX-1, D},
{"correct_ts_overflow", "correct single timestamp overflows",
OFFSET(correct_ts_overflow), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, D},
{"flush_packets", "enable flushing of the I/O context after each packet",
OFFSET(flush_packets), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, E},
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sws/aarch64: add {nv12, nv21, yuv420p, yuv422p}_to_{argb, rgba, abgr, rgba}_neon
On 2/18/2016 10:42 AM, Clément Bœsch wrote: > On Thu, Feb 18, 2016 at 02:40:06PM +0100, Clément Bœsch wrote: >> On Thu, Feb 18, 2016 at 01:00:10PM +, Carl Eugen Hoyos wrote: >>> Clément Bœsch pkh.me> writes: >>> It's not tested on real hardware (qemu only), so I have no idea about performance. >>> >>> I can test this on real hardware if you can provide >>> (exact) command lines. >>> >> >> for ifmt in nv12 nv21 yuv420p yuv422p; do >> for ofmt in argb rgba abgr bgra; do >> ./ffmpeg -f lavfi -i testsrc2=d=10 -vf format=$ifmt,format=$ofmt -f >> null - >> done >> done > > This will unfortunately involve more converts (testsrc fmt -> ifmt) so it > won't really give you much hint. You probably want to test with sth like > av_gettime() before and after the > ff_##ifmt##_to_##ofmt##_neon_##precision() calls in > libswscale/aarch64/swscale_unscaled.c The START_TIMER and STOP_TIMER() macros are made specifically for this scenario. > > > > ___ > 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] sws/aarch64: add {nv12, nv21, yuv420p, yuv422p}_to_{argb, rgba, abgr, rgba}_neon
On Thu, Feb 18, 2016 at 11:12:19AM -0300, James Almer wrote: > On 2/18/2016 10:42 AM, Clément Bœsch wrote: > > On Thu, Feb 18, 2016 at 02:40:06PM +0100, Clément Bœsch wrote: > >> On Thu, Feb 18, 2016 at 01:00:10PM +, Carl Eugen Hoyos wrote: > >>> Clément Bœsch pkh.me> writes: > >>> > It's not tested on real hardware (qemu only), so I have > no idea about performance. > >>> > >>> I can test this on real hardware if you can provide > >>> (exact) command lines. > >>> > >> > >> for ifmt in nv12 nv21 yuv420p yuv422p; do > >> for ofmt in argb rgba abgr bgra; do > >> ./ffmpeg -f lavfi -i testsrc2=d=10 -vf format=$ifmt,format=$ofmt > >> -f null - > >> done > >> done > > > > This will unfortunately involve more converts (testsrc fmt -> ifmt) so it > > won't really give you much hint. You probably want to test with sth like > > av_gettime() before and after the > > ff_##ifmt##_to_##ofmt##_neon_##precision() calls in > > libswscale/aarch64/swscale_unscaled.c > > The START_TIMER and STOP_TIMER() macros are made specifically for this > scenario. > The function is at frame level, so it's likely not called enough times. -- 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] [PATCH 2/4] Revert "Merge commit 'a2bb771a3cded8a05137c0effb34f61a2bc78e22'"
This reverts commit e8ebcb0034c5d4e5df8ff407a5c28d8c53823236, reversing
changes made to 3bff005be8ea213c23160ee0ac286634a80a10e1.
---
configure | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/configure b/configure
index 40821e1..6562e70 100755
--- a/configure
+++ b/configure
@@ -3047,7 +3047,10 @@ cpu="generic"
intrinsics="none"
# configurable options
+enable $PROGRAM_LIST
enable $DOCUMENT_LIST
+enable $EXAMPLE_LIST
+enable $(filter_out avresample $LIBRARY_LIST)
enable stripping
enable asm
@@ -3235,7 +3238,6 @@ for opt do
;;
--disable-everything)
map 'eval disable \${$(toupper ${v%s})_LIST}' $COMPONENT_LIST
-enable_deep_force $EXAMPLE_LIST $(filter_out avresample
$LIBRARY_LIST) $PROGRAM_LIST
;;
--disable-all)
map 'eval disable \${$(toupper ${v%s})_LIST}' $COMPONENT_LIST
@@ -3262,11 +3264,10 @@ for opt do
;;
--enable-?*|--disable-?*)
eval $(echo "$opt" | sed 's/--/action=/;s/-/ option=/;s/-/_/g')
+test $action = enable && action="request"
if is_in $option $COMPONENT_LIST; then
-test $action = enable && action="enable_deep_force"
eval $action \$$(toupper ${option%s})_LIST
elif is_in $option $CMDLINE_SELECT; then
-test $action = enable && action="request"
$action $option
else
die_unknown $opt
@@ -3303,10 +3304,6 @@ done
disabled logging && logfile=/dev/null
-# Enable the default components if not disabled explicitly
-
-enable_weak $EXAMPLE_LIST $(filter_out avresample $LIBRARY_LIST) $PROGRAM_LIST
-
# Disable all the library-specific components if the library itself
# is disabled, see AVCODEC_LIST and following _LIST variables.
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/4] Revert recent configure changed
The recent merges broke dependency handling This patchset reverts the changes See: 0217 23:15 Hendrik Leppkes Re: [FFmpeg-devel] [PATCH 1/3] configure: Use set_all to force the dependency refresh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] Revert "Revert "configure: Revert recent changes to disable-everything""
This reverts commit f97ee815cf25580cbb9d6bed304d9c22895f7074.
---
configure | 66 +++--
1 file changed, 12 insertions(+), 54 deletions(-)
diff --git a/configure b/configure
index 8e673b6..287896f 100755
--- a/configure
+++ b/configure
@@ -579,15 +579,8 @@ enable(){
set_all yes $*
}
-check_requested() {
-for var; do
-eval test "x\$${var#!}_requested" = "xyes" && die "${var#*_}
${var/_*} cannot be enabled"
-done
-}
-
disable(){
set_all no $*
-check_requested $*
}
enable_weak(){
@@ -638,28 +631,6 @@ enable_deep_weak(){
done
}
-do_enable_deep_force(){
-for var; do
-enabled $var && continue
-eval sel="\$${var}_select\ \$${var}_suggest\ \$${var}_select_any"
-pushvar var
-enable_deep_force $sel
-popvar var
-done
-}
-
-enable_deep_force(){
-do_enable_deep_force $*
-enable $*
-}
-
-request(){
-for var; do
-enable ${var}_requested
-done
-enable_deep_force $*
-}
-
enabled(){
test "${1#!}" = "$1" && op='=' || op=!=
eval test "x\$${1#!}" $op "xyes"
@@ -719,7 +690,7 @@ do_check_deps(){
append allopts $cfg
eval dep_all="\$${cfg}_deps"
-eval dep_any="\$${cfg}_deps_any\ \$${cfg}_select_any"
+eval dep_any="\$${cfg}_deps_any"
eval dep_sel="\$${cfg}_select"
eval dep_sgs="\$${cfg}_suggest"
eval dep_ifa="\$${cfg}_if"
@@ -2856,7 +2827,7 @@ tls_schannel_protocol_deps="schannel"
tls_schannel_protocol_select="tcp_protocol"
tls_securetransport_protocol_deps="securetransport"
tls_securetransport_protocol_select="tcp_protocol"
-tls_protocol_select_any="tls_schannel_protocol tls_securetransport_protocol
tls_gnutls_protocol tls_openssl_protocol"
+tls_protocol_deps_any="tls_schannel_protocol tls_securetransport_protocol
tls_gnutls_protocol tls_openssl_protocol"
udp_protocol_select="network"
udplite_protocol_select="network"
unix_protocol_deps="sys_un_h"
@@ -3167,6 +3138,12 @@ ALL_COMPONENTS="
$PROTOCOL_LIST
"
+for n in $COMPONENT_LIST; do
+v=$(toupper ${n%s})_LIST
+eval enable \$$v
+eval ${n}_if_any="\$$v"
+done
+
enable $ARCH_EXT_LIST
die_unknown(){
@@ -3233,10 +3210,10 @@ for opt do
disable $PROGRAM_LIST
;;
--disable-everything)
-map 'eval disable \${$(toupper ${v%s})_LIST}' $COMPONENT_LIST
+map 'eval unset \${$(toupper ${v%s})_LIST}' $COMPONENT_LIST
;;
--disable-all)
-map 'eval disable \${$(toupper ${v%s})_LIST}' $COMPONENT_LIST
+map 'eval unset \${$(toupper ${v%s})_LIST}' $COMPONENT_LIST
disable $LIBRARY_LIST $PROGRAM_LIST doc
enable avutil
;;
@@ -3253,7 +3230,6 @@ for opt do
is_in "${thing}s" $COMPONENT_LIST || die_unknown "$opt"
eval list=\$$(toupper $thing)_LIST
name=$(echo "${optval}" | sed "s/,/_${thing}|/g")_${thing}
-test $action = enable && action="request"
list=$(filter "$name" $list)
[ "$list" = "" ] && warn "Option $opt did not match anything"
$action $list
@@ -3261,6 +3237,7 @@ for opt do
--enable-?*|--disable-?*)
eval $(echo "$opt" | sed 's/--/action=/;s/-/ option=/;s/-/_/g')
if is_in $option $COMPONENT_LIST; then
+test $action = disable && action=unset
eval $action \$$(toupper ${option%s})_LIST
elif is_in $option $CMDLINE_SELECT; then
$action $option
@@ -3303,7 +3280,7 @@ disabled logging && logfile=/dev/null
# is disabled, see AVCODEC_LIST and following _LIST variables.
disable_components(){
-disabled ${1} && disable_weak $(
+disabled ${1} && disable $(
eval components="\$$(toupper ${1})_COMPONENTS"
map 'eval echo \${$(toupper ${v%s})_LIST}' $components
)
@@ -3312,25 +3289,6 @@ disable_components(){
map 'disable_components $v' $LIBRARY_LIST
echo "# $0 $FFMPEG_CONFIGURATION" > $logfile
-
-# Mark components that had not been enabled/disabled explicitly
-# as enabled
-
-for n in $COMPONENT_LIST; do
-v=$(toupper ${n%s})_LIST
-eval enable_weak \$$v
-eval ${n}_if_any="\$$v"
-done
-
-# Make so that disabled libraries are enabled if a component
-# of them is requested
-
-for n in $LIBRARY_LIST; do
-v=$(toupper ${n})_COMPONENTS
-eval ${n}_if_any="\$$v"
-done
-
-echo "# $0 $FFMPEG_CONFIGURATION" > $logfile
set >> $logfile
test -n "$valgrind" && toolchain="valgrind-memcheck"
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] Revert "configure: Don't enable examples when --disable-everything is used"
reverted as the problematic commit will be reverted too
This reverts commit 02dfa64c088c87367c298a3f648454204656734f.
---
configure |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index fb81a19..40821e1 100755
--- a/configure
+++ b/configure
@@ -3235,7 +3235,7 @@ for opt do
;;
--disable-everything)
map 'eval disable \${$(toupper ${v%s})_LIST}' $COMPONENT_LIST
-enable_deep_force $(filter_out avresample $LIBRARY_LIST)
$PROGRAM_LIST
+enable_deep_force $EXAMPLE_LIST $(filter_out avresample
$LIBRARY_LIST) $PROGRAM_LIST
;;
--disable-all)
map 'eval disable \${$(toupper ${v%s})_LIST}' $COMPONENT_LIST
@@ -3305,7 +3305,7 @@ disabled logging && logfile=/dev/null
# Enable the default components if not disabled explicitly
-enable_weak $(filter_out avresample $LIBRARY_LIST) $PROGRAM_LIST
+enable_weak $EXAMPLE_LIST $(filter_out avresample $LIBRARY_LIST) $PROGRAM_LIST
# Disable all the library-specific components if the library itself
# is disabled, see AVCODEC_LIST and following _LIST variables.
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] Revert "Merge commit '21c750f240b9d0c41a258d1adee2d9f75ff378b6'"
This reverts commit 470bfab470893d45328f4e6e25d60b89c9af1abe, reversing
changes made to f97ee815cf25580cbb9d6bed304d9c22895f7074.
---
configure | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/configure b/configure
index 6562e70..8e673b6 100755
--- a/configure
+++ b/configure
@@ -581,7 +581,7 @@ enable(){
check_requested() {
for var; do
-eval test "x\$${var#!}_requested" = "xyes" && die "${var%%_*} cannot
be enabled"
+eval test "x\$${var#!}_requested" = "xyes" && die "${var#*_}
${var/_*} cannot be enabled"
done
}
@@ -641,7 +641,7 @@ enable_deep_weak(){
do_enable_deep_force(){
for var; do
enabled $var && continue
-eval sel="\$${var}_deps\ \$${var}_deps_any\ \$${var}_select\
\$${var}_suggest\ \$${var}_select_any"
+eval sel="\$${var}_select\ \$${var}_suggest\ \$${var}_select_any"
pushvar var
enable_deep_force $sel
popvar var
@@ -650,18 +650,14 @@ do_enable_deep_force(){
enable_deep_force(){
do_enable_deep_force $*
-for var; do
-is_in $var $ALL_COMPONENTS $COMPONENT_LIST $LIBRARY_LIST && enable $var
-done
+enable $*
}
request(){
-disable $* # force the refresh of the dependencies
for var; do
enable ${var}_requested
done
enable_deep_force $*
-enable $*
}
enabled(){
@@ -3264,7 +3260,6 @@ for opt do
;;
--enable-?*|--disable-?*)
eval $(echo "$opt" | sed 's/--/action=/;s/-/ option=/;s/-/_/g')
-test $action = enable && action="request"
if is_in $option $COMPONENT_LIST; then
eval $action \$$(toupper ${option%s})_LIST
elif is_in $option $CMDLINE_SELECT; then
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/4] Revert recent configure changed
On Thu, Feb 18, 2016 at 3:35 PM, Michael Niedermayer wrote: > The recent merges broke dependency handling > This patchset reverts the changes > > See: 0217 23:15 Hendrik Leppkes Re: [FFmpeg-devel] [PATCH 1/3] configure: Use > set_all to force the dependency refresh > > I would prefer if you squash them into one. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/4] Revert recent configure changed
On Thu, Feb 18, 2016 at 03:49:24PM +0100, Hendrik Leppkes wrote: > On Thu, Feb 18, 2016 at 3:35 PM, Michael Niedermayer > wrote: > > The recent merges broke dependency handling > > This patchset reverts the changes > > > > See: 0217 23:15 Hendrik Leppkes Re: [FFmpeg-devel] [PATCH 1/3] configure: > > Use set_all to force the dependency refresh > > > > > > I would prefer if you squash them into one. ok, i will do that ill wait a bit more so others can comment too before applying though [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/4] Revert recent configure changed
On Thu, Feb 18, 2016 at 04:10:22PM +0100, Michael Niedermayer wrote: > On Thu, Feb 18, 2016 at 03:49:24PM +0100, Hendrik Leppkes wrote: > > On Thu, Feb 18, 2016 at 3:35 PM, Michael Niedermayer > > wrote: > > > The recent merges broke dependency handling > > > This patchset reverts the changes > > > > > > See: 0217 23:15 Hendrik Leppkes Re: [FFmpeg-devel] [PATCH 1/3] configure: > > > Use set_all to force the dependency refresh > > > > > > > > > > I would prefer if you squash them into one. > > ok, i will do that > ill wait a bit more so others can comment too before applying though that is unless people want me to apply this immedeatly ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/4] Revert recent configure changed
On Thu, Feb 18, 2016 at 04:12:25PM +0100, Michael Niedermayer wrote: > On Thu, Feb 18, 2016 at 04:10:22PM +0100, Michael Niedermayer wrote: > > On Thu, Feb 18, 2016 at 03:49:24PM +0100, Hendrik Leppkes wrote: > > > On Thu, Feb 18, 2016 at 3:35 PM, Michael Niedermayer > > > wrote: > > > > The recent merges broke dependency handling > > > > This patchset reverts the changes > > > > > > > > See: 0217 23:15 Hendrik Leppkes Re: [FFmpeg-devel] [PATCH 1/3] > > > > configure: Use set_all to force the dependency refresh > > > > > > > > > > > > > > I would prefer if you squash them into one. > > > > ok, i will do that > > > ill wait a bit more so others can comment too before applying though > > that is unless people want me to apply this immedeatly ? immedeat apply suggested by ronald applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/options_table: mark use_wallclock_as_timestamps as boolean
On Thu, Feb 18, 2016 at 02:47:10PM +0100, Moritz Barsnick wrote: > It is only used in a boolean context. Also clarify its documentation. > > Signed-off-by: Moritz Barsnick > --- > doc/formats.texi| 2 +- > libavformat/options_table.h | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) applied thx [..] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] pngdsp add bytes padding
On Thu, Feb 18, 2016 at 12:42:59PM +0100, Michael Niedermayer wrote:
> On Thu, Feb 18, 2016 at 11:36:18AM +0100, Clément Bœsch wrote:
> > Hi,
> >
> > While working on PNG DSP, I realized the filter up was doing extra
> > overflow checks on the bytes non multiple of the long word size. This
> > logic is present in both C and x86 ASM. Here is the current C code for
> > reference:
> >
> > -- 8<
> >
> > // 0x7f7f7f7f or 0x7f7f7f7f7f7f7f7f or whatever, depending on the cpu's
> > native arithmetic size
> > #define pb_7f (~0UL / 255 * 0x7f)
> > #define pb_80 (~0UL / 255 * 0x80)
> >
> > static void add_bytes_l2_c(uint8_t *dst, uint8_t *src1, uint8_t *src2, int
> > w)
> > {
> > long i;
> > for (i = 0; i <= w - (int) sizeof(long); i += sizeof(long)) {
> > long a = *(long *)(src1 + i);
> > long b = *(long *)(src2 + i);
> > *(long *)(dst + i) = ((a & pb_7f) + (b & pb_7f)) ^ ((a ^ b) &
> > pb_80);
> > }
> > for (; i < w; i++)
> > dst[i] = src1[i] + src2[i];
> > }
> >
> > -- 8<
> >
> > The thing is, the buffers seem to be 0 padded to 16 (see
> > av_fast_padded_malloc() calls). I'm assuming there are cases where it's
> > not?
>
> isnt dst the AVFrame in one call ?
> so that this would write over width if it wrote beyond ?
>
but isn't frame->data[N] always padded as well...?
--
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] GSoC 2016 own ideas
Good day, I'm a master student and long term FFmpeg-user. I want to participate in the GSoC 2016 for FFmpeg. The reason, I write this, is that I want to suggest some own ideas. It could be, that some of the mentioned things are wrong (because FFmpeg could do this already or it it much more difficult than I think). Please correct me if so. I'm excited to hear, what do you think about this ideas, if you think, they are suitable for GSoC and if you maybe are willing to mentor some of this. 1. *disc support What current FFmpeg could do: - Bluray support through protocol support with prefix "bluray:" and libbluray. The implemention is some kind of limited. There is missing chapter support. The "main movie" selection is simply the longest one. Menus are not supported. Afaik no metadata are transfered. - CD support through libavdevice and libcdio. Last time I tried it, it only works under some strange circumstances (I have to set the parameter "-ss 0"). I don't know if it is fixed right now. It recognizes a CD as one track with multiple chapters. Afaik CD-Text is not supported. - No DVD support at all. I saw, that Stefano ones write a patch [1] (protocol and libdvdnav based), which seems to work in principal, but was probably not ready to merge. Goal: - Implement an uniform solution for *disc support, that also support metadata. - Maybe (?): Add some kind of Menu Support, FFmpeg is not made for this atm, I think. Not sure how difficult it is. - Maybe (?): Try to change something on libdvdnav/libdvdread to make it more consistent (to libbluray ?). Similar idea from Flameeyes [2]. Qualification task: - Maybe (?): Add chapter support for the current Bluray implementation (get the chapters out of libbluray is fairly simple, I'm not sure how difficult it is to get them into the stream). Comments: - I would try to orientate on VLC, mplayer and mpv implementation. - libdvdread/nav seem to do much less than libbluray, so the main work would be the dvd support, I guess. - All kinds of discs normally contains more than one track. My idea for a solution would be, that ffmpeg recognize the disc as multiinput and choose the mainmovie as default. 2. treelike metadata What current FFmpeg could do: - Metadata is always an AVDictionary (string based afaik). - Some metadata systems like the one of Matroska use a treelike structure (xml in mkv), so you can specify the charatername given an actor or define more than on actor, see example at the end of the mail. Goal: Rewrite the FFmpeg metadata system, to support extended tags. In Detail: - Support for more than one value per key. - Support for more key/value pairs as value. Qualification task: No idea. Comments: Not sure, if this task is GSoC suitable. 3. Vector graphic support What current FFmpeg could do: - No support at all, afaik. Goal: - Extend FFmpeg to support vector graphics (without converting to pixel graphics). - Write an SVG decoder for this. - Write an vector to pixel image converter/filter. Qualification task: No idea. Comments: I think, this could be a very hard task. Could you comment, whether you find this suitable? I have no experience with SVG. Maybe it could be based on cairo. 4. Usable analyse filter output for programs Not sure, if this is a real problem at all. Not sure if this is suitable for GSoC at all. What current FFmpeg could do: - Receive (multiple) streams in filter and write back other streams. - The problem I see here, is that the output of analyse filters is hard to process (needs some kind of subprocess and extended usage of grep/sed). Examples: All filters that analyse some thing and then "print" it to stdout, like cropdetect, volumedetect, blackframe, Some (not implemented filter) like tonality, bpm detection, waveform analysis, ... Goal: - Rewrite the filtersystem, so that some function "receive_output" exists, that could be called from the external API or another filter to get non multimedia data as the filter output, like an String for tonality, or an index array for the wavform, etc. Comments: - Has the side effect, that a following filter in the chain could use the output to do some other stuff. - Not sure, how hard (and wanted) this is. Other ideas, but imho not suitable for GSoC: - Jack output support (too simple for GSoC) - Python bindings - merge of ffmpeg and ffplay (call ffmpeg without output reacts like ffplay). Maybe this idea is fairly naive. thank you, Gerion [1] https://gitorious.org/ffmpeg/sastes-ffmpeg/commit/716c1f7b2ad02a906ad1e47182492554b668f3dc?p=ffmpeg:sastes-ffmpeg.git;a=blob;f=libavformat/dvdproto.c;h=72ed431c6a47c87e30e4876587c6bb97215517cf;hb=4ed59d83a6e9fb45c3134bb67267e9b05927125c [2] https://blog.flameeyes.eu/2013/02/it-s-that-time-of-the-year-again example tags from matroska: ... ACTOR Matthew McConaughey und 1 CHARACTER Jake Tyler Brigance und 1 ACT
Re: [FFmpeg-devel] GSoC 2016 own ideas
Dana 18. 2. 2016. 18:27 osoba "Gerion Entrup" napisala je: > > Good day, > > I'm a master student and long term FFmpeg-user. I want to participate in the GSoC 2016 for FFmpeg. The reason, I write this, is that I want to suggest some own ideas. It could be, that some of the mentioned things are wrong (because FFmpeg could do this already or it it much more difficult than I think). Please correct me if so. > I'm excited to hear, what do you think about this ideas, if you think, they are suitable for GSoC and if you maybe are willing to mentor some of this. > > 1. *disc support > > What current FFmpeg could do: > - Bluray support through protocol support with prefix "bluray:" and libbluray. The implemention is some kind of limited. There is missing chapter support. The "main movie" selection is simply the longest one. Menus are not supported. Afaik no metadata are transfered. > - CD support through libavdevice and libcdio. Last time I tried it, it only works under some strange circumstances (I have to set the parameter "-ss 0"). I don't know if it is fixed right now. It recognizes a CD as one track with multiple chapters. Afaik CD-Text is not supported. > - No DVD support at all. I saw, that Stefano ones write a patch [1] (protocol and libdvdnav based), which seems to work in principal, but was probably not ready to merge. > > Goal: > - Implement an uniform solution for *disc support, that also support metadata. > - Maybe (?): Add some kind of Menu Support, FFmpeg is not made for this atm, I think. Not sure how difficult it is. > - Maybe (?): Try to change something on libdvdnav/libdvdread to make it more consistent (to libbluray ?). Similar idea from Flameeyes [2]. > > Qualification task: > - Maybe (?): Add chapter support for the current Bluray implementation (get the chapters out of libbluray is fairly simple, I'm not sure how difficult it is to get them into the stream). > > Comments: > - I would try to orientate on VLC, mplayer and mpv implementation. > - libdvdread/nav seem to do much less than libbluray, so the main work would be the dvd support, I guess. > - All kinds of discs normally contains more than one track. My idea for a solution would be, that ffmpeg recognize the disc as multiinput and choose the mainmovie as default. > This is out of scope for project. And who will use it when everyone have own solution. > > 2. treelike metadata > > What current FFmpeg could do: > - Metadata is always an AVDictionary (string based afaik). > - Some metadata systems like the one of Matroska use a treelike structure (xml in mkv), so you can specify the charatername given an actor or define more than on actor, see example at the end of the mail. > > Goal: > Rewrite the FFmpeg metadata system, to support extended tags. In Detail: > - Support for more than one value per key. > - Support for more key/value pairs as value. > > Qualification task: > No idea. > > Comments: > Not sure, if this task is GSoC suitable. Trivial and out of scope. > > > 3. Vector graphic support > > What current FFmpeg could do: > - No support at all, afaik. > > Goal: > - Extend FFmpeg to support vector graphics (without converting to pixel graphics). > - Write an SVG decoder for this. > - Write an vector to pixel image converter/filter. > > Qualification task: > No idea. > > Comments: > I think, this could be a very hard task. Could you comment, whether you find this suitable? I have no experience with SVG. Maybe it could be based on cairo. Out of scope. > > > 4. Usable analyse filter output for programs > Not sure, if this is a real problem at all. Not sure if this is suitable for GSoC at all. > > What current FFmpeg could do: > - Receive (multiple) streams in filter and write back other streams. > - The problem I see here, is that the output of analyse filters is hard to process (needs some kind of subprocess and extended usage of grep/sed). > Examples: All filters that analyse some thing and then "print" it to stdout, like cropdetect, volumedetect, blackframe, Some (not implemented filter) like tonality, bpm detection, waveform analysis, ... > > Goal: > - Rewrite the filtersystem, so that some function "receive_output" exists, that could be called from the external API or another filter to get non multimedia data as the filter output, like an String for tonality, or an index array for the wavform, etc. > > Comments: > - Has the side effect, that a following filter in the chain could use the output to do some other stuff. > - Not sure, how hard (and wanted) this is. Already available via metadata. > > > > Other ideas, but imho not suitable for GSoC: > - Jack output support (too simple for GSoC) > - Python bindings > - merge of ffmpeg and ffplay (call ffmpeg without output reacts like ffplay). Maybe this idea is fairly naive. > > thank you, > Gerion > > [1] https://gitorious.org/ffmpeg/sastes-ffmpeg/commit/716c1f7b2ad02a906ad1e47182492554b668f3dc?p=ffmpeg:sastes-ffmpeg.git;a=blob;f=libavformat/dvdproto.c;h=72ed431c6a47c8
Re: [FFmpeg-devel] GSoC 2016 own ideas
On Thu, 18 Feb 2016 18:27:45 +0100 Gerion Entrup wrote: > Good day, > > I'm a master student and long term FFmpeg-user. I want to participate in the > GSoC 2016 for FFmpeg. The reason, I write this, is that I want to suggest > some own ideas. It could be, that some of the mentioned things are wrong > (because FFmpeg could do this already or it it much more difficult than I > think). Please correct me if so. > I'm excited to hear, what do you think about this ideas, if you think, they > are suitable for GSoC and if you maybe are willing to mentor some of this. > > 1. *disc support > > What current FFmpeg could do: > - Bluray support through protocol support with prefix "bluray:" and > libbluray. The implemention is some kind of limited. There is missing chapter > support. The "main movie" selection is simply the longest one. Menus are not > supported. Afaik no metadata are transfered. > - CD support through libavdevice and libcdio. Last time I tried it, it only > works under some strange circumstances (I have to set the parameter "-ss 0"). > I don't know if it is fixed right now. It recognizes a CD as one track with > multiple chapters. Afaik CD-Text is not supported. > - No DVD support at all. I saw, that Stefano ones write a patch [1] (protocol > and libdvdnav based), which seems to work in principal, but was probably not > ready to merge. > > Goal: > - Implement an uniform solution for *disc support, that also support metadata. > - Maybe (?): Add some kind of Menu Support, FFmpeg is not made for this atm, > I think. Not sure how difficult it is. > - Maybe (?): Try to change something on libdvdnav/libdvdread to make it more > consistent (to libbluray ?). Similar idea from Flameeyes [2]. Hm, I'm not sure if that's even possible in a reasonable way. Full DVD/Bluray support requires menus, which are hard to get right, and which would require non-trivial interactions between applications and libavformat. Improving support for merely transcoding a DVD to a file might be not so hard and potentially a good idea, though. > Qualification task: > - Maybe (?): Add chapter support for the current Bluray implementation (get > the chapters out of libbluray is fairly simple, I'm not sure how difficult it > is to get them into the stream). This sounds like a hard design issue: currently bluray is implemented as avio protocol, which can not pass things like chapters to the higher level (demuxer). This would require coming up with a mechanism for transferring this metadata, which sounds hard. Just reading the bluray chapters should indeed be simple. > Comments: > - I would try to orientate on VLC, mplayer and mpv implementation. > - libdvdread/nav seem to do much less than libbluray, so the main work would > be the dvd support, I guess. > - All kinds of discs normally contains more than one track. My idea for a > solution would be, that ffmpeg recognize the disc as multiinput and choose > the mainmovie as default. > > > 2. treelike metadata > > What current FFmpeg could do: > - Metadata is always an AVDictionary (string based afaik). > - Some metadata systems like the one of Matroska use a treelike structure > (xml in mkv), so you can specify the charatername given an actor or define > more than on actor, see example at the end of the mail. > > Goal: > Rewrite the FFmpeg metadata system, to support extended tags. In Detail: > - Support for more than one value per key. > - Support for more key/value pairs as value. > > Qualification task: > No idea. > > Comments: > Not sure, if this task is GSoC suitable. > Includes API design, which is better avoided for a gsoc. I'm also not sure if we really need such metadata, but I guess this is debatable. > > 3. Vector graphic support > > What current FFmpeg could do: > - No support at all, afaik. > > Goal: > - Extend FFmpeg to support vector graphics (without converting to pixel > graphics). > - Write an SVG decoder for this. > - Write an vector to pixel image converter/filter. > That sounds not only very hard, but also very out of scope for ffmpeg. The problem with SVG is that nothing seems to support it correctly and entirely, so it's a good way to get hurt. > Qualification task: > No idea. > > Comments: > I think, this could be a very hard task. Could you comment, whether you find > this suitable? I have no experience with SVG. Maybe it could be based on > cairo. > > > 4. Usable analyse filter output for programs > Not sure, if this is a real problem at all. Not sure if this is suitable for > GSoC at all. > > What current FFmpeg could do: > - Receive (multiple) streams in filter and write back other streams. > - The problem I see here, is that the output of analyse filters is hard to > process (needs some kind of subprocess and extended usage of grep/sed). > Examples: All filters that analyse some thing and then "print" it to > stdout, like cropdetect, volumedetect, blackframe, Some (not implemented > filter) like
Re: [FFmpeg-devel] GSoC 2016 own ideas
On Donnerstag, 18. Februar 2016 18:53:45 CET Paul B Mahol wrote: > Dana 18. 2. 2016. 18:27 osoba "Gerion Entrup" > napisala je: > > > > Good day, > > > > I'm a master student and long term FFmpeg-user. I want to participate in > the GSoC 2016 for FFmpeg. The reason, I write this, is that I want to > suggest some own ideas. It could be, that some of the mentioned things are > wrong (because FFmpeg could do this already or it it much more difficult > than I think). Please correct me if so. > > I'm excited to hear, what do you think about this ideas, if you think, > they are suitable for GSoC and if you maybe are willing to mentor some of > this. > > > > 1. *disc support > > > > What current FFmpeg could do: > > - Bluray support through protocol support with prefix "bluray:" and > libbluray. The implemention is some kind of limited. There is missing > chapter support. The "main movie" selection is simply the longest one. > Menus are not supported. Afaik no metadata are transfered. > > - CD support through libavdevice and libcdio. Last time I tried it, it > only works under some strange circumstances (I have to set the parameter > "-ss 0"). I don't know if it is fixed right now. It recognizes a CD as one > track with multiple chapters. Afaik CD-Text is not supported. > > - No DVD support at all. I saw, that Stefano ones write a patch [1] > (protocol and libdvdnav based), which seems to work in principal, but was > probably not ready to merge. > > > > Goal: > > - Implement an uniform solution for *disc support, that also support > metadata. > > - Maybe (?): Add some kind of Menu Support, FFmpeg is not made for this > atm, I think. Not sure how difficult it is. > > - Maybe (?): Try to change something on libdvdnav/libdvdread to make it > more consistent (to libbluray ?). Similar idea from Flameeyes [2]. > > > > Qualification task: > > - Maybe (?): Add chapter support for the current Bluray implementation > (get the chapters out of libbluray is fairly simple, I'm not sure how > difficult it is to get them into the stream). > > > > Comments: > > - I would try to orientate on VLC, mplayer and mpv implementation. > > - libdvdread/nav seem to do much less than libbluray, so the main work > would be the dvd support, I guess. > > - All kinds of discs normally contains more than one track. My idea for a > solution would be, that ffmpeg recognize the disc as multiinput and choose > the mainmovie as default. > > > > This is out of scope for project. And who will use it when everyone have > own solution. I have the impression, that DVD support is not trivial. Kodi e.g. fails on DVDs, that VLC can play. As an application programmer with already existent FFmpeg support I would be happy to see a simple solution. Also some new programs could arise, that do not have an own solution. Also some devs seem to want DVD support [1]. > > > > > 2. treelike metadata > > > > What current FFmpeg could do: > > - Metadata is always an AVDictionary (string based afaik). > > - Some metadata systems like the one of Matroska use a treelike structure > (xml in mkv), so you can specify the charatername given an actor or define > more than on actor, see example at the end of the mail. > > > > Goal: > > Rewrite the FFmpeg metadata system, to support extended tags. In Detail: > > - Support for more than one value per key. > > - Support for more key/value pairs as value. > > > > Qualification task: > > No idea. > > > > Comments: > > Not sure, if this task is GSoC suitable. > > Trivial and out of scope. > > > > > > > 3. Vector graphic support > > > > What current FFmpeg could do: > > - No support at all, afaik. > > > > Goal: > > - Extend FFmpeg to support vector graphics (without converting to pixel > graphics). > > - Write an SVG decoder for this. > > - Write an vector to pixel image converter/filter. > > > > Qualification task: > > No idea. > > > > Comments: > > I think, this could be a very hard task. Could you comment, whether you > find this suitable? I have no experience with SVG. Maybe it could be based > on cairo. > > Out of scope. > > > > > > > 4. Usable analyse filter output for programs > > Not sure, if this is a real problem at all. Not sure if this is suitable > for GSoC at all. > > > > What current FFmpeg could do: > > - Receive (multiple) streams in filter and write back other streams. > > - The problem I see here, is that the output of analyse filters is hard > to process (needs some kind of subprocess and extended usage of grep/sed). > > Examples: All filters that analyse some thing and then "print" it to > stdout, like cropdetect, volumedetect, blackframe, Some (not > implemented filter) like tonality, bpm detection, waveform analysis, ... > > > > Goal: > > - Rewrite the filtersystem, so that some function "receive_output" > exists, that could be called from the external API or another filter to get > non multimedia data as the filter output, like an String for tonality, or > an index array for the wavform, etc.
Re: [FFmpeg-devel] GSoC 2016 own ideas
On Donnerstag, 18. Februar 2016 20:10:47 CET wm4 wrote: > On Thu, 18 Feb 2016 18:27:45 +0100 > Gerion Entrup wrote: > > > Good day, > > > > I'm a master student and long term FFmpeg-user. I want to participate in the GSoC 2016 for FFmpeg. The reason, I write this, is that I want to suggest some own ideas. It could be, that some of the mentioned things are wrong (because FFmpeg could do this already or it it much more difficult than I think). Please correct me if so. > > I'm excited to hear, what do you think about this ideas, if you think, they are suitable for GSoC and if you maybe are willing to mentor some of this. > > > > 1. *disc support > > > > What current FFmpeg could do: > > - Bluray support through protocol support with prefix "bluray:" and libbluray. The implemention is some kind of limited. There is missing chapter support. The "main movie" selection is simply the longest one. Menus are not supported. Afaik no metadata are transfered. > > - CD support through libavdevice and libcdio. Last time I tried it, it only works under some strange circumstances (I have to set the parameter "-ss 0"). I don't know if it is fixed right now. It recognizes a CD as one track with multiple chapters. Afaik CD-Text is not supported. > > - No DVD support at all. I saw, that Stefano ones write a patch [1] (protocol and libdvdnav based), which seems to work in principal, but was probably not ready to merge. > > > > Goal: > > - Implement an uniform solution for *disc support, that also support metadata. > > - Maybe (?): Add some kind of Menu Support, FFmpeg is not made for this atm, I think. Not sure how difficult it is. > > - Maybe (?): Try to change something on libdvdnav/libdvdread to make it more consistent (to libbluray ?). Similar idea from Flameeyes [2]. > > Hm, I'm not sure if that's even possible in a reasonable way. Full > DVD/Bluray support requires menus, which are hard to get right, and > which would require non-trivial interactions between applications and > libavformat. > > Improving support for merely transcoding a DVD to a file might be not > so hard and potentially a good idea, though. > > > Qualification task: > > - Maybe (?): Add chapter support for the current Bluray implementation (get the chapters out of libbluray is fairly simple, I'm not sure how difficult it is to get them into the stream). > > This sounds like a hard design issue: currently bluray is implemented > as avio protocol, which can not pass things like chapters to the higher > level (demuxer). This would require coming up with a mechanism for > transferring this metadata, which sounds hard. Just reading the bluray > chapters should indeed be simple. Just reading the chapters and print them is too simple to be a qualification task. > > > Comments: > > - I would try to orientate on VLC, mplayer and mpv implementation. > > - libdvdread/nav seem to do much less than libbluray, so the main work would be the dvd support, I guess. > > - All kinds of discs normally contains more than one track. My idea for a solution would be, that ffmpeg recognize the disc as multiinput and choose the mainmovie as default. > > > > > > 2. treelike metadata > > > > What current FFmpeg could do: > > - Metadata is always an AVDictionary (string based afaik). > > - Some metadata systems like the one of Matroska use a treelike structure (xml in mkv), so you can specify the charatername given an actor or define more than on actor, see example at the end of the mail. > > > > Goal: > > Rewrite the FFmpeg metadata system, to support extended tags. In Detail: > > - Support for more than one value per key. > > - Support for more key/value pairs as value. > > > > Qualification task: > > No idea. > > > > Comments: > > Not sure, if this task is GSoC suitable. > > > > Includes API design, which is better avoided for a gsoc. I'm also not > sure if we really need such metadata, but I guess this is debatable. > > > > > 3. Vector graphic support > > > > What current FFmpeg could do: > > - No support at all, afaik. > > > > Goal: > > - Extend FFmpeg to support vector graphics (without converting to pixel graphics). > > - Write an SVG decoder for this. > > - Write an vector to pixel image converter/filter. > > > > That sounds not only very hard, but also very out of scope for ffmpeg. > The problem with SVG is that nothing seems to support it correctly :) > and > entirely, so it's a good way to get hurt. Ok, thank you for the evaluation. > > > Qualification task: > > No idea. > > > > Comments: > > I think, this could be a very hard task. Could you comment, whether you find this suitable? I have no experience with SVG. Maybe it could be based on cairo. > > > > > > 4. Usable analyse filter output for programs > > Not sure, if this is a real problem at all. Not sure if this is suitable for GSoC at all. > > > > What current FFmpeg could do: > > - Receive (multiple) streams in filter and write back other streams. > > - The
Re: [FFmpeg-devel] GSoC 2016 own ideas
On 2/18/16, Gerion Entrup wrote:
> On Donnerstag, 18. Februar 2016 18:53:45 CET Paul B Mahol wrote:
>> Dana 18. 2. 2016. 18:27 osoba "Gerion Entrup"
>>
>> napisala je:
>> >
>> > Good day,
>> >
>> > I'm a master student and long term FFmpeg-user. I want to participate in
>> the GSoC 2016 for FFmpeg. The reason, I write this, is that I want to
>> suggest some own ideas. It could be, that some of the mentioned things are
>> wrong (because FFmpeg could do this already or it it much more difficult
>> than I think). Please correct me if so.
>> > I'm excited to hear, what do you think about this ideas, if you think,
>> they are suitable for GSoC and if you maybe are willing to mentor some of
>> this.
>> >
>> > 1. *disc support
>> >
>> > What current FFmpeg could do:
>> > - Bluray support through protocol support with prefix "bluray:" and
>> libbluray. The implemention is some kind of limited. There is missing
>> chapter support. The "main movie" selection is simply the longest one.
>> Menus are not supported. Afaik no metadata are transfered.
>> > - CD support through libavdevice and libcdio. Last time I tried it, it
>> only works under some strange circumstances (I have to set the parameter
>> "-ss 0"). I don't know if it is fixed right now. It recognizes a CD as one
>> track with multiple chapters. Afaik CD-Text is not supported.
>> > - No DVD support at all. I saw, that Stefano ones write a patch [1]
>> (protocol and libdvdnav based), which seems to work in principal, but was
>> probably not ready to merge.
>> >
>> > Goal:
>> > - Implement an uniform solution for *disc support, that also support
>> metadata.
>> > - Maybe (?): Add some kind of Menu Support, FFmpeg is not made for this
>> atm, I think. Not sure how difficult it is.
>> > - Maybe (?): Try to change something on libdvdnav/libdvdread to make it
>> more consistent (to libbluray ?). Similar idea from Flameeyes [2].
>> >
>> > Qualification task:
>> > - Maybe (?): Add chapter support for the current Bluray implementation
>> (get the chapters out of libbluray is fairly simple, I'm not sure how
>> difficult it is to get them into the stream).
>> >
>> > Comments:
>> > - I would try to orientate on VLC, mplayer and mpv implementation.
>> > - libdvdread/nav seem to do much less than libbluray, so the main work
>> would be the dvd support, I guess.
>> > - All kinds of discs normally contains more than one track. My idea for
>> > a
>> solution would be, that ffmpeg recognize the disc as multiinput and choose
>> the mainmovie as default.
>> >
>>
>> This is out of scope for project. And who will use it when everyone have
>> own solution.
> I have the impression, that DVD support is not trivial. Kodi e.g. fails on
> DVDs, that VLC can play. As an application programmer with already existent
> FFmpeg support I would be happy to see a simple solution.
>
> Also some new programs could arise, that do not have an own solution.
>
> Also some devs seem to want DVD support [1].
It could use dvdread/dvdnav library to just allow reading dvds, no
menus and other
stuf. Still not enough for GSoC task IMHO.
[...]
>> > 4. Usable analyse filter output for programs
>> > Not sure, if this is a real problem at all. Not sure if this is suitable
>> for GSoC at all.
>> >
>> > What current FFmpeg could do:
>> > - Receive (multiple) streams in filter and write back other streams.
>> > - The problem I see here, is that the output of analyse filters is hard
>> to process (needs some kind of subprocess and extended usage of grep/sed).
>> > Examples: All filters that analyse some thing and then "print" it to
>> stdout, like cropdetect, volumedetect, blackframe, Some (not
>> implemented filter) like tonality, bpm detection, waveform analysis, ...
>> >
>> > Goal:
>> > - Rewrite the filtersystem, so that some function "receive_output"
>> exists, that could be called from the external API or another filter to
>> get
>> non multimedia data as the filter output, like an String for tonality, or
>> an index array for the wavform, etc.
>> >
>> > Comments:
>> > - Has the side effect, that a following filter in the chain could use
>> > the
>> output to do some other stuff.
>> > - Not sure, how hard (and wanted) this is.
>>
>> Already available via metadata.
> Is this in a standardized way? E.g. volumedetect has:
> static av_cold void uninit(AVFilterContext *ctx)
> {
> print_stats(ctx);
> }
> And print_stats does a lot of av_log. I see no way to get the (integer and
> float) values out of the filter without av_log output parsing (and
> reconverting
> to int and float).
This is printed at end, but yes outputing this also as (graph?) metadata
should be nicer to the users, still not enough to be GSoC task.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GSoC 2016 own ideas
On 2/18/16, Gerion Entrup wrote: >> > - merge of ffmpeg and ffplay (call ffmpeg without output reacts like > ffplay). Maybe this idea is fairly naive. >> > >> >> That sounds hard, and maybe not really what we'd want anyway. (Updating >> ffplay with SDL2 or something sounds more realistic.) > A question for that. If I get it right, ffplay use SDL directly. It is > wanted > to "swap it out" to some kind of libavdevice and then use this device out of > ffplay? There is already SDL(1) output in libavdevice. But libavdevice is just bad libavformat ripof API wise. There is no libavdevice API. And it is shame. I had idea to improve it but seems nobody likes such idea. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GSoC 2016 own ideas
Le decadi 30 pluviôse, an CCXXIV, Gerion Entrup a écrit : > A question for that. If I get it right, ffplay use SDL directly. It is wanted > to "swap it out" to some kind of libavdevice and then use this device out of > ffplay? You will probably get a different answer from each developer, but my advice is very much that I would like it if ffplay used libavdevice and if libavdevice was powerful enough for that. By the way, your e-mails are almost unreadable due to missing ">" on long quoted lines. See the archive for a non-doctored view: http://ffmpeg.org/pipermail/ffmpeg-devel/2016-February/189645.html Would you fix your mail client please? Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GSoC 2016 own ideas
On Thu, 18 Feb 2016 20:41:29 +0100 Gerion Entrup wrote: > On Donnerstag, 18. Februar 2016 20:10:47 CET wm4 wrote: > > On Thu, 18 Feb 2016 18:27:45 +0100 > > Gerion Entrup wrote: > > > > > Good day, > > > > > > I'm a master student and long term FFmpeg-user. I want to participate in > > > > the GSoC 2016 for FFmpeg. The reason, I write this, is that I want to suggest > some own ideas. It could be, that some of the mentioned things are wrong > (because FFmpeg could do this already or it it much more difficult than I > think). Please correct me if so. > > > I'm excited to hear, what do you think about this ideas, if you think, > they are suitable for GSoC and if you maybe are willing to mentor some of > this. > > > > > > 1. *disc support > > > > > > What current FFmpeg could do: > > > - Bluray support through protocol support with prefix "bluray:" and > libbluray. The implemention is some kind of limited. There is missing chapter > support. The "main movie" selection is simply the longest one. Menus are not > supported. Afaik no metadata are transfered. > > > - CD support through libavdevice and libcdio. Last time I tried it, it > only works under some strange circumstances (I have to set the parameter "-ss > 0"). I don't know if it is fixed right now. It recognizes a CD as one track > with multiple chapters. Afaik CD-Text is not supported. > > > - No DVD support at all. I saw, that Stefano ones write a patch [1] > (protocol and libdvdnav based), which seems to work in principal, but was > probably not ready to merge. > > > > > > Goal: > > > - Implement an uniform solution for *disc support, that also support > metadata. > > > - Maybe (?): Add some kind of Menu Support, FFmpeg is not made for this > atm, I think. Not sure how difficult it is. > > > - Maybe (?): Try to change something on libdvdnav/libdvdread to make it > more consistent (to libbluray ?). Similar idea from Flameeyes [2]. > > > > Hm, I'm not sure if that's even possible in a reasonable way. Full > > DVD/Bluray support requires menus, which are hard to get right, and > > which would require non-trivial interactions between applications and > > libavformat. > > > > Improving support for merely transcoding a DVD to a file might be not > > so hard and potentially a good idea, though. > > > > > Qualification task: > > > - Maybe (?): Add chapter support for the current Bluray implementation > (get the chapters out of libbluray is fairly simple, I'm not sure how > difficult > it is to get them into the stream). > > > > This sounds like a hard design issue: currently bluray is implemented > > as avio protocol, which can not pass things like chapters to the higher > > level (demuxer). This would require coming up with a mechanism for > > transferring this metadata, which sounds hard. Just reading the bluray > > chapters should indeed be simple. > Just reading the chapters and print them is too simple to be a qualification > task. Indeed. By the way, your mail client is making it very hard to distinguish quoted text from your replies. It doesn't add a ">" on the next line when line-breaking the quoted text. > > > > > > Comments: > > > - I would try to orientate on VLC, mplayer and mpv implementation. > > > - libdvdread/nav seem to do much less than libbluray, so the main work > would be the dvd support, I guess. > > > - All kinds of discs normally contains more than one track. My idea for a > > > > solution would be, that ffmpeg recognize the disc as multiinput and choose > the > mainmovie as default. > > > > > > > > > 2. treelike metadata > > > > > > What current FFmpeg could do: > > > - Metadata is always an AVDictionary (string based afaik). > > > - Some metadata systems like the one of Matroska use a treelike structure > > > > (xml in mkv), so you can specify the charatername given an actor or define > more > than on actor, see example at the end of the mail. > > > > > > Goal: > > > Rewrite the FFmpeg metadata system, to support extended tags. In Detail: > > > - Support for more than one value per key. > > > - Support for more key/value pairs as value. > > > > > > Qualification task: > > > No idea. > > > > > > Comments: > > > Not sure, if this task is GSoC suitable. > > > > > > > Includes API design, which is better avoided for a gsoc. I'm also not > > sure if we really need such metadata, but I guess this is debatable. > > > > > > > > 3. Vector graphic support > > > > > > What current FFmpeg could do: > > > - No support at all, afaik. > > > > > > Goal: > > > - Extend FFmpeg to support vector graphics (without converting to pixel > graphics). > > > - Write an SVG decoder for this. > > > - Write an vector to pixel image converter/filter. > > > > > > > That sounds not only very hard, but also very out of scope for ffmpeg. > > The problem with SVG is that nothing seems to support it correctly > :) It's the truth. Support for standard SVG features is
[FFmpeg-devel] [PATCH] avformat/avienc: Store pal8 palette
This can be made more efficient, but first and the main goal of this change is
to
store it at all
Signed-off-by: Michael Niedermayer
---
libavformat/avienc.c | 19 +++
libavformat/internal.h |7 ++-
libavformat/rawutils.c |5 +++--
3 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 09ec63b..e6a27c3 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -646,7 +646,11 @@ static int write_skip_frames(AVFormatContext *s, int
stream_index, int64_t dts)
static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
{
+unsigned char tag[5];
const int stream_index = pkt->stream_index;
+const uint8_t *data= pkt->data;
+int size = pkt->size;
+AVIOContext *pb = s->pb;
AVCodecContext *enc = s->streams[stream_index]->codec;
int ret;
@@ -667,6 +671,21 @@ static int avi_write_packet(AVFormatContext *s, AVPacket
*pkt)
if (ret < 0)
return ret;
if (ret) {
+if (ret == CONTAINS_PAL) {
+int pc_tag, i;
+avi_stream2fourcc(tag, stream_index, enc->codec_type);
+tag[2] = 'p'; tag[3] = 'c';
+
+pc_tag = ff_start_tag(pb, tag);
+avio_w8(pb, 0);
+avio_w8(pb, 0);
+avio_wl16(pb, 0/*flags FIXME*/);
+for (i = 0; i<256; i++) {
+uint32_t v = AV_RL32(data + size - 1024 + 4*i);
+avio_wb32(pb, v<<8);
+}
+ff_end_tag(pb, pc_tag);
+}
ret = avi_write_packet_internal(s, pkt);
av_packet_free(&pkt);
return ret;
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 93be632..936415b 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -560,11 +560,16 @@ void ff_format_io_close(AVFormatContext *s, AVIOContext
**pb);
*/
int ff_parse_creation_time_metadata(AVFormatContext *s, int64_t *timestamp,
int return_seconds);
+
+#define CONTAINS_PAL 2
/**
* Reshuffles the lines to use the user specified stride.
*
* @param ppkt input and output packet
- * @return negative error code or 0 or 1, 1 indicates that ppkt needs to be
freed
+ * @return negative error code or
+ * 0 if no new packet was allocated
+ * no zerp if a new packet was allocated and ppkt has to be freed
+ * CONTAINS_PAL if in addition to a new packet the old contained a
palette
*/
int ff_reshuffle_raw_rgb(AVFormatContext *s, AVPacket **ppkt, AVCodecContext
*enc, int expected_stride);
diff --git a/libavformat/rawutils.c b/libavformat/rawutils.c
index 1e6148d..26ebbb5 100644
--- a/libavformat/rawutils.c
+++ b/libavformat/rawutils.c
@@ -29,7 +29,8 @@ int ff_reshuffle_raw_rgb(AVFormatContext *s, AVPacket **ppkt,
AVCodecContext *en
int64_t bpc = enc->bits_per_coded_sample != 15 ?
enc->bits_per_coded_sample : 16;
int min_stride = (enc->width * bpc + 7) >> 3;
int with_pal_size = min_stride * enc->height + 1024;
-int size = bpc == 8 && pkt->size == with_pal_size ? min_stride *
enc->height : pkt->size;
+int contains_pal = bpc == 8 && pkt->size == with_pal_size;
+int size = contains_pal ? min_stride * enc->height : pkt->size;
int stride = size / enc->height;
int padding = expected_stride - FFMIN(expected_stride, stride);
int y;
@@ -58,7 +59,7 @@ int ff_reshuffle_raw_rgb(AVFormatContext *s, AVPacket **ppkt,
AVCodecContext *en
}
*ppkt = new_pkt;
-return 1;
+return 1 + contains_pal;
fail:
av_packet_free(&new_pkt);
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add BobWeaver deinterlacing filter
>>> Paul B Mahol schrieb am Mi, 17.2.2016: > If nobody plans to comment on code I will apply this soon. I´ve seen you applied it. Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat/avienc: Use avi_write_packet_internal() to store raw rgb in a more spec compliant way
On Wed, Feb 17, 2016 at 02:29:08PM +0100, Mats Peterson wrote: > On 02/17/2016 02:16 PM, Mats Peterson wrote: > >On 02/17/2016 02:02 PM, Michael Niedermayer wrote: > >>Please test this with various players if you can > > > >The only player that I have here that can play raw files properly is > >FFplay, unfortunately. The VLC I have here is an old one from Debian > >Wheezy, and MPlayer erroneusly thinks anything with rawvideo is 24-bit > >RGB. But I'll try these with FFplay. > > > > Seems to work OK with AVI. No palette included in the output file, > and stride is correct. But the palette after the BITMAPINFOHEADER in > the strf chunk is still missing. Currently the display is just > black. one step at a time patch applied, as it fixes th stride thanks for testing > > QuickTime still doesn't work, but I didn't expect it to. > > Mats > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] pngdsp add bytes padding
On Thu, Feb 18, 2016 at 05:53:46PM +0100, Clément Bœsch wrote:
> On Thu, Feb 18, 2016 at 12:42:59PM +0100, Michael Niedermayer wrote:
> > On Thu, Feb 18, 2016 at 11:36:18AM +0100, Clément Bœsch wrote:
> > > Hi,
> > >
> > > While working on PNG DSP, I realized the filter up was doing extra
> > > overflow checks on the bytes non multiple of the long word size. This
> > > logic is present in both C and x86 ASM. Here is the current C code for
> > > reference:
> > >
> > > -- 8<
> > >
> > > // 0x7f7f7f7f or 0x7f7f7f7f7f7f7f7f or whatever, depending on the cpu's
> > > native arithmetic size
> > > #define pb_7f (~0UL / 255 * 0x7f)
> > > #define pb_80 (~0UL / 255 * 0x80)
> > >
> > > static void add_bytes_l2_c(uint8_t *dst, uint8_t *src1, uint8_t *src2,
> > > int w)
> > > {
> > > long i;
> > > for (i = 0; i <= w - (int) sizeof(long); i += sizeof(long)) {
> > > long a = *(long *)(src1 + i);
> > > long b = *(long *)(src2 + i);
> > > *(long *)(dst + i) = ((a & pb_7f) + (b & pb_7f)) ^ ((a ^ b) &
> > > pb_80);
> > > }
> > > for (; i < w; i++)
> > > dst[i] = src1[i] + src2[i];
> > > }
> > >
> > > -- 8<
> > >
> > > The thing is, the buffers seem to be 0 padded to 16 (see
> > > av_fast_padded_malloc() calls). I'm assuming there are cases where it's
> > > not?
> >
> > isnt dst the AVFrame in one call ?
> > so that this would write over width if it wrote beyond ?
> >
>
> but isn't frame->data[N] always padded as well...?
if a user app returns pointers to some memory for direct rendering
from get_buffer then it might be all kinds of stuff
for example it might be aligned but there might be data to the
right like window decorations/border
but maybe iam missing something
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/libvpx: fix support for RGB colorspace.
Initial patch by Carl Eugen Hoyos.
Fix trac ticket #5249.
Signed-off-by: Nicolas George
---
libavcodec/libvpx.c| 1 +
libavcodec/libvpxenc.c | 1 +
2 files changed, 2 insertions(+)
This is probably quite incomplete (high bit depth?), and there should
probably be a consistency check or automatic switch between colorspace and
pixel format.
Adding James Zern in Cc, since he is the author of this bit.
diff --git a/libavcodec/libvpx.c b/libavcodec/libvpx.c
index a60d186..980ad01 100644
--- a/libavcodec/libvpx.c
+++ b/libavcodec/libvpx.c
@@ -38,6 +38,7 @@ static const enum AVPixelFormat vp9_pix_fmts_highcol[] = {
AV_PIX_FMT_YUV422P,
AV_PIX_FMT_YUV440P,
AV_PIX_FMT_YUV444P,
+AV_PIX_FMT_GBRP,
AV_PIX_FMT_NONE
};
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 8992497..91499fd 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -295,6 +295,7 @@ static int set_pix_fmt(AVCodecContext *avctx,
vpx_codec_caps_t codec_caps,
*img_fmt = VPX_IMG_FMT_I440;
return 0;
#endif
+case AV_PIX_FMT_GBRP:
case AV_PIX_FMT_YUV444P:
enccfg->g_profile = 1;
*img_fmt = VPX_IMG_FMT_I444;
--
2.7.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add firequalizer filter
> +center = s->fir_len / 2;
> +
> +for (k = 0; k <= center; k++) {
> +double u = k * (M_PI/center);
> +double win;
> +switch (s->wfunc) {
> +case WFUNC_RECTANGULAR:
> +win = 1.0;
> +break;
> +case WFUNC_HANN:
> +win = 0.5 + 0.5 * cos(u);
> +break;
> +case WFUNC_HAMMING:
> +win = 0.53836 + 0.46164 * cos(u);
> +break;
> +case WFUNC_BLACKMAN:
> +win = 0.48 + 0.5 * cos(u) + 0.02 * cos(2*u);
> +break;
> +case WFUNC_NUTTALL3:
> +win = 0.40897 + 0.5 * cos(u) + 0.09103 * cos(2*u);
> +break;
> +case WFUNC_MNUTTALL3:
> +win = 0.4243801 + 0.4973406 * cos(u) + 0.0782793 * cos(2*u);
> +break;
> +case WFUNC_NUTTALL:
> +win = 0.355768 + 0.487396 * cos(u) + 0.144232 * cos(2*u) +
> 0.012604 * cos(3*u);
> +break;
> +case WFUNC_BNUTTALL:
> +win = 0.3635819 + 0.4891775 * cos(u) + 0.1365995 * cos(2*u)
> + 0.0106411 * cos(3*u);
> +break;
> +case WFUNC_BHARRIS:
> +win = 0.35875 + 0.48829 * cos(u) + 0.14128 * cos(2*u) +
> 0.01168 * cos(3*u);
> +break;
What about using libavfilter/window_func.c ?
Still LGTM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avienc: Store pal8 palette
On 02/18/2016 09:14 PM, Michael Niedermayer wrote: This can be made more efficient, but first and the main goal of this change is to store it at all Great, Michael. I'll try it out. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avienc: Store pal8 palette
On Thu, Feb 18, 2016 at 21:14:55 +0100, Michael Niedermayer wrote: > + * no zerp if a new packet was allocated and ppkt has to be freed "no zerp"? Cute. Probably "non-zero" Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avienc: Store pal8 palette
On 02/18/2016 10:27 PM, Mats Peterson wrote: On 02/18/2016 09:14 PM, Michael Niedermayer wrote: This can be made more efficient, but first and the main goal of this change is to store it at all Great, Michael. I'll try it out. Mats I notice that the palette inclusion is only made by using 'xxpc' chunks in the video data so far. I'm not so sure if these in-data palette changing chunks are widely supported. Therefore, first and foremost, and the most widely supported way in my book, is to add an "initial" palette after the BITMAPINFOHEADER in the strf chunk. That's where I found it to be a bit tricky, but I'm sure you can solve it in some way. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avienc: Store pal8 palette
On 02/18/2016 10:39 PM, Moritz Barsnick wrote: On Thu, Feb 18, 2016 at 21:14:55 +0100, Michael Niedermayer wrote: + * no zerp if a new packet was allocated and ppkt has to be freed "no zerp"? Cute. Probably "non-zero" That's a new term ;) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avienc: Store pal8 palette
On 02/18/2016 10:40 PM, Mats Peterson wrote: On 02/18/2016 10:27 PM, Mats Peterson wrote: On 02/18/2016 09:14 PM, Michael Niedermayer wrote: This can be made more efficient, but first and the main goal of this change is to store it at all Great, Michael. I'll try it out. Mats I notice that the palette inclusion is only made by using 'xxpc' chunks in the video data so far. I'm not so sure if these in-data palette changing chunks are widely supported. Therefore, first and foremost, and the most widely supported way in my book, is to add an "initial" palette after the BITMAPINFOHEADER in the strf chunk. That's where I found it to be a bit tricky, but I'm sure you can solve it in some way. Mats FFplay plays these files fine, but Windows XP Media Player needs that palette after the BITMAPINFOHEADER. It doesn't seem to care about those 'xxpc' chunks. Interesting, since the Media Player ought to support everything in the AVI specs. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avienc: Store pal8 palette
On 02/18/2016 10:53 PM, Mats Peterson wrote: FFplay plays these files fine, but Windows XP Media Player needs that palette after the BITMAPINFOHEADER. It doesn't seem to care about those 'xxpc' chunks. Interesting, since the Media Player ought to support everything in the AVI specs. That is Windows Media Player 9. But I doubt that playback of raw video has improved in later versions. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avienc: Store pal8 palette
On Thu, Feb 18, 2016 at 10:40:42PM +0100, Mats Peterson wrote: > On 02/18/2016 10:27 PM, Mats Peterson wrote: > >On 02/18/2016 09:14 PM, Michael Niedermayer wrote: > >>This can be made more efficient, but first and the main goal of this > >>change is to > >>store it at all > >Great, Michael. I'll try it out. > > > >Mats > > > > I notice that the palette inclusion is only made by using 'xxpc' > chunks in the video data so far. I'm not so sure if these in-data > palette changing chunks are widely supported. Therefore, first and > foremost, and the most widely supported way in my book, is to add an > "initial" palette after the BITMAPINFOHEADER in the strf chunk. > That's where I found it to be a bit tricky, but I'm sure you can > solve it in some way. its quite easy to implement if you want to try just leave some space where the palette should go whe writing the headers and keep track of the location, then when the first packet comes in take its palette and store it there [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 "Rare item" - "Common item with rare defect or maybe just a lie" "Professional" - "'Toy' made in china, not functional except as doorstop" "Experts will know" - "The seller hopes you are not an expert" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avienc: Store pal8 palette
On 02/18/2016 11:04 PM, Michael Niedermayer wrote: On Thu, Feb 18, 2016 at 10:40:42PM +0100, Mats Peterson wrote: On 02/18/2016 10:27 PM, Mats Peterson wrote: On 02/18/2016 09:14 PM, Michael Niedermayer wrote: This can be made more efficient, but first and the main goal of this change is to store it at all Great, Michael. I'll try it out. Mats I notice that the palette inclusion is only made by using 'xxpc' chunks in the video data so far. I'm not so sure if these in-data palette changing chunks are widely supported. Therefore, first and foremost, and the most widely supported way in my book, is to add an "initial" palette after the BITMAPINFOHEADER in the strf chunk. That's where I found it to be a bit tricky, but I'm sure you can solve it in some way. its quite easy to implement if you want to try just leave some space where the palette should go whe writing the headers and keep track of the location, then when the first packet comes in take its palette and store it there I could try, yes. But not tonight, I'm a bit tired :) I'll look into it, perhaps I can make it. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GSoC 2016 own ideas
On Donnerstag, 18. Februar 2016 21:02:09 CET wm4 wrote: > On Thu, 18 Feb 2016 20:41:29 +0100 > > Gerion Entrup wrote: > > On Donnerstag, 18. Februar 2016 20:10:47 CET wm4 wrote: > > > On Thu, 18 Feb 2016 18:27:45 +0100 > > > > > > Gerion Entrup wrote: > > > > Good day, > > > > > > > > I'm a master student and long term FFmpeg-user. I want to participate > > > > in > > > > the GSoC 2016 for FFmpeg. The reason, I write this, is that I want to > > suggest some own ideas. It could be, that some of the mentioned things > > are wrong (because FFmpeg could do this already or it it much more > > difficult than I think). Please correct me if so. > > > > > > I'm excited to hear, what do you think about this ideas, if you think, > > > > they are suitable for GSoC and if you maybe are willing to mentor some of > > this. > > > > > > 1. *disc support > > > > > > > > What current FFmpeg could do: > > > > - Bluray support through protocol support with prefix "bluray:" and > > > > libbluray. The implemention is some kind of limited. There is missing > > chapter support. The "main movie" selection is simply the longest one. > > Menus are not supported. Afaik no metadata are transfered. > > > > > > - CD support through libavdevice and libcdio. Last time I tried it, it > > > > only works under some strange circumstances (I have to set the parameter > > "-ss 0"). I don't know if it is fixed right now. It recognizes a CD as > > one track with multiple chapters. Afaik CD-Text is not supported. > > > > > > - No DVD support at all. I saw, that Stefano ones write a patch [1] > > > > (protocol and libdvdnav based), which seems to work in principal, but was > > probably not ready to merge. > > > > > > Goal: > > > > - Implement an uniform solution for *disc support, that also support > > > > metadata. > > > > > > - Maybe (?): Add some kind of Menu Support, FFmpeg is not made for > > > > this > > > > atm, I think. Not sure how difficult it is. > > > > > > - Maybe (?): Try to change something on libdvdnav/libdvdread to make > > > > it > > > > more consistent (to libbluray ?). Similar idea from Flameeyes [2]. > > > > > Hm, I'm not sure if that's even possible in a reasonable way. Full > > > DVD/Bluray support requires menus, which are hard to get right, and > > > which would require non-trivial interactions between applications and > > > libavformat. > > > > > > Improving support for merely transcoding a DVD to a file might be not > > > so hard and potentially a good idea, though. > > > > > > > Qualification task: > > > > - Maybe (?): Add chapter support for the current Bluray implementation > > > > (get the chapters out of libbluray is fairly simple, I'm not sure how > > difficult it is to get them into the stream). > > > > > This sounds like a hard design issue: currently bluray is implemented > > > as avio protocol, which can not pass things like chapters to the higher > > > level (demuxer). This would require coming up with a mechanism for > > > transferring this metadata, which sounds hard. Just reading the bluray > > > chapters should indeed be simple. > > > > Just reading the chapters and print them is too simple to be a > > qualification task. > > Indeed. > > By the way, your mail client is making it very hard to distinguish > quoted text from your replies. It doesn't add a ">" on the next line > when line-breaking the quoted text. I see it myself in the received mail. I found out, what causes it. It is clearly a bug, but I hopefully can circumvent it, sorry. > > > > > Comments: > > > > - I would try to orientate on VLC, mplayer and mpv implementation. > > > > - libdvdread/nav seem to do much less than libbluray, so the main work > > > > would be the dvd support, I guess. > > > > > > - All kinds of discs normally contains more than one track. My idea > > > > for a > > > > solution would be, that ffmpeg recognize the disc as multiinput and choose > > the mainmovie as default. > > > > > > 2. treelike metadata > > > > > > > > What current FFmpeg could do: > > > > - Metadata is always an AVDictionary (string based afaik). > > > > - Some metadata systems like the one of Matroska use a treelike > > > > structure > > > > (xml in mkv), so you can specify the charatername given an actor or define > > more than on actor, see example at the end of the mail. > > > > > > Goal: > > > > Rewrite the FFmpeg metadata system, to support extended tags. In > > > > Detail: > > > > - Support for more than one value per key. > > > > - Support for more key/value pairs as value. > > > > > > > > Qualification task: > > > > No idea. > > > > > > > > Comments: > > > > Not sure, if this task is GSoC suitable. > > > > > > Includes API design, which is better avoided for a gsoc. I'm also not > > > sure if we really need such metadata, but I guess this is debatable. > > > > > > > 3. Vector graphic support > > > > > > > > What current FFmpeg could do: > > > > - No support at all, afaik. > > > > > > > > Goal: > > > > - E
[FFmpeg-devel] avcodec/cdxl: add support for videos with chunky format
Hi,
patch attached.
From 7f8779b9be131414a073d051725a5e0aac19d466 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Thu, 18 Feb 2016 23:47:39 +0100
Subject: [PATCH] avcodec/cdxl: add support for videos with chunky format
Signed-off-by: Paul B Mahol
---
libavcodec/cdxl.c | 33 ++---
libavformat/cdxl.c | 8 ++--
2 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/libavcodec/cdxl.c b/libavcodec/cdxl.c
index 50d514b..5d968ec 100644
--- a/libavcodec/cdxl.c
+++ b/libavcodec/cdxl.c
@@ -30,6 +30,7 @@
#include "libavutil/intreadwrite.h"
#include "libavutil/imgutils.h"
#include "avcodec.h"
+#include "bytestream.h"
#include "get_bits.h"
#include "internal.h"
@@ -107,6 +108,17 @@ static void bitline2chunky(CDXLVideoContext *c, int linesize, uint8_t *out)
}
}
+static void chunky2chunky(CDXLVideoContext *c, int linesize, uint8_t *out)
+{
+GetByteContext gb;
+int y;
+
+bytestream2_init(&gb, c->video, c->video_size);
+for (y = 0; y < c->avctx->height; y++) {
+bytestream2_get_buffer(&gb, out + linesize * y, c->avctx->width * 3);
+}
+}
+
static void import_format(CDXLVideoContext *c, int linesize, uint8_t *out)
{
memset(out, 0, linesize * c->avctx->height);
@@ -118,6 +130,9 @@ static void import_format(CDXLVideoContext *c, int linesize, uint8_t *out)
case BIT_LINE:
bitline2chunky(c, linesize, out);
break;
+case CHUNKY:
+chunky2chunky(c, linesize, out);
+break;
}
}
@@ -130,6 +145,11 @@ static void cdxl_decode_rgb(CDXLVideoContext *c, AVFrame *frame)
import_format(c, frame->linesize[0], frame->data[0]);
}
+static void cdxl_decode_raw(CDXLVideoContext *c, AVFrame *frame)
+{
+import_format(c, frame->linesize[0], frame->data[0]);
+}
+
static void cdxl_decode_ham6(CDXLVideoContext *c, AVFrame *frame)
{
AVCodecContext *avctx = c->avctx;
@@ -242,7 +262,7 @@ static int cdxl_decode_frame(AVCodecContext *avctx, void *data,
return AVERROR_INVALIDDATA;
if (c->bpp < 1)
return AVERROR_INVALIDDATA;
-if (c->format != BIT_PLANAR && c->format != BIT_LINE) {
+if (c->format != BIT_PLANAR && c->format != BIT_LINE && c->format != CHUNKY) {
avpriv_request_sample(avctx, "Pixel format 0x%0x", c->format);
return AVERROR_PATCHWELCOME;
}
@@ -250,7 +270,10 @@ static int cdxl_decode_frame(AVCodecContext *avctx, void *data,
if ((ret = ff_set_dimensions(avctx, w, h)) < 0)
return ret;
-aligned_width = FFALIGN(c->avctx->width, 16);
+if (c->format == CHUNKY)
+aligned_width = avctx->width;
+else
+aligned_width = FFALIGN(c->avctx->width, 16);
c->padded_bits = aligned_width - c->avctx->width;
if (c->video_size < aligned_width * avctx->height * c->bpp / 8)
return AVERROR_INVALIDDATA;
@@ -260,6 +283,8 @@ static int cdxl_decode_frame(AVCodecContext *avctx, void *data,
if (c->palette_size != (1 << (c->bpp - 1)))
return AVERROR_INVALIDDATA;
avctx->pix_fmt = AV_PIX_FMT_BGR24;
+} else if (!encoding && c->bpp == 8 && c->format == CHUNKY) {
+avctx->pix_fmt = AV_PIX_FMT_BGR24;
} else {
avpriv_request_sample(avctx, "Encoding %d and bpp %d",
encoding, c->bpp);
@@ -279,8 +304,10 @@ static int cdxl_decode_frame(AVCodecContext *avctx, void *data,
cdxl_decode_ham8(c, p);
else
cdxl_decode_ham6(c, p);
-} else {
+} else if (avctx->pix_fmt == AV_PIX_FMT_PAL8) {
cdxl_decode_rgb(c, p);
+} else {
+cdxl_decode_raw(c, p);
}
*got_frame = 1;
diff --git a/libavformat/cdxl.c b/libavformat/cdxl.c
index 3d80b47..0b8b199 100644
--- a/libavformat/cdxl.c
+++ b/libavformat/cdxl.c
@@ -111,7 +111,7 @@ static int cdxl_read_packet(AVFormatContext *s, AVPacket *pkt)
uint32_t current_size, video_size, image_size;
uint16_t audio_size, palette_size, width, height;
int64_t pos;
-int frames, ret;
+int format, frames, ret;
if (avio_feof(pb))
return AVERROR_EOF;
@@ -125,6 +125,7 @@ static int cdxl_read_packet(AVFormatContext *s, AVPacket *pkt)
return AVERROR_INVALIDDATA;
}
+format = cdxl->header[1] & 0xE0;
current_size = AV_RB32(&cdxl->header[2]);
width= AV_RB16(&cdxl->header[14]);
height = AV_RB16(&cdxl->header[16]);
@@ -132,7 +133,10 @@ static int cdxl_read_packet(AVFormatContext *s, AVPacket *pkt)
audio_size = AV_RB16(&cdxl->header[22]);
if (FFALIGN(width, 16) * (uint64_t)height * cdxl->header[19] > INT_MAX)
return AVERROR_INVALIDDATA;
-image_size = FFALIGN(width, 16) * height * cdxl->header[19] / 8;
+if (format == 0x20)
+image_size = width * height * cdxl->header[19] / 8;
+else
+image_size = FFALIGN(width, 16) * height * cdxl->header[19] / 8;
video_size = palette_size + image_size;
if (palette
Re: [FFmpeg-devel] [PATCH] lavc/libvpx: fix support for RGB colorspace.
On Thursday 18 February 2016 09:40:01 pm Nicolas George wrote:
> Initial patch by Carl Eugen Hoyos.
>
> Fix trac ticket #5249.
Patch with (automatic) support for 8, 10 and 12 bit gbr attached.
Please comment, Carl Eugen
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 8992497..c1c1fbe 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -106,6 +106,7 @@ typedef struct VP8EncoderContext {
int aq_mode;
int drop_threshold;
int noise_sensitivity;
+int vpx_cs;
} VP8Context;
/** String mappings for enum vp8e_enc_control_id */
@@ -277,6 +278,7 @@ static int set_pix_fmt(AVCodecContext *avctx,
vpx_codec_caps_t codec_caps,
struct vpx_codec_enc_cfg *enccfg, vpx_codec_flags_t
*flags,
vpx_img_fmt_t *img_fmt)
{
+VP8Context *ctx = avctx->priv_data;
#ifdef VPX_IMG_FMT_HIGHBITDEPTH
enccfg->g_bit_depth = enccfg->g_input_bit_depth = 8;
#endif
@@ -295,6 +297,8 @@ static int set_pix_fmt(AVCodecContext *avctx,
vpx_codec_caps_t codec_caps,
*img_fmt = VPX_IMG_FMT_I440;
return 0;
#endif
+case AV_PIX_FMT_GBRP:
+ctx->vpx_cs = VPX_CS_SRGB;
case AV_PIX_FMT_YUV444P:
enccfg->g_profile = 1;
*img_fmt = VPX_IMG_FMT_I444;
@@ -335,11 +339,15 @@ static int set_pix_fmt(AVCodecContext *avctx,
vpx_codec_caps_t codec_caps,
}
break;
#endif
+case AV_PIX_FMT_GBRP10LE:
+case AV_PIX_FMT_GBRP12LE:
+ctx->vpx_cs = VPX_CS_SRGB;
case AV_PIX_FMT_YUV444P10LE:
case AV_PIX_FMT_YUV444P12LE:
if (codec_caps & VPX_CODEC_CAP_HIGHBITDEPTH) {
enccfg->g_bit_depth = enccfg->g_input_bit_depth =
-avctx->pix_fmt == AV_PIX_FMT_YUV444P10LE ? 10 : 12;
+avctx->pix_fmt == AV_PIX_FMT_YUV444P10LE ||
+avctx->pix_fmt == AV_PIX_FMT_GBRP10LE ? 10 : 12;
enccfg->g_profile = 3;
*img_fmt = VPX_IMG_FMT_I44416;
*flags |= VPX_CODEC_USE_HIGHBITDEPTH;
@@ -358,7 +366,11 @@ static int set_pix_fmt(AVCodecContext *avctx,
vpx_codec_caps_t codec_caps,
static void set_colorspace(AVCodecContext *avctx)
{
enum vpx_color_space vpx_cs;
+VP8Context *ctx = avctx->priv_data;
+if (ctx->vpx_cs) {
+vpx_cs = ctx->vpx_cs;
+} else {
switch (avctx->colorspace) {
case AVCOL_SPC_RGB: vpx_cs = VPX_CS_SRGB; break;
case AVCOL_SPC_BT709: vpx_cs = VPX_CS_BT_709;break;
@@ -373,6 +385,7 @@ static void set_colorspace(AVCodecContext *avctx)
avctx->colorspace);
return;
}
+}
codecctl_int(avctx, VP9E_SET_COLOR_SPACE, vpx_cs);
}
#endif
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/libvpx: fix support for RGB colorspace.
On Thu, Feb 18, 2016 at 11:59 PM, Carl Eugen Hoyos wrote: > On Thursday 18 February 2016 09:40:01 pm Nicolas George wrote: >> Initial patch by Carl Eugen Hoyos. >> >> Fix trac ticket #5249. > > Patch with (automatic) support for 8, 10 and 12 bit gbr attached. > > Please comment, Carl Eugen This lacks the appropriate changes in libvpx.c to the supported pixel formats for the encoder. Also, please re-indent appropriately. If its not in this patch, it'll never get done. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/libvpx: fix support for RGB colorspace.
On 2/18/2016 7:59 PM, Carl Eugen Hoyos wrote: > +case AV_PIX_FMT_GBRP: > +ctx->vpx_cs = VPX_CS_SRGB; This is only available since libvpx 1.4.0, so you need to wrap all this new code inside some preprocessor checks. I think VPX_IMAGE_ABI_VERSION >= 3 should do it, but better wait for James Zern for confirmation. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/libvpx: fix support for RGB colorspace.
On Friday 19 February 2016 12:02:59 am Hendrik Leppkes wrote:
> On Thu, Feb 18, 2016 at 11:59 PM, Carl Eugen Hoyos wrote:
> > On Thursday 18 February 2016 09:40:01 pm Nicolas George wrote:
> >> Initial patch by Carl Eugen Hoyos.
> >>
> >> Fix trac ticket #5249.
> >
> > Patch with (automatic) support for 8, 10 and 12 bit gbr attached.
> >
> > Please comment, Carl Eugen
>
> This lacks the appropriate changes in libvpx.c to the supported pixel
> formats for the encoder.
Sorry, new patch attached.
> Also, please re-indent appropriately. If its not in this patch, it'll
> never get done.
I will reindent if you (or James) want me to do it.
Carl Eugen
diff --git a/libavcodec/libvpx.c b/libavcodec/libvpx.c
index a60d186..fb2d1fc 100644
--- a/libavcodec/libvpx.c
+++ b/libavcodec/libvpx.c
@@ -38,6 +38,7 @@ static const enum AVPixelFormat vp9_pix_fmts_highcol[] = {
AV_PIX_FMT_YUV422P,
AV_PIX_FMT_YUV440P,
AV_PIX_FMT_YUV444P,
+AV_PIX_FMT_GBRP,
AV_PIX_FMT_NONE
};
@@ -54,6 +55,8 @@ static const enum AVPixelFormat vp9_pix_fmts_highbd[] = {
AV_PIX_FMT_YUV422P12LE,
AV_PIX_FMT_YUV440P12LE,
AV_PIX_FMT_YUV444P12LE,
+AV_PIX_FMT_GBRP10LE,
+AV_PIX_FMT_GBRP12LE,
AV_PIX_FMT_NONE
};
#endif
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 8992497..c1c1fbe 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -106,6 +106,7 @@ typedef struct VP8EncoderContext {
int aq_mode;
int drop_threshold;
int noise_sensitivity;
+int vpx_cs;
} VP8Context;
/** String mappings for enum vp8e_enc_control_id */
@@ -277,6 +278,7 @@ static int set_pix_fmt(AVCodecContext *avctx,
vpx_codec_caps_t codec_caps,
struct vpx_codec_enc_cfg *enccfg, vpx_codec_flags_t
*flags,
vpx_img_fmt_t *img_fmt)
{
+VP8Context *ctx = avctx->priv_data;
#ifdef VPX_IMG_FMT_HIGHBITDEPTH
enccfg->g_bit_depth = enccfg->g_input_bit_depth = 8;
#endif
@@ -295,6 +297,8 @@ static int set_pix_fmt(AVCodecContext *avctx,
vpx_codec_caps_t codec_caps,
*img_fmt = VPX_IMG_FMT_I440;
return 0;
#endif
+case AV_PIX_FMT_GBRP:
+ctx->vpx_cs = VPX_CS_SRGB;
case AV_PIX_FMT_YUV444P:
enccfg->g_profile = 1;
*img_fmt = VPX_IMG_FMT_I444;
@@ -335,11 +339,15 @@ static int set_pix_fmt(AVCodecContext *avctx,
vpx_codec_caps_t codec_caps,
}
break;
#endif
+case AV_PIX_FMT_GBRP10LE:
+case AV_PIX_FMT_GBRP12LE:
+ctx->vpx_cs = VPX_CS_SRGB;
case AV_PIX_FMT_YUV444P10LE:
case AV_PIX_FMT_YUV444P12LE:
if (codec_caps & VPX_CODEC_CAP_HIGHBITDEPTH) {
enccfg->g_bit_depth = enccfg->g_input_bit_depth =
-avctx->pix_fmt == AV_PIX_FMT_YUV444P10LE ? 10 : 12;
+avctx->pix_fmt == AV_PIX_FMT_YUV444P10LE ||
+avctx->pix_fmt == AV_PIX_FMT_GBRP10LE ? 10 : 12;
enccfg->g_profile = 3;
*img_fmt = VPX_IMG_FMT_I44416;
*flags |= VPX_CODEC_USE_HIGHBITDEPTH;
@@ -358,7 +366,11 @@ static int set_pix_fmt(AVCodecContext *avctx,
vpx_codec_caps_t codec_caps,
static void set_colorspace(AVCodecContext *avctx)
{
enum vpx_color_space vpx_cs;
+VP8Context *ctx = avctx->priv_data;
+if (ctx->vpx_cs) {
+vpx_cs = ctx->vpx_cs;
+} else {
switch (avctx->colorspace) {
case AVCOL_SPC_RGB: vpx_cs = VPX_CS_SRGB; break;
case AVCOL_SPC_BT709: vpx_cs = VPX_CS_BT_709;break;
@@ -373,6 +385,7 @@ static void set_colorspace(AVCodecContext *avctx)
avctx->colorspace);
return;
}
+}
codecctl_int(avctx, VP9E_SET_COLOR_SPACE, vpx_cs);
}
#endif
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/libvpx: fix support for RGB colorspace.
On 2/18/2016 8:10 PM, James Almer wrote: > On 2/18/2016 7:59 PM, Carl Eugen Hoyos wrote: >> +case AV_PIX_FMT_GBRP: >> +ctx->vpx_cs = VPX_CS_SRGB; > > This is only available since libvpx 1.4.0, so you need to wrap all this new > code inside some preprocessor checks. I think VPX_IMAGE_ABI_VERSION >= 3 > should do it, but better wait for James Zern for confirmation. Alternatively we could bump the minimum required version and remove most of the existing checks. 1.3.0 is pretty old by now and it would let us clean these files. I doubt there's any distro out there that would ship ffmpeg 3.1 alongside libvpx 1.3.0. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavc/libvpx: Fix high-bitrate colour spaces
Please comment, Carl Eugen
diff --git a/libavcodec/libvpx.c b/libavcodec/libvpx.c
index a60d186..1e7010b 100644
--- a/libavcodec/libvpx.c
+++ b/libavcodec/libvpx.c
@@ -46,14 +46,14 @@ static const enum AVPixelFormat vp9_pix_fmts_highbd[] = {
AV_PIX_FMT_YUV422P,
AV_PIX_FMT_YUV440P,
AV_PIX_FMT_YUV444P,
-AV_PIX_FMT_YUV420P10LE,
-AV_PIX_FMT_YUV422P10LE,
-AV_PIX_FMT_YUV440P10LE,
-AV_PIX_FMT_YUV444P10LE,
-AV_PIX_FMT_YUV420P12LE,
-AV_PIX_FMT_YUV422P12LE,
-AV_PIX_FMT_YUV440P12LE,
-AV_PIX_FMT_YUV444P12LE,
+AV_PIX_FMT_YUV420P10,
+AV_PIX_FMT_YUV422P10,
+AV_PIX_FMT_YUV440P10,
+AV_PIX_FMT_YUV444P10,
+AV_PIX_FMT_YUV420P12,
+AV_PIX_FMT_YUV422P12,
+AV_PIX_FMT_YUV440P12,
+AV_PIX_FMT_YUV444P12,
AV_PIX_FMT_NONE
};
#endif
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 8992497..8dce4bb 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -300,22 +300,22 @@ static int set_pix_fmt(AVCodecContext *avctx,
vpx_codec_caps_t codec_caps,
*img_fmt = VPX_IMG_FMT_I444;
return 0;
#ifdef VPX_IMG_FMT_HIGHBITDEPTH
-case AV_PIX_FMT_YUV420P10LE:
-case AV_PIX_FMT_YUV420P12LE:
+case AV_PIX_FMT_YUV420P10:
+case AV_PIX_FMT_YUV420P12:
if (codec_caps & VPX_CODEC_CAP_HIGHBITDEPTH) {
enccfg->g_bit_depth = enccfg->g_input_bit_depth =
-avctx->pix_fmt == AV_PIX_FMT_YUV420P10LE ? 10 : 12;
+avctx->pix_fmt == AV_PIX_FMT_YUV420P10 ? 10 : 12;
enccfg->g_profile = 2;
*img_fmt = VPX_IMG_FMT_I42016;
*flags |= VPX_CODEC_USE_HIGHBITDEPTH;
return 0;
}
break;
-case AV_PIX_FMT_YUV422P10LE:
-case AV_PIX_FMT_YUV422P12LE:
+case AV_PIX_FMT_YUV422P10:
+case AV_PIX_FMT_YUV422P12:
if (codec_caps & VPX_CODEC_CAP_HIGHBITDEPTH) {
enccfg->g_bit_depth = enccfg->g_input_bit_depth =
-avctx->pix_fmt == AV_PIX_FMT_YUV422P10LE ? 10 : 12;
+avctx->pix_fmt == AV_PIX_FMT_YUV422P10 ? 10 : 12;
enccfg->g_profile = 3;
*img_fmt = VPX_IMG_FMT_I42216;
*flags |= VPX_CODEC_USE_HIGHBITDEPTH;
@@ -323,11 +323,11 @@ static int set_pix_fmt(AVCodecContext *avctx,
vpx_codec_caps_t codec_caps,
}
break;
#if VPX_IMAGE_ABI_VERSION >= 3
-case AV_PIX_FMT_YUV440P10LE:
-case AV_PIX_FMT_YUV440P12LE:
+case AV_PIX_FMT_YUV440P10:
+case AV_PIX_FMT_YUV440P12:
if (codec_caps & VPX_CODEC_CAP_HIGHBITDEPTH) {
enccfg->g_bit_depth = enccfg->g_input_bit_depth =
-avctx->pix_fmt == AV_PIX_FMT_YUV440P10LE ? 10 : 12;
+avctx->pix_fmt == AV_PIX_FMT_YUV440P10 ? 10 : 12;
enccfg->g_profile = 3;
*img_fmt = VPX_IMG_FMT_I44016;
*flags |= VPX_CODEC_USE_HIGHBITDEPTH;
@@ -335,11 +335,11 @@ static int set_pix_fmt(AVCodecContext *avctx,
vpx_codec_caps_t codec_caps,
}
break;
#endif
-case AV_PIX_FMT_YUV444P10LE:
-case AV_PIX_FMT_YUV444P12LE:
+case AV_PIX_FMT_YUV444P10:
+case AV_PIX_FMT_YUV444P12:
if (codec_caps & VPX_CODEC_CAP_HIGHBITDEPTH) {
enccfg->g_bit_depth = enccfg->g_input_bit_depth =
-avctx->pix_fmt == AV_PIX_FMT_YUV444P10LE ? 10 : 12;
+avctx->pix_fmt == AV_PIX_FMT_YUV444P10 ? 10 : 12;
enccfg->g_profile = 3;
*img_fmt = VPX_IMG_FMT_I44416;
*flags |= VPX_CODEC_USE_HIGHBITDEPTH;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] checkasm: fix dependencies for vf_blend tests
They will now compile if avcodec is disabled
Signed-off-by: James Almer
---
tests/checkasm/Makefile | 6 +-
tests/checkasm/checkasm.c | 8 +---
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index bfd7c11..c24e797 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -1,6 +1,5 @@
# libavcodec tests
AVCODECOBJS-$(CONFIG_ALAC_DECODER) += alacdsp.o
-AVCODECOBJS-$(CONFIG_BLEND_FILTER) += vf_blend.o
AVCODECOBJS-$(CONFIG_BSWAPDSP) += bswapdsp.o
AVCODECOBJS-$(CONFIG_DCA_DECODER) += synth_filter.o
AVCODECOBJS-$(CONFIG_FLACDSP) += flacdsp.o
@@ -15,6 +14,11 @@ AVCODECOBJS-$(CONFIG_VIDEODSP) += videodsp.o
CHECKASMOBJS-$(CONFIG_AVCODEC) += $(AVCODECOBJS-yes)
+# libavfilter tests
+AVFILTEROBJS-$(CONFIG_BLEND_FILTER) += vf_blend.o
+
+CHECKASMOBJS-$(CONFIG_AVFILTER) += $(AVFILTEROBJS-yes)
+
-include $(SRC_PATH)/tests/checkasm/$(ARCH)/Makefile
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 1e73e34..fb8defd 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -68,9 +68,6 @@ static const struct {
#if CONFIG_ALAC_DECODER
{ "alacdsp", checkasm_check_alacdsp },
#endif
-#if CONFIG_BLEND_FILTER
-{ "vf_blend", checkasm_check_blend },
-#endif
#if CONFIG_BSWAPDSP
{ "bswapdsp", checkasm_check_bswapdsp },
#endif
@@ -105,6 +102,11 @@ static const struct {
{ "videodsp", checkasm_check_videodsp },
#endif
#endif
+#if CONFIG_AVFILTER
+#if CONFIG_BLEND_FILTER
+{ "vf_blend", checkasm_check_blend },
+#endif
+#endif
{ NULL }
};
--
2.7.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/libvpx: fix support for RGB colorspace.
On Friday 19 February 2016 12:18:06 am James Almer wrote:
> On 2/18/2016 8:10 PM, James Almer wrote:
> > On 2/18/2016 7:59 PM, Carl Eugen Hoyos wrote:
> >> +case AV_PIX_FMT_GBRP:
> >> +ctx->vpx_cs = VPX_CS_SRGB;
> >
> > This is only available since libvpx 1.4.0, so you need to wrap all this
> > new code inside some preprocessor checks. I think VPX_IMAGE_ABI_VERSION
> > >= 3 should do it, but better wait for James Zern for confirmation.
Of course, new patch attached (depends on the BE fix).
> Alternatively we could bump the minimum required version and remove most of
> the existing checks. 1.3.0 is pretty old by now and it would let us clean
> these files.
I would prefer if this could be done independently (and afterwards).
Thank you for the review, Carl Eugen
diff --git a/libavcodec/libvpx.c b/libavcodec/libvpx.c
index a60d186..58e98e6 100644
--- a/libavcodec/libvpx.c
+++ b/libavcodec/libvpx.c
@@ -38,6 +38,9 @@ static const enum AVPixelFormat vp9_pix_fmts_highcol[] = {
AV_PIX_FMT_YUV422P,
AV_PIX_FMT_YUV440P,
AV_PIX_FMT_YUV444P,
+#if VPX_IMAGE_ABI_VERSION >= 3
+AV_PIX_FMT_GBRP,
+#endif
AV_PIX_FMT_NONE
};
@@ -54,6 +57,11 @@ static const enum AVPixelFormat vp9_pix_fmts_highbd[] = {
AV_PIX_FMT_YUV422P12,
AV_PIX_FMT_YUV440P12,
AV_PIX_FMT_YUV444P12,
+#if VPX_IMAGE_ABI_VERSION >= 3
+AV_PIX_FMT_GBRP,
+AV_PIX_FMT_GBRP10,
+AV_PIX_FMT_GBRP12,
+#endif
AV_PIX_FMT_NONE
};
#endif
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 8992497..5417aea 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -106,6 +106,7 @@ typedef struct VP8EncoderContext {
int aq_mode;
int drop_threshold;
int noise_sensitivity;
+int vpx_cs;
} VP8Context;
/** String mappings for enum vp8e_enc_control_id */
@@ -277,6 +278,7 @@ static int set_pix_fmt(AVCodecContext *avctx,
vpx_codec_caps_t codec_caps,
struct vpx_codec_enc_cfg *enccfg, vpx_codec_flags_t
*flags,
vpx_img_fmt_t *img_fmt)
{
+VP8Context *ctx = avctx->priv_data;
#ifdef VPX_IMG_FMT_HIGHBITDEPTH
enccfg->g_bit_depth = enccfg->g_input_bit_depth = 8;
#endif
@@ -294,6 +296,8 @@ static int set_pix_fmt(AVCodecContext *avctx,
vpx_codec_caps_t codec_caps,
enccfg->g_profile = 1;
*img_fmt = VPX_IMG_FMT_I440;
return 0;
+case AV_PIX_FMT_GBRP:
+ctx->vpx_cs = VPX_CS_SRGB;
#endif
case AV_PIX_FMT_YUV444P:
enccfg->g_profile = 1;
@@ -334,12 +338,16 @@ static int set_pix_fmt(AVCodecContext *avctx,
vpx_codec_caps_t codec_caps,
return 0;
}
break;
+case AV_PIX_FMT_GBRP10:
+case AV_PIX_FMT_GBRP12:
+ctx->vpx_cs = VPX_CS_SRGB;
#endif
case AV_PIX_FMT_YUV444P10:
case AV_PIX_FMT_YUV444P12:
if (codec_caps & VPX_CODEC_CAP_HIGHBITDEPTH) {
enccfg->g_bit_depth = enccfg->g_input_bit_depth =
-avctx->pix_fmt == AV_PIX_FMT_YUV444P10 ? 10 : 12;
+avctx->pix_fmt == AV_PIX_FMT_YUV444P10 ||
+avctx->pix_fmt == AV_PIX_FMT_GBRP10 ? 10 : 12;
enccfg->g_profile = 3;
*img_fmt = VPX_IMG_FMT_I44416;
*flags |= VPX_CODEC_USE_HIGHBITDEPTH;
@@ -358,7 +366,11 @@ static int set_pix_fmt(AVCodecContext *avctx,
vpx_codec_caps_t codec_caps,
static void set_colorspace(AVCodecContext *avctx)
{
enum vpx_color_space vpx_cs;
+VP8Context *ctx = avctx->priv_data;
+if (ctx->vpx_cs) {
+vpx_cs = ctx->vpx_cs;
+} else {
switch (avctx->colorspace) {
case AVCOL_SPC_RGB: vpx_cs = VPX_CS_SRGB; break;
case AVCOL_SPC_BT709: vpx_cs = VPX_CS_BT_709;break;
@@ -373,6 +385,7 @@ static void set_colorspace(AVCodecContext *avctx)
avctx->colorspace);
return;
}
+}
codecctl_int(avctx, VP9E_SET_COLOR_SPACE, vpx_cs);
}
#endif
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Fixed issue #43 JACK indev support on OSX
---
configure | 14 +++---
libavdevice/jack.c | 12
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/configure b/configure
index 287896f..f2f7c3d 100755
--- a/configure
+++ b/configure
@@ -1732,6 +1732,7 @@ BUILTIN_LIST="
mm_empty
rdtsc
sarestart
+sem_timedwait
sync_val_compare_and_swap
"
HAVE_LIST_CMDLINE="
@@ -1758,6 +1759,7 @@ HEADERS_LIST="
dev_ic_bt8xx_h
dev_video_bktr_ioctl_bt848_h
dev_video_meteor_ioctl_meteor_h
+dispatch_dispatch_h
direct_h
dirent_h
dlfcn_h
@@ -2757,7 +2759,7 @@ gdigrab_indev_deps="CreateDIBSection"
gdigrab_indev_extralibs="-lgdi32"
gdigrab_indev_select="bmp_decoder"
iec61883_indev_deps="libiec61883"
-jack_indev_deps="jack_jack_h sem_timedwait"
+jack_indev_deps="jack_jack_h"
lavfi_indev_deps="avfilter"
libcdio_indev_deps="libcdio"
libdc1394_indev_deps="libdc1394"
@@ -5303,6 +5305,7 @@ check_func mprotect
check_func_headers time.h nanosleep || { check_func_headers time.h nanosleep
-lrt && add_extralibs -lrt && LIBRT="-lrt"; }
check_func sched_getaffinity
check_func setrlimit
+check_func sem_timedwait
check_struct "sys/stat.h" "struct stat" st_mtim.tv_nsec -D_BSD_SOURCE
check_func strerror_r
check_func sysconf
@@ -5330,6 +5333,7 @@ check_func_headers glob.h glob
enabled xlib &&
check_func_headers "X11/Xlib.h X11/extensions/Xvlib.h" XvGetPortAttribute
-lXv -lX11 -lXext
+check_header dispatch/dispatch.h
check_header direct.h
check_header dirent.h
check_header dlfcn.h
@@ -5702,8 +5706,12 @@ check_header soundcard.h
enabled_any alsa_indev alsa_outdev &&
check_lib2 alsa/asoundlib.h snd_pcm_htimestamp -lasound
-enabled jack_indev && check_lib2 jack/jack.h jack_client_open -ljack &&
check_func sem_timedwait &&
-check_func jack_port_get_latency_range -ljack
+if enabled jack_indev; then
+{ check_lib2 jack/jack.h jack_client_open -ljack &&
+ check_func jack_port_get_latency_range -ljack &&
+ enabled_any sem_timedwait dispatch_dispatch_h; } ||
+disable jack_indev
+fi
enabled_any sndio_indev sndio_outdev && check_lib2 sndio.h sio_open -lsndio
diff --git a/libavdevice/jack.c b/libavdevice/jack.c
index 9ecbf9e..b5b8666 100644
--- a/libavdevice/jack.c
+++ b/libavdevice/jack.c
@@ -35,6 +35,18 @@
#include "timefilter.h"
#include "avdevice.h"
+#if HAVE_DISPATCH_DISPATCH_H
+
+#include
+#define sem_t dispatch_semaphore_t
+#define sem_init(psem,x,val) *psem = dispatch_semaphore_create(val)
+#define sem_post(psem)dispatch_semaphore_signal(*psem)
+#define sem_wait(psem)dispatch_semaphore_wait(*psem,
DISPATCH_TIME_FOREVER)
+#define sem_timedwait(psem, val) dispatch_semaphore_wait(*psem,
dispatch_walltime(val, 0))
+#define sem_destroy(psem) dispatch_release(*psem)
+
+#endif /* HAVE_DISPATCH_DISPATCH_H */
+
/**
* Size of the internal FIFO buffers as a number of audio packets
*/
--
2.5.4 (Apple Git-61)
Finally took the time to take a look at this one, works on my machine (OSX
10.11.3) with the latest ffmpeg from git; would appreciate maybe someone else
to test it, see if it works on other people's machines as well, I don't see why
it shouldn't but just to be sure :)
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/libvpx: Fix high-bitrate colour spaces
Hi,
On Thu, Feb 18, 2016 at 3:30 PM, Carl Eugen Hoyos wrote:
> Please comment, Carl Eugen
> diff --git a/libavcodec/libvpx.c b/libavcodec/libvpx.c
> index a60d186..1e7010b 100644
> --- a/libavcodec/libvpx.c
> +++ b/libavcodec/libvpx.c
> @@ -46,14 +46,14 @@ static const enum AVPixelFormat vp9_pix_fmts_highbd[] = {
> AV_PIX_FMT_YUV422P,
> AV_PIX_FMT_YUV440P,
> AV_PIX_FMT_YUV444P,
> -AV_PIX_FMT_YUV420P10LE,
> -AV_PIX_FMT_YUV422P10LE,
> -AV_PIX_FMT_YUV440P10LE,
> -AV_PIX_FMT_YUV444P10LE,
> -AV_PIX_FMT_YUV420P12LE,
> -AV_PIX_FMT_YUV422P12LE,
> -AV_PIX_FMT_YUV440P12LE,
> -AV_PIX_FMT_YUV444P12LE,
> +AV_PIX_FMT_YUV420P10,
> +AV_PIX_FMT_YUV422P10,
> +AV_PIX_FMT_YUV440P10,
> +AV_PIX_FMT_YUV444P10,
> +AV_PIX_FMT_YUV420P12,
> +AV_PIX_FMT_YUV422P12,
> +AV_PIX_FMT_YUV440P12,
> +AV_PIX_FMT_YUV444P12,
> AV_PIX_FMT_NONE
> };
> #endif
>
> diff --git a/libavcodec/libvpx.c b/libavcodec/libvpx.c
> index a60d186..1e7010b 100644
> --- a/libavcodec/libvpx.c
> +++ b/libavcodec/libvpx.c
> @@ -46,14 +46,14 @@ static const enum AVPixelFormat vp9_pix_fmts_highbd[] = {
> AV_PIX_FMT_YUV422P,
> AV_PIX_FMT_YUV440P,
> AV_PIX_FMT_YUV444P,
> -AV_PIX_FMT_YUV420P10LE,
> -AV_PIX_FMT_YUV422P10LE,
> -AV_PIX_FMT_YUV440P10LE,
> -AV_PIX_FMT_YUV444P10LE,
> -AV_PIX_FMT_YUV420P12LE,
> -AV_PIX_FMT_YUV422P12LE,
> -AV_PIX_FMT_YUV440P12LE,
> -AV_PIX_FMT_YUV444P12LE,
> +AV_PIX_FMT_YUV420P10,
> +AV_PIX_FMT_YUV422P10,
> +AV_PIX_FMT_YUV440P10,
> +AV_PIX_FMT_YUV444P10,
> +AV_PIX_FMT_YUV420P12,
> +AV_PIX_FMT_YUV422P12,
> +AV_PIX_FMT_YUV440P12,
> +AV_PIX_FMT_YUV444P12,
> AV_PIX_FMT_NONE
> };
> #endif
>
The decoder won't change when built on a big-endian platform, so I don't think
this is correct.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/libvpx: fix support for RGB colorspace.
On Thu, Feb 18, 2016 at 3:10 PM, James Almer wrote: > On 2/18/2016 7:59 PM, Carl Eugen Hoyos wrote: >> +case AV_PIX_FMT_GBRP: >> +ctx->vpx_cs = VPX_CS_SRGB; > > This is only available since libvpx 1.4.0, so you need to wrap all this new > code inside some preprocessor checks. I think VPX_IMAGE_ABI_VERSION >= 3 > should do it, but better wait for James Zern for confirmation. That's correct. This would prevent the user from overriding the decision with unspecified/reserved, not sure it matters. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/libvpx: fix support for RGB colorspace.
On Thu, Feb 18, 2016 at 3:34 PM, Carl Eugen Hoyos wrote: >> Alternatively we could bump the minimum required version and remove most of >> the existing checks. 1.3.0 is pretty old by now and it would let us clean >> these files. > > I would prefer if this could be done independently (and afterwards). That would be fine by me. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/libvpx: fix support for RGB colorspace.
On Thu, Feb 18, 2016 at 3:02 PM, Hendrik Leppkes wrote: > On Thu, Feb 18, 2016 at 11:59 PM, Carl Eugen Hoyos wrote: >> On Thursday 18 February 2016 09:40:01 pm Nicolas George wrote: >>> Initial patch by Carl Eugen Hoyos. >>> >>> Fix trac ticket #5249. >> >> Patch with (automatic) support for 8, 10 and 12 bit gbr attached. >> >> Please comment, Carl Eugen > > This lacks the appropriate changes in libvpx.c to the supported pixel > formats for the encoder. > Also, please re-indent appropriately. If its not in this patch, it'll > never get done. > There was a historical preference not to do that, the developer docs still say something to that effect [1]. If the preference has changed then I'm OK with it. [1] http://ffmpeg.org/developer.html#Development-Policy "8. We refuse source indentation and other cosmetic changes if they are mixed with functional changes, such commits will be rejected and removed." ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/libvpx: Fix high-bitrate colour spaces
On Friday 19 February 2016 07:59:37 am James Zern wrote:
> The decoder won't change when built on a big-endian platform, so I don't
> think this is correct.
New patch attached.
Thank you, Carl Eugen
diff --git a/libavcodec/libvpx.c b/libavcodec/libvpx.c
index a60d186..1e7010b 100644
--- a/libavcodec/libvpx.c
+++ b/libavcodec/libvpx.c
@@ -46,14 +46,14 @@ static const enum AVPixelFormat vp9_pix_fmts_highbd[] = {
AV_PIX_FMT_YUV422P,
AV_PIX_FMT_YUV440P,
AV_PIX_FMT_YUV444P,
-AV_PIX_FMT_YUV420P10LE,
-AV_PIX_FMT_YUV422P10LE,
-AV_PIX_FMT_YUV440P10LE,
-AV_PIX_FMT_YUV444P10LE,
-AV_PIX_FMT_YUV420P12LE,
-AV_PIX_FMT_YUV422P12LE,
-AV_PIX_FMT_YUV440P12LE,
-AV_PIX_FMT_YUV444P12LE,
+AV_PIX_FMT_YUV420P10,
+AV_PIX_FMT_YUV422P10,
+AV_PIX_FMT_YUV440P10,
+AV_PIX_FMT_YUV444P10,
+AV_PIX_FMT_YUV420P12,
+AV_PIX_FMT_YUV422P12,
+AV_PIX_FMT_YUV440P12,
+AV_PIX_FMT_YUV444P12,
AV_PIX_FMT_NONE
};
#endif
diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
index b51bfa2..adbc6d0 100644
--- a/libavcodec/libvpxdec.c
+++ b/libavcodec/libvpxdec.c
@@ -108,10 +108,10 @@ static int set_pix_fmt(AVCodecContext *avctx, struct
vpx_image *img)
case VPX_IMG_FMT_I42016:
avctx->profile = FF_PROFILE_VP9_2;
if (img->bit_depth == 10) {
-avctx->pix_fmt = AV_PIX_FMT_YUV420P10LE;
+avctx->pix_fmt = AV_PIX_FMT_YUV420P10;
return 0;
} else if (img->bit_depth == 12) {
-avctx->pix_fmt = AV_PIX_FMT_YUV420P12LE;
+avctx->pix_fmt = AV_PIX_FMT_YUV420P12;
return 0;
} else {
return AVERROR_INVALIDDATA;
@@ -119,10 +119,10 @@ static int set_pix_fmt(AVCodecContext *avctx, struct
vpx_image *img)
case VPX_IMG_FMT_I42216:
avctx->profile = FF_PROFILE_VP9_3;
if (img->bit_depth == 10) {
-avctx->pix_fmt = AV_PIX_FMT_YUV422P10LE;
+avctx->pix_fmt = AV_PIX_FMT_YUV422P10;
return 0;
} else if (img->bit_depth == 12) {
-avctx->pix_fmt = AV_PIX_FMT_YUV422P12LE;
+avctx->pix_fmt = AV_PIX_FMT_YUV422P12;
return 0;
} else {
return AVERROR_INVALIDDATA;
@@ -131,10 +131,10 @@ static int set_pix_fmt(AVCodecContext *avctx, struct
vpx_image *img)
case VPX_IMG_FMT_I44016:
avctx->profile = FF_PROFILE_VP9_3;
if (img->bit_depth == 10) {
-avctx->pix_fmt = AV_PIX_FMT_YUV440P10LE;
+avctx->pix_fmt = AV_PIX_FMT_YUV440P10;
return 0;
} else if (img->bit_depth == 12) {
-avctx->pix_fmt = AV_PIX_FMT_YUV440P12LE;
+avctx->pix_fmt = AV_PIX_FMT_YUV440P12;
return 0;
} else {
return AVERROR_INVALIDDATA;
@@ -145,17 +145,17 @@ static int set_pix_fmt(AVCodecContext *avctx, struct
vpx_image *img)
if (img->bit_depth == 10) {
#if VPX_IMAGE_ABI_VERSION >= 3
avctx->pix_fmt = avctx->colorspace == AVCOL_SPC_RGB ?
- AV_PIX_FMT_GBRP10LE : AV_PIX_FMT_YUV444P10LE;
+ AV_PIX_FMT_GBRP10 : AV_PIX_FMT_YUV444P10;
#else
-avctx->pix_fmt = AV_PIX_FMT_YUV444P10LE;
+avctx->pix_fmt = AV_PIX_FMT_YUV444P10;
#endif
return 0;
} else if (img->bit_depth == 12) {
#if VPX_IMAGE_ABI_VERSION >= 3
avctx->pix_fmt = avctx->colorspace == AVCOL_SPC_RGB ?
- AV_PIX_FMT_GBRP12LE : AV_PIX_FMT_YUV444P12LE;
+ AV_PIX_FMT_GBRP12 : AV_PIX_FMT_YUV444P12;
#else
-avctx->pix_fmt = AV_PIX_FMT_YUV444P12LE;
+avctx->pix_fmt = AV_PIX_FMT_YUV444P12;
#endif
return 0;
} else {
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 8992497..8dce4bb 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -300,22 +300,22 @@ static int set_pix_fmt(AVCodecContext *avctx,
vpx_codec_caps_t codec_caps,
*img_fmt = VPX_IMG_FMT_I444;
return 0;
#ifdef VPX_IMG_FMT_HIGHBITDEPTH
-case AV_PIX_FMT_YUV420P10LE:
-case AV_PIX_FMT_YUV420P12LE:
+case AV_PIX_FMT_YUV420P10:
+case AV_PIX_FMT_YUV420P12:
if (codec_caps & VPX_CODEC_CAP_HIGHBITDEPTH) {
enccfg->g_bit_depth = enccfg->g_input_bit_depth =
-avctx->pix_fmt == AV_PIX_FMT_YUV420P10LE ? 10 : 12;
+avctx->pix_fmt == AV_PIX_FMT_YUV420P10 ? 10 : 12;
enccfg->g_profile = 2;
*img_fmt = VPX_IMG_FMT_I42016;
*flags |= VPX_CODEC_USE_HIGHBITDEPTH;
return 0;
}
break;
-case AV_PIX_FMT_YUV422P10LE:
-case AV_PIX_FMT_YUV422P12LE:
+case AV_PIX_FMT_YUV422P10:
+case AV_PIX_FMT_YUV422P12:
if (codec_caps & VPX_CODEC_CAP_HIGHBITDEPTH) {
enccfg->g_bit_depth = enccfg->g_input_bit_depth =
-avctx->pix_fmt == AV_PIX_FMT_YUV422P10L
Re: [FFmpeg-devel] [PATCH]lavc/libvpx: Fix high-bitrate colour spaces
On Thu, Feb 18, 2016 at 11:40 PM, Carl Eugen Hoyos wrote: > On Friday 19 February 2016 07:59:37 am James Zern wrote: > >> The decoder won't change when built on a big-endian platform, so I don't >> think this is correct. > > New patch attached. > Sorry, I meant all of it, high bitdepth is no different. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
