[FFmpeg-devel] [PATCH] matroskadec: execute seekheads recursively
This fixes https://trac.ffmpeg.org/ticket/3934 https://trac.ffmpeg.org/ticket/3934, but I'm not sure if there was a good reason for this to be here to begin with. Perhaps a protection against infinite recursion (though I believe EBML_MAX_DEPTH serves that purpose to some degree)? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] matroskadec: execute seekheads recursively
On Oct 17, 2014, at 01:16, Rodger Combs rodger.co...@gmail.com wrote: This fixes https://trac.ffmpeg.org/ticket/3934 https://trac.ffmpeg.org/ticket/3934, but I'm not sure if there was a good reason for this to be here to begin with. Perhaps a protection against infinite recursion (though I believe EBML_MAX_DEPTH serves that purpose to some degree)? 0001-matroskadec-execute-seekheads-recursively.patch Evidently either I or my mail client screwed up and the patch didn't get attached. Whoops. Let's try that again... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] matroskadec: execute seekheads recursively
On Oct 17, 2014, at 01:52, Rodger Combs rodger.co...@gmail.com wrote: On Oct 17, 2014, at 01:16, Rodger Combs rodger.co...@gmail.com mailto:rodger.co...@gmail.com wrote: This fixes https://trac.ffmpeg.org/ticket/3934 https://trac.ffmpeg.org/ticket/3934, but I'm not sure if there was a good reason for this to be here to begin with. Perhaps a protection against infinite recursion (though I believe EBML_MAX_DEPTH serves that purpose to some degree)? 0001-matroskadec-execute-seekheads-recursively.patch Evidently either I or my mail client screwed up and the patch didn't get attached. Whoops. 0001-matroskadec-execute-seekheads-recursively.patch Let's try that again... Welp, apparently my email client's borked badly in some way. Here's a gist link instead: https://gist.github.com/08f111e72b8b5ddba078 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH: Make -copyts a tri-state
On Oct 15, 2014, at 06:00, Rodger Combs rodger.co...@gmail.com wrote: On Oct 15, 2014, at 05:37, Nicolas George geo...@nsup.org wrote: Le quartidi 24 vendémiaire, an CCXXIII, Rodger Combs a écrit : Discussed this briefly on IRC; decided this was a good idea. I'm not sure if the commit message explains it well enough; please poke me here or on IRC if it doesn't. From 617b532c8a403c1cf06e60c99e9f36c787553b43 Mon Sep 17 00:00:00 2001 From: Rodger Combs rodger.co...@gmail.com Date: Wed, 15 Oct 2014 05:00:02 -0500 Subject: [PATCH] Make copyts a tri-state, with `no` normalizing input timestamps. This doesn't change the default or `-copyts` behavior, but allows `-nocopyts` to make e.g. `-ss 50` have timestamps starting at 50 seconds, even if the input file's timestamps start at a value other than zero. --- ffmpeg.c | 6 +++--- ffmpeg_opt.c | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) It looks like you forgot to update the documentation too. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Indeed I did. Here you go: 0001-Make-copyts-a-tri-state-with-no-normalizing-input-ti.patch It occurs to me that it might be more useful in some cases to have one master input file (the first one?) be shifted so its timestamps start at zero, and the rest be shifted by the same amount as the master. That might be a good argument for making this its own option, instead of making copyts a tri-state. I'm not particularly attached to the naming or implementation here, so suggestions are plenty welcome :) Upon some further testing, this seems to create some unusual and undesired behavior in some cases, and I'm not sure exactly why. The patch is definitely not ready, but I'd appreciate it if anyone could help work out a better design for the feature. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/id3v2: support buggy id3v2.3 tag length in id3v2.4
Some encoders do not use syncsafe sizes in v2.4 id3 tags. Check the next
tag to try to choose between the two.
Fixes ticket #4003
---
libavformat/id3v2.c | 64 +++--
1 file changed, 62 insertions(+), 2 deletions(-)
diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
index 44df4ff..3e54620 100644
--- a/libavformat/id3v2.c
+++ b/libavformat/id3v2.c
@@ -170,6 +170,48 @@ static unsigned int get_size(AVIOContext *s, int len)
return v;
}
+static unsigned int size_to_syncsafe(unsigned int size)
+{
+return (((size) (0x7f 0)) 0) +
+ (((size) (0x7f 8)) 1) +
+ (((size) (0x7f 16)) 2) +
+ (((size) (0x7f 24)) 3);
+}
+
+/* No real verification, only check that the tag consists of
+ * a combination of capital alpha-numerical characters */
+static int is_tag(const char *buf, unsigned int len)
+{
+if (!len)
+return 0;
+
+while (len--)
+if ((buf[len] 'A' ||
+ buf[len] 'Z')
+(buf[len] '0' ||
+ buf[len] '9'))
+return 0;
+
+return 1;
+}
+
+/**
+ * Return 1 if the tag of length len at the given offset is valid, 0 if not,
-1 on error
+ */
+static int check_tag(AVIOContext *s, int offset, unsigned int len)
+{
+char tag[4];
+
+if (len 4 ||
+avio_seek(s, offset, SEEK_SET) 0 ||
+avio_read(s, tag, len) len)
+return -1;
+else if (!AV_RB32(tag) || is_tag(tag, len))
+return 1;
+
+return 0;
+}
+
/**
* Free GEOB type extra metadata.
*/
@@ -734,8 +776,26 @@ static void id3v2_parse(AVIOContext *pb, AVDictionary
**metadata,
tag[4] = 0;
if (version == 3) {
tlen = avio_rb32(pb);
-} else
-tlen = get_size(pb, 4);
+} else {
+/* some encoders incorrectly uses v3 sizes instead of syncsafe
ones
+ * so check the next tag to see which one to use */
+tlen = avio_rb32(pb);
+if (tlen 0x7f) {
+if (tlen len) {
+int64_t cur = avio_tell(pb);
+
+if (ffio_ensure_seekback(pb, 2 /* tflags */ + tlen + 4
/* next tag */))
+break;
+
+if (check_tag(pb, cur + 2 + size_to_syncsafe(tlen), 4)
== 1)
+tlen = size_to_syncsafe(tlen);
+else if (check_tag(pb, cur + 2 + tlen, 4) != 1)
+break;
+avio_seek(pb, cur, SEEK_SET);
+} else
+tlen = size_to_syncsafe(tlen);
+}
+}
tflags = avio_rb16(pb);
tunsync = tflags ID3v2_FLAG_UNSYNCH;
} else {
--
2.1.2.443.g670a3c1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/aacdec: map LFE[0] to SCE[1] for 4.0 audio.
Hi,
- Mail original -
On Mon, Oct 13, 2014 at 02:42:55PM +0200, Benoit Fouet wrote:
Fixes ticket #3930
---
libavcodec/aacdec.c | 10 ++
1 file changed, 10 insertions(+)
applied
maybe these special case mappings should print some warning or
some debug information, could help if they are ever wrong
See attached patch.
--
Ben
From bf370c0c2ec49881d7a2de1fd74e7bd5b2b2e12d Mon Sep 17 00:00:00 2001
From: Benoit Fouet benoit.fo...@free.fr
Date: Fri, 17 Oct 2014 11:44:55 +0200
Subject: [PATCH] avcodec/aacdec: warn user when remapping streams.
---
libavcodec/aacdec.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index ed12e7d..83cb384 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -621,6 +621,10 @@ static ChannelElement *get_che(AACContext *ac, int type, int elem_id)
* If we seem to have encountered such a stream, transfer
* the LFE[0] element to the SCE[1]'s mapping */
if (ac-tags_mapped == tags_per_config[ac-oc[1].m4ac.chan_config] - 1 (type == TYPE_LFE || type == TYPE_SCE)) {
+if (type != TYPE_LFE || elem_id != 0)
+av_log(ac-avctx, AV_LOG_WARNING,
+ This stream seems to incorrectly report its last channel as %s[%d], mapping to LFE[0]\n,
+ type == TYPE_SCE ? SCE : LFE, elem_id);
ac-tags_mapped++;
return ac-tag_che_map[type][elem_id] = ac-che[TYPE_LFE][0];
}
@@ -637,6 +641,10 @@ static ChannelElement *get_che(AACContext *ac, int type, int elem_id)
* If we seem to have encountered such a stream, transfer
* the SCE[1] element to the LFE[0]'s mapping */
if (ac-tags_mapped == tags_per_config[ac-oc[1].m4ac.chan_config] - 1 (type == TYPE_LFE || type == TYPE_SCE)) {
+if (type != TYPE_SCE || elem_id != 1)
+av_log(ac-avctx, AV_LOG_WARNING,
+ This stream seems to incorrectly report its last channel as %s[%d], mapping to SCE[1]\n,
+ type == TYPE_SCE ? SCE : LFE, elem_id);
ac-tags_mapped++;
return ac-tag_che_map[type][elem_id] = ac-che[TYPE_SCE][1];
}
--
2.1.2.443.g670a3c1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] gitignore: add test_copy.ffmeta
--- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 480fbe0..793d33a 100644 --- a/.gitignore +++ b/.gitignore @@ -64,6 +64,7 @@ /tests/data/ /tests/pixfmts.mak /tests/rotozoom +/tests/test_copy.ffmeta /tests/tiny_psnr /tests/tiny_ssim /tests/videogen -- 2.1.2.443.g670a3c1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] matroskadec: execute seekheads recursively
On Fri, 17 Oct 2014 01:55:35 -0500 Rodger Combs rodger.co...@gmail.com wrote: On Oct 17, 2014, at 01:52, Rodger Combs rodger.co...@gmail.com wrote: On Oct 17, 2014, at 01:16, Rodger Combs rodger.co...@gmail.com mailto:rodger.co...@gmail.com wrote: This fixes https://trac.ffmpeg.org/ticket/3934 https://trac.ffmpeg.org/ticket/3934, but I'm not sure if there was a good reason for this to be here to begin with. Perhaps a protection against infinite recursion (though I believe EBML_MAX_DEPTH serves that purpose to some degree)? 0001-matroskadec-execute-seekheads-recursively.patch Evidently either I or my mail client screwed up and the patch didn't get attached. Whoops. 0001-matroskadec-execute-seekheads-recursively.patch Let's try that again... Welp, apparently my email client's borked badly in some way. Here's a gist link instead: https://gist.github.com/08f111e72b8b5ddba078 Yes, seekheads can reference other seekheads. IMO it should perhaps keep a list of elements to read (and which have already been read), which includes the seakhead. Since it'd be a list, it'd be safe against recursion. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Allocate buffer in case of long metadata entries.
Am 16.10.14 04:47, schrieb Michael Niedermayer:
On Mon, Oct 13, 2014 at 09:40:42AM +0200, Thilo Borgmann wrote:
Am 11.10.14 16:19, schrieb Nicolas George:
[...]
all remarks applied.
-Thilo
mov.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
cabb6e51de7f9329603561773f209b6a948478ce
0001-lavf-mov.c-Allocate-buffer-in-case-of-long-metadata-.patch
From 5a14ef97ffc7d82dea5644c736e6dc2de2079e89 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann thilo.borgm...@mail.de
Date: Mon, 13 Oct 2014 09:36:17 +0200
Subject: [PATCH] lavf/mov.c: Allocate buffer in case of long metadata
entries.
---
libavformat/mov.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 4ff46dd..8d6d074 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -261,7 +261,9 @@ static int mov_read_udta_string(MOVContext *c,
AVIOContext *pb, MOVAtom atom)
#ifdef MOV_EXPORT_ALL_METADATA
char tmp_key[5];
#endif
-char str[1024], key2[16], language[4] = {0};
+char str_small[1024], key2[16], language[4] = {0};
+char *str = str_small;
+char *pstr = NULL;
const char *key = NULL;
uint16_t langcode = 0;
uint32_t data_type = 0, str_size;
@@ -358,13 +360,17 @@ static int mov_read_udta_string(MOVContext *c,
AVIOContext *pb, MOVAtom atom)
if (atom.size 0)
return AVERROR_INVALIDDATA;
-str_size = FFMIN3(sizeof(str)-1, str_size, atom.size);
-
if (parse)
parse(c, pb, str_size, key);
else {
+if (str_size sizeof(str_small)-1) { // allocate buffer for long
data field
+pstr = str = av_malloc(str_size);
+if (!pstr)
+return AVERROR(ENOMEM);
+}
+
if (data_type == 3 || (data_type == 0 (langcode 0x400 ||
langcode == 0x7fff))) { // MAC Encoded
-mov_read_mac_string(c, pb, str_size, str, sizeof(str));
+mov_read_mac_string(c, pb, str_size, str, str_size);
this seems to store UTF8, which can require more space than str_size
New patch attached using a worst-case size of twice the input string size if
the input is in utf8.
Tested only with non utf8 by now - I would appreciate it if someone could test
this with UTF8 metadata or tell me how to generate/where to get a suitable file.
-Thilo
From 1a59272e3d333c784e9f4857cd3aa6542ad28d6d Mon Sep 17 00:00:00 2001
From: Thilo Borgmann thilo.borgm...@mail.de
Date: Fri, 17 Oct 2014 14:30:30 +0200
Subject: [PATCH] lavf/mov.c: Allocate buffer in case of long metadata entries.
---
libavformat/mov.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 4ff46dd..a48877d 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -261,7 +261,9 @@ static int mov_read_udta_string(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
#ifdef MOV_EXPORT_ALL_METADATA
char tmp_key[5];
#endif
-char str[1024], key2[16], language[4] = {0};
+char str_small[1024], key2[16], language[4] = {0};
+char *str = str_small;
+char *pstr = NULL;
const char *key = NULL;
uint16_t langcode = 0;
uint32_t data_type = 0, str_size;
@@ -358,15 +360,28 @@ static int mov_read_udta_string(MOVContext *c,
AVIOContext *pb, MOVAtom atom)
if (atom.size 0)
return AVERROR_INVALIDDATA;
-str_size = FFMIN3(sizeof(str)-1, str_size, atom.size);
-
if (parse)
parse(c, pb, str_size, key);
else {
+#define LONG_META_ALLOC() { \
+if (str_size sizeof(str_small)-1) { \
+pstr = str = av_malloc(str_size); \
+if (!pstr)\
+return AVERROR(ENOMEM); \
+} \
+}
+
if (data_type == 3 || (data_type == 0 (langcode 0x400 || langcode
== 0x7fff))) { // MAC Encoded
-mov_read_mac_string(c, pb, str_size, str, sizeof(str));
+int str_size_in = str_size;
+str_size = 1; // worst-case requirement for output string in
case of utf8 coded input
+// allocate buffer for long data field if necessary
+LONG_META_ALLOC();
+mov_read_mac_string(c, pb, str_size_in, str, str_size);
} else {
-int ret = avio_read(pb, str, str_size);
+int ret;
+// allocate buffer for long data field if necessary
+LONG_META_ALLOC();
+ret = avio_read(pb, str, str_size);
if (ret != str_size)
return ret 0 ? ret : AVERROR_INVALIDDATA;
str[str_size] = 0;
@@ -382,6 +397,8 @@ static int mov_read_udta_string(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
av_dlog(c-fc, tag \%s\ value \%s\ atom \%.4s\ %d %PRId64\n,
key, str, (char*)atom.type, str_size, atom.size);
+av_freep(pstr);
+
return 0;
}
--
Re: [FFmpeg-devel] [PATCH] matroskadec: execute seekheads recursively
On Fri, Oct 17, 2014 at 01:55:35AM -0500, Rodger Combs wrote: On Oct 17, 2014, at 01:52, Rodger Combs rodger.co...@gmail.com wrote: On Oct 17, 2014, at 01:16, Rodger Combs rodger.co...@gmail.com mailto:rodger.co...@gmail.com wrote: This fixes https://trac.ffmpeg.org/ticket/3934 https://trac.ffmpeg.org/ticket/3934, but I'm not sure if there was a good reason for this to be here to begin with. Perhaps a protection against infinite recursion (though I believe EBML_MAX_DEPTH serves that purpose to some degree)? 0001-matroskadec-execute-seekheads-recursively.patch Evidently either I or my mail client screwed up and the patch didn't get attached. Whoops. 0001-matroskadec-execute-seekheads-recursively.patch Let's try that again... Welp, apparently my email client's borked badly in some way. Here's a gist link instead: https://gist.github.com/08f111e72b8b5ddba078 copy and pasted so our archives dont depend on external links as well as for easy revieweing From 4cf14a9d117da69b64c267e6f982931cfa60a300 Mon Sep 17 00:00:00 2001 From: Rodger Combs rodger.co...@gmail.com Date: Fri, 17 Oct 2014 00:35:12 -0500 Subject: [PATCH] matroskadec: execute seekheads recursively Fixes https://trac.ffmpeg.org/ticket/3934 --- libavformat/matroskadec.c | 1 - 1 file changed, 1 deletion(-) diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c index b742319..b437e74 100644 --- a/libavformat/matroskadec.c +++ b/libavformat/matroskadec.c @@ -1368,7 +1368,6 @@ static int matroska_parse_seekhead_entry(MatroskaDemuxContext *matroska, int ret = 0; if (idx = seekhead_list-nb_elem|| -seekhead[idx].id == MATROSKA_ID_SEEKHEAD || seekhead[idx].id == MATROSKA_ID_CLUSTER) return 0; -- 1.9.1 [...] -- 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] [PATCH] gitignore: add test_copy.ffmeta
On Fri, Oct 17, 2014 at 11:50:53AM +0200, Benoit Fouet wrote: --- .gitignore | 1 + 1 file changed, 1 insertion(+) applied thanks [...] -- 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] avformat/id3v2: support buggy id3v2.3 tag length in id3v2.4
On Fri, Oct 17, 2014 at 10:56:59AM +0200, Benoit Fouet wrote: Some encoders do not use syncsafe sizes in v2.4 id3 tags. Check the next tag to try to choose between the two. Fixes ticket #4003 --- libavformat/id3v2.c | 64 +++-- 1 file changed, 62 insertions(+), 2 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: add pkg-config support for libx264
---
configure | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 3e7143c..5b16af9 100755
--- a/configure
+++ b/configure
@@ -4880,7 +4880,10 @@ enabled libvpx {
enabled libvpx_vp9_encoder { check_lib2 vpx/vpx_encoder.h vpx/vp8cx.h
vpx_codec_vp9_cx VP9E_SET_AQ_MODE -lvpx || disable libvpx_vp9_encoder; } }
enabled libwavpack require libwavpack wavpack/wavpack.h
WavpackOpenFileOutput -lwavpack
enabled libwebprequire_pkg_config libwebp = 0.2.0
webp/encode.h WebPGetEncoderVersion
-enabled libx264require libx264 x264.h x264_encoder_encode -lx264
+enabled libx264{ { check_pkg_config x264 stdint.h x264.h
x264_encoder_encode
+ require_pkg_config x264 stdint.h x264.h
x264_encoder_encode; } ||
+ { require libx264 x264.h x264_encoder_encode
-lx264
+ warn using libx264 without pkg-config; } }
{ check_cpp_condition x264.h X264_BUILD = 118
||
die ERROR: libx264 must be installed and
version must be = 0.118.; }
enabled libx265require_pkg_config x265 x265.h
x265_encoder_encode
--
2.1.2.443.g670a3c1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Allocate buffer in case of long metadata entries.
On Fri, Oct 17, 2014 at 02:33:27PM +0200, Thilo Borgmann wrote:
Am 16.10.14 04:47, schrieb Michael Niedermayer:
On Mon, Oct 13, 2014 at 09:40:42AM +0200, Thilo Borgmann wrote:
Am 11.10.14 16:19, schrieb Nicolas George:
[...]
all remarks applied.
-Thilo
mov.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
cabb6e51de7f9329603561773f209b6a948478ce
0001-lavf-mov.c-Allocate-buffer-in-case-of-long-metadata-.patch
From 5a14ef97ffc7d82dea5644c736e6dc2de2079e89 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann thilo.borgm...@mail.de
Date: Mon, 13 Oct 2014 09:36:17 +0200
Subject: [PATCH] lavf/mov.c: Allocate buffer in case of long metadata
entries.
---
libavformat/mov.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 4ff46dd..8d6d074 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -261,7 +261,9 @@ static int mov_read_udta_string(MOVContext *c,
AVIOContext *pb, MOVAtom atom)
#ifdef MOV_EXPORT_ALL_METADATA
char tmp_key[5];
#endif
-char str[1024], key2[16], language[4] = {0};
+char str_small[1024], key2[16], language[4] = {0};
+char *str = str_small;
+char *pstr = NULL;
const char *key = NULL;
uint16_t langcode = 0;
uint32_t data_type = 0, str_size;
@@ -358,13 +360,17 @@ static int mov_read_udta_string(MOVContext *c,
AVIOContext *pb, MOVAtom atom)
if (atom.size 0)
return AVERROR_INVALIDDATA;
-str_size = FFMIN3(sizeof(str)-1, str_size, atom.size);
-
if (parse)
parse(c, pb, str_size, key);
else {
+if (str_size sizeof(str_small)-1) { // allocate buffer for long
data field
+pstr = str = av_malloc(str_size);
+if (!pstr)
+return AVERROR(ENOMEM);
+}
+
if (data_type == 3 || (data_type == 0 (langcode 0x400 ||
langcode == 0x7fff))) { // MAC Encoded
-mov_read_mac_string(c, pb, str_size, str, sizeof(str));
+mov_read_mac_string(c, pb, str_size, str, str_size);
this seems to store UTF8, which can require more space than str_size
New patch attached using a worst-case size of twice the input string size if
the input is in utf8.
Tested only with non utf8 by now - I would appreciate it if someone could test
this with UTF8 metadata or tell me how to generate/where to get a suitable
file.
-Thilo
mov.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
c6706cd53f0c804d993ba5dec8112faf1b9e84e5
0001-lavf-mov.c-Allocate-buffer-in-case-of-long-metadata-.patch
From 1a59272e3d333c784e9f4857cd3aa6542ad28d6d Mon Sep 17 00:00:00 2001
From: Thilo Borgmann thilo.borgm...@mail.de
Date: Fri, 17 Oct 2014 14:30:30 +0200
Subject: [PATCH] lavf/mov.c: Allocate buffer in case of long metadata entries.
---
libavformat/mov.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 4ff46dd..a48877d 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -261,7 +261,9 @@ static int mov_read_udta_string(MOVContext *c,
AVIOContext *pb, MOVAtom atom)
#ifdef MOV_EXPORT_ALL_METADATA
char tmp_key[5];
#endif
-char str[1024], key2[16], language[4] = {0};
+char str_small[1024], key2[16], language[4] = {0};
+char *str = str_small;
+char *pstr = NULL;
const char *key = NULL;
uint16_t langcode = 0;
uint32_t data_type = 0, str_size;
@@ -358,15 +360,28 @@ static int mov_read_udta_string(MOVContext *c,
AVIOContext *pb, MOVAtom atom)
if (atom.size 0)
return AVERROR_INVALIDDATA;
-str_size = FFMIN3(sizeof(str)-1, str_size, atom.size);
-
if (parse)
parse(c, pb, str_size, key);
else {
+#define LONG_META_ALLOC() { \
+if (str_size sizeof(str_small)-1) { \
+pstr = str = av_malloc(str_size); \
+if (!pstr)\
+return AVERROR(ENOMEM); \
+} \
+}
+
if (data_type == 3 || (data_type == 0 (langcode 0x400 ||
langcode == 0x7fff))) { // MAC Encoded
-mov_read_mac_string(c, pb, str_size, str, sizeof(str));
+int str_size_in = str_size;
+str_size = 1; // worst-case requirement for output string in
case of utf8 coded input
+// allocate buffer for long data field if necessary
+LONG_META_ALLOC();
+mov_read_mac_string(c, pb, str_size_in, str, str_size);
} else {
-int ret = avio_read(pb, str, str_size);
+int ret;
+// allocate buffer for long data field if necessary
+LONG_META_ALLOC();
+ret = avio_read(pb, str, str_size);
i
Re: [FFmpeg-devel] Fix bug for POWER LE: libswscale/ppc/swscale_altivec.c
On Thu, Oct 16, 2014 at 10:48:14AM +0800, rongyan wrote:
Hi,
I created a patch to fix the bug in file libswscale/ppc/swscale_altivec.c
for POWER LE. The fixed functions including 'hScale_altivec_real()',
'yuv2planeX_16_altivec()', and 'yuv2planeX_8()'. The fate test result can be
found on http://fate.ffmpeg.org/ by search ibmcrl, also attached here to
facilitate the review:
[...]
+#if !HAVE_BIGENDIAN
+#define yuv2planeX_8(d1, d2, l1, src, x, filter) do { \
+vector signed int i1 = vec_mule(filter, l1); \
+vector signed int i2 = vec_mulo(filter, l1); \
+vector signed int vf1 = vec_mergel(i2, i1); \
+vector signed int vf2 = vec_mergeh(i2, i1); \
+d1 = vec_add(d1, vf1); \
+d2 = vec_add(d2, vf2); \
+} while (0)
+#else
#define yuv2planeX_8(d1, d2, l1, src, x, perm, filter) do { \
vector signed short l2 = vec_ld(((x) 1) + 16, src); \
vector signed short ls = vec_perm(l1, l2, perm); \
@@ -44,11 +54,49 @@
d2 = vec_add(d2, vf2); \
l1 = l2;\
} while (0)
+#endif
static void yuv2planeX_16_altivec(const int16_t *filter, int filterSize,
const int16_t **src, uint8_t *dest,
const uint8_t *dither, int offset, int x)
{
+#if !HAVE_BIGENDIAN
+register int i, j;
+DECLARE_ALIGNED(16, int, val)[16];
+vector signed int vo1, vo2, vo3, vo4;
+vector unsigned short vs1, vs2;
+vector unsigned char vf;
+vector unsigned int altivec_vectorShiftInt19 =
+vec_add(vec_splat_u32(10), vec_splat_u32(9));
+
+for (i = 0; i 16; i++)
+val[i] = dither[(x + i + offset) 7] 12;
+
+vo1 = vec_ld(0, val);
+vo2 = vec_ld(16, val);
+vo3 = vec_ld(32, val);
+vo4 = vec_ld(48, val);
+
+for (j = 0; j filterSize; j++) {
+vector signed short l1, l2, vLumFilter = vec_vsx_ld(j 1, filter);
+vLumFilter = vec_splat(vLumFilter, 0); // lumFilter[j] is loaded 8
times in vLumFilter
+
+l1 = vec_vsx_ld(x 1, src[j]);
+l2 = vec_vsx_ld(((x) 1) + 16, src[j]);
+
+yuv2planeX_8(vo1, vo2, l1, src[j], x, vLumFilter);
+yuv2planeX_8(vo3, vo4, l2, src[j], x + 8, vLumFilter);
+}
+
+vo1 = vec_sra(vo1, altivec_vectorShiftInt19);
+vo2 = vec_sra(vo2, altivec_vectorShiftInt19);
+vo3 = vec_sra(vo3, altivec_vectorShiftInt19);
+vo4 = vec_sra(vo4, altivec_vectorShiftInt19);
+vs1 = vec_packsu(vo1, vo2);
+vs2 = vec_packsu(vo3, vo4);
+vf = vec_packsu(vs1, vs2);
+vec_vsx_st(vf, 0, dest);
+#else /* else of #if !HAVE_BIGENDIAN */
register int i, j;
DECLARE_ALIGNED(16, int, val)[16];
vector signed int vo1, vo2, vo3, vo4;
code duplication, this is identical to the code in the #if
@@ -86,6 +134,7 @@ static void yuv2planeX_16_altivec(const int16_t *filter,
int filterSize,
vs2 = vec_packsu(vo3, vo4);
vf = vec_packsu(vs1, vs2);
vec_st(vf, 0, dest);
this is identical as well, except vec_st, the following avoids more
code duplication:
#if HAVE_VSX
#define VEC_ST vec_vsx_st
#else
#define VEC_ST vec_st)
#endif
similar for the other functions, please dont duplicate code
unless there is a reason
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Fw: [FFmpeg-user] How to create trapezoid videos with ffmpeg?
On Thursday, October 16, 2014 11:59 AM, Moritz Barsnick barsn...@gmx.net wrote: Hi Zenny, On Wed, Oct 15, 2014 at 10:55:40 +0200, Zenny wrote: New to ffmpeg. How can one create a trapezoid shaped video as a overlay to the background as seen at http://www.youtube.com/watch?v=_380o5B9MrA (starts at 00:02:25) using ffmpeg command? I can't seem to find a filter which does that directly, but the perspective does a similar transformation, in an inverse way. I believe it virtually pulls the given viewpoints to the corners. Using it with values pointing at viewpoints outside of the frame gives the approximate effect of what you're trying to achieve, see my example below. Interestingly, that filter smears the edges colors of the input across the rest of the output frame. (I'm not sure whether that's a bug or a feature.) Here's an example, using a test source with an overlayed outline and grid lines, to may the effect more clearly visible. It uses the SDL display driver as output to screen, but you can output to a file alternatively: ffmpeg -re -f lavfi -i testsrc,drawbox=x=1:y=1:w=iw-2:h=ih-2:t=1:c=white,drawgrid=w=iw/10:h=ih/10:t=1:c=white@0.5 -filter_complex [0:v]perspective=x0=-100:y0=-100:x2=-100:y2=H+100[ovl1]; [0:v]pad=w=iw*2[ovl0]; [ovl0][ovl1]overlay=x=W/2[vidout] -map [vidout] -pix_fmt yuv420p -f sdl - I use the -filter_complex chain to combine the original and the transformed output side-by-side. The relevant perspective filter section is: perspective=x0=-100:y0=-100:x2=-100:y2=H+100 Note the reference points _outside_ of the frame to achieve a trapezoid size reduction. The filter you are looking for should probably accept actual corner values. That said, such a filter could probably be derived from the perspective filter's code. (I failed at finding an easy way to do this though.) Moritz Ok, it seems like this should be easier. If we had a filter that did the same thing as vf_perspective but with inverse options this would be easy. So instead telling it what points you want to send to the corners, you tell it where you want the corners sent. I ran the math and the formulas to map between the two different ways of specifying the projective transformation are a bit messy. For instance, if you want to send the corners to x0:y0:x1:y1:x2:y2:x3:y3 the first option for the vf_perspective should be (W (x2 y0 - x0 y2) (x3 (y0 - y1) + x0 (y1 - y3) + x1 (-y0 + y3)) (x3 (y1 - y2) + x1 (y2 - y3) + x2 (-y1 + y3)))/(-x0 (x3^2 (y1 - y2) (-2 y1 y2 + y0 (y1 + y2)) - 2 x2 x3 y1 (y1 - y2) (y0 - y3) + x2^2 y0 (y1 - y3)^2) + x2 x3 (y0 - y1)^2 (-x3 y2 + x2 y3) + x1 (x3^2 y1 (y0 - y2)^2 + 2 x0 x3 (y1 - y2) y2 (y0 - y3) - x0^2 y1 (y2 - y3)^2 - 2 x2 (y1 - y2) (y0 - y3) (x3 y0 + x0 y3) + x2^2 (y0 - y3) (y0 (y1 - 2 y3) + y1 y3)) + x0^2 (x2 y2 (y1 - y3)^2 - x3 (y1 - y2) (2 y1 y2 - y1 y3 - y2 y3)) + x1^2 (x0 y0 (y2 - y3)^2 - x3 (y0 - y2)^2 y3 - x2 (y0 - y3) (y0 (y2 - 2 y3) + y2 y3))) not something you can put on the command line or even want to work out by hand. However, it would be totally doable to calculate in filter initialization. So is it possible to make a filter that is basically just a wrapper around another filter? This hypothetical filter (call it vf_keystone) would just call vf_perspective with crazy options. Clearly I could just copy the vf_perspective filter and then insert these changes, but than any future changes to vf_perspective wouldn't filter down to vf_keystone. Is this possible? -Nick ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hlsenc.c, segment.c: propagate defaults to mpegts
On Fri, Oct 17, 2014 at 07:28:47PM +0300, Mika Raento wrote: This fixes the abnormally high ts overhead in the files produced by the HLS and segments muxers. See https://trac.ffmpeg.org/ticket/2857 . For example makes it much more likely that it can produces streams that fit under the 64kb App store limit. --- libavformat/hlsenc.c | 10 ++ libavformat/segment.c | 1 + 2 files changed, 7 insertions(+), 4 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/5] Introduce new error codes for 4XX and 5XX replies from remote servers
---
libavutil/error.c | 6 ++
libavutil/error.h | 7 +++
2 files changed, 13 insertions(+)
diff --git a/libavutil/error.c b/libavutil/error.c
index 9be78bc..d2868ac 100644
--- a/libavutil/error.c
+++ b/libavutil/error.c
@@ -53,6 +53,12 @@ static const struct error_entry error_entries[] = {
{ ERROR_TAG(UNKNOWN),Unknown error occurred
},
{ ERROR_TAG(EXPERIMENTAL), Experimental feature
},
{ ERROR_TAG(INPUT_AND_OUTPUT_CHANGED), Input and output changed
},
+{ ERROR_TAG(HTTP_BAD_REQUEST), Server returned 400 Bad Request
},
+{ ERROR_TAG(HTTP_UNAUTHORIZED), Server returned 401 Unauthorized
(authorization failed) },
+{ ERROR_TAG(HTTP_FORBIDDEN), Server returned 403 Forbidden (access
denied) },
+{ ERROR_TAG(HTTP_NOT_FOUND), Server returned 404 Not Found
},
+{ ERROR_TAG(HTTP_OTHER_4XX), Server returned 4XX Client Error, but
not one of 40{0,1,3,4} },
+{ ERROR_TAG(HTTP_SERVER_ERROR), Server returned 5XX Server Error reply
},
};
int av_strerror(int errnum, char *errbuf, size_t errbuf_size)
diff --git a/libavutil/error.h b/libavutil/error.h
index 621279a..71df4da 100644
--- a/libavutil/error.h
+++ b/libavutil/error.h
@@ -72,6 +72,13 @@
#define AVERROR_EXPERIMENTAL (-0x2bb2afa8) /// Requested feature is
flagged experimental. Set strict_std_compliance if you really want to use it.
#define AVERROR_INPUT_CHANGED (-0x636e6701) /// Input changed between
calls. Reconfiguration is required. (can be OR-ed with AVERROR_OUTPUT_CHANGED)
#define AVERROR_OUTPUT_CHANGED (-0x636e6702) /// Output changed between
calls. Reconfiguration is required. (can be OR-ed with AVERROR_INPUT_CHANGED)
+/* HTTP RTSP errors */
+#define AVERROR_HTTP_BAD_REQUEST FFERRTAG(0xF8,'4','0','0')
+#define AVERROR_HTTP_UNAUTHORIZED FFERRTAG(0xF8,'4','0','1')
+#define AVERROR_HTTP_FORBIDDEN FFERRTAG(0xF8,'4','0','3')
+#define AVERROR_HTTP_NOT_FOUND FFERRTAG(0xF8,'4','0','4')
+#define AVERROR_HTTP_OTHER_4XX FFERRTAG(0xF8,'4','X','X')
+#define AVERROR_HTTP_SERVER_ERROR FFERRTAG(0xF8,'5','X','X')
#define AV_ERROR_MAX_STRING_SIZE 64
--
1.8.5.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/5] Introduce ff_http_averror()
int ff_http_averror(int status_code, int default_averror)
This helper function returns AVERROR_ value from 3-digit HTTP status
code.
Second argument, default_averror, is used if no specific AVERROR_ is
available. It is introduced because in different places of code
different return codes are used - -1, AVERROR(EIO), AVERROR_INVALIDDATA.
---
libavformat/http.c | 17 +
libavformat/http.h | 2 ++
2 files changed, 19 insertions(+)
diff --git a/libavformat/http.c b/libavformat/http.c
index 018d25c..1958a1b 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -272,6 +272,23 @@ int ff_http_do_new_request(URLContext *h, const char *uri)
return ret;
}
+int ff_http_averror(int status_code, int default_averror)
+{
+switch (status_code) {
+case 400: return AVERROR_HTTP_BAD_REQUEST;
+case 401: return AVERROR_HTTP_UNAUTHORIZED;
+case 403: return AVERROR_HTTP_FORBIDDEN;
+case 404: return AVERROR_HTTP_NOT_FOUND;
+default: break;
+}
+if (status_code = 400 status_code = 499)
+return AVERROR_HTTP_OTHER_4XX;
+else if (status_code = 500)
+return AVERROR_HTTP_SERVER_ERROR;
+else
+return default_averror;
+}
+
static int http_open(URLContext *h, const char *uri, int flags,
AVDictionary **options)
{
diff --git a/libavformat/http.h b/libavformat/http.h
index be8ae7f..7d02713 100644
--- a/libavformat/http.h
+++ b/libavformat/http.h
@@ -47,4 +47,6 @@ void ff_http_init_auth_state(URLContext *dest, const
URLContext *src);
*/
int ff_http_do_new_request(URLContext *h, const char *uri);
+int ff_http_averror(int status_code, int default_averror);
+
#endif /* AVFORMAT_HTTP_H */
--
1.8.5.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/5] Use ff_rtsp_averror()
---
libavformat/rtsp.c| 4 ++--
libavformat/rtspdec.c | 27 ++-
libavformat/rtspenc.c | 4 ++--
3 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 77f03ba..1682db8 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1478,7 +1478,7 @@ int ff_rtsp_make_setup_request(AVFormatContext *s, const
char *host, int port,
goto fail;
} else if (reply-status_code != RTSP_STATUS_OK ||
reply-nb_transports != 1) {
-err = AVERROR_INVALIDDATA;
+err = ff_rtsp_averror(reply-status_code, AVERROR_INVALIDDATA);
goto fail;
}
@@ -1778,7 +1778,7 @@ redirect:
sizeof(cmd));
ff_rtsp_send_cmd(s, OPTIONS, rt-control_uri, cmd, reply, NULL);
if (reply-status_code != RTSP_STATUS_OK) {
-err = AVERROR_INVALIDDATA;
+err = ff_rtsp_averror(reply-status_code, AVERROR_INVALIDDATA);
goto fail;
}
diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index cf073b3..cad8de3 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -532,7 +532,7 @@ static int rtsp_read_play(AVFormatContext *s)
}
ff_rtsp_send_cmd(s, PLAY, rt-control_uri, cmd, reply, NULL);
if (reply-status_code != RTSP_STATUS_OK) {
-return -1;
+return ff_rtsp_averror(reply-status_code, -1);
}
if (rt-transport == RTSP_TRANSPORT_RTP
reply-range_start != AV_NOPTS_VALUE) {
@@ -564,7 +564,7 @@ static int rtsp_read_pause(AVFormatContext *s)
else if (!(rt-server_type == RTSP_SERVER_REAL rt-need_subscription)) {
ff_rtsp_send_cmd(s, PAUSE, rt-control_uri, NULL, reply, NULL);
if (reply-status_code != RTSP_STATUS_OK) {
-return -1;
+return ff_rtsp_averror(reply-status_code, -1);
}
}
rt-state = RTSP_STATE_PAUSED;
@@ -591,12 +591,12 @@ int ff_rtsp_setup_input_streams(AVFormatContext *s,
RTSPMessageHeader *reply)
sizeof(cmd));
}
ff_rtsp_send_cmd(s, DESCRIBE, rt-control_uri, cmd, reply, content);
-if (!content)
-return AVERROR_INVALIDDATA;
if (reply-status_code != RTSP_STATUS_OK) {
av_freep(content);
-return AVERROR_INVALIDDATA;
+return ff_rtsp_averror(reply-status_code, AVERROR_INVALIDDATA);
}
+if (!content)
+return AVERROR_INVALIDDATA;
av_log(s, AV_LOG_VERBOSE, SDP:\n%s\n, content);
/* now we got the SDP description, we parse it */
@@ -717,10 +717,10 @@ static int rtsp_read_header(AVFormatContext *s)
if (rt-initial_pause) {
/* do not start immediately */
} else {
-if (rtsp_read_play(s) 0) {
+if ((ret = rtsp_read_play(s)) 0) {
ff_rtsp_close_streams(s);
ff_rtsp_close_connections(s);
-return AVERROR_INVALIDDATA;
+return ret;
}
}
}
@@ -814,7 +814,7 @@ retry:
ff_rtsp_send_cmd(s, SET_PARAMETER, rt-control_uri,
cmd, reply, NULL);
if (reply-status_code != RTSP_STATUS_OK)
-return AVERROR_INVALIDDATA;
+return ff_rtsp_averror(reply-status_code,
AVERROR_INVALIDDATA);
rt-need_subscription = 1;
}
}
@@ -849,7 +849,7 @@ retry:
ff_rtsp_send_cmd(s, SET_PARAMETER, rt-control_uri,
cmd, reply, NULL);
if (reply-status_code != RTSP_STATUS_OK)
-return AVERROR_INVALIDDATA;
+return ff_rtsp_averror(reply-status_code,
AVERROR_INVALIDDATA);
rt-need_subscription = 0;
if (rt-state == RTSP_STATE_STREAMING)
@@ -910,6 +910,7 @@ static int rtsp_read_seek(AVFormatContext *s, int
stream_index,
int64_t timestamp, int flags)
{
RTSPState *rt = s-priv_data;
+int ret;
rt-seek_timestamp = av_rescale_q(timestamp,
s-streams[stream_index]-time_base,
@@ -919,11 +920,11 @@ static int rtsp_read_seek(AVFormatContext *s, int
stream_index,
case RTSP_STATE_IDLE:
break;
case RTSP_STATE_STREAMING:
-if (rtsp_read_pause(s) != 0)
-return -1;
+if ((ret = rtsp_read_pause(s)) != 0)
+return ret;
rt-state = RTSP_STATE_SEEKING;
-if (rtsp_read_play(s) != 0)
-return -1;
+if ((ret = rtsp_read_play(s)) != 0)
+return ret;
break;
case RTSP_STATE_PAUSED:
rt-state = RTSP_STATE_IDLE;
diff --git a/libavformat/rtspenc.c b/libavformat/rtspenc.c
index 12fb410..e7707bb 100644
--- a/libavformat/rtspenc.c
+++ b/libavformat/rtspenc.c
@@ -84,7 +84,7 @@ int ff_rtsp_setup_output_streams(AVFormatContext *s, const
char *addr)
[FFmpeg-devel] [PATCH 3/5] Use ff_http_averror()
---
libavformat/http.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index 1958a1b..d12dcaa 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -250,7 +250,7 @@ redo:
fail:
if (s-hd)
ffurl_closep(s-hd);
-return AVERROR(EIO);
+return ff_http_averror(s-http_code, AVERROR(EIO));
}
int ff_http_do_new_request(URLContext *h, const char *uri)
@@ -371,7 +371,7 @@ static int check_http_code(URLContext *h, int http_code,
const char *end)
(http_code != 407 || s-proxy_auth_state.auth_type != HTTP_AUTH_NONE))
{
end += strspn(end, SPACE_CHARS);
av_log(h, AV_LOG_WARNING, HTTP error %d %s\n, http_code, end);
-return AVERROR(EIO);
+return ff_http_averror(http_code, AVERROR(EIO));
}
return 0;
}
@@ -1284,7 +1284,7 @@ redo:
if (s-http_code 400)
return 0;
-ret = AVERROR(EIO);
+ret = ff_http_averror(s-http_code, AVERROR(EIO));
fail:
http_proxy_close(h);
--
1.8.5.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/5] Introduce ff_rtsp_averror()
Currently this is another name for ff_http_averror()
---
libavformat/rtspcodes.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavformat/rtspcodes.h b/libavformat/rtspcodes.h
index d4ae0a8..0ae490a 100644
--- a/libavformat/rtspcodes.h
+++ b/libavformat/rtspcodes.h
@@ -25,6 +25,7 @@
#define AVFORMAT_RTSPCODES_H
#include libavutil/common.h
+#include libavformat/http.h
/** RTSP handling */
enum RTSPStatusCode {
@@ -139,4 +140,10 @@ enum RTSPMethod {
RECORD,
UNKNOWN = -1,
};
+
+static inline int ff_rtsp_averror(enum RTSPStatusCode status_code, int
default_averror)
+{
+return ff_http_averror(status_code, default_averror);
+}
+
#endif /* AVFORMAT_RTSPCODES_H */
--
1.8.5.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-user] How to create trapezoid videos with ffmpeg?
On Friday, October 17, 2014 2:30 PM, Nicholas Robbins nickrobb...@yahoo.com wrote: snip actual request Ok, it seems like this should be easier. If we had a filter that did the same thing as vf_perspective but with inverse options this would be easy. So instead telling it what points you want to send to the corners, you tell it where you want the corners sent. I ran the math and the formulas to map between the two different ways of specifying the projective transformation are a bit messy. For instance, if you want to send the corners to x0:y0:x1:y1:x2:y2:x3:y3 the first option for the vf_perspective should be snip messy formula not something you can put on the command line or even want to work out by hand. However, it would be totally doable to calculate in filter initialization. So is it possible to make a filter that is basically just a wrapper around another filter? This hypothetical filter (call it vf_keystone) would just call vf_perspective with crazy options. Clearly I could just copy the vf_perspective filter and then insert these changes, but than any future changes to vf_perspective wouldn't filter down to vf_keystone. Is this possible? -Nick Upon further thought and a closer read of the vf_perspective code, I think an easier option would be to insert an option of sense or mode or something. Then condition the code at lines 144-160 (these lines calculate the matrix used for the transformation) and then put in another block conditioned on the mode that finds the inverse matrix rather than the matrix currently found. Is this a reasonable approach? If so, I think I'll put this in in a little while. -Nick ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/5] Add HTTP/RTSP specific AVERROR codes
On Sat, Oct 18, 2014 at 1:19 AM, Carl Eugen Hoyos ceho...@ag.or.at wrote: Andrey Utkin andrey.utkin at corp.bluecherry.net writes: Any comments and testing are appreciated. I have made a little amount of testing, but RTSP, HTTP and HTTPS 401 and 404 work as expected. Is the patchset related to ticket #4039? If yes, please mention it. No, it is not related. Primarily I care about error codes application gets from av_read_frame(). -- Bluecherry developer. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] matroskadec: execute seekheads recursively
On Fri, Oct 17, 2014 at 03:27:49PM +0200, Michael Niedermayer wrote: On Fri, Oct 17, 2014 at 01:55:35AM -0500, Rodger Combs wrote: On Oct 17, 2014, at 01:52, Rodger Combs rodger.co...@gmail.com wrote: On Oct 17, 2014, at 01:16, Rodger Combs rodger.co...@gmail.com mailto:rodger.co...@gmail.com wrote: This fixes https://trac.ffmpeg.org/ticket/3934 https://trac.ffmpeg.org/ticket/3934, but I'm not sure if there was a good reason for this to be here to begin with. Perhaps a protection against infinite recursion (though I believe EBML_MAX_DEPTH serves that purpose to some degree)? 0001-matroskadec-execute-seekheads-recursively.patch Evidently either I or my mail client screwed up and the patch didn't get attached. Whoops. 0001-matroskadec-execute-seekheads-recursively.patch Let's try that again... Welp, apparently my email client's borked badly in some way. Here's a gist link instead: https://gist.github.com/08f111e72b8b5ddba078 copy and pasted so our archives dont depend on external links as well as for easy revieweing From 4cf14a9d117da69b64c267e6f982931cfa60a300 Mon Sep 17 00:00:00 2001 From: Rodger Combs rodger.co...@gmail.com Date: Fri, 17 Oct 2014 00:35:12 -0500 Subject: [PATCH] matroskadec: execute seekheads recursively Fixes https://trac.ffmpeg.org/ticket/3934 --- libavformat/matroskadec.c | 1 - 1 file changed, 1 deletion(-) diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c index b742319..b437e74 100644 --- a/libavformat/matroskadec.c +++ b/libavformat/matroskadec.c @@ -1368,7 +1368,6 @@ static int matroska_parse_seekhead_entry(MatroskaDemuxContext *matroska, int ret = 0; if (idx = seekhead_list-nb_elem|| -seekhead[idx].id == MATROSKA_ID_SEEKHEAD || seekhead[idx].id == MATROSKA_ID_CLUSTER) return 0; ebml_parse() that gets called as a result of this change does not succeed and causes the one and only seekhead entry to return failure so i think this doesnt execute seekheads recursively [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-user] How to create trapezoid videos with ffmpeg?
On Fri, Oct 17, 2014 at 02:09:49PM -0700, Nicholas Robbins wrote: On Friday, October 17, 2014 2:30 PM, Nicholas Robbins nickrobb...@yahoo.com wrote: snip actual request Ok, it seems like this should be easier. If we had a filter that did the same thing as vf_perspective but with inverse options this would be easy. So instead telling it what points you want to send to the corners, you tell it where you want the corners sent. I ran the math and the formulas to map between the two different ways of specifying the projective transformation are a bit messy. For instance, if you want to send the corners to x0:y0:x1:y1:x2:y2:x3:y3 the first option for the vf_perspective should be snip messy formula not something you can put on the command line or even want to work out by hand. However, it would be totally doable to calculate in filter initialization. So is it possible to make a filter that is basically just a wrapper around another filter? This hypothetical filter (call it vf_keystone) would just call vf_perspective with crazy options. Clearly I could just copy the vf_perspective filter and then insert these changes, but than any future changes to vf_perspective wouldn't filter down to vf_keystone. Is this possible? -Nick Upon further thought and a closer read of the vf_perspective code, I think an easier option would be to insert an option of sense or mode or something. Then condition the code at lines 144-160 (these lines calculate the matrix used for the transformation) and then put in another block conditioned on the mode that finds the inverse matrix rather than the matrix currently found. Is this a reasonable approach? If so, I think I'll put this in in a little while. yes, thats an option too [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add support for Opus in MPEG-TS
---
libavcodec/opus.c| 11 +---
libavcodec/opus.h|9 +++
libavcodec/opus_parser.c | 139 +-
libavformat/mpegts.c | 54 +-
4 files changed, 191 insertions(+), 22 deletions(-)
diff --git a/libavcodec/opus.c b/libavcodec/opus.c
index 91021ce..1bc417b 100644
--- a/libavcodec/opus.c
+++ b/libavcodec/opus.c
@@ -290,10 +290,6 @@ av_cold int ff_opus_parse_extradata(AVCodecContext *avctx,
OpusContext *s)
{
static const uint8_t default_channel_map[2] = { 0, 1 };
-uint8_t default_extradata[19] = {
-'O', 'p', 'u', 's', 'H', 'e', 'a', 'd',
-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-};
int (*channel_reorder)(int, int) = channel_reorder_unknown;
@@ -308,9 +304,8 @@ av_cold int ff_opus_parse_extradata(AVCodecContext *avctx,
Multichannel configuration without extradata.\n);
return AVERROR(EINVAL);
}
-default_extradata[9] = (avctx-channels == 1) ? 1 : 2;
-extradata = default_extradata;
-extradata_size = sizeof(default_extradata);
+extradata = opus_default_extradata;
+extradata_size = sizeof(opus_default_extradata);
} else {
extradata = avctx-extradata;
extradata_size = avctx-extradata_size;
@@ -330,7 +325,7 @@ av_cold int ff_opus_parse_extradata(AVCodecContext *avctx,
avctx-delay = AV_RL16(extradata + 10);
-channels = extradata[9];
+channels = avctx-extradata ? extradata[9] : (avctx-channels == 1) ? 1 :
2;
if (!channels) {
av_log(avctx, AV_LOG_ERROR, Zero channel count specified in the
extadata\n);
return AVERROR_INVALIDDATA;
diff --git a/libavcodec/opus.h b/libavcodec/opus.h
index c2fac06..94993d6 100644
--- a/libavcodec/opus.h
+++ b/libavcodec/opus.h
@@ -61,6 +61,15 @@
#define ROUND_MUL16(a,b) ((MUL16(a, b) + 16384) 15)
#define opus_ilog(i) (av_log2(i) + !!(i))
+#define OPUS_TS_HEADER 0x7FE0// 0x3ff (11 bits)
+#define OPUS_TS_MASK 0xFFE0// top 11 bits
+
+static const uint8_t opus_default_extradata[30] = {
+'O', 'p', 'u', 's', 'H', 'e', 'a', 'd',
+1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+};
+
enum OpusMode {
OPUS_MODE_SILK,
OPUS_MODE_HYBRID,
diff --git a/libavcodec/opus_parser.c b/libavcodec/opus_parser.c
index 8a2bc22..3ef3558 100644
--- a/libavcodec/opus_parser.c
+++ b/libavcodec/opus_parser.c
@@ -27,49 +27,162 @@
#include avcodec.h
#include opus.h
+#include parser.h
+#include bytestream.h
typedef struct OpusParseContext {
OpusContext ctx;
OpusPacket pkt;
int extradata_parsed;
+ParseContext pc;
+int ts_framing;
} OpusParseContext;
-static int opus_parse(AVCodecParserContext *ctx, AVCodecContext *avctx,
- const uint8_t **poutbuf, int *poutbuf_size,
- const uint8_t *buf, int buf_size)
+static const uint8_t *parse_opus_ts_header(const uint8_t *start, int
*payload_len, int buf_len)
+{
+const uint8_t *buf = start + 1;
+int start_trim_flag, end_trim_flag, control_extension_flag,
control_extension_length, i;
+uint8_t flags;
+
+GetByteContext gb;
+bytestream2_init(gb, buf, buf_len);
+
+flags = bytestream2_get_byte(gb);
+start_trim_flag= (flags 4) 1;
+end_trim_flag = (flags 3) 1;
+control_extension_flag = (flags 2) 1;
+
+*payload_len = 0;
+while (bytestream2_peek_byte(gb) == 0xff)
+*payload_len += bytestream2_get_byte(gb);
+
+*payload_len += bytestream2_get_byte(gb);
+
+if (start_trim_flag)
+bytestream2_skip(gb, 2);
+if (end_trim_flag)
+bytestream2_skip(gb, 2);
+if (control_extension_flag) {
+control_extension_length = bytestream2_get_byte(gb);
+bytestream2_skip(gb, control_extension_length);
+}
+
+return buf + bytestream2_tell(gb);
+}
+
+/**
+ * Find the end of the current frame in the bitstream.
+ * @return the position of the first byte of the next frame, or -1
+ */
+static int opus_find_frame_end(AVCodecParserContext *ctx, AVCodecContext
*avctx,
+ const uint8_t *buf, int buf_size, int
*header_len)
{
OpusParseContext *s = ctx-priv_data;
-int ret;
+ParseContext *pc= s-pc;
+int ret, start_found, i = 0, payload_len = 0;
+const uint8_t *payload;
+uint32_t state;
+uint16_t hdr;
+*header_len = 0;
if (!buf_size)
return 0;
+start_found = pc-frame_start_found;
+state = pc-state;
+payload = buf;
+
+/* Check if we're using Opus in MPEG-TS framing */
+if (!s-ts_framing buf_size 2) {
+hdr = AV_RB16(buf);
+if ((hdr OPUS_TS_MASK) == OPUS_TS_HEADER)
+s-ts_framing = 1;
+}
+
+if (s-ts_framing !start_found) {
+for (i = 0; i buf_size-2; i++) {
+state = (state 8) | payload[i];
+
Re: [FFmpeg-devel] [PATCHv2] ffplay: update documentation
On Sat, Oct 18, 2014 at 01:22:03AM +0200, Marton Balint wrote: On Thu, 16 Oct 2014, Lou Logan wrote: On Wed, 15 Oct 2014 23:46:21 +0200, Marton Balint wrote: Thank you for all your feedback, apparently there was some confusion because I have used set both as a synonym to enabled and as an imperative. I have changed all occurences of it to enabled or use, so hopefully it will be more clear now. I have also done minor modifications in the text mostly based on your comments. Here is v2 of the patch. --- Signed-off-by: Marton Balint c...@passwd.hu --- doc/ffplay.texi | 26 -- 1 file changed, 20 insertions(+), 6 deletions(-) Docs LGTM. Hi Michael, Please merge from my stable branch for this patch and the rest of the pending ffplay patches: 9dac797 ffplay: remove delays when paused from video and subtitle thread 0edf3e7 ffplay: remove manual bug option handling code 2c4d6a3 ffplay: update documentation merged thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: add pkg-config support for libx264
Benoit Fouet benoit.fouet at free.fr writes:
+enabled libx264{ { check_pkg_config x264 stdint.h x264.h
x264_encoder_encode
+ require_pkg_config x264 stdint.h
x264.h x264_encoder_encode; } ||
+ { require libx264 x264.h
x264_encoder_encode -lx264
No objections from me.
(Works fine here.)
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: add pkg-config support for libx264
Benoit Fouet benoit.fouet at free.fr writes:
+enabled libx264{ { check_pkg_config x264
I forgot:
You could add a line to the Changelog pkg-config is now
preferred over --extra-*flags for x264 detection.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: add pkg-config support for libx264
On 17/10/14 8:49 PM, Carl Eugen Hoyos wrote:
Benoit Fouet benoit.fouet at free.fr writes:
+enabled libx264{ { check_pkg_config x264
I forgot:
You could add a line to the Changelog pkg-config is now
preferred over --extra-*flags for x264 detection.
No need to mention it's preferred over anything (especially when --extra-cflags
wasn't even necessary in 99% of cases and only a small portion of users ever
needed to use that).
A line saying something like x264 may now also be detected with pkg-config is
enough.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: add pkg-config support for libx264
James Almer jamrial at gmail.com writes: You could add a line to the Changelog pkg-config is now preferred over --extra-*flags for x264 detection. A line saying something like x264 may now also be detected with pkg-config is enough. I disagree (this would be the change that I originally suggested) but it is not that important. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch for Cast128 algorithm implementation
On Sat, Oct 18, 2014 at 12:00:28AM +0530, supraja reddy wrote: Hello , Updated the changes in the patch . Please let me know if any further changes required . [...] Changelog|1 libavutil/Makefile |3 libavutil/cast5.c| 541 +++ libavutil/cast5.h| 67 + tests/fate/libavutil.mak |5 5 files changed, 617 insertions(+) 411c2b7394c93b909648890e5e97bda2b5a13077 0001-add-cipher.patch From b542575061026d918ef3cb9ab5b9dfb9aeb6a6e5 Mon Sep 17 00:00:00 2001 From: Supraja Meedinti supraja0...@gmail.com Date: Fri, 17 Oct 2014 23:52:25 +0530 Subject: [PATCH] libavutil: Add CAST128 symmetric block cipher Only ECB mode is supported at the moment Signed-off-by: Supraja Meedinti supraja0...@gmail.com --- Changelog| 1 + libavutil/Makefile | 3 + libavutil/cast5.c| 541 +++ libavutil/cast5.h| 67 ++ tests/fate/libavutil.mak | 5 + 5 files changed, 617 insertions(+) create mode 100644 libavutil/cast5.c create mode 100644 libavutil/cast5.h patch applied thanks [...] -- 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] configure: add pkg-config support for libx264
On Fri, Oct 17, 2014 at 11:48:12PM +, Carl Eugen Hoyos wrote:
Benoit Fouet benoit.fouet at free.fr writes:
+enabled libx264{ { check_pkg_config x264 stdint.h x264.h
x264_encoder_encode
+ require_pkg_config x264 stdint.h
x264.h x264_encoder_encode; } ||
+ { require libx264 x264.h
x264_encoder_encode -lx264
No objections from me.
(Works fine here.)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
