Re: [FFmpeg-devel] [PATCH] avutil/motion_vector.h: fix coordinate types
On Thu, Aug 21, 2014 at 07:34:50AM +0200, Clément Bœsch wrote: On Thu, Aug 21, 2014 at 12:01:51AM +0200, Michael Niedermayer wrote: On Wed, Aug 20, 2014 at 11:30:27PM +0200, Clément Bœsch wrote: --- doc/APIchanges| 2 +- libavutil/motion_vector.h | 8 libavutil/version.h | 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/doc/APIchanges b/doc/APIchanges index 1bed107..1fbeb09 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -15,7 +15,7 @@ libavutil: 2014-08-09 API changes, most recent first: -2014-08-xx - xxx - lavu 54.5.100 - frame.h motion_vector.h +2014-08-xx - b0352b1,xxx - lavu 54.6.100 - frame.h motion_vector.h what is b0352b1,xxx ? b0352b1 is the main commit, at 54.5.100 xxx would be this fixup commit, at 54.6.100 We wouldn't really want the users to use the feature in 54.5.100 because of the bug I'm fixing, but b0352b1 - lavu 54.6.100 would leave a version inconsistency. And OTOH referencing only the new hash doesn't give much insight on the feature/change mentioned. One solution could be to clearly reference b0352b1 into the new commit, and make sure we reference the new hash in the 54.6 in APIChanges. Would that be fine? [...] -- Clément B. pgpRD2cNqrdK4.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Filters
On Mon, Aug 18, 2014 at 06:51:41PM +0100, JULIAN GARDNER wrote: [...] Thanks for this, its 99% what i need apart from I lose the audio on the [vid] output. I want the small picture [160x100] output without audio and the 640x360 output with audio Commandlineffmpeg -threads 0 -i udp://231.231.11.3:1234?localaddr=192.168.2.123 -filter_complex 'scale=iw/2:ih/2,split [mark], scale=160:90,drawbox=10:10:5:5:color=red [detect];[mark] drawbox=10:10:10:5:5:color=blue [vid]' -map [detect] -vcodec libx264 -preset faster -x264opts keyint=75 -x264opts bitrate=512 -bufsize 1M -r 25 -an -f mpegts udp://238.170.112.96:1234?pkt_size=1316buffer_size=1048576 -map [vid][0:a] -vcodec libx264 -preset faster -x264opts keyint=75 -x264opts bitrate=1150 -bufsize 1M -r 25 -acodec libfaac -ab 128k -ar 32k -ac 2 -f mpegts udp://225.170.112.96:1234?pkt_size=1316buffer_size=1048576 Please suggest improvements in the documentation if this is not obvious, but -map [vid][0:a] is not valid. Try -map [vid] -map [0:a]. [...] -- Clément B. pgp6ap5AXktCd.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_lenscorrection: get rid of floats i init code
--- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 20, 2014, at 4:20 PM, Michael Niedermayer michae...@gmx.at wrote: On Wed, Aug 20, 2014 at 03:48:39PM +0200, Daniel Oberhoff wrote: --- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 20, 2014, at 3:11 PM, Michael Niedermayer michae...@gmx.at wrote: On Wed, Aug 20, 2014 at 02:58:50PM +0200, Daniel Oberhoff wrote: --- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 20, 2014, at 2:55 PM, Michael Niedermayer michae...@gmx.at wrote: On Wed, Aug 20, 2014 at 02:36:29PM +0200, Daniel Oberhoff wrote: --- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 20, 2014, at 2:33 PM, Michael Niedermayer michae...@gmx.at wrote: On Wed, Aug 20, 2014 at 02:23:10PM +0200, Daniel Oberhoff wrote: So we prefer int64_t above float32? well, its not exactly making me happy either but its just 2 32x32-64 operations per pixel which shouldnt be that bad when we need to do 16 multiplications for bicubic per sample also at the expense of a bit more space they could be precalculated as they dont change between frames I assumed we stick with 32bits for calculations. Did you test this with very large resolutions? just tried: ./ffplay -f lavfi -i testsrc=s=16385x8192 -vf lenscorrection=0.3:0.2:0.2:0.9,scale=640x48 which seems working I so congratulation :). I am glad I could push you to finish what I failed to do :). As I would still like to have interpolation, I assume I shall refactor the interpolation out of perspective and rotation instead, right? Ok, but by default I would only refactor so far as to support all use cases currently in perspective/rotate/lens_correction, and none more. sure Do you still think there should be a version/versions of the algorithm for packed formats? i think if we want to add gamma correct interpolation then yes otherwise its probably not worth the work to be honest: I have no idea about that, do you have pointers for that? I.e. what it is, how it works, when it is needed, how it correlates with the image representation (i.e. yuv vs rgb, compressed vs full, etc)? its very simple normal every day 8bit per sample rgb and yuv are not linear, in the sense that twice the number of photons does not equal twice the integer value for , lets say red or y but interpolation, be that bilinear or bicubic assumes that it is so so it would be needed to first get linear rgb (which needs more than 8bits per sample to look good) then interpolate in that and then to convert back to everyday gamma corrected 8bit per sample rgb in principle these correction steps could be done by seperate filters and RGB48 could be used in vf_lenscorrection then vf_lenscorrection would not need to know about any of that Right, so by supporting rgb48 that would be effectively supported. Sounds ok to me for the time being as workaround for high quality operation. yes, theoretically in practice we might need something to make it convenient to be used requiring the user the manually insert some kind of gamma correction filter before and afterwards is a bit inconvenient Hey, are you going to push this? Could then start a new resampling patch tomorrow. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/motion_vector.h: fix coordinate types
On Thu, Aug 21, 2014 at 09:32:29AM +0200, Clément Bœsch wrote: On Thu, Aug 21, 2014 at 07:34:50AM +0200, Clément Bœsch wrote: On Thu, Aug 21, 2014 at 12:01:51AM +0200, Michael Niedermayer wrote: On Wed, Aug 20, 2014 at 11:30:27PM +0200, Clément Bœsch wrote: --- doc/APIchanges| 2 +- libavutil/motion_vector.h | 8 libavutil/version.h | 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/doc/APIchanges b/doc/APIchanges index 1bed107..1fbeb09 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -15,7 +15,7 @@ libavutil: 2014-08-09 API changes, most recent first: -2014-08-xx - xxx - lavu 54.5.100 - frame.h motion_vector.h +2014-08-xx - b0352b1,xxx - lavu 54.6.100 - frame.h motion_vector.h what is b0352b1,xxx ? b0352b1 is the main commit, at 54.5.100 xxx would be this fixup commit, at 54.6.100 We wouldn't really want the users to use the feature in 54.5.100 because of the bug I'm fixing, but b0352b1 - lavu 54.6.100 would leave a version inconsistency. And OTOH referencing only the new hash doesn't give much insight on the feature/change mentioned. One solution could be to clearly reference b0352b1 into the new commit, and make sure we reference the new hash in the 54.6 in APIChanges. Would that be fine? yes also to clarify what my concern was, it was for that listing 2 hashes equally is confusing to a reader, we often have 2 hashes where one is from libav and one fro ffmpeg but i think this variant is new. Also it could scripts [...] -- 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
Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_lenscorrection: get rid of floats i init code
On Thu, Aug 21, 2014 at 10:41:57AM +0200, Daniel Oberhoff wrote: --- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 20, 2014, at 4:20 PM, Michael Niedermayer michae...@gmx.at wrote: On Wed, Aug 20, 2014 at 03:48:39PM +0200, Daniel Oberhoff wrote: --- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 20, 2014, at 3:11 PM, Michael Niedermayer michae...@gmx.at wrote: On Wed, Aug 20, 2014 at 02:58:50PM +0200, Daniel Oberhoff wrote: --- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 20, 2014, at 2:55 PM, Michael Niedermayer michae...@gmx.at wrote: On Wed, Aug 20, 2014 at 02:36:29PM +0200, Daniel Oberhoff wrote: --- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 20, 2014, at 2:33 PM, Michael Niedermayer michae...@gmx.at wrote: On Wed, Aug 20, 2014 at 02:23:10PM +0200, Daniel Oberhoff wrote: So we prefer int64_t above float32? well, its not exactly making me happy either but its just 2 32x32-64 operations per pixel which shouldnt be that bad when we need to do 16 multiplications for bicubic per sample also at the expense of a bit more space they could be precalculated as they dont change between frames I assumed we stick with 32bits for calculations. Did you test this with very large resolutions? just tried: ./ffplay -f lavfi -i testsrc=s=16385x8192 -vf lenscorrection=0.3:0.2:0.2:0.9,scale=640x48 which seems working I so congratulation :). I am glad I could push you to finish what I failed to do :). As I would still like to have interpolation, I assume I shall refactor the interpolation out of perspective and rotation instead, right? Ok, but by default I would only refactor so far as to support all use cases currently in perspective/rotate/lens_correction, and none more. sure Do you still think there should be a version/versions of the algorithm for packed formats? i think if we want to add gamma correct interpolation then yes otherwise its probably not worth the work to be honest: I have no idea about that, do you have pointers for that? I.e. what it is, how it works, when it is needed, how it correlates with the image representation (i.e. yuv vs rgb, compressed vs full, etc)? its very simple normal every day 8bit per sample rgb and yuv are not linear, in the sense that twice the number of photons does not equal twice the integer value for , lets say red or y but interpolation, be that bilinear or bicubic assumes that it is so so it would be needed to first get linear rgb (which needs more than 8bits per sample to look good) then interpolate in that and then to convert back to everyday gamma corrected 8bit per sample rgb in principle these correction steps could be done by seperate filters and RGB48 could be used in vf_lenscorrection then vf_lenscorrection would not need to know about any of that Right, so by supporting rgb48 that would be effectively supported. Sounds ok to me for the time being as workaround for high quality operation. yes, theoretically in practice we might need something to make it convenient to be used requiring the user the manually insert some kind of gamma correction filter before and afterwards is a bit inconvenient Hey, are you going to push this? Could then start a new resampling patch tomorrow. pushed, sorry you didnt say clearly they are ok and you are maitainer so i would have waited a day or 2 before pushing Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] mpegts: support ARIB subtitles in libavformat
Hello, I added support of ARIB subtitles to mpegts in libavformat. Regards, Tsukasa. 0001-mpegts-support-ARIB-subtitles-in-libavformat.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpegts: support ARIB subtitles in libavformat
Tsukasa OMOTO henry0312 at gmail.com writes: I added support of ARIB subtitles to mpegts in libavformat. Shouldn't you add ARIB to DESC_types[]? Could you provide samples for both types? (Ideally even for all stream_identifiers but I guess this isn't possible.) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/motion_vector.h: fix coordinate types
On Thu, Aug 21, 2014 at 11:42:53AM +0200, Michael Niedermayer wrote: On Thu, Aug 21, 2014 at 09:32:29AM +0200, Clément Bœsch wrote: On Thu, Aug 21, 2014 at 07:34:50AM +0200, Clément Bœsch wrote: On Thu, Aug 21, 2014 at 12:01:51AM +0200, Michael Niedermayer wrote: On Wed, Aug 20, 2014 at 11:30:27PM +0200, Clément Bœsch wrote: --- doc/APIchanges| 2 +- libavutil/motion_vector.h | 8 libavutil/version.h | 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/doc/APIchanges b/doc/APIchanges index 1bed107..1fbeb09 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -15,7 +15,7 @@ libavutil: 2014-08-09 API changes, most recent first: -2014-08-xx - xxx - lavu 54.5.100 - frame.h motion_vector.h +2014-08-xx - b0352b1,xxx - lavu 54.6.100 - frame.h motion_vector.h what is b0352b1,xxx ? b0352b1 is the main commit, at 54.5.100 xxx would be this fixup commit, at 54.6.100 We wouldn't really want the users to use the feature in 54.5.100 because of the bug I'm fixing, but b0352b1 - lavu 54.6.100 would leave a version inconsistency. And OTOH referencing only the new hash doesn't give much insight on the feature/change mentioned. One solution could be to clearly reference b0352b1 into the new commit, and make sure we reference the new hash in the 54.6 in APIChanges. Would that be fine? yes Thanks, applied also to clarify what my concern was, it was for that listing 2 hashes equally is confusing to a reader, we often have 2 hashes where one is from libav and one fro ffmpeg but i think this variant is new. Also it could scripts [...] -- Clément B. pgp_wR_cPUr7b.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_lenscorrection: add assert to ensure there are not more planes than the correction array is large
--- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 21, 2014, at 12:34 PM, Michael Niedermayer michae...@gmx.at wrote: Exceeding the count would write out of array, and should not occur with any current pixel format Signed-off-by: Michael Niedermayer michae...@gmx.at --- libavfilter/vf_lenscorrection.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/libavfilter/vf_lenscorrection.c b/libavfilter/vf_lenscorrection.c index 58184b0..01380fc 100644 --- a/libavfilter/vf_lenscorrection.c +++ b/libavfilter/vf_lenscorrection.c @@ -26,6 +26,7 @@ #include stdlib.h #include math.h +#include libavutil/avassert.h #include libavutil/opt.h #include libavutil/intreadwrite.h #include libavutil/pixdesc.h @@ -132,6 +133,8 @@ static int config_props(AVFilterLink *outlink) outlink-w = rect-width = inlink-w; outlink-h = rect-height = inlink-h; rect-nb_planes = av_pix_fmt_count_planes(inlink-format); +av_assert0(rect-nb_planes = FF_ARRAY_ELEMS(rect-correction)); how many planes can there ever be? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Fail in h264 nal unit decoding if slice header decoding failed
Hi!
Attached patch fixes ticket #3873 here, I don't know if it has any
unexpected side-effects.
Please review, Carl Eugen
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 389307b..2b299bc 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -1585,8 +1585,11 @@ again:
hx-inter_gb_ptr = hx-gb;
hx-data_partitioning = 0;
-if ((err = ff_h264_decode_slice_header(hx, h)))
+if ((err = ff_h264_decode_slice_header(hx, h)) 0) {
+goto end;
+} else if (err) {
break;
+}
if (h-sei_recovery_frame_cnt = 0) {
if (h-frame_num != h-sei_recovery_frame_cnt ||
hx-slice_type_nos != AV_PICTURE_TYPE_I)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] mov: better check dref atome validity
Hi, the fuzzed file from ticket #3866 somehow ends on reading a dref atom, where a size element is not validated. The reading then skips that arbitrary amount without reporting an issue. I'm not sure it is the best fix, but I don't think this could happen in any valid file, nor it would help to swallow the error. -- Christophe From dacdd50379af1bcb3dab2ce813124cfc577adace Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq...@gmail.com Date: Thu, 21 Aug 2014 12:59:10 +0200 Subject: [PATCH] mov: better check dref atome validity The size of each entry helps determining whether it would cause overreads and thus if this size, and the atom, is valid. Should fix ticket #3866. --- libavformat/mov.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index 1255824..586fcd0 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -423,6 +423,7 @@ static int mov_read_dref(MOVContext *c, AVIOContext *pb, MOVAtom atom) AVStream *st; MOVStreamContext *sc; int entries, i, j; +int64_t end = avio_tell(pb) + atom.size; if (c-fc-nb_streams 1) return 0; @@ -446,7 +447,7 @@ static int mov_read_dref(MOVContext *c, AVIOContext *pb, MOVAtom atom) uint32_t size = avio_rb32(pb); int64_t next = avio_tell(pb) + size - 4; -if (size 12) +if (size 12 || next end) return AVERROR_INVALIDDATA; dref-type = avio_rl32(pb); -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] mark null encoder as ts-nonstrict , avoids error messages for null output
https://gist.github.com/anonymous/0e26f490ec13d67996fd
commit e94a44543a96b13aa6a23efce2f0378a5479d530
Author: Rodger Combs rodger.co...@gmail.com
Date: Wed Aug 20 15:38:12 2014 -0700
avformat/nullenc: mark null as timestamp-nonstrict
This avoids unnecessary error messages for null output
diff --git a/libavformat/nullenc.c b/libavformat/nullenc.c
index 7c08c39..58b88a1 100644
--- a/libavformat/nullenc.c
+++ b/libavformat/nullenc.c
@@ -32,5 +32,5 @@ AVOutputFormat ff_null_muxer = {
.audio_codec = AV_NE(AV_CODEC_ID_PCM_S16BE, AV_CODEC_ID_PCM_S16LE),
.video_codec = AV_CODEC_ID_RAWVIDEO,
.write_packet = null_write_packet,
-.flags = AVFMT_VARIABLE_FPS | AVFMT_NOFILE |
AVFMT_NOTIMESTAMPS | AVFMT_RAWPICTURE,
+.flags = AVFMT_TS_NONSTRICT | AVFMT_VARIABLE_FPS |
AVFMT_NOFILE | AVFMT_NOTIMESTAMPS | AVFMT_RAWPICTURE,
};
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpegts: support ARIB subtitles in libavformat
On Thu, 21 Aug 2014 10:26:18 + (UTC) Carl Eugen Hoyos ceho...@ag.or.at wrote: Could you provide samples for both types? uploaded to incoming/private-aribu_sub_sample.ts -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] build: rely on pkg-config for libx264 probing
On Thu, Aug 21, 2014 at 11:23:41AM +, Carl Eugen Hoyos wrote: Clément Bœsch u at pkh.me writes: I thought the purpose is to allow educated developers to use pkg-config while (uneducated) users (like me) will not understand how this is easier than using configure parameters. Yes, it's also simpler for the users. Please understand that we disagree on this point. (It makes no difference though, I already accepted that some developers need pkg-config for x264, opus and hevc.) They will also almost never be tested, I will care about the testing. Well, you probably won't test static linking of random libs on various platforms typically. If you don't allow testing this on your fate client, I will have to take care. It's a generic linux, it would only cover a very limited usecase. If you want to test this properly you'd have to: - create multiple builds of the target library with different compilation flags (for x264 that would mean with or without opencl for example) - follow that project to look for any potential new library dependency addition - test with static and shared - test with minimal other dependencies in the build (because other places could add a linker flag or something that happen to actually be a dep you forgot) ; this mean an instance per library check - test on different plateform, where the linkers behave differently Are you willing to do that or... pkg-config makes possible to completely ignore that part since it moves the responsibility away from us. Completely apart from the fact that we already know this doesn't work, I still consider it an undesired change of behaviour. ...simply trust the project delivering the .pc? That said, if you want to support a fallback as I suggested above, it won't work as you expect: I feel that all this only supports my point that we should not rely on pkg-config. No, it shows that the hack is not reliable and never will. But since you insist, let's ignore the unavoidable problems, just make sure that a user who (already) knows about --extra-cflags and --extra-ldflags and remembers how he custom-compiled his library still has a chance to compile FFmpeg with the library even if he does not want to rely on pkg-config. We can't keep the current behaviour. We will need the users to add yet another option flag for this, probably in addition to a --pkg-config=/bin/false Basically, it will require them to change: --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/lib Into: --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/locallib --disable-pkg-config-detection (Yes, we want to make a distinction with --pkg-config=false) Or if they're going to change their command line anyway, they could just do: PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ./configure ...and we wouldn't have to deal with such stupid hack. If the build system chooses the wrong one of two working libraries, this is the user's problem. What I try to avoid is just that the user installs a second version of the library because the system library doesn't work but cannot select it because the configure script blindly trusts the pkg-config return value. He can select it through PKG_CONFIG_PATH instead of --extra-* options. No difference here. As I said several times, we can be more verbose about the pkg-config process; I don't mind sending a patch to print debug the detection process, like which libs with which flags is getting selected. [...] -- Clément B. pgpKFtKhB0rj9.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_lenscorrection: add assert to ensure there are not more planes than the correction array is large
On Thu, Aug 21, 2014 at 12:57:08PM +0200, Daniel Oberhoff wrote: --- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 21, 2014, at 12:34 PM, Michael Niedermayer michae...@gmx.at wrote: Exceeding the count would write out of array, and should not occur with any current pixel format Signed-off-by: Michael Niedermayer michae...@gmx.at --- libavfilter/vf_lenscorrection.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/libavfilter/vf_lenscorrection.c b/libavfilter/vf_lenscorrection.c index 58184b0..01380fc 100644 --- a/libavfilter/vf_lenscorrection.c +++ b/libavfilter/vf_lenscorrection.c @@ -26,6 +26,7 @@ #include stdlib.h #include math.h +#include libavutil/avassert.h #include libavutil/opt.h #include libavutil/intreadwrite.h #include libavutil/pixdesc.h @@ -132,6 +133,8 @@ static int config_props(AVFilterLink *outlink) outlink-w = rect-width = inlink-w; outlink-h = rect-height = inlink-h; rect-nb_planes = av_pix_fmt_count_planes(inlink-format); +av_assert0(rect-nb_planes = FF_ARRAY_ELEMS(rect-correction)); how many planes can there ever be? I think the current pixel formats dont have more than 4 but things like CMYKA would have 5, and formats could contain more planes in principle, we dont support such stuff ATM but cameras exist that record infrared in addition to vissible inforation. for example [...] -- 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] avfilter/vf_lenscorrection: add assert to ensure there are not more planes than the correction array is large
--- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 21, 2014, at 1:52 PM, Michael Niedermayer michae...@gmx.at wrote: On Thu, Aug 21, 2014 at 12:57:08PM +0200, Daniel Oberhoff wrote: --- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 21, 2014, at 12:34 PM, Michael Niedermayer michae...@gmx.at wrote: Exceeding the count would write out of array, and should not occur with any current pixel format Signed-off-by: Michael Niedermayer michae...@gmx.at --- libavfilter/vf_lenscorrection.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/libavfilter/vf_lenscorrection.c b/libavfilter/vf_lenscorrection.c index 58184b0..01380fc 100644 --- a/libavfilter/vf_lenscorrection.c +++ b/libavfilter/vf_lenscorrection.c @@ -26,6 +26,7 @@ #include stdlib.h #include math.h +#include libavutil/avassert.h #include libavutil/opt.h #include libavutil/intreadwrite.h #include libavutil/pixdesc.h @@ -132,6 +133,8 @@ static int config_props(AVFilterLink *outlink) outlink-w = rect-width = inlink-w; outlink-h = rect-height = inlink-h; rect-nb_planes = av_pix_fmt_count_planes(inlink-format); +av_assert0(rect-nb_planes = FF_ARRAY_ELEMS(rect-correction)); how many planes can there ever be? I think the current pixel formats dont have more than 4 but things like CMYKA would have 5, and formats could contain more planes in principle, we dont support such stuff ATM but cameras exist that record infrared in addition to vissible inforation. for example But this data only comes from another part of ffmpeg, right? Should then there not be some kind of config macro or such along FF_MAX_NUM_PLANES? Best ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_lenscorrection: add assert to ensure there are not more planes than the correction array is large
--- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 21, 2014, at 1:53 PM, Daniel Oberhoff daniel.oberh...@gmail.com wrote: --- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 21, 2014, at 1:52 PM, Michael Niedermayer michae...@gmx.at wrote: On Thu, Aug 21, 2014 at 12:57:08PM +0200, Daniel Oberhoff wrote: --- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 21, 2014, at 12:34 PM, Michael Niedermayer michae...@gmx.at wrote: Exceeding the count would write out of array, and should not occur with any current pixel format Signed-off-by: Michael Niedermayer michae...@gmx.at --- libavfilter/vf_lenscorrection.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/libavfilter/vf_lenscorrection.c b/libavfilter/vf_lenscorrection.c index 58184b0..01380fc 100644 --- a/libavfilter/vf_lenscorrection.c +++ b/libavfilter/vf_lenscorrection.c @@ -26,6 +26,7 @@ #include stdlib.h #include math.h +#include libavutil/avassert.h #include libavutil/opt.h #include libavutil/intreadwrite.h #include libavutil/pixdesc.h @@ -132,6 +133,8 @@ static int config_props(AVFilterLink *outlink) outlink-w = rect-width = inlink-w; outlink-h = rect-height = inlink-h; rect-nb_planes = av_pix_fmt_count_planes(inlink-format); +av_assert0(rect-nb_planes = FF_ARRAY_ELEMS(rect-correction)); how many planes can there ever be? I think the current pixel formats dont have more than 4 but things like CMYKA would have 5, and formats could contain more planes in principle, we dont support such stuff ATM but cameras exist that record infrared in addition to vissible inforation. for example But this data only comes from another part of ffmpeg, right? Should then there not be some kind of config macro or such along FF_MAX_NUM_PLANES? Or how about doing alloc/realloc instead? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mark null encoder as ts-nonstrict , avoids error messages for null output
On Thu, Aug 21, 2014 at 1:38 PM, compn te...@mi.rr.com wrote:
https://gist.github.com/anonymous/0e26f490ec13d67996fd
commit e94a44543a96b13aa6a23efce2f0378a5479d530
Author: Rodger Combs rodger.co...@gmail.com
Date: Wed Aug 20 15:38:12 2014 -0700
avformat/nullenc: mark null as timestamp-nonstrict
This avoids unnecessary error messages for null output
diff --git a/libavformat/nullenc.c b/libavformat/nullenc.c
index 7c08c39..58b88a1 100644
--- a/libavformat/nullenc.c
+++ b/libavformat/nullenc.c
@@ -32,5 +32,5 @@ AVOutputFormat ff_null_muxer = {
.audio_codec = AV_NE(AV_CODEC_ID_PCM_S16BE, AV_CODEC_ID_PCM_S16LE),
.video_codec = AV_CODEC_ID_RAWVIDEO,
.write_packet = null_write_packet,
-.flags = AVFMT_VARIABLE_FPS | AVFMT_NOFILE |
AVFMT_NOTIMESTAMPS | AVFMT_RAWPICTURE,
+.flags = AVFMT_TS_NONSTRICT | AVFMT_VARIABLE_FPS |
AVFMT_NOFILE | AVFMT_NOTIMESTAMPS | AVFMT_RAWPICTURE,
};
There is a lot of other muxers out there that also have NOTIMESTAMPS
set, and not this flag.
IMHO the code that complains about invalid timestamps should be
adjusted to not do it when NOTIMESTAMPS is set, instead of this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpegts: support ARIB subtitles in libavformat
On Thu, Aug 21, 2014 at 1:49 PM, Tsukasa OMOTO henry0...@gmail.com wrote: Hi, Carl Shouldn't you add ARIB to DESC_types[]? I don't know which ISO_types or DESC_types I should add to. Do you think DESC_types is better? Tsukasa ISO defines id 0x6 as a generic type for private data, its certainly not specified by ISO for ARIB subtitles. I wonder if adding this might run into problems at some point though, if something elses uses 0x6. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpegts: support ARIB subtitles in libavformat
Tsukasa OMOTO henry0312 at gmail.com writes: Shouldn't you add ARIB to DESC_types[]? I don't know which ISO_types or DESC_types I should add to. Do you think DESC_types is better? I probably mixed up stream descriptions and stream identifiers, so ignore this suggestion. But I believe you should simply remove the hunk that sets ISO_types for ARIB. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] build: rely on pkg-config for libx264 probing
On Thu, Aug 21, 2014 at 12:16:35PM +, Carl Eugen Hoyos wrote: Clément Bœsch u at pkh.me writes: [...] Sorry, I seem to have lost track of what you fear will not work if pkg-config is used for x264 detection but will fallback to the current system if pkg-config does not find the right version. It's simple really. You said earlier: or do you actually want a real fallback when it is present but didn't succeed? This is the preferred solution imo. In this case, if pkg-config finds the system install, it will not honor the user c/ld flags but the one from pkg-config. [...] -- Clément B. pgpd_s6qnlY2C.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] imc: reject files with unfathomable sampling rates
On Thu, Aug 21, 2014 at 12:32:52PM +0200, Christophe Gisquet wrote: Hi, ticket #3868 is about a fuzzed file containing a weird sampling rate. richardpl (?) suggestion is perfectly fine in my opinion. I didn't put one, but don't hesitate to put the proper -by. added -- Christophe imc.c |8 1 file changed, 8 insertions(+) efcf55e549ecbbd7513fdd6a33304a20b51f883d 0001-imc-reject-files-with-unfathomable-sampling-rates.patch From 412a719ac4ab830ddc35b3d7e99fab2ccb543279 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq...@gmail.com Date: Thu, 21 Aug 2014 12:21:07 +0200 Subject: [PATCH] imc: reject files with unfathomable sampling rates With huge sampling rates, the table derivation method does not converge fast enough. While fixing it using e.g. Newton-Rhapson-like methods (the curve is nicely convex) is possible, it is much simpler to reject these cases. i would suggest simple bisection instead of more complex methods if someone wants to improve this either way, i aggree this solution is fully adequate applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] build: rely on pkg-config for libx264 probing
On Thu, Aug 21, 2014 at 02:24:40PM +0200, Clément Bœsch wrote:
On Thu, Aug 21, 2014 at 12:16:35PM +, Carl Eugen Hoyos wrote:
Clément Bœsch u at pkh.me writes:
[...]
Sorry, I seem to have lost track of what you fear
will not work if pkg-config is used for x264
detection but will fallback to the current
system if pkg-config does not find the right
version.
It's simple really. You said earlier:
or do you actually want a real fallback when it is
present but didn't succeed?
This is the preferred solution imo.
In this case, if pkg-config finds the system install, it will not honor
the user c/ld flags but the one from pkg-config.
BTW, now that I think of it, depending on where the --extra-{ld,cflags}
are added in the compilation and linker flag, they *might* allow you to
trick the detection.
Did you try the patch with pkg-config only detection?
And try to add --pkg-config=true to trick the detect function.
--
Clément B.
pgpbnBlHSU4vx.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpegts: support ARIB subtitles in libavformat
But I believe you should simply remove the hunk that sets ISO_types for ARIB. updated the patch. Like this? 0001-mpegts-support-ARIB-subtitles-in-libavformat.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mov: better check dref atome validity
On 8/21/2014 12:09 PM, Christophe Gisquet wrote: I'm not sure it is the best fix, but I don't think this could happen in any valid file, nor it would help to swallow the error. Perhaps off-topic, but the source drop from Elemental seems to include completely rewritten dref code -- is it worth looking at? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] set bitrate from rc_max_rate for duration estimation will fix ticket #3678
I have analysed a little more of code, and in fact the duration was not
present in the MXF.
It's for this reason who we pass in the estimation based on the bitrate.
You can see here the selection of the method:
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/utils.c#L2458
About the max bitrate, I agreed how it can't work every time but in major
cases it can be ok because we target the max_bitrate value during the
encoding.
can I send a patch with these modifactions:
if (st-codec-bit_rate 0) {
if (INT_MAX - st-codec-bit_rate bit_rate) {
bit_rate = 0;
break;
}
bit_rate += st-codec-bit_rate;
}
*else *if (st-codec-rc_max_rate 0) {
if (INT_MAX - st-codec-rc_max_rate bit_rate) {
bit_rate = 0;
break;
}
bit_rate += st-codec-rc_max_rate;
*show_warning = 1;*
}
It can increase the bitrate, but also display the warning message.
This solution can display the minimum duration of the stream.
--
*Marc-Antoine*
| e: arnaud.marcanto...@gmail.com
| tel: 06-84-71-84-45
| ohloh: http://bit.ly/1iwtlsU
[image: LinkedIn]
http://s.wisestamp.com/links?url=https%3A%2F%2Fwww.linkedin.com%2Fpub%2Fmarc-antoine-arnaud%2Fb%2F7b8%2F2a3sn=YXJuYXVkLm1hcmNhbnRvaW5lQGdtYWlsLmNvbQ%3D%3D
[image:
Google Plus]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/hevc_res_add: refactor ff_hevc_transform_add{16, 32}_8
On Thu, Aug 21, 2014 at 12:42 AM, James Almer jamr...@gmail.com wrote: * Reduced xmm register count to 7 (As such they are now enabled for x86_32). * Removed four movdqa (affects the sse2 version only). * pxor is now used to clear m0 only once. ~5% faster. Signed-off-by: James Almer jamr...@gmail.com --- Good job, faster and 32-bit compat! libavcodec/x86/hevc_res_add.asm | 122 libavcodec/x86/hevcdsp_init.c | 10 ++-- 2 files changed, 51 insertions(+), 81 deletions(-) diff --git a/libavcodec/x86/hevc_res_add.asm b/libavcodec/x86/hevc_res_add.asm index feea50c..7238fb3 100644 --- a/libavcodec/x86/hevc_res_add.asm +++ b/libavcodec/x86/hevc_res_add.asm @@ -88,71 +88,41 @@ cglobal hevc_transform_add4_8, 3, 4, 6 movhps [r0+r3 ], m1 %endmacro -%macro TR_ADD_INIT_SSE_8 0 -pxor m0, m0 - -mova m4, [r1] -mova m1, [r1+16] -psubw m2, m0, m1 -psubw m5, m0, m4 -packuswb m4, m1 -packuswb m5, m2 - -mova m6, [r1+32] -mova m1, [r1+48] -psubw m2, m0, m1 -psubw m7, m0, m6 -packuswb m6, m1 -packuswb m7, m2 - -mova m8, [r1+64] -mova m1, [r1+80] -psubw m2, m0, m1 -psubw m9, m0, m8 -packuswb m8, m1 -packuswb m9, m2 - -mova m10, [r1+96] -mova m1, [r1+112] -psubw m2, m0, m1 -psubwm11, m0, m10 -packuswb m10, m1 -packuswb m11, m2 -%endmacro - - -%macro TR_ADD_SSE_16_8 0 -TR_ADD_INIT_SSE_8 - -paddusb m0, m4, [r0 ] -paddusb m1, m6, [r0+r2 ] -paddusb m2, m8, [r0+r2*2] -paddusb m3, m10,[r0+r3 ] -psubusb m0, m5 -psubusb m1, m7 -psubusb m2, m9 -psubusb m3, m11 -mova [r0 ], m0 -mova [r0+r2 ], m1 -mova [r0+2*r2], m2 -mova [r0+r3 ], m3 -%endmacro - -%macro TR_ADD_SSE_32_8 0 -TR_ADD_INIT_SSE_8 - -paddusb m0, m4, [r0 ] -paddusb m1, m6, [r0+16 ] -paddusb m2, m8, [r0+r2 ] -paddusb m3, m10,[r0+r2+16] -psubusb m0, m5 -psubusb m1, m7 -psubusb m2, m9 -psubusb m3, m11 -mova [r0 ], m0 -mova [r0+16 ], m1 -mova [r0+r2 ], m2 -mova [r0+r2+16], m3 +%macro TR_ADD_SSE_16_32_8 3 +mova m2, [r1+%1 ] +mova m6, [r1+%1+16] +%if cpuflag(avx) +psubw m1, m0, m2 +psubw m5, m0, m6 +%else +mova m1, m0 +mova m5, m0 +psubw m1, m2 +psubw m5, m6 +%endif I was wondering about these blocks - doesn't the x264asm layer automatically add the mova's when you just use the 3-arg form on sse2? Or is there a speed benefit grouping the mov's? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mov: better check dref atome validity
Hi, 2014-08-21 14:55 GMT+02:00 Derek Buitenhuis derek.buitenh...@gmail.com: On 8/21/2014 12:09 PM, Christophe Gisquet wrote: I'm not sure it is the best fix, but I don't think this could happen in any valid file, nor it would help to swallow the error. Perhaps off-topic, but the source drop from Elemental seems to include completely rewritten dref code -- is it worth looking at? Actually, the more I think about this patch, the more I want to drop it: I'm not a mov expert. Basically, it makes sense, but the caller tries to handle overreads by just moving to the expected end of the atom. Not a very sane practive unless ones knows that code to be prone to such issues and thinks it can be recovered. As for the new dref code, I'm not an expert, so no opinion. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/h264: do proper cleanup in ff_h264_alloc_tables() in case DPB alloc fails
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/h264.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 389307b..5082c14 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -473,7 +473,7 @@ int ff_h264_alloc_tables(H264Context *h)
if (!h-DPB) {
h-DPB = av_mallocz_array(H264_MAX_PICTURE_COUNT, sizeof(*h-DPB));
if (!h-DPB)
-return AVERROR(ENOMEM);
+goto fail;
for (i = 0; i H264_MAX_PICTURE_COUNT; i++)
av_frame_unref(h-DPB[i].f);
av_frame_unref(h-cur_pic.f);
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/h264_slice: More complete cleanup in h264_slice_header_init()
Fixes null pointer dereference
Fixes Ticket3873
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/h264_slice.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index fc744f2..c5a9784 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1173,7 +1173,7 @@ static int h264_slice_header_init(H264Context *h, int
reinit)
ret = ff_h264_alloc_tables(h);
if (ret 0) {
av_log(h-avctx, AV_LOG_ERROR, Could not allocate memory\n);
-return ret;
+goto fail;
}
if (nb_slices H264_MAX_THREADS || (nb_slices h-mb_height
h-mb_height)) {
@@ -1192,14 +1192,16 @@ static int h264_slice_header_init(H264Context *h, int
reinit)
ret = ff_h264_context_init(h);
if (ret 0) {
av_log(h-avctx, AV_LOG_ERROR, context_init() failed.\n);
-return ret;
+goto fail;
}
} else {
for (i = 1; i h-slice_context_count; i++) {
H264Context *c;
c= h-thread_context[i] =
av_mallocz(sizeof(H264Context));
-if (!c)
-return AVERROR(ENOMEM);
+if (!c) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
c-avctx = h-avctx;
if (CONFIG_ERROR_RESILIENCE) {
c-mecc = h-mecc;
@@ -1238,13 +1240,17 @@ static int h264_slice_header_init(H264Context *h, int
reinit)
for (i = 0; i h-slice_context_count; i++)
if ((ret = ff_h264_context_init(h-thread_context[i])) 0) {
av_log(h-avctx, AV_LOG_ERROR, context_init() failed.\n);
-return ret;
+goto fail;
}
}
h-context_initialized = 1;
return 0;
+fail:
+ff_h264_free_tables(h, 0);
+h-context_initialized = 0;
+return ret;
}
static enum AVPixelFormat non_j_pixfmt(enum AVPixelFormat a)
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Fail in h264 nal unit decoding if slice header decoding failed
On Thu, Aug 21, 2014 at 01:09:06PM +0200, Carl Eugen Hoyos wrote: Hi! Attached patch fixes ticket #3873 here, I don't know if it has any unexpected side-effects. Please review, Carl Eugen posted an altenative patch [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 100% positive feedback - All either got their money back or didnt complain Best seller ever, very honest - Seller refunded buyer after failed scam signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mov: better check dref atome validity
On Thu, Aug 21, 2014 at 01:55:05PM +0100, Derek Buitenhuis wrote: On 8/21/2014 12:09 PM, Christophe Gisquet wrote: I'm not sure it is the best fix, but I don't think this could happen in any valid file, nor it would help to swallow the error. Perhaps off-topic, but the source drop from Elemental seems to include completely rewritten dref code -- is it worth looking at? can you provide a link ? [...] -- 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] lavfi/apad: fix logic when whole_len or pad_len options are specified
On date Wednesday 2014-08-20 15:36:26 +0200, Michael Niedermayer encoded: On Wed, Aug 20, 2014 at 12:43:22PM +0200, Stefano Sabatini wrote: On date Tuesday 2014-08-19 01:29:42 +0200, Michael Niedermayer encoded: On Mon, Aug 18, 2014 at 02:53:45PM +0200, Stefano Sabatini wrote: --- libavfilter/af_apad.c | 29 + 1 file changed, 17 insertions(+), 12 deletions(-) probably ok With more changes. -- FFmpeg = Fundamental Foolish Magnificient Portable Exxagerate God af_apad.c | 34 -- 1 file changed, 20 insertions(+), 14 deletions(-) a953355f7237c81362322baa549621a35a92d537 0001-lavfi-apad-fix-logic-when-whole_len-or-pad_len-optio.patch From e81a186aee715c0481df21cf982121736c67e75f Mon Sep 17 00:00:00 2001 From: Stefano Sabatini stefa...@gmail.com Date: Mon, 18 Aug 2014 14:51:25 +0200 Subject: [PATCH] lavfi/apad: fix logic when whole_len or pad_len options are specified probably still ok Applied, thanks. -- FFmpeg = Freak and Frightening Mortal Peaceless Ecumenical Gladiator ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/filters/apad: extend documentation
On date Wednesday 2014-08-20 12:44:15 +0200, Stefano Sabatini encoded: On date Monday 2014-08-18 14:53:52 +0200, Stefano Sabatini encoded: --- doc/filters.texi | 47 +-- 1 file changed, 45 insertions(+), 2 deletions(-) Up. -- FFmpeg = Fundamentalist Fiendish Mega Powered Encoding/decoding Gorilla From 17eecedf1bcd23187deca859b377cf53323b5b1b Mon Sep 17 00:00:00 2001 From: Stefano Sabatini stefa...@gmail.com Date: Mon, 18 Aug 2014 14:52:08 +0200 Subject: [PATCH] doc/filters/apad: extend documentation --- doc/filters.texi | 51 +-- 1 file changed, 49 insertions(+), 2 deletions(-) Applied with a few edits. -- FFmpeg = Fundamentalist Fabulous Mind-dumbing Ponderous Eretic Gadget ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mov: better check dref atome validity
On 8/21/2014 4:13 PM, Michael Niedermayer wrote: can you provide a link ? Provided on IRC. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mark null encoder as ts-nonstrict , avoids error messages for null output
On Thu, Aug 21, 2014 at 02:00:22PM +0200, Hendrik Leppkes wrote:
On Thu, Aug 21, 2014 at 1:38 PM, compn te...@mi.rr.com wrote:
https://gist.github.com/anonymous/0e26f490ec13d67996fd
commit e94a44543a96b13aa6a23efce2f0378a5479d530
Author: Rodger Combs rodger.co...@gmail.com
Date: Wed Aug 20 15:38:12 2014 -0700
avformat/nullenc: mark null as timestamp-nonstrict
This avoids unnecessary error messages for null output
diff --git a/libavformat/nullenc.c b/libavformat/nullenc.c
index 7c08c39..58b88a1 100644
--- a/libavformat/nullenc.c
+++ b/libavformat/nullenc.c
@@ -32,5 +32,5 @@ AVOutputFormat ff_null_muxer = {
.audio_codec = AV_NE(AV_CODEC_ID_PCM_S16BE,
AV_CODEC_ID_PCM_S16LE),
.video_codec = AV_CODEC_ID_RAWVIDEO,
.write_packet = null_write_packet,
-.flags = AVFMT_VARIABLE_FPS | AVFMT_NOFILE |
AVFMT_NOTIMESTAMPS | AVFMT_RAWPICTURE,
+.flags = AVFMT_TS_NONSTRICT | AVFMT_VARIABLE_FPS |
AVFMT_NOFILE | AVFMT_NOTIMESTAMPS | AVFMT_RAWPICTURE,
};
There is a lot of other muxers out there that also have NOTIMESTAMPS
set, and not this flag.
IMHO the code that complains about invalid timestamps should be
adjusted to not do it when NOTIMESTAMPS is set, instead of this.
maybe but for testing/fate at least we should retain timestamp
checks, null is used alot for testing if one looks at trac
iam not sure what is the best thing to do here
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mov: use 64bit for size in mov_skip_multiple_stsd()
Fixes integer overflow
Fixes Ticket 3866
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavformat/mov.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 1255824..b3eb287 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1635,7 +1635,7 @@ static int mov_finalize_stsd_codec(MOVContext *c,
AVIOContext *pb,
static int mov_skip_multiple_stsd(MOVContext *c, AVIOContext *pb,
int codec_tag, int format,
- int size)
+ int64_t size)
{
int video_codec_id = ff_codec_get_id(ff_codec_movvideo_tags, format);
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: use 64bit for size in mov_skip_multiple_stsd()
2014-08-21 17:43 GMT+02:00 Michael Niedermayer michae...@gmx.at: static int mov_skip_multiple_stsd(MOVContext *c, AVIOContext *pb, int codec_tag, int format, - int size) + int64_t size) Nice catch, the size - (avio_tell(pb) - start_pos)) value passed is stored in an int64_t later on. OK then. Thank you. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] wavpackenc: report too small buffer
On Thu, Aug 21, 2014 at 02:32:46PM +0200, Christophe Gisquet wrote: Hi, 2014-08-19 18:28 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com: 2014-08-19 16:20 GMT+02:00 Nicolas George geo...@nsup.org: IMHO, the correct error depends on how sure you are that a buffer too small SHOULD not happen. If you are very sure, then av_assert0(). That would be it: I'm sure that, if the condition occurs and the packet is written anyway, the file will be incorrect. Anyway, that should never occur, so here's a version with av_assert0. -- Christophe wavpackenc.c |2 ++ 1 file changed, 2 insertions(+) 04628a0ec235881d99b91fda00ddebb79dbc340d 0001-wavpackenc-assert-on-too-small-buffer.patch From ae8998602fa0d9114a09291c4623a1609a5fcb8c Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq...@gmail.com Date: Tue, 19 Aug 2014 14:05:56 +0200 Subject: [PATCH] wavpackenc: assert on too small buffer bytestream2_* will not cause buffer overflow, but in that case, this means the allocation would be incorrect and the encoded result invalid. Therefore, assert no overflow occurred. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/hevc_res_add: refactor ff_hevc_transform_add{16, 32}_8
On 21/08/14 10:03 AM, Hendrik Leppkes wrote: On Thu, Aug 21, 2014 at 12:42 AM, James Almer jamr...@gmail.com wrote: * Reduced xmm register count to 7 (As such they are now enabled for x86_32). * Removed four movdqa (affects the sse2 version only). * pxor is now used to clear m0 only once. ~5% faster. Signed-off-by: James Almer jamr...@gmail.com --- Good job, faster and 32-bit compat! libavcodec/x86/hevc_res_add.asm | 122 libavcodec/x86/hevcdsp_init.c | 10 ++-- 2 files changed, 51 insertions(+), 81 deletions(-) diff --git a/libavcodec/x86/hevc_res_add.asm b/libavcodec/x86/hevc_res_add.asm index feea50c..7238fb3 100644 --- a/libavcodec/x86/hevc_res_add.asm +++ b/libavcodec/x86/hevc_res_add.asm @@ -88,71 +88,41 @@ cglobal hevc_transform_add4_8, 3, 4, 6 movhps [r0+r3 ], m1 %endmacro -%macro TR_ADD_INIT_SSE_8 0 -pxor m0, m0 - -mova m4, [r1] -mova m1, [r1+16] -psubw m2, m0, m1 -psubw m5, m0, m4 -packuswb m4, m1 -packuswb m5, m2 - -mova m6, [r1+32] -mova m1, [r1+48] -psubw m2, m0, m1 -psubw m7, m0, m6 -packuswb m6, m1 -packuswb m7, m2 - -mova m8, [r1+64] -mova m1, [r1+80] -psubw m2, m0, m1 -psubw m9, m0, m8 -packuswb m8, m1 -packuswb m9, m2 - -mova m10, [r1+96] -mova m1, [r1+112] -psubw m2, m0, m1 -psubwm11, m0, m10 -packuswb m10, m1 -packuswb m11, m2 -%endmacro - - -%macro TR_ADD_SSE_16_8 0 -TR_ADD_INIT_SSE_8 - -paddusb m0, m4, [r0 ] -paddusb m1, m6, [r0+r2 ] -paddusb m2, m8, [r0+r2*2] -paddusb m3, m10,[r0+r3 ] -psubusb m0, m5 -psubusb m1, m7 -psubusb m2, m9 -psubusb m3, m11 -mova [r0 ], m0 -mova [r0+r2 ], m1 -mova [r0+2*r2], m2 -mova [r0+r3 ], m3 -%endmacro - -%macro TR_ADD_SSE_32_8 0 -TR_ADD_INIT_SSE_8 - -paddusb m0, m4, [r0 ] -paddusb m1, m6, [r0+16 ] -paddusb m2, m8, [r0+r2 ] -paddusb m3, m10,[r0+r2+16] -psubusb m0, m5 -psubusb m1, m7 -psubusb m2, m9 -psubusb m3, m11 -mova [r0 ], m0 -mova [r0+16 ], m1 -mova [r0+r2 ], m2 -mova [r0+r2+16], m3 +%macro TR_ADD_SSE_16_32_8 3 +mova m2, [r1+%1 ] +mova m6, [r1+%1+16] +%if cpuflag(avx) +psubw m1, m0, m2 +psubw m5, m0, m6 +%else +mova m1, m0 +mova m5, m0 +psubw m1, m2 +psubw m5, m6 +%endif I was wondering about these blocks - doesn't the x264asm layer automatically add the mova's when you just use the 3-arg form on sse2? Or is there a speed benefit grouping the mov's? - Hendrik It does that, but on older SSE2 cpus with not-so-good OOO execution grouping instructions like this might help reduce dependencies a bit. This trick is used all over the tree (including some macros from x86util), so it's certainly useful for some cpus. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] [PATCH] hevc_ps: reorder SPS reading to allow some errors
Hi,
2014-08-21 3:06 GMT+02:00 Michael Niedermayer michae...@gmx.at:
heres a narrower solution for this file
not sure its better
i can apply whichever you prefer, probably we wont find out which
is the best solution before pushing something and waiting for more
bug reports
Thanks for narrowing it done, and now I have dug it further.
When you look at what get parsed before that,
vui-def_disp_win.left_offset gets an insane value unrelated to the
video dimensions. I tried instead to do as if
vui-default_display_window_flag and related syntax does not exist.
Then, the timing info is decoded, and the values are actually normal:
vui_num_units_in_tick = 1000
vui_time_scale = 23976
(rest less relevant and meaningfull)
So I think the actual bug in that stream is that it does not contain
any default_display_window information. Why is that? Probably because
the encoder writes an older VUI syntax, and several bits get
misinterpreted. By luck they don't bother us. It would be nice to know
what syntax is used, but there could be so many variations...
The attached therefore barely improves on your patch.
--
Christophe
From 80cd353f464f3785285e0c82efd3c6ccd655bf5c Mon Sep 17 00:00:00 2001
From: Christophe Gisquet christophe.gisq...@gmail.com
Date: Thu, 21 Aug 2014 18:57:18 +0200
Subject: [PATCH] hevc_ps: check overflow and test alternate syntax
Some streams were found to have what appeared to be truncated SPS.
Their syntax seem to be valid at least until the end of the VUI, so
try that syntax if the parsing would overflow the SPS in the
conforming syntax.
Fixes ticket #3872.
---
libavcodec/hevc_ps.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 2ccce5f..29412d2 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -471,7 +471,8 @@ static void decode_vui(HEVCContext *s, HEVCSPS *sps)
{
VUI *vui = sps-vui;
GetBitContext *gb = s-HEVClc-gb;
-int sar_present;
+GetBitContext backup;
+int sar_present, alt = 1;
av_log(s-avctx, AV_LOG_DEBUG, Decoding VUI\n);
@@ -525,6 +526,10 @@ static void decode_vui(HEVCContext *s, HEVCSPS *sps)
vui-frame_field_info_present_flag = get_bits1(gb);
vui-default_display_window_flag = get_bits1(gb);
+// Backup context in case an alternate header is detected
+if( get_bits_left(gb) = 66)
+memcpy(backup, gb, sizeof(backup));
+
if (vui-default_display_window_flag) {
//TODO: * 2 is only valid for 420
vui-def_disp_win.left_offset = get_ue_golomb_long(gb) * 2;
@@ -552,8 +557,22 @@ static void decode_vui(HEVCContext *s, HEVCSPS *sps)
vui-vui_timing_info_present_flag = get_bits1(gb);
if (vui-vui_timing_info_present_flag) {
+if( get_bits_left(gb) 66) {
+// The alternate syntax seem to have timing info located
+// at where def_disp_win is normally located
+av_log(s-avctx, AV_LOG_WARNING,
+ Strange VUI timing information, retrying...\n);
+vui-default_display_window_flag = 0;
+memset(vui-def_disp_win, 0, sizeof(vui-def_disp_win));
+memcpy(gb, backup, sizeof(backup));
+alt = 1;
+}
vui-vui_num_units_in_tick = get_bits_long(gb, 32);
vui-vui_time_scale = get_bits_long(gb, 32);
+if (alt) {
+av_log(s-avctx, AV_LOG_INFO, Retry got %i/%i fps\n,
+ vui-vui_time_scale, vui-vui_num_units_in_tick);
+}
vui-vui_poc_proportional_to_timing_flag = get_bits1(gb);
if (vui-vui_poc_proportional_to_timing_flag)
vui-vui_num_ticks_poc_diff_one_minus1 = get_ue_golomb_long(gb);
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/hevc_res_add: refactor ff_hevc_transform_add{16, 32}_8
Hi, 2014-08-21 0:42 GMT+02:00 James Almer jamr...@gmail.com: * Reduced xmm register count to 7 (As such they are now enabled for x86_32). * Removed four movdqa (affects the sse2 version only). * pxor is now used to clear m0 only once. OK. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpegts: support ARIB subtitles in libavformat
On Thu, Aug 21, 2014 at 09:42:30PM +0900, Tsukasa ŌMOTO wrote: But I believe you should simply remove the hunk that sets ISO_types for ARIB. updated the patch. Like this? libavcodec/avcodec.h|2 ++ libavcodec/codec_desc.c | 14 ++ libavformat/mpegts.c| 34 ++ 3 files changed, 50 insertions(+) 5c9f5b15f2d6e55d517cdd0517d429d3d9330fff 0001-mpegts-support-ARIB-subtitles-in-libavformat.patch From: Tsukasa OMOTO henry0...@gmail.com Date: Thu, 21 Aug 2014 18:57:36 +0900 Subject: [PATCH] mpegts: support ARIB subtitles in libavformat this breaks stream detection in https://trac.ffmpeg.org/raw-attachment/ticket/2632/dvbs_fail_sample4_cut.ts [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/hevc_res_add: refactor ff_hevc_transform_add{16, 32}_8
On 21/08/14 2:15 PM, Christophe Gisquet wrote: Hi, 2014-08-21 0:42 GMT+02:00 James Almer jamr...@gmail.com: * Reduced xmm register count to 7 (As such they are now enabled for x86_32). * Removed four movdqa (affects the sse2 version only). * pxor is now used to clear m0 only once. OK. Pushed. Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] [PATCH] hevc_ps: reorder SPS reading to allow some errors
On Thu, Aug 21, 2014 at 07:14:03PM +0200, Christophe Gisquet wrote: Hi, 2014-08-21 3:06 GMT+02:00 Michael Niedermayer michae...@gmx.at: heres a narrower solution for this file not sure its better i can apply whichever you prefer, probably we wont find out which is the best solution before pushing something and waiting for more bug reports Thanks for narrowing it done, and now I have dug it further. When you look at what get parsed before that, vui-def_disp_win.left_offset gets an insane value unrelated to the video dimensions. I tried instead to do as if vui-default_display_window_flag and related syntax does not exist. Then, the timing info is decoded, and the values are actually normal: vui_num_units_in_tick = 1000 vui_time_scale = 23976 (rest less relevant and meaningfull) So I think the actual bug in that stream is that it does not contain any default_display_window information. Why is that? Probably because the encoder writes an older VUI syntax, and several bits get misinterpreted. By luck they don't bother us. It would be nice to know what syntax is used, but there could be so many variations... The attached therefore barely improves on your patch. -- Christophe hevc_ps.c | 21 - 1 file changed, 20 insertions(+), 1 deletion(-) b60bac9ae4f56940b8e219dbe735308c38b9a57a 0001-hevc_ps-check-overflow-and-test-alternate-syntax.patch From 80cd353f464f3785285e0c82efd3c6ccd655bf5c Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq...@gmail.com Date: Thu, 21 Aug 2014 18:57:18 +0200 Subject: [PATCH] hevc_ps: check overflow and test alternate syntax Some streams were found to have what appeared to be truncated SPS. Their syntax seem to be valid at least until the end of the VUI, so try that syntax if the parsing would overflow the SPS in the conforming syntax. Fixes ticket #3872. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/hevc_res_add: refactor ff_hevc_transform_add{16, 32}_8
It does that, but on older SSE2 cpus with not-so-good OOO execution grouping instructions like this might help reduce dependencies a bit. Are any older SSE2 CPUs actually capable of decoding reasonable HEVC? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] libavformat/ftp: Do not leak memory in routine ftp_features
Setting the pointer to NULL inside both ftp_send_command
and ftp_features is redundant. Generally always setting to
NULL in ftp_send_command seems safer, but throughout the file
that parameter was always passed initialized. So I do it here
too for consistency.
Should fix CID1231988 (RESOURCE_LEAK)
Signed-off-by: Alexander Strasser eclip...@gmx.net
---
I tested with valgrind and the mem leak goes away. About the
rest it would be good if someone could have a 2nd look.
And maybe Lukasz can comment if he finds some time because he
maintains this code.
libavformat/ftp.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavformat/ftp.c b/libavformat/ftp.c
index 9ee9b16..7faf4a5 100644
--- a/libavformat/ftp.c
+++ b/libavformat/ftp.c
@@ -183,6 +183,9 @@ static int ftp_send_command(FTPContext *s, const char
*command,
{
int err;
+if (response)
+*response = NULL;
+
if ((err = ffurl_write(s-conn_control, command, strlen(command))) 0)
return err;
if (!err)
@@ -444,12 +447,14 @@ static int ftp_features(FTPContext *s)
static const char *enable_utf8_command = OPTS UTF8 ON\r\n;
static const int feat_codes[] = {211, 0};
static const int opts_codes[] = {200, 451};
-char *feat;
+char *feat = NULL;
if (ftp_send_command(s, feat_command, feat_codes, feat) == 211) {
if (av_stristr(feat, UTF8))
ftp_send_command(s, enable_utf8_command, opts_codes, NULL);
}
+av_freep(feat);
+
return 0;
}
--
pgpPp3z4D5DcF.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/hevc_res_add: refactor ff_hevc_transform_add{16, 32}_8
On 21/08/14 5:40 PM, Kieran Kunhya wrote: It does that, but on older SSE2 cpus with not-so-good OOO execution grouping instructions like this might help reduce dependencies a bit. Are any older SSE2 CPUs actually capable of decoding reasonable HEVC? Probably not (at least nothing above dvd resolution), but aside from uglyfying the asm a bit it doesn't hurt. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/ftp: Do not leak memory in routine ftp_features
On 2014-08-20 06:27 +0200, Alexander Strasser wrote: On 2014-08-20 01:25 +0200, Alexander Strasser wrote: Should fix CID1231988 (RESOURCE_LEAK) Signed-off-by: Alexander Strasser eclip...@gmx.net --- WARNING: Sorry, I only compile-tested so far. There is one remaining thing, I am not sure of: It looks like the variable feet could be uninitialized at the point av_freep is called. I think it cannot, but I had to follow quite some hops down the call hierarchy. I see two possibilities for taking care of that: 1) explicitly initialize it with NULL (could be merged with declaration) 2) someone else goes all the way down and if he comes to the same conclusion as I did, we add a comment stating that to ftp_send_command After sleeping over it I think I am wrong about 2 because ftp_send_command may early return and in those cases leave feat uninitialized. So here is some more: 3) Examine all places ftp_send_command, ftp_status is called and do what described for this instance in point 1 4) Change ftp_send_command and ftp_status to make sure the out parameter is always valid or at least NULL after a call Doing 4 seem best to me ATM but maybe I missed some things again :( Dropped. I sent v2 which combines points 1, 3 and 4. https://ffmpeg.org/pipermail/ffmpeg-devel/2014-August/161668.html Subject: [FFmpeg-devel] [PATCH v2] libavformat/ftp: Do not leak memory in routine ftp_features Message-ID: a0e0e8e0008bfc3e7c957ebf3e4d97d89483beba.1408637365.git.eclip...@gmx.net Alexander pgpihp_luxi5_.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Disable chunked output for Icecast
On Wed, Aug 20, 2014 at 10:31:39AM +0300, Maksym Veremeyenko wrote: hi, attached patch fix input stream detection by Icecast that do not understand chunked http input. how can this issue/bug be reproduced ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] dpxenc: fix padding in encode_gbrp12
On Thu, Aug 21, 2014 at 02:11:17PM +0200, Christophe Gisquet wrote: Hi, 2014-08-20 11:35 GMT+02:00 James Darnley james.darn...@gmail.com: (In an effort to help review...) This does move from per-pixel to per-line so if this is supposed to be correct then it looks good to me. Yes, this is a bugfix that is actually independent of the intent of the patchset. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/h264_slice: More complete cleanup in h264_slice_header_init()
Michael Niedermayer michaelni at gmx.at writes: Fixes null pointer dereference Fixes Ticket3873 Thank you! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264: Move AFD to side data to match MPEG-2
Hi, 2014-08-09 2:45 GMT+02:00 Kieran Kunhya kier...@obe.tv: +AVFrameSideData *sd = +av_frame_new_side_data(cur-f, + AV_FRAME_DATA_AFD, 1); +if (!sd) +return; You're not responsible for what has already been committed before, but: 1) The allocation failure is detected but not returned to the caller; 2) It leaves objects in a kind of undetermined state by exiting early the function. Maybe all that side data stuff should be moved to the end of the function first (but before the last thread-related line), and fixed, then you also add this hunk there? -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Adds support for constant quality mode in VP9.
Changes in the parameter mapping for libvpx to support the constant
quality mode in VP9. The assumption in the patch is that if crf is
provided but bitrate is 0, then the 'constant quality' mode of VP9
is used. However if both are present, the 'constrained quality' mode
is used as before.
---
libavcodec/libvpxenc.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 830a793..a6e5392 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -300,10 +300,17 @@ static av_cold int vpx_init(AVCodecContext *avctx,
enccfg.g_pass = VPX_RC_ONE_PASS;
if (avctx-rc_min_rate == avctx-rc_max_rate
-avctx-rc_min_rate == avctx-bit_rate avctx-bit_rate)
+avctx-rc_min_rate == avctx-bit_rate avctx-bit_rate) {
enccfg.rc_end_usage = VPX_CBR;
-else if (ctx-crf)
+} else if (ctx-crf = 0) {
enccfg.rc_end_usage = VPX_CQ;
+#if CONFIG_LIBVPX_VP9_ENCODER
+if (!avctx-bit_rate avctx-codec_id == AV_CODEC_ID_VP9)
+enccfg.rc_end_usage = VPX_Q;
+#endif
+av_log(avctx, AV_LOG_INFO, %s usage set with cq=%d\n,
+ enccfg.rc_end_usage == VPX_CQ ? VPX_CQ : VPX_Q, ctx-crf);
+}
if (avctx-bit_rate) {
enccfg.rc_target_bitrate = av_rescale_rnd(avctx-bit_rate, 1, 1000,
@@ -311,7 +318,7 @@ static av_cold int vpx_init(AVCodecContext *avctx,
} else {
if (enccfg.rc_end_usage == VPX_CQ) {
enccfg.rc_target_bitrate = 100;
-} else {
+} else if (enccfg.rc_end_usage != VPX_Q) {
avctx-bit_rate = enccfg.rc_target_bitrate * 1000;
av_log(avctx, AV_LOG_WARNING,
Neither bitrate nor constrained quality specified, using
default bitrate of %dkbit/sec\n,
@@ -324,7 +331,7 @@ static av_cold int vpx_init(AVCodecContext *avctx,
if (avctx-qmax = 0)
enccfg.rc_max_quantizer = avctx-qmax;
-if (enccfg.rc_end_usage == VPX_CQ) {
+if (enccfg.rc_end_usage == VPX_CQ || enccfg.rc_end_usage == VPX_Q) {
if (ctx-crf enccfg.rc_min_quantizer || ctx-crf
enccfg.rc_max_quantizer) {
av_log(avctx, AV_LOG_ERROR,
CQ level must be between minimum and maximum quantizer
value (%d-%d)\n,
@@ -430,7 +437,8 @@ static av_cold int vpx_init(AVCodecContext *avctx,
if (avctx-codec_id == AV_CODEC_ID_VP8)
codecctl_int(avctx, VP8E_SET_TOKEN_PARTITIONS,
av_log2(avctx-slices));
codecctl_int(avctx, VP8E_SET_STATIC_THRESHOLD, avctx-mb_threshold);
-codecctl_int(avctx, VP8E_SET_CQ_LEVEL, ctx-crf);
+if (ctx-crf = 0)
+codecctl_int(avctx, VP8E_SET_CQ_LEVEL, ctx-crf);
if (ctx-max_intra_rate = 0)
codecctl_int(avctx, VP8E_SET_MAX_INTRA_BITRATE_PCT,
ctx-max_intra_rate);
@@ -775,7 +783,7 @@ static int vp8_encode(AVCodecContext *avctx, AVPacket *pkt,
by the bool decoder, meaning that partitions can be
decoded even \
though earlier partitions have been lost. Note that
intra predicition \
is still done over the partition boundary.,
0, AV_OPT_TYPE_CONST, {.i64 = VPX_ERROR_RESILIENT_PARTITIONS}, 0, 0, VE, er},
\
-{ crf, Select the quality for constant quality mode,
offsetof(VP8Context, crf), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 63, VE }, \
+{ crf, Select the quality for constant quality mode,
offsetof(VP8Context, crf), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 63, VE }, \
#define LEGACY_OPTIONS \
{speed, , offsetof(VP8Context, cpu_used), AV_OPT_TYPE_INT, {.i64 = 1},
-16, 16, VE}, \
--
2.1.0.rc2.206.gedb03e5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/fic: Check if a frame is available before using it
On Thu, Aug 14, 2014 at 05:46:08AM +0200, Michael Niedermayer wrote: Fixes null pointer dereference Fixes: ficvf.avi Found-by: Piotr Bandurski ami_st...@o2.pl Signed-off-by: Michael Niedermayer michae...@gmx.at applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] vidstabutils: improve documentation
Signed-off-by: Timothy Gu timothyg...@gmail.com --- libavfilter/vidstabutils.h | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/libavfilter/vidstabutils.h b/libavfilter/vidstabutils.h index 93278f6..c6d6ced 100644 --- a/libavfilter/vidstabutils.h +++ b/libavfilter/vidstabutils.h @@ -25,12 +25,23 @@ #include avfilter.h -/* ** some conversions from avlib to vid.stab constants and functions *** */ +/* Conversion routines between libav* and vid.stab */ -/** converts the pixelformat of avlib into the one of the vid.stab library */ +/** + * Converts an AVPixelFormat to a VSPixelFormat. + * + * @param[in] ctx AVFilterContext used for logging + * @param[in] pf AVPixelFormat + * @returna corresponding VSPixelFormat + */ VSPixelFormat ff_av2vs_pixfmt(AVFilterContext *ctx, enum AVPixelFormat pf); -/** sets the memory allocation function and logging constants to av versions */ +/** + * Initialize libvidstab + * + * Sets the memory allocation functions and logging constants to corresponding + * av* versions. + */ void ff_vs_init(void); #endif -- 1.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] delete the old segment file from hls list
repost new patch:
when update the hls m3u8 list, the old file is not unlinked
this patch can do this operation
delete the old ts segment which not show in m3u8,
use hls_sync_list.
Signed-off-by: Steven Liu qi@chinacache.com
---
libavformat/hlsenc.c | 15 ++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 11f1e5b..fc1063e 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -30,6 +30,10 @@
#include avformat.h
#include internal.h
+#if HAVE_UNISTD_H
+#include unistd.h
+#endif
+
typedef struct HLSSegment {
char filename[1024];
@@ -50,6 +54,7 @@ typedef struct HLSContext {
float time;// Set by a private option.
int max_nb_segments; // Set by a private option.
int wrap; // Set by a private option.
+int sync_list;
int64_t recording_time;
int has_video;
@@ -96,6 +101,7 @@ static int hls_mux_init(AVFormatContext *s)
static int hls_append_segment(HLSContext *hls, double duration)
{
HLSSegment *en = av_malloc(sizeof(*en));
+int ret = 0;
if (!en)
return AVERROR(ENOMEM);
@@ -115,7 +121,13 @@ static int hls_append_segment(HLSContext *hls, double
duration)
if (hls-max_nb_segments hls-nb_entries = hls-max_nb_segments) {
en = hls-segments;
hls-segments = en-next;
-av_free(en);
+if (hls-sync_list) {
+ret = unlink(en-filename);
+if (ret 0) {
+av_log(hls-avf, AV_LOG_WARNING, remove %s failed\n,
en-filename);
+}
+}
+av_free(en);
} else
hls-nb_entries++;
@@ -340,6 +352,7 @@ static const AVOption options[] = {
{hls_list_size, set maximum number of playlist entries,
OFFSET(max_nb_segments),AV_OPT_TYPE_INT,{.i64 = 5}, 0, INT_MAX,
E},
{hls_wrap, set number after which the index wraps,
OFFSET(wrap),AV_OPT_TYPE_INT,{.i64 = 0}, 0, INT_MAX, E},
{hls_base_url, url to prepend to each playlist entry,
OFFSET(baseurl), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, E},
+{hls_sync_list, remove old ts segment for sync the file with the
m3u8 list, OFFSET(sync_list),AV_OPT_TYPE_INT,{.i64 = 0}, 0,
INT_MAX, E},
{ NULL },
};
--
1.7.1
2014-08-21 16:51 GMT+08:00 Steven Liu lingjiujia...@gmail.com:
Hi Stefano,
if unistd is not available under Linux,
it will output error message when compile the source code.
[root@testrtmp ffmpeg]# make
CC libavformat/hlsenc.o
libavformat/hlsenc.c: In function ‘hls_append_segment’:
libavformat/hlsenc.c:125: error: implicit declaration of function ‘unlink’
make: *** [libavformat/hlsenc.o] Error 1
[root@testrtmp ffmpeg]#
the follow is the new patch:
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 11f1e5b..fc1063e 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -30,6 +30,10 @@
#include avformat.h
#include internal.h
+#if HAVE_UNISTD_H
+#include unistd.h
+#endif
+
typedef struct HLSSegment {
char filename[1024];
@@ -50,6 +54,7 @@ typedef struct HLSContext {
float time;// Set by a private option.
int max_nb_segments; // Set by a private option.
int wrap; // Set by a private option.
+int sync_list;// Set by a private option.
int64_t recording_time;
int has_video;
@@ -96,6 +101,7 @@ static int hls_mux_init(AVFormatContext *s)
static int hls_append_segment(HLSContext *hls, double duration)
{
HLSSegment *en = av_malloc(sizeof(*en));
+ int ret = 0;
if (!en)
return AVERROR(ENOMEM);
@@ -115,7 +121,13 @@ static int hls_append_segment(HLSContext *hls, double
duration)
if (hls-max_nb_segments hls-nb_entries = hls-max_nb_segments) {
en = hls-segments;
hls-segments = en-next;
-av_free(en);
+if (hls-sync_list) {
+ret = unlink(en-filename);
+if (ret 0) {
+av_log(hls-avf, AV_LOG_WARNING, remove %s failed\n,
en-filename);
+}
+}
+ av_free(en);
} else
hls-nb_entries++;
@@ -340,6 +352,7 @@ static const AVOption options[] = {
{hls_list_size, set maximum number of playlist entries,
OFFSET(max_nb_segments),AV_OPT_TYPE_INT,{.i64 = 5}, 0, INT_MAX,
E},
{hls_wrap, set number after which the index wraps,
OFFSET(wrap),AV_OPT_TYPE_INT,{.i64 = 0}, 0, INT_MAX, E},
{hls_base_url, url to prepend to each playlist entry,
OFFSET(baseurl), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, E},
+{hls_sync_list, remove old ts segment for sync the file with the
m3u8 list, OFFSET(sync_list),AV_OPT_TYPE_INT,{.i64 = 0}, 0,
INT_MAX, E},
{ NULL },
};
If you want sync the file with the m3u8 list, please use the hls_sync_list
parameter, default it is 0, and !0 is enable the sync
[FFmpeg-devel] Codec Routing
I have been investigating the ways and means of the 'routing' of FFMPEG internally. I've built from source binaries with Windows and C99to89. I build with --enable-libvpx. I was keenly interested in the ability of libvpx to create/encode webm with alpha. ( output from ffprobe ffprobe version 2.3.git Copyright (c) 2007-2014 the FFmpeg developers built on Aug 21 2014 09:14:40 with Microsoft (R) 32-bit C/C++ Optimizing Compi ler Version 16.00.40219.01 for 80x86 configuration: --toolchain=msvc --enable-shared --enable-libvpx --enable-libvo rbis --disable-pthreads libavutil 54. 5.100 / 54. 5.100 libavcodec 56. 0.101 / 56. 0.101 libavformat56. 1.100 / 56. 1.100 libavdevice56. 0.100 / 56. 0.100 libavfilter 5. 0.100 / 5. 0.100 libswscale 3. 0.100 / 3. 0.100 libswresample 1. 1.100 / 1. 1.100 ) Hey, it built and it 'seemed' to work. So I started digging in and then discovered that it doesn't decode alpha yet. HA, that was a surprise. So I started examining the FFmpeg codec HOWTO (http://wiki.multimedia.cx/index.php?title=FFmpeg_codec_HOWTO) and instrumented some printf instructions into libvpxdec.c in vpx_init() and vp8_decode(). These don't ever appear, so I also tried to do a fopen(abc.txt) and that doesn't get created. So WHAT routes the linkage to Where? So I dumped --codecs and low and behold DEV.L. vp8 On2 VP8 (decoders: vp8 libvpx ) (encoders: libvpx ) DEV.L. vp9 Google VP9 (decoders: vp9 libvpx-vp9 ) (encoders: libvpx-vp9 ) There's 2 DECODERS for vp8 and vp8 and the 'internal' one is used first ! Isn't that a build bug? Do I need to do a --disable-vp8, etc? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Codec Routing
Hi, This question belongs in ffmpeg-u...@ffmpeg.org mailing list. I have CC'd this mail to that mailing list, and please don't reply to ffmpeg-devel anymore. On Thu, Aug 21, 2014 at 4:55 PM, Chuck Burfoot ch...@burfoots.com wrote: I build with --enable-libvpx. I was keenly interested in the ability of libvpx to create/encode webm with alpha. So you only want encoding with libvpx? The questions below are all about decoding. [...] So I dumped --codecs and low and behold DEV.L. vp8 On2 VP8 (decoders: vp8 libvpx ) (encoders: libvpx ) DEV.L. vp9 Google VP9 (decoders: vp9 libvpx-vp9 ) (encoders: libvpx-vp9 ) There's 2 DECODERS for vp8 and vp9 and the 'internal' one is used first ! Isn't that a build bug? No. The internal decoder is much faster than libvpx (See http://x264dev.multimedia.cx/archives/499), and not many people use alpha in VP8. That's why we made it default. If you really want to use libvpx to decode vp8, use something like: ffmpeg -c:v libvpx -i INPUT ... Do I need to do a --disable-vp8, etc? If you want to force libvpx decoding at all times and disable the internal VP8 decoder, do --disable-decoder=vp8. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] [PATCH] hevc_ps: reorder SPS reading to allow some errors
On Aug 21, 2014 10:14 AM, Christophe Gisquet christophe.gisq...@gmail.com wrote: Hi, 2014-08-21 3:06 GMT+02:00 Michael Niedermayer michae...@gmx.at: heres a narrower solution for this file not sure its better i can apply whichever you prefer, probably we wont find out which is the best solution before pushing something and waiting for more bug reports Thanks for narrowing it done, and now I have dug it further. When you look at what get parsed before that, vui-def_disp_win.left_offset gets an insane value unrelated to the video dimensions. I tried instead to do as if vui-default_display_window_flag and related syntax does not exist. Then, the timing info is decoded, and the values are actually normal: vui_num_units_in_tick = 1000 vui_time_scale = 23976 (rest less relevant and meaningfull) So I think the actual bug in that stream is that it does not contain any default_display_window information. Why is that? Probably because the encoder writes an older VUI syntax, and several bits get misinterpreted. By luck they don't bother us. It would be nice to know what syntax is used, but there could be so many variations... The attached therefore barely improves on your patch. -int sar_present; +GetBitContext backup; +int sar_present, alt = 1; Shouldn't alt be initialized to 0? Sorry about being too late. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/hevc_res_add: refactor ff_hevc_transform_add{16, 32}_8
On 21.08.2014, at 22:40, Kieran Kunhya kier...@obe.tv wrote: It does that, but on older SSE2 cpus with not-so-good OOO execution grouping instructions like this might help reduce dependencies a bit. Are any older SSE2 CPUs actually capable of decoding reasonable HEVC? Of course they are. Not in real time, but people would use the same method that was used for H.264 back in the day: re-encode to a simpler format (and/or skip processing steps). So any speedup will still be welcome on these even if less critical. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] dict.c: Free non-strduped av_dict_set arguments on error.
On 22.08.2014, at 04:06, Michael Niedermayer michae...@gmx.at wrote: On Sat, Aug 16, 2014 at 02:43:46PM +0200, Reimar Döffinger wrote: On Wed, Aug 13, 2014 at 01:57:56PM +0200, Michael Niedermayer wrote: On Mon, Aug 11, 2014 at 09:17:18PM +0200, Reimar Döffinger wrote: Unfortunately this was not explicitly documented and thus might be very risky. yes maybe a AV_DICT_FREE_ARGS_ON_ERROR could be used, but its not as convenient as getting the behavior by default That would add a lot of clutter and make it more inconvenient to use and likely to be forgotten. I also honestly see no real use-case for not setting it. One way to solve this would be to deprecate AV_DICT_DONT_STRDUP_KEY/ AV_DICT_DONT_STRDUP_VAL, warning that they fail to free on error and then add new values, e.g. AV_DICT_OWN_KEY (better suggestions?) with the new behaviour. Will still be a bit of a pain to replace all uses in FFmpeg, but manageable. What do you think? Better suggestions? i guess its either to apply the patch or not, i dont see a better solution. renaming and deprecating options is certainly a bigger mess and doesnt avoid the problem Given how fixing all uses in FFmpeg would be a bigger mess IMHO I'd favour applying it, if necessary with the ABI bump as excuse. If you agree apply it (or wait for me to do it this evening at earliest). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
