Re: [FFmpeg-devel] [PATCH v5 4/4 v2] lavf/utils: Normalize AVPacket.data to native endian in ff_get_packet_palette()
On 03/03/2016 08:29 AM, Mats Peterson wrote: Due to Morton Balint's recent addition of ff_standardize_creation_time(), the previous patch would fail. Please add this one before any more changes occur. In my book, using native uint32_t when dealing with the palette on muxing is clearly the most logical and cleanest way. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v5 4/4 v2] lavf/utils: Normalize AVPacket.data to native endian in ff_get_packet_palette()
Due to Morton Balint's recent addition of
ff_standardize_creation_time(), the previous patch would fail. Please
add this one before any more changes occur.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 08b75292ed7ede8de32bdecf5ec72fedc18b1aa9 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Thu, 3 Mar 2016 08:25:58 +0100
Subject: [PATCH v5 4/4 v2] lavf/utils: Normalize AVPacket.data to native endian in ff_get_packet_palette()
---
libavformat/internal.h |7 +--
libavformat/utils.c| 23 ---
2 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 63e0632..37a8591 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -588,9 +588,12 @@ int ff_reshuffle_raw_rgb(AVFormatContext *s, AVPacket **ppkt, AVCodecContext *en
*
* Use 0 for the ret parameter to check for side data only.
*
- * @param pkt pointer to the packet before calling ff_reshuffle_raw_rgb()
+ * @param pkt pointer to packet before calling ff_reshuffle_raw_rgb()
* @param ret return value from ff_reshuffle_raw_rgb(), or 0
+ * @param palette pointer to palette buffer
+ * @return negative error code or
+ * 1 if the packet has a palette, else 0
*/
-int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, const uint8_t **palette);
+int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, uint32_t *palette);
#endif /* AVFORMAT_INTERNAL_H */
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 85702dd..7c14725 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4782,18 +4782,27 @@ int ff_standardize_creation_time(AVFormatContext *s)
return ret;
}
-int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, const uint8_t **palette)
+int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, uint32_t *palette)
{
+uint8_t *side_data;
int size;
-*palette = av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, &size);
-if (*palette && size != AVPALETTE_SIZE) {
-av_log(s, AV_LOG_ERROR, "Invalid palette side data\n");
-return AVERROR_INVALIDDATA;
+side_data = av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, &size);
+if (side_data) {
+if (size != AVPALETTE_SIZE) {
+av_log(s, AV_LOG_ERROR, "Invalid palette side data\n");
+return AVERROR_INVALIDDATA;
+}
+memcpy(palette, side_data, AVPALETTE_SIZE);
+return 1;
}
-if (!*palette && ret == CONTAINS_PAL)
-*palette = pkt->data + pkt->size - AVPALETTE_SIZE;
+if (ret == CONTAINS_PAL) {
+int i;
+for (i = 0; i < AVPALETTE_COUNT; i++)
+palette[i] = AV_RL32(pkt->data + pkt->size - AVPALETTE_SIZE + i*4);
+return 1;
+}
return 0;
}
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 4/4] lavf/utils: Fix endianness in ff_get_packet_palette()
On 03/03/2016 07:22 AM, Mats Peterson wrote:
On 03/03/2016 07:15 AM, Mats Peterson wrote:
On 03/03/2016 06:52 AM, Mats Peterson wrote:
On 03/03/2016 06:39 AM, Mats Peterson wrote:
On 03/03/2016 06:33 AM, Mats Peterson wrote:
On 03/03/2016 03:05 AM, Michael Niedermayer wrote:
with this API each muxer must convert the palette from native endian
to whatever the format requires
feels a bit odd to extact the palette from AVPacket.data where its
stored as the container needs (for some containers) and then
Exactly for the reason that the AVPacket.data is stored in
"container-specific" (exclusively little-endian, i hope) format, it has
Well, exclusively little-endian in the case of raw nut, at least. That's
the only format that appends the palette to the video data in each frame
in the file, as far as I know.
Mats
___
By the way, would you mind telling me why the palette in AVPacket.data
is always little endian (regardless of using nut or not)? And where in
FFmpeg is conversion from native endian to little endian done?
Mats
___
I found it in av_image_copy_to_buffer() in libavutil/imgutils.c. I
suppose that's the right place:
if (desc->flags & AV_PIX_FMT_FLAG_PAL) {
uint32_t *d32 = (uint32_t *)dst;
for (i = 0; i<256; i++)
AV_WL32(d32 + i, AV_RN32(src_data[1] + 4*i));
}
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
So much more logical to convert this fixed little-endian storage in
AVPacket.data to native endian for use by the outside world.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 4/4] lavf/utils: Fix endianness in ff_get_packet_palette()
On 03/03/2016 07:15 AM, Mats Peterson wrote:
On 03/03/2016 06:52 AM, Mats Peterson wrote:
On 03/03/2016 06:39 AM, Mats Peterson wrote:
On 03/03/2016 06:33 AM, Mats Peterson wrote:
On 03/03/2016 03:05 AM, Michael Niedermayer wrote:
with this API each muxer must convert the palette from native endian
to whatever the format requires
feels a bit odd to extact the palette from AVPacket.data where its
stored as the container needs (for some containers) and then
Exactly for the reason that the AVPacket.data is stored in
"container-specific" (exclusively little-endian, i hope) format, it has
Well, exclusively little-endian in the case of raw nut, at least. That's
the only format that appends the palette to the video data in each frame
in the file, as far as I know.
Mats
___
By the way, would you mind telling me why the palette in AVPacket.data
is always little endian (regardless of using nut or not)? And where in
FFmpeg is conversion from native endian to little endian done?
Mats
___
I found it in av_image_copy_to_buffer() in libavutil/imgutils.c. I
suppose that's the right place:
if (desc->flags & AV_PIX_FMT_FLAG_PAL) {
uint32_t *d32 = (uint32_t *)dst;
for (i = 0; i<256; i++)
AV_WL32(d32 + i, AV_RN32(src_data[1] + 4*i));
}
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 4/4] lavf/utils: Fix endianness in ff_get_packet_palette()
On 03/03/2016 06:52 AM, Mats Peterson wrote: On 03/03/2016 06:39 AM, Mats Peterson wrote: On 03/03/2016 06:33 AM, Mats Peterson wrote: On 03/03/2016 03:05 AM, Michael Niedermayer wrote: with this API each muxer must convert the palette from native endian to whatever the format requires feels a bit odd to extact the palette from AVPacket.data where its stored as the container needs (for some containers) and then Exactly for the reason that the AVPacket.data is stored in "container-specific" (exclusively little-endian, i hope) format, it has Well, exclusively little-endian in the case of raw nut, at least. That's the only format that appends the palette to the video data in each frame in the file, as far as I know. Mats ___ By the way, would you mind telling me why the palette in AVPacket.data is always little endian (regardless of using nut or not)? And where in FFmpeg is conversion from native endian to little endian done? Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 4/4] lavf/utils: Fix endianness in ff_get_packet_palette()
On 03/03/2016 06:39 AM, Mats Peterson wrote: On 03/03/2016 06:33 AM, Mats Peterson wrote: On 03/03/2016 03:05 AM, Michael Niedermayer wrote: with this API each muxer must convert the palette from native endian to whatever the format requires feels a bit odd to extact the palette from AVPacket.data where its stored as the container needs (for some containers) and then Exactly for the reason that the AVPacket.data is stored in "container-specific" (exclusively little-endian, i hope) format, it has Well, exclusively little-endian in the case of raw nut, at least. That's the only format that appends the palette to the video data in each frame in the file, as far as I know. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 4/4] lavf/utils: Fix endianness in ff_get_packet_palette()
On 03/03/2016 06:33 AM, Mats Peterson wrote: On 03/03/2016 03:05 AM, Michael Niedermayer wrote: with this API each muxer must convert the palette from native endian to whatever the format requires feels a bit odd to extact the palette from AVPacket.data where its stored as the container needs (for some containers) and then Exactly for the reason that the AVPacket.data is stored in "container-specific" (exclusively little-endian, i hope) format, it has to be converted to some common denominator (native endian) when used with the various functions, in my book, especially in the case of muxing to another container format. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 4/4] lavf/utils: Fix endianness in ff_get_packet_palette()
On 03/03/2016 03:05 AM, Michael Niedermayer wrote: with this API each muxer must convert the palette from native endian to whatever the format requires feels a bit odd to extact the palette from AVPacket.data where its stored as the container needs (for some containers) and then convert that to RGBA in native int32 which the muxer then needs to convert back for storage What do you mean by "as the container needs"? I thought the endian of the AVPacket.data palette was fixed at little-endian? Are there differences in that area as well? This is getting really messy. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 4/4] lavf/utils: Fix endianness in ff_get_packet_palette()
On 03/03/2016 03:05 AM, Michael Niedermayer wrote:
On Thu, Mar 03, 2016 at 12:36:21AM +0100, Mats Peterson wrote:
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
internal.h |7 +--
utils.c| 23 ---
2 files changed, 21 insertions(+), 9 deletions(-)
3f86328b63621ddba1ee0730ce639010fc38aec3
0004-lavf-utils-Fix-endianness-in-ff_get_palette_packet.patch
From 75f98197bda12b486971d1d6cc139cb5d22b30ba Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Thu, 3 Mar 2016 00:29:32 +0100
Subject: [PATCH v5 4/4] lavf/utils: Fix endianness in ff_get_packet_palette()
---
libavformat/internal.h |7 +--
libavformat/utils.c| 23 ---
2 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 8e06655..e58d078 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -580,9 +580,12 @@ int ff_reshuffle_raw_rgb(AVFormatContext *s, AVPacket
**ppkt, AVCodecContext *en
*
* Use 0 for the ret parameter to check for side data only.
*
- * @param pkt pointer to the packet before calling ff_reshuffle_raw_rgb()
+ * @param pkt pointer to packet before calling ff_reshuffle_raw_rgb()
* @param ret return value from ff_reshuffle_raw_rgb(), or 0
+ * @param palette pointer to palette buffer
+ * @return negative error code or
+ 1 if the packet contains a palette, else 0
*/
-int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, const
uint8_t **palette);
+int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, uint32_t
*palette);
#endif /* AVFORMAT_INTERNAL_H */
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 771e878..9931e61 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4760,18 +4760,27 @@ int ff_parse_creation_time_metadata(AVFormatContext *s,
int64_t *timestamp, int
return 0;
}
-int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, const
uint8_t **palette)
+int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, uint32_t
*palette)
{
+uint8_t *side_data;
int size;
-*palette = av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, &size);
-if (*palette && size != AVPALETTE_SIZE) {
-av_log(s, AV_LOG_ERROR, "Invalid palette side data\n");
-return AVERROR_INVALIDDATA;
+side_data = av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, &size);
+if (side_data) {
+if (size != AVPALETTE_SIZE) {
+av_log(s, AV_LOG_ERROR, "Invalid palette side data\n");
+return AVERROR_INVALIDDATA;
+}
+memcpy(palette, side_data, AVPALETTE_SIZE);
+return 1;
}
-if (!*palette && ret == CONTAINS_PAL)
-*palette = pkt->data + pkt->size - AVPALETTE_SIZE;
+if (ret == CONTAINS_PAL) {
+int i;
+for (i = 0; i < AVPALETTE_COUNT; i++)
+palette[i] = AV_RL32(pkt->data + pkt->size - AVPALETTE_SIZE + i*4);
+return 1;
+}
return 0;
}
with this API each muxer must convert the palette from native endian
to whatever the format requires
I don't understand what you mean here really.
feels a bit odd to extact the palette from AVPacket.data where its
stored as the container needs (for some containers) and then
convert that to RGBA in native int32 which the muxer then needs to
convert back for storage
I don't think so. Since any palette side data, as you said yourself,
uses native endian, I have made this function return the palette in
native order "to the outside world". It's more logical than having to
deal with the (for some weird reason) little-endian order of the
AVPacket.data palette in certain places.
The muxer will have to convert it to what the storage needs for the
specific file format, whether it's big- or little endian. That's
irrelevant of the native endian of the palette in FFmpeg. These types of
conversions (using av_wl32() or av_wb32() or similar) are done all over
the place already, so it's nothing new.
I hope I have understood you correctly.
Mats
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add test foravpriv_get_trc_function_from_trc function
Passes on my mac ~/Documents/projects/FFmpeg/libavutil (master ✘)✭ ᐅ file color_utils-test color_utils-test: Mach-O executable i386 ~/Documents/projects/FFmpeg/libavutil (master ✘)✭ ᐅ cd .. ~/Documents/projects/FFmpeg (master ✘)✭ ᐅ make fate-color_utils TESTcolor_utils Will test this on my ubuntu machine and make a new patch. On Wed, Mar 2, 2016 at 7:44 PM, Michael Niedermayer wrote: > On Wed, Mar 02, 2016 at 06:36:26PM -0800, NagaChaitanya Vellanki wrote: > > --- > > libavutil/Makefile | 1 + > > libavutil/color_utils.c| 29 + > > tests/fate/libavutil.mak | 4 + > > tests/ref/fate/color_utils | 285 > + > > 4 files changed, 319 insertions(+) > > create mode 100644 tests/ref/fate/color_utils > > fails on x86-32 > --- ffmpeg/tests/ref/fate/color_utils 2016-03-03 04:07:54.150126182 +0100 > +++ tests/data/fate/color_utils 2016-03-03 04:43:57.406171756 +0100 > @@ -172,7 +172,7 @@ > AVColorTransferCharacteristic=12 calling func(-0.10) > expected=-0.206787 > AVColorTransferCharacteristic=12 calling func(-0.018054) > expected=-0.109049 > AVColorTransferCharacteristic=12 calling func(-0.01) > expected=-0.089387 > -AVColorTransferCharacteristic=12 calling func(-0.004500) > expected=-0.069898 > +AVColorTransferCharacteristic=12 calling func(-0.004500) > expected=-0.020250 > AVColorTransferCharacteristic=12 calling func(0.00) expected=0.00 > AVColorTransferCharacteristic=12 calling func(0.003162) expected=0.014230 > AVColorTransferCharacteristic=12 calling func(0.005000) expected=0.022500 > Test color_utils failed. Look at tests/data/fate/color_utils.err for > details. > make: *** [fate-color_utils] Error 1 > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > When the tyrant has disposed of foreign enemies by conquest or treaty, and > there is nothing more to fear from them, then he is always stirring up > some war or other, in order that the people may require a leader. -- Plato > > ___ > 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] videotoolboxenc: Fix compile failure on OS X 10.10
> ---
> libavcodec/videotoolboxenc.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> index bbecb24..342c83c 100644
> --- a/libavcodec/videotoolboxenc.c
> +++ b/libavcodec/videotoolboxenc.c
> @@ -32,6 +32,14 @@
> #include "internal.h"
> #include
>
> +#ifndef CM_NULLABLE
> +#define CM_NULLABLE
> +#endif
> +
> +#ifndef CV_NULLABLE
> +#define CV_NULLABLE
> +#endif
> +
> typedef enum VT_H264Profile {
> H264_PROF_AUTO,
> H264_PROF_BASELINE,
> --
> 2.7.2
Never mind; use Rodger's patch instead.
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fate: fix filter-hls tests dependencies
Signed-off-by: James Almer
---
tests/fate/filter-audio.mak| 15 +--
tests/ref/fate/{filter-hls2 => filter-hls} | 0
2 files changed, 9 insertions(+), 6 deletions(-)
rename tests/ref/fate/{filter-hls2 => filter-hls} (100%)
diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index fee48fb..b7bc979 100644
--- a/tests/fate/filter-audio.mak
+++ b/tests/fate/filter-audio.mak
@@ -3,12 +3,15 @@ fate-filter-adelay: tests/data/asynth-44100-2.wav
fate-filter-adelay: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
fate-filter-adelay: CMD = framecrc -i $(SRC) -af adelay=42
-FATE_AFILTER-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER
AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-filter-hls1
fate-filter-hls2
-fate-filter-hls1: CMD = run ffmpeg -f lavfi -i
"aevalsrc=cos(2*PI*t)*sin(2*PI*(440+4*t)*t)::d=20" -f segment -segment_time 10
-map 0 -flags +bitexact -codec:a mp2fixed \
- -segment_list
$(TARGET_PATH)/tests/data/hls-list.m3u8
$(TARGET_PATH)/tests/data/hls-out-%03d.ts
-fate-filter-hls1: REF = /dev/null
-fate-filter-hls2: fate-filter-hls1
-fate-filter-hls2: CMD = framecrc -flags +bitexact -i
$(TARGET_PATH)/tests/data/hls-list.m3u8
+tests/data/hls-list.m3u8: TAG = GEN
+tests/data/hls-list.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
+ $(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
+-f lavfi -i "aevalsrc=cos(2*PI*t)*sin(2*PI*(440+4*t)*t)::d=20" -f
segment -segment_time 10 -map 0 -flags +bitexact -codec:a mp2fixed \
+-segment_list $(TARGET_PATH)/$@ -y
$(TARGET_PATH)/tests/data/hls-out-%03d.ts 2>/dev/null
+
+FATE_AFILTER-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER
AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-filter-hls
+fate-filter-hls: tests/data/hls-list.m3u8
+fate-filter-hls: CMD = framecrc -flags +bitexact -i
$(TARGET_PATH)/tests/data/hls-list.m3u8
FATE_AMIX += fate-filter-amix-simple
fate-filter-amix-simple: CMD = ffmpeg -filter_complex amix -i $(SRC) -ss 3 -i
$(SRC1) -f f32le -
diff --git a/tests/ref/fate/filter-hls2 b/tests/ref/fate/filter-hls
similarity index 100%
rename from tests/ref/fate/filter-hls2
rename to tests/ref/fate/filter-hls
--
2.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/videotoolboxenc: remove *_NULLABLE annotations; fixes pre-10.11 build
> On Mar 3, 2016, at 11:46 AM, Rodger Combs wrote:
>
> These macros were added in OS X 10.11, and the file compiles without warnings
> on both 10.10 and 10.11 with them removed.
>
> Thanks to mark4o on IRC for pointing out the failure and testing the patch.
Lgtm - thanks for the quick fix.
> ---
> libavcodec/videotoolboxenc.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> index bbecb24..3ed1f64 100644
> --- a/libavcodec/videotoolboxenc.c
> +++ b/libavcodec/videotoolboxenc.c
> @@ -317,11 +317,11 @@ static int set_extradata(AVCodecContext *avctx,
> CMSampleBufferRef sample_buffer)
> }
>
> static void vtenc_output_callback(
> -void *CM_NULLABLE ctx,
> +void *ctx,
> void *sourceFrameCtx,
> OSStatus status,
> VTEncodeInfoFlags flags,
> -CM_NULLABLE CMSampleBufferRef sample_buffer)
> +CMSampleBufferRef sample_buffer)
> {
> AVCodecContext *avctx = ctx;
> VTEncContext *vtctx = avctx->priv_data;
> @@ -975,11 +975,11 @@ static int get_cv_pixel_info(
> #if !TARGET_OS_IPHONE
> //Not used on iOS - frame is always copied.
> static void free_avframe(
> -void *CV_NULLABLE release_ctx,
> -const void *CV_NULLABLE data,
> -size_t size,
> -size_t plane_count,
> -const void *CV_NULLABLE plane_addresses[])
> +void *release_ctx,
> +const void *data,
> +size_t size,
> +size_t plane_count,
> +const void *plane_addresses[])
> {
> AVFrame *frame = release_ctx;
> av_frame_free(&frame);
> --
> 2.7.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/videotoolboxenc: remove *_NULLABLE annotations; fixes pre-10.11 build
These macros were added in OS X 10.11, and the file compiles without warnings
on both 10.10 and 10.11 with them removed.
Thanks to mark4o on IRC for pointing out the failure and testing the patch.
---
libavcodec/videotoolboxenc.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index bbecb24..3ed1f64 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -317,11 +317,11 @@ static int set_extradata(AVCodecContext *avctx,
CMSampleBufferRef sample_buffer)
}
static void vtenc_output_callback(
-void *CM_NULLABLE ctx,
+void *ctx,
void *sourceFrameCtx,
OSStatus status,
VTEncodeInfoFlags flags,
-CM_NULLABLE CMSampleBufferRef sample_buffer)
+CMSampleBufferRef sample_buffer)
{
AVCodecContext *avctx = ctx;
VTEncContext *vtctx = avctx->priv_data;
@@ -975,11 +975,11 @@ static int get_cv_pixel_info(
#if !TARGET_OS_IPHONE
//Not used on iOS - frame is always copied.
static void free_avframe(
-void *CV_NULLABLE release_ctx,
-const void *CV_NULLABLE data,
-size_t size,
-size_t plane_count,
-const void *CV_NULLABLE plane_addresses[])
+void *release_ctx,
+const void *data,
+size_t size,
+size_t plane_count,
+const void *plane_addresses[])
{
AVFrame *frame = release_ctx;
av_frame_free(&frame);
--
2.7.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add test foravpriv_get_trc_function_from_trc function
On Wed, Mar 02, 2016 at 06:36:26PM -0800, NagaChaitanya Vellanki wrote: > --- > libavutil/Makefile | 1 + > libavutil/color_utils.c| 29 + > tests/fate/libavutil.mak | 4 + > tests/ref/fate/color_utils | 285 > + > 4 files changed, 319 insertions(+) > create mode 100644 tests/ref/fate/color_utils fails on x86-32 --- ffmpeg/tests/ref/fate/color_utils 2016-03-03 04:07:54.150126182 +0100 +++ tests/data/fate/color_utils 2016-03-03 04:43:57.406171756 +0100 @@ -172,7 +172,7 @@ AVColorTransferCharacteristic=12 calling func(-0.10) expected=-0.206787 AVColorTransferCharacteristic=12 calling func(-0.018054) expected=-0.109049 AVColorTransferCharacteristic=12 calling func(-0.01) expected=-0.089387 -AVColorTransferCharacteristic=12 calling func(-0.004500) expected=-0.069898 +AVColorTransferCharacteristic=12 calling func(-0.004500) expected=-0.020250 AVColorTransferCharacteristic=12 calling func(0.00) expected=0.00 AVColorTransferCharacteristic=12 calling func(0.003162) expected=0.014230 AVColorTransferCharacteristic=12 calling func(0.005000) expected=0.022500 Test color_utils failed. Look at tests/data/fate/color_utils.err for details. make: *** [fate-color_utils] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] videotoolboxenc: Fix compile failure on OS X 10.10
---
libavcodec/videotoolboxenc.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index bbecb24..342c83c 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -32,6 +32,14 @@
#include "internal.h"
#include
+#ifndef CM_NULLABLE
+#define CM_NULLABLE
+#endif
+
+#ifndef CV_NULLABLE
+#define CV_NULLABLE
+#endif
+
typedef enum VT_H264Profile {
H264_PROF_AUTO,
H264_PROF_BASELINE,
--
2.7.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add filter-hls
On Tue, Mar 01, 2016 at 04:59:46AM +0100, Michael Niedermayer wrote: > On Tue, Mar 01, 2016 at 12:32:27AM -0300, James Almer wrote: > > On 3/1/2016 12:24 AM, Michael Niedermayer wrote: > > > On Tue, Mar 01, 2016 at 12:17:33AM -0300, James Almer wrote: > > >> On 2/29/2016 11:47 PM, Michael Niedermayer wrote: > > >>> +fate-filter-hls2: tests/data/hls-list.m3u8 > > >> > > >> Why not just add fate-filter-hls1 as dep here, and get rid of the m3u8 > > >> target above? > > > > > > i think that isnt correct > > > consider that the m3u8 has been build previously and the user runs > > > make fate-filter-hls2 > > > the hls1 test should not run in that case, its not needed > > > > Doesn't seem to be the case, though. At least not on msys2/mingw64: > > ok, simpliied as you suggested then ... and applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add test foravpriv_get_trc_function_from_trc function
---
libavutil/Makefile | 1 +
libavutil/color_utils.c| 29 +
tests/fate/libavutil.mak | 4 +
tests/ref/fate/color_utils | 285 +
4 files changed, 319 insertions(+)
create mode 100644 tests/ref/fate/color_utils
diff --git a/libavutil/Makefile b/libavutil/Makefile
index a4d79cd..934564f 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -176,6 +176,7 @@ TESTPROGS = adler32
\
bprint \
cast5 \
camellia\
+color_utils \
cpu \
crc \
des \
diff --git a/libavutil/color_utils.c b/libavutil/color_utils.c
index b68b402..0ee1dea 100644
--- a/libavutil/color_utils.c
+++ b/libavutil/color_utils.c
@@ -21,6 +21,7 @@
#include
#include
+#include "common.h"
#include "libavutil/color_utils.h"
#include "libavutil/pixfmt.h"
@@ -216,3 +217,31 @@ avpriv_trc_function avpriv_get_trc_function_from_trc(enum
AVColorTransferCharact
}
return func;
}
+
+#ifdef TEST
+// LCOV_EXCL_START
+
+int main(int argc, char *argv[])
+{
+ int i, j;
+ double test_data[] = {
+ -0.1, -0.018053968510807, -0.01, -0.0045, 0.0, 0.00316227760, 0.005,
+ 0.009, 0.015, 0.1, 1.0, 52.37, 125.098765, 1999.11123, 6945.443,
+ 15123.4567, 19845.88923, 98678.4231, 9.88
+ };
+
+ for(i = 0; i < AVCOL_TRC_NB; i++) {
+ avpriv_trc_function func = avpriv_get_trc_function_from_trc(i);
+ for(j = 0; j < FF_ARRAY_ELEMS(test_data); j++) {
+ if(func != NULL) {
+ double result = func(test_data[j]);
+ printf("AVColorTransferCharacteristic=%d calling func(%f)
expected=%f\n",
+ i, test_data[j], result);
+ }
+ }
+ }
+
+}
+
+// LCOV_EXCL_STOP
+#endif
diff --git a/tests/fate/libavutil.mak b/tests/fate/libavutil.mak
index 022ae6a..a89bc1d 100644
--- a/tests/fate/libavutil.mak
+++ b/tests/fate/libavutil.mak
@@ -48,6 +48,10 @@ FATE_LIBAVUTIL += fate-crc
fate-crc: libavutil/crc-test$(EXESUF)
fate-crc: CMD = run libavutil/crc-test
+FATE_LIBAVUTIL += fate-color_utils
+fate-color_utils: libavutil/color_utils-test$(EXESUF)
+fate-color_utils: CMD = run libavutil/color_utils-test
+
FATE_LIBAVUTIL += fate-des
fate-des: libavutil/des-test$(EXESUF)
fate-des: CMD = run libavutil/des-test
diff --git a/tests/ref/fate/color_utils b/tests/ref/fate/color_utils
new file mode 100644
index 000..a8933ff
--- /dev/null
+++ b/tests/ref/fate/color_utils
@@ -0,0 +1,285 @@
+AVColorTransferCharacteristic=1 calling func(-0.10) expected=0.00
+AVColorTransferCharacteristic=1 calling func(-0.018054) expected=0.00
+AVColorTransferCharacteristic=1 calling func(-0.01) expected=0.00
+AVColorTransferCharacteristic=1 calling func(-0.004500) expected=0.00
+AVColorTransferCharacteristic=1 calling func(0.00) expected=0.00
+AVColorTransferCharacteristic=1 calling func(0.003162) expected=0.014230
+AVColorTransferCharacteristic=1 calling func(0.005000) expected=0.022500
+AVColorTransferCharacteristic=1 calling func(0.009000) expected=0.040500
+AVColorTransferCharacteristic=1 calling func(0.015000) expected=0.067500
+AVColorTransferCharacteristic=1 calling func(0.10) expected=0.290748
+AVColorTransferCharacteristic=1 calling func(1.00) expected=1.00
+AVColorTransferCharacteristic=1 calling func(52.37) expected=6.427531
+AVColorTransferCharacteristic=1 calling func(125.098765) expected=9.558517
+AVColorTransferCharacteristic=1 calling func(1999.111230) expected=33.512490
+AVColorTransferCharacteristic=1 calling func(6945.443000) expected=58.768794
+AVColorTransferCharacteristic=1 calling func(15123.456700) expected=83.452916
+AVColorTransferCharacteristic=1 calling func(19845.889230) expected=94.321297
+AVColorTransferCharacteristic=1 calling func(98678.423100) expected=194.219568
+AVColorTransferCharacteristic=1 calling func(9.88) expected=195.386306
+AVColorTransferCharacteristic=4 calling func(-0.10) expected=0.00
+AVColorTransferCharacteristic=4 calling func(-0.018054) expected=0.00
+AVColorTransferCharacteristic=4 calling func(-0.01) expected=0.00
+AVColorTransferCharacteristic=4 calling func(-0.004500) expected=0.00
+AVColorTransferCharacteristic=4 calling func(0.00) expected=0.00
+AVColorTransferCharacteristic=4 calling func(0.003162) expected=0.073053
+AVColorTransferCharacteristic=4 calling func(0.005000) expected=0.089966
+AVColorTransferCharacteristic=4 calling func(0.009000) expected=0.117520
+AVColorTransferChara
Re: [FFmpeg-devel] [PATCH] Add test foravpriv_get_trc_function_from_trc function
Sending in the new patch :-).
On Wed, Mar 2, 2016 at 5:20 PM, Michael Niedermayer
wrote:
> On Wed, Mar 02, 2016 at 04:35:08PM -0800, NagaChaitanya Vellanki wrote:
> > ---
> > libavutil/Makefile | 1 +
> > libavutil/color_utils.c| 65
> ++
> > tests/fate/libavutil.mak | 4 +++
> > tests/ref/fate/color_utils | 38 +++
> > 4 files changed, 108 insertions(+)
> > create mode 100644 tests/ref/fate/color_utils
> >
> > diff --git a/libavutil/Makefile b/libavutil/Makefile
> > index a4d79cd..934564f 100644
> > --- a/libavutil/Makefile
> > +++ b/libavutil/Makefile
> > @@ -176,6 +176,7 @@ TESTPROGS = adler32
>\
> > bprint
> \
> > cast5
> \
> > camellia
> \
> > +color_utils
> \
> > cpu
> \
> > crc
> \
> > des
> \
> > diff --git a/libavutil/color_utils.c b/libavutil/color_utils.c
> > index b68b402..e53f408 100644
> > --- a/libavutil/color_utils.c
> > +++ b/libavutil/color_utils.c
> > @@ -21,6 +21,7 @@
> > #include
> > #include
> >
> > +#include "common.h"
> > #include "libavutil/color_utils.h"
> > #include "libavutil/pixfmt.h"
> >
> > @@ -216,3 +217,67 @@ avpriv_trc_function
> avpriv_get_trc_function_from_trc(enum AVColorTransferCharact
> > }
> > return func;
> > }
> > +
> > +#ifdef TEST
> > +// LCOV_EXCL_START
> > +
> > +int main(int argc, char *argv[])
> > +{
> > + int i;
> > + struct test {
> > + enum AVColorTransferCharacteristic trc;
> > + const char* func_name;
> > + double arg;
> > + double result;
> > + } tests[] = {
> > + { AVCOL_TRC_BT709, "avpriv_trc_bt709", -0.01, 0.0 },
> > + { AVCOL_TRC_SMPTE170M, "avpriv_trc_bt709", 0.005, 0.022500 },
> > + { AVCOL_TRC_BT2020_10, "avpriv_trc_bt709", 0.015, 0.067500 },
> > + { AVCOL_TRC_BT2020_12, "avpriv_trc_bt709", 1.0, 1.0 },
> > + { AVCOL_TRC_BT2020_12, "avpriv_trc_bt709", 15123.4567, 83.452916
> },
> > + { AVCOL_TRC_GAMMA22, "avpriv_trc_gamma22", -0.01, 0.0 },
> > + { AVCOL_TRC_GAMMA22, "avpriv_trc_gamma22", 1.0, 1.0 },
> > + { AVCOL_TRC_GAMMA22, "avpriv_trc_gamma22", 125.098765, 8.980424 },
> > + { AVCOL_TRC_GAMMA28, "avpriv_trc_gamma28", -0.01, 0.0 },
> > + { AVCOL_TRC_GAMMA28, "avpriv_trc_gamma28", 1.0, 1.0 },
> > + { AVCOL_TRC_GAMMA28, "avpriv_trc_gamma28", 9.88,
> 61.054001 },
> > + { AVCOL_TRC_SMPTE240M, "avpriv_trc_smpte240M", -0.01, 0.0 },
> > + { AVCOL_TRC_SMPTE240M, "avpriv_trc_smpte240M", 0.015, 0.06 },
> > + { AVCOL_TRC_LINEAR, "avpriv_trc_linear", 0.0, 0.0 },
> > + { AVCOL_TRC_LINEAR, "avpriv_trc_linear", 0.1, 0.1 },
> > + { AVCOL_TRC_LINEAR, "avpriv_trc_linear", -0.1, -0.1 },
> > + { AVCOL_TRC_LOG, "avpriv_trc_log", 0.009, 0.0 },
> > + { AVCOL_TRC_LOG, "avpriv_trc_log", 1.0, 1.0 },
> > + { AVCOL_TRC_LOG, "avpriv_trc_log", 98678.4231, 3.497111 },
> > + { AVCOL_TRC_LOG_SQRT, "avpriv_trc_log_sqrt", 0.00316227760, 0.0 },
> > + { AVCOL_TRC_LOG_SQRT, "avpriv_trc_log_sqrt", 1.0, 1.0 },
> > + { AVCOL_TRC_LOG_SQRT, "avpriv_trc_log_sqrt", 19845.88923,
> 2.719068 },
> > + { AVCOL_TRC_IEC61966_2_4, "avpriv_trc_iec61966_2_4", 0.0, 0.0 },
> > + { AVCOL_TRC_IEC61966_2_4, "avpriv_trc_iec61966_2_4",
> -0.018053968510807, -0.081243 },
> > + { AVCOL_TRC_IEC61966_2_4, "avpriv_trc_iec61966_2_4", 0.015,
> 0.067500 },
> > + { AVCOL_TRC_IEC61966_2_4, "avpriv_trc_iec61966_2_4", 98245.76983,
> 193.835711 },
> > + { AVCOL_TRC_BT1361_ECG, "avpriv_trc_bt1361", 0.0, 0.0 },
> > + { AVCOL_TRC_BT1361_ECG, "avpriv_trc_bt1361", -0.0045, -0.069898 },
> > + { AVCOL_TRC_BT1361_ECG, "avpriv_trc_bt1361", 0.015, 0.067500 },
> > + { AVCOL_TRC_BT1361_ECG, "avpriv_trc_bt1361", 1999.11123,
> 33.512490 },
> > + { AVCOL_TRC_IEC61966_2_1, "avpriv_trc_iec61966_2_1", 0.0, 0.0 },
> > + { AVCOL_TRC_IEC61966_2_1, "avpriv_trc_iec61966_2_1", 0.015,
> 0.128354 },
> > + { AVCOL_TRC_IEC61966_2_1, "avpriv_trc_iec61966_2_1", 6945.443,
> 42.013863 },
> > + { AVCOL_TRC_SMPTEST2084, "avpriv_trc_smpte_st2084", -0.01, 0.0 },
> > + { AVCOL_TRC_SMPTEST2084, "avpriv_trc_smpte_st2084", 0.0, 0.01
> },
> > + { AVCOL_TRC_SMPTEST428_1, "avpriv_trc_smpte_st428_1", -0.01, 0.0
> },
> > + { AVCOL_TRC_SMPTEST428_1, "avpriv_trc_smpte_st428_1", 52.37,
> 4.432321 },
> > + { AVCOL_TRC_SMPTEST428_1, "avpriv_trc_smpte_st428_1", 0.0, 0.0 }
>
> this can be simplified, you dont need to list the results explicitly
> nor the functions or enum values and the testpoints can be the same
> for all
>
>
> for (i = 0; i avpriv_trc_function func = avpriv_get_trc_function_from_trc(i);
> for (j = 0; FF_ARRAY_ELEMS(testpoints); j++) {
> double result = func(testpoints[j]);
> printf(...
> }
> }
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040
Re: [FFmpeg-devel] [PATCH] tests/gapless: add gapless aac tests
On Thu, Mar 03, 2016 at 02:27:52AM +0100, Marton Balint wrote: > Signed-off-by: Marton Balint > --- > tests/fate/gapless.mak | 3 +++ > tests/ref/fate/gapless-aac | 5 + > 2 files changed, 8 insertions(+) > create mode 100644 tests/ref/fate/gapless-aac seems to fail on x86-32 --- ffmpeg/tests/ref/fate/gapless-aac 2016-03-03 03:06:35.306048679 +0100 +++ tests/data/fate/gapless-aac 2016-03-03 03:11:56.286055441 +0100 @@ -1,5 +1,5 @@ 9459e7dc74af1b451eb890686f04f262 *tests/data/fate/gapless-aac.out-1 -d3c3c4ea121b3f3b8a346a168d2fec0e +d00bed4d4a83ce1addb92c075b2fcaaf 9459e7dc74af1b451eb890686f04f262 *tests/data/fate/gapless-aac.out-2 -d3c3c4ea121b3f3b8a346a168d2fec0e +d00bed4d4a83ce1addb92c075b2fcaaf 63dd86b78c8fbd22a99bf88583256bfe *tests/data/fate/gapless-aac.out-3 Test gapless-aac failed. Look at tests/data/fate/gapless-aac.err for details. make: *** [fate-gapless-aac] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 4/4] lavf/utils: Fix endianness in ff_get_packet_palette()
On Thu, Mar 03, 2016 at 12:36:21AM +0100, Mats Peterson wrote:
>
> --
> Mats Peterson
> http://matsp888.no-ip.org/~mats/
> internal.h |7 +--
> utils.c| 23 ---
> 2 files changed, 21 insertions(+), 9 deletions(-)
> 3f86328b63621ddba1ee0730ce639010fc38aec3
> 0004-lavf-utils-Fix-endianness-in-ff_get_palette_packet.patch
> From 75f98197bda12b486971d1d6cc139cb5d22b30ba Mon Sep 17 00:00:00 2001
> From: Mats Peterson
> Date: Thu, 3 Mar 2016 00:29:32 +0100
> Subject: [PATCH v5 4/4] lavf/utils: Fix endianness in ff_get_packet_palette()
>
> ---
> libavformat/internal.h |7 +--
> libavformat/utils.c| 23 ---
> 2 files changed, 21 insertions(+), 9 deletions(-)
>
> diff --git a/libavformat/internal.h b/libavformat/internal.h
> index 8e06655..e58d078 100644
> --- a/libavformat/internal.h
> +++ b/libavformat/internal.h
> @@ -580,9 +580,12 @@ int ff_reshuffle_raw_rgb(AVFormatContext *s, AVPacket
> **ppkt, AVCodecContext *en
> *
> * Use 0 for the ret parameter to check for side data only.
> *
> - * @param pkt pointer to the packet before calling ff_reshuffle_raw_rgb()
> + * @param pkt pointer to packet before calling ff_reshuffle_raw_rgb()
> * @param ret return value from ff_reshuffle_raw_rgb(), or 0
> + * @param palette pointer to palette buffer
> + * @return negative error code or
> + 1 if the packet contains a palette, else 0
> */
> -int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, const
> uint8_t **palette);
> +int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret,
> uint32_t *palette);
>
> #endif /* AVFORMAT_INTERNAL_H */
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 771e878..9931e61 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -4760,18 +4760,27 @@ int ff_parse_creation_time_metadata(AVFormatContext
> *s, int64_t *timestamp, int
> return 0;
> }
>
> -int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, const
> uint8_t **palette)
> +int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret,
> uint32_t *palette)
> {
> +uint8_t *side_data;
> int size;
>
> -*palette = av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, &size);
> -if (*palette && size != AVPALETTE_SIZE) {
> -av_log(s, AV_LOG_ERROR, "Invalid palette side data\n");
> -return AVERROR_INVALIDDATA;
> +side_data = av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, &size);
> +if (side_data) {
> +if (size != AVPALETTE_SIZE) {
> +av_log(s, AV_LOG_ERROR, "Invalid palette side data\n");
> +return AVERROR_INVALIDDATA;
> +}
> +memcpy(palette, side_data, AVPALETTE_SIZE);
> +return 1;
> }
>
> -if (!*palette && ret == CONTAINS_PAL)
> -*palette = pkt->data + pkt->size - AVPALETTE_SIZE;
> +if (ret == CONTAINS_PAL) {
> +int i;
> +for (i = 0; i < AVPALETTE_COUNT; i++)
> +palette[i] = AV_RL32(pkt->data + pkt->size - AVPALETTE_SIZE +
> i*4);
> +return 1;
> +}
>
> return 0;
> }
with this API each muxer must convert the palette from native endian
to whatever the format requires
feels a bit odd to extact the palette from AVPacket.data where its
stored as the container needs (for some containers) and then
convert that to RGBA in native int32 which the muxer then needs to
convert back for storage
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
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/y4m: fix seeking in partial files
On Wed, Mar 02, 2016 at 08:59:34PM +0100, Paul B Mahol wrote:
> Hi,
>
> patch attached.
> yuv4mpegdec.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
> 3e38c18c187adfbc6aa88e52c9e01177de126847
> 0001-avformat-yuv4mpegdec-fix-seeking-for-partial-files.patch
> From af75cff37a296072fad21648459b4e005ce1afc6 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Wed, 2 Mar 2016 20:56:01 +0100
> Subject: [PATCH] avformat/yuv4mpegdec: fix seeking for partial files
>
> Signed-off-by: Paul B Mahol
> ---
> libavformat/yuv4mpegdec.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libavformat/yuv4mpegdec.c b/libavformat/yuv4mpegdec.c
> index ea1ae25..5d338c2 100644
> --- a/libavformat/yuv4mpegdec.c
> +++ b/libavformat/yuv4mpegdec.c
> @@ -307,8 +307,7 @@ static int yuv4_read_packet(AVFormatContext *s, AVPacket
> *pkt)
> static int yuv4_read_seek(AVFormatContext *s, int stream_index,
>int64_t pts, int flags)
> {
> -avio_seek(s->pb, pts * s->packet_size + s->internal->data_offset,
> SEEK_SET);
> -return 0;
> +return avio_seek(s->pb, pts * s->packet_size + s->internal->data_offset,
> SEEK_SET);
breaks fate
--- ./tests/ref/seek/lavf-yuv4mpeg 2016-03-02 14:28:47.297090793 +0100
+++ tests/data/fate/seek-lavf-yuv4mpeg 2016-03-03 02:32:02.286005006 +0100
@@ -1,53 +1,45 @@
ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 64
size:152064
-ret: 0 st:-1 flags:0 ts:-1.00
-ret: 0 st: 0 flags:1 dts: 0.04 pts: 0.04 pos: 152134
size:152064
+ret:-1 st:-1 flags:0 ts:-1.00
ret: 0 st:-1 flags:1 ts: 1.894167
ret:-EOF
ret: 0 st: 0 flags:0 ts: 0.80
ret: 0 st: 0 flags:1 dts: 0.80 pts: 0.80 pos:3041464
size:152064
-ret: 0 st: 0 flags:1 ts:-0.32
-ret: 0 st: 0 flags:1 dts: 0.84 pts: 0.84 pos:3193534
size:152064
+ret:-1 st: 0 flags:1 ts:-0.32
ret: 0 st:-1 flags:0 ts: 2.576668
ret:-EOF
ret: 0 st:-1 flags:1 ts: 1.470835
ret:-EOF
ret: 0 st: 0 flags:0 ts: 0.36
ret: 0 st: 0 flags:1 dts: 0.36 pts: 0.36 pos:1368694
size:152064
-ret: 0 st: 0 flags:1 ts:-0.76
-ret: 0 st: 0 flags:1 dts: 0.40 pts: 0.40 pos:1520764
size:152064
+ret:-1 st: 0 flags:1 ts:-0.76
ret: 0 st:-1 flags:0 ts: 2.153336
ret:-EOF
ret: 0 st:-1 flags:1 ts: 1.047503
ret:-EOF
-ret: 0 st: 0 flags:0 ts:-0.04
-ret:-EOF
+ret:-1 st: 0 flags:0 ts:-0.04
ret: 0 st: 0 flags:1 ts: 2.84
ret:-EOF
ret: 0 st:-1 flags:0 ts: 1.730004
ret:-EOF
ret: 0 st:-1 flags:1 ts: 0.624171
ret: 0 st: 0 flags:1 dts: 0.64 pts: 0.64 pos:2433184
size:152064
-ret: 0 st: 0 flags:0 ts:-0.48
-ret: 0 st: 0 flags:1 dts: 0.68 pts: 0.68 pos:2585254
size:152064
+ret:-1 st: 0 flags:0 ts:-0.48
ret: 0 st: 0 flags:1 ts: 2.40
ret:-EOF
ret: 0 st:-1 flags:0 ts: 1.306672
ret:-EOF
ret: 0 st:-1 flags:1 ts: 0.200839
ret: 0 st: 0 flags:1 dts: 0.20 pts: 0.20 pos: 760414
size:152064
-ret: 0 st: 0 flags:0 ts:-0.92
-ret: 0 st: 0 flags:1 dts: 0.24 pts: 0.24 pos: 912484
size:152064
+ret:-1 st: 0 flags:0 ts:-0.92
ret: 0 st: 0 flags:1 ts: 2.00
ret:-EOF
ret: 0 st:-1 flags:0 ts: 0.883340
ret: 0 st: 0 flags:1 dts: 0.88 pts: 0.88 pos:3345604
size:152064
-ret: 0 st:-1 flags:1 ts:-0.222493
-ret: 0 st: 0 flags:1 dts: 0.92 pts: 0.92 pos:3497674
size:152064
+ret:-1 st:-1 flags:1 ts:-0.222493
ret: 0 st: 0 flags:0 ts: 2.68
ret:-EOF
ret: 0 st: 0 flags:1 ts: 1.56
ret:-EOF
ret: 0 st:-1 flags:0 ts: 0.460008
ret: 0 st: 0 flags:1 dts: 0.48 pts: 0.48 pos:1824904
size:152064
-ret: 0 st:-1 flags:1 ts:-0.645825
-ret: 0 st: 0 flags:1 dts: 0.52 pts: 0.52 pos:1976974
size:152064
+ret:-1 st:-1 flags:1 ts:-0.645825
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] tests/gapless: add gapless aac tests
Signed-off-by: Marton Balint --- tests/fate/gapless.mak | 3 +++ tests/ref/fate/gapless-aac | 5 + 2 files changed, 8 insertions(+) create mode 100644 tests/ref/fate/gapless-aac diff --git a/tests/fate/gapless.mak b/tests/fate/gapless.mak index 2fb005f..c47ab94 100644 --- a/tests/fate/gapless.mak +++ b/tests/fate/gapless.mak @@ -1,6 +1,9 @@ FATE_GAPLESS-$(CONFIG_MP3_DEMUXER) += fate-gapless-mp3 fate-gapless-mp3: CMD = gapless $(TARGET_SAMPLES)/gapless/gapless.mp3 +FATE_GAPLESS-$(call DEMDEC, MOV, AAC_FIXED) += fate-gapless-aac +fate-gapless-aac: CMD = gapless $(TARGET_SAMPLES)/gapless/102400samples_qt-lc-aac.m4a "-codec:a aac_fixed" + FATE_GAPLESS = $(FATE_GAPLESS-yes) FATE_SAMPLES_AVCONV += $(FATE_GAPLESS) diff --git a/tests/ref/fate/gapless-aac b/tests/ref/fate/gapless-aac new file mode 100644 index 000..607022d --- /dev/null +++ b/tests/ref/fate/gapless-aac @@ -0,0 +1,5 @@ +9459e7dc74af1b451eb890686f04f262 *tests/data/fate/gapless-aac.out-1 +d3c3c4ea121b3f3b8a346a168d2fec0e +9459e7dc74af1b451eb890686f04f262 *tests/data/fate/gapless-aac.out-2 +d3c3c4ea121b3f3b8a346a168d2fec0e +63dd86b78c8fbd22a99bf88583256bfe *tests/data/fate/gapless-aac.out-3 -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add test foravpriv_get_trc_function_from_trc function
On Wed, Mar 02, 2016 at 04:35:08PM -0800, NagaChaitanya Vellanki wrote:
> ---
> libavutil/Makefile | 1 +
> libavutil/color_utils.c| 65
> ++
> tests/fate/libavutil.mak | 4 +++
> tests/ref/fate/color_utils | 38 +++
> 4 files changed, 108 insertions(+)
> create mode 100644 tests/ref/fate/color_utils
>
> diff --git a/libavutil/Makefile b/libavutil/Makefile
> index a4d79cd..934564f 100644
> --- a/libavutil/Makefile
> +++ b/libavutil/Makefile
> @@ -176,6 +176,7 @@ TESTPROGS = adler32
> \
> bprint \
> cast5 \
> camellia\
> +color_utils \
> cpu \
> crc \
> des \
> diff --git a/libavutil/color_utils.c b/libavutil/color_utils.c
> index b68b402..e53f408 100644
> --- a/libavutil/color_utils.c
> +++ b/libavutil/color_utils.c
> @@ -21,6 +21,7 @@
> #include
> #include
>
> +#include "common.h"
> #include "libavutil/color_utils.h"
> #include "libavutil/pixfmt.h"
>
> @@ -216,3 +217,67 @@ avpriv_trc_function
> avpriv_get_trc_function_from_trc(enum AVColorTransferCharact
> }
> return func;
> }
> +
> +#ifdef TEST
> +// LCOV_EXCL_START
> +
> +int main(int argc, char *argv[])
> +{
> + int i;
> + struct test {
> + enum AVColorTransferCharacteristic trc;
> + const char* func_name;
> + double arg;
> + double result;
> + } tests[] = {
> + { AVCOL_TRC_BT709, "avpriv_trc_bt709", -0.01, 0.0 },
> + { AVCOL_TRC_SMPTE170M, "avpriv_trc_bt709", 0.005, 0.022500 },
> + { AVCOL_TRC_BT2020_10, "avpriv_trc_bt709", 0.015, 0.067500 },
> + { AVCOL_TRC_BT2020_12, "avpriv_trc_bt709", 1.0, 1.0 },
> + { AVCOL_TRC_BT2020_12, "avpriv_trc_bt709", 15123.4567, 83.452916 },
> + { AVCOL_TRC_GAMMA22, "avpriv_trc_gamma22", -0.01, 0.0 },
> + { AVCOL_TRC_GAMMA22, "avpriv_trc_gamma22", 1.0, 1.0 },
> + { AVCOL_TRC_GAMMA22, "avpriv_trc_gamma22", 125.098765, 8.980424 },
> + { AVCOL_TRC_GAMMA28, "avpriv_trc_gamma28", -0.01, 0.0 },
> + { AVCOL_TRC_GAMMA28, "avpriv_trc_gamma28", 1.0, 1.0 },
> + { AVCOL_TRC_GAMMA28, "avpriv_trc_gamma28", 9.88, 61.054001 },
> + { AVCOL_TRC_SMPTE240M, "avpriv_trc_smpte240M", -0.01, 0.0 },
> + { AVCOL_TRC_SMPTE240M, "avpriv_trc_smpte240M", 0.015, 0.06 },
> + { AVCOL_TRC_LINEAR, "avpriv_trc_linear", 0.0, 0.0 },
> + { AVCOL_TRC_LINEAR, "avpriv_trc_linear", 0.1, 0.1 },
> + { AVCOL_TRC_LINEAR, "avpriv_trc_linear", -0.1, -0.1 },
> + { AVCOL_TRC_LOG, "avpriv_trc_log", 0.009, 0.0 },
> + { AVCOL_TRC_LOG, "avpriv_trc_log", 1.0, 1.0 },
> + { AVCOL_TRC_LOG, "avpriv_trc_log", 98678.4231, 3.497111 },
> + { AVCOL_TRC_LOG_SQRT, "avpriv_trc_log_sqrt", 0.00316227760, 0.0 },
> + { AVCOL_TRC_LOG_SQRT, "avpriv_trc_log_sqrt", 1.0, 1.0 },
> + { AVCOL_TRC_LOG_SQRT, "avpriv_trc_log_sqrt", 19845.88923, 2.719068 },
> + { AVCOL_TRC_IEC61966_2_4, "avpriv_trc_iec61966_2_4", 0.0, 0.0 },
> + { AVCOL_TRC_IEC61966_2_4, "avpriv_trc_iec61966_2_4",
> -0.018053968510807, -0.081243 },
> + { AVCOL_TRC_IEC61966_2_4, "avpriv_trc_iec61966_2_4", 0.015, 0.067500 },
> + { AVCOL_TRC_IEC61966_2_4, "avpriv_trc_iec61966_2_4", 98245.76983,
> 193.835711 },
> + { AVCOL_TRC_BT1361_ECG, "avpriv_trc_bt1361", 0.0, 0.0 },
> + { AVCOL_TRC_BT1361_ECG, "avpriv_trc_bt1361", -0.0045, -0.069898 },
> + { AVCOL_TRC_BT1361_ECG, "avpriv_trc_bt1361", 0.015, 0.067500 },
> + { AVCOL_TRC_BT1361_ECG, "avpriv_trc_bt1361", 1999.11123, 33.512490 },
> + { AVCOL_TRC_IEC61966_2_1, "avpriv_trc_iec61966_2_1", 0.0, 0.0 },
> + { AVCOL_TRC_IEC61966_2_1, "avpriv_trc_iec61966_2_1", 0.015, 0.128354 },
> + { AVCOL_TRC_IEC61966_2_1, "avpriv_trc_iec61966_2_1", 6945.443,
> 42.013863 },
> + { AVCOL_TRC_SMPTEST2084, "avpriv_trc_smpte_st2084", -0.01, 0.0 },
> + { AVCOL_TRC_SMPTEST2084, "avpriv_trc_smpte_st2084", 0.0, 0.01 },
> + { AVCOL_TRC_SMPTEST428_1, "avpriv_trc_smpte_st428_1", -0.01, 0.0 },
> + { AVCOL_TRC_SMPTEST428_1, "avpriv_trc_smpte_st428_1", 52.37, 4.432321
> },
> + { AVCOL_TRC_SMPTEST428_1, "avpriv_trc_smpte_st428_1", 0.0, 0.0 }
this can be simplified, you dont need to list the results explicitly
nor the functions or enum values and the testpoints can be the same
for all
for (i = 0; i
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpe
Re: [FFmpeg-devel] [PATCH 3/3] ffmpeg: remove hardcoded 'now' creation_time support
On Sun, 28 Feb 2016, Marton Balint wrote: Every date parsing routine now uses av_parse_time which handles 'now' and provides greater precision as well. This change also enables the segmenter muxer to set the proper 'now' creation time at the beginning of each segment. Signed-off-by: Marton Balint --- ffmpeg_opt.c | 13 - 1 file changed, 13 deletions(-) All concerns I had are now addressed, and this patch is pending for quite a lot of time, so applied. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avformat: use ff_standardize_creation_time for formats writing all format string metadata
On Sun, 28 Feb 2016, wm4 wrote: On Sun, 28 Feb 2016 14:28:20 +0100 Marton Balint wrote: Signed-off-by: Marton Balint --- libavformat/apetag.c| 1 + libavformat/cafenc.c| 1 + libavformat/flvenc.c| 1 + libavformat/id3v2enc.c | 1 + libavformat/lrcenc.c| 1 + libavformat/nutenc.c| 1 + libavformat/smjpegenc.c | 1 + libavformat/wtvenc.c| 1 + 8 files changed, 8 insertions(+) Patches 1 and 2 LGTM. Thanks, applied both. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add test foravpriv_get_trc_function_from_trc function
---
libavutil/Makefile | 1 +
libavutil/color_utils.c| 65 ++
tests/fate/libavutil.mak | 4 +++
tests/ref/fate/color_utils | 38 +++
4 files changed, 108 insertions(+)
create mode 100644 tests/ref/fate/color_utils
diff --git a/libavutil/Makefile b/libavutil/Makefile
index a4d79cd..934564f 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -176,6 +176,7 @@ TESTPROGS = adler32
\
bprint \
cast5 \
camellia\
+color_utils \
cpu \
crc \
des \
diff --git a/libavutil/color_utils.c b/libavutil/color_utils.c
index b68b402..e53f408 100644
--- a/libavutil/color_utils.c
+++ b/libavutil/color_utils.c
@@ -21,6 +21,7 @@
#include
#include
+#include "common.h"
#include "libavutil/color_utils.h"
#include "libavutil/pixfmt.h"
@@ -216,3 +217,67 @@ avpriv_trc_function avpriv_get_trc_function_from_trc(enum
AVColorTransferCharact
}
return func;
}
+
+#ifdef TEST
+// LCOV_EXCL_START
+
+int main(int argc, char *argv[])
+{
+ int i;
+ struct test {
+ enum AVColorTransferCharacteristic trc;
+ const char* func_name;
+ double arg;
+ double result;
+ } tests[] = {
+ { AVCOL_TRC_BT709, "avpriv_trc_bt709", -0.01, 0.0 },
+ { AVCOL_TRC_SMPTE170M, "avpriv_trc_bt709", 0.005, 0.022500 },
+ { AVCOL_TRC_BT2020_10, "avpriv_trc_bt709", 0.015, 0.067500 },
+ { AVCOL_TRC_BT2020_12, "avpriv_trc_bt709", 1.0, 1.0 },
+ { AVCOL_TRC_BT2020_12, "avpriv_trc_bt709", 15123.4567, 83.452916 },
+ { AVCOL_TRC_GAMMA22, "avpriv_trc_gamma22", -0.01, 0.0 },
+ { AVCOL_TRC_GAMMA22, "avpriv_trc_gamma22", 1.0, 1.0 },
+ { AVCOL_TRC_GAMMA22, "avpriv_trc_gamma22", 125.098765, 8.980424 },
+ { AVCOL_TRC_GAMMA28, "avpriv_trc_gamma28", -0.01, 0.0 },
+ { AVCOL_TRC_GAMMA28, "avpriv_trc_gamma28", 1.0, 1.0 },
+ { AVCOL_TRC_GAMMA28, "avpriv_trc_gamma28", 9.88, 61.054001 },
+ { AVCOL_TRC_SMPTE240M, "avpriv_trc_smpte240M", -0.01, 0.0 },
+ { AVCOL_TRC_SMPTE240M, "avpriv_trc_smpte240M", 0.015, 0.06 },
+ { AVCOL_TRC_LINEAR, "avpriv_trc_linear", 0.0, 0.0 },
+ { AVCOL_TRC_LINEAR, "avpriv_trc_linear", 0.1, 0.1 },
+ { AVCOL_TRC_LINEAR, "avpriv_trc_linear", -0.1, -0.1 },
+ { AVCOL_TRC_LOG, "avpriv_trc_log", 0.009, 0.0 },
+ { AVCOL_TRC_LOG, "avpriv_trc_log", 1.0, 1.0 },
+ { AVCOL_TRC_LOG, "avpriv_trc_log", 98678.4231, 3.497111 },
+ { AVCOL_TRC_LOG_SQRT, "avpriv_trc_log_sqrt", 0.00316227760, 0.0 },
+ { AVCOL_TRC_LOG_SQRT, "avpriv_trc_log_sqrt", 1.0, 1.0 },
+ { AVCOL_TRC_LOG_SQRT, "avpriv_trc_log_sqrt", 19845.88923, 2.719068 },
+ { AVCOL_TRC_IEC61966_2_4, "avpriv_trc_iec61966_2_4", 0.0, 0.0 },
+ { AVCOL_TRC_IEC61966_2_4, "avpriv_trc_iec61966_2_4", -0.018053968510807,
-0.081243 },
+ { AVCOL_TRC_IEC61966_2_4, "avpriv_trc_iec61966_2_4", 0.015, 0.067500 },
+ { AVCOL_TRC_IEC61966_2_4, "avpriv_trc_iec61966_2_4", 98245.76983,
193.835711 },
+ { AVCOL_TRC_BT1361_ECG, "avpriv_trc_bt1361", 0.0, 0.0 },
+ { AVCOL_TRC_BT1361_ECG, "avpriv_trc_bt1361", -0.0045, -0.069898 },
+ { AVCOL_TRC_BT1361_ECG, "avpriv_trc_bt1361", 0.015, 0.067500 },
+ { AVCOL_TRC_BT1361_ECG, "avpriv_trc_bt1361", 1999.11123, 33.512490 },
+ { AVCOL_TRC_IEC61966_2_1, "avpriv_trc_iec61966_2_1", 0.0, 0.0 },
+ { AVCOL_TRC_IEC61966_2_1, "avpriv_trc_iec61966_2_1", 0.015, 0.128354 },
+ { AVCOL_TRC_IEC61966_2_1, "avpriv_trc_iec61966_2_1", 6945.443, 42.013863
},
+ { AVCOL_TRC_SMPTEST2084, "avpriv_trc_smpte_st2084", -0.01, 0.0 },
+ { AVCOL_TRC_SMPTEST2084, "avpriv_trc_smpte_st2084", 0.0, 0.01 },
+ { AVCOL_TRC_SMPTEST428_1, "avpriv_trc_smpte_st428_1", -0.01, 0.0 },
+ { AVCOL_TRC_SMPTEST428_1, "avpriv_trc_smpte_st428_1", 52.37, 4.432321 },
+ { AVCOL_TRC_SMPTEST428_1, "avpriv_trc_smpte_st428_1", 0.0, 0.0 }
+ };
+
+ for(i = 0; i < FF_ARRAY_ELEMS(tests); i++) {
+ avpriv_trc_function func =
avpriv_get_trc_function_from_trc(tests[i].trc);
+ double result = func(tests[i].arg);
+ printf("AVColorTransferCharacteristic=%d calling %s(%f) expected=%f
got=%f\n",
+ tests[i].trc, tests[i].func_name, tests[i].arg,
+ tests[i].result, result);
+ }
+}
+
+// LCOV_EXCL_STOP
+#endif
diff --git a/tests/fate/libavutil.mak b/tests/fate/libavutil.mak
index 022ae6a..a89bc1d 100644
--- a/tests/fate/libavutil.mak
+++ b/tests/fate/libavutil.mak
@@ -48,6 +48,10 @@ FATE_LIBAVUTIL += fate-c
Re: [FFmpeg-devel] [PATCH v5 1/4] lavf/avienc: Add support for palette side data
On 03/03/2016 12:34 AM, Mats Peterson wrote: Hopefully this patch set will work on big-endian machines as well. Please try stream copy to and from avi/mov with the files below: QuickTime Animation (RLE): https://drive.google.com/open?id=0B3_pEBoLs0faREo1SlRydmV1LU0 QuickTime Graphics (SMC): https://drive.google.com/open?id=0B3_pEBoLs0faODd5RVBldkdvVGc Microsoft Video 1 (CRAM) https://drive.google.com/open?id=0B3_pEBoLs0faT2ZZZVNpVUM0blE Mats And convert with -vcodec rawvideo as well, to make sure it works on a big-endian machine. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 4/4] lavf/utils: Fix endianness in ff_get_packet_palette()
On 03/03/2016 12:36 AM, Mats Peterson wrote: Different interface as well. Now uses a pointer to a palette buffer that the palette is copied to. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] avcodec/dca: simplify condition
On Wed, Mar 2, 2016 at 8:32 PM, foo86 wrote:
> ---
> libavcodec/dca_xll.c | 17 ++---
> 1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/libavcodec/dca_xll.c b/libavcodec/dca_xll.c
> index ffe8ef3..5e6cf35 100644
> --- a/libavcodec/dca_xll.c
> +++ b/libavcodec/dca_xll.c
> @@ -460,19 +460,14 @@ static int chs_parse_band_data(DCAXllDecoder *s,
> DCAXllChSet *c, int band, int s
> // Unpack Rice coding flag
> // 0 - linear code, 1 - Rice code
> c->rice_code_flag[i] = get_bits1(&s->gb);
> -if (!c->seg_common && c->rice_code_flag[i]) {
> -// Unpack Hybrid Rice coding flag
> -// 0 - Rice code, 1 - Hybrid Rice code
> -if (get_bits1(&s->gb))
> -// Unpack binary code length for isolated samples
> -c->bitalloc_hybrid_linear[i] = get_bits(&s->gb,
> c->nabits) + 1;
> -else
> -// 0 indicates no Hybrid Rice coding
> -c->bitalloc_hybrid_linear[i] = 0;
> -} else {
> +// Unpack Hybrid Rice coding flag
> +// 0 - Rice code, 1 - Hybrid Rice code
> +if (!c->seg_common && c->rice_code_flag[i] && get_bits1(&s->gb))
> +// Unpack binary code length for isolated samples
> +c->bitalloc_hybrid_linear[i] = get_bits(&s->gb, c->nabits) +
> 1;
> +else
> // 0 indicates no Hybrid Rice coding
> c->bitalloc_hybrid_linear[i] = 0;
> -}
> }
>
> // Unpack coding parameters
> --
> 2.1.4
LGTM, logic appears unchanged afterall.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] avcodec/dca: fix av_cold placement in declarations
On Wed, Mar 2, 2016 at 8:31 PM, foo86 wrote:
> ---
> libavcodec/dca_xll.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/dca_xll.c b/libavcodec/dca_xll.c
> index cd1af81..ffe8ef3 100644
> --- a/libavcodec/dca_xll.c
> +++ b/libavcodec/dca_xll.c
> @@ -602,7 +602,7 @@ static int chs_parse_band_data(DCAXllDecoder *s,
> DCAXllChSet *c, int band, int s
> return 0;
> }
>
> -static void av_cold chs_clear_band_data(DCAXllDecoder *s, DCAXllChSet *c,
> int band, int seg)
> +static av_cold void chs_clear_band_data(DCAXllDecoder *s, DCAXllChSet *c,
> int band, int seg)
> {
> DCAXllBand *b = &c->bands[band];
> int i, offset, nsamples;
> @@ -1242,7 +1242,7 @@ static void scale_down_mix(DCAXllDecoder *s,
> DCAXllChSet *o, int band)
>
> // Clear all band data and replace non-residual encoded channels with lossy
> // counterparts
> -static void av_cold force_lossy_output(DCAXllDecoder *s, DCAXllChSet *c)
> +static av_cold void force_lossy_output(DCAXllDecoder *s, DCAXllChSet *c)
> {
> DCAContext *dca = s->avctx->priv_data;
> int band, ch;
> --
> 2.1.4
LGTM, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] avcodec/dca: make reading past end of buffer safe
On Thu, Mar 3, 2016 at 12:37 AM, Ronald S. Bultje wrote: > Hi, > > On Wed, Mar 2, 2016 at 2:32 PM, foo86 wrote: > >> Limit the maximum length of unary part of Rice code by the number of >> available bits instead of using an arbitrary constant that happens to be >> just large enough to work. >> >> This effectively limits amount of data that can be overread per segment >> by maximum length of binary code per sample multiplied by maximum >> segment size. >> >> Increase size of padding area after the end of input buffer according to >> this limit and add some extra overread checks to make reading past end >> of buffer safe. >> --- >> libavcodec/dca_xll.c | 25 +++-- >> libavcodec/dcadec.h | 2 +- >> 2 files changed, 16 insertions(+), 11 deletions(-) > > > Completely random comment, but isn't it easier to just enable the safe > bitstream reader? > This is actually enabled by default, so it probably should never have overread anywhere, but if the code can be made a bit safer in itself it probably does no harm either way. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] avcodec/dca: make reading past end of buffer safe
Hi, On Wed, Mar 2, 2016 at 2:32 PM, foo86 wrote: > Limit the maximum length of unary part of Rice code by the number of > available bits instead of using an arbitrary constant that happens to be > just large enough to work. > > This effectively limits amount of data that can be overread per segment > by maximum length of binary code per sample multiplied by maximum > segment size. > > Increase size of padding area after the end of input buffer according to > this limit and add some extra overread checks to make reading past end > of buffer safe. > --- > libavcodec/dca_xll.c | 25 +++-- > libavcodec/dcadec.h | 2 +- > 2 files changed, 16 insertions(+), 11 deletions(-) Completely random comment, but isn't it easier to just enable the safe bitstream reader? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v5 4/4] lavf/utils: Fix endianness in ff_get_packet_palette()
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 75f98197bda12b486971d1d6cc139cb5d22b30ba Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Thu, 3 Mar 2016 00:29:32 +0100
Subject: [PATCH v5 4/4] lavf/utils: Fix endianness in ff_get_packet_palette()
---
libavformat/internal.h |7 +--
libavformat/utils.c| 23 ---
2 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 8e06655..e58d078 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -580,9 +580,12 @@ int ff_reshuffle_raw_rgb(AVFormatContext *s, AVPacket **ppkt, AVCodecContext *en
*
* Use 0 for the ret parameter to check for side data only.
*
- * @param pkt pointer to the packet before calling ff_reshuffle_raw_rgb()
+ * @param pkt pointer to packet before calling ff_reshuffle_raw_rgb()
* @param ret return value from ff_reshuffle_raw_rgb(), or 0
+ * @param palette pointer to palette buffer
+ * @return negative error code or
+ 1 if the packet contains a palette, else 0
*/
-int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, const uint8_t **palette);
+int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, uint32_t *palette);
#endif /* AVFORMAT_INTERNAL_H */
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 771e878..9931e61 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4760,18 +4760,27 @@ int ff_parse_creation_time_metadata(AVFormatContext *s, int64_t *timestamp, int
return 0;
}
-int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, const uint8_t **palette)
+int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, uint32_t *palette)
{
+uint8_t *side_data;
int size;
-*palette = av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, &size);
-if (*palette && size != AVPALETTE_SIZE) {
-av_log(s, AV_LOG_ERROR, "Invalid palette side data\n");
-return AVERROR_INVALIDDATA;
+side_data = av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, &size);
+if (side_data) {
+if (size != AVPALETTE_SIZE) {
+av_log(s, AV_LOG_ERROR, "Invalid palette side data\n");
+return AVERROR_INVALIDDATA;
+}
+memcpy(palette, side_data, AVPALETTE_SIZE);
+return 1;
}
-if (!*palette && ret == CONTAINS_PAL)
-*palette = pkt->data + pkt->size - AVPALETTE_SIZE;
+if (ret == CONTAINS_PAL) {
+int i;
+for (i = 0; i < AVPALETTE_COUNT; i++)
+palette[i] = AV_RL32(pkt->data + pkt->size - AVPALETTE_SIZE + i*4);
+return 1;
+}
return 0;
}
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v5 3/4] lavf/riffenc: Handle palette for non-raw codecs
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 602db1c464b7a432b4f4b471cbeed401cd220e4c Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Thu, 3 Mar 2016 00:28:23 +0100
Subject: [PATCH v5 3/4] lavf/riffenc: Handle palette for non-raw codecs
---
libavformat/riffenc.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index 1dd7971..195a58e 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -209,12 +209,17 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
int keep_height = enc->extradata_size >= 9 &&
!memcmp(enc->extradata + enc->extradata_size - 9, "BottomUp", 9);
int extradata_size = enc->extradata_size - 9*keep_height;
-int raw_pal_avi;
+enum AVPixelFormat pix_fmt = enc->pix_fmt;
+int pal_avi;
-raw_pal_avi = !for_asf && enc->codec_id == AV_CODEC_ID_RAWVIDEO &&
- !enc->codec_tag &&
-enc->bits_per_coded_sample >= 1 && enc->bits_per_coded_sample <= 8;
-if (!enc->extradata_size && raw_pal_avi)
+if (pix_fmt == AV_PIX_FMT_NONE && enc->bits_per_coded_sample == 1)
+pix_fmt = AV_PIX_FMT_MONOWHITE;
+pal_avi = !for_asf &&
+ (pix_fmt == AV_PIX_FMT_PAL8 ||
+ pix_fmt == AV_PIX_FMT_MONOWHITE ||
+ pix_fmt == AV_PIX_FMT_MONOBLACK);
+
+if (!enc->extradata_size && pal_avi)
extradata_size = 4 * (1 << enc->bits_per_coded_sample);
/* size */
@@ -239,11 +244,8 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
avio_write(pb, enc->extradata, extradata_size);
if (!for_asf && extradata_size & 1)
avio_w8(pb, 0);
-} else if (raw_pal_avi) {
+} else if (pal_avi) {
int i;
-enum AVPixelFormat pix_fmt = enc->pix_fmt;
-if (pix_fmt == AV_PIX_FMT_NONE && enc->bits_per_coded_sample == 1)
-pix_fmt = AV_PIX_FMT_MONOWHITE;
for (i = 0; i < 1 << enc->bits_per_coded_sample; i++) {
/* Initialize 1 bpp palette to black & white */
if (i == 0 && pix_fmt == AV_PIX_FMT_MONOWHITE)
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v5 2/4] lavf/movenc: Add support for palette side data
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 99e1f56c242cfa3d20a0987a7e766fa358ed35c2 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Thu, 3 Mar 2016 00:27:53 +0100
Subject: [PATCH v5 2/4] lavf/movenc: Add support for palette side data
---
libavformat/movenc.c | 44 +---
1 file changed, 25 insertions(+), 19 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 3295266..cb125d8 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1716,14 +1716,15 @@ static int mov_write_video_tag(AVIOContext *pb, MOVMuxContext *mov, MOVTrack *tr
else
avio_wb16(pb, 0x18); /* Reserved */
-if (track->is_unaligned_qt_rgb && track->enc->pix_fmt == AV_PIX_FMT_PAL8) {
+if (track->mode == MODE_MOV && track->enc->pix_fmt == AV_PIX_FMT_PAL8) {
+int pal_size = 1 << track->enc->bits_per_coded_sample;
int i;
avio_wb16(pb, 0); /* Color table ID */
avio_wb32(pb, 0); /* Color table seed */
avio_wb16(pb, 0x8000);/* Color table flags */
-avio_wb16(pb, 255); /* Color table size (zero-relative) */
-for (i = 0; i < 256; i++) {
-uint32_t rgb = AV_RL32(&track->palette[i]);
+avio_wb16(pb, pal_size - 1); /* Color table size (zero-relative) */
+for (i = 0; i < pal_size; i++) {
+uint32_t rgb = track->palette[i];
uint16_t r = (rgb >> 16) & 0xff;
uint16_t g = (rgb >> 8) & 0xff;
uint16_t b = rgb & 0xff;
@@ -4763,21 +4764,26 @@ static int mov_write_packet(AVFormatContext *s, AVPacket *pkt)
}
}
-if (trk->is_unaligned_qt_rgb) {
-const uint8_t *data = pkt->data;
-int size = pkt->size;
-int64_t bpc = trk->enc->bits_per_coded_sample != 15 ? trk->enc->bits_per_coded_sample : 16;
-int expected_stride = ((trk->enc->width * bpc + 15) >> 4)*2;
-int ret = ff_reshuffle_raw_rgb(s, &pkt, trk->enc, expected_stride);
-if (ret < 0)
-return ret;
-if (ret == CONTAINS_PAL && !trk->pal_done) {
-int pal_size = 1 << trk->enc->bits_per_coded_sample;
-memset(trk->palette, 0, AVPALETTE_SIZE);
-memcpy(trk->palette, data + size - 4*pal_size, 4*pal_size);
-trk->pal_done++;
-} else if (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 ||
- trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK) {
+if (trk->mode == MODE_MOV && trk->enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+AVPacket *opkt = pkt;
+int ret;
+if (trk->is_unaligned_qt_rgb) {
+int64_t bpc = trk->enc->bits_per_coded_sample != 15 ? trk->enc->bits_per_coded_sample : 16;
+int expected_stride = ((trk->enc->width * bpc + 15) >> 4)*2;
+ret = ff_reshuffle_raw_rgb(s, &pkt, trk->enc, expected_stride);
+if (ret < 0)
+return ret;
+} else
+ret = 0;
+if (trk->enc->pix_fmt == AV_PIX_FMT_PAL8 && !trk->pal_done) {
+int ret2 = ff_get_packet_palette(s, opkt, ret, trk->palette);
+if (ret2 < 0)
+return ret2;
+if (ret2)
+trk->pal_done++;
+} else if (trk->enc->codec_id == AV_CODEC_ID_RAWVIDEO &&
+ (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 ||
+ trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK)) {
for (i = 0; i < pkt->size; i++)
pkt->data[i] = ~pkt->data[i];
}
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v5 1/4] lavf/avienc: Add support for palette side data
Hopefully this patch set will work on big-endian machines as well.
Please try stream copy to and from avi/mov with the files below:
QuickTime Animation (RLE):
https://drive.google.com/open?id=0B3_pEBoLs0faREo1SlRydmV1LU0
QuickTime Graphics (SMC):
https://drive.google.com/open?id=0B3_pEBoLs0faODd5RVBldkdvVGc
Microsoft Video 1 (CRAM)
https://drive.google.com/open?id=0B3_pEBoLs0faT2ZZZVNpVUM0blE
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 899da4b2d6aba1095513a016bd4425221e257eb6 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Thu, 3 Mar 2016 00:27:38 +0100
Subject: [PATCH v5 1/4] lavf/avienc: Add support for palette side data
---
libavformat/avienc.c | 60 --
1 file changed, 39 insertions(+), 21 deletions(-)
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ca505f4..3a073a3 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -74,12 +74,15 @@ typedef struct AVIStream {
int max_size;
int sample_requested;
-int64_t pal_offset;
-int hdr_pal_done;
-
int64_t last_dts;
AVIIndex indexes;
+
+uint32_t palette[AVPALETTE_COUNT];
+int pal_done;
+
+int64_t hdr_pal_offset;
+int hdr_pal_done;
} AVIStream;
static int avi_write_packet_internal(AVFormatContext *s, AVPacket *pkt);
@@ -362,7 +365,8 @@ static int avi_write_header(AVFormatContext *s)
&& enc->pix_fmt == AV_PIX_FMT_RGB555LE
&& enc->bits_per_coded_sample == 15)
enc->bits_per_coded_sample = 16;
-avist->pal_offset = avio_tell(pb) + 40;
+if (pb->seekable)
+avist->hdr_pal_offset = avio_tell(pb) + 40;
ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0, 0);
pix_fmt = avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi,
enc->bits_per_coded_sample);
@@ -652,11 +656,11 @@ 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;
AVIStream *avist= s->streams[stream_index]->priv_data;
+AVPacket *opkt = pkt;
+enum AVPixelFormat pix_fmt = enc->pix_fmt;
int ret;
if (enc->codec_id == AV_CODEC_ID_H264 && enc->codec_tag == MKTAG('H','2','6','4') && pkt->size) {
@@ -668,22 +672,34 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
if ((ret = write_skip_frames(s, stream_index, pkt->dts)) < 0)
return ret;
-if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) {
-int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
-int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
-
-ret = ff_reshuffle_raw_rgb(s, &pkt, enc, expected_stride);
-if (ret < 0)
-return ret;
-if (ret) {
-if (ret == CONTAINS_PAL) {
-int pc_tag, i;
+if (!pkt->size)
+return avi_write_packet_internal(s, pkt); /* Passthrough */
+
+if (enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) {
+int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
+int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
+ret = ff_reshuffle_raw_rgb(s, &pkt, enc, expected_stride);
+if (ret < 0)
+return ret;
+} else
+ret = 0;
+if (pix_fmt == AV_PIX_FMT_NONE && enc->bits_per_coded_sample == 1)
+pix_fmt = AV_PIX_FMT_MONOWHITE;
+if (pix_fmt == AV_PIX_FMT_PAL8 ||
+pix_fmt == AV_PIX_FMT_MONOWHITE ||
+pix_fmt == AV_PIX_FMT_MONOBLACK) {
+int ret2 = ff_get_packet_palette(s, opkt, ret, avist->palette);
+if (ret2 < 0)
+return ret2;
+if (ret2) {
int pal_size = 1 << enc->bits_per_coded_sample;
-if (!avist->hdr_pal_done) {
-int64_t cur_offset = avio_tell(pb);
-avio_seek(pb, avist->pal_offset, SEEK_SET);
+int pc_tag, i;
+if (pb->seekable && !avist->hdr_pal_done) {
+int64_t cur_offset = avio_tell(pb);
+avio_seek(pb, avist->hdr_pal_offset, SEEK_SET);
for (i = 0; i < pal_size; i++) {
-uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
+uint32_t v = avist->palette[i];
avio_wl32(pb, v & 0xff);
}
avio_seek(pb, cur_offset, SEEK_SET);
@@ -696,11 +712,13 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
[FFmpeg-devel] [PATCH] Use matroska TrackNumber for populating AVStream::id
As far as I can see FFmpeg currently doesn't set AVStream::id for
matroska/webm streams. I think we could use either MatroskaTrack::num
(TrackNumber) or MatroskaTrack::uid (TrackUID) for that.
I have found a few discussions claiming that TrackUID could be missing,
even though TrackUID is marked as mandatory field in matroska spec, for
example see
https://github.com/mbunkus/mkvtoolnix/issues/1050
https://lists.w3.org/Archives/Public/public-inbandtracks/2014May/0003.html
So I guess it's safer to use TrackNumber for now.
---
libavformat/matroskadec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index d20568c..8b80df1 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1856,6 +1856,8 @@ static int matroska_parse_tracks(AVFormatContext *s)
return AVERROR(ENOMEM);
}
+st->id = (int) track->num;
+
if (key_id_base64) {
/* export encryption key id as base64 metadata tag */
av_dict_set(&st->metadata, "enc_key_id", key_id_base64, 0);
--
2.7.0.rc3.207.g0ac5344
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add encoder stats to the NVENC codec.
---
libavcodec/nvenc.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index a3b02fa..67232c7 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -1208,31 +1208,35 @@ static int process_output_surface(AVCodecContext
*avctx, AVPacket *pkt, NvencOut
if (nv_status != NV_ENC_SUCCESS)
av_log(avctx, AV_LOG_ERROR, "Failed unlocking bitstream buffer, expect
the gates of mordor to open\n");
+enum AVPictureType pict_type;
+
switch (lock_params.pictureType) {
case NV_ENC_PIC_TYPE_IDR:
pkt->flags |= AV_PKT_FLAG_KEY;
-#if FF_API_CODED_FRAME
-FF_DISABLE_DEPRECATION_WARNINGS
case NV_ENC_PIC_TYPE_I:
-avctx->coded_frame->pict_type = AV_PICTURE_TYPE_I;
+pict_type = AV_PICTURE_TYPE_I;
break;
case NV_ENC_PIC_TYPE_P:
-avctx->coded_frame->pict_type = AV_PICTURE_TYPE_P;
+pict_type = AV_PICTURE_TYPE_P;
break;
case NV_ENC_PIC_TYPE_B:
-avctx->coded_frame->pict_type = AV_PICTURE_TYPE_B;
+pict_type = AV_PICTURE_TYPE_B;
break;
case NV_ENC_PIC_TYPE_BI:
-avctx->coded_frame->pict_type = AV_PICTURE_TYPE_BI;
+pict_type = AV_PICTURE_TYPE_BI;
break;
default:
av_log(avctx, AV_LOG_ERROR, "Unknown picture type encountered, expect
the output to be broken.\n");
av_log(avctx, AV_LOG_ERROR, "Please report this error and include as
much information on how to reproduce it as possible.\n");
res = AVERROR_EXTERNAL;
goto error;
+}
+#if FF_API_CODED_FRAME
+FF_DISABLE_DEPRECATION_WARNINGS
+avctx->coded_frame->pict_type = pict_type;
FF_ENABLE_DEPRECATION_WARNINGS
#endif
-}
+ff_side_data_set_encoder_stats(pkt, (lock_params.frameAvgQP - 1) *
FF_QP2LAMBDA, NULL, 0, pict_type);
pkt->pts = lock_params.outputTimeStamp;
pkt->dts = timestamp_queue_dequeue(&ctx->timestamp_list);
--
2.7.0.rc3.207.g0ac5344
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 2/5 v2] lavf/movenc: Add support for palette side data
On 03/02/2016 11:19 PM, Mats Peterson wrote:
On 03/02/2016 11:07 PM, Mats Peterson wrote:
On 03/02/2016 10:30 PM, Michael Niedermayer wrote:
+ret = 0;
+if (trk->enc->pix_fmt == AV_PIX_FMT_PAL8 &&
!trk->pal_done) {
+const uint8_t *pal;
+int ret2 = ff_get_packet_palette(s, opkt, ret, &pal);
+if (ret2 < 0)
+return ret2;
+if (pal) {
+memcpy(trk->palette, pal, AVPALETTE_SIZE);
this fails on big endian
AV_PKT_DATA_PALETTE is stored in cpu endianness
in general AVPacket->data is defined byte per byte and can be stored
as is byte per byte
AVPacket->side_data is in whatever endianness
people preferred at the time a specific AV_PKT_DATA_* was added.
in case of AV_PKT_DATA_PALETTE its native cpu endianness
Messy! But alright, thanks for the info.
I just don't understand why the palette when stored in AVPacket->data is
in little-endian format when it is stored byte by byte. And I can't find
the place where this is done. It would be more logical to use big-endian
format.
I'm making an all new patch set, since there are several things to be
fixed, including ff_get_packet_palette().
Mats
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 2/5 v2] lavf/movenc: Add support for palette side data
On 03/02/2016 11:07 PM, Mats Peterson wrote:
On 03/02/2016 10:30 PM, Michael Niedermayer wrote:
+ret = 0;
+if (trk->enc->pix_fmt == AV_PIX_FMT_PAL8 &&
!trk->pal_done) {
+const uint8_t *pal;
+int ret2 = ff_get_packet_palette(s, opkt, ret, &pal);
+if (ret2 < 0)
+return ret2;
+if (pal) {
+memcpy(trk->palette, pal, AVPALETTE_SIZE);
this fails on big endian
AV_PKT_DATA_PALETTE is stored in cpu endianness
in general AVPacket->data is defined byte per byte and can be stored
as is byte per byte
AVPacket->side_data is in whatever endianness
people preferred at the time a specific AV_PKT_DATA_* was added.
in case of AV_PKT_DATA_PALETTE its native cpu endianness
Messy! But alright, thanks for the info.
I just don't understand why the palette when stored in AVPacket->data is
in little-endian format when it is stored byte by byte. And I can't find
the place where this is done. It would be more logical to use big-endian
format.
Mats
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 2/5 v2] lavf/movenc: Add support for palette side data
On 03/02/2016 10:30 PM, Michael Niedermayer wrote:
+ret = 0;
+if (trk->enc->pix_fmt == AV_PIX_FMT_PAL8 && !trk->pal_done) {
+const uint8_t *pal;
+int ret2 = ff_get_packet_palette(s, opkt, ret, &pal);
+if (ret2 < 0)
+return ret2;
+if (pal) {
+memcpy(trk->palette, pal, AVPALETTE_SIZE);
this fails on big endian
AV_PKT_DATA_PALETTE is stored in cpu endianness
in general AVPacket->data is defined byte per byte and can be stored
as is byte per byte
AVPacket->side_data is in whatever endianness
people preferred at the time a specific AV_PKT_DATA_* was added.
in case of AV_PKT_DATA_PALETTE its native cpu endianness
Messy! But alright, thanks for the info.
Mats
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 2/5 v2] lavf/movenc: Add support for palette side data
On 03/02/2016 09:36 PM, Michael Niedermayer wrote: in which cases of compressed (non raw) video does doing something special for pix_fmt == pal8 fix a problem ? In several cases. QuickTime RLE in 8-bit mode, QuickTime Graphics (SMC) in 8-bit mode, Microsoft Video 1 (CRAM) in 8-bit mode. All of them use a palette. There are possibly more formats, but these are the ones I can come up with at the moment. Mats Try stream copy with the files I mentioned in patch 1/5. ok, will look at them Please do. Thanks. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/4] DCA decoder fixes
On 3/2/2016 4:30 PM, foo86 wrote: > This fixes some potential issues I've identified within new DCA decoder. It is > probably a good idea to backport these patches into 3.0 release branch. > > foo86 (4): > avcodec/dca: clear X96 channels if nothing was decoded > avcodec/dca: fix av_cold placement in declarations > avcodec/dca: simplify condition > avcodec/dca: make reading past end of buffer safe > > libavcodec/dca_core.c | 1 + > libavcodec/dca_xll.c | 46 +++--- > libavcodec/dcadec.h | 2 +- > 3 files changed, 25 insertions(+), 24 deletions(-) Nice, thanks. While at it, could you check if https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/188319.html was the proper workaround to get https://trac.ffmpeg.org/raw-attachment/ticket/3550/WorstCase.wav working, or if it needs some changes similar to the ones in patch 4/4 from this set? Also, send a patch to add yourself as maintainer of the decoder in the MAINTAINERS file. You should also ask Michael (i think) to get push access to the git repo. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/img2enc: Allow to reverse frame order
Michael Niedermayer niedermayer.cc> writes: > personally ill probably abstain, as i even half misunderstood > the use case this was inteded for ;) But that's true for everybody who has commented so far... Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/img2enc: Allow to reverse frame order
On Tue, Mar 01, 2016 at 10:38:27PM -0500, Ganesh Ajjanagadde wrote: > On Tue, Mar 1, 2016 at 9:17 AM, Paul B Mahol wrote: > > On 3/1/16, Ronald S. Bultje wrote: > >> Hi, > >> > >> On Tue, Mar 1, 2016 at 8:04 AM, Carl Eugen Hoyos wrote: > >> > >>> Ronald S. Bultje gmail.com> writes: > >>> > >>> > > So how does this mechanism look like for the requested > >>> > > use case? > >>> > > >>> > man ln. > >>> > >>> As said, this is a completely ridiculous argument: > >>> FFmpeg has always tried to provide new features, no > >>> matter if other solutions existed or not. > >> > >> > >> When you don't get your way, just shout "ridiculous!" and all will be okay. > > > > Its just few loc. I see nothing wrong with it, lets vote! > > +1 to voting - why don't we actually put the developer committee to > use instead of arguing about it? if people want to vote on this, why not personally ill probably abstain, as i even half misunderstood the use case this was inteded for ;) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 2/5 v2] lavf/movenc: Add support for palette side data
On Wed, Mar 02, 2016 at 08:33:42PM +0100, Mats Peterson wrote:
> Check that the track type is AVMEDIA_TYPE_VIDEO in appropriate places.
>
> --
> Mats Peterson
> http://matsp888.no-ip.org/~mats/
> movenc.c | 45 +++--
> 1 file changed, 27 insertions(+), 18 deletions(-)
> f2f811cb47f8ba331ca3886ef99239f68aef98a0
> 0002-lavf-movenc-Add-support-for-palette-side-data.patch
> From c2d0b7a69486afb926e731216b4aff3b04c4ee4a Mon Sep 17 00:00:00 2001
> From: Mats Peterson
> Date: Wed, 2 Mar 2016 20:30:59 +0100
> Subject: [PATCH v4 2/5 v2] lavf/movenc: Add support for palette side data
>
> ---
> libavformat/movenc.c | 45 +++--
> 1 file changed, 27 insertions(+), 18 deletions(-)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 3295266..277f2d2 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -1716,13 +1716,14 @@ static int mov_write_video_tag(AVIOContext *pb,
> MOVMuxContext *mov, MOVTrack *tr
> else
> avio_wb16(pb, 0x18); /* Reserved */
>
> -if (track->is_unaligned_qt_rgb && track->enc->pix_fmt ==
> AV_PIX_FMT_PAL8) {
> +if (track->mode == MODE_MOV && track->enc->pix_fmt == AV_PIX_FMT_PAL8) {
> +int pal_size = 1 << track->enc->bits_per_coded_sample;
> int i;
> avio_wb16(pb, 0); /* Color table ID */
> avio_wb32(pb, 0); /* Color table seed */
> avio_wb16(pb, 0x8000);/* Color table flags */
> -avio_wb16(pb, 255); /* Color table size (zero-relative) */
> -for (i = 0; i < 256; i++) {
> +avio_wb16(pb, pal_size - 1); /* Color table size (zero-relative) */
> +for (i = 0; i < pal_size; i++) {
> uint32_t rgb = AV_RL32(&track->palette[i]);
> uint16_t r = (rgb >> 16) & 0xff;
> uint16_t g = (rgb >> 8) & 0xff;
> @@ -4763,21 +4764,29 @@ static int mov_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> }
> }
>
> -if (trk->is_unaligned_qt_rgb) {
> -const uint8_t *data = pkt->data;
> -int size = pkt->size;
> -int64_t bpc = trk->enc->bits_per_coded_sample != 15 ?
> trk->enc->bits_per_coded_sample : 16;
> -int expected_stride = ((trk->enc->width * bpc + 15) >> 4)*2;
> -int ret = ff_reshuffle_raw_rgb(s, &pkt, trk->enc,
> expected_stride);
> -if (ret < 0)
> -return ret;
> -if (ret == CONTAINS_PAL && !trk->pal_done) {
> -int pal_size = 1 << trk->enc->bits_per_coded_sample;
> -memset(trk->palette, 0, AVPALETTE_SIZE);
> -memcpy(trk->palette, data + size - 4*pal_size, 4*pal_size);
> -trk->pal_done++;
> -} else if (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 ||
> - trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK) {
> +if (trk->mode == MODE_MOV && trk->enc->codec_type ==
> AVMEDIA_TYPE_VIDEO) {
> +AVPacket *opkt = pkt;
> +int ret;
> +if (trk->is_unaligned_qt_rgb) {
> +int64_t bpc = trk->enc->bits_per_coded_sample != 15 ?
> trk->enc->bits_per_coded_sample : 16;
> +int expected_stride = ((trk->enc->width * bpc + 15) >> 4)*2;
> +ret = ff_reshuffle_raw_rgb(s, &pkt, trk->enc,
> expected_stride);
> +if (ret < 0)
> +return ret;
> +} else
> +ret = 0;
> +if (trk->enc->pix_fmt == AV_PIX_FMT_PAL8 && !trk->pal_done) {
> +const uint8_t *pal;
> +int ret2 = ff_get_packet_palette(s, opkt, ret, &pal);
> +if (ret2 < 0)
> +return ret2;
> +if (pal) {
> +memcpy(trk->palette, pal, AVPALETTE_SIZE);
this fails on big endian
AV_PKT_DATA_PALETTE is stored in cpu endianness
in general AVPacket->data is defined byte per byte and can be stored
as is byte per byte
AVPacket->side_data is in whatever endianness
people preferred at the time a specific AV_PKT_DATA_* was added.
in case of AV_PKT_DATA_PALETTE its native cpu endianness
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf: allow BSFs to drop packets.
Hi, On Wed, Mar 2, 2016 at 3:51 PM, wm4 wrote: > On Wed, 2 Mar 2016 15:48:11 -0500 > "Ronald S. Bultje" wrote: > > > Hi, > > > > On Mon, Feb 29, 2016 at 10:32 AM, Ronald S. Bultje > > wrote: > > > > > If pkt->size == 0 && pkt->side_data_elems == 0 after bsf->filter() > > > returns, the packet is considered dropped. > > > > > > Ping? > > > > (Personally I'm not so fond of such subtle API changes, also doesn't > Libav's glorious new BSF API cover this?) Possibly, but it's not in yet, is it? (We can revert this piece of code when their new API lands.) Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf: allow BSFs to drop packets.
On Wed, 2 Mar 2016 15:48:11 -0500 "Ronald S. Bultje" wrote: > Hi, > > On Mon, Feb 29, 2016 at 10:32 AM, Ronald S. Bultje > wrote: > > > If pkt->size == 0 && pkt->side_data_elems == 0 after bsf->filter() > > returns, the packet is considered dropped. > > > Ping? > (Personally I'm not so fond of such subtle API changes, also doesn't Libav's glorious new BSF API cover this?) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf: allow BSFs to drop packets.
Hi, On Mon, Feb 29, 2016 at 10:32 AM, Ronald S. Bultje wrote: > If pkt->size == 0 && pkt->side_data_elems == 0 after bsf->filter() > returns, the packet is considered dropped. Ping? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 2/5 v2] lavf/movenc: Add support for palette side data
On Wed, Mar 02, 2016 at 09:24:37PM +0100, Mats Peterson wrote:
> On 03/02/2016 09:23 PM, Mats Peterson wrote:
> >On 03/02/2016 09:21 PM, Michael Niedermayer wrote:
> >>On Wed, Mar 02, 2016 at 08:33:42PM +0100, Mats Peterson wrote:
> >>>Check that the track type is AVMEDIA_TYPE_VIDEO in appropriate places.
> >>>
> >>>--
> >>>Mats Peterson
> >>>http://matsp888.no-ip.org/~mats/
> >>
> >>> movenc.c | 45 +++--
> >>> 1 file changed, 27 insertions(+), 18 deletions(-)
> >>>f2f811cb47f8ba331ca3886ef99239f68aef98a0
> >>>0002-lavf-movenc-Add-support-for-palette-side-data.patch
> >>> From c2d0b7a69486afb926e731216b4aff3b04c4ee4a Mon Sep 17 00:00:00 2001
> >>>From: Mats Peterson
> >>>Date: Wed, 2 Mar 2016 20:30:59 +0100
> >>>Subject: [PATCH v4 2/5 v2] lavf/movenc: Add support for palette side
> >>>data
> >>>
> >>>---
> >>> libavformat/movenc.c | 45
> >>>+++--
> >>> 1 file changed, 27 insertions(+), 18 deletions(-)
> >>>
> >>>diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> >>>index 3295266..277f2d2 100644
> >>>--- a/libavformat/movenc.c
> >>>+++ b/libavformat/movenc.c
> >>>@@ -1716,13 +1716,14 @@ static int mov_write_video_tag(AVIOContext
> >>>*pb, MOVMuxContext *mov, MOVTrack *tr
> >>> else
> >>> avio_wb16(pb, 0x18); /* Reserved */
> >>>
> >>>-if (track->is_unaligned_qt_rgb && track->enc->pix_fmt ==
> >>>AV_PIX_FMT_PAL8) {
> >>>+if (track->mode == MODE_MOV && track->enc->pix_fmt ==
> >>>AV_PIX_FMT_PAL8) {
> >>>+int pal_size = 1 << track->enc->bits_per_coded_sample;
> >>> int i;
> >>> avio_wb16(pb, 0); /* Color table ID */
> >>> avio_wb32(pb, 0); /* Color table seed */
> >>> avio_wb16(pb, 0x8000);/* Color table flags */
> >>>-avio_wb16(pb, 255); /* Color table size
> >>>(zero-relative) */
> >>>-for (i = 0; i < 256; i++) {
> >>>+avio_wb16(pb, pal_size - 1); /* Color table size
> >>>(zero-relative) */
> >>>+for (i = 0; i < pal_size; i++) {
> >>> uint32_t rgb = AV_RL32(&track->palette[i]);
> >>> uint16_t r = (rgb >> 16) & 0xff;
> >>> uint16_t g = (rgb >> 8) & 0xff;
> >>>@@ -4763,21 +4764,29 @@ static int mov_write_packet(AVFormatContext
> >>>*s, AVPacket *pkt)
> >>> }
> >>> }
> >>>
> >>>-if (trk->is_unaligned_qt_rgb) {
> >>>-const uint8_t *data = pkt->data;
> >>>-int size = pkt->size;
> >>>-int64_t bpc = trk->enc->bits_per_coded_sample != 15 ?
> >>>trk->enc->bits_per_coded_sample : 16;
> >>>-int expected_stride = ((trk->enc->width * bpc + 15) >>
> >>>4)*2;
> >>>-int ret = ff_reshuffle_raw_rgb(s, &pkt, trk->enc,
> >>>expected_stride);
> >>>-if (ret < 0)
> >>>-return ret;
> >>>-if (ret == CONTAINS_PAL && !trk->pal_done) {
> >>>-int pal_size = 1 << trk->enc->bits_per_coded_sample;
> >>>-memset(trk->palette, 0, AVPALETTE_SIZE);
> >>>-memcpy(trk->palette, data + size - 4*pal_size,
> >>>4*pal_size);
> >>>-trk->pal_done++;
> >>>-} else if (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 ||
> >>>- trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK) {
> >>>+if (trk->mode == MODE_MOV && trk->enc->codec_type ==
> >>>AVMEDIA_TYPE_VIDEO) {
> >>>+AVPacket *opkt = pkt;
> >>>+int ret;
> >>>+if (trk->is_unaligned_qt_rgb) {
> >>>+int64_t bpc = trk->enc->bits_per_coded_sample != 15
> >>>? trk->enc->bits_per_coded_sample : 16;
> >>>+int expected_stride = ((trk->enc->width * bpc + 15)
> > 4)*2;
> >>>+ret = ff_reshuffle_raw_rgb(s, &pkt, trk->enc,
> >>>expected_stride);
> >>>+if (ret < 0)
> >>>+return ret;
> >>>+} else
> >>>+ret = 0;
> >>>+if (trk->enc->pix_fmt == AV_PIX_FMT_PAL8 &&
> >>>!trk->pal_done) {
> >>
> >>in which cases of compressed (non raw) video does doing something
> >>special for pix_fmt == pal8 fix a problem ?
> >>
> >
> >In several cases. QuickTime RLE in 8-bit mode, QuickTime Graphics (SMC)
> >in 8-bit mode, Microsoft Video 1 (CRAM) in 8-bit mode. All of them use a
> >palette. There are possibly more formats, but these are the ones I can
> >come up with at the moment.
> >
> >Mats
> >
>
> Try stream copy with the files I mentioned in patch 1/5.
ok, will look at them
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No snowflake in an avalanche ever feels responsible. -- Voltaire
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 2/5 v2] lavf/movenc: Add support for palette side data
On Wed, Mar 02, 2016 at 09:23:40PM +0100, Mats Peterson wrote:
> On 03/02/2016 09:21 PM, Michael Niedermayer wrote:
> >On Wed, Mar 02, 2016 at 08:33:42PM +0100, Mats Peterson wrote:
> >>Check that the track type is AVMEDIA_TYPE_VIDEO in appropriate places.
> >>
> >>--
> >>Mats Peterson
> >>http://matsp888.no-ip.org/~mats/
> >
> >> movenc.c | 45 +++--
> >> 1 file changed, 27 insertions(+), 18 deletions(-)
> >>f2f811cb47f8ba331ca3886ef99239f68aef98a0
> >>0002-lavf-movenc-Add-support-for-palette-side-data.patch
> >> From c2d0b7a69486afb926e731216b4aff3b04c4ee4a Mon Sep 17 00:00:00 2001
> >>From: Mats Peterson
> >>Date: Wed, 2 Mar 2016 20:30:59 +0100
> >>Subject: [PATCH v4 2/5 v2] lavf/movenc: Add support for palette side data
> >>
> >>---
> >> libavformat/movenc.c | 45 +++--
> >> 1 file changed, 27 insertions(+), 18 deletions(-)
> >>
> >>diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> >>index 3295266..277f2d2 100644
> >>--- a/libavformat/movenc.c
> >>+++ b/libavformat/movenc.c
> >>@@ -1716,13 +1716,14 @@ static int mov_write_video_tag(AVIOContext *pb,
> >>MOVMuxContext *mov, MOVTrack *tr
> >> else
> >> avio_wb16(pb, 0x18); /* Reserved */
> >>
> >>-if (track->is_unaligned_qt_rgb && track->enc->pix_fmt ==
> >>AV_PIX_FMT_PAL8) {
> >>+if (track->mode == MODE_MOV && track->enc->pix_fmt == AV_PIX_FMT_PAL8)
> >>{
> >>+int pal_size = 1 << track->enc->bits_per_coded_sample;
> >> int i;
> >> avio_wb16(pb, 0); /* Color table ID */
> >> avio_wb32(pb, 0); /* Color table seed */
> >> avio_wb16(pb, 0x8000);/* Color table flags */
> >>-avio_wb16(pb, 255); /* Color table size (zero-relative)
> >>*/
> >>-for (i = 0; i < 256; i++) {
> >>+avio_wb16(pb, pal_size - 1); /* Color table size (zero-relative)
> >>*/
> >>+for (i = 0; i < pal_size; i++) {
> >> uint32_t rgb = AV_RL32(&track->palette[i]);
> >> uint16_t r = (rgb >> 16) & 0xff;
> >> uint16_t g = (rgb >> 8) & 0xff;
> >>@@ -4763,21 +4764,29 @@ static int mov_write_packet(AVFormatContext *s,
> >>AVPacket *pkt)
> >> }
> >> }
> >>
> >>-if (trk->is_unaligned_qt_rgb) {
> >>-const uint8_t *data = pkt->data;
> >>-int size = pkt->size;
> >>-int64_t bpc = trk->enc->bits_per_coded_sample != 15 ?
> >>trk->enc->bits_per_coded_sample : 16;
> >>-int expected_stride = ((trk->enc->width * bpc + 15) >> 4)*2;
> >>-int ret = ff_reshuffle_raw_rgb(s, &pkt, trk->enc,
> >>expected_stride);
> >>-if (ret < 0)
> >>-return ret;
> >>-if (ret == CONTAINS_PAL && !trk->pal_done) {
> >>-int pal_size = 1 << trk->enc->bits_per_coded_sample;
> >>-memset(trk->palette, 0, AVPALETTE_SIZE);
> >>-memcpy(trk->palette, data + size - 4*pal_size, 4*pal_size);
> >>-trk->pal_done++;
> >>-} else if (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 ||
> >>- trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK) {
> >>+if (trk->mode == MODE_MOV && trk->enc->codec_type ==
> >>AVMEDIA_TYPE_VIDEO) {
> >>+AVPacket *opkt = pkt;
> >>+int ret;
> >>+if (trk->is_unaligned_qt_rgb) {
> >>+int64_t bpc = trk->enc->bits_per_coded_sample != 15 ?
> >>trk->enc->bits_per_coded_sample : 16;
> >>+int expected_stride = ((trk->enc->width * bpc + 15) >>
> >>4)*2;
> >>+ret = ff_reshuffle_raw_rgb(s, &pkt, trk->enc,
> >>expected_stride);
> >>+if (ret < 0)
> >>+return ret;
> >>+} else
> >>+ret = 0;
> >>+if (trk->enc->pix_fmt == AV_PIX_FMT_PAL8 && !trk->pal_done) {
> >
> >in which cases of compressed (non raw) video does doing something
> >special for pix_fmt == pal8 fix a problem ?
> >
>
> In several cases. QuickTime RLE in 8-bit mode, QuickTime Graphics
> (SMC) in 8-bit mode, Microsoft Video 1 (CRAM) in 8-bit mode. All of
> them use a palette. There are possibly more formats, but these are
> the ones I can come up with at the moment.
do you have a testcase with command line and small input file?
preferrably a file already in fatesamples ?
iam asking as i think this needs a fate test and its easier for me
to add a test if i have some command line example with all needed
parts
[...]
--
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
___
f
Re: [FFmpeg-devel] [PATCH v4 2/5 v2] lavf/movenc: Add support for palette side data
On 03/02/2016 09:23 PM, Mats Peterson wrote:
On 03/02/2016 09:21 PM, Michael Niedermayer wrote:
On Wed, Mar 02, 2016 at 08:33:42PM +0100, Mats Peterson wrote:
Check that the track type is AVMEDIA_TYPE_VIDEO in appropriate places.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
movenc.c | 45 +++--
1 file changed, 27 insertions(+), 18 deletions(-)
f2f811cb47f8ba331ca3886ef99239f68aef98a0
0002-lavf-movenc-Add-support-for-palette-side-data.patch
From c2d0b7a69486afb926e731216b4aff3b04c4ee4a Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Wed, 2 Mar 2016 20:30:59 +0100
Subject: [PATCH v4 2/5 v2] lavf/movenc: Add support for palette side
data
---
libavformat/movenc.c | 45
+++--
1 file changed, 27 insertions(+), 18 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 3295266..277f2d2 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1716,13 +1716,14 @@ static int mov_write_video_tag(AVIOContext
*pb, MOVMuxContext *mov, MOVTrack *tr
else
avio_wb16(pb, 0x18); /* Reserved */
-if (track->is_unaligned_qt_rgb && track->enc->pix_fmt ==
AV_PIX_FMT_PAL8) {
+if (track->mode == MODE_MOV && track->enc->pix_fmt ==
AV_PIX_FMT_PAL8) {
+int pal_size = 1 << track->enc->bits_per_coded_sample;
int i;
avio_wb16(pb, 0); /* Color table ID */
avio_wb32(pb, 0); /* Color table seed */
avio_wb16(pb, 0x8000);/* Color table flags */
-avio_wb16(pb, 255); /* Color table size
(zero-relative) */
-for (i = 0; i < 256; i++) {
+avio_wb16(pb, pal_size - 1); /* Color table size
(zero-relative) */
+for (i = 0; i < pal_size; i++) {
uint32_t rgb = AV_RL32(&track->palette[i]);
uint16_t r = (rgb >> 16) & 0xff;
uint16_t g = (rgb >> 8) & 0xff;
@@ -4763,21 +4764,29 @@ static int mov_write_packet(AVFormatContext
*s, AVPacket *pkt)
}
}
-if (trk->is_unaligned_qt_rgb) {
-const uint8_t *data = pkt->data;
-int size = pkt->size;
-int64_t bpc = trk->enc->bits_per_coded_sample != 15 ?
trk->enc->bits_per_coded_sample : 16;
-int expected_stride = ((trk->enc->width * bpc + 15) >>
4)*2;
-int ret = ff_reshuffle_raw_rgb(s, &pkt, trk->enc,
expected_stride);
-if (ret < 0)
-return ret;
-if (ret == CONTAINS_PAL && !trk->pal_done) {
-int pal_size = 1 << trk->enc->bits_per_coded_sample;
-memset(trk->palette, 0, AVPALETTE_SIZE);
-memcpy(trk->palette, data + size - 4*pal_size,
4*pal_size);
-trk->pal_done++;
-} else if (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 ||
- trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK) {
+if (trk->mode == MODE_MOV && trk->enc->codec_type ==
AVMEDIA_TYPE_VIDEO) {
+AVPacket *opkt = pkt;
+int ret;
+if (trk->is_unaligned_qt_rgb) {
+int64_t bpc = trk->enc->bits_per_coded_sample != 15
? trk->enc->bits_per_coded_sample : 16;
+int expected_stride = ((trk->enc->width * bpc + 15)
>> 4)*2;
+ret = ff_reshuffle_raw_rgb(s, &pkt, trk->enc,
expected_stride);
+if (ret < 0)
+return ret;
+} else
+ret = 0;
+if (trk->enc->pix_fmt == AV_PIX_FMT_PAL8 &&
!trk->pal_done) {
in which cases of compressed (non raw) video does doing something
special for pix_fmt == pal8 fix a problem ?
In several cases. QuickTime RLE in 8-bit mode, QuickTime Graphics (SMC)
in 8-bit mode, Microsoft Video 1 (CRAM) in 8-bit mode. All of them use a
palette. There are possibly more formats, but these are the ones I can
come up with at the moment.
Mats
Try stream copy with the files I mentioned in patch 1/5.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 2/5 v2] lavf/movenc: Add support for palette side data
On 03/02/2016 09:21 PM, Michael Niedermayer wrote:
On Wed, Mar 02, 2016 at 08:33:42PM +0100, Mats Peterson wrote:
Check that the track type is AVMEDIA_TYPE_VIDEO in appropriate places.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
movenc.c | 45 +++--
1 file changed, 27 insertions(+), 18 deletions(-)
f2f811cb47f8ba331ca3886ef99239f68aef98a0
0002-lavf-movenc-Add-support-for-palette-side-data.patch
From c2d0b7a69486afb926e731216b4aff3b04c4ee4a Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Wed, 2 Mar 2016 20:30:59 +0100
Subject: [PATCH v4 2/5 v2] lavf/movenc: Add support for palette side data
---
libavformat/movenc.c | 45 +++--
1 file changed, 27 insertions(+), 18 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 3295266..277f2d2 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1716,13 +1716,14 @@ static int mov_write_video_tag(AVIOContext *pb,
MOVMuxContext *mov, MOVTrack *tr
else
avio_wb16(pb, 0x18); /* Reserved */
-if (track->is_unaligned_qt_rgb && track->enc->pix_fmt == AV_PIX_FMT_PAL8) {
+if (track->mode == MODE_MOV && track->enc->pix_fmt == AV_PIX_FMT_PAL8) {
+int pal_size = 1 << track->enc->bits_per_coded_sample;
int i;
avio_wb16(pb, 0); /* Color table ID */
avio_wb32(pb, 0); /* Color table seed */
avio_wb16(pb, 0x8000);/* Color table flags */
-avio_wb16(pb, 255); /* Color table size (zero-relative) */
-for (i = 0; i < 256; i++) {
+avio_wb16(pb, pal_size - 1); /* Color table size (zero-relative) */
+for (i = 0; i < pal_size; i++) {
uint32_t rgb = AV_RL32(&track->palette[i]);
uint16_t r = (rgb >> 16) & 0xff;
uint16_t g = (rgb >> 8) & 0xff;
@@ -4763,21 +4764,29 @@ static int mov_write_packet(AVFormatContext *s,
AVPacket *pkt)
}
}
-if (trk->is_unaligned_qt_rgb) {
-const uint8_t *data = pkt->data;
-int size = pkt->size;
-int64_t bpc = trk->enc->bits_per_coded_sample != 15 ?
trk->enc->bits_per_coded_sample : 16;
-int expected_stride = ((trk->enc->width * bpc + 15) >> 4)*2;
-int ret = ff_reshuffle_raw_rgb(s, &pkt, trk->enc, expected_stride);
-if (ret < 0)
-return ret;
-if (ret == CONTAINS_PAL && !trk->pal_done) {
-int pal_size = 1 << trk->enc->bits_per_coded_sample;
-memset(trk->palette, 0, AVPALETTE_SIZE);
-memcpy(trk->palette, data + size - 4*pal_size, 4*pal_size);
-trk->pal_done++;
-} else if (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 ||
- trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK) {
+if (trk->mode == MODE_MOV && trk->enc->codec_type ==
AVMEDIA_TYPE_VIDEO) {
+AVPacket *opkt = pkt;
+int ret;
+if (trk->is_unaligned_qt_rgb) {
+int64_t bpc = trk->enc->bits_per_coded_sample != 15 ?
trk->enc->bits_per_coded_sample : 16;
+int expected_stride = ((trk->enc->width * bpc + 15) >> 4)*2;
+ret = ff_reshuffle_raw_rgb(s, &pkt, trk->enc, expected_stride);
+if (ret < 0)
+return ret;
+} else
+ret = 0;
+if (trk->enc->pix_fmt == AV_PIX_FMT_PAL8 && !trk->pal_done) {
in which cases of compressed (non raw) video does doing something
special for pix_fmt == pal8 fix a problem ?
In several cases. QuickTime RLE in 8-bit mode, QuickTime Graphics (SMC)
in 8-bit mode, Microsoft Video 1 (CRAM) in 8-bit mode. All of them use a
palette. There are possibly more formats, but these are the ones I can
come up with at the moment.
Mats
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 2/5 v2] lavf/movenc: Add support for palette side data
On Wed, Mar 02, 2016 at 08:33:42PM +0100, Mats Peterson wrote:
> Check that the track type is AVMEDIA_TYPE_VIDEO in appropriate places.
>
> --
> Mats Peterson
> http://matsp888.no-ip.org/~mats/
> movenc.c | 45 +++--
> 1 file changed, 27 insertions(+), 18 deletions(-)
> f2f811cb47f8ba331ca3886ef99239f68aef98a0
> 0002-lavf-movenc-Add-support-for-palette-side-data.patch
> From c2d0b7a69486afb926e731216b4aff3b04c4ee4a Mon Sep 17 00:00:00 2001
> From: Mats Peterson
> Date: Wed, 2 Mar 2016 20:30:59 +0100
> Subject: [PATCH v4 2/5 v2] lavf/movenc: Add support for palette side data
>
> ---
> libavformat/movenc.c | 45 +++--
> 1 file changed, 27 insertions(+), 18 deletions(-)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 3295266..277f2d2 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -1716,13 +1716,14 @@ static int mov_write_video_tag(AVIOContext *pb,
> MOVMuxContext *mov, MOVTrack *tr
> else
> avio_wb16(pb, 0x18); /* Reserved */
>
> -if (track->is_unaligned_qt_rgb && track->enc->pix_fmt ==
> AV_PIX_FMT_PAL8) {
> +if (track->mode == MODE_MOV && track->enc->pix_fmt == AV_PIX_FMT_PAL8) {
> +int pal_size = 1 << track->enc->bits_per_coded_sample;
> int i;
> avio_wb16(pb, 0); /* Color table ID */
> avio_wb32(pb, 0); /* Color table seed */
> avio_wb16(pb, 0x8000);/* Color table flags */
> -avio_wb16(pb, 255); /* Color table size (zero-relative) */
> -for (i = 0; i < 256; i++) {
> +avio_wb16(pb, pal_size - 1); /* Color table size (zero-relative) */
> +for (i = 0; i < pal_size; i++) {
> uint32_t rgb = AV_RL32(&track->palette[i]);
> uint16_t r = (rgb >> 16) & 0xff;
> uint16_t g = (rgb >> 8) & 0xff;
> @@ -4763,21 +4764,29 @@ static int mov_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> }
> }
>
> -if (trk->is_unaligned_qt_rgb) {
> -const uint8_t *data = pkt->data;
> -int size = pkt->size;
> -int64_t bpc = trk->enc->bits_per_coded_sample != 15 ?
> trk->enc->bits_per_coded_sample : 16;
> -int expected_stride = ((trk->enc->width * bpc + 15) >> 4)*2;
> -int ret = ff_reshuffle_raw_rgb(s, &pkt, trk->enc,
> expected_stride);
> -if (ret < 0)
> -return ret;
> -if (ret == CONTAINS_PAL && !trk->pal_done) {
> -int pal_size = 1 << trk->enc->bits_per_coded_sample;
> -memset(trk->palette, 0, AVPALETTE_SIZE);
> -memcpy(trk->palette, data + size - 4*pal_size, 4*pal_size);
> -trk->pal_done++;
> -} else if (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 ||
> - trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK) {
> +if (trk->mode == MODE_MOV && trk->enc->codec_type ==
> AVMEDIA_TYPE_VIDEO) {
> +AVPacket *opkt = pkt;
> +int ret;
> +if (trk->is_unaligned_qt_rgb) {
> +int64_t bpc = trk->enc->bits_per_coded_sample != 15 ?
> trk->enc->bits_per_coded_sample : 16;
> +int expected_stride = ((trk->enc->width * bpc + 15) >> 4)*2;
> +ret = ff_reshuffle_raw_rgb(s, &pkt, trk->enc,
> expected_stride);
> +if (ret < 0)
> +return ret;
> +} else
> +ret = 0;
> +if (trk->enc->pix_fmt == AV_PIX_FMT_PAL8 && !trk->pal_done) {
in which cases of compressed (non raw) video does doing something
special for pix_fmt == pal8 fix a problem ?
do you have a testcase for that ?
same question for avi
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v10] VideoToolbox H.264 Encoder
On Wed, 2 Mar 2016 20:11:40 +0800 Rick Kern wrote: > Autodetected by default. Encode using -codec:v h264_videotoolbox. > > Signed-off-by: Rick Kern > --- Applied. Thanks, and sorry for the delays/revisions. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FLIC in AVI
On 03/02/2016 09:18 PM, Mats Peterson wrote: On 03/02/2016 09:16 PM, Mats Peterson wrote: On 03/02/2016 09:02 PM, Paul B Mahol wrote: On 3/2/16, Mats Peterson wrote: On 03/02/2016 08:45 PM, Paul B Mahol wrote: On 3/2/16, Mats Peterson wrote: I noticed that you, Paul, added a patch somewhere in 2012 with the purpose of making it possible to use FLI(C) in AVI. It doesn't work very well in my book. Try the following command with the file below: There is trac for bug reporting always available. I thought it was OK to mention it "through the back door" :) It would be nice if you could look into it. My memory is limited, I forget new things very fast. Its general PAL8 issue with any format not just this specific case. ___ No, it's format specific. Most, if not all, pal8 issues have been remedied by my recent patches. 3DMORPH.FLI: Input/output error frame=0 fps=0.0 q=-1.0 Lsize= 6kB time=00:00:00.00 bitrate=N/A speed= 0x video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used) Perhaps it's only able to *play back* FLIC in AVI so far? Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FLIC in AVI
On 03/02/2016 09:16 PM, Mats Peterson wrote: On 03/02/2016 09:02 PM, Paul B Mahol wrote: On 3/2/16, Mats Peterson wrote: On 03/02/2016 08:45 PM, Paul B Mahol wrote: On 3/2/16, Mats Peterson wrote: I noticed that you, Paul, added a patch somewhere in 2012 with the purpose of making it possible to use FLI(C) in AVI. It doesn't work very well in my book. Try the following command with the file below: There is trac for bug reporting always available. I thought it was OK to mention it "through the back door" :) It would be nice if you could look into it. My memory is limited, I forget new things very fast. Its general PAL8 issue with any format not just this specific case. ___ No, it's format specific. Most, if not all, pal8 issues have been remedied by my recent patches. 3DMORPH.FLI: Input/output error frame=0 fps=0.0 q=-1.0 Lsize= 6kB time=00:00:00.00 bitrate=N/A speed= 0x video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used) -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FLIC in AVI
On 03/02/2016 09:02 PM, Paul B Mahol wrote: On 3/2/16, Mats Peterson wrote: On 03/02/2016 08:45 PM, Paul B Mahol wrote: On 3/2/16, Mats Peterson wrote: I noticed that you, Paul, added a patch somewhere in 2012 with the purpose of making it possible to use FLI(C) in AVI. It doesn't work very well in my book. Try the following command with the file below: There is trac for bug reporting always available. I thought it was OK to mention it "through the back door" :) It would be nice if you could look into it. My memory is limited, I forget new things very fast. Its general PAL8 issue with any format not just this specific case. ___ No, it's format specific. Most, if not all, pal8 issues have been remedied by my recent patches. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/y4m: fix seeking in partial files
Hi,
patch attached.
From af75cff37a296072fad21648459b4e005ce1afc6 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Wed, 2 Mar 2016 20:56:01 +0100
Subject: [PATCH] avformat/yuv4mpegdec: fix seeking for partial files
Signed-off-by: Paul B Mahol
---
libavformat/yuv4mpegdec.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavformat/yuv4mpegdec.c b/libavformat/yuv4mpegdec.c
index ea1ae25..5d338c2 100644
--- a/libavformat/yuv4mpegdec.c
+++ b/libavformat/yuv4mpegdec.c
@@ -307,8 +307,7 @@ static int yuv4_read_packet(AVFormatContext *s, AVPacket *pkt)
static int yuv4_read_seek(AVFormatContext *s, int stream_index,
int64_t pts, int flags)
{
-avio_seek(s->pb, pts * s->packet_size + s->internal->data_offset, SEEK_SET);
-return 0;
+return avio_seek(s->pb, pts * s->packet_size + s->internal->data_offset, SEEK_SET);
}
static int yuv4_probe(AVProbeData *pd)
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FLIC in AVI
On 3/2/16, Mats Peterson wrote: > On 03/02/2016 08:45 PM, Paul B Mahol wrote: >> On 3/2/16, Mats Peterson wrote: >>> I noticed that you, Paul, added a patch somewhere in 2012 with the >>> purpose of making it possible to use FLI(C) in AVI. It doesn't work very >>> well in my book. Try the following command with the file below: >> >> There is trac for bug reporting always available. > > I thought it was OK to mention it "through the back door" :) It would be > nice if you could look into it. My memory is limited, I forget new things very fast. Its general PAL8 issue with any format not just this specific case. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FLIC in AVI
On 03/02/2016 08:45 PM, Paul B Mahol wrote: On 3/2/16, Mats Peterson wrote: I noticed that you, Paul, added a patch somewhere in 2012 with the purpose of making it possible to use FLI(C) in AVI. It doesn't work very well in my book. Try the following command with the file below: There is trac for bug reporting always available. I thought it was OK to mention it "through the back door" :) It would be nice if you could look into it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] avcodec/dca: clear X96 channels if nothing was decoded
The first X96 channel set can have more channels than core, causing X96
decoding to be skipped. Clear the number of decoded X96 channels to zero
in this rudimentary case.
---
libavcodec/dca_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/dca_core.c b/libavcodec/dca_core.c
index 48a8f61..d9f1a4c 100644
--- a/libavcodec/dca_core.c
+++ b/libavcodec/dca_core.c
@@ -1760,6 +1760,7 @@ static int parse_x96_frame_exss(DCACoreDecoder *s)
return ret;
// Channel set data
+s->x96_nchannels = 0;
for (i = 0, x96_base_ch = 0; i < x96_nchsets; i++) {
header_pos = get_bits_count(&s->gb);
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FLIC in AVI
On 3/2/16, Mats Peterson wrote: > I noticed that you, Paul, added a patch somewhere in 2012 with the > purpose of making it possible to use FLI(C) in AVI. It doesn't work very > well in my book. Try the following command with the file below: There is trac for bug reporting always available. > > ffmpeg -i 3DMORPH.FLI -vcodec copy 3dmorph.avi > > File: > https://drive.google.com/open?id=0B3_pEBoLs0faNWRLc2tYLVAzWG8 > > Mats > > -- > Mats Peterson > http://matsp888.no-ip.org/~mats/ > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v4 2/5 v2] lavf/movenc: Add support for palette side data
Check that the track type is AVMEDIA_TYPE_VIDEO in appropriate places.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From c2d0b7a69486afb926e731216b4aff3b04c4ee4a Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Wed, 2 Mar 2016 20:30:59 +0100
Subject: [PATCH v4 2/5 v2] lavf/movenc: Add support for palette side data
---
libavformat/movenc.c | 45 +++--
1 file changed, 27 insertions(+), 18 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 3295266..277f2d2 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1716,13 +1716,14 @@ static int mov_write_video_tag(AVIOContext *pb, MOVMuxContext *mov, MOVTrack *tr
else
avio_wb16(pb, 0x18); /* Reserved */
-if (track->is_unaligned_qt_rgb && track->enc->pix_fmt == AV_PIX_FMT_PAL8) {
+if (track->mode == MODE_MOV && track->enc->pix_fmt == AV_PIX_FMT_PAL8) {
+int pal_size = 1 << track->enc->bits_per_coded_sample;
int i;
avio_wb16(pb, 0); /* Color table ID */
avio_wb32(pb, 0); /* Color table seed */
avio_wb16(pb, 0x8000);/* Color table flags */
-avio_wb16(pb, 255); /* Color table size (zero-relative) */
-for (i = 0; i < 256; i++) {
+avio_wb16(pb, pal_size - 1); /* Color table size (zero-relative) */
+for (i = 0; i < pal_size; i++) {
uint32_t rgb = AV_RL32(&track->palette[i]);
uint16_t r = (rgb >> 16) & 0xff;
uint16_t g = (rgb >> 8) & 0xff;
@@ -4763,21 +4764,29 @@ static int mov_write_packet(AVFormatContext *s, AVPacket *pkt)
}
}
-if (trk->is_unaligned_qt_rgb) {
-const uint8_t *data = pkt->data;
-int size = pkt->size;
-int64_t bpc = trk->enc->bits_per_coded_sample != 15 ? trk->enc->bits_per_coded_sample : 16;
-int expected_stride = ((trk->enc->width * bpc + 15) >> 4)*2;
-int ret = ff_reshuffle_raw_rgb(s, &pkt, trk->enc, expected_stride);
-if (ret < 0)
-return ret;
-if (ret == CONTAINS_PAL && !trk->pal_done) {
-int pal_size = 1 << trk->enc->bits_per_coded_sample;
-memset(trk->palette, 0, AVPALETTE_SIZE);
-memcpy(trk->palette, data + size - 4*pal_size, 4*pal_size);
-trk->pal_done++;
-} else if (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 ||
- trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK) {
+if (trk->mode == MODE_MOV && trk->enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+AVPacket *opkt = pkt;
+int ret;
+if (trk->is_unaligned_qt_rgb) {
+int64_t bpc = trk->enc->bits_per_coded_sample != 15 ? trk->enc->bits_per_coded_sample : 16;
+int expected_stride = ((trk->enc->width * bpc + 15) >> 4)*2;
+ret = ff_reshuffle_raw_rgb(s, &pkt, trk->enc, expected_stride);
+if (ret < 0)
+return ret;
+} else
+ret = 0;
+if (trk->enc->pix_fmt == AV_PIX_FMT_PAL8 && !trk->pal_done) {
+const uint8_t *pal;
+int ret2 = ff_get_packet_palette(s, opkt, ret, &pal);
+if (ret2 < 0)
+return ret2;
+if (pal) {
+memcpy(trk->palette, pal, AVPALETTE_SIZE);
+trk->pal_done++;
+}
+} else if (trk->enc->codec_id == AV_CODEC_ID_RAWVIDEO &&
+ (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 ||
+ trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK)) {
for (i = 0; i < pkt->size; i++)
pkt->data[i] = ~pkt->data[i];
}
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v4 1/5 v2] lavf/avienc: Add support for palette side data
Check that the track type is AVMEDIA_TYPE_VIDEO in appropriate places.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 719c9d9ed312da81499c9fef589af24595c3228b Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Wed, 2 Mar 2016 20:30:47 +0100
Subject: [PATCH v4 1/5 v2] lavf/avienc: Add support for palette side data
---
libavformat/avienc.c | 50 +-
1 file changed, 33 insertions(+), 17 deletions(-)
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ca505f4..888d062 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -362,7 +362,8 @@ static int avi_write_header(AVFormatContext *s)
&& enc->pix_fmt == AV_PIX_FMT_RGB555LE
&& enc->bits_per_coded_sample == 15)
enc->bits_per_coded_sample = 16;
-avist->pal_offset = avio_tell(pb) + 40;
+if (pb->seekable)
+avist->pal_offset = avio_tell(pb) + 40;
ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0, 0);
pix_fmt = avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi,
enc->bits_per_coded_sample);
@@ -652,11 +653,11 @@ 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;
AVIStream *avist= s->streams[stream_index]->priv_data;
+AVPacket *opkt = pkt;
+enum AVPixelFormat pix_fmt = enc->pix_fmt;
int ret;
if (enc->codec_id == AV_CODEC_ID_H264 && enc->codec_tag == MKTAG('H','2','6','4') && pkt->size) {
@@ -668,22 +669,35 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
if ((ret = write_skip_frames(s, stream_index, pkt->dts)) < 0)
return ret;
-if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) {
-int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
-int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
-
-ret = ff_reshuffle_raw_rgb(s, &pkt, enc, expected_stride);
-if (ret < 0)
-return ret;
-if (ret) {
-if (ret == CONTAINS_PAL) {
-int pc_tag, i;
+if (!pkt->size)
+return avi_write_packet_internal(s, pkt); /* Passthrough */
+
+if (enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) {
+int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
+int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
+ret = ff_reshuffle_raw_rgb(s, &pkt, enc, expected_stride);
+if (ret < 0)
+return ret;
+} else
+ret = 0;
+if (pix_fmt == AV_PIX_FMT_NONE && enc->bits_per_coded_sample == 1)
+pix_fmt = AV_PIX_FMT_MONOWHITE;
+if (pix_fmt == AV_PIX_FMT_PAL8 ||
+pix_fmt == AV_PIX_FMT_MONOWHITE ||
+pix_fmt == AV_PIX_FMT_MONOBLACK) {
+const uint8_t *pal;
+int ret2 = ff_get_packet_palette(s, opkt, ret, &pal);
+if (ret2 < 0)
+return ret2;
+if (pal) {
int pal_size = 1 << enc->bits_per_coded_sample;
-if (!avist->hdr_pal_done) {
-int64_t cur_offset = avio_tell(pb);
+int pc_tag, i;
+if (pb->seekable && !avist->hdr_pal_done) {
+int64_t cur_offset = avio_tell(pb);
avio_seek(pb, avist->pal_offset, SEEK_SET);
for (i = 0; i < pal_size; i++) {
-uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
+uint32_t v = AV_RL32(pal + 4*i);
avio_wl32(pb, v & 0xff);
}
avio_seek(pb, cur_offset, SEEK_SET);
@@ -696,11 +710,13 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
avio_w8(pb, pal_size & 0xFF);
avio_wl16(pb, 0); // reserved
for (i = 0; i < pal_size; i++) {
-uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
+uint32_t v = AV_RL32(pal + 4*i);
avio_wb32(pb, v<<8);
}
ff_end_tag(pb, pc_tag);
}
+}
+if (ret) {
ret = avi_write_packet_internal(s, pkt);
av_packet_free(&pkt);
return ret;
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacenc: avoid double in quantize_bands.
On 1 March 2016 at 21:55, Reimar Döffinger wrote:
> I cannot see any point whatsoever to use
> double here instead of float.
> Using float allows for use of SIMD.
> ---
> libavcodec/aacenc_utils.h | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/aacenc_utils.h b/libavcodec/aacenc_utils.h
> index cb5bc8d..571b1e6 100644
> --- a/libavcodec/aacenc_utils.h
> +++ b/libavcodec/aacenc_utils.h
> @@ -66,10 +66,9 @@ static inline void quantize_bands(int *out, const float
> *in, const float *scaled
>const float rounding)
> {
> int i;
> -double qc;
> for (i = 0; i < size; i++) {
> -qc = scaled[i] * Q34;
> -out[i] = (int)FFMIN(qc + rounding, (double)maxval);
> +float qc = scaled[i] * Q34;
> +out[i] = (int)FFMIN(qc + rounding, (float)maxval);
> if (is_signed && in[i] < 0.0f) {
> out[i] = -out[i];
> }
> --
>
You could just avoid the whole need for qc and just do "FFMIN((scaled[i] *
Q34) + rounding, (float)maxval));". We have plenty of space and I think it
would look neater.
But up to you to decide, either way it looks good to me, doesn't change
anything. Feel free to push if you can.
Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] avcodec/dca: make reading past end of buffer safe
Limit the maximum length of unary part of Rice code by the number of
available bits instead of using an arbitrary constant that happens to be
just large enough to work.
This effectively limits amount of data that can be overread per segment
by maximum length of binary code per sample multiplied by maximum
segment size.
Increase size of padding area after the end of input buffer according to
this limit and add some extra overread checks to make reading past end
of buffer safe.
---
libavcodec/dca_xll.c | 25 +++--
libavcodec/dcadec.h | 2 +-
2 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/libavcodec/dca_xll.c b/libavcodec/dca_xll.c
index 5e6cf35..46bef3d 100644
--- a/libavcodec/dca_xll.c
+++ b/libavcodec/dca_xll.c
@@ -32,7 +32,7 @@ static int get_linear(GetBitContext *gb, int n)
static int get_rice_un(GetBitContext *gb, int k)
{
-unsigned int v = get_unary(gb, 1, 128);
+unsigned int v = get_unary(gb, 1, get_bits_left(gb));
return (v << k) | get_bits_long(gb, k);
}
@@ -512,7 +512,7 @@ static int chs_parse_band_data(DCAXllDecoder *s,
DCAXllChSet *c, int band, int s
nsamples_part_b = s->nsegsamples - c->nsamples_part_a[k];
if (get_bits_left(&s->gb) < 0)
-return AVERROR_INVALIDDATA;
+goto overread;
if (!c->rice_code_flag[k]) {
// Linear codes
@@ -534,6 +534,9 @@ static int chs_parse_band_data(DCAXllDecoder *s,
DCAXllChSet *c, int band, int s
// Unpack the number of isolated samples
int nisosamples = get_bits(&s->gb, s->nsegsamples_log2);
+if (get_bits_left(&s->gb) < nisosamples * s->nsegsamples_log2)
+goto overread;
+
// Set all locations to 0
memset(part_b, 0, sizeof(*part_b) * nsamples_part_b);
@@ -573,14 +576,14 @@ static int chs_parse_band_data(DCAXllDecoder *s,
DCAXllChSet *c, int band, int s
// Start unpacking LSB portion of the segment
if (b->lsb_section_size) {
// Skip to the start of LSB portion
-if (ff_dca_seek_bits(&s->gb, band_data_end - b->lsb_section_size * 8))
{
-av_log(s->avctx, AV_LOG_ERROR, "Read past end of XLL band data\n");
-return AVERROR_INVALIDDATA;
-}
+if (ff_dca_seek_bits(&s->gb, band_data_end - b->lsb_section_size * 8))
+goto overread;
// Unpack all LSB parts of residuals of this segment
for (i = 0; i < c->nchannels; i++) {
if (b->nscalablelsbs[i]) {
+if (get_bits_left(&s->gb) < 0)
+goto overread;
get_array(&s->gb,
b->lsb_sample_buffer[i] + seg * s->nsegsamples,
s->nsegsamples, b->nscalablelsbs[i]);
@@ -589,12 +592,14 @@ static int chs_parse_band_data(DCAXllDecoder *s,
DCAXllChSet *c, int band, int s
}
// Skip to the end of band data
-if (ff_dca_seek_bits(&s->gb, band_data_end)) {
-av_log(s->avctx, AV_LOG_ERROR, "Read past end of XLL band data\n");
-return AVERROR_INVALIDDATA;
-}
+if (ff_dca_seek_bits(&s->gb, band_data_end))
+goto overread;
return 0;
+
+overread:
+av_log(s->avctx, AV_LOG_ERROR, "Read past end of XLL band data\n");
+return AVERROR_INVALIDDATA;
}
static av_cold void chs_clear_band_data(DCAXllDecoder *s, DCAXllChSet *c, int
band, int seg)
diff --git a/libavcodec/dcadec.h b/libavcodec/dcadec.h
index 6726121..2805a0e 100644
--- a/libavcodec/dcadec.h
+++ b/libavcodec/dcadec.h
@@ -32,7 +32,7 @@
#include "dca_exss.h"
#include "dca_xll.h"
-#define DCA_BUFFER_PADDING_SIZE 1024
+#define DCA_BUFFER_PADDING_SIZE 2048
#define DCA_PACKET_CORE 0x01
#define DCA_PACKET_EXSS 0x02
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] avcodec/dca: fix av_cold placement in declarations
---
libavcodec/dca_xll.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dca_xll.c b/libavcodec/dca_xll.c
index cd1af81..ffe8ef3 100644
--- a/libavcodec/dca_xll.c
+++ b/libavcodec/dca_xll.c
@@ -602,7 +602,7 @@ static int chs_parse_band_data(DCAXllDecoder *s,
DCAXllChSet *c, int band, int s
return 0;
}
-static void av_cold chs_clear_band_data(DCAXllDecoder *s, DCAXllChSet *c, int
band, int seg)
+static av_cold void chs_clear_band_data(DCAXllDecoder *s, DCAXllChSet *c, int
band, int seg)
{
DCAXllBand *b = &c->bands[band];
int i, offset, nsamples;
@@ -1242,7 +1242,7 @@ static void scale_down_mix(DCAXllDecoder *s, DCAXllChSet
*o, int band)
// Clear all band data and replace non-residual encoded channels with lossy
// counterparts
-static void av_cold force_lossy_output(DCAXllDecoder *s, DCAXllChSet *c)
+static av_cold void force_lossy_output(DCAXllDecoder *s, DCAXllChSet *c)
{
DCAContext *dca = s->avctx->priv_data;
int band, ch;
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] avcodec/dca: simplify condition
---
libavcodec/dca_xll.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/libavcodec/dca_xll.c b/libavcodec/dca_xll.c
index ffe8ef3..5e6cf35 100644
--- a/libavcodec/dca_xll.c
+++ b/libavcodec/dca_xll.c
@@ -460,19 +460,14 @@ static int chs_parse_band_data(DCAXllDecoder *s,
DCAXllChSet *c, int band, int s
// Unpack Rice coding flag
// 0 - linear code, 1 - Rice code
c->rice_code_flag[i] = get_bits1(&s->gb);
-if (!c->seg_common && c->rice_code_flag[i]) {
-// Unpack Hybrid Rice coding flag
-// 0 - Rice code, 1 - Hybrid Rice code
-if (get_bits1(&s->gb))
-// Unpack binary code length for isolated samples
-c->bitalloc_hybrid_linear[i] = get_bits(&s->gb, c->nabits)
+ 1;
-else
-// 0 indicates no Hybrid Rice coding
-c->bitalloc_hybrid_linear[i] = 0;
-} else {
+// Unpack Hybrid Rice coding flag
+// 0 - Rice code, 1 - Hybrid Rice code
+if (!c->seg_common && c->rice_code_flag[i] && get_bits1(&s->gb))
+// Unpack binary code length for isolated samples
+c->bitalloc_hybrid_linear[i] = get_bits(&s->gb, c->nabits) + 1;
+else
// 0 indicates no Hybrid Rice coding
c->bitalloc_hybrid_linear[i] = 0;
-}
}
// Unpack coding parameters
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/4] DCA decoder fixes
This fixes some potential issues I've identified within new DCA decoder. It is probably a good idea to backport these patches into 3.0 release branch. foo86 (4): avcodec/dca: clear X96 channels if nothing was decoded avcodec/dca: fix av_cold placement in declarations avcodec/dca: simplify condition avcodec/dca: make reading past end of buffer safe libavcodec/dca_core.c | 1 + libavcodec/dca_xll.c | 46 +++--- libavcodec/dcadec.h | 2 +- 3 files changed, 25 insertions(+), 24 deletions(-) -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacenc: optimize cost cache.
On 1 March 2016 at 23:34, Reimar Döffinger wrote:
> Avoids trashing the CPU cache each time the
> cost cache is cleared.
> ---
> libavcodec/aaccoder_twoloop.h | 20
> libavcodec/aacenc.c | 7 +--
> libavcodec/aacenc.h | 4 +---
> libavcodec/aacenc_quantization_misc.h | 17 +++--
> 4 files changed, 13 insertions(+), 35 deletions(-)
>
> diff --git a/libavcodec/aaccoder_twoloop.h b/libavcodec/aaccoder_twoloop.h
> index 397a4db..73bd082 100644
> --- a/libavcodec/aaccoder_twoloop.h
> +++ b/libavcodec/aaccoder_twoloop.h
> @@ -391,10 +391,7 @@ static void
> search_for_quantizers_twoloop(AVCodecContext *avctx,
> sce->ics.swb_sizes[g],
> sce->sf_idx[w*16+g],
> cb,
> - 1.0f,
> - INFINITY,
> - &b, &sqenergy,
> - 0);
> + &b, &sqenergy);
> bits += b;
> qenergy += sqenergy;
> }
> @@ -472,10 +469,7 @@ static void
> search_for_quantizers_twoloop(AVCodecContext *avctx,
> sce->ics.swb_sizes[g],
> sce->sf_idx[w*16+g],
> cb,
> -1.0f,
> -INFINITY,
> -&b, &sqenergy,
> -0);
> +&b, &sqenergy);
> bits += b;
> qenergy += sqenergy;
> }
> @@ -628,10 +622,7 @@ static void
> search_for_quantizers_twoloop(AVCodecContext *avctx,
>
> sce->ics.swb_sizes[g],
>
> sce->sf_idx[w*16+g]-1,
> cb,
> -1.0f,
> -INFINITY,
> -&b, &sqenergy,
> -0);
> +&b, &sqenergy);
> bits += b;
> qenergy += sqenergy;
> }
> @@ -665,10 +656,7 @@ static void
> search_for_quantizers_twoloop(AVCodecContext *avctx,
>
> sce->ics.swb_sizes[g],
>
> sce->sf_idx[w*16+g]+1,
> cb,
> -1.0f,
> -INFINITY,
> -&b, &sqenergy,
> -0);
> +&b,
> &sqenergy);
> bits += b;
> qenergy += sqenergy;
> }
> diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
> index 5a70da1..e60bbfe 100644
> --- a/libavcodec/aacenc.c
> +++ b/libavcodec/aacenc.c
> @@ -78,12 +78,7 @@ static void put_audio_specific_config(AVCodecContext
> *avctx)
>
> void ff_quantize_band_cost_cache_init(struct AACEncContext *s)
> {
> -int sf, g;
> -for (sf = 0; sf < 256; sf++) {
> -for (g = 0; g < 128; g++) {
> -s->quantize_band_cost_cache[sf][g].bits = -1;
> -}
> -}
> +memset(s->quantize_band_cost_cache_state, 0xff,
> sizeof(s->quantize_band_cost_cache_state));
> }
>
> #define WINDOW_FUNC(type) \
> diff --git a/libavcodec/aacenc.h b/libavcodec/aacenc.h
> index 2252e29..d937d17 100644
> --- a/libavcodec/aacenc.h
> +++ b/libavcodec/aacenc.h
> @@ -85,9 +85,6 @@ typedef struct AACQuantizeBandCostCacheEntry {
> float rd;
> float energy;
> int bits; ///< -1 means uninitialized entry
> -char cb;
> -char rtz;
> -char padding[2]; ///< Keeps the entry size a multiple of 32 bits
> } AACQuantizeBandCostCacheEntry;
>
> /**
> @@ -126,6 +123,7 @@ typedef struct AACEncContext {
> DECLARE_ALIGNED(16, int, qcoefs)[96]; ///< quantized
> coefficients
> DECLARE_ALIGNED(32, float, scoefs)[1024];///< scaled coefficients
>
> +uint8_t quantize_band_cost_cache_state[256][128];
> AACQuantizeBandCostCacheEntry quantize_band_cost_cache[256][128];
> ///< memoization area for quantize_band_cost
>
> struct {
> diff --git
Re: [FFmpeg-devel] [PATCH]concatdec: measure duration when it is not available
2016.03.01. 11:26 keltezéssel, Michael Niedermayer írta: On Tue, Mar 01, 2016 at 10:57:57AM +0100, Nicolas George wrote: Le nonidi 29 pluviôse, an CCXXIV, Bodecs Bela a écrit : I have checked the code where and when duration filled and made some reasoning about it. Duration value for input files has been populated some time after opening. (estimate_timings function in utils.c) And never again corrected or called this function.. So, if early in processing there is no duration info, it remains empty. When input is not a seekable file but a not-seekable stream, the only chance to get a duration info when the stream itself contains info about this value. (eg. flv metadata, mp4-moov) But mpegts format does not contain this info. So the only moment when duration calculatable is when we finish the reading. I think contoniously updating the duration value after each packet would not be a good idea. (cur_dts is updated is AVStream->info struct) So reading a file via pipe or reading hls stream via http it is normal that duration value remains empty. thus, I think to handle the cases when duration value is not populated, this is not a bug fix but a reasonable solution for these cases. I agree with you that we should not "measure" our-own the pts values but I could not find any existing/available data member to have this info. Sorry for the late reply, I was distracted. If I summarize correctly your findings: For formats without a reliable duration header with seekable backing, the duration is evaluated at the opening by peeking at the last timestamps. With unseekable backing, the duration is not evaluated at all. In particular, the duration is not updated once the end of the file is reached. Well, I thought it was and wrote the code in consequence, thanks for correcting me. Still, the logic for tracking the duration can be a bit tricky, possibly trickier than your original patch if there are B-frames and timestamps resets. I would rather have it in a common part of the code than in the concat demuxer. I suspect we could consider adding AVStream.current_duration that tracks the maximum recently seen PTS for each stream. (We could also have a function that peeks in AVStream.pts_buffer, but that looks tricky; and the corresponding duration is not available.) I hope other can give advice about this issue. somewhat independant of this, but i thik some kind of "indexer" input would be usefull i mean a input format that opens another input and sequentially reads the whole at open and creates an index with that exact seeking, exact bitrate, exact duration would become available. the index could also be stored in a on disk cache if the user wants making repeated opening of the same file not require sequentially scaning the whole [...] like a lookup map ___ 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]concatdec: measure duration when it is not available
2016.03.01. 10:57 keltezéssel, Nicolas George írta: Le nonidi 29 pluviôse, an CCXXIV, Bodecs Bela a écrit : I have checked the code where and when duration filled and made some reasoning about it. Duration value for input files has been populated some time after opening. (estimate_timings function in utils.c) And never again corrected or called this function.. So, if early in processing there is no duration info, it remains empty. When input is not a seekable file but a not-seekable stream, the only chance to get a duration info when the stream itself contains info about this value. (eg. flv metadata, mp4-moov) But mpegts format does not contain this info. So the only moment when duration calculatable is when we finish the reading. I think contoniously updating the duration value after each packet would not be a good idea. (cur_dts is updated is AVStream->info struct) So reading a file via pipe or reading hls stream via http it is normal that duration value remains empty. thus, I think to handle the cases when duration value is not populated, this is not a bug fix but a reasonable solution for these cases. I agree with you that we should not "measure" our-own the pts values but I could not find any existing/available data member to have this info. Sorry for the late reply, I was distracted. If I summarize correctly your findings: Thank you. You summarized correctly my findings. For formats without a reliable duration header with seekable backing, the duration is evaluated at the opening by peeking at the last timestamps. With unseekable backing, the duration is not evaluated at all. In particular, the duration is not updated once the end of the file is reached. Well, I thought it was and wrote the code in consequence, thanks for correcting me. Still, the logic for tracking the duration can be a bit tricky, possibly trickier than your original patch if there are B-frames and timestamps resets. I would rather have it in a common part of the code than in the concat demuxer. I agree. I suspect we could consider adding AVStream.current_duration that tracks the maximum recently seen PTS for each stream. yes, it sounds good. (We could also have a function that peeks in AVStream.pts_buffer, but that looks tricky; and the corresponding duration is not available.) I hope other can give advice about this issue. Regards, I hope somebody will give a better solution than me. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel best, bb ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 5/5 v2] lavf/internal.h: Add declaration for ff_get_packet_palette()
On Wed, Mar 02, 2016 at 07:52:30AM +0100, Mats Peterson wrote: > Edited the doxy documentation. > > -- > Mats Peterson > http://matsp888.no-ip.org/~mats/ > internal.h | 12 > 1 file changed, 12 insertions(+) > 9b2a67e03ab88f7806a94c66f3d62410d34cd122 > 0005-lavf-internal.h-Add-declaration-for-ff_get_packet_pa.patch > From b5b8af39030ea01759567fdcd17d0420fb788c78 Mon Sep 17 00:00:00 2001 > From: Mats Peterson > Date: Wed, 2 Mar 2016 07:50:32 +0100 > Subject: [PATCH v4 5/5 v2] lavf/internal.h: Add declaration for > ff_get_packet_palette() applied together with ff_get_packet_palette() as they belong together thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 4/5] lavf/utils: New function ff_get_packet_palette()
On Wed, Mar 02, 2016 at 03:26:02AM +0100, Mats Peterson wrote: > > -- > Mats Peterson > http://matsp888.no-ip.org/~mats/ > utils.c | 16 > 1 file changed, 16 insertions(+) > 7fbf3f392daebb25a47ba12957917aee6c73db87 > 0004-lavf-utils-New-function-ff_get_packet_palette.patch > From 403d4db37d2690a8263db53b28225409eeb9bb8c Mon Sep 17 00:00:00 2001 > From: Mats Peterson > Date: Wed, 2 Mar 2016 03:14:05 +0100 > Subject: [PATCH v4 4/5] lavf/utils: New function ff_get_packet_palette() applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin 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/2] lavc: add h264 mediacodec decoder
On Tue, Mar 01, 2016 at 11:26:45PM +0100, Michael Niedermayer wrote:
> On Tue, Mar 01, 2016 at 08:01:45PM +0100, Matthieu Bouron wrote:
> > On Sat, Feb 27, 2016 at 04:28:43PM +0100, Michael Niedermayer wrote:
> > > On Fri, Feb 26, 2016 at 04:54:47PM +0100, Matthieu Bouron wrote:
> > > > On Tue, Feb 23, 2016 at 11:28:01AM +0100, wm4 wrote:
> > > > > On Tue, 23 Feb 2016 09:53:43 +0100
> > > > > Matthieu Bouron wrote:
> > > > >
> > > > > > On Mon, Feb 22, 2016 at 01:08:49PM +0100, Michael Niedermayer wrote:
> > > > > > > On Mon, Feb 22, 2016 at 12:20:36PM +0100, Matthieu Bouron wrote:
> > > > > > > > From: Matthieu Bouron
> > > > > > > [...]
> > > > > > > > +codec = (*env)->NewObject(env,
> > > > > > > > jfields.mediacodec_list_class, jfields.init_id, 0);
> > > > > > > > +if (!codec) {
> > > > > > > > +av_log(NULL, AV_LOG_ERROR, "Could not create media
> > > > > > > > codec list\n");
> > > > > > > > +goto done;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +tmp = (*env)->CallObjectMethod(env, codec,
> > > > > > > > jfields.find_decoder_for_format_id, format);
> > > > > > > > +if (!tmp) {
> > > > > > > > +av_log(NULL, AV_LOG_ERROR, "Could not find decoder
> > > > > > > > in media codec list\n");
> > > > > > > > +goto done;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +name = ff_jni_jstring_to_utf_chars(env, tmp, NULL);
> > > > > > > > +if (!name) {
> > > > > > >
> > > > > > > > +av_log(NULL, AV_LOG_ERROR, "Could not convert
> > > > > > > > jstring to utf chars\n");
> > > > > > >
> > > > > > > some non NULL context would be better, if possible, so the user
> > > > > > > knows
> > > > > > > where an error came from
> > > > > >
> > > > > > It would require to pass the log_ctx (avctx) as an argument of
> > > > > > ff_AMediaCodecList_getCodecByName.
> > > > > >
> > > > > > All the functions of this wrapper does not take a log_ctx as
> > > > > > argument
> > > > > > to be as close as possible to the original NDK MediaCodec API. The
> > > > > > NDK MediaCodec API does not provide any wrapper around
> > > > > > MediaCodecList.
> > > > > >
> > > > > > I would like the whole wrapper API to be consistent but also as
> > > > > > close as
> > > > > > possible to original one.
> > > > > > If you think it's mandatory I can add a log_ctx argument to every
> > > > > > functions of the wrapper API (so it will be used directly by av_log
> > > > > > and
> > > > > > ff_jni_exception_check).
> > > > > >
> > > > > > On another note, I fixed locally this part of the code by adding
> > > > > > missing calls
> > > > > > to ff_jni_exception_check.
> > > > > >
> > > > > > [...]
> > > > >
> > > > > Is it possible to store the log_ctx somewhere in the JNI?
> > > > >
> > > > > We might at some point in the future forbid av_log(NULL, ...) calls,
> > > > > and
> > > > > then it'd get complicated.
> > > >
> > > > Patch updated with the following differences:
> > > > * All logging arguments in mediacodec_wrapper functions are now non
> > > > NULL
> > > > * The mediacodec buffer copy functions has been moved to a separate
> > > > file
> > > > * The Mediacodec enum codec flags are properly retrieved from JNI
> > > >
> > > > The codec extradata conversion to annex b simplification has not been
> > > > addressed in this update. The bitstream filter api does not seem to
> > > > provide a way to do the extradata conversion without feeding an actual
> > > > packet to the api (av_bitstream_filter_filter) and i would like to keep
> > > > the codec initialization in the init function.
> > > >
> > > > The patchset has been pushed to a new branch:
> > > > https://github.com/mbouron/FFmpeg/tree/feature/mediacodec-support-v3
> > > >
> > > > Matthieu
> > >
> > > > configure |5
> > > > libavcodec/Makefile |3
> > > > libavcodec/allcodecs.c|1
> > > > libavcodec/mediacodec_sw_buffer.c | 339 +++
> > > > libavcodec/mediacodec_sw_buffer.h | 62 +
> > > > libavcodec/mediacodec_wrapper.c | 1674
> > > > ++
> > > > libavcodec/mediacodec_wrapper.h | 122 ++
> > > > libavcodec/mediacodecdec.c| 563
> > > > libavcodec/mediacodecdec.h| 82 +
> > > > libavcodec/mediacodecdec_h264.c | 356
> > > > 10 files changed, 3207 insertions(+)
> > > > f545068afece74d27cc04a365d9de7dcf5586a7d
> > > > 0002-lavc-add-h264-mediacodec-decoder.patch
> > > > From 805c7b95433f1bfbbc5d47fd59a1bbb755edb112 Mon Sep 17 00:00:00 2001
> > > > From: Matthieu Bouron
> > > > Date: Thu, 21 Jan 2016 09:29:39 +0100
> > > > Subject: [PATCH 2/2] lavc: add h264 mediacodec decoder
> > >
> > > breaks fate
> > > swr-resample_lin-fltp-48000-44100
> > > TESTswr-resample_lin-dblp-8000-44100
> > > TESTswr-resample_lin-dblp-8000-48000
> > > --- ./tests/ref/
[FFmpeg-devel] [PATCH 3/3] lavf/hashenc: clone md5 and framemd5 muxers into hash and framehash muxers
The two new muxers are functionally identical, except that they default
to the SHA-512 algorithm instead of MD5. The original "legacy" muxers
continue to provide their MD5 defaults.
The currently supported hash functions are now documented.
Signed-off-by: Moritz Barsnick
---
Changelog| 1 +
doc/muxers.texi | 129 ---
libavformat/Makefile | 2 +
libavformat/allformats.c | 2 +
libavformat/hashenc.c| 78
libavformat/version.h| 2 +-
6 files changed, 175 insertions(+), 39 deletions(-)
diff --git a/Changelog b/Changelog
index 0677b33..64a7428 100644
--- a/Changelog
+++ b/Changelog
@@ -9,6 +9,7 @@ version :
- firequalizer filter
- datascope filter
- bench and abench filters
+- hash and framehash filters
version 3.0:
diff --git a/doc/muxers.texi b/doc/muxers.texi
index f2ad7fe..c0d1fbf 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -174,25 +174,65 @@ ffmpeg -i INPUT -c:a pcm_u8 -c:v mpeg2video -f framecrc -
See also the @ref{crc} muxer.
-@anchor{framemd5}
-@section framemd5
+@anchor{framehash}
+@section framehash
-Per-packet MD5 testing format.
+Per-packet hash testing format.
-This muxer computes and prints the MD5 hash for each audio
-and video packet. By default audio frames are converted to signed
-16-bit raw audio and video frames to raw video before computing the
-hash.
+This muxer computes and prints a cryptographic hash for each audio
+and video packet. This can be used for packet-by-packet equality
+checks without having to individually do a binary comparison on each.
+
+By default audio frames are converted to signed 16-bit raw audio and
+video frames to raw video before computing the hash, but the output
+of explicit conversions to other codecs can also be used. It uses the
+SHA-512 cryptographic hash function by default, but supports several
+further hashes.
The output of the muxer consists of a line for each audio and video
packet of the form:
@example
-@var{stream_index}, @var{packet_dts}, @var{packet_pts}, @var{packet_duration},
@var{packet_size}, @var{MD5}
+@var{stream_index}, @var{packet_dts}, @var{packet_pts}, @var{packet_duration},
@var{packet_size}, @var{hash}
@end example
-@var{MD5} is a hexadecimal number representing the computed MD5 hash
+@var{hash} is a hexadecimal number representing the computed hash
for the packet.
+@table @option
+@item hash @var{algorithm}
+Use the cryptographic hash function specified by the string @var{algorithm}.
+Supported values include @code{MD5}, @code{murmur3}, @code{RIPEMD128},
+@code{RIPEMD160}, @code{RIPEMD256}, @code{RIPEMD320}, @code{SHA160},
+@code{SHA224}, @code{SHA256}, @code{SHA512/224}, @code{SHA512/256},
+@code{SHA384}, @code{SHA512} (default), @code{CRC32} and @code{adler32}.
+
+@end table
+
+@subsection Examples
+
+To compute the SHA-512 hash of the audio and video frames in @file{INPUT},
+converted to raw audio and video packets, and store it in the file
+@file{out.sha512}:
+@example
+ffmpeg -i INPUT -f framehash out.sha512
+@end example
+
+To print the information to stdout, using the MD5 hash function, use
+the command:
+@example
+ffmpeg -i INPUT -f framehash -hash md5 -
+@end example
+
+See also the @ref{hash} muxer.
+
+@anchor{framemd5}
+@section framemd5
+
+Per-packet MD5 testing format.
+
+This is a variant of the @ref{framehash} muxer. Unlike that muxer,
+it defaults to using the MD5 hash function.
+
@subsection Examples
For example to compute the MD5 of the audio and video frames in
@@ -202,12 +242,7 @@ in the file @file{out.md5}:
ffmpeg -i INPUT -f framemd5 out.md5
@end example
-To print the information to stdout, use the command:
-@example
-ffmpeg -i INPUT -f framemd5 -
-@end example
-
-See also the @ref{md5} muxer.
+See also the @ref{framehash} and @ref{md5} muxers.
@anchor{gif}
@section gif
@@ -243,6 +278,51 @@ ffmpeg -i INPUT -c:v gif -f image2 "out%d.gif"
Note 2: the GIF format has a very small time base: the delay between two frames
can not be smaller than one centi second.
+@anchor{hash}
+@section hash
+
+Hash testing format.
+
+This muxer computes and prints a cryptographic hash of all the input
+audio and video frames. This can be used for equality checks without
+having to do a complete binary comparison.
+
+By default audio frames are converted to signed 16-bit raw audio and
+video frames to raw video before computing the hash, but the output
+of explicit conversions to other codecs can also be used. Timestamps
+are ignored. It uses the SHA-512 cryptographic hash function by default,
+but supports several further hashes.
+
+The output of the muxer consists of a single line of the form:
+@var{algo}=@var{hash}, where @var{algo} is a short string representing
+the hash function used, and @var{hash} is a hexadecimal number
+representing the computed hash.
+
+@table @option
+@item hash @var{algorithm}
+Use the cryptographic hash function specified by the s
Re: [FFmpeg-devel] [PATCH 1/2] lavc: add JNI support
On Tue, Mar 01, 2016 at 09:06:35PM +0100, wm4 wrote: > On Tue, 1 Mar 2016 20:57:12 +0100 > Matthieu Bouron wrote: > > > On Tue, Mar 01, 2016 at 08:55:23PM +0100, Matthieu Bouron wrote: > > > On Tue, Mar 01, 2016 at 08:38:04PM +0100, wm4 wrote: > > > > On Tue, 1 Mar 2016 20:33:14 +0100 > > > > Matthieu Bouron wrote: > > > > > > > > > On Tue, Mar 01, 2016 at 08:24:27PM +0100, Matthieu Bouron wrote: > > > > > > On Tue, Mar 01, 2016 at 08:13:48PM +0100, wm4 wrote: > > > > > > > On Tue, 1 Mar 2016 20:10:50 +0100 > > > > > > > Matthieu Bouron wrote: > > > > > > > > > > > > > > > On Tue, Mar 01, 2016 at 07:56:30PM +0100, wm4 wrote: > > > > > > > > > On Tue, 1 Mar 2016 19:52:08 +0100 > > > > > > > > > Matthieu Bouron wrote: > > > > > > > > > > > > > > > > > > > On Fri, Feb 26, 2016 at 05:36:40PM +0100, Matthieu Bouron > > > > > > > > > > wrote: > > > > > > > > > > > On Fri, Feb 26, 2016 at 4:41 PM, Matthieu Bouron > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > On Mon, Feb 22, 2016 at 12:20:35PM +0100, Matthieu > > > > > > > > > > > > Bouron wrote: > > > > > > > > > > > > > From: Matthieu Bouron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Patch updated with the following differences: > > > > > > > > > > > > * fix of switch/case code style > > > > > > > > > > > > * removal of a miss declaration of FFJNIField enum as > > > > > > > > > > > > a global variable > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Patch updated with the following differences: > > > > > > > > > > > * fixes a few typo in comments > > > > > > > > > > > * fixes a if statement in ff_jni_init_jfields > > > > > > > > > > > > > > > > > > > > Patch updated with the following differences: > > > > > > > > > > * fixes a few typo in comments and message logs > > > > > > > > > > * add missing .so at end of library names when trying to > > > > > > > > > > find > > > > > > > > > > JNI_GetCreatedVMs symbol (also add libart.so) > > > > > > > > > > * reintroduce public functions that allow the user to set > > > > > > > > > > the Java > > > > > > > > > > virtual machine (av_jni_(set,get)_java_vm) as the private > > > > > > > > > > C++ > > > > > > > > > > JniInvocation wrapper is not available on all devices > > > > > > > > > > (android >= 4.4) > > > > > > > > > > > > > > > > > > I'm wondering if the VM should be stored per AVCodecContext. > > > > > > > > > (Since it > > > > > > > > > has to be set explicitly again by the user.) > > > > > > > > > > > > > > > > I think it is fine to store one VM for all the AVCodecContext > > > > > > > > as it will > > > > > > > > be the same during all the lifetime of the application. I > > > > > > > > should also > > > > > > > > enforce that the VM cannot be changed afterwards. > > > > > > > > > > > > > > > > av_jni_set_java_vm stores the Java VM pointer locally in jni.c > > > > > > > > and not in > > > > > > > > ffjni.c and it is retrieved in jni.c using av_jni_get_java_vm. > > > > > > > > I've done > > > > > > > > it that way because if at some point we are to include ffjni.c > > > > > > > > from > > > > > > > > libavformat it won't work (it will only set the java vm in the > > > > > > > > libavcodec > > > > > > > > memory space). > > > > > > > > > > > > > > The problem is that this is not library-safe. What if two libs > > > > > > > within > > > > > > > the process (which both are using libavcodec) are setting a > > > > > > > different > > > > > > > VM? > > > > > > > > > > > > In the Android application context, you only have, AFAIK, one VM > > > > > > running > > > > > > during the lifetime of the application. The code does handle the > > > > > > general > > > > > > > > > > does *not* (sorry) > > > > > > > > > > > JNI case (even outside Android) but do we really want to do that > > > > > > anyway ? > > > > > > > > If there's guaranteed to be exactly one, I don't get why we can't get > > > > it into existence ourselves? > > > > > > > > Where exactly would an application get the VM handle from? > > > > > > You get the Java VM pointer when JNI_onLoad(JavaVM *vm, void *reserved) is > > > executed at library load. This is where you can pass the pointer to lavc. > > > > > > IMHO, av_jni_set_java_vm should set the VM once and then warn (or return > > > an error) > > > if the user is providing a different Java VM pointer. > > > > > > In theory, on some version of Android, you can spawn your own VM using > > > their > > > private C++ JniInvocation wrapper. > > > On a regular desktop, you can create Java VMs (using JNI_createJavaVM). > > > > Also note that the JniInvocation wrapper is still used if the user hasn't > > provided a Java
[FFmpeg-devel] [PATCH 2/3] lavf/hashenc: rename variables where appropriate
In preparation for duplication of muxers and functionality. Functions
which are applicable to md5 only - those which default to using the
MD5 hash algorithm - and will continue to do so keep their names.
What's more, the options array, which already carried "hash" in its
name instead of "md5", now gains an "md5" name, as it will continue
to exist in order to carry the same default option for the "legacy"
muxers.
Signed-off-by: Moritz Barsnick
---
libavformat/hashenc.c | 68 +--
1 file changed, 34 insertions(+), 34 deletions(-)
diff --git a/libavformat/hashenc.c b/libavformat/hashenc.c
index 8433be4..e4d308d 100644
--- a/libavformat/hashenc.c
+++ b/libavformat/hashenc.c
@@ -1,5 +1,5 @@
/*
- * MD5 encoder (for codec/format testing)
+ * Hash/MD5 encoder (for codec/format testing)
* Copyright (c) 2009 Reimar Döffinger, based on crcenc (c) 2002 Fabrice
Bellard
*
* This file is part of FFmpeg.
@@ -26,23 +26,23 @@
#include "avformat.h"
#include "internal.h"
-struct MD5Context {
+struct HashContext {
const AVClass *avclass;
struct AVHashContext *hash;
char *hash_name;
int format_version;
};
-static void md5_finish(struct AVFormatContext *s, char *buf)
+static void hash_finish(struct AVFormatContext *s, char *buf)
{
-struct MD5Context *c = s->priv_data;
-uint8_t md5[AV_HASH_MAX_SIZE];
+struct HashContext *c = s->priv_data;
+uint8_t hash[AV_HASH_MAX_SIZE];
int i, offset = strlen(buf);
int len = av_hash_get_size(c->hash);
-av_assert0(len > 0 && len <= sizeof(md5));
-av_hash_final(c->hash, md5);
+av_assert0(len > 0 && len <= sizeof(hash));
+av_hash_final(c->hash, hash);
for (i = 0; i < len; i++) {
-snprintf(buf + offset, 3, "%02"PRIx8, md5[i]);
+snprintf(buf + offset, 3, "%02"PRIx8, hash[i]);
offset += 2;
}
buf[offset] = '\n';
@@ -52,9 +52,9 @@ static void md5_finish(struct AVFormatContext *s, char *buf)
avio_flush(s->pb);
}
-#define OFFSET(x) offsetof(struct MD5Context, x)
+#define OFFSET(x) offsetof(struct HashContext, x)
#define ENC AV_OPT_FLAG_ENCODING_PARAM
-static const AVOption hash_options[] = {
+static const AVOption md5_options[] = {
{ "hash", "set hash to use", OFFSET(hash_name), AV_OPT_TYPE_STRING, {.str
= "md5"}, 0, 0, ENC },
{ "format_version", "file format version", OFFSET(format_version),
AV_OPT_TYPE_INT, {.i64 = 1}, 1, 1, ENC },
{ NULL },
@@ -63,14 +63,14 @@ static const AVOption hash_options[] = {
static const AVClass md5enc_class = {
.class_name = "hash encoder class",
.item_name = av_default_item_name,
-.option = hash_options,
+.option = md5_options,
.version= LIBAVUTIL_VERSION_INT,
};
#if CONFIG_MD5_MUXER
-static int write_header(struct AVFormatContext *s)
+static int hash_write_header(struct AVFormatContext *s)
{
-struct MD5Context *c = s->priv_data;
+struct HashContext *c = s->priv_data;
int res = av_hash_alloc(&c->hash, c->hash_name);
if (res < 0)
return res;
@@ -78,21 +78,21 @@ static int write_header(struct AVFormatContext *s)
return 0;
}
-static int write_packet(struct AVFormatContext *s, AVPacket *pkt)
+static int hash_write_packet(struct AVFormatContext *s, AVPacket *pkt)
{
-struct MD5Context *c = s->priv_data;
+struct HashContext *c = s->priv_data;
av_hash_update(c->hash, pkt->data, pkt->size);
return 0;
}
-static int write_trailer(struct AVFormatContext *s)
+static int hash_write_trailer(struct AVFormatContext *s)
{
-struct MD5Context *c = s->priv_data;
+struct HashContext *c = s->priv_data;
char buf[256];
av_strlcpy(buf, av_hash_get_name(c->hash), sizeof(buf) - 200);
av_strlcat(buf, "=", sizeof(buf) - 200);
-md5_finish(s, buf);
+hash_finish(s, buf);
av_hash_freep(&c->hash);
return 0;
@@ -101,12 +101,12 @@ static int write_trailer(struct AVFormatContext *s)
AVOutputFormat ff_md5_muxer = {
.name = "md5",
.long_name = NULL_IF_CONFIG_SMALL("MD5 testing"),
-.priv_data_size= sizeof(struct MD5Context),
+.priv_data_size= sizeof(struct HashContext),
.audio_codec = AV_CODEC_ID_PCM_S16LE,
.video_codec = AV_CODEC_ID_RAWVIDEO,
-.write_header = write_header,
-.write_packet = write_packet,
-.write_trailer = write_trailer,
+.write_header = hash_write_header,
+.write_packet = hash_write_packet,
+.write_trailer = hash_write_trailer,
.flags = AVFMT_VARIABLE_FPS | AVFMT_TS_NONSTRICT |
AVFMT_TS_NEGATIVE,
.priv_class= &md5enc_class,
@@ -114,9 +114,9 @@ AVOutputFormat ff_md5_muxer = {
#endif
#if CONFIG_FRAMEMD5_MUXER
-static int framemd5_write_header(struct AVFormatContext *s)
+static int framehash_write_header(struct AVFormatContext *s)
{
-struct MD5Context *c = s->priv_data;
+struct Ha
[FFmpeg-devel] [PATCH 0/3] lavf: generalize md5enc to hashenc and clone the muxers
As suggested in the thread regarding the proposed streammd5 muxer:
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-February/189694.html
this patchset converts the md5/framemd5 muxers into hash/hashenc muxers with
aliased muxers retaining the original names and default algorithms.
I am aware that there are also the crc muxer (which the md5 muxer was
derived from) and the md5 protocol, but I'm not sure how they should relate
to this. The crc muxer can also be merged by creating a new cloned muxer
which defaults to adler32, but its output currently differs a bit.
I went with an approach in several steps. I do like atomic renames without
code changes. Perhaps some, if not all, of these steps can be squashed.
Feel free to do so or to comment accordingly.
Steps:
1. Rename the source files (keeping muxers' names).
-> No functional or source changes.
2. Rename the source's variables to make them more generic, where applicable.
-> Code which is still specific to MD5 retains that string, and the muxer
names do as well of course.
-> No functional changes at all.
3. Clone the muxers, with separate options arrays defaulting to MD5 ("legacy")
and SHA-512 ("new", "generic"), and with separate classes using them. The
"legacy" muxers behave exactly as before, and take the same options as
before. The "new" new muxers with generic names share the code, but default
to the SHA-512 hash.
I'm not sure about the version bump and the Changelog entry, because no
actual feature was added.
Caveat: lavu/hash, which provides the hashing functions, doesn't expose the
supported algorithms, but even if it did, I wouldn't know how to map that into
the options array at compile time. I copied the currently known algorithm
strings from libavutil/hash.c to the texi documentation.
Moritz Barsnick (3):
lavf: rename md5enc source to hashenc
lavf/hashenc: rename variables where appropriate
lavf/hashenc: clone md5 and framemd5 muxers into hash and framehash
muxers
Changelog| 1 +
doc/muxers.texi | 129 --
libavformat/Makefile | 6 +-
libavformat/allformats.c | 2 +
libavformat/hashenc.c| 231 +++
libavformat/md5enc.c | 171 ---
libavformat/version.h| 2 +-
7 files changed, 339 insertions(+), 203 deletions(-)
create mode 100644 libavformat/hashenc.c
delete mode 100644 libavformat/md5enc.c
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] lavf: rename md5enc source to hashenc
To move away from naming it by only one of the supported algorithms.
Signed-off-by: Moritz Barsnick
---
libavformat/Makefile | 4 +-
libavformat/hashenc.c | 171 ++
libavformat/md5enc.c | 171 --
3 files changed, 173 insertions(+), 173 deletions(-)
create mode 100644 libavformat/hashenc.c
delete mode 100644 libavformat/md5enc.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index dc931d9..05c0fe8 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -173,7 +173,7 @@ OBJS-$(CONFIG_LIVE_FLV_DEMUXER) += flvdec.o
OBJS-$(CONFIG_FLV_MUXER) += flvenc.o avc.o
OBJS-$(CONFIG_FOURXM_DEMUXER)+= 4xm.o
OBJS-$(CONFIG_FRAMECRC_MUXER)+= framecrcenc.o framehash.o
-OBJS-$(CONFIG_FRAMEMD5_MUXER)+= md5enc.o framehash.o
+OBJS-$(CONFIG_FRAMEMD5_MUXER)+= hashenc.o framehash.o
OBJS-$(CONFIG_FRM_DEMUXER) += frmdec.o
OBJS-$(CONFIG_FSB_DEMUXER) += fsb.o
OBJS-$(CONFIG_GIF_MUXER) += gif.o
@@ -256,7 +256,7 @@ OBJS-$(CONFIG_MATROSKA_MUXER)+= matroskaenc.o
matroska.o \
avc.o hevc.o \
flacenc_header.o avlanguage.o
vorbiscomment.o wv.o \
webmdashenc.o webm_chunk.o
-OBJS-$(CONFIG_MD5_MUXER) += md5enc.o
+OBJS-$(CONFIG_MD5_MUXER) += hashenc.o
OBJS-$(CONFIG_MGSTS_DEMUXER) += mgsts.o
OBJS-$(CONFIG_MICRODVD_DEMUXER) += microdvddec.o subtitles.o
OBJS-$(CONFIG_MICRODVD_MUXER)+= microdvdenc.o
diff --git a/libavformat/hashenc.c b/libavformat/hashenc.c
new file mode 100644
index 000..8433be4
--- /dev/null
+++ b/libavformat/hashenc.c
@@ -0,0 +1,171 @@
+/*
+ * MD5 encoder (for codec/format testing)
+ * Copyright (c) 2009 Reimar Döffinger, based on crcenc (c) 2002 Fabrice
Bellard
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/avstring.h"
+#include "libavutil/hash.h"
+#include "libavutil/opt.h"
+#include "avformat.h"
+#include "internal.h"
+
+struct MD5Context {
+const AVClass *avclass;
+struct AVHashContext *hash;
+char *hash_name;
+int format_version;
+};
+
+static void md5_finish(struct AVFormatContext *s, char *buf)
+{
+struct MD5Context *c = s->priv_data;
+uint8_t md5[AV_HASH_MAX_SIZE];
+int i, offset = strlen(buf);
+int len = av_hash_get_size(c->hash);
+av_assert0(len > 0 && len <= sizeof(md5));
+av_hash_final(c->hash, md5);
+for (i = 0; i < len; i++) {
+snprintf(buf + offset, 3, "%02"PRIx8, md5[i]);
+offset += 2;
+}
+buf[offset] = '\n';
+buf[offset+1] = 0;
+
+avio_write(s->pb, buf, strlen(buf));
+avio_flush(s->pb);
+}
+
+#define OFFSET(x) offsetof(struct MD5Context, x)
+#define ENC AV_OPT_FLAG_ENCODING_PARAM
+static const AVOption hash_options[] = {
+{ "hash", "set hash to use", OFFSET(hash_name), AV_OPT_TYPE_STRING, {.str
= "md5"}, 0, 0, ENC },
+{ "format_version", "file format version", OFFSET(format_version),
AV_OPT_TYPE_INT, {.i64 = 1}, 1, 1, ENC },
+{ NULL },
+};
+
+static const AVClass md5enc_class = {
+.class_name = "hash encoder class",
+.item_name = av_default_item_name,
+.option = hash_options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
+#if CONFIG_MD5_MUXER
+static int write_header(struct AVFormatContext *s)
+{
+struct MD5Context *c = s->priv_data;
+int res = av_hash_alloc(&c->hash, c->hash_name);
+if (res < 0)
+return res;
+av_hash_init(c->hash);
+return 0;
+}
+
+static int write_packet(struct AVFormatContext *s, AVPacket *pkt)
+{
+struct MD5Context *c = s->priv_data;
+av_hash_update(c->hash, pkt->data, pkt->size);
+return 0;
+}
+
+static int write_trailer(struct AVFormatContext *s)
+{
+struct MD5Context *c = s->priv_data;
+char buf[256];
+av_strlcpy(buf, av_hash_get_name(c->hash), sizeof(buf) - 200);
+av_strlcat(buf, "=", sizeof(buf) - 200);
+
+md5_finish(s, buf);
+
+av_hash_freep(&c->hash);
+return 0;
+}
+
+AVOutputFor
Re: [FFmpeg-devel] [PATCH] Fix a bug in ff_thread_report_progress in updating progress[field].
Hi, On Tue, Mar 1, 2016 at 8:05 PM, Wan-Teh Chang wrote: > On Tue, Mar 1, 2016 at 7:44 AM, Ronald S. Bultje > wrote: > > Hi, > > > > On Tue, Mar 1, 2016 at 9:34 AM, Wan-Teh Chang < > wtc-at-google@ffmpeg.org> > > wrote: > > > >> By the way, I'm also wondering why ff_thread_report_progress is > >> sometimes called with progress[field] >= n? I saw it happen when I ran > >> make fate-h264, but did not investigate it. > > > > I don't know, which sample (test name) specifically? > > The attached ff_thread_report_progress.txt file is a patch for ffmpeg > that counts the fast and slow code paths in ff_thread_report_progress > and ff_thread_await_progress, and prints the counters at the end. > > I ran "make fate-h264 THREADS=4". Here are the results, which show > that the fast code path (progress[field] >= n) was taken in > ff_thread_report_progress. I think I mis-read the question. We don't care if progress[field] == n, that's a logical thing that can happen in many cases. We care only if progress[field] > n, which would be an actual race. It's only logical that the fast code path is taken if progress[field] == n, and this can happen for all sort of reasons, none of which are pathological or worth spending time on. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] vc2enc: remove useless alignment on slice encoding
This was a leftover from before the slices were encoded in parallel. Since the put_bits context is initialized per slice aligning it aferwards is pointless. Signed-off-by: Rostislav Pehlivanov --- libavcodec/vc2enc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c index 3311d97..34a4f95 100644 --- a/libavcodec/vc2enc.c +++ b/libavcodec/vc2enc.c @@ -749,7 +749,6 @@ static int encode_hq_slice(AVCodecContext *avctx, void *arg) uint8_t quants[MAX_DWT_LEVELS][4]; int p, level, orientation; -avpriv_align_put_bits(pb); skip_put_bytes(pb, s->prefix_bytes); put_bits(pb, 8, quant_idx); -- 2.7.0.79.gdc08a19 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] vc2enc: only warn on a non-standard base video format
This commit is up for discussion.
Requiring the user to reduce the strictness just to encode some random
file (which decodes fine in all implementations except 1) isn't helping
the encoder at all. The encoder needs to be used to get bug reports and
to be improved by multiple people. Only supporting 5 popular broadcast
formats (1080/720 at 23.97p/25i/29.97i/50p/59.94p) because some
obscure hardware decoder might not be able to decode anything
outside of exactly 2 of those formats is no reason to lock down the
encoder when the specifications clearly give you the tools to encode
files or pictures with arbitrary sizes, frame rates, pixel formats or
pixel ranges.
Therefore, only warn if the video format does not belong to the small
limited set of formats that the very few existing hardware decoders in
the world can't handle. That way the encoder will see more use and
therefore more bug reports.
The commit is up for discussion, so it would be nice to hear an opposing
view on this problem.
Signed-off-by: Rostislav Pehlivanov
---
libavcodec/vc2enc.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index 3bc60a3..af17b15 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -1109,14 +1109,9 @@ static av_cold int vc2_encode_init(AVCodecContext *avctx)
}
if (s->base_vf <= 0) {
-if (avctx->strict_std_compliance <= FF_COMPLIANCE_UNOFFICIAL) {
-s->strict_compliance = s->base_vf = 0;
-av_log(avctx, AV_LOG_WARNING, "Disabling strict compliance\n");
-} else {
-av_log(avctx, AV_LOG_WARNING, "Given format does not strictly
comply with "
- "the specifications, please add a -strict -1 flag to use
it\n");
-return AVERROR_UNKNOWN;
-}
+s->base_vf = 0;
+av_log(avctx, AV_LOG_WARNING, "Unable to find a suitable base video
format, "
+ "output file might not be strictly
spec-compliant\n");
} else {
av_log(avctx, AV_LOG_INFO, "Selected base video format = %i\n",
s->base_vf);
}
--
2.7.0.79.gdc08a19
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] vc2enc: minor cosmetic changes
Signed-off-by: Rostislav Pehlivanov
---
libavcodec/vc2enc.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index 34a4f95..3bc60a3 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -506,7 +506,6 @@ static void encode_wavelet_transform(VC2EncContext *s)
{
encode_transform_params(s);
avpriv_align_put_bits(&s->pb);
-/* Continued after DWT in encode_transform_data() */
}
/* VC-2 12 - picture_parse() */
@@ -542,7 +541,7 @@ static void encode_subband(VC2EncContext *s, PutBitContext
*pb, int sx, int sy,
const int neg = coeff[x] < 0;
uint32_t c_abs = FFABS(coeff[x]);
if (c_abs < COEF_LUT_TAB) {
-const uint8_t len = len_lut[c_abs];
+const uint8_t len = len_lut[c_abs];
if (len == 1)
put_bits(pb, 1, 1);
else
@@ -961,7 +960,7 @@ static int encode_frame(VC2EncContext *s, AVPacket *avpkt,
const AVFrame *frame,
}
static av_cold int vc2_encode_frame(AVCodecContext *avctx, AVPacket *avpkt,
- const AVFrame *frame, int
*got_packet_ptr)
+ const AVFrame *frame, int *got_packet)
{
int ret = 0;
int sig_size = 256;
@@ -984,7 +983,7 @@ static av_cold int vc2_encode_frame(AVCodecContext *avctx,
AVPacket *avpkt,
/* Find an appropriate size scaler */
while (sig_size > 255) {
s->slice_max_bytes = FFALIGN(av_rescale(max_frame_bytes, 1,
- s->num_x*s->num_y), s->size_scaler);
+s->num_x*s->num_y),
s->size_scaler);
s->slice_max_bytes += 4 + s->prefix_bytes;
sig_size = s->slice_max_bytes/s->size_scaler; /* Signalled slize size
*/
s->size_scaler <<= 1;
@@ -1004,7 +1003,7 @@ static av_cold int vc2_encode_frame(AVCodecContext
*avctx, AVPacket *avpkt,
flush_put_bits(&s->pb);
avpkt->size = put_bits_count(&s->pb) >> 3;
-*got_packet_ptr = 1;
+*got_packet = 1;
return 0;
}
--
2.7.0.79.gdc08a19
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] vc2enc: do not allocate packet until exact frame size is known
This commit solves most of the crashes and issues with the encoder and
the bitrate setting. Now the encoder will always allocate the absolute
lowest amount of memory regardless of what the bitrate has been set to.
Therefore if a user inputs a very low bitrate the encoder will use the
maximum possible quantization (basically zero out all coefficients),
allocate a packet and encode it. There is no coupling between the
bitrate and the allocation size and so no crashes because the buffer
isn't large enough.
The maximum quantizer was raised to the size of the table now to both
keep the overshoot at ridiculous bitrates low and to improve quality
with higher bit depths (since the coefficients grow larger per transform
quantizing them to the same relative level requires larger quantization
indices).
Since the quantization index start follows the previous quantization
index for that slice, the quantization step was reduced to a static 1
to improve performance. Previously with quant/5 the step was usually
set to 0 upon start (and was later clipped to 1), that isn't a big change.
As the step size increases so does the amount of bits leftover and so
the redistribution algorithm has to iterate more and thus waste more
time.
Signed-off-by: Rostislav Pehlivanov
---
libavcodec/vc2enc.c | 332 ++--
1 file changed, 166 insertions(+), 166 deletions(-)
diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index 8688754..3311d97 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -30,7 +30,7 @@
#include "diractab.h"
/* Quantizations above this usually zero coefficients and lower the quality */
-#define MAX_QUANT_INDEX 50
+#define MAX_QUANT_INDEX FF_ARRAY_ELEMS(ff_dirac_qscale_tab)
/* Total range is -COEF_LUT_TAB to +COEFF_LUT_TAB, but total tab size is half
* (COEF_LUT_TAB*MAX_QUANT_INDEX) since the sign is appended during encoding */
@@ -99,6 +99,7 @@ typedef struct VC2EncContext {
/* For conversion from unsigned pixel values to signed */
int diff_offset;
int bpp;
+int bpp_idx;
/* Picture number */
uint32_t picture_number;
@@ -110,6 +111,7 @@ typedef struct VC2EncContext {
/* Quantization matrix */
uint8_t quant[MAX_DWT_LEVELS][4];
+int custom_quant_matrix;
/* Coefficient LUT */
uint32_t *coef_lut_val;
@@ -327,31 +329,9 @@ static void encode_clean_area(VC2EncContext *s)
/* VC-2 11.3.8 - signal_range() */
static void encode_signal_range(VC2EncContext *s)
{
-int idx;
-AVCodecContext *avctx = s->avctx;
-const AVPixFmtDescriptor *fmt = av_pix_fmt_desc_get(avctx->pix_fmt);
-const int depth = fmt->comp[0].depth;
-if (depth == 8 && avctx->color_range == AVCOL_RANGE_JPEG) {
-idx = 1;
-s->bpp = 1;
-s->diff_offset = 128;
-} else if (depth == 8 && (avctx->color_range == AVCOL_RANGE_MPEG ||
- avctx->color_range == AVCOL_RANGE_UNSPECIFIED)) {
-idx = 2;
-s->bpp = 1;
-s->diff_offset = 128;
-} else if (depth == 10) {
-idx = 3;
-s->bpp = 2;
-s->diff_offset = 512;
-} else {
-idx = 4;
-s->bpp = 2;
-s->diff_offset = 2048;
-}
put_bits(&s->pb, 1, !s->strict_compliance);
if (!s->strict_compliance)
-put_vc2_ue_uint(&s->pb, idx);
+put_vc2_ue_uint(&s->pb, s->bpp_idx);
}
/* VC-2 11.3.9 - color_spec() */
@@ -455,10 +435,23 @@ const uint8_t vc2_qm_flat_tab[][4] = {
{ 0, 0, 0, 0}
};
-static void init_custom_qm(VC2EncContext *s)
+static void init_quant_matrix(VC2EncContext *s)
{
int level, orientation;
+if (s->wavelet_depth <= 4 && s->quant_matrix == VC2_QM_DEF) {
+s->custom_quant_matrix = 0;
+for (level = 0; level < s->wavelet_depth; level++) {
+s->quant[level][0] =
ff_dirac_default_qmat[s->wavelet_idx][level][0];
+s->quant[level][1] =
ff_dirac_default_qmat[s->wavelet_idx][level][1];
+s->quant[level][2] =
ff_dirac_default_qmat[s->wavelet_idx][level][2];
+s->quant[level][3] =
ff_dirac_default_qmat[s->wavelet_idx][level][3];
+}
+return;
+}
+
+s->custom_quant_matrix = 1;
+
if (s->quant_matrix == VC2_QM_DEF) {
for (level = 0; level < s->wavelet_depth; level++) {
for (orientation = 0; orientation < 4; orientation++) {
@@ -486,25 +479,15 @@ static void init_custom_qm(VC2EncContext *s)
/* VC-2 12.3.4.2 - quant_matrix() */
static void encode_quant_matrix(VC2EncContext *s)
{
-int level, custom_quant_matrix = 0;
-if (s->wavelet_depth > 4 || s->quant_matrix != VC2_QM_DEF)
-custom_quant_matrix = 1;
-put_bits(&s->pb, 1, custom_quant_matrix);
-if (custom_quant_matrix) {
-init_custom_qm(s);
+int level;
+put_bits(&s->pb, 1, s->custom_quant_matrix);
+if (s->custom_quant_matrix) {
put_vc2_ue_uint(&s->pb, s->quant[0][0]);
for (level = 0; level < s->wavelet_depth; l
[FFmpeg-devel] [PATCH v10] VideoToolbox H.264 Encoder
Autodetected by default. Encode using -codec:v h264_videotoolbox. Signed-off-by: Rick Kern --- MAINTAINERS |1 + configure| 26 +- libavcodec/Makefile |1 + libavcodec/allcodecs.c |1 + libavcodec/videotoolboxenc.c | 1339 ++ 5 files changed, 1361 insertions(+), 7 deletions(-) create mode 100644 libavcodec/videotoolboxenc.c diff --git a/MAINTAINERS b/MAINTAINERS index 155642b..a62726d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -279,6 +279,7 @@ Codecs: vc2* Rostislav Pehlivanov vcr1.cMichael Niedermayer vda_h264_dec.cXidorn Quan + videotoolboxenc.c Rick Kern vima.cPaul B Mahol vmnc.cKostya Shishkov vorbisdec.c Denes Balatoni, David Conrad diff --git a/configure b/configure index 8491fa1..81769ee 100755 --- a/configure +++ b/configure @@ -155,7 +155,6 @@ Hardware accelerators: --disable-vaapi disable VAAPI code [autodetect] --disable-vdadisable VDA code [autodetect] --disable-vdpau disable VDPAU code [autodetect] - --enable-videotoolboxenable VideoToolbox code [autodetect] Individual component options: --disable-everything disable all components listed below @@ -289,6 +288,7 @@ External library support: --disable-sdldisable sdl [autodetect] --disable-securetransport disable Secure Transport, needed for TLS support on OSX if openssl and gnutls are not used [autodetect] + --disable-videotoolbox disable VideoToolbox code [autodetect] --enable-x11grab enable X11 grabbing (legacy) [no] --disable-xlib disable xlib [autodetect] --disable-zlib disable zlib [autodetect] @@ -1509,6 +1509,7 @@ EXTERNAL_LIBRARY_LIST=" schannel sdl securetransport +videotoolbox x11grab xlib zlib @@ -1540,7 +1541,7 @@ HWACCEL_LIST=" vaapi vda vdpau -videotoolbox +videotoolbox_hwaccel xvmc " @@ -2484,11 +2485,13 @@ crystalhd_deps="libcrystalhd_libcrystalhd_if_h" d3d11va_deps="d3d11_h dxva_h ID3D11VideoDecoder ID3D11VideoContext" dxva2_deps="dxva2api_h DXVA2_ConfigPictureDecode" vaapi_deps="va_va_h" -vda_deps="VideoDecodeAcceleration_VDADecoder_h pthreads" -vda_extralibs="-framework CoreFoundation -framework VideoDecodeAcceleration -framework QuartzCore" +vda_framework_deps="VideoDecodeAcceleration_VDADecoder_h" +vda_framework_extralibs="-framework VideoDecodeAcceleration" +vda_deps="vda_framework pthreads" +vda_extralibs="-framework CoreFoundation -framework QuartzCore" vdpau_deps="vdpau_vdpau_h vdpau_vdpau_x11_h" -videotoolbox_deps="VideoToolbox_VideoToolbox_h pthreads" -videotoolbox_extralibs="-framework CoreFoundation -framework VideoToolbox -framework CoreMedia -framework QuartzCore -framework CoreVideo" +videotoolbox_hwaccel_deps="videotoolbox pthreads" +videotoolbox_hwaccel_extralibs="-framework QuartzCore" xvmc_deps="X11_extensions_XvMClib_h" h263_vaapi_hwaccel_deps="vaapi" @@ -2611,6 +2614,8 @@ mjpeg2jpeg_bsf_select="jpegtables" # external libraries chromaprint_muxer_deps="chromaprint" +h264_videotoolbox_encoder_deps="videotoolbox_encoder pthreads" +h264_videotoolbox_encoder_select="bzlib zlib iconv" libcelt_decoder_deps="libcelt" libdcadec_decoder_deps="libdcadec" libfaac_encoder_deps="libfaac" @@ -2672,6 +2677,10 @@ libzvbi_teletext_decoder_deps="libzvbi" nvenc_encoder_deps="nvenc" nvenc_h264_encoder_deps="nvenc" nvenc_hevc_encoder_deps="nvenc" +videotoolbox_deps="VideoToolbox_VideoToolbox_h" +videotoolbox_extralibs="-framework CoreFoundation -framework VideoToolbox -framework CoreMedia -framework CoreVideo" +videotoolbox_encoder_deps="videotoolbox VTCompressionSessionPrepareToEncodeFrames" +videotoolbox_encoder_suggest="vda_framework" # demuxers / muxers ac3_demuxer_select="ac3_parser" @@ -3052,9 +3061,11 @@ sws_max_filter_size_default=256 set_default sws_max_filter_size # Enable hwaccels by default. -enable d3d11va dxva2 vaapi vda vdpau videotoolbox xvmc +enable d3d11va dxva2 vaapi vda vdpau videotoolbox_hwaccel xvmc enable xlib +enable vda_framework videotoolbox videotoolbox_encoder + # build settings SHFLAGS='-shared -Wl,-soname,$$(@F)' LIBPREF="lib" @@ -5449,6 +5460,7 @@ check_header vdpau/vdpau.h check_header vdpau/vdpau_x11.h check_header VideoDecodeAcceleration/VDADecoder.h check_header VideoToolbox/VideoToolbox.h +check_func_headers VideoToolbox/VTCompressionSession.h VTCompressionSessionPrepareToEncodeFrames -framework VideoToolbox check_header windows.h check_header X11/extensions/XvMClib.h check_header asm/types.h diff --git a/libavcodec/Makefile b/libavcodec/Makefile index 667e257..bbca908 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile
[FFmpeg-devel] [PATCH v10] VideoToolbox H.264 Encoder
Uses the --disable-videotoolbox configure switch like the hwaccel, changed encoder filename, changed free() to av_free(). Rick Kern (1): VideoToolbox H.264 Encoder MAINTAINERS |1 + configure| 26 +- libavcodec/Makefile |1 + libavcodec/allcodecs.c |1 + libavcodec/videotoolboxenc.c | 1339 ++ 5 files changed, 1361 insertions(+), 7 deletions(-) create mode 100644 libavcodec/videotoolboxenc.c -- 2.5.4 (Apple Git-61) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v9] VideoToolbox H.264 Encoder
> On Mar 2, 2016, at 12:11 AM, wm4 wrote:
>
> On Tue, 01 Mar 2016 14:57:29 +
> Timothy Gu mailto:timothyg...@gmail.com>> wrote:
>
>> Hi,
>>
>> On Mon, Feb 29, 2016 at 9:42 PM Rick Kern wrote:
>>
>>> Autodetected by default. Encode using -codec:v vtenc.
>>>
>>> Signed-off-by: Rick Kern
>>> ---
>>> MAINTAINERS|1 +
>>> configure | 19 +
>>> libavcodec/Makefile|1 +
>>> libavcodec/allcodecs.c |1 +
>>> libavcodec/vtenc.c | 1339
>>>
>>> 5 files changed, 1361 insertions(+)
>>> create mode 100644 libavcodec/vtenc.c
>>>
>>
>> We already have videotoolbox AVHWAccel. Maybe it would be better to change
>> the name of the file to videotoolboxenc.c so that it's easier to associate
>> these two files?
>
> I don't mind. They're pretty different after all.
Sounds good. I’ll rename it.
>
>>
>>> +AVCodec ff_vtenc_encoder = {
>>
>>> +.name = "vtenc",
>>> +.long_name= NULL_IF_CONFIG_SMALL("VideoToolbox H.264
>>> Encoder"),
>>>
>>
>> The norm seems to be using "h264_videotoolbox" (like "h264_qsv") so that
>> potential future extensions to VideoToolbox can be supported without
>> changing the name of the codec.
>>
>
> Good point.
Ok. I’d also like to make configure —enable-videotoolbox apply to the
VideoToolbox external library, not just the hwaccel. The VideoToolbox hwaccel
build code will have to be updated to depend on the external library, but then
disabling VideoToolbox-related code requires one parameter. The names of the
hwaccels would stay the same, so I don’t see any backwards compatibility issues.
> ___
> 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] lavc/aacenc_utils: replace sqrtf(Q*sqrtf(Q)) by precomputed value
On 2 March 2016 at 04:04, Ganesh Ajjanagadde wrote: > On Tue, Mar 1, 2016 at 7:52 AM, Derek Buitenhuis > wrote: > > On 3/1/2016 3:21 AM, Ganesh Ajjanagadde wrote: > > > > [...] > > > >> --- > >> libavcodec/aacenc_utils.h | 3 +-- > >> 1 file changed, 1 insertion(+), 2 deletions(-) > > > > Cool. Looks like an obvious/easy win, assuming it's identical. > > They are not precisely identical, and in fact the change results in > slightly better accuracy wrt the mathematical expression, simply > because sqrtf(q * sqrtf(q)) is not always a correctly rounded float. I > vaguely recall negligible ~ 2/3 ulp differences. The table is > correctly rounded; I tested that while speeding up the tablegen. > > Added a small line to this effect in the notes. > > I did test it for a few test tracks and the results had the exact same SHA1 as before. Either the differences are only affecting in very extreme cases or we've cracked SHA1. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
