[FFmpeg-devel] [PATCH]Allow easy png streamcopying
Hi!
Stream-copying png is currently too difficult.
An alternative is to remove the extension from the apng muxer.
Please comment, Carl Eugen
diff --git a/libavformat/apngenc.c b/libavformat/apngenc.c
index 4b31309..9090f92 100644
--- a/libavformat/apngenc.c
+++ b/libavformat/apngenc.c
@@ -23,6 +23,7 @@
#include "avformat.h"
#include "internal.h"
+#include "rawenc.h"
#include "libavutil/avassert.h"
#include "libavutil/crc.h"
#include "libavutil/intreadwrite.h"
@@ -81,11 +82,14 @@ static int apng_write_header(AVFormatContext
*format_context)
if (format_context->nb_streams != 1 ||
format_context->streams[0]->codec->codec_type != AVMEDIA_TYPE_VIDEO ||
-format_context->streams[0]->codec->codec_id != AV_CODEC_ID_APNG) {
+format_context->streams[0]->codec->codec_id != AV_CODEC_ID_APNG &&
+format_context->streams[0]->codec->codec_id != AV_CODEC_ID_PNG) {
av_log(format_context, AV_LOG_ERROR,
- "APNG muxer supports only a single video APNG stream.\n");
+ "APNG muxer supports only a single video (A)PNG stream.\n");
return AVERROR(EINVAL);
}
+if (format_context->streams[0]->codec->codec_id == AV_CODEC_ID_PNG)
+return 0;
if (apng->last_delay.num > USHRT_MAX || apng->last_delay.den > USHRT_MAX) {
av_reduce(&apng->last_delay.num, &apng->last_delay.den,
@@ -201,6 +205,9 @@ static int apng_write_packet(AVFormatContext
*format_context, AVPacket *packet)
{
APNGMuxContext *apng = format_context->priv_data;
+if (format_context->streams[0]->codec->codec_id == AV_CODEC_ID_PNG)
+return ff_raw_write_packet(format_context, packet);
+
if (!apng->prev_packet) {
apng->prev_packet = av_malloc(sizeof(*apng->prev_packet));
if (!apng->prev_packet)
@@ -220,6 +227,9 @@ static int apng_write_trailer(AVFormatContext
*format_context)
AVIOContext *io_context = format_context->pb;
uint8_t buf[8];
+if (format_context->streams[0]->codec->codec_id == AV_CODEC_ID_PNG)
+return 0;
+
if (apng->prev_packet) {
flush_packet(format_context, NULL);
av_freep(&apng->prev_packet);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Allow easy png streamcopying
Le quartidi 4 floréal, an CCXXIII, Carl Eugen Hoyos a écrit : > Subject: [FFmpeg-devel] [PATCH]Allow easy png streamcopying > > Stream-copying png is currently too difficult. I can not comment on the patch itself, but the commit message should explain what the patch does, not just why it was needed. The patch changes lavf (by the way, it would be nice if you included the diffstat), but "streamcopying" has only meaning for ffmpeg.c, when you have both an input and an output. Maybe something like: lavf/apngenc: accept PNG codec too ? Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add get_device_list() to AVFoundation input device.
This makes avdevice_list_input_sources() available for
device_name = "avfoundation".
I didn't yet retrofit avf_read_header() to use the new function to
keep this patch small.
Signed-off-by: Daniel Ly
---
libavdevice/avfoundation.m | 85 ++
1 file changed, 85 insertions(+)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 763e675..523dc12 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -34,6 +34,7 @@
#include "libavformat/internal.h"
#include "libavutil/internal.h"
#include "libavutil/parseutils.h"
+#include "libavutil/avstring.h"
#include "libavutil/time.h"
#include "avdevice.h"
@@ -1007,6 +1008,89 @@ static int avf_read_packet(AVFormatContext *s, AVPacket
*pkt)
return 0;
}
+static int avf_add_device_info(
+AVDeviceInfoList *list, int index, const char *description, const char
*model
+)
+{
+AVDeviceInfo *info = av_mallocz(sizeof(AVDeviceInfo));
+if (!info) return AVERROR(ENOMEM);
+
+info->device_name = av_asprintf("[%d] %s; %s", index, description, model);
+info->device_description = strdup(description);
+if (!info->device_name || !info->device_description) {
+av_free(info);
+return AVERROR(ENOMEM);
+}
+
+av_dynarray_add(&list->devices, &list->nb_devices, info);
+return list ? list->nb_devices : AVERROR(ENOMEM);
+}
+
+
+static int avf_get_device_list(
+struct AVFormatContext *s, struct AVDeviceInfoList *list
+)
+{
+NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
+uint32_t num_screens= 0;
+AVFContext *ctx = (AVFContext*)s->priv_data;
+NSArray *devices = [AVCaptureDevice devicesWithMediaType:AVMediaTypeVideo];
+
+#if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
+CGGetActiveDisplayList(0, NULL, &num_screens);
+#endif
+
+int result = 0;
+int index;
+const char *localizedName, *modelID;
+
+av_log(ctx, AV_LOG_INFO, "AVFoundation video devices:\n");
+for (AVCaptureDevice *device in devices) {
+index = [devices indexOfObject:device];
+localizedName = [[device localizedName] UTF8String];
+modelID = [[device modelID] UTF8String];
+result = avf_add_device_info(list, index, localizedName, modelID);
+if (result < 0) goto fail;
+av_log(ctx, AV_LOG_INFO, "%s\n", list->devices[result -
1]->device_name);
+}
+#if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
+if (num_screens > 0) {
+CGDirectDisplayID screens[num_screens];
+CGGetActiveDisplayList(num_screens, screens, &num_screens);
+for (int i = 0; i < num_screens; i++) {
+char buf[30];
+snprintf(buf, 30, "Capture screen %d", i);
+
+// No screen name available. Implementation is arcane and uses
+// deprecated API, see http://stackoverflow.com/q/24348142/220060.
+// Perhaps the current screen resolution would be more interesting.
+result = avf_add_device_info(list, index + i + 1, buf, "-");
+if (result < 0) goto fail;
+av_log(ctx, AV_LOG_INFO, "%s\n", list->devices[result -
1]->device_name);
+}
+}
+#endif
+
+av_log(ctx, AV_LOG_INFO, "AVFoundation audio devices:\n");
+devices = [AVCaptureDevice devicesWithMediaType:AVMediaTypeAudio];
+for (AVCaptureDevice *device in devices) {
+index = [devices indexOfObject:device];
+localizedName = [[device localizedName] UTF8String];
+modelID = [[device modelID] UTF8String];
+result = avf_add_device_info(list, index, localizedName, modelID);
+if (result < 0) goto fail;
+av_log(ctx, AV_LOG_INFO, "%s\n", list->devices[result -
1]->device_name);
+}
+
+list->default_device = 0;
+
+fail:
+[pool release];
+destroy_context(ctx);
+
+return result;
+}
+
static int avf_close(AVFormatContext *s)
{
AVFContext* ctx = (AVFContext*)s->priv_data;
@@ -1044,6 +1128,7 @@ AVInputFormat ff_avfoundation_demuxer = {
.read_header= avf_read_header,
.read_packet= avf_read_packet,
.read_close = avf_close,
+.get_device_list= avf_get_device_list,
.flags = AVFMT_NOFILE,
.priv_class = &avf_class,
};
--
1.8.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add get_device_list() to AVFoundation input device.
Am 23.04.15 um 09:35 schrieb Daniel Ly:
> This makes avdevice_list_input_sources() available for
> device_name = "avfoundation".
>
> I didn't yet retrofit avf_read_header() to use the new function to
> keep this patch small.
Please post a follow-up patch for that purpose, too. (In that thread)
> Signed-off-by: Daniel Ly
> ---
> libavdevice/avfoundation.m | 85
> ++
> 1 file changed, 85 insertions(+)
>
> diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
> index 763e675..523dc12 100644
> --- a/libavdevice/avfoundation.m
> +++ b/libavdevice/avfoundation.m
> @@ -34,6 +34,7 @@
> #include "libavformat/internal.h"
> #include "libavutil/internal.h"
> #include "libavutil/parseutils.h"
> +#include "libavutil/avstring.h"
> #include "libavutil/time.h"
> #include "avdevice.h"
>
> @@ -1007,6 +1008,89 @@ static int avf_read_packet(AVFormatContext *s,
> AVPacket *pkt)
> return 0;
> }
>
> +static int avf_add_device_info(
> +AVDeviceInfoList *list, int index, const char *description, const char
> *model
> +)
Paranthesis looks awkward.
> +{
> +AVDeviceInfo *info = av_mallocz(sizeof(AVDeviceInfo));
> +if (!info) return AVERROR(ENOMEM);
> +
> +info->device_name = av_asprintf("[%d] %s; %s", index, description,
> model);
Is this string format kind of standard in FFmpeg? Otherwise I would prefer
description behind model and no ';' but a ':'.
> +info->device_description = strdup(description);
> +if (!info->device_name || !info->device_description) {
> +av_free(info);
> +return AVERROR(ENOMEM);
> +}
> +
> +av_dynarray_add(&list->devices, &list->nb_devices, info);
> +return list ? list->nb_devices : AVERROR(ENOMEM);
I'm not sure if "list" is null'd in case of an error in av_dynarray_add?
> +}
> +
> +
> +static int avf_get_device_list(
> +struct AVFormatContext *s, struct AVDeviceInfoList *list
> +)
See above...
> +{
> +NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> +uint32_t num_screens= 0;
> +AVFContext *ctx = (AVFContext*)s->priv_data;
> +NSArray *devices = [AVCaptureDevice
> devicesWithMediaType:AVMediaTypeVideo];
Please align vertically even if one line gets too long by that.
> +
> +#if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
> +CGGetActiveDisplayList(0, NULL, &num_screens);
> +#endif
> +
> +int result = 0;
> +int index;
> +const char *localizedName, *modelID;
> +
> +av_log(ctx, AV_LOG_INFO, "AVFoundation video devices:\n");
> +for (AVCaptureDevice *device in devices) {
> +index = [devices indexOfObject:device];
> +localizedName = [[device localizedName] UTF8String];
> +modelID = [[device modelID] UTF8String];
> +result = avf_add_device_info(list, index, localizedName, modelID);
Vertical alignment.
> +if (result < 0) goto fail;
> +av_log(ctx, AV_LOG_INFO, "%s\n", list->devices[result -
> 1]->device_name);
Segfault if result == 0?
> +}
> +#if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
> +if (num_screens > 0) {
> +CGDirectDisplayID screens[num_screens];
> +CGGetActiveDisplayList(num_screens, screens, &num_screens);
> +for (int i = 0; i < num_screens; i++) {
> +char buf[30];
> +snprintf(buf, 30, "Capture screen %d", i);
> +
> +// No screen name available. Implementation is arcane and uses
> +// deprecated API, see
> http://stackoverflow.com/q/24348142/220060.
> +// Perhaps the current screen resolution would be more
> interesting.
> +result = avf_add_device_info(list, index + i + 1, buf, "-");
> +if (result < 0) goto fail;
> +av_log(ctx, AV_LOG_INFO, "%s\n", list->devices[result -
> 1]->device_name);
> +}
> +}
> +#endif
> +
> +av_log(ctx, AV_LOG_INFO, "AVFoundation audio devices:\n");
> +devices = [AVCaptureDevice devicesWithMediaType:AVMediaTypeAudio];
> +for (AVCaptureDevice *device in devices) {
> +index = [devices indexOfObject:device];
> +localizedName = [[device localizedName] UTF8String];
> +modelID = [[device modelID] UTF8String];
> +result = avf_add_device_info(list, index, localizedName, modelID);
> +if (result < 0) goto fail;
> +av_log(ctx, AV_LOG_INFO, "%s\n", list->devices[result -
> 1]->device_name);
> +}
> +
> +list->default_device = 0;
> +
> +fail:
> +[pool release];
> +destroy_context(ctx);
> +
> +return result;
> +}
> +
> static int avf_close(AVFormatContext *s)
> {
> AVFContext* ctx = (AVFContext*)s->priv_data;
> @@ -1044,6 +1128,7 @@ AVInputFormat ff_avfoundation_demuxer = {
> .read_header= avf_read_header,
> .read_packet= avf_read_packet,
> .read_close = avf_close,
> +.get_device_list= avf_get_device_list,
> .flags
[FFmpeg-devel] [PATCH] Add get_device_list() to AVFoundation input device.
This makes avdevice_list_input_sources() available for
device_name = "avfoundation".
I didn't yet retrofit avf_read_header() to use the new function to
keep this patch small. I will post the follow-up patch in the same
thread.
Signed-off-by: Daniel Ly
---
libavdevice/avfoundation.m | 98 ++
1 file changed, 90 insertions(+), 8 deletions(-)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 763e675..19ce2a0 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -34,6 +34,7 @@
#include "libavformat/internal.h"
#include "libavutil/internal.h"
#include "libavutil/parseutils.h"
+#include "libavutil/avstring.h"
#include "libavutil/time.h"
#include "avdevice.h"
@@ -1007,6 +1008,86 @@ static int avf_read_packet(AVFormatContext *s, AVPacket
*pkt)
return 0;
}
+static int avf_add_device_info(AVDeviceInfoList *list, AVFormatContext *s,
+int index, const char *description, const char *model)
+{
+AVDeviceInfo *info = av_mallocz(sizeof(AVDeviceInfo));
+if (!info) return AVERROR(ENOMEM);
+
+info->device_name = av_asprintf("[%d] %s: %s", index, description, model);
+info->device_description = strdup(description);
+if (!info->device_name || !info->device_description) {
+av_free(info);
+return AVERROR(ENOMEM);
+}
+
+av_log(s->priv_data, AV_LOG_INFO, "%s\n", info->device_name);
+av_dynarray_add(&list->devices, &list->nb_devices, info);
+
+return list ? list->nb_devices : AVERROR(ENOMEM);
+}
+
+
+static int avf_get_device_list(struct AVFormatContext *s, struct
AVDeviceInfoList *list)
+{
+int result = 0, index;
+const char *localizedName, *modelID;
+
+av_log(s->priv_data, AV_LOG_INFO, "AVFoundation video devices:\n");
+NSArray *video_devices = [AVCaptureDevice
devicesWithMediaType:AVMediaTypeVideo];
+for (AVCaptureDevice *device in video_devices) {
+@autoreleasepool {
+index = [video_devices indexOfObject:device];
+localizedName = [[device localizedName] UTF8String];
+modelID = [[device modelID] UTF8String];
+
+result = avf_add_device_info(list, s, index, localizedName,
modelID);
+if (result < 0) break;
+}
+}
+[video_devices release];
+
+
+#if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
+uint32_t num_screens = 0;
+CGGetActiveDisplayList(0, NULL, &num_screens);
+
+if (num_screens > 0) {
+CGDirectDisplayID screens[num_screens];
+CGGetActiveDisplayList(num_screens, screens, &num_screens);
+int i;
+for (i = 0; i < num_screens; i++) {
+char buf[30];
+snprintf(buf, 30, "Capture screen %d", i);
+
+// No screen name available (as model). Implementation is arcane
+// and uses deprecated API. See stackoverflow.com/q/24348142/220060
+result = avf_add_device_info(list, s, index + i + 1, buf, "-");
+if (result < 0) break;
+}
+}
+#endif
+
+av_log(s->priv_data, AV_LOG_INFO, "AVFoundation audio devices:\n");
+NSArray *audio_devices = [AVCaptureDevice
devicesWithMediaType:AVMediaTypeVideo];
+for (AVCaptureDevice *device in audio_devices) {
+@autoreleasepool {
+index = [audio_devices indexOfObject:device];
+localizedName = [[device localizedName] UTF8String];
+modelID = [[device modelID] UTF8String];
+
+result = avf_add_device_info(list, s, index, localizedName,
modelID);
+if (result < 0) break;
+}
+}
+[audio_devices release];
+
+// Make the first device default if it exists.
+list->default_device = list->nb_devices > 0 ? 0 : -1;
+
+return result;
+}
+
static int avf_close(AVFormatContext *s)
{
AVFContext* ctx = (AVFContext*)s->priv_data;
@@ -1038,12 +1119,13 @@ static const AVClass avf_class = {
};
AVInputFormat ff_avfoundation_demuxer = {
-.name = "avfoundation",
-.long_name = NULL_IF_CONFIG_SMALL("AVFoundation input device"),
-.priv_data_size = sizeof(AVFContext),
-.read_header= avf_read_header,
-.read_packet= avf_read_packet,
-.read_close = avf_close,
-.flags = AVFMT_NOFILE,
-.priv_class = &avf_class,
+.name= "avfoundation",
+.long_name = NULL_IF_CONFIG_SMALL("AVFoundation input device"),
+.priv_data_size = sizeof(AVFContext),
+.read_header = avf_read_header,
+.read_packet = avf_read_packet,
+.read_close = avf_close,
+.get_device_list = avf_get_device_list,
+.flags = AVFMT_NOFILE,
+.priv_class = &avf_class,
};
--
1.8.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add get_device_list() to AVFoundation input device.
On Thu, Apr 23, 2015 at 11:07:43AM +0200, Daniel Ly wrote:
> This makes avdevice_list_input_sources() available for
> device_name = "avfoundation".
>
> I didn't yet retrofit avf_read_header() to use the new function to
> keep this patch small. I will post the follow-up patch in the same
> thread.
>
> Signed-off-by: Daniel Ly
> ---
> libavdevice/avfoundation.m | 98
> ++
> 1 file changed, 90 insertions(+), 8 deletions(-)
>
> diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
> index 763e675..19ce2a0 100644
> --- a/libavdevice/avfoundation.m
> +++ b/libavdevice/avfoundation.m
> @@ -34,6 +34,7 @@
> #include "libavformat/internal.h"
> #include "libavutil/internal.h"
> #include "libavutil/parseutils.h"
> +#include "libavutil/avstring.h"
> #include "libavutil/time.h"
> #include "avdevice.h"
>
> @@ -1007,6 +1008,86 @@ static int avf_read_packet(AVFormatContext *s,
> AVPacket *pkt)
> return 0;
> }
>
> +static int avf_add_device_info(AVDeviceInfoList *list, AVFormatContext *s,
> +int index, const char *description, const char *model)
> +{
> +AVDeviceInfo *info = av_mallocz(sizeof(AVDeviceInfo));
> +if (!info) return AVERROR(ENOMEM);
> +
> +info->device_name = av_asprintf("[%d] %s: %s", index, description,
> model);
> +info->device_description = strdup(description);
> +if (!info->device_name || !info->device_description) {
> +av_free(info);
> +return AVERROR(ENOMEM);
> +}
> +
> +av_log(s->priv_data, AV_LOG_INFO, "%s\n", info->device_name);
Why do you log this?
Won't this cause a dup of the list in the output?
[...]
--
Clément B.
pgpKCQXV4szYr.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add get_device_list() to AVFoundation input device.
Am 23.04.15 um 11:07 schrieb Daniel Ly:
> This makes avdevice_list_input_sources() available for
> device_name = "avfoundation".
>
> I didn't yet retrofit avf_read_header() to use the new function to
> keep this patch small. I will post the follow-up patch in the same
> thread.
>
> Signed-off-by: Daniel Ly
> ---
> libavdevice/avfoundation.m | 98
> ++
> 1 file changed, 90 insertions(+), 8 deletions(-)
>
> diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
> index 763e675..19ce2a0 100644
> --- a/libavdevice/avfoundation.m
> +++ b/libavdevice/avfoundation.m
> @@ -34,6 +34,7 @@
> #include "libavformat/internal.h"
> #include "libavutil/internal.h"
> #include "libavutil/parseutils.h"
> +#include "libavutil/avstring.h"
> #include "libavutil/time.h"
> #include "avdevice.h"
>
> @@ -1007,6 +1008,86 @@ static int avf_read_packet(AVFormatContext *s,
> AVPacket *pkt)
> return 0;
> }
>
> +static int avf_add_device_info(AVDeviceInfoList *list, AVFormatContext *s,
> +int index, const char *description, const char *model)
> +{
> +AVDeviceInfo *info = av_mallocz(sizeof(AVDeviceInfo));
> +if (!info) return AVERROR(ENOMEM);
> +
> +info->device_name = av_asprintf("[%d] %s: %s", index, description,
> model);
So I assume that this is not parsed later.
However, it changes current output format and should interfere with
parse_device_string(). Consider choosing the very same format string which is
there already.
> +info->device_description = strdup(description);
> +if (!info->device_name || !info->device_description) {
> +av_free(info);
> +return AVERROR(ENOMEM);
> +}
> +
> +av_log(s->priv_data, AV_LOG_INFO, "%s\n", info->device_name);
This always prints all devices, which is an unwanted behaviour.
Currently you have to cause an error (e.g. wrong index) or explicitly call with
-list_devices to get that.
Otherwise it already looks good. However, your follow-up patch incorporating
this to avoid redundancy will show if it is ok to commit.
-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFMpeg-Devel][GSoC][PATCH 1/2] postproc: Updated postprocess_template to use new sse/avx deinterlace functions
On Thu, Apr 23, 2015 at 12:20:37AM -0400, Tucker DiNapoli wrote: > A few notes on changes from the last version of this patch. > The main issue with the previous code was with the sse2/avx2 > implementation of the blockCopy function, so for the time being the MMX2 > version > is used instead. I tried to place the MMX2 version into a function, but this > did not work, my best guess as to why is alignment, but I really don't know. > The way it's done now is a bit ugly but it works and I don't have time to > figure > out the issue right now. > > This commit adds several new files containing yasm assembly code, they are: > PPContext.asm; Defines the PPContext struct using the yasm struc command > PPUtil.asm; Various utility macros used in the other asm code > block_copy.asm; Implements the block copy function, the sse2 and avx2 > versions copy multiple blocks at once. > deinterlace.asm; Contains implemenations of the postprocessing filters > with support for sse2 and avx2. > > Adding these new functions to postprocess_template entailed adding a new > templates for AVX2 and modifying the current SSE2 template to use the > sse2 functions. A new deinterlace function was added to move the logic > of which deinterlace function to use out of the postprocess function and > make adding the new functions eaiser. The inline code for packing QP > into pQPb was moved into a seperate asm file and uptaded for sse2/avx2. > > Currently the sse2/avx2 deinterlace filters don't give results which are > bitexact to the C results, so I've modified one of the postprocessing > tests so that only the C funcitons are tested by fate. Ultimately either > the sse2/avx2 code will need to be fixed or diffrent tests will need to > be added. I'm not sure if this is a problem with my code, a problem inherent > in using sse2/avx2 or a problem that's a result of deinterlacing being done > blockwise. On a AVX machine (using SSE2 i assume) -vf pp=md -vf pp=lb -vf pp=ci -vf pp=fd -vf pp=l5 tested with ./ffplay matrixbench_mpeg2.mpg -vf tinterlace=4,pp=XX shows blocking artifacts as if some deinterlace function is applied to only every second column of some size thats not just not bitexact that is completely not working On a AVX2 machine the tests above produce an output that looks as if one out of 4 columns is filtered with the other 3 still showing interlacing artifacts also the code produces these warnings libpostproc/x86/PPContext.asm:37: warning: section flags ignored on section redeclaration libpostproc/x86/PPContext.asm:77: warning: section flags ignored on section redeclaration libpostproc/x86/PPUtil.asm:215: warning: section flags ignored on section redeclaration [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFMpeg-Devel][GSoC][PATCH 2/2] postproc: Added support for sse2/avx2 versions of the do_a_deblock function
On Thu, Apr 23, 2015 at 12:20:38AM -0400, Tucker DiNapoli wrote:
> I added a new file with the sse2/avx2 code for do_a_deblock.
> I also moved the code for running vertical deblock filters into it's own
> function, both to clean up the postprocess funciton and to make it
> easier to integrate the new sse2/avx2 versions of these filters.
> ---
> libpostproc/postprocess_template.c | 123 +++---
> libpostproc/x86/Makefile | 1 +
> libpostproc/x86/deblock.asm| 454
> +
> 3 files changed, 545 insertions(+), 33 deletions(-)
> create mode 100644 libpostproc/x86/deblock.asm
putting a av_log() before the old inline asm for do_a_deblock*()
and a jump to NULL in the yasm code shows that only the old code is
executed when testing as in:
./ffplay matrixbench_mpeg2.mpg -vf pp=ha/va
postproc clearly does not use the new code so i have no idea how to
test it
tested both on AVX and AVX2 machines
also there is:
In file included from libpostproc/postprocess.c:538:0:
libpostproc/postprocess_template.c: In function ‘deblock_MMX’:
libpostproc/postprocess_template.c:3414:20: note: The ABI for passing
parameters with 32-byte alignment has changed in GCC 4.6
static inline void RENAME(deblock)(uint8_t *dstBlock, int stride,
^
diff --git a/libpostproc/postprocess_template.c
b/libpostproc/postprocess_template.c
index 9bff458..f98a00c 100644
--- a/libpostproc/postprocess_template.c
+++ b/libpostproc/postprocess_template.c
@@ -2649,6 +2649,7 @@ static av_always_inline void RENAME(do_a_deblock)(uint8_t
*src, int step, int st
int64_t dc_mask, eq_mask, both_masks;
int64_t sums[10*8*2];
src+= step*3; // src points to begin of the 8x8 Block
+av_log(0,0, "Old do_a_deblock\n");
//{ START_TIMER
__asm__ volatile(
"movq %0, %%mm7 \n\t"
diff --git a/libpostproc/x86/deblock.asm b/libpostproc/x86/deblock.asm
index fbee291..1aa91f5 100644
--- a/libpostproc/x86/deblock.asm
+++ b/libpostproc/x86/deblock.asm
@@ -28,6 +28,9 @@
cglobal do_a_deblock, 5, 6, 7, 22 * mmsize ;src, step, stride, ppcontext, mode
;; stride, mode arguments are unused, but kept for compatability with
;; existing c version. They will be removed eventually
+xor r0, r0
+jmp r0
+
lea r0, [r0 + r1*2]
add r0, r1
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Allow easy png streamcopying
Nicolas George nsup.org> writes: > > Stream-copying png is currently too difficult. > > I can not comment on the patch itself, but the > commit message should explain what the patch does, > not just why it was needed. I believe it is much more important to explain why. [...] > Maybe something like: > > lavf/apngenc: accept PNG codec too Changed locally. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add mp3 CBR seek test
On Wed, Apr 22, 2015 at 07:57:02PM +0200, wm4 wrote: > This tests the "old", now non-default seek mode, and this requires a > special extra argument. > --- > Requested... not like I think this test is overly useful. > --- > libavformat/seek-test.c | 2 ++ > tests/fate/seek.mak | 13 +--- > tests/ref/seek/extra-mp3 | 53 > > 3 files changed, 65 insertions(+), 3 deletions(-) > create mode 100644 tests/ref/seek/extra-mp3 applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Allow easy png streamcopying
On Thu, 23 Apr 2015 09:25:44 +0200 Carl Eugen Hoyos wrote: > Hi! > > Stream-copying png is currently too difficult. > An alternative is to remove the extension from the apng muxer. > > Please comment, Carl Eugen I don't understand why apng would use the png file extension. This makes it way too easy to creates PNGs with ffmpeg.c that are not standard conform. So, I suggest to just remove the extension and be done with it. (Yes, APNG is a non-standard hack not supported by the PNG standard.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/wvdec: fix seeking
While I'm not sure why exactly sure why the old code could end up in the
wrong position, using the generic index code is much simpler and is
known to work correctly.
---
A sample for testing can be produced with ffmpeg itself.
---
libavformat/wvdec.c | 38 ++
1 file changed, 2 insertions(+), 36 deletions(-)
diff --git a/libavformat/wvdec.c b/libavformat/wvdec.c
index 4e58512..96a631f 100644
--- a/libavformat/wvdec.c
+++ b/libavformat/wvdec.c
@@ -296,6 +296,7 @@ static int wv_read_packet(AVFormatContext *s, AVPacket *pkt)
}
}
pkt->stream_index = 0;
+pkt->pos = pos;
wc->block_parsed = 1;
pkt->pts = wc->header.block_idx;
block_samples = wc->header.samples;
@@ -305,41 +306,6 @@ static int wv_read_packet(AVFormatContext *s, AVPacket
*pkt)
else
pkt->duration = block_samples;
-av_add_index_entry(s->streams[0], pos, pkt->pts, 0, 0, AVINDEX_KEYFRAME);
-return 0;
-}
-
-static int wv_read_seek(AVFormatContext *s, int stream_index,
-int64_t timestamp, int flags)
-{
-AVStream *st = s->streams[stream_index];
-WVContext *wc = s->priv_data;
-AVPacket pkt1, *pkt = &pkt1;
-int ret;
-int index = av_index_search_timestamp(st, timestamp, flags);
-int64_t pos, pts;
-
-/* if found, seek there */
-if (index >= 0 &&
-timestamp <= st->index_entries[st->nb_index_entries - 1].timestamp) {
-wc->block_parsed = 1;
-avio_seek(s->pb, st->index_entries[index].pos, SEEK_SET);
-return 0;
-}
-/* if timestamp is out of bounds, return error */
-if (timestamp < 0 || timestamp >= s->duration)
-return AVERROR(EINVAL);
-
-pos = avio_tell(s->pb);
-do {
-ret = av_read_frame(s, pkt);
-if (ret < 0) {
-avio_seek(s->pb, pos, SEEK_SET);
-return ret;
-}
-pts = pkt->pts;
-av_free_packet(pkt);
-} while(pts < timestamp);
return 0;
}
@@ -350,5 +316,5 @@ AVInputFormat ff_wv_demuxer = {
.read_probe = wv_probe,
.read_header= wv_read_header,
.read_packet= wv_read_packet,
-.read_seek = wv_read_seek,
+.flags = AVFMT_GENERIC_INDEX,
};
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Allow easy png streamcopying
wm4 googlemail.com> writes: > > Stream-copying png is currently too difficult. > > An alternative is to remove the extension from the > > apng muxer. > > > > Please comment, Carl Eugen > > I don't understand why apng would use the png file > extension. As said, removing the extension is also a possibility, I only care about the regression being fixed. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg: remove incorrect network deinit
Signed-off-by: Michael Niedermayer --- ffmpeg.c |1 - 1 file changed, 1 deletion(-) diff --git a/ffmpeg.c b/ffmpeg.c index 1ba0a42..7e5b16d 100644 --- a/ffmpeg.c +++ b/ffmpeg.c @@ -352,7 +352,6 @@ void term_init(void) signal(SIGQUIT, sigterm_handler); /* Quit (POSIX). */ } #endif -avformat_network_deinit(); signal(SIGINT , sigterm_handler); /* Interrupt (ANSI).*/ signal(SIGTERM, sigterm_handler); /* Termination (ANSI). */ -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Allow easy png streamcopying
On Thu, Apr 23, 2015 at 12:14:43PM +, Carl Eugen Hoyos wrote: > wm4 googlemail.com> writes: > > > > Stream-copying png is currently too difficult. > > > An alternative is to remove the extension from the > > > apng muxer. > > > > > > Please comment, Carl Eugen > > > > I don't understand why apng would use the png file > > extension. > > As said, removing the extension is also a possibility, > I only care about the regression being fixed. without really thinking about it, the idea to remove the extension for apng or change it to .apng, seems like a good idea [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Allow easy png streamcopying
Le quartidi 4 floréal, an CCXXIII, Michael Niedermayer a écrit : > without really thinking about it, the idea to remove the extension > for apng or change it to .apng, seems like a good idea It looks like it is an officially supported extension, and having the same extension for two not-really-compatible formats is a bad idea, so I second that (except I am the fourth, not the second). Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] tests/tiny_psnr: do not ignore errors from run_psnr
On Wed, Apr 22, 2015 at 09:10:51PM -0700, Timothy Gu wrote: > On Thu, Apr 23, 2015 at 04:43:09AM +0200, Michael Niedermayer wrote: > > failure to calculate psnr should not result in tiny_psnr returning success > > > > Signed-off-by: Michael Niedermayer > > --- > > tests/tiny_psnr.c |9 ++--- > > 1 file changed, 6 insertions(+), 3 deletions(-) > > Patchset LGTM. Would be cool if you can add a link to a broken FATE results > page in the second patch commit message though. i can add a link if someone has one, i seem not lucky in finding one quickly ATM first patch applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] vp9: add lf_deltas fate test.
On Wed, Apr 22, 2015 at 11:51:03AM -0400, Ronald S. Bultje wrote: > Sample available at: > http://downloads.webmproject.org/test_data/libvpx/vp90-2-09-lf_deltas.webm uploaded [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] vp9: maintain lf_delta values if feature is turned off.
On Wed, Apr 22, 2015 at 11:51:02AM -0400, Ronald S. Bultje wrote: > This is required if it's subsequently re-enabled with no value updates > (which means, use values that were previously set). > --- > libavcodec/vp9.c | 27 +++ > 1 file changed, 15 insertions(+), 12 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. 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/3] vp9: add fate test for bilinear MC filter.
On Wed, Apr 22, 2015 at 11:51:01AM -0400, Ronald S. Bultje wrote: > Sample at: > http://downloads.webmproject.org/test_data/libvpx/vp90-2-06-bilinear.webm > --- > tests/fate/vpx.mak | 1 + > tests/ref/fate/vp9-06-bilinear | 15 +++ > 2 files changed, 16 insertions(+) > create mode 100644 tests/ref/fate/vp9-06-bilinear applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Allow easy png streamcopying
On 23 April 2015 at 23:38, Nicolas George wrote: > Le quartidi 4 floréal, an CCXXIII, Michael Niedermayer a écrit : > > without really thinking about it, the idea to remove the extension > > for apng or change it to .apng, seems like a good idea > > It looks like it is an officially supported extension, and having the same > extension for two not-really-compatible formats is a bad idea > APNG is meant to be "backwards compatible" with PNG though. That is, non-APNG aware programs would just ignore the extra APNG data. Regards, Donny ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] alac: validate k before using show_bits in decode_scalar
On Wed, Apr 22, 2015 at 06:24:54PM +0200, Andreas Cadhalpun wrote: > The k != 1 case calls show_bits(gb, k), which doesn't make sense if k > is 0. i dont think k = 0 is allowed i suggest you check rice_limit when it is set, i assume that is the source of k=0 asking for a sample with rice_limit=0 if it occurs is also a good idea [...] -- 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
Re: [FFmpeg-devel] [PATCH] alsdec: only adapt order for positive max_order
On Wed, Apr 22, 2015 at 04:03:41PM +0200, Andreas Cadhalpun wrote: > For max_order = 0 the clipping range is invalid. (amin = 2, amax = 1) > > Signed-off-by: Andreas Cadhalpun > --- > libavcodec/alsdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] git-howto.texi: fix a typo
On Thu, Apr 23, 2015 at 12:57:49AM -0700, James Zern wrote: > replace 'Refer to and to sync...' with a reference to the section that > discusses updated the source tree. > --- > doc/git-howto.texi | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) LGTM thanks [...] -- 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 1/3] libvpxenc: only set noise reduction w/vp8
On Wed, Apr 22, 2015 at 08:58:35PM -0700, James Zern wrote: > this quiets a warning: > Failed to set VP8E_SET_NOISE_SENSITIVITY codec control: Unspecified > internal error > --- > libavcodec/libvpxenc.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH] aacsbr: break infinite loop in sbr_hf_calc_npatches
On Wed, Apr 22, 2015 at 1:52 PM, Vittorio Giovara wrote: I don't think the INVALIDDATA return will have the desired effect. I think you want return -1; >>> >>> This function is only called once and there the check is: >>> if (sbr_hf_calc_npatches(ac, sbr) < 0) >>> return -1; >>> >>> Thus returning AVERROR_INVALIDDATA works as well as -1. >> >> The fact that AVERROR_INVALIDDATA < 0 is a close call on 32 bit platforms. >> >> Still, it's not a new assumption in the code, so I'll grant you that. > > What do you mean by "A close call"? All AVERROR_* are negative by > design, and they carry more information than a -1, so their increased > usage is certainly welcome. > The fact that it does not get propagated is a separate issue. Just that it's not obvious, and I was thinking error-prone, but now I think it was just a reaction to it being non-obvious to me. So nothing relevant. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH] aacsbr: break infinite loop in sbr_hf_calc_npatches
On Thu, Apr 23, 2015 at 12:22:49PM -0300, Claudio Freire wrote: > On Wed, Apr 22, 2015 at 1:52 PM, Vittorio Giovara > wrote: > I don't think the INVALIDDATA return will have the desired effect. > > I think you want return -1; > >>> > >>> This function is only called once and there the check is: > >>> if (sbr_hf_calc_npatches(ac, sbr) < 0) > >>> return -1; > >>> > >>> Thus returning AVERROR_INVALIDDATA works as well as -1. > >> > >> The fact that AVERROR_INVALIDDATA < 0 is a close call on 32 bit platforms. > >> > >> Still, it's not a new assumption in the code, so I'll grant you that. > > > > What do you mean by "A close call"? All AVERROR_* are negative by > > design, and they carry more information than a -1, so their increased > > usage is certainly welcome. > > The fact that it does not get propagated is a separate issue. > > Just that it's not obvious, and I was thinking error-prone, but now I > think it was just a reaction to it being non-obvious to me. > > So nothing relevant. ok, so is the patch the correct solution or are the fields already invalid before this loop and should have been checked prior ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope 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] vp9: add fate test for segmentation image-edge issue.
On Wed, Apr 22, 2015 at 08:19:00PM -0400, Ronald S. Bultje wrote: > Sample available at: > http://downloads.webmproject.org/test_data/libvpx/vp90-2-15-segkey_adpq.webm will upload in a moment [...] -- 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 2/2] vp9: add fate test for intraonly frames.
On Wed, Apr 22, 2015 at 08:59:47PM -0400, Ronald S. Bultje wrote: > Sample available at: > http://downloads.webmproject.org/test_data/libvpx/vp90-2-16-intra-only.webm will upload in a moment [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH] aacsbr: break infinite loop in sbr_hf_calc_npatches
On Thu, Apr 23, 2015 at 12:43 PM, Michael Niedermayer wrote: > On Thu, Apr 23, 2015 at 12:22:49PM -0300, Claudio Freire wrote: >> On Wed, Apr 22, 2015 at 1:52 PM, Vittorio Giovara >> wrote: >> I don't think the INVALIDDATA return will have the desired effect. >> >> I think you want return -1; >> >>> >> >>> This function is only called once and there the check is: >> >>> if (sbr_hf_calc_npatches(ac, sbr) < 0) >> >>> return -1; >> >>> >> >>> Thus returning AVERROR_INVALIDDATA works as well as -1. >> >> >> >> The fact that AVERROR_INVALIDDATA < 0 is a close call on 32 bit platforms. >> >> >> >> Still, it's not a new assumption in the code, so I'll grant you that. >> > >> > What do you mean by "A close call"? All AVERROR_* are negative by >> > design, and they carry more information than a -1, so their increased >> > usage is certainly welcome. >> > The fact that it does not get propagated is a separate issue. >> >> Just that it's not obvious, and I was thinking error-prone, but now I >> think it was just a reaction to it being non-obvious to me. >> >> So nothing relevant. > > ok, so is the patch the correct solution or are the fields already > invalid before this loop and should have been checked prior ? I think either the fields are already invalid before the loop (which could mean an invalid file), or there is a slight bug on the loop, the patch just avoids infinite loop in those cases. What I'm yet unable to decide is whether it's the first or the second case (invalid input file vs bugged loop). I'll have to carefully review the specs for that, and sadly I only have drafts. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] vp9: add fate tests for show-existing-frame feature.
On Wed, Apr 22, 2015 at 12:24:41PM -0400, Ronald S. Bultje wrote: > Samples available at: > http://downloads.webmproject.org/test_data/libvpx/vp90-2-10-show-existing-frame.webm > http://downloads.webmproject.org/test_data/libvpx/vp90-2-10-show-existing-frame2.webm uploaded [...] -- 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
[FFmpeg-devel] [PATCH] libavcodec/exr.c : exr lossy compression B44 added
for patch PFA
Greeshma
From c10e182e56310cfc5ebd6c6f8801128668042a2a Mon Sep 17 00:00:00 2001
From: greeshmab
Date: Mon, 20 Apr 2015 23:33:55 +0530
Subject: [PATCH] exr lossy compression B44 added
---
libavcodec/exr.c | 114 +++
1 file changed, 114 insertions(+)
diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index f9525ec..92ecc9b 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -770,6 +770,115 @@ static int piz_uncompress(EXRContext *s, const uint8_t *src, int ssize,
return 0;
}
+static void B44_unpack14 ( GetByteContext *gb, uint16_t out[16]){
+uint16_t shift;
+const uint8_t *r = gb->buffer;
+av_assert0(r[2] != 0xfc);
+out[0] = (r[0] << 8) | r[1];
+shift = (r[2] >> 2);
+out[ 1] = out[ 0] + ((r[ 5] >> 2) << shift);
+out[ 2] = out[ 1] + ((r[ 8] >> 2) << shift);
+out[ 3] = out[ 2] + ((r[11] >> 2) << shift);
+out[ 4] = out[ 0] + (((r[ 2] << 4) | (r[ 3] >> 4)) << shift);
+out[ 5] = out[ 4] + (((r[ 5] << 4) | (r[ 6] >> 4)) << shift);
+out[ 6] = out[ 5] + (((r[ 8] << 4) | (r[ 9] >> 4)) << shift);
+out[ 7] = out[ 6] + (((r[11] << 4) | (r[12] >> 4)) << shift);
+out[ 8] = out[ 4] + (((r[ 3] << 2) | (r[ 4] >> 6)) << shift);
+out[ 9] = out[ 8] + (((r[ 6] << 2) | (r[ 7] >> 6)) << shift);
+out[10] = out[ 9] + (((r[ 9] << 2) | (r[10] >> 6)) << shift);
+out[11] = out[10] + (((r[12] << 2) | (r[13] >> 6)) << shift);
+out[12] = out[ 8] + (r[ 4] << shift);
+out[13] = out[12] + (r[ 7] << shift);
+out[14] = out[13] + (r[10] << shift);
+out[15] = out[14] + (r[13] << shift);
+for (int i = 0; i < 16; ++i) { //if any out value exceeds 16bits
+if (out[i] & 0x8000)
+out[i] &= 0x7fff;
+else
+out[i] = ~out[i];
+}
+}
+
+static void B44_unpack3 ( GetByteContext *gb, uint16_t out[16]){
+const uint8_t *r = gb->buffer; //pixels have the same value
+av_assert0(r[2] == 0xfc);
+out[0] = (r[0] << 8) | r[1];
+if (out[0] & 0x8000)
+out[0] &= 0x7fff;
+else
+out[0] = ~out[0];
+for (int i = 1; i < 16; ++i)
+out[i] = out[0];
+}
+
+static int b44_uncompress(EXRContext *s, const uint8_t *src,int ssize, int dsize, EXRThreadData *td){
+GetByteContext gb;
+unsigned long dest_len = dsize;
+uint8_t *out;
+int i, j;
+uint16_t *tmp = (uint16_t *)td->tmp;
+out = td->uncompressed_data;
+bytestream2_init(&gb, src, ssize);
+if (uncompress(td->tmp, &dest_len, src, ssize) != Z_OK || dest_len != dsize)
+return AVERROR_INVALIDDATA;
+for (i = 0; i < s->nb_channels; i++) {
+EXRChannel *channel = &s->channels[i];
+int size = channel->pixel_type;
+int inSize = ssize;
+if (channel->pixel_type != EXR_HALF) { // UINT or FLOAT channel.
+int n = s->xdelta * s->ydelta * size * sizeof (*tmp);
+memcpy (tmp, gb.buffer, n);
+gb.buffer += n;
+inSize -= n;
+continue;
+} else {//EXR_HALF Channel
+for (int y=0; y < s->ydelta; y +=4 ) {
+uint16_t *row0 = tmp + y * s->xdelta;
+uint16_t *row1 = row0 + s->xdelta;
+uint16_t *row2 = row1 + s->xdelta;
+uint16_t *row3 = row2 + s->xdelta;
+for (int x = 0; x < s->xdelta; x += 4) {
+uint16_t out[16];
+int num = (x + 3 < s->xdelta)? 4 * sizeof (*out) : (s->xdelta - x) * sizeof (*out);
+if (gb.buffer[2] == 0xfc) {
+B44_unpack3 (&gb, out);
+gb.buffer += 3;
+inSize -= 3;
+} else {
+B44_unpack14 (&gb, out);
+gb.buffer += 14;
+inSize -= 14;
+}
+if (y + 3 < s->ydelta) {
+memcpy (row0, &out[ 0], num);
+memcpy (row1, &out[ 4], num);
+memcpy (row2, &out[ 8], num);
+memcpy (row3, &out[12], num);
+} else {
+memcpy (row0, &out[ 0], num);
+if (y + 1 < s->ydelta)
+memcpy (row1, &out[ 4], num);
+if (y + 2 < s->ydelta)
+memcpy (row2, &out[ 8], num);
+}
+row0 += 4;
+row1 += 4;
+row2 += 4;
+row3 += 4;
+}
+}
+}
+}
+for (i = 0; i < s->ysize; i++) {
+for (j = 0; j < s->nb_channels; j++) {
+uint16_t *in = tmp + j * s->xdelta * s->ysize + i * s->xdelta;
+memcpy(out, in, s->xdelta * 2);
+out += s
[FFmpeg-devel] [GSoC] Patch which add simple P frame support for ffv1
Hi, everyone. This is my GSoC qualification task, add simple P frame for ffv1. P frame will work when you add -level 4. eg. ffmpeg -pix_fmt yuv420p -s -i xx.yuv -vcodec ffv1 -level 4 test.nut Notice: Only support yuv colorspace and 8 bit currently, i will support these in later time. Other option about ffv1 can be find here: http://trac.ffmpeg.org/wiki/Encode/FFV1 About test. I haven't send FATE result to server as i'm not that familiar with those staff. But i will complete this as soon as possible. Best regards 0001-Add-simple-P-frame-support-for-ffv1.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFMpeg-Devel][GSoC][PATCH 1/2] postproc: Updated postprocess_template to use new sse/avx deinterlace functions
On 23/04/15 7:05 AM, Michael Niedermayer wrote: > also the code produces these warnings > libpostproc/x86/PPContext.asm:37: warning: section flags ignored on section > redeclaration > libpostproc/x86/PPContext.asm:77: warning: section flags ignored on section > redeclaration > libpostproc/x86/PPUtil.asm:215: warning: section flags ignored on section > redeclaration > This happens other asm files that define one or more structs as well. libavcodec/x86/fft.asm and libswresample/x86/resample.asm produce the same warnings on some systems. Not sure what exactly causes them. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] Patch which add simple P frame support for ffv1
On Fri, Apr 24, 2015 at 12:03:38AM +0800, Yingming Fan wrote: > Hi, everyone. > > This is my GSoC qualification task, add simple P frame for ffv1. > > P frame will work when you add -level 4. > > eg. ffmpeg -pix_fmt yuv420p -s -i xx.yuv -vcodec ffv1 -level 4 test.nut > > Notice: Only support yuv colorspace and 8 bit currently, i will support > these in later time. > > Other option about ffv1 can be find here: > http://trac.ffmpeg.org/wiki/Encode/FFV1 > > About test. > > I haven't send FATE result to server as i'm not that familiar with those > staff. But i will complete this as soon as possible. > > Best regards > ffv1.c| 10 +++ > ffv1.h|1 > ffv1dec.c | 54 +- > ffv1enc.c | 87 > ++ > 4 files changed, 124 insertions(+), 28 deletions(-) > 56a6b95f90706b65b833f1a359c08f927fdc1124 > 0001-Add-simple-P-frame-support-for-ffv1.patch > From 5fcc87093ce1f2aea3a43b52399b09fdf8acda36 Mon Sep 17 00:00:00 2001 > From: Yingming Fan > Date: Thu, 23 Apr 2015 23:19:05 +0800 > Subject: [PATCH] Add simple P frame support for ffv1. breaks ffv1 with normal intra frames: ./ffmpeg -i matrixbench_mpeg2.mpg -vf format=gbrp10 -vcodec ffv1 -t 1 test.avi just segfaults ./ffmpeg -i matrixbench_mpeg2.mpg -vcodec ffv1 -level 3 -t 1 test-3.nut ./ffmpeg -i matrixbench_mpeg2.mpg -vcodec ffv1 -level 4 -t 1 test-4.nut -rw-r- 1 michael michael 2325508 Apr 23 18:24 test-3.nut -rw-r- 1 michael michael 3394282 Apr 23 18:24 test-4.nut the file with P frames is 50% bigger, thats not a good start, considering the goal is to improve compression of the currently existing FFV1 [...] -- 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] [GSoC] Patch which add simple P frame support for ffv1
I will continue working on this. Firstly, i will fix crash and make sure everything OK without P frame. Then, i will add some optimization that select between intra and inter to decrease bitstream size. Best regards. 2015-04-24 0:36 GMT+08:00 Michael Niedermayer : > On Fri, Apr 24, 2015 at 12:03:38AM +0800, Yingming Fan wrote: > > Hi, everyone. > > > > This is my GSoC qualification task, add simple P frame for ffv1. > > > > P frame will work when you add -level 4. > > > > eg. ffmpeg -pix_fmt yuv420p -s -i xx.yuv -vcodec ffv1 -level 4 > test.nut > > > > Notice: Only support yuv colorspace and 8 bit currently, i will support > > these in later time. > > > > Other option about ffv1 can be find here: > > http://trac.ffmpeg.org/wiki/Encode/FFV1 > > > > About test. > > > > I haven't send FATE result to server as i'm not that familiar with those > > staff. But i will complete this as soon as possible. > > > > Best regards > > > ffv1.c| 10 +++ > > ffv1.h|1 > > ffv1dec.c | 54 +- > > ffv1enc.c | 87 > ++ > > 4 files changed, 124 insertions(+), 28 deletions(-) > > 56a6b95f90706b65b833f1a359c08f927fdc1124 > 0001-Add-simple-P-frame-support-for-ffv1.patch > > From 5fcc87093ce1f2aea3a43b52399b09fdf8acda36 Mon Sep 17 00:00:00 2001 > > From: Yingming Fan > > Date: Thu, 23 Apr 2015 23:19:05 +0800 > > Subject: [PATCH] Add simple P frame support for ffv1. > > breaks ffv1 with normal intra frames: > ./ffmpeg -i matrixbench_mpeg2.mpg -vf format=gbrp10 -vcodec ffv1 -t 1 > test.avi > just segfaults > > ./ffmpeg -i matrixbench_mpeg2.mpg -vcodec ffv1 -level 3 -t 1 test-3.nut > ./ffmpeg -i matrixbench_mpeg2.mpg -vcodec ffv1 -level 4 -t 1 test-4.nut > > -rw-r- 1 michael michael 2325508 Apr 23 18:24 test-3.nut > -rw-r- 1 michael michael 3394282 Apr 23 18:24 test-4.nut > > the file with P frames is 50% bigger, thats not a good start, > considering the goal is to improve compression of the currently > existing FFV1 > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Asymptotically faster algorithms should always be preferred if you have > asymptotical amounts of data > > ___ > 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] Add get_device_list() to AVFoundation input device.
On Thu, Apr 23, 2015 at 9:58 AM, Thilo Borgmann
wrote:
> Am 23.04.15 um 09:35 schrieb Daniel Ly:
> > This makes avdevice_list_input_sources() available for
> > device_name = "avfoundation".
> >
> > I didn't yet retrofit avf_read_header() to use the new function to
> > keep this patch small.
>
> Please post a follow-up patch for that purpose, too. (In that thread)
Ok.
>
> Signed-off-by: Daniel Ly
> > ---
> > libavdevice/avfoundation.m | 85
> ++
> > 1 file changed, 85 insertions(+)
> >
> > diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
> > index 763e675..523dc12 100644
> > --- a/libavdevice/avfoundation.m
> > +++ b/libavdevice/avfoundation.m
> > @@ -34,6 +34,7 @@
> > #include "libavformat/internal.h"
> > #include "libavutil/internal.h"
> > #include "libavutil/parseutils.h"
> > +#include "libavutil/avstring.h"
> > #include "libavutil/time.h"
> > #include "avdevice.h"
> >
> > @@ -1007,6 +1008,89 @@ static int avf_read_packet(AVFormatContext *s,
> AVPacket *pkt)
> > return 0;
> > }
> >
> > +static int avf_add_device_info(
> > +AVDeviceInfoList *list, int index, const char *description, const
> char *model
> > +)
>
> Paranthesis looks awkward.
>
I moved the parenthesis to the end of the previous line.
> > +{
> > +AVDeviceInfo *info = av_mallocz(sizeof(AVDeviceInfo));
> > +if (!info) return AVERROR(ENOMEM);
> > +
>
> > +info->device_name = av_asprintf("[%d] %s; %s", index, description,
> model);
>
> Is this string format kind of standard in FFmpeg? Otherwise I would prefer
> description behind model and no ';' but a ':'.
>
I replaced ; by :.
ffmpeg -f avfoundation -list_devices true -i dummy produces this output:
[AVFoundation input device @ 0x7fec68c01080] AVFoundation video devices:
[AVFoundation input device @ 0x7fec68c01080] [0] Logitech Camera
[AVFoundation input device @ 0x7fec68c01080] [1] Capture screen 0
[AVFoundation input device @ 0x7fec68c01080] [2] Capture screen 1
[AVFoundation input device @ 0x7fec68c01080] AVFoundation audio devices:
[AVFoundation input device @ 0x7fec68c01080] [0] Logitech Camera
[AVFoundation input device @ 0x7fec68c01080] [1] Built-in Input
Now it looks like this:
[AVFoundation input device @ 0x7fdcd9421830] AVFoundation video devices:
[AVFoundation input device @ 0x7fdcd9421830] [0] Logitech Camera: UVC
Camera VendorID_1133 ProductID_2050
[AVFoundation input device @ 0x7fdcd9421830] [1] Capture screen 0: -
[AVFoundation input device @ 0x7fdcd9421830] [2] Capture screen 1: -
[AVFoundation input device @ 0x7fdcd9421830] AVFoundation audio devices:
[AVFoundation input device @ 0x7fdcd9421830] [0] Logitech Camera: UVC
Camera VendorID_1133 ProductID_2050
Doxygen says about the struct AVDeviceInfo that device_name is device name,
format depends on device; and that device_description is human friendly
name.
Therefore I set device_description to "Logitech Camera" and device_name to
= "Logitech Camera: UVC Camera VendorID_1133 ProductID_2050". This is
awkward but I don't know what else to put in.
> +info->device_description = strdup(description);
> > +if (!info->device_name || !info->device_description) {
> > +av_free(info);
> > +return AVERROR(ENOMEM);
> > +}
> > +
>
> > +av_dynarray_add(&list->devices, &list->nb_devices, info);
> > +return list ? list->nb_devices : AVERROR(ENOMEM);
>
> I'm not sure if "list" is null'd in case of an error in av_dynarray_add?
>
Doxygen says: In case of failure, the array is freed, *tab_ptr is set to
NULL and *nb_ptr is set to 0.
> > +}
> > +
> > +
> > +static int avf_get_device_list(
> > +struct AVFormatContext *s, struct AVDeviceInfoList *list
> > +)
>
> See above...
>
Ok.
> > +{
> > +NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> > +uint32_t num_screens= 0;
> > +AVFContext *ctx = (AVFContext*)s->priv_data;
> > +NSArray *devices = [AVCaptureDevice
> devicesWithMediaType:AVMediaTypeVideo];
>
> Please align vertically even if one line gets too long by that.
>
Ok.
> > +
> > +#if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
> > +CGGetActiveDisplayList(0, NULL, &num_screens);
> > +#endif
> > +
> > +int result = 0;
> > +int index;
> > +const char *localizedName, *modelID;
> > +
> > +av_log(ctx, AV_LOG_INFO, "AVFoundation video devices:\n");
> > +for (AVCaptureDevice *device in devices) {
>
> > +index = [devices indexOfObject:device];
> > +localizedName = [[device localizedName] UTF8String];
> > +modelID = [[device modelID] UTF8String];
> > +result = avf_add_device_info(list, index, localizedName,
> modelID);
>
> Vertical alignment.
>
Ok. Also aligned lines 1122-1130.
> > +if (result < 0) goto fail;
> > +av_log(ctx, AV_LOG_INFO, "%s\n", list->devices[result -
> 1]->device_name);
>
> Segfault if result == 0?
>
Does not matter. I switched to @autoreleasepool {} and re
Re: [FFmpeg-devel] [GSoC] Patch which adds support for gamma correct scaling
On Tue, Apr 21, 2015 at 05:25:37PM -0300, Pedro Arthur wrote: > New patch with changes. > > 2015-04-21 13:14 GMT-03:00 Pedro Arthur : > > > I intended to fetch the correct gamma value from the video/image metada > > or pass it by flag (like gamma=x) but yet I don't know how to get the > > correct gamma based on the input, thus for now it is hardcode. > > > > 2015-04-21 12:31 GMT-03:00 Kevin Wheatley : > > > > Pedro > >> > >> I understand the desire to 'degamma' images prior to scaling, I'd be > >> interested in understanding how this could work with the colour_trc > >> options rather than only assuming a simple gamma. > >> > >> Kevin > >> ___ > >> ffmpeg-devel mailing list > >> ffmpeg-devel@ffmpeg.org > >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > > > > > options.c |3 ++ > swscale.c | 51 +++ > swscale.h |1 > swscale_internal.h |9 +- > utils.c| 76 > + > 5 files changed, 139 insertions(+), 1 deletion(-) > 2d3c2ec7671d700454621fedf30f2ddc40d8a33c > 0001-Add-gamma-encodign-decoding-before-after-scaling-in-.patch > From aff2c1c0f73e867f2aed90aa01cf3e0a1ba95261 Mon Sep 17 00:00:00 2001 > From: Pedro Arthur > Date: Fri, 17 Apr 2015 17:08:42 -0300 > Subject: [PATCH] Add gamma encodign/decoding before/after scaling in > libswscale > > --- > libswscale/options.c | 3 ++ > libswscale/swscale.c | 51 + > libswscale/swscale.h | 1 + > libswscale/swscale_internal.h | 9 - > libswscale/utils.c| 76 > +++ > 5 files changed, 139 insertions(+), 1 deletion(-) applied (as time is a bit short before the deadline and the patch is basically fine, remaining are just nitpicks) replaced SWS_GAMMA_CORRECT by a internal varible Feel free to submit any follow up improvments on top of this Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus 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] vp9: set timestamps for show_existing_frame return images.
On Wed, Apr 22, 2015 at 12:24:40PM -0400, Ronald S. Bultje wrote: > --- > libavcodec/vp9.c | 2 ++ > 1 file changed, 2 insertions(+) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. 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] tests/tiny_psnr: do not ignore errors from run_psnr
On 23.04.2015 15:44, Michael Niedermayer wrote: > On Wed, Apr 22, 2015 at 09:10:51PM -0700, Timothy Gu wrote: >> On Thu, Apr 23, 2015 at 04:43:09AM +0200, Michael Niedermayer wrote: >>> failure to calculate psnr should not result in tiny_psnr returning success >>> >>> Signed-off-by: Michael Niedermayer >>> --- >>> tests/tiny_psnr.c |9 ++--- >>> 1 file changed, 6 insertions(+), 3 deletions(-) >> >> Patchset LGTM. Would be cool if you can add a link to a broken FATE results >> page in the second patch commit message though. > > i can add a link if someone has one, i seem not lucky in finding one > quickly ATM Does this fix the "awk: line 1: syntax error" messages? Those can be seen among the test failures on sparc64 [1]. Best regards, Andreas 1: http://buildd.debian-ports.org/status/fetch.php?pkg=ffmpeg&arch=sparc64&ver=7%3A2.6.2-1&stamp=1428928967 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] alac: validate k before using show_bits in decode_scalar
On 23.04.2015 16:37, Michael Niedermayer wrote:
> On Wed, Apr 22, 2015 at 06:24:54PM +0200, Andreas Cadhalpun wrote:
>> The k != 1 case calls show_bits(gb, k), which doesn't make sense if k
>> is 0.
>
> i dont think k = 0 is allowed
> i suggest you check rice_limit when it is set, i assume that is the
> source of k=0
> asking for a sample with rice_limit=0 if it occurs is also a good idea
OK, new patch attached.
Best regards,
Andreas
>From d539a0e3abdffe415553c8e39e22268b01c13187 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Thu, 23 Apr 2015 20:51:03 +0200
Subject: [PATCH] alac: reject rice_limit 0
If rice_limit is 0, k can be 0 in decode_scalar, which calls show_bits(gb, k).
Signed-off-by: Andreas Cadhalpun
---
libavcodec/alac.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/alac.c b/libavcodec/alac.c
index ffd2d77..16d56a7 100644
--- a/libavcodec/alac.c
+++ b/libavcodec/alac.c
@@ -569,6 +569,10 @@ static int alac_set_info(ALACContext *alac)
alac->rice_history_mult= bytestream2_get_byteu(&gb);
alac->rice_initial_history = bytestream2_get_byteu(&gb);
alac->rice_limit = bytestream2_get_byteu(&gb);
+if (!alac->rice_limit) {
+avpriv_request_sample(alac->avctx, "Rice limit 0");
+return AVERROR(ENOSYS);
+}
alac->channels = bytestream2_get_byteu(&gb);
bytestream2_get_be16u(&gb); // maxRun
bytestream2_get_be32u(&gb); // max coded frame size
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/exr.c : exr lossy compression B44 added
On Thu, Apr 23, 2015 at 09:29:31PM +0530, greeshma wrote:
> for patch PFA
>
> Greeshma
> exr.c | 114
> ++
> 1 file changed, 114 insertions(+)
> 57f8f5e474a82ddfce30f7356cb83fed4186d137
> 0001-exr-lossy-compression-B44-added.patch
> From c10e182e56310cfc5ebd6c6f8801128668042a2a Mon Sep 17 00:00:00 2001
> From: greeshmab
> Date: Mon, 20 Apr 2015 23:33:55 +0530
> Subject: [PATCH] exr lossy compression B44 added
FFmpeg_Logo_B44_HalfRGBA.exr does not decode correctly
>
> ---
> libavcodec/exr.c | 114
> +++
> 1 file changed, 114 insertions(+)
>
> diff --git a/libavcodec/exr.c b/libavcodec/exr.c
> index f9525ec..92ecc9b 100644
> --- a/libavcodec/exr.c
> +++ b/libavcodec/exr.c
> @@ -770,6 +770,115 @@ static int piz_uncompress(EXRContext *s, const uint8_t
> *src, int ssize,
> return 0;
> }
>
> +static void B44_unpack14 ( GetByteContext *gb, uint16_t out[16]){
> +uint16_t shift;
> +const uint8_t *r = gb->buffer;
theers no need to pass a GetByteContext if only a uint8_t * is used
> +av_assert0(r[2] != 0xfc);
> +out[0] = (r[0] << 8) | r[1];
> +shift = (r[2] >> 2);
> +out[ 1] = out[ 0] + ((r[ 5] >> 2) << shift);
> +out[ 2] = out[ 1] + ((r[ 8] >> 2) << shift);
> +out[ 3] = out[ 2] + ((r[11] >> 2) << shift);
> +out[ 4] = out[ 0] + (((r[ 2] << 4) | (r[ 3] >> 4)) << shift);
> +out[ 5] = out[ 4] + (((r[ 5] << 4) | (r[ 6] >> 4)) << shift);
> +out[ 6] = out[ 5] + (((r[ 8] << 4) | (r[ 9] >> 4)) << shift);
> +out[ 7] = out[ 6] + (((r[11] << 4) | (r[12] >> 4)) << shift);
> +out[ 8] = out[ 4] + (((r[ 3] << 2) | (r[ 4] >> 6)) << shift);
> +out[ 9] = out[ 8] + (((r[ 6] << 2) | (r[ 7] >> 6)) << shift);
> +out[10] = out[ 9] + (((r[ 9] << 2) | (r[10] >> 6)) << shift);
> +out[11] = out[10] + (((r[12] << 2) | (r[13] >> 6)) << shift);
> +out[12] = out[ 8] + (r[ 4] << shift);
> +out[13] = out[12] + (r[ 7] << shift);
> +out[14] = out[13] + (r[10] << shift);
> +out[15] = out[14] + (r[13] << shift);
> +for (int i = 0; i < 16; ++i) { //if any out value exceeds
> 16bits
> +if (out[i] & 0x8000)
> +out[i] &= 0x7fff;
> +else
> +out[i] = ~out[i];
> +}
> +}
> +
> +static void B44_unpack3 ( GetByteContext *gb, uint16_t out[16]){
> +const uint8_t *r = gb->buffer;
> //pixels have the same value
> +av_assert0(r[2] == 0xfc);
> +out[0] = (r[0] << 8) | r[1];
> +if (out[0] & 0x8000)
> +out[0] &= 0x7fff;
> +else
> +out[0] = ~out[0];
> +for (int i = 1; i < 16; ++i)
> +out[i] = out[0];
> +}
> +
> +static int b44_uncompress(EXRContext *s, const uint8_t *src,int ssize, int
> dsize, EXRThreadData *td){
> +GetByteContext gb;
> +unsigned long dest_len = dsize;
> +uint8_t *out;
> +int i, j;
> +uint16_t *tmp = (uint16_t *)td->tmp;
> +out = td->uncompressed_data;
> +bytestream2_init(&gb, src, ssize);
> +if (uncompress(td->tmp, &dest_len, src, ssize) != Z_OK || dest_len !=
> dsize)
> +return AVERROR_INVALIDDATA;
this initialized both a bytereader as well as decomressing from
the same source
later the output from uncompress is overwritten without being used
> +for (i = 0; i < s->nb_channels; i++) {
> +EXRChannel *channel = &s->channels[i];
> +int size = channel->pixel_type;
> +int inSize = ssize;
> +if (channel->pixel_type != EXR_HALF) { // UINT or FLOAT
> channel.
> +int n = s->xdelta * s->ydelta * size * sizeof (*tmp);
> +memcpy (tmp, gb.buffer, n);
> +gb.buffer += n;
> +inSize -= n;
> +continue;
> +} else {//EXR_HALF
> Channel
> +for (int y=0; y < s->ydelta; y +=4 ) {
> +uint16_t *row0 = tmp + y * s->xdelta;
> +uint16_t *row1 = row0 + s->xdelta;
> +uint16_t *row2 = row1 + s->xdelta;
> +uint16_t *row3 = row2 + s->xdelta;
> +for (int x = 0; x < s->xdelta; x += 4) {
> +uint16_t out[16];
> +int num = (x + 3 < s->xdelta)? 4 * sizeof (*out) :
> (s->xdelta - x) * sizeof (*out);
> +if (gb.buffer[2] == 0xfc) {
> +B44_unpack3 (&gb, out);
> +gb.buffer += 3;
> +inSize -= 3;
> +} else {
> +B44_unpack14 (&gb, out);
> +gb.buffer += 14;
> +inSize -= 14;
> +}
> +if (y + 3 < s->ydelta) {
> +memcpy (row0, &out[ 0], num);
> +memcpy (row1, &out[ 4], num);
> +memcpy (row2, &out[ 8], num
Re: [FFmpeg-devel] [libav-devel] [PATCH] alac: validate k before using show_bits in decode_scalar
On 23.04.2015 22:06, Luca Barbato wrote: > On 23/04/15 20:53, Andreas Cadhalpun wrote: >> On 23.04.2015 16:37, Michael Niedermayer wrote: >>> On Wed, Apr 22, 2015 at 06:24:54PM +0200, Andreas Cadhalpun wrote: The k != 1 case calls show_bits(gb, k), which doesn't make sense if k is 0. >>> >>> i dont think k = 0 is allowed >>> i suggest you check rice_limit when it is set, i assume that is the >>> source of k=0 >>> asking for a sample with rice_limit=0 if it occurs is also a good idea >> >> OK, new patch attached. > > alac->rice_initial_history needs the same validation I guess. I don't think so: alac->rice_initial_history = bytestream2_get_byteu(&gb); ... unsigned int history = alac->rice_initial_history; ... k = av_log2((history >> 9) + 3); k = FFMIN(k, alac->rice_limit); So even if rice_initial_history is 0, k is not: k = av_log2(3) = 1 Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] alac: validate k before using show_bits in decode_scalar
On Thu, Apr 23, 2015 at 08:53:29PM +0200, Andreas Cadhalpun wrote:
> On 23.04.2015 16:37, Michael Niedermayer wrote:
> > On Wed, Apr 22, 2015 at 06:24:54PM +0200, Andreas Cadhalpun wrote:
> >> The k != 1 case calls show_bits(gb, k), which doesn't make sense if k
> >> is 0.
> >
> > i dont think k = 0 is allowed
> > i suggest you check rice_limit when it is set, i assume that is the
> > source of k=0
> > asking for a sample with rice_limit=0 if it occurs is also a good idea
>
> OK, new patch attached.
>
> Best regards,
> Andreas
>
> alac.c |4
> 1 file changed, 4 insertions(+)
> d364bcf9db9c6dab0584a27026fe36354c5b7c05 0001-alac-reject-rice_limit-0.patch
> From d539a0e3abdffe415553c8e39e22268b01c13187 Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun
> Date: Thu, 23 Apr 2015 20:51:03 +0200
> Subject: [PATCH] alac: reject rice_limit 0
>
> If rice_limit is 0, k can be 0 in decode_scalar, which calls show_bits(gb, k).
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/alac.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/alac.c b/libavcodec/alac.c
> index ffd2d77..16d56a7 100644
> --- a/libavcodec/alac.c
> +++ b/libavcodec/alac.c
> @@ -569,6 +569,10 @@ static int alac_set_info(ALACContext *alac)
> alac->rice_history_mult= bytestream2_get_byteu(&gb);
> alac->rice_initial_history = bytestream2_get_byteu(&gb);
> alac->rice_limit = bytestream2_get_byteu(&gb);
> +if (!alac->rice_limit) {
> +avpriv_request_sample(alac->avctx, "Rice limit 0");
> +return AVERROR(ENOSYS);
> +}
this doesnt work as our encoder uses a rice_limit of 0 when
compression is disabled
moving the check into if(is_compressed) should work hopefully
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec[/format]/webpenc: use WebPAnimEncoder API to generate animated WebP
On Thu, Apr 16, 2015 at 10:40:14PM +, Urvang Joshi wrote:
> On Thu, Apr 16, 2015 at 3:09 PM James Almer wrote:
>
> > On 16/04/15 4:18 PM, Urvang Joshi wrote:
> > > Hi,
> > > Here's the patch without whitespace changes.
> > >
> > > Thanks,
> > > Urvang
> >
> > This patch doesn't apply cleanly. Looks like something weird with the
> > indentation still.
> > Was this patch handmade? It says the hash for libwebpenc.c is 95d56ac
> > (same as git head),
> > but the contents of the patch don't match.
> >
>
> Sorry, I should have mentioned that it was created with
> "--ignore-all-space" option, so using the same option when applying the
> patch would have worked.
>
> But to avoid any confusion, here's the re-created patch, that should apply
> cleanly with just 'git am'.
>
>
> >
> > After fixing the conflicts and compiling the patch seems to work, but the
> > resulting
> > animated webp files are smaller than those using the native muxer using
> > the default
> > encoding and muxing settings.
> > Is this because the muxing done by libwebpmux is different, or are the
> > quality defaults
> > changed in any way when using this codepath? If the former then that's
> > pretty good, but
> > if the latter then it should probably be fixed.
> >
>
> Short answer: muxing done by libwebpmux is different, so it's expected that
> it generates smaller WebP files.
>
> Detailed answer:
> The native muxer is naive, and it always uses X offset and Y offset of 0
> for all frames. This means the full width x height of all frames are
> encoded.
> libwebpmux muxer is smart on the other hand: for example, it only encodes
> the part of the frame which has changed from previous frame.
> This and other optimizations result in smaller WebP files.
can you show some PSNR vs filesize information ?
>
> Thanks,
> Urvang
>
>
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> configure |5 ++
> libavcodec/libwebpenc.c | 93
> +++-
> libavformat/webpenc.c | 44 ++
why are there changes to libavformat in a patch changing an encoder?
[...]
> index ee110de..0162eff 100644
> --- a/libavformat/webpenc.c
> +++ b/libavformat/webpenc.c
> @@ -22,12 +22,25 @@
> #include "libavutil/intreadwrite.h"
> #include "libavutil/opt.h"
> #include "avformat.h"
> +#include "config.h"
> #include "internal.h"
>
> +#if CONFIG_LIBWEBP
> +#include
> +#if HAVE_WEBP_MUX_H
> +#include
> +#if (WEBP_MUX_ABI_VERSION >= 0x0105)
> +#define USE_WEBP_ANIMENCODER
> +#endif
> +#endif
> +#endif
> +
> typedef struct WebpContext{
> AVClass *class;
> int frame_count;
> +#ifndef USE_WEBP_ANIMENCODER
> AVPacket last_pkt;
> +#endif
> int loop;
> } WebpContext;
>
> @@ -44,13 +57,40 @@ static int webp_write_header(AVFormatContext *s)
> av_log(s, AV_LOG_ERROR, "Only WebP is supported\n");
> return AVERROR(EINVAL);
> }
> -avpriv_set_pts_info(st, 24, 1, 1000);
>
> +#ifndef USE_WEBP_ANIMENCODER
> +avpriv_set_pts_info(st, 24, 1, 1000);
> avio_write(s->pb, "RIFF\0\0\0\0WEBP", 12);
> +#endif
> +
> +return 0;
> +}
this removes the timebase setting, that looks wrong
also please make sure -vcodec copy does if it works before the
patch, still work afterwards
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [FFMpeg-Devel][GSoC][PATCH 2/2] postproc: Added support for sse2/avx2 versions of the do_a_deblock function
The sse2/avx2 deblock functions now actually get called,
I added a new file with the sse2/avx2 code for do_a_deblock.
I also moved the code for running vertical deblock filters into it's own
function, both to clean up the postprocess funciton and to make it
easier to integrate the new sse2/avx2 versions of these filters.
---
libpostproc/postprocess_template.c | 88 ---
libpostproc/x86/Makefile | 1 +
libpostproc/x86/deblock.asm| 454 +
3 files changed, 507 insertions(+), 36 deletions(-)
create mode 100644 libpostproc/x86/deblock.asm
diff --git a/libpostproc/postprocess_template.c
b/libpostproc/postprocess_template.c
index 3bcfb42..c201d62 100644
--- a/libpostproc/postprocess_template.c
+++ b/libpostproc/postprocess_template.c
@@ -129,6 +129,7 @@ extern void RENAME(ff_deInterlaceFF)(uint8_t *, int,
uint8_t *);
extern void RENAME(ff_deInterlaceL5)(uint8_t *, int, uint8_t *, uint8_t*);
extern void RENAME(ff_deInterlaceBlendLinear)(uint8_t *, int, uint8_t *);
extern void RENAME(ff_deInterlaceMedian)(uint8_t *, int);
+extern void RENAME(ff_do_a_deblock)(uint8_t *, int, int, PPContext*, int);
extern void RENAME(ff_blockCopy)(uint8_t*,int,const uint8_t*,
int,int,int64_t*);
extern void RENAME(ff_duplicate)(uint8_t*, int);
@@ -161,6 +162,11 @@ static inline void RENAME(deInterlaceMedian)(uint8_t
src[], int stride)
{
RENAME(ff_deInterlaceMedian)(src, stride);
}
+static inline void RENAME(do_a_deblock)(uint8_t *src, int stride, int step,
+PPContext *c, int mode)
+{
+RENAME(ff_do_a_deblock)(src, stride, step, c, mode);
+}
#else
//FIXME? |255-0| = 1 (should not be a problem ...)
#if TEMPLATE_PP_MMX
@@ -3365,6 +3371,49 @@ static inline void RENAME(prefetcht2)(const void *p)
return;
}
#endif
+
+//pass PPContext by value since this should get inlined into postprocess
+//which has a copy of PPContext on the stack for fast access
+static inline void RENAME(deblock)(uint8_t *dstBlock, int stride,
+ int step, PPContext c, int mode,
+ int num_blocks)
+{
+int block_index = 0;
+while(block_index < num_blocks){
+c.QP = c.QP_block[block_index];
+c.nonBQP = c.nonBQP_block[block_index];
+c.pQPb = c.pQPb_block[block_index];
+c.pQPb2 = c.pQPb2_block[block_index];
+if(mode & V_A_DEBLOCK){
+//usually processes 4 blocks, unless there are less than 4 left
+#if TEMPLATE_PP_AVX2
+if(num_blocks == 4){
+RENAME(do_a_deblock)(dstBlock, stride, step, &c, mode);
+block_index += 4;
+continue;
+}
+#endif
+#if TEMPLATE_PP_SSE2
+if(block_index-num_blocks >= 2){
+do_a_deblock_sse2(dstBlock + block_index*8, stride, 0, &c,
mode);
+block_index += 2;
+continue;
+}
+#endif
+RENAME_SCALAR(do_a_deblock)(dstBlock + block_index*8, stride, 0,
&c, mode);
+} else if(mode & V_X1_FILTER){
+RENAME_SCALAR(vertX1Filter)(dstBlock + block_index*8, stride,
&c);
+} else if(mode & V_DEBLOCK){
+const int t = RENAME_SCALAR(vertClassify)(dstBlock +
block_index*8, stride, &c);
+if(t == 1){
+RENAME_SCALAR(doVertLowPass)(dstBlock + block_index*8, stride,
&c);
+} else if(t == 2){
+RENAME_SCALAR(doVertDefFilter)(dstBlock + block_index*8,
stride, &c);
+}
+}
+block_index++;
+}
+}
/*
This calls a rather trivial assembly function, there is some performance
overhead to the function call vs using inline asm, but (at least I think)
@@ -3650,10 +3699,8 @@ static void RENAME(postProcess)(const uint8_t src[], int
srcStride, uint8_t dst[
int endx = FFMIN(width, x+32);
int num_blocks = (endx-startx)/8;
int block_index;
-uint8_t *dstBlockStart = dstBlock;
-const uint8_t *srcBlockStart = srcBlock;
int qp_index = 0;
-for(qp_index=0; qp_index < (endx-startx)/BLOCK_SIZE; qp_index++){
+for(qp_index=0; qp_index < num_blocks; qp_index++){
QP = QPptr[(x+qp_index*BLOCK_SIZE)>>qpHShift];
nonBQP = nonBQPptr[(x+qp_index*BLOCK_SIZE)>>qpHShift];
if(!isColor){
@@ -3678,40 +3725,9 @@ static void RENAME(postProcess)(const uint8_t src[], int
srcStride, uint8_t dst[
}
RENAME(deInterlace)(dstBlock, dstStride, c.deintTemp +x,
c.deintTemp + width + x, mode, num_blocks);
-
-
- for(x = startx, qp_index = 0; x < endx; x+=BLOCK_SIZE, qp_index++){
-const int stride= dstStride;
-//temporary while changing QP stuff to make things continue to work
-//eventually QP,nonBQP,etc will be arrays
[FFmpeg-devel] [FFMpeg-Devel][GSoC][PATCH 1/2] postproc: Updated postprocess_template to use new sse/avx deinterlace functions
I've revised the code and now the linear_interpolate and median deinterlace
filters
give the exact same results for both C and sse2/avx2. I'm almost certain the
reason
the other deinterlace filters don't give the exact same result is due to the use
of tempory memory to hold some lines, I'm not exactly sure what to do about this
however.
Unfortunately this patch causes the C/MMX versions to produce different
results than before. I'm not exactly sure why this is, I changed the code
to work 4 blocks at a time, which I'm guessing is the issue, but I don't
know why that would be. If anyone has any idea why this is happening and
how to fix it it would be appreciated.
This commit adds several new files containing yasm assembly code, they are:
PPContext.asm; Defines the PPContext struct using the yasm struc command
PPUtil.asm; Various utility macros used in the other asm code
block_copy.asm; Implements the block copy function, the sse2 and avx2
versions copy multiple blocks at once.
deinterlace.asm; Contains implemenations of the postprocessing filters
with support for sse2 and avx2.
Adding these new functions to postprocess_template entailed adding a new
templates for AVX2 and modifying the current SSE2 template to use the
sse2 functions. A new deinterlace function was added to move the logic
of which deinterlace function to use out of the postprocess function and
make adding the new functions eaiser. The inline code for packing QP
into pQPb was moved into a seperate asm file and uptaded for sse2/avx2.
---
libpostproc/postprocess.c | 16 +-
libpostproc/postprocess_internal.h | 11 +-
libpostproc/postprocess_template.c | 275 +++-
libpostproc/x86/Makefile | 2 +
libpostproc/x86/PPContext.asm | 77
libpostproc/x86/PPUtil.asm | 224 +++
libpostproc/x86/block_copy.asm | 132 ++
libpostproc/x86/deinterlace.asm| 359 +
8 files changed, 1011 insertions(+), 85 deletions(-)
create mode 100644 libpostproc/x86/Makefile
create mode 100644 libpostproc/x86/PPContext.asm
create mode 100644 libpostproc/x86/PPUtil.asm
create mode 100644 libpostproc/x86/block_copy.asm
create mode 100644 libpostproc/x86/deinterlace.asm
diff --git a/libpostproc/postprocess.c b/libpostproc/postprocess.c
index af70bb3..20df267 100644
--- a/libpostproc/postprocess.c
+++ b/libpostproc/postprocess.c
@@ -542,8 +542,13 @@ static av_always_inline void do_a_deblock_C(uint8_t *src,
int step,
#include "postprocess_template.c"
#define TEMPLATE_PP_SSE2 1
#include "postprocess_template.c"
+#define TEMPLATE_PP_AVX2 1
+#include "postprocess_template.c"
#else
-#if HAVE_SSE2_INLINE
+#if HAVE_AVX2_INLINE
+#define TEMPLATE_PP_AVX2 1
+#include "postprocess_template.c"
+#elif HAVE_SSE2_INLINE
#define TEMPLATE_PP_SSE2 1
#include "postprocess_template.c"
#elif HAVE_MMXEXT_INLINE
@@ -574,7 +579,8 @@ static inline void postProcess(const uint8_t src[], int
srcStride, uint8_t dst[]
#if CONFIG_RUNTIME_CPUDETECT
#if ARCH_X86 && HAVE_INLINE_ASM
// ordered per speed fastest first
-if (c->cpuCaps & AV_CPU_FLAG_SSE2) pp = postProcess_SSE2;
+if (c->cpuCaps & AV_CPU_FLAG_AVX2) pp = postProcess_avx2;
+else if (c->cpuCaps & AV_CPU_FLAG_SSE2) pp = postProcess_sse2;
else if (c->cpuCaps & AV_CPU_FLAG_MMXEXT) pp = postProcess_MMX2;
else if (c->cpuCaps & AV_CPU_FLAG_3DNOW)pp = postProcess_3DNow;
else if (c->cpuCaps & AV_CPU_FLAG_MMX) pp = postProcess_MMX;
@@ -582,8 +588,10 @@ static inline void postProcess(const uint8_t src[], int
srcStride, uint8_t dst[]
if (c->cpuCaps & AV_CPU_FLAG_ALTIVEC) pp = postProcess_altivec;
#endif
#else /* CONFIG_RUNTIME_CPUDETECT */
-#if HAVE_SSE2_INLINE
-pp = postProcess_SSE2;
+#if HAVE_AVX2_INLINE
+pp = postProcess_avx2;
+#elif HAVE_SSE2_INLINE
+pp = postProcess_sse2;
#elif HAVE_MMXEXT_INLINE
pp = postProcess_MMX2;
#elif HAVE_AMD3DNOW_INLINE
diff --git a/libpostproc/postprocess_internal.h
b/libpostproc/postprocess_internal.h
index c1a306d..022f87e 100644
--- a/libpostproc/postprocess_internal.h
+++ b/libpostproc/postprocess_internal.h
@@ -180,5 +180,14 @@ static inline void linecpy(void *dest, const void *src,
int lines, int stride) {
memcpy((uint8_t*)dest+(lines-1)*stride, (const
uint8_t*)src+(lines-1)*stride, -lines*stride);
}
}
-
+extern void ff_deInterlaceInterpolateLinear_mmx2(uint8_t *, int);
+extern void ff_deInterlaceInterpolateCubic_mmx2(uint8_t *, int);
+extern void ff_deInterlaceFF_mmx2(uint8_t *, int, uint8_t *);
+extern void ff_deInterlaceL5_mmx2(uint8_t *, int,
+ uint8_t *,u
[FFmpeg-devel] Commit messages (was: [PATCH]Allow easy png streamcopying)
Le quartidi 4 floréal, an CCXXIII, Carl Eugen Hoyos a écrit : > I believe it is much more important to explain why. Sorry to insist on that, but that is something that is bothering me and this is as good an occasion as any. I find that our side of the fork in general (I do not want to point any name specifically) does not pay as much attention to the commit messages as we should. OTOH, I realize that mail has grown much too long. I post it anyway because I believe it has some interesting points. To build on your message: "more important to explain why": I believe there are roughly four sides to a commit message: What: what part of the code was changed and what the change does. Why: why is the new version better than the original. How: how did we achieve the intended result. When (for lack of a better adverb): at what occasion did you notice that the change was needed. In this particular instance, that would be: What: the APNG muxer to make it accept plain PNG. Why: because it works and is convenient. Actually, in this case, the why is not convincing, because, as it happens, dropping the extension is a better idea. But in other case, "Why" would involve explaining why a pointer can be NULL. And sometimes, it is obvious, if what is "fix unchecked malloc" for example. How: by making a special case for AV_CODEC_ID_PNG. Once again, it is frequently obvious by reading the code. When: when trying to stream-copy PNG, because ffmpeg.c automatically chooses the APNG muxer rather than the PNG muxer. In other cases, it may be a trac ticket number. Note that in my formulation, you did not explain Why, you explained When. Now, there are two places these information must be stated: in the Git commit message and in the preamble of the mail to the mailing-list. With git send-email, these are more or less the same; you can add some more info to the mail. Note: since the commit message is important, it should be reviewed as part of the patch. Manual replacements for git send-email that separate the commit metadata from the code diff should be avoided. Personally, I consider that the parts should be, roughly, in the order I have given, with not much preference between How and When. When reading the mail: What should appear in the mail Subject. Compelling reason: a maintainer who has ten minutes and fifty unread mails needs to spot the one that needs reading immediately. Why is a direct follow-up on What. In the commit message: we read the commit messages to look for a commit that introduced a bug, a change of behaviour, etc. We need to know What. Let us take this particular patch as an example and examine what is most convenient in a few situations. A is maintainer of ffmpeg.c, B is maintainer of lavf/apngenc.c. They both read the index of their inbox and see "Allow easy png streamcopying". A says "'streamcopying' is a task done by ffmpeg.c" and reads the mail immediately; B says the same, but adds "PNG is something I know a bit about, I'll read that later". Both were wrong. With "apng" in the subject, B would have read the mail immediately. Without "streamcopying", A would not have wasted immediate time. C is looking for a regression in AAC stream copy, sees "streamcopying" in the commit message, looks at the patch. Wasted time. Here are a few commits that I believe have good commit messages, taken at random: commit e4fe535d12f4f30df2dd672e30304af112a5a827 Author: Vittorio Giovara Date: 2015-03-17 17:38:48 + [What] mov: Write the display matrix in order [Why] This will allow to copy the matrix as is and it is just cleaner to keep the matrix in the same order specified by the mov standard (which is also explicitly described in the documentation). [How] In order to preserve compatibility, flip the angle sign in the display API av_display_rotation_set() and av_display_rotation_get(), and improve the documentation mentioning the rotation direction. commit e8446a685077b071361cc997116c315c68ef8da3 Author: Michael Niedermayer Date: 2015-03-16 15:31:57 +0100 [What] configure: Silence warnings about constant unsigned overflows in MSVC [Why] unsigned overflows are well defined in C and used for example in crypto and various other places. None of the affected warnings currently shown points to an actual defect untested commit 7b05b5093ea67a3397b0c37cf398bab471e1ce2b Author: Andreas Cadhalpun Date: 2015-03-13 22:28:42 +0100 [What] ac3dec_fixed: always use the USE_FIXED=1 variant of the AC3DecodeContext [Why] The AC3DecodeContext has a float (USE_FIXED=0) and an integer (USE_FIXED=1) variant, both of which can be present in the same binary. This is not only very confusing, but it also breaks horribly, when one variant is used by code expecting the other. This currently happens, because eac3dec.c is only compiled for the float variant, but also used from ac3dec_fixed.c, which uses the integer variant. The re
Re: [FFmpeg-devel] [PATCH] avcodec[/format]/webpenc: use WebPAnimEncoder API to generate animated WebP
On Thu, Apr 23, 2015 at 11:51:15PM +0200, Michael Niedermayer wrote: > On Thu, Apr 16, 2015 at 10:40:14PM +, Urvang Joshi wrote: > > On Thu, Apr 16, 2015 at 3:09 PM James Almer wrote: > > > > > On 16/04/15 4:18 PM, Urvang Joshi wrote: > > > > Hi, > > > > Here's the patch without whitespace changes. > > > > > > > > Thanks, > > > > Urvang > > > > > > This patch doesn't apply cleanly. Looks like something weird with the > > > indentation still. > > > Was this patch handmade? It says the hash for libwebpenc.c is 95d56ac > > > (same as git head), > > > but the contents of the patch don't match. > > > > > > > Sorry, I should have mentioned that it was created with > > "--ignore-all-space" option, so using the same option when applying the > > patch would have worked. > > > > But to avoid any confusion, here's the re-created patch, that should apply > > cleanly with just 'git am'. > > > > > > > > > > After fixing the conflicts and compiling the patch seems to work, but the > > > resulting > > > animated webp files are smaller than those using the native muxer using > > > the default > > > encoding and muxing settings. > > > Is this because the muxing done by libwebpmux is different, or are the > > > quality defaults > > > changed in any way when using this codepath? If the former then that's > > > pretty good, but > > > if the latter then it should probably be fixed. > > > > > > > Short answer: muxing done by libwebpmux is different, so it's expected that > > it generates smaller WebP files. > > > > Detailed answer: > > The native muxer is naive, and it always uses X offset and Y offset of 0 > > for all frames. This means the full width x height of all frames are > > encoded. > > > libwebpmux muxer is smart on the other hand: for example, it only encodes > > the part of the frame which has changed from previous frame. > > This and other optimizations result in smaller WebP files. > > can you show some PSNR vs filesize information ? also when doing PSNR vs fiesize comparissions dont forget to try cr_threshold / cr_size / quality to vary the threshold at which changes are ommited with the native encoder [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] alac: validate k before using show_bits in decode_scalar
On 23.04.2015 23:37, Michael Niedermayer wrote:
> On Thu, Apr 23, 2015 at 08:53:29PM +0200, Andreas Cadhalpun wrote:
>> On 23.04.2015 16:37, Michael Niedermayer wrote:
>>> On Wed, Apr 22, 2015 at 06:24:54PM +0200, Andreas Cadhalpun wrote:
>> libavcodec/alac.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/libavcodec/alac.c b/libavcodec/alac.c
>> index ffd2d77..16d56a7 100644
>> --- a/libavcodec/alac.c
>> +++ b/libavcodec/alac.c
>> @@ -569,6 +569,10 @@ static int alac_set_info(ALACContext *alac)
>> alac->rice_history_mult= bytestream2_get_byteu(&gb);
>> alac->rice_initial_history = bytestream2_get_byteu(&gb);
>> alac->rice_limit = bytestream2_get_byteu(&gb);
>> +if (!alac->rice_limit) {
>> +avpriv_request_sample(alac->avctx, "Rice limit 0");
>> +return AVERROR(ENOSYS);
>> +}
>
> this doesnt work as our encoder uses a rice_limit of 0 when
> compression is disabled
I see.
> moving the check into if(is_compressed) should work hopefully
Done.
Best regards,
Andreas
>From 709c9f553387989633e4cb7416851c538884fdb0 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Fri, 24 Apr 2015 00:01:43 +0200
Subject: [PATCH] alac: reject rice_limit 0 if compression is used
If rice_limit is 0, k can be 0 in decode_scalar, which calls show_bits(gb, k).
Signed-off-by: Andreas Cadhalpun
---
libavcodec/alac.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/alac.c b/libavcodec/alac.c
index ffd2d77..ada7c73 100644
--- a/libavcodec/alac.c
+++ b/libavcodec/alac.c
@@ -316,6 +316,11 @@ static int decode_element(AVCodecContext *avctx, AVFrame *frame, int ch_index,
int lpc_quant[2];
int rice_history_mult[2];
+if (!alac->rice_limit) {
+avpriv_request_sample(alac->avctx, "Compression with rice limit 0");
+return AVERROR(ENOSYS);
+}
+
decorr_shift = get_bits(&alac->gb, 8);
decorr_left_weight = get_bits(&alac->gb, 8);
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFMpeg-Devel][GSoC][PATCH 1/2] postproc: Updated postprocess_template to use new sse/avx deinterlace functions
On Thu, Apr 23, 2015 at 05:54:05PM -0400, Tucker DiNapoli wrote: > I've revised the code and now the linear_interpolate and median deinterlace > filters > give the exact same results for both C and sse2/avx2. I'm almost certain the > reason > the other deinterlace filters don't give the exact same result is due to the > use > of tempory memory to hold some lines, I'm not exactly sure what to do about > this > however. > > Unfortunately this patch causes the C/MMX versions to produce different > results than before. I'm not exactly sure why this is, I changed the code > to work 4 blocks at a time, which I'm guessing is the issue, but I don't > know why that would be. If anyone has any idea why this is happening and > how to fix it it would be appreciated. i really wish i knew and could fix all bugs in this quickly now but i cant :( > > > > This commit adds several new files containing yasm assembly code, they are: > PPContext.asm; Defines the PPContext struct using the yasm struc command > PPUtil.asm; Various utility macros used in the other asm code > block_copy.asm; Implements the block copy function, the sse2 and avx2 > versions copy multiple blocks at once. > deinterlace.asm; Contains implemenations of the postprocessing filters > with support for sse2 and avx2. > > Adding these new functions to postprocess_template entailed adding a new > templates for AVX2 and modifying the current SSE2 template to use the > sse2 functions. A new deinterlace function was added to move the logic > of which deinterlace function to use out of the postprocess function and > make adding the new functions eaiser. The inline code for packing QP > into pQPb was moved into a seperate asm file and uptaded for sse2/avx2. > ./ffplay matrixbench_mpeg2.mpg -vf tinterlace=4,pp=lb shows some remaining interlacing artifacts in some individual blocks thats even happening with -cpuflags 0 after the patch this patch also seems to break the deblocking filters -vf 'pp=fq|50/va/ha' looks vissibly different after it with a low bitrate video [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] alac: validate k before using show_bits in decode_scalar
On Fri, Apr 24, 2015 at 12:15:23AM +0200, Andreas Cadhalpun wrote:
> On 23.04.2015 23:37, Michael Niedermayer wrote:
> > On Thu, Apr 23, 2015 at 08:53:29PM +0200, Andreas Cadhalpun wrote:
> >> On 23.04.2015 16:37, Michael Niedermayer wrote:
> >>> On Wed, Apr 22, 2015 at 06:24:54PM +0200, Andreas Cadhalpun wrote:
> >> libavcodec/alac.c | 4
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/libavcodec/alac.c b/libavcodec/alac.c
> >> index ffd2d77..16d56a7 100644
> >> --- a/libavcodec/alac.c
> >> +++ b/libavcodec/alac.c
> >> @@ -569,6 +569,10 @@ static int alac_set_info(ALACContext *alac)
> >> alac->rice_history_mult= bytestream2_get_byteu(&gb);
> >> alac->rice_initial_history = bytestream2_get_byteu(&gb);
> >> alac->rice_limit = bytestream2_get_byteu(&gb);
> >> +if (!alac->rice_limit) {
> >> +avpriv_request_sample(alac->avctx, "Rice limit 0");
> >> +return AVERROR(ENOSYS);
> >> +}
> >
> > this doesnt work as our encoder uses a rice_limit of 0 when
> > compression is disabled
>
> I see.
>
> > moving the check into if(is_compressed) should work hopefully
>
> Done.
>
> Best regards,
> Andreas
>
> alac.c |5 +
> 1 file changed, 5 insertions(+)
> 607ba39e0c617f9efc2db93b2788f666ffce3620
> 0001-alac-reject-rice_limit-0-if-compression-is-used.patch
> From 709c9f553387989633e4cb7416851c538884fdb0 Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun
> Date: Fri, 24 Apr 2015 00:01:43 +0200
> Subject: [PATCH] alac: reject rice_limit 0 if compression is used
>
> If rice_limit is 0, k can be 0 in decode_scalar, which calls show_bits(gb, k).
>
> Signed-off-by: Andreas Cadhalpun
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
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] tests/tiny_psnr: do not ignore errors from run_psnr
On Thu, Apr 23, 2015 at 08:38:15PM +0200, Andreas Cadhalpun wrote: > On 23.04.2015 15:44, Michael Niedermayer wrote: > > On Wed, Apr 22, 2015 at 09:10:51PM -0700, Timothy Gu wrote: > >> On Thu, Apr 23, 2015 at 04:43:09AM +0200, Michael Niedermayer wrote: > >>> failure to calculate psnr should not result in tiny_psnr returning success > >>> > >>> Signed-off-by: Michael Niedermayer > >>> --- > >>> tests/tiny_psnr.c |9 ++--- > >>> 1 file changed, 6 insertions(+), 3 deletions(-) > >> > >> Patchset LGTM. Would be cool if you can add a link to a broken FATE results > >> page in the second patch commit message though. > > > > i can add a link if someone has one, i seem not lucky in finding one > > quickly ATM > > Does this fix the "awk: line 1: syntax error" messages? > Those can be seen among the test failures on sparc64 [1]. probably but it wont fix the fate failures just the nonsense errors applied Thanks to all [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/wvdec: fix seeking
On Thu, Apr 23, 2015 at 01:33:06PM +0200, wm4 wrote: > While I'm not sure why exactly sure why the old code could end up in the > wrong position, using the generic index code is much simpler and is > known to work correctly. > --- > A sample for testing can be produced with ffmpeg itself. > --- > libavformat/wvdec.c | 38 ++ > 1 file changed, 2 insertions(+), 36 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
