[FFmpeg-devel] [PATCH] lavd/v4l2: fix typo
From 55f35aaea4b1aaf59e3a7620e0ca0e078c8c2010 Mon Sep 17 00:00:00 2001
From: Giorgio Vazzana mywin...@gmail.com
Date: Fri, 8 May 2015 17:42:34 +0200
Subject: [PATCH] lavd/v4l2: fix typo
This was introduced in cde6e328de214ffe8387641cdc1e433a2c2150f3
---
libavdevice/v4l2.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
index 6137cef..76f7c4e 100644
--- a/libavdevice/v4l2.c
+++ b/libavdevice/v4l2.c
@@ -286,7 +286,7 @@ static void list_formats(AVFormatContext *ctx, int type)
} else if (vfd.flags V4L2_FMT_FLAG_COMPRESSED
type V4L_COMPFORMATS) {
const AVCodecDescriptor *desc = avcodec_descriptor_get(codec_id);
-av_log(ctx, AV_LOG_INFO, Compressedll : %9s : %20s :,
+av_log(ctx, AV_LOG_INFO, Compressed: %9s : %20s :,
desc ? desc-name : Unsupported,
vfd.description);
} else {
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavd/v4l2: produce a 0 byte packet when a dequeued buffer is flagged with V4L2_BUF_FLAG_ERROR
Hi,
this patch fixes ticket #4030. Users have tested it and they confirm
it solves the problem.
Giorgio Vazzana
From 5f1b247ee7c47821da301eddad539f8e35652cf5 Mon Sep 17 00:00:00 2001
From: Giorgio Vazzana mywin...@gmail.com
Date: Fri, 8 May 2015 17:25:15 +0200
Subject: [PATCH] lavd/v4l2: produce a 0 byte packet when a dequeued buffer is
flagged with V4L2_BUF_FLAG_ERROR
Fixes ticket #4030.
---
libavdevice/v4l2.c | 37 ++---
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
index b0fa765..6137cef 100644
--- a/libavdevice/v4l2.c
+++ b/libavdevice/v4l2.c
@@ -499,13 +499,14 @@ static int mmap_read_frame(AVFormatContext *ctx, AVPacket *pkt)
};
int res;
+pkt-size = 0;
+
/* FIXME: Some special treatment might be needed in case of loss of signal... */
while ((res = v4l2_ioctl(s-fd, VIDIOC_DQBUF, buf)) 0 (errno == EINTR));
if (res 0) {
-if (errno == EAGAIN) {
-pkt-size = 0;
+if (errno == EAGAIN)
return AVERROR(EAGAIN);
-}
+
res = AVERROR(errno);
av_log(ctx, AV_LOG_ERROR, ioctl(VIDIOC_DQBUF): %s\n,
av_err2str(res));
@@ -520,18 +521,24 @@ static int mmap_read_frame(AVFormatContext *ctx, AVPacket *pkt)
// always keep at least one buffer queued
av_assert0(avpriv_atomic_int_get(s-buffers_queued) = 1);
-/* CPIA is a compressed format and we don't know the exact number of bytes
- * used by a frame, so set it here as the driver announces it.
- */
-if (ctx-video_codec_id == AV_CODEC_ID_CPIA)
-s-frame_size = buf.bytesused;
+if (buf.flags V4L2_BUF_FLAG_ERROR) {
+av_log(ctx, AV_LOG_WARNING,
+ Dequeued v4l2 buffer contains corrupted data (%d bytes).\n,
+ buf.bytesused);
+buf.bytesused = 0;
+} else {
+/* CPIA is a compressed format and we don't know the exact number of bytes
+ * used by a frame, so set it here as the driver announces it. */
+if (ctx-video_codec_id == AV_CODEC_ID_CPIA)
+s-frame_size = buf.bytesused;
-if (s-frame_size 0 buf.bytesused != s-frame_size) {
-av_log(ctx, AV_LOG_ERROR,
- The v4l2 frame is %d bytes, but %d bytes are expected. Flags: 0x%08X\n,
- buf.bytesused, s-frame_size, buf.flags);
-enqueue_buffer(s, buf);
-return AVERROR_INVALIDDATA;
+if (s-frame_size 0 buf.bytesused != s-frame_size) {
+av_log(ctx, AV_LOG_ERROR,
+ Dequeued v4l2 buffer contains %d bytes, but %d were expected. Flags: 0x%08X.\n,
+ buf.bytesused, s-frame_size, buf.flags);
+enqueue_buffer(s, buf);
+return AVERROR_INVALIDDATA;
+}
}
/* Image is at s-buff_start[buf.index] */
@@ -586,7 +593,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
pkt-pts = buf.timestamp.tv_sec * INT64_C(100) + buf.timestamp.tv_usec;
convert_timestamp(ctx, pkt-pts);
-return s-buf_len[buf.index];
+return pkt-size;
}
static int mmap_start(AVFormatContext *ctx)
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/v4l2: produce a 0 byte packet when a dequeued buffer is flagged with V4L2_BUF_FLAG_ERROR
2015-05-09 0:34 GMT+02:00 Michael Niedermayer michae...@gmx.at: On Fri, May 08, 2015 at 07:00:18PM -0300, James Almer wrote: On 08/05/15 6:10 PM, Michael Niedermayer wrote: applied thanks This does not compile on netbsd and openbsd. http://fate.ffmpeg.org/log.cgi?time=20150508171126log=compileslot=x86_64-netbsd-clang-noopt http://fate.ffmpeg.org/log.cgi?time=20150508182740log=compileslot=x86_64-openbsd5.6-gcc4.8 should be fixed Sorry and thank you James and Michael, I only test on Linux so I didn't realize it would break the build for netbsd/openbsd. Giorgio Vazzana ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavd/v4l2: print buffer flags in case of error
Hello,
I wrote this simple patch a while back trying to solve ticket #4030,
but I think we might as well apply it as it would make debugging
easier in general.
Giorgio Vazzana
From 1b471609878a9982960bf25e921c560e595ad667 Mon Sep 17 00:00:00 2001
From: Giorgio Vazzana mywin...@gmail.com
Date: Thu, 16 Oct 2014 11:10:03 +0200
Subject: [PATCH] lavd/v4l2: print buffer flags in case of error
---
libavdevice/v4l2.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
index cf7a92c..d6fc79f 100644
--- a/libavdevice/v4l2.c
+++ b/libavdevice/v4l2.c
@@ -525,8 +525,8 @@ static int mmap_read_frame(AVFormatContext *ctx, AVPacket *pkt)
if (s-frame_size 0 buf.bytesused != s-frame_size) {
av_log(ctx, AV_LOG_ERROR,
- The v4l2 frame is %d bytes, but %d bytes are expected\n,
- buf.bytesused, s-frame_size);
+ The v4l2 frame is %d bytes, but %d bytes are expected. Flags: 0x%08X\n,
+ buf.bytesused, s-frame_size, buf.flags);
enqueue_buffer(s, buf);
return AVERROR_INVALIDDATA;
}
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg: fix option name in documentation
Hi,
$ ffmpeg -h full 2/dev/null | grep thread_queue_size
-thread_queue_size set the maximum number of queued packets from the demuxer
Giorgio Vazzana
From 15e9d7d8d3e23ec7a0649b36f104c755c5a33783 Mon Sep 17 00:00:00 2001
From: Giorgio Vazzana mywin...@gmail.com
Date: Tue, 24 Mar 2015 20:20:45 +0100
Subject: [PATCH] ffmpeg: fix option name in documentation
---
doc/ffmpeg.texi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 1dde682..02952ac 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1158,7 +1158,7 @@ This option enables or disables accurate seeking in input files with the
transcoding. Use @option{-noaccurate_seek} to disable it, which may be useful
e.g. when copying some streams and transcoding the others.
-@item -thread_message_queue @var{size} (@emph{input})
+@item -thread_queue_size @var{size} (@emph{input})
This option sets the maximum number of queued packets when reading from the
file or device. With low latency / high rate live streams, packets may be
discarded if they are not read in a timely manner; raising this value can
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] tools: crypto_bench: Added support for Twofish
Hi,
2015-02-14 11:12 GMT+01:00 Giorgio Vazzana mywin...@gmail.com:
Hi,
2015-02-14 9:33 GMT+01:00 supraja reddy supraja0...@gmail.com:
Hello,
I have added the necessary functions for twofish in crypto_bench.
A note, there is no twofish implementation in openssl library but since the
code demands that all the libraries have the impl, i have introduced a
dummy function.
I know this was initially my suggestion, but looking now at the code I
see that maybe we could use the IMPL() macro instead of the IMPL_ALL()
macro in order to exclude 'crypto'. This should simplify the patch.
I'll give it a look tomorrow hopefully, but of course let's see if
others have comments.
what about something like the following code? You won't need to add a
dummy function or insert a check inside run_implementation():
@@ -398,6 +398,9 @@ struct hash_impl implementations[] = {
IMPL_ALL(AES-128,aes128,crc:ff6bc888)
IMPL_ALL(CAMELLIA, camellia, crc:7abb59a7)
IMPL_ALL(CAST-128, cast128, crc:456aa584)
+IMPL(lavu, TWOFISH, twofish, crc:9edbd5c1)
+IMPL(gcrypt, TWOFISH, twofish, crc:9edbd5c1)
+IMPL(tomcrypt, TWOFISH, twofish, crc:9edbd5c1)
};
Giorgio Vazzana
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] tools: crypto_bench: Added support for Twofish
Hi, 2015-02-14 9:33 GMT+01:00 supraja reddy supraja0...@gmail.com: Hello, I have added the necessary functions for twofish in crypto_bench. A note, there is no twofish implementation in openssl library but since the code demands that all the libraries have the impl, i have introduced a dummy function. I know this was initially my suggestion, but looking now at the code I see that maybe we could use the IMPL() macro instead of the IMPL_ALL() macro in order to exclude 'crypto'. This should simplify the patch. I'll give it a look tomorrow hopefully, but of course let's see if others have comments. Giorgio Vazzana ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavutil: optimize camellia cipher
Hi Supraja, could you also post the result of crypto_bench now to see how fast our implementation is compared to the others? Thanks. Giorgio Vazzana ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavutil: Added twofish block cipher
};
+int i, j, err = 0;
+AVTWOFISH *cs;
+cs = av_twofish_alloc();
+if (!cs)
+return 1;
+for (j = 1; j 3; j++) {
+av_twofish_init(cs, Key, kbits[j]);
+av_twofish_crypt(cs, temp, rpt, 1, NULL, 0);
+for (i = 0; i 16; i++) {
+if (rct[j][i] != temp[i]) {
+av_log(NULL, AV_LOG_ERROR, %d %02x %02x\n, i, rct[j][i],
temp[i]);
+err = 1;
+}
+}
+av_twofish_crypt(cs, temp, rct[j], 1, NULL, 1);
+for (i = 0; i 16; i++) {
+if (rpt[i] != temp[i]) {
+av_log(NULL, AV_LOG_ERROR, %d %02x %02x\n, i, rpt[i],
temp[i]);
+err = 1;
+}
+}
+}
+for (j = 0; j 3; j++) {
+memset(Key, 0, sizeof(Key));
+memset(rpt, 0, sizeof(rpt));
+for (i = 1; i 50; i++) {
+av_twofish_init(cs, Key, kbits[j]);
+av_twofish_crypt(cs, temp, rpt, 1, NULL, 0);
+memcpy(Key+16,Key,(kbits[j]-128) 3);
+memcpy(Key,rpt,16);
+memcpy(rpt,temp,16);
+}
+for (i = 0; i 16; i++) {
+if (rct[3 + j][i] != temp[i]) {
+av_log(NULL, AV_LOG_ERROR, %d %02x %02x\n, i, rct[3 +
j][i], temp[i]);
+err = 1;
+}
+}
+}
+memset(rpt, 0, sizeof(rpt));
+memcpy(iv, HALLO123HALLO123, 16);
+av_twofish_crypt(cs, temp, rpt, 2, iv, 0);
+memcpy(iv, HALLO123HALLO123, 16);
+av_twofish_crypt(cs, temp, temp, 2, iv, 1);
+for (i = 0; i 32; i++) {
+if (rpt[i] != temp[i]) {
+av_log(NULL, AV_LOG_ERROR, %d %02x %02x\n, i, rpt[i], temp[i]);
+err = 1;
+}
+}
+av_free(cs);
+return err;
+}
+#endif
diff --git a/libavutil/twofish.h b/libavutil/twofish.h
new file mode 100644
index 000..a34b8f6
--- /dev/null
+++ b/libavutil/twofish.h
@@ -0,0 +1,70 @@
+/*
+ * An implementation of the TwoFish algorithm
+ * Copyright (c) 2015 Supraja Meedinti
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
+ */
+
+#ifndef AVUTIL_TWOFISH_H
+#define AVUTIL_TWOFISH_H
+
+#include stdint.h
+
+
+/**
+ * @file
+ * @brief Public header for libavutil TWOFISH algorithm
+ * @defgroup lavu_twofish TWOFISH
+ * @ingroup lavu_crypto
+ * @{
+ */
+
+extern const int av_twofish_size;
+
+struct AVTWOFISH;
+
+/**
+ * Allocate an AVTWOFISH context
+ * To free the struct: av_free(ptr)
+ */
+struct AVTWOFISH *av_twofish_alloc(void);
+
+/**
+ * Initialize an AVTWOFISH context.
+ *
+ * @param ctx an AVTWOFISH context
+ * @param key a key of 16, 24, 32 bytes used for encryption/decryption
+ * @param key_bits number of keybits: possible are 128, 192, 256
+ */
+int av_twofish_init(struct AVTWOFISH *ctx, const uint8_t *key, int key_bits);
+
+/**
+ * Encrypt or decrypt a buffer using a previously initialized context
+ *
+ * @param ctx an AVTWOFISH context
+ * @param dst destination array, can be equal to src
+ * @param src source array, can be equal to dst
+ * @param count number of 16 byte blocks
+ * @paran iv initialization vector for CBC mode, NULL for ECB mode
+ * @param decrypt 0 for encryption, 1 for decryption
+ */
+void av_twofish_crypt(struct AVTWOFISH *ctx, uint8_t *dst, const uint8_t
*src, int count, uint8_t* iv, int decrypt);
+
+/**
+ * @}
+ */
+#endif /* AVUTIL_TWOFISH_H */
--
1.8.3.2
Giorgio Vazzana
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavd/v4l2: implement list device callback
2015-01-03 4:45 GMT+01:00 Lukasz Marek lukasz.m.lu...@gmail.com:
On 21 December 2014 at 23:39, Lukasz Marek lukasz.m.lu...@gmail.com wrote:
On 21.12.2014 22:43, Lukasz Marek wrote:
Signed-off-by: Lukasz Marek lukasz.m.lu...@gmail.com
---
libavdevice/v4l2.c | 58 ++
1 file changed, 58 insertions(+)
diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
index 2969980..9d4d7ae 100644
--- a/libavdevice/v4l2.c
+++ b/libavdevice/v4l2.c
@@ -1006,6 +1006,63 @@ static int v4l2_read_close(AVFormatContext *ctx)
return 0;
}
+static int v4l2_get_device_list(AVFormatContext *ctx, AVDeviceInfoList
*device_list)
+{
+struct video_data *s = ctx-priv_data;
+AVDeviceInfo *device = NULL;
+struct v4l2_capability cap;
+int i, ret = 0;
+
+if (!device_list)
+return AVERROR(EINVAL);
+
+for (i = 0; i = 31; i++) {
+snprintf(ctx-filename, sizeof(ctx-filename), /dev/video%d,
i);
I wasn't sure this is correct. I changed this loop to opendir/readdir -
similar way v4l-utils does.
ping on patchset
LGTM, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavutil: added camellia block cipher
Hello,
2015-01-02 15:17 GMT+01:00 Michael Niedermayer michae...@gmx.at:
i assume giorgio is ok with the patch as he previously said rest LGTM
so applied
thank you Supraja for the good work and thanks Michael for applying the patch.
I spotted only minor things, attached some patches from most important
to less important.
maybe you can add a fate test for it
Yes please, a fate test would be nice.
Giorgio Vazzana
From bdd85f3b5727f0e64f4bbae02c9023b379e50f4c Mon Sep 17 00:00:00 2001
From: Giorgio Vazzana mywin...@gmail.com
Date: Fri, 2 Jan 2015 16:33:17 +0100
Subject: [PATCH 1/4] avutil/camellia: fix documentation for
av_camellia_crypt()
Signed-off-by: Giorgio Vazzana mywin...@gmail.com
---
libavutil/camellia.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/camellia.h b/libavutil/camellia.h
index fc3b570..e674c9b 100644
--- a/libavutil/camellia.h
+++ b/libavutil/camellia.h
@@ -58,7 +58,7 @@ int av_camellia_init(struct AVCAMELLIA *ctx, const uint8_t *key, int key_bits);
* @param ctx an AVCAMELLIA context
* @param dst destination array, can be equal to src
* @param src source array, can be equal to dst
- * @param count number of 8 byte blocks
+ * @param count number of 16 byte blocks
* @paran iv initialization vector for CBC mode, NULL for ECB mode
* @param decrypt 0 for encryption, 1 for decryption
*/
--
1.7.9.5
From 826b3d152aa13cf462f6be4605bcc1cefae6a79c Mon Sep 17 00:00:00 2001
From: Giorgio Vazzana mywin...@gmail.com
Date: Fri, 2 Jan 2015 16:49:12 +0100
Subject: [PATCH 2/4] avutil/camellia: make LR128() more robust
Signed-off-by: Giorgio Vazzana mywin...@gmail.com
---
libavutil/camellia.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/camellia.c b/libavutil/camellia.c
index fcbf970..2e719be 100644
--- a/libavutil/camellia.c
+++ b/libavutil/camellia.c
@@ -126,14 +126,14 @@ static const uint8_t SBOX4[256] =
const int av_camellia_size = sizeof(AVCAMELLIA);
-static void LR128(uint64_t* d, uint64_t *K, int x)
+static void LR128(uint64_t d[2], const uint64_t K[2], int x)
{
int i = 0;
if (x =64 x 128) {
i = 1;
x -= 64;
}
-if (!x || x == 128) {
+if (x = 0 || x = 128) {
d[0] = K[i];
d[1] = K[!i];
return;
--
1.7.9.5
From 39f8200e5894f23a3d3ee12c699af251e77d5cff Mon Sep 17 00:00:00 2001
From: Giorgio Vazzana mywin...@gmail.com
Date: Fri, 2 Jan 2015 16:57:09 +0100
Subject: [PATCH 3/4] avutil/camellia: use K[2] instead of *K in
generate_round_keys()
Additionally, change parameters order.
Signed-off-by: Giorgio Vazzana mywin...@gmail.com
---
libavutil/camellia.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/camellia.c b/libavutil/camellia.c
index 2e719be..15b63f3 100644
--- a/libavutil/camellia.c
+++ b/libavutil/camellia.c
@@ -190,7 +190,7 @@ static const uint8_t vars[2][12] = {
{3,1,2,3,0,2,1,3,0,1,2,0}
};
-static void generate_round_keys(AVCAMELLIA* cs, uint64_t *Ka, uint64_t *Kb, uint64_t *Kl, uint64_t *Kr)
+static void generate_round_keys(AVCAMELLIA* cs, uint64_t Kl[2], uint64_t Kr[2], uint64_t Ka[2], uint64_t Kb[2])
{
int i;
uint64_t *Kd[4], d[2];
@@ -374,7 +374,7 @@ av_cold int av_camellia_init(AVCAMELLIA* cs, const uint8_t *key, int key_bits)
Kb[0] = D1;
Kb[1] = D2;
}
-generate_round_keys(cs, Ka, Kb, Kl, Kr);
+generate_round_keys(cs, Kl, Kr, Ka, Kb);
return 0;
}
--
1.7.9.5
From 2ef08a16ff7a5ceadaf83cd3b61908e07fc44d2b Mon Sep 17 00:00:00 2001
From: Giorgio Vazzana mywin...@gmail.com
Date: Fri, 2 Jan 2015 17:05:30 +0100
Subject: [PATCH 4/4] avutil/camellia: cosmetic fixes
Signed-off-by: Giorgio Vazzana mywin...@gmail.com
---
libavutil/camellia.c | 163 +-
1 file changed, 80 insertions(+), 83 deletions(-)
diff --git a/libavutil/camellia.c b/libavutil/camellia.c
index 15b63f3..7382414 100644
--- a/libavutil/camellia.c
+++ b/libavutil/camellia.c
@@ -44,84 +44,80 @@ typedef struct AVCAMELLIA {
int key_bits;
} AVCAMELLIA;
-static const uint8_t SBOX1[256] =
-{
-112, 130, 44, 236, 179, 39, 192, 229, 228, 133, 87, 53, 234, 12, 174, 65,
-35, 239, 107, 147, 69, 25, 165, 33, 237, 14, 79, 78, 29, 101, 146, 189,
-134, 184, 175, 143, 124, 235, 31, 206, 62, 48, 220, 95, 94, 197, 11, 26,
-166, 225, 57, 202, 213, 71, 93, 61, 217, 1, 90, 214, 81, 86, 108, 77,
-139, 13, 154, 102, 251, 204, 176, 45, 116, 18, 43, 32, 240, 177, 132, 153,
-223, 76, 203, 194, 52, 126, 118, 5, 109, 183, 169, 49, 209, 23, 4, 215,
-20, 88, 58, 97, 222, 27, 17, 28, 50, 15, 156, 22, 83, 24, 242, 34,
-254, 68, 207, 178, 195, 181, 122, 145, 36, 8, 232, 168, 96, 252, 105, 80,
-170, 208, 160, 125, 161, 137, 98, 151, 84, 91, 30, 149, 224, 255, 100, 210,
-16, 196, 0, 72, 163, 247, 117, 219, 138, 3, 230, 218, 9, 63, 221, 148,
-135, 92, 131, 2, 205, 74, 144, 51, 115, 103, 246
Re: [FFmpeg-devel] libavutil: added camellia block cipher
]);
+err = 1;
+}
+}
+av_camellia_crypt(cs, temp, rct[j], 1, NULL, 1);
+for (i = 0; i 16; i++) {
+if (rpt[i] != temp[i]) {
+av_log(NULL, AV_LOG_ERROR, %d %02x %02x\n, i, rpt[i],
temp[i]);
+err = 1;
+}
+}
+}
+
+av_camellia_init(cs, Key[2], 256);
+av_camellia_crypt(cs, temp2, rpt2, 2, NULL, 0);
+av_camellia_crypt(cs, temp2, temp2, 2, NULL, 1);
+for (i = 0; i 32; i++) {
+if (rpt2[i] != temp2[i]) {
+av_log(NULL, AV_LOG_ERROR, %d %02x %02x\n, i, rpt2[i],
temp2[i]);
+err = 1;
+}
+}
You are testing ECB again with a longer pt here, is it not redundant
or am I missing something?
+av_camellia_init(cs, Key[0], 128);
+memcpy(iv, HALLO123HALLO123, 16);
+av_camellia_crypt(cs, temp2, rpt2, 2, iv, 0);
+memcpy(iv, HALLO123HALLO123, 16);
+av_camellia_crypt(cs, temp2, temp2, 2, iv, 1);
+for (i = 0; i 32; i++) {
+if (rpt2[i] != temp2[i]) {
+av_log(NULL, AV_LOG_ERROR, %d %02x %02x\n, i, rpt2[i],
temp2[i]);
+err = 1;
+}
+}
+av_free(cs);
+return err;
+}
+#endif
diff --git a/libavutil/camellia.h b/libavutil/camellia.h
new file mode 100644
index 000..41076d4
--- /dev/null
+++ b/libavutil/camellia.h
@@ -0,0 +1,68 @@
+/*
+ * An implementation of the CAMELLIA algorithm as mentioned in RFC3713
+ * Copyright (c) 2014 Supraja Meedinti
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
+ */
+
+#ifndef AVUTIL_CAMELLIA_H
+#define AVUTIL_CAMELLIA_H
+
+#include stdint.h
+
+
+/**
+ * @file
+ * @brief Public header for libavutil CAMELLIA algorithm
+ * @defgroup lavu_camellia CAMELLIA
+ * @ingroup lavu_crypto
+ * @{
+ */
+
+extern const int av_camellia_size;
+
+struct AVCAMELLIA;
+
+/**
+ * Allocate an AVCAMELLIA context
+ * To free the struct: av_free(ptr)
+ */
+struct AVCAMELLIA *av_camellia_alloc(void);
Nit: add a blank line here
+/**
+ * Initialize an AVCAMELLIA context.
+ *
+ * @param ctx an AVCAMELLIA context
+ * @param key a key of 16, 24, 32 bytes used for encryption/decryption
+ * @param key_bits number of keybits: possible are 128, 192, 256
+ */
+int av_camellia_init(struct AVCAMELLIA *ctx, const uint8_t *key, int
key_bits);
+
+/**
+ * Encrypt or decrypt a buffer using a previously initialized context
+ *
+ * @param ctx an AVCAMELLIA context
+ * @param dst destination array, can be equal to src
+ * @param src source array, can be equal to dst
+ * @param count number of 8 byte blocks
+ * @paran iv initialization vector for CBC mode, NULL for ECB mode
+ * @param decrypt 0 for encryption, 1 for decryption
+ */
+void av_camellia_crypt(struct AVCAMELLIA *ctx, uint8_t *dst, const uint8_t
*src, int count, uint8_t* iv, int decrypt);
Nit: add a blank line here
+/**
+ * @}
+ */
+#endif /* AVUTIL_CAMELLIA_H */
--
1.8.3.2
the rest LGTM thanks.
Giorgio Vazzana
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavutil: added camellia block cipher
Hi, 2014-12-24 23:41 GMT+01:00 supraja reddy supraja0...@gmail.com: Hello, Thank you for your reviews. I have attached the updated patch . You are using a single array K for all the keys, without distinguishing between kw, k and ke as in the rfc. This makes code harder to read/maintain with no real gain I guess. Any reason why you made this decision? I have created a single array for all keys to make the key scheduling more compact as you have seen. Please let me know if there is any other way to do so . You can separate the keys and still make the scheduling compact by using a single for loop to compute the 24 k subkeys, and then compute kw and ke. This will probably also simplify the encrypt() and decrypt() functions. +Zl ^= ((Zr 8) | (Zr 24)); +Zr ^= ((Zl 16) | (Zl 16)); +Zl ^= ((Zr 8) | (Zr 24)); +Zr ^= ((Zl 8) | (Zl 24)); This optimization is correct, just curious, where did you read about it? I have found a specifications page for camellia by the authors of the algorithm. Here's the link to it : www.cryptrec.go.jp/cryptrec_03_spec_cypherlist_files/PDF/06_01espec.pdf I hope I am allowed to do so. Of course, you are encouraged to read other material/documentation and compare/improve your implementation of the algorithm. Please let me know if you find anything useful in the above link that I can incorporate. There are other useful optimizations described in that paper, but we can implement them later. Please let me know if there are any further changes. Thanks, Supraja ___ 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] libavutil: added camellia block cipher
2014-12-26 20:01 GMT+01:00 Michael Niedermayer michae...@gmx.at:
[...]
+static uint64_t F(uint64_t F_IN, uint64_t KE)
+{
+uint32_t Zl, Zr;
+Zl = (F_IN 32) ^ (KE 32);
+Zr = (F_IN MASK32) ^ (KE MASK32);
KE ^= F_IN;
Zl = KE 32;
Zr = KE MASK32;
+Zl = ((SBOX1[(Zl 24) MASK8] 24) | (SBOX2[(Zl 16) MASK8]
16) |(SBOX3[(Zl 8) MASK8] 8) |(SBOX4[Zl MASK8]));
+Zr = ((SBOX2[(Zr 24) MASK8] 24) | (SBOX3[(Zr 16) MASK8]
16) |(SBOX4[(Zr 8) MASK8] 8) |(SBOX1[Zr MASK8]));
(Zl 24) and (Zr 24) are limited to 8bit they should not need
MASK8
((uint32_t)SBOX1[Zl 24]) 24)
Maybe this will be useful later: on 64-bit processors, if MASK8 is a
64-bit constant, this may be faster:
KE ^= F_IN;
Zl = ((uint32_t)SBOX1[KE 56] 24) | ((uint32_t)SBOX2[(KE 48)
MASK8] 16) | ...
+Zl ^= LR32(Zr, 8);
+Zr ^= LR32(Zl, 16);
+Zl ^= RR32(Zr, 8);
+Zr ^= RR32(Zl, 8);
The instructions above have a long critical path (each one depends on
the previous one), and this is probably where we lose most speed at
the moment.
it would also be possible to reduce the number of operations at the
expense of larger tables but iam not sure that would be a good idea
On 64-bit processors, a big speedup can be obtained by computing S and
P operation together, using 8 8x64 bit sboxes (a total of 16kB of
data) that can be computed in the initialization phase from
SBOX1...SBOX4.
But all these suggestions can be implemented later. My main objection
with this patch is using one big array for all subkeys.
[...]
+static const int shift1[2][6] = {
+{0, 15, 30, 17, 17, 17},
+{0, 15, 15, 15, 34, 17}
+};
+static const int pos1[2][6] = {
+{0, 4, 10, 16, 18, 22},
+{2, 6, 8, 14, 20, 24}
+};
+static const int pos2[4][4]= {
+{0, 12, 16, 22},
+{6, 14, 24, 28},
+{2, 10, 20, 32},
+{4, 8, 18, 26}
+};
+static const int shift2[4][5]= {
+{0, 45, 15, 17},
+{15, 30, 32, 17},
+{0, 30, 30, 51},
+{15, 15, 30, 34}
+};
these could be made uint8_t
[...]
--
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.
___
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] libavutil: added camellia block cipher
Hello Supraja,
2014-12-23 18:38 GMT+01:00 supraja reddy supraja0...@gmail.com:
I have attached the patch to the basic implementation of camellia block
cipher. Please let me know if there are any bugs to be fixed or if any
further optimization needed.
thanks for the patch and thank you Michael for the first review.
My comments follow:
From 4ace69c4cc76f04e0e795e67290e979925df600c Mon Sep 17 00:00:00 2001
From: Supraja Meedinti supraja0...@gmail.com
Date: Fri, 19 Dec 2014 20:02:29 +0530
Subject: [PATCH] libavutil: added camellia block cipher
Signed-off-by: Supraja Meedinti supraja0...@gmail.com
---
libavutil/Makefile | 3 +
libavutil/camellia.c | 456
+++
libavutil/camellia.h | 68
3 files changed, 527 insertions(+)
create mode 100644 libavutil/camellia.c
create mode 100644 libavutil/camellia.h
diff --git a/libavutil/Makefile b/libavutil/Makefile
index c1aa8aa..4db89b8 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -16,6 +16,7 @@ HEADERS = adler32.h
\
bswap.h \
buffer.h \
cast5.h \
+ camellia.h\
channel_layout.h \
common.h \
cpu.h \
@@ -84,6 +85,7 @@ OBJS = adler32.o
\
bprint.o \
buffer.o \
cast5.o \
+ camellia.o \
channel_layout.o \
cpu.o\
crc.o\
@@ -154,6 +156,7 @@ TESTPROGS = adler32
\
blowfish\
bprint \
cast5 \
+camellia\
cpu \
crc \
des \
diff --git a/libavutil/camellia.c b/libavutil/camellia.c
new file mode 100644
index 000..6f0d859
--- /dev/null
+++ b/libavutil/camellia.c
@@ -0,0 +1,456 @@
+/*
+ * An implementation of the CAMELLIA algorithm as mentioned in RFC3713
+ * Copyright (c) 2014 Supraja Meedinti
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
+ */
+#include camellia.h
+#include common.h
+#include intreadwrite.h
+#include attributes.h
+
+#define MASK8 0xff
+#define MASK32 0x
+#define MASK64 0x
+
+#define Sigma1 0xA09E667F3BCC908B
+#define Sigma2 0xB67AE8584CAA73B2
+#define Sigma3 0xC6EF372FE94F82BE
+#define Sigma4 0x54FF53A5F1D36F1C
+#define Sigma5 0x10E527FADE682D1D
+#define Sigma6 0xB05688C2B3E6C1FD
+
+typedef struct AVCAMELLIA {
+uint64_t K[34];
+int key_bits;
+} AVCAMELLIA;
You are using a single array K for all the keys, without distinguishing between
kw, k and ke as in the rfc. This makes code harder to read/maintain with no
real gain I guess. Any reason why you made this decision?
+
+static void LROT(uint64_t *K, int x)
+{
+uint64_t d[2];
+if (x)
+return;
Maybe if (!x) ?
+d[0] = (K[0] x | K[1] (64 - x));
+d[1] = (K[1] x | K[0] (64 - x));
+K[0] = d[0];
+K[1] = d[1];
+}
+
+static void swap(uint64_t *k1, uint64_t *k2)
Re: [FFmpeg-devel] libavutil: Added cbc mode to cast5.c
Hello,
2014-12-17 19:53 GMT+01:00 supraja reddy supraja0...@gmail.com:
I hope this fixes all the issues .
From 16c8db86ebf92f68a8a750dcbe5e3598a8bd69b5 Mon Sep 17 00:00:00 2001
From: Supraja Meedinti supraja0...@gmail.com
Date: Thu, 18 Dec 2014 00:17:45 +0530
Subject: [PATCH] libavutil: Added cbc mode to cast128
Signed-off-by: Supraja Meedinti supraja0...@gmail.com
---
libavutil/cast5.c | 40 ++--
libavutil/cast5.h | 14 +-
2 files changed, 51 insertions(+), 3 deletions(-)
diff --git a/libavutil/cast5.c b/libavutil/cast5.c
index 14dd701..dba5b6a 100644
--- a/libavutil/cast5.c
+++ b/libavutil/cast5.c
@@ -416,7 +416,7 @@ static void encipher(AVCAST5* cs, uint8_t* dst, const
uint8_t* src)
AV_WB32(dst + 4, l);
}
-static void decipher(AVCAST5* cs, uint8_t* dst, const uint8_t* src)
+static void decipher(AVCAST5* cs, uint8_t* dst, const uint8_t* src, uint8_t
*iv)
{
uint32_t f, I, r, l;
l = AV_RB32(src);
@@ -439,6 +439,11 @@ static void decipher(AVCAST5* cs, uint8_t* dst, const
uint8_t* src)
F3(r, l, 3);
F2(l, r, 2);
F1(r, l, 1);
+if (iv) {
+r ^= AV_RB32(iv);
+l ^= AV_RB32(iv + 4);
+memcpy(iv, src, 8);
Indentation is off.
+}
AV_WB32(dst, r);
AV_WB32(dst + 4, l);
}
@@ -468,11 +473,30 @@ av_cold int av_cast5_init(AVCAST5* cs, const uint8_t
*key, int key_bits)
return 0;
}
+void av_cast5_crypt2(AVCAST5* cs, uint8_t* dst, const uint8_t* src, int
count, uint8_t *iv, int decrypt)
+{
+int i;
+while (count--) {
+if (decrypt){
Missing space between ) and {.
+decipher(cs, dst, src, iv);
+} else {
The indentation of this else branch is wrong.
+if (iv) {
+for (i = 0; i 8; i++)
+dst[i] = src[i] ^ iv[i];
+encipher(cs, dst, dst);
Again, you are not saving the IV for the next block here.
+} else {
+encipher(cs, dst, src);
+}
+}
+src = src + 8;
+dst = dst + 8;
+}
+}
void av_cast5_crypt(AVCAST5* cs, uint8_t* dst, const uint8_t* src, int
count, int decrypt)
{
while (count--) {
if (decrypt){
-decipher(cs, dst, src);
+decipher(cs, dst, src, NULL);
} else {
encipher(cs, dst, src);
}
@@ -504,6 +528,7 @@ int main(int argc, char** argv)
{0xee, 0xa9, 0xd0, 0xa2, 0x49, 0xfd, 0x3b, 0xa6, 0xb3, 0x43, 0x6f,
0xb8, 0x9d, 0x6d, 0xca, 0x92},
{0xb2, 0xc9, 0x5e, 0xb0, 0x0c, 0x31, 0xad, 0x71, 0x80, 0xac, 0x05,
0xb8, 0xe8, 0x3d, 0x69, 0x6e}
};
+uint8_t iv[8] = {0xee, 0xa9, 0xd0, 0xa2, 0x49, 0xfd, 0x3b, 0xa6};
static uint8_t rpt2[2][16];
int i, j, err = 0;
static int key_bits[3] = {128, 80, 40};
@@ -547,6 +572,17 @@ int main(int argc, char** argv)
}
}
}
+for (j = 0; j 3; j++) {
+av_cast5_init(cs, Key[j], key_bits[j]);
+av_cast5_crypt2(cs, temp, rpt, 1, iv, 0);
+av_cast5_crypt2(cs, temp, temp, 1, iv, 1);
+for (i =0; i 8; i++) {
Missing space after =.
+if (rpt[i] != temp[i]) {
+av_log(NULL, AV_LOG_ERROR, %d %02x %02x\n, i, rpt[i],
temp[i]);
+err = 1;
+}
+}
+}
I see at least 2 problems with this for loop:
1) you need to use the same IV to encrypt and decrypt the block. It
seems to work here because you forgot to propagate the IV correctly in
av_cast5_crypt2, otherwise after the encryption the IV would change,
and so you would be using a different IV for the decryption.
2) to correctly test CBC mode we need to work on 2 blocks at least.
av_free(cs);
return err;
}
diff --git a/libavutil/cast5.h b/libavutil/cast5.h
index 913d048..4a86743 100644
--- a/libavutil/cast5.h
+++ b/libavutil/cast5.h
@@ -52,7 +52,7 @@ struct AVCAST5 *av_cast5_alloc(void);
int av_cast5_init(struct AVCAST5 *ctx, const uint8_t *key, int key_bits);
/**
- * Encrypt or decrypt a buffer using a previously initialized context
+ * Encrypt or decrypt a buffer using a previously initialized context, ECB
mode only
*
* @param ctx an AVCAST5 context
* @param dst destination array, can be equal to src
@@ -61,6 +61,18 @@ int av_cast5_init(struct AVCAST5 *ctx, const uint8_t *key,
int key_bits);
* @param decrypt 0 for encryption, 1 for decryption
*/
void av_cast5_crypt(struct AVCAST5 *ctx, uint8_t *dst, const uint8_t *src,
int count, int decrypt);
+
+/**
+ * Encrypt or decrypt a buffer using a previously initialized context
+ *
+ * @param ctx an AVCAST5 context
+ * @param dst destination array, can be equal to src
+ * @param src source array, can be equal to dst
+ * @param count number of 8 byte blocks
+ * @param iv initialization vector for cbc mode, NULL for ecb mode
+ * @param decrypt 0 for encryption, 1 for
Re: [FFmpeg-devel] libavutil: Added cbc mode to cast5.c
AVCAST5 *ctx, uint8_t *dst, const uint8_t *src, int count, uint8_t *iv, int decrypt); /** * @} */ -- 1.8.3.2 the rest LGTM, thanks. Giorgio Vazzana ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavutil: Added cbc mode to cast5.c
Hello,
2014-12-17 10:27 GMT+01:00 Carl Eugen Hoyos ceho...@ag.or.at:
supraja reddy supraja0493 at gmail.com writes:
-- CAST128 symmetric block cipher, ECB mode
+- CAST128 symmetric block cipher
This line is part of the 2.5 paragraph, please
do not change this paragraph as 2.5 was already
released.
-void av_cast5_crypt(struct AVCAST5 *ctx, uint8_t *dst,
const uint8_t *src, int count, int decrypt);
+void av_cast5_crypt(struct AVCAST5 *ctx, uint8_t *dst,
const uint8_t *src, int count, uint8_t *iv, int decrypt);
You cannot do this because cast5.h is an installed
header. One possibility is to introduce a new
function av_cast5_crypt2().
-for (j = 0; j 3; j++){
+for (j = 0; j 3; j++) {
-for (i = 0; i 100; i++){
+for (i = 0; i 100; i++) {
Please avoid cosmetic changes in patches that
introduce new features: Either send another
cosmetics-only patch or leave it as it is.
+} else {
+if (iv) {
+for (i = 0; i 8; i++)
+dst[i] = src[i] ^ iv[i];
+encipher(cs, dst, dst);
Indentation in the new code is wrong.
thank you Carl for the review, I agree all your points are valid.
There seems to be a bigger problem with this patch though, the IV
vector is not propagated correctly and thus the CBC mode would not
work.
Also, it would be nice if we could add some code in the selftest to
cover this mode too.
Giorgio Vazzana
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavutil : cosmetic: added spaces wherever necessary
], Key[0], 16);
+memcpy(rpt2[1], Key[0], 16);
+for (i = 0; i 100; i++){
+av_cast5_init(cs, rpt2[1], 128);
+av_cast5_crypt(cs, rpt2[0], rpt2[0], 2, 0);
+av_cast5_init(cs, rpt2[0], 128);
+av_cast5_crypt(cs, rpt2[1], rpt2[1], 2, 0);
}
-for (j=0;j2;j++){
-for (i=0;i16;i++){
-if (rct2[j][i]!=rpt2[j][i]){
-av_log(NULL,AV_LOG_ERROR,%d %02x
%02x\n,i,rct2[j][i],rpt2[j][i]);
-err=1;
+for (j = 0; j 2; j++) {
+for (i = 0; i 16; i++) {
+if (rct2[j][i] != rpt2[j][i]) {
+av_log(NULL, AV_LOG_ERROR, %d %02x %02x\n, i, rct2[j][i],
rpt2[j][i]);
+err = 1;
}
}
}
The rest looks good to me, thanks.
Giorgio Vazzana
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] v4l2: setting device parameters early
2014-11-06 12:47 GMT+01:00 Giorgio Vazzana mywin...@gmail.com: Hi, 2014-11-05 21:54 GMT+01:00 Michael Niedermayer michae...@gmx.at: On Wed, Oct 22, 2014 at 04:12:31PM +0200, Giorgio Vazzana wrote: Hello, this was probably wrong and has caused i can revert it if you want ? I will sent a patch for testing on that ticket later and see if we get some feedback from the OP. Reverting this commit fixes ticket #3517, so Michael I think it's safe to revert. Federico, I could not reproduce the error you reported in the commit message. If that problem is still present on git master (after reverting this commit) please let us know. Giorgio Vazzana https://trac.ffmpeg.org/ticket/3517 . Will investigate. Giorgio Vazzana 2014-01-05 17:17 GMT+01:00 Michael Niedermayer michae...@gmx.at: On Sun, Jan 05, 2014 at 12:33:42PM +0100, Federico Simoncelli wrote: Any feedback? looks good, thus applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes ___ 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 -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavd/v4l2: use pixel format variable names consistently
From c373c413bd2d27463a45e50c5827975e579b6e7c Mon Sep 17 00:00:00 2001
From: Giorgio Vazzana mywin...@gmail.com
Date: Thu, 6 Nov 2014 11:30:41 +0100
Subject: [PATCH] lavd/v4l2: use pixel format variable names consistently
We now use 'pixelformat' for V4L2_PIX_FMT_* (as they do in v4l2
documentation) and 'pix_fmt' for AVPixelFormat.
No functional change in the code.
---
libavdevice/v4l2.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
index bd72d3d..783a03c 100644
--- a/libavdevice/v4l2.c
+++ b/libavdevice/v4l2.c
@@ -67,7 +67,7 @@ static const int desired_video_buffers = 256;
struct video_data {
AVClass *class;
int fd;
-int frame_format; /* V4L2_PIX_FMT_* */
+int pixelformat; /* V4L2_PIX_FMT_* */
int width, height;
int frame_size;
int interlaced;
@@ -183,18 +183,19 @@ fail:
}
static int device_init(AVFormatContext *ctx, int *width, int *height,
- uint32_t pix_fmt)
+ uint32_t pixelformat)
{
struct video_data *s = ctx-priv_data;
struct v4l2_format fmt = { .type = V4L2_BUF_TYPE_VIDEO_CAPTURE };
-struct v4l2_pix_format *pix = fmt.fmt.pix;
int res = 0;
-pix-width = *width;
-pix-height = *height;
-pix-pixelformat = pix_fmt;
-pix-field = V4L2_FIELD_ANY;
+fmt.fmt.pix.width = *width;
+fmt.fmt.pix.height = *height;
+fmt.fmt.pix.pixelformat = pixelformat;
+fmt.fmt.pix.field = V4L2_FIELD_ANY;
+/* Some drivers will fail and return EINVAL when the pixelformat
+ is not supported (even if type field is valid and supported) */
if (v4l2_ioctl(s-fd, VIDIOC_S_FMT, fmt) 0)
res = AVERROR(errno);
@@ -206,11 +207,11 @@ static int device_init(AVFormatContext *ctx, int *width, int *height,
*height = fmt.fmt.pix.height;
}
-if (pix_fmt != fmt.fmt.pix.pixelformat) {
+if (pixelformat != fmt.fmt.pix.pixelformat) {
av_log(ctx, AV_LOG_DEBUG,
The V4L2 driver changed the pixel format
from 0x%08X to 0x%08X\n,
- pix_fmt, fmt.fmt.pix.pixelformat);
+ pixelformat, fmt.fmt.pix.pixelformat);
res = AVERROR(EINVAL);
}
@@ -931,7 +932,7 @@ static int v4l2_read_header(AVFormatContext *ctx)
if ((res = av_image_check_size(s-width, s-height, 0, ctx)) 0)
goto fail;
-s-frame_format = desired_format;
+s-pixelformat = desired_format;
st-codec-pix_fmt = ff_fmt_v4l2ff(desired_format, codec_id);
s-frame_size =
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/v4l2: don't use avpriv_ prefix for internal functions
2014-10-21 12:26 GMT+02:00 Stefano Sabatini stefa...@gmail.com: On date Tuesday 2014-10-21 03:56:06 -0300, James Almer encoded: No need to keep the old symbols around until a major bump since lavd functions with the avpriv_ prefix were never exposed. Signed-off-by: James Almer jamr...@gmail.com LGTM. Ping. Any news about this? Can it be applied? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] v4l2: setting device parameters early
Hello, this was probably wrong and has caused https://trac.ffmpeg.org/ticket/3517 . Will investigate. Giorgio Vazzana 2014-01-05 17:17 GMT+01:00 Michael Niedermayer michae...@gmx.at: On Sun, Jan 05, 2014 at 12:33:42PM +0100, Federico Simoncelli wrote: Any feedback? looks good, thus applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavutil: Add missing av_free() to cast5 selftest
Hi, this should make fate green again. Giorgio Vazzana From 769cd50d4d3ba4a6f62db3c2599ba653e919e94a Mon Sep 17 00:00:00 2001 From: Giorgio Vazzana mywin...@gmail.com Date: Sat, 18 Oct 2014 16:50:59 +0200 Subject: [PATCH] libavutil: Add missing av_free() to cast5 selftest --- libavutil/cast5.c |1 + 1 file changed, 1 insertion(+) diff --git a/libavutil/cast5.c b/libavutil/cast5.c index 63f8598..2309223 100644 --- a/libavutil/cast5.c +++ b/libavutil/cast5.c @@ -535,6 +535,7 @@ int main(int argc, char** argv) } } } +av_free(cs); return err; } #endif -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch for Cast128 algorithm implementation
Hi, 2014-10-16 5:32 GMT+02:00 Michael Niedermayer michae...@gmx.at: On Thu, Oct 16, 2014 at 03:25:42AM +0530, supraja reddy wrote: Extremely sorry for resending the patch . There was a trailing whitespace which I hadn't corrected . All the changes are done . Please let me if any changes needed further . also a test that enciphers and deciphers a larger amount of random data could be added The RFC defines a Full Maintenance Test, http://tools.ietf.org/html/rfc2144#appendix-B.2 it should probably be added (easy: just a few lines of code). +return err; +} +#endif diff --git a/libavutil/cast5.h b/libavutil/cast5.h new file mode 100644 index 000..d151031 --- /dev/null +++ b/libavutil/cast5.h @@ -0,0 +1,60 @@ +/* + * An implementation of the CAST128 algorithm as mentioned in RFC2144 + * Copyright (c) 2014 Supraja Meedinti + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef AVUTIL_CAST5_H +#define AVUTIL_CAST5_H + +#include stdint.h + +#include attributes.h +#include version.h I think version.h is not needed and you can move attributes.h to cast5.c No more comments from me, apart from: well done! Another round of revision and hopefully we'll soon be able to apply the patch :) Giorgio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] opw@ffmpeg mail alias
2014-10-13 3:49 GMT+02:00 Michael Niedermayer michae...@gmx.at: Hi all does any mentor want to be added to the opw@ffmpeg alias if so, tell me and ill add you Sure, add me, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] gnome-opw 2015
Hi, 2014-10-13 22:07 GMT+02:00 Nikita Mantri nikita.mantr...@gmail.com: Hi, For the generic CMAC module, can I reuse the code of md5 and sha from libavutil, or should I implement this hash function again. You can reuse the existing code, of course. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] gnome-opw 2015
2014-10-12 2:18 GMT+02:00 Michael Niedermayer michae...@gmx.at: Hi On Sun, Oct 12, 2014 at 02:51:36AM +0530, Nikita Mantri wrote: Hi, I am a 4th year B.Tech. student. As a part of gnome-opw 2015 programme, I would like to contribute to one of the development projects that is listed on the website. I have decided to contribute to the symmetric-key block ciphers project as i have an intermediate knowledge of cryptography. I have done a research project in cryptography and security primitives during my research internship period. I would be obliged if you will help me in start contributing to this project. there are already 2 other potential applicants for symmetric-key block ciphers, but if you want to try anyway, please choose a related qualification task, like some hash function or symmetric block cypher that FFmpeg doesnt support yet and that noone else has picked as their qualification task. also, if you start working on a qualification task please add yourself to the wiki also note that for qualification to be passed the code for the qualification task has to be submited here and pass review, this may take multiple iterations and has to happen before slot(s) are assigned to applicants. Giorgio may have more or other comments, he is the mentor of the symmetric-key block ciphers task ... Hello Nikita, thanks for your email. As Michael pointed out we already have two potential applicants for the Symmetric-key block ciphers project and I feel like I've reached the number of people I want to mentor in one round (allright, I didn't think this project would turn out to be so popular!) Anyway if you still want to try let us know and together with you we will choose a suitable qualification task (the ones that Michael proposed are fine with me). You will have only ten days to complete your qualification task and submit your application, but depending on your level of experience this could be doable. Regards, Giorgio Vazzana ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] gnome-opw 2015
Hi Michael, 2014-10-12 18:11 GMT+02:00 Michael Niedermayer michae...@gmx.at: On Sun, Oct 12, 2014 at 05:49:54PM +0200, Giorgio Vazzana wrote: 2014-10-12 2:18 GMT+02:00 Michael Niedermayer michae...@gmx.at: Hi On Sun, Oct 12, 2014 at 02:51:36AM +0530, Nikita Mantri wrote: Hi, I am a 4th year B.Tech. student. As a part of gnome-opw 2015 programme, I would like to contribute to one of the development projects that is listed on the website. I have decided to contribute to the symmetric-key block ciphers project as i have an intermediate knowledge of cryptography. I have done a research project in cryptography and security primitives during my research internship period. I would be obliged if you will help me in start contributing to this project. there are already 2 other potential applicants for symmetric-key block ciphers, but if you want to try anyway, please choose a related qualification task, like some hash function or symmetric block cypher that FFmpeg doesnt support yet and that noone else has picked as their qualification task. also, if you start working on a qualification task please add yourself to the wiki also note that for qualification to be passed the code for the qualification task has to be submited here and pass review, this may take multiple iterations and has to happen before slot(s) are assigned to applicants. Giorgio may have more or other comments, he is the mentor of the symmetric-key block ciphers task ... Hello Nikita, thanks for your email. As Michael pointed out we already have two potential applicants for the Symmetric-key block ciphers project and I feel like I've reached the number of people I want to mentor in one round (allright, I didn't think this project would turn out to be so popular!) note, its unlikely that more than one applicant for symmetric-key block ciphers will get a slot, though it could happen if there are 2 who submit very impressive qualification tasks and theres noone submitting a good qualification task for something else and if we do have enough slots ... Thanks, now it's more clear. Do we already know the total number of OPW slots for ffmpeg? so its ATM just the qualification tasks for which the number of applicants is rather large. If you need help or need someone else to take over mentoring an applicant for the qualification task, ill find someone ? OK, I should be able to help another applicant for her qualification task then. But for the internship itself (Dec 2014 to Mar 2015) I'm afraid I will have time to mentor at most 2 students. Of course if someone has free time and is willing to help with the qualification tasks, by all means please go for it. This way we'll make sure every student gets a chance. Giorgio Vazzana [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato ___ 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] gnome-opw 2015
Hello Nikita, we already have a HMAC module in libavutil, so you could try to implement The AES-CMAC Algorithm, RFC 4493. Michael, would this be acceptable for you? Giorgio Vazzana 2014-10-12 19:17 GMT+02:00 Nikita Mantri nikita.mantr...@gmail.com: Hi, Thanks for your response. I want to contribute to this project (Symmetric-key block cipher). I am aware of that there are already two candidates who are working on this project, but I still want to give it a try. For the qualification round, suggest me some task. I can implement the hash function (CMAC, HMAC,..) if it is considered as suitable. Thanks, Nikita Mantri On 12 October 2014 21:19, Giorgio Vazzana mywin...@gmail.com wrote: 2014-10-12 2:18 GMT+02:00 Michael Niedermayer michae...@gmx.at: Hi On Sun, Oct 12, 2014 at 02:51:36AM +0530, Nikita Mantri wrote: Hi, I am a 4th year B.Tech. student. As a part of gnome-opw 2015 programme, I would like to contribute to one of the development projects that is listed on the website. I have decided to contribute to the symmetric-key block ciphers project as i have an intermediate knowledge of cryptography. I have done a research project in cryptography and security primitives during my research internship period. I would be obliged if you will help me in start contributing to this project. there are already 2 other potential applicants for symmetric-key block ciphers, but if you want to try anyway, please choose a related qualification task, like some hash function or symmetric block cypher that FFmpeg doesnt support yet and that noone else has picked as their qualification task. also, if you start working on a qualification task please add yourself to the wiki also note that for qualification to be passed the code for the qualification task has to be submited here and pass review, this may take multiple iterations and has to happen before slot(s) are assigned to applicants. Giorgio may have more or other comments, he is the mentor of the symmetric-key block ciphers task ... Hello Nikita, thanks for your email. As Michael pointed out we already have two potential applicants for the Symmetric-key block ciphers project and I feel like I've reached the number of people I want to mentor in one round (allright, I didn't think this project would turn out to be so popular!) Anyway if you still want to try let us know and together with you we will choose a suitable qualification task (the ones that Michael proposed are fine with me). You will have only ten days to complete your qualification task and submit your application, but depending on your level of experience this could be doable. Regards, Giorgio Vazzana ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Please help update tasks and mentor/backups for OPW
2014-09-25 19:20 GMT+02:00 Reynaldo H. Verdejo Pinochet reyna...@osg.samsung.com: Things that need urgent attention are ensuring listed projects are still relevant as well as making sure their mentors are still available and willing to take part on the program. I took the liberty of CCing some of the currently listed mentors so they can hopefully help with the latter. I am still available as a mentor for the Symmetric-key block ciphers project. Regards, Giorgio Vazzana ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavdevice/v4l2: fix of crash caused by assert
2014-09-01 22:46 GMT+02:00 Reimar Döffinger reimar.doeffin...@gmx.de:
On Mon, Sep 01, 2014 at 10:33:15PM +0200, Giorgio Vazzana wrote:
+static int enqueue_buffer(struct video_data *s, struct v4l2_buffer *buf)
+{
+int res = 0;
+
+if (v4l2_ioctl(s-fd, VIDIOC_QBUF, buf) 0) {
+res = AVERROR(errno);
+av_log(NULL, AV_LOG_ERROR, ioctl(VIDIOC_QBUF): %s\n,
av_err2str(res));
+} else {
+avpriv_atomic_int_add_and_fetch(s-buffers_queued, 1);
+}
+
+return res;
Nit: I'd prefer something simpler that avoids cluttering the normal path
because of error handling like:
+if (v4l2_ioctl(s-fd, VIDIOC_QBUF, buf) 0) {
+av_log(NULL, AV_LOG_ERROR, ioctl(VIDIOC_QBUF): %s\n,
av_err2str(res));
+return AVERROR(errno);
If we call av_log(), errno is not guaranteed to be the same after the
call. Also, av_err2str() needs AVERROR(errno).
+}
+avpriv_atomic_int_add_and_fetch(s-buffers_queued, 1);
+return 0;
static void mmap_release_buffer(void *opaque, uint8_t *data)
I haven't checked, but I suspect this function could be made simpler
and more likely to not re-introduce these bugs by using for the
error paths goto.
Admittedly that doesn't belong in this patch anyway though.
OK, we'll fix this in another patch then.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
