Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 22/06/15 9:11 AM, Derek Buitenhuis wrote: On 6/21/2015 8:04 PM, Mariusz Szczepańczyk wrote: Anyway, this is a part of my GSoC task that has been accepted and I'm compelled to implement it so I won't be getting into further discussion. Let's just say a large portion of the community didn't and don't think this idea has any place in libav* in the first place, but were ignored, or our complaints pushed aside. - Derek I have no opinion one or way or another regarding this addition, but if this is a GSoC project then i guess the time to show disagreement was back in February when it was a suggested project waiting for applications, and not in the middle of the program long after a student got the project assigned. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 6/22/2015 5:33 PM, James Almer wrote: I have no opinion one or way or another regarding this addition, but if this is a GSoC project then i guess the time to show disagreement was back in February when it was a suggested project waiting for applications, and not in the middle of the program long after a student got the project assigned. We did. Several times. It was ignored or pushed aside. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add ssim filter
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fc9f455..55cd055 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -197,6 +197,7 @@ OBJS-$(CONFIG_SIGNALSTATS_FILTER)+=
vf_signalstats.o
OBJS-$(CONFIG_SMARTBLUR_FILTER) += vf_smartblur.o
OBJS-$(CONFIG_SPLIT_FILTER) += split.o
OBJS-$(CONFIG_SPP_FILTER)+= vf_spp.o
+OBJS-$(CONFIG_SSIM_FILTER) += vf_ssim.o dualinput.o
framesync.o
OBJS-$(CONFIG_STEREO3D_FILTER) += vf_stereo3d.o
OBJS-$(CONFIG_SUBTITLES_FILTER) += vf_subtitles.o
OBJS-$(CONFIG_SUPER2XSAI_FILTER) += vf_super2xsai.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 415ed1b..3898498 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -212,6 +212,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(SMARTBLUR, smartblur, vf);
REGISTER_FILTER(SPLIT, split, vf);
REGISTER_FILTER(SPP,spp,vf);
+REGISTER_FILTER(SSIM, ssim, vf);
REGISTER_FILTER(STEREO3D, stereo3d, vf);
REGISTER_FILTER(SUBTITLES, subtitles, vf);
REGISTER_FILTER(SUPER2XSAI, super2xsai, vf);
diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c
new file mode 100644
index 000..035a3a5
--- /dev/null
+++ b/libavfilter/vf_ssim.c
@@ -0,0 +1,335 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Caculate the SSIM between two input videos.
+ */
+
+#include libavutil/opt.h
+#include libavutil/pixdesc.h
+#include avfilter.h
+#include dualinput.h
+#include drawutils.h
+#include formats.h
+#include internal.h
+#include video.h
+
+typedef struct SSIMContext {
+const AVClass *class;
+FFDualInputContext dinput;
+FILE *stats_file;
+char *stats_file_str;
+uint64_t nb_frames;
+double ssim[4];
+char comps[4];
+uint8_t rgba_map[4];
+int planewidth[4];
+int planeheight[4];
+} SSIMContext;
+
+#define OFFSET(x) offsetof(SSIMContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+
+static const AVOption ssim_options[] = {
+{stats_file, Set file where to store per-frame difference information,
OFFSET(stats_file_str), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, FLAGS },
+{f, Set file where to store per-frame difference information,
OFFSET(stats_file_str), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, FLAGS },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(ssim);
+
+static void set_meta(AVDictionary **metadata, const char *key, char comp,
float d)
+{
+char value[128];
+snprintf(value, sizeof(value), %0.2f, d);
+if (comp) {
+char key2[128];
+snprintf(key2, sizeof(key2), %s%c, key, comp);
+av_dict_set(metadata, key2, value, 0);
+} else {
+av_dict_set(metadata, key, value, 0);
+}
+}
+
+static void ssim_parms_8x8(uint8_t *s, int sp, uint8_t *r, int rp,
+ uint64_t *sum_s, uint64_t *sum_r, uint64_t
*sum_sq_s,
+ uint64_t *sum_sq_r, uint64_t *sum_sxr)
+{
+int i, j;
+
+for (i = 0; i 8; i++, s += sp, r += rp) {
+for (j = 0; j 8; j++) {
+*sum_s+= s[j];
+*sum_r+= r[j];
+*sum_sq_s += s[j] * s[j];
+*sum_sq_r += r[j] * r[j];
+*sum_sxr += s[j] * r[j];
+}
+}
+}
+
+const static int64_t cc1 = 26634; // (64^2*(.01*255)^2
+const static int64_t cc2 = 239708; // (64^2*(.03*255)^2
+
+static double similarity(uint64_t sum_s, uint64_t sum_r, uint64_t sum_sq_s,
+ uint64_t sum_sq_r, uint64_t sum_sxr, int count)
+{
+int64_t ssim_n, ssim_d;
+int64_t c1, c2;
+
+//scale the constants by number of pixels
+c1 = (cc1 * count * count) 12;
+c2 = (cc2 * count * count) 12;
+
+ssim_n = (2 * sum_s * sum_r + c1)*((int64_t)2 * count * sum_sxr -
+ (int64_t)2 * sum_s * sum_r + c2);
+
+ssim_d = (sum_s * sum_s + sum_r * sum_r+c1) * ((int64_t)count * sum_sq_s -
+ (int64_t)sum_s * sum_s +
+
Re: [FFmpeg-devel] [PATCH v2] fate: add some tests for ffv1 level 3 with 8/10/16 bps
On 22.06.2015 14:59, Michael Niedermayer wrote: On Mon, Jun 22, 2015 at 09:38:43AM +0200, Tobias Rapp wrote: Attached patch adds some FATE tests for FFV1 level 3 with different bits-per-sample. fate/vcodec.mak |6 +- ref/vsynth/vsynth1-ffv1.3-420|4 ref/vsynth/vsynth1-ffv1.3-422p10 |4 ref/vsynth/vsynth1-ffv1.3-444p16 |4 ref/vsynth/vsynth1-ffv1.3-bgr|4 ref/vsynth/vsynth2-ffv1.3-420|4 ref/vsynth/vsynth2-ffv1.3-422p10 |4 ref/vsynth/vsynth2-ffv1.3-444p16 |4 ref/vsynth/vsynth2-ffv1.3-bgr|4 ref/vsynth/vsynth3-ffv1.3-420|4 ref/vsynth/vsynth3-ffv1.3-422p10 |4 ref/vsynth/vsynth3-ffv1.3-444p16 |4 ref/vsynth/vsynth3-ffv1.3-bgr|4 ref/vsynth/vsynth_lena-ffv1.3-420|4 ref/vsynth/vsynth_lena-ffv1.3-422p10 |4 ref/vsynth/vsynth_lena-ffv1.3-444p16 |4 ref/vsynth/vsynth_lena-ffv1.3-bgr|4 17 files changed, 69 insertions(+), 1 deletion(-) 09d8d05b6b5cded64fc6e6698e503584daad057c 0001-fate-add-some-tests-for-ffv1-level-3-with-8-10-16-bp.patch From aee3721703e8530bb71f85daf4b4438ed170f612 Mon Sep 17 00:00:00 2001 From: Tobias Rapp t.r...@noa-audio.com Date: Fri, 19 Jun 2015 14:30:27 +0200 Subject: [PATCH] fate: add some tests for ffv1 level 3 with 8/10/16 bps fails on MIPS you are possibly missing some swscale bitexact flag or something Attached a new version of the patch with -sws_flags neighbor+bitexact added to 10/16 bit YUV and RGB. Looking at fate-run.sh the bitexact flag might be redundant, though. Noticed that the stddev of all YUV output files is 0.00 now (but not for RGB). Regards, Tobias From 0ac4ba5ea07c8cb168ba3ff23b0f30d86b25cef8 Mon Sep 17 00:00:00 2001 From: Tobias Rapp t.r...@noa-audio.com Date: Fri, 19 Jun 2015 14:30:27 +0200 Subject: [PATCH] fate: add some tests for ffv1 level 3 with 8/10/16 bps --- tests/fate/vcodec.mak | 12 +++- tests/ref/vsynth/vsynth1-ffv1.3-420| 4 tests/ref/vsynth/vsynth1-ffv1.3-422p10 | 4 tests/ref/vsynth/vsynth1-ffv1.3-444p16 | 4 tests/ref/vsynth/vsynth1-ffv1.3-bgr| 4 tests/ref/vsynth/vsynth2-ffv1.3-420| 4 tests/ref/vsynth/vsynth2-ffv1.3-422p10 | 4 tests/ref/vsynth/vsynth2-ffv1.3-444p16 | 4 tests/ref/vsynth/vsynth2-ffv1.3-bgr| 4 tests/ref/vsynth/vsynth3-ffv1.3-420| 4 tests/ref/vsynth/vsynth3-ffv1.3-422p10 | 4 tests/ref/vsynth/vsynth3-ffv1.3-444p16 | 4 tests/ref/vsynth/vsynth3-ffv1.3-bgr| 4 tests/ref/vsynth/vsynth_lena-ffv1.3-420| 4 tests/ref/vsynth/vsynth_lena-ffv1.3-422p10 | 4 tests/ref/vsynth/vsynth_lena-ffv1.3-444p16 | 4 tests/ref/vsynth/vsynth_lena-ffv1.3-bgr| 4 17 files changed, 75 insertions(+), 1 deletion(-) create mode 100644 tests/ref/vsynth/vsynth1-ffv1.3-420 create mode 100644 tests/ref/vsynth/vsynth1-ffv1.3-422p10 create mode 100644 tests/ref/vsynth/vsynth1-ffv1.3-444p16 create mode 100644 tests/ref/vsynth/vsynth1-ffv1.3-bgr create mode 100644 tests/ref/vsynth/vsynth2-ffv1.3-420 create mode 100644 tests/ref/vsynth/vsynth2-ffv1.3-422p10 create mode 100644 tests/ref/vsynth/vsynth2-ffv1.3-444p16 create mode 100644 tests/ref/vsynth/vsynth2-ffv1.3-bgr create mode 100644 tests/ref/vsynth/vsynth3-ffv1.3-420 create mode 100644 tests/ref/vsynth/vsynth3-ffv1.3-422p10 create mode 100644 tests/ref/vsynth/vsynth3-ffv1.3-444p16 create mode 100644 tests/ref/vsynth/vsynth3-ffv1.3-bgr create mode 100644 tests/ref/vsynth/vsynth_lena-ffv1.3-420 create mode 100644 tests/ref/vsynth/vsynth_lena-ffv1.3-422p10 create mode 100644 tests/ref/vsynth/vsynth_lena-ffv1.3-444p16 create mode 100644 tests/ref/vsynth/vsynth_lena-ffv1.3-bgr diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak index 1ad5e96..f282d1c 100644 --- a/tests/fate/vcodec.mak +++ b/tests/fate/vcodec.mak @@ -68,9 +68,19 @@ fate-vsynth%-dv-50: ENCOPTS = -dct int -s pal -pix_fmt yuv422p \ fate-vsynth%-dv-50: DECOPTS = -sws_flags neighbor fate-vsynth%-dv-50: FMT = dv -FATE_VCODEC-$(call ENCDEC, FFV1, AVI) += ffv1 ffv1.0 +FATE_VCODEC-$(call ENCDEC, FFV1, AVI) += ffv1 ffv1.0 ffv1.3-420 ffv1.3-422p10 ffv1.3-444p16 ffv1.3-bgr fate-vsynth%-ffv1: ENCOPTS = -slices 4 fate-vsynth%-ffv1.0: CODEC = ffv1 +fate-vsynth%-ffv1.3-420: ENCOPTS = -vcodec ffv1 -level 3 -pix_fmt yuv420p +fate-vsynth%-ffv1.3-422p10: ENCOPTS = -vcodec ffv1 -level 3 -pix_fmt yuv422p10le \ + -sws_flags neighbor+bitexact +fate-vsynth%-ffv1.3-422p10: DECOPTS = -sws_flags neighbor+bitexact +fate-vsynth%-ffv1.3-444p16: ENCOPTS = -vcodec ffv1 -level 3 -pix_fmt yuv444p16le \ +
Re: [FFmpeg-devel] [PATCH] Fixed EA vp6 files with alpha not picked up by the EA demuxer
You should get a crash when trying to play this file with ffplay or when trying to open it with avformat_open_input. (Before the patch is applied). Stephan Am 22.06.2015 um 16:41 schrieb Carl Eugen Hoyos ceho...@ag.or.at: stephan.vedder at gmail.com writes: https://bfme2-see.googlecode.com/svn-history/r129/trunk/data/movies/SmallRing.vp6 Before you had to use: ffplay -f ./SmallRing.vp6 since it would use the aac demuxer otherwise (resulting in a crash). How can I reproduce the crash? Crashes are always (very) important, but I cannot reproduce... Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 6/22/2015 6:52 PM, Michael Niedermayer wrote: When and where ? Example: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/179883 And also *constantly* on IRC, although I am sure IRC doesn't count or somesuch. My argument then is the same as now: this does not belong in libav*. It belongs in the player or user application who uses the libav* API. (And before you say but that is for smb, the argument is the same, and the end goal and author+mentor are the same. It's the same issue.) You may also recall I brought up the fact that the GSOC qualification task was mostly reworking the patch set from Lukasz, and thinking that was a bit sketchy. P.S. I'm getting pretty tired of the demand for proof every time a bad design shows itself for the Nth time. A bad design is a bad design. The burden is on the designer to prove it is WORTH including, not the other way around. The burden should not be on the review to have to respond and register their dissent for every Nth iteration of an idea or patch set, lest it be pushed through anyway, be it as a GSOC or patch set. If it was bad once, it is still bad. Also, the Browsing content on the server project was added 17 months ago to the GSoC 2014 page: https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2014?confirm_email=email_confirm=action=diffversion=28old_version=27confirm_email=email_confirm= Thats a long time prior to GSoC 2015 in which anyone could have removed it if they wanted, its a publically editable wiki basically And pissed off Lukasz? And theres another aspect to this, theres quite some code that needs the rename function (git grep ff_rename). What options exist here 1. leave it so it only works with local files [...] 2. support other protocols than file:// by the API here 3. support other protocols than file:// by some other API protocol indeed. 4. remove the code that uses ff_rename (hls, hds, dash, smoothstreaming, ...) Very funny. I might be wrong but i think people really like none of the options here for 3. also some other API would need to be suggested, this may very well be the solution if someone does have a better idea for a better API, that is one that everyone likes or at least can live with Yes, let us dump every idea someone has into libav*. Everything belongs in libav. also another use case for this may be simple cleanup on errors, a muxer might (possibly not by default if people prefer) remove files that failed to be created at an early stage [...] that is for example when writing the header fails in the middle and before any content is stored in a file deleting the file is probably what some users would want ... Probably what some users want can pretty much be quoted as the reasoning for every insane design choice in libav*... Also lets rather encourage work toward a solution, everyone is happy with instead of disencouraging people from working I don't think encouraging work just for the sake of encouraging work is a good idea. It leads to bad technical design is we just go well we shouldn't discourage work, even if it's a bad idea. I get now it's too late as it was registered for GSOC, but crikey. Bonus random IRC logs found by grepping for directory listing in #ffmpeg-devel: 17:54 cone-632 ffmpeg Lukasz Marek master:184084c6998c: lavf: add directory listing API 18:02 +wm4 Daemon404: shit ^ 18:02 +wm4 damage done, maintain forever 18:05 @Daemon404 D: Days later: 16:38 +kierank ffmpeg has too much mission creep 16:38 +kierank an in built web server 16:38 +kierank directory listing api 16:38 +kierank wtf 16:40 @iive avsystemd 16:40 @BBB_ yeah the directory listing api kind of confused me 16:41 rcombs isn't that supposed to be MKV ordered chapters and such 16:41 @BBB_ as long as I can disable it I don't care I guess 16:41 +wm4 rcombs: fuck no 16:41 rcombs well then I have no idea what that's for then 16:41 +wm4 nobody knows 16:42 +wm4 because Lukasz wanted it and mini can't say no? 16:42 +kierank wm4: ding ding ding - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 6/22/2015 9:15 PM, Mariusz Szczepańczyk wrote: Thank you for clarification. I understand there are people who are not happy with additions like this. However, there are also people who think these changes are needed and trying to stop them just because we don't want this here or worse, making fun of their work is not the way to go to be honest. Considering whether a feature should be in a particular library by design is a legitimate consideration. You can't just blindly accept all features someone might find useful. Some may also think a GUI toolkit and X protocol implementation would be awesome to have in libav*, but does it belong? No. May I add, that I do not think pushing through APIs and and design choices that have registered dissent is kinda of sketchy at best. That is not on you though, and I apologize for dragging your GSOC application into it. (Also I'm not making fun of your work. If you point out where I've done that, I'd be glad to retract and apologize.) I don't really know how/when this conflict started or have your complaints been answered or not but it seems to me there are some of you who are really frustrated with the direction ffmpeg have taken. Yes, it predates your GSOC task, and involves your mentor. Again, apologies for it being dumped on you in this thread. So why don't you propose something constructive, e.g. partition into distinct libraries so muxing/demuxing code is not getting spoiled? There must be some kind of solution everyone can agree with. We did. We proposed it is *not* the task of libav* to do this. It belongs in the layer above, in the application (e.g. a player). And indeed, this is what VLC and mplayer/mpv already do. Your mentor is the only one who decided it belongs here, because he wanted to use it. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fixed EA vp6 files with alpha not picked up by the EA demuxer
stephan.vedder at gmail.com writes: https://bfme2-see.googlecode.com/svn-history/r129/trunk/data/movies/SmallRing.vp6 Do you know how to decode the alpha channel for this file? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 6/22/2015 11:58 PM, Mariusz Szczepańczyk wrote: I don't think it's fair to say Lukasz is the only one standing for these changes. But let's not make it personal and hold on any grudges for a moment. I hold no ill will against anyone, as long as no ill will is held against me. I do, however, think it was pretty dishonest of some people to push this forward as a GSOC project when there was internal dissent for it (on IRC, on the ffmpeg-mentor list, etc.). This is of course not your problem, nor should it be. We're here now, so we should make the best of it. My point is that ongoing fights like this are counterproductive and only discourage people from contributing into open source. I also think everyone wants the best for the project regardless they are pro or against the changes. Agreed. I see the current situation is as follows: there is increasing amount of code in libav* that you and some others find out of place. This is obviously not good. Is there any viable solution not involving removing functionality from ffmpeg would you agree on and make adding changes like this less painful? What do you think about making a temporary fork, moving things around there and showing something that is satisfactory to you? The crux of the issue here is that there is disagreement on whether some features should be in libav* at all. It's separation of functionality. It's not really possible to show something satisfactory when it's the wrong place for it in the first place, in someone's mind. I speak for myself here, only, of course. Take it with a grain of salt. As far as I see this situation, the damage is done already (it's in libav*), so we may as well make it (the API) as decent as possible. (P.S. I wouldn't use the word fork here, people get angsty :P) - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On Mon, Jun 22, 2015 at 11:31 PM, Derek Buitenhuis derek.buitenh...@gmail.com wrote: On 6/22/2015 9:15 PM, Mariusz Szczepańczyk wrote: Thank you for clarification. I understand there are people who are not happy with additions like this. However, there are also people who think these changes are needed and trying to stop them just because we don't want this here or worse, making fun of their work is not the way to go to be honest. Considering whether a feature should be in a particular library by design is a legitimate consideration. You can't just blindly accept all features someone might find useful. Some may also think a GUI toolkit and X protocol implementation would be awesome to have in libav*, but does it belong? No. May I add, that I do not think pushing through APIs and and design choices that have registered dissent is kinda of sketchy at best. That is not on you though, and I apologize for dragging your GSOC application into it. (Also I'm not making fun of your work. If you point out where I've done that, I'd be glad to retract and apologize.) No offence taken. Actually this remark wasn't directed at you any way, just an observation of what's going on in this thread (and some other). I don't really know how/when this conflict started or have your complaints been answered or not but it seems to me there are some of you who are really frustrated with the direction ffmpeg have taken. Yes, it predates your GSOC task, and involves your mentor. Again, apologies for it being dumped on you in this thread. So why don't you propose something constructive, e.g. partition into distinct libraries so muxing/demuxing code is not getting spoiled? There must be some kind of solution everyone can agree with. We did. We proposed it is *not* the task of libav* to do this. It belongs in the layer above, in the application (e.g. a player). And indeed, this is what VLC and mplayer/mpv already do. Your mentor is the only one who decided it belongs here, because he wanted to use it. I don't think it's fair to say Lukasz is the only one standing for these changes. But let's not make it personal and hold on any grudges for a moment. My point is that ongoing fights like this are counterproductive and only discourage people from contributing into open source. I also think everyone wants the best for the project regardless they are pro or against the changes. I see the current situation is as follows: there is increasing amount of code in libav* that you and some others find out of place. This is obviously not good. Is there any viable solution not involving removing functionality from ffmpeg would you agree on and make adding changes like this less painful? What do you think about making a temporary fork, moving things around there and showing something that is satisfactory to you? Mariusz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On Mon, Jun 22, 2015 at 08:46:01PM -0300, Reynaldo H. Verdejo Pinochet wrote: Hi everyone Not really getting into the whole discussion on blocking remarks to a running (sponsored) project. I sincerely hope we all agree that once work has started on these, we should try to be constructive and let the student do their job while benefiting from all we can feed to them on the do-it-better side. Now, on the hopes of being constructive: I do understand resource renaming and removing are borderline use cases, but I also see the need for such functionality when, for instance, there's no easy way to properly inform the application about what and how to rename/move. It been a protocol:// issue, a loosely defined naming%0Xd*.ext convention, etc (there are similar examples for renaming). Lacking a better solution and considering we should be at least responsible for our own cleanup, I'd just make sure this API stays in the avpriv_ realm and work together on designing a solution that would let us have this functionality available for internal use while being maintainable , have good platform coverage, and be as uncluttered (use-case wise) as it can possibly be. +1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On Mon, Jun 22, 2015 at 10:31:00PM +0100, Derek Buitenhuis wrote: [...] Your mentor is the only one who decided it belongs here, because he wanted to use it. Please stop the finger pointing and work toward a resolution of this its not just one man, iam not even sure he intended to use it himself. [...] -- 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 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 6/22/2015 10:24 PM, Derek Buitenhuis wrote: You may also recall I brought up the fact that the GSOC qualification task was mostly reworking the patch set from Lukasz, and thinking that was a bit sketchy. I went and looked. It wad *directly* brought up by Keiran on ffmpeg-mentors. He was, of course, shat on. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 6/23/2015 12:46 AM, Reynaldo H. Verdejo Pinochet wrote: Not really getting into the whole discussion on blocking remarks to a running (sponsored) project. I sincerely hope we all agree that once work has started on these, we should try to be constructive and let the student do their job while benefiting from all we can feed to them on the do-it-better side. As noted in my other mail(s), I agree, since work has started already on GSOC. I do understand resource renaming and removing are borderline use cases, but I also see the need for such functionality when, for instance, there's no easy way to properly inform the application about what and how to rename/move. It been a protocol:// issue, a loosely defined naming%0Xd*.ext convention, etc (there are similar examples for renaming). Lacking a better solution and considering we should be at least responsible for our own cleanup, I'd just make sure this API stays in the avpriv_ realm and work together on designing a solution that would let us have this functionality available for internal use while being maintainable , have good platform coverage, and be as uncluttered (use-case wise) as it can possibly be. That's the most reasonable thing I've read so far. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] lavf/libssh: implement move and delete callbacks
---
libavformat/libssh.c | 82
1 file changed, 82 insertions(+)
diff --git a/libavformat/libssh.c b/libavformat/libssh.c
index ee8fd7e..31b6f6a 100644
--- a/libavformat/libssh.c
+++ b/libavformat/libssh.c
@@ -392,6 +392,86 @@ static int libssh_close_dir(URLContext *h)
return -1;
}
+static int libssh_delete(URLContext *h)
+{
+int ret;
+LIBSSHContext *libssh = h-priv_data;
+sftp_attributes attr = NULL;
+char path[MAX_URL_SIZE];
+
+if ((ret = libssh_connect(h, h-filename, path, sizeof(path))) 0)
+goto cleanup;
+
+if (!(attr = sftp_stat(libssh-sftp, path))) {
+ret = AVERROR(sftp_get_error(libssh-sftp));
+goto cleanup;
+}
+
+if (attr-type == SSH_FILEXFER_TYPE_DIRECTORY) {
+if (sftp_rmdir(libssh-sftp, path) 0) {
+ret = AVERROR(sftp_get_error(libssh-sftp));
+goto cleanup;
+}
+} else {
+if (sftp_unlink(libssh-sftp, path) 0) {
+ret = AVERROR(sftp_get_error(libssh-sftp));
+goto cleanup;
+}
+}
+
+ret = 0;
+
+cleanup:
+if (attr)
+sftp_attributes_free(attr);
+libssh_close(h);
+return ret;
+}
+
+static int libssh_move(URLContext *h_src, URLContext *h_dst)
+{
+int ret;
+LIBSSHContext *libssh = h_src-priv_data;
+char path_src[MAX_URL_SIZE], path_dst[MAX_URL_SIZE];
+char hostname_src[1024], hostname_dst[1024];
+char credentials_src[1024], credentials_dst[1024];
+int port_src = 22, port_dst = 22;
+
+av_url_split(NULL, 0,
+ credentials_src, sizeof(credentials_src),
+ hostname_src, sizeof(hostname_src),
+ port_src,
+ path_src, sizeof(path_src),
+ h_src-filename);
+
+av_url_split(NULL, 0,
+ credentials_dst, sizeof(credentials_dst),
+ hostname_dst, sizeof(hostname_dst),
+ port_dst,
+ path_dst, sizeof(path_dst),
+ h_dst-filename);
+
+if (strcmp(credentials_src, credentials_dst) ||
+strcmp(hostname_src, hostname_dst) ||
+port_src != port_dst) {
+return AVERROR(EINVAL);
+}
+
+if ((ret = libssh_connect(h_src, h_src-filename, path_src,
sizeof(path_src))) 0)
+goto cleanup;
+
+if (sftp_rename(libssh-sftp, path_src, path_dst) 0) {
+ret = AVERROR(sftp_get_error(libssh-sftp));
+goto cleanup;
+}
+
+ret = 0;
+
+cleanup:
+libssh_close(h_src);
+return ret;
+}
+
#define OFFSET(x) offsetof(LIBSSHContext, x)
#define D AV_OPT_FLAG_DECODING_PARAM
#define E AV_OPT_FLAG_ENCODING_PARAM
@@ -416,6 +496,8 @@ URLProtocol ff_libssh_protocol = {
.url_write = libssh_write,
.url_seek= libssh_seek,
.url_close = libssh_close,
+.url_delete = libssh_delete,
+.url_move= libssh_move,
.url_open_dir= libssh_open_dir,
.url_read_dir= libssh_read_dir,
.url_close_dir = libssh_close_dir,
--
2.3.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] lavf/libssh: implement directory listing callbacks
From: Lukasz Marek lukasz.m.lu...@gmail.com
Signed-off-by: Lukasz Marek lukasz.m.luki2 at gmail.com
---
libavformat/libssh.c | 111 ---
1 file changed, 105 insertions(+), 6 deletions(-)
diff --git a/libavformat/libssh.c b/libavformat/libssh.c
index fac6114..150c037 100644
--- a/libavformat/libssh.c
+++ b/libavformat/libssh.c
@@ -24,6 +24,7 @@
#include libavutil/avstring.h
#include libavutil/opt.h
#include libavutil/attributes.h
+#include libavformat/avio.h
#include avformat.h
#include internal.h
#include url.h
@@ -33,6 +34,7 @@ typedef struct {
ssh_session session;
sftp_session sftp;
sftp_file file;
+sftp_dir dir;
int64_t filesize;
int rw_timeout;
int trunc;
@@ -187,11 +189,11 @@ static av_cold int libssh_close(URLContext *h)
return 0;
}
-static av_cold int libssh_open(URLContext *h, const char *url, int flags)
+static av_cold int libssh_connect(URLContext *h, const char *url, char *path,
size_t path_size)
{
LIBSSHContext *libssh = h-priv_data;
-char proto[10], path[MAX_URL_SIZE], hostname[1024], credencials[1024];
-int port, ret;
+char proto[10], hostname[1024], credencials[1024];
+int port = 22, ret;
const char *user = NULL, *pass = NULL;
char *end = NULL;
@@ -199,7 +201,7 @@ static av_cold int libssh_open(URLContext *h, const char
*url, int flags)
credencials, sizeof(credencials),
hostname, sizeof(hostname),
port,
- path, sizeof(path),
+ path, path_size,
url);
// a port of 0 will use a port from ~/.ssh/config or the default value 22
@@ -207,15 +209,27 @@ static av_cold int libssh_open(URLContext *h, const char
*url, int flags)
port = 0;
if ((ret = libssh_create_ssh_session(libssh, hostname, port)) 0)
-goto fail;
+return ret;
user = av_strtok(credencials, :, end);
pass = av_strtok(end, :, end);
if ((ret = libssh_authentication(libssh, user, pass)) 0)
-goto fail;
+return ret;
if ((ret = libssh_create_sftp_session(libssh)) 0)
+return ret;
+
+return 0;
+}
+
+static av_cold int libssh_open(URLContext *h, const char *url, int flags)
+{
+int ret;
+LIBSSHContext *libssh = h-priv_data;
+char path[MAX_URL_SIZE];
+
+if ((ret = libssh_connect(h, url, path, sizeof(path))) 0)
goto fail;
if ((ret = libssh_open_file(libssh, flags, path)) 0)
@@ -293,6 +307,88 @@ static int libssh_write(URLContext *h, const unsigned char
*buf, int size)
return bytes_written;
}
+static int libssh_open_dir(URLContext *h)
+{
+LIBSSHContext *libssh = h-priv_data;
+int ret;
+char path[MAX_URL_SIZE];
+
+if ((ret = libssh_connect(h, h-filename, path, sizeof(path))) 0)
+goto fail;
+
+if (!(libssh-dir = sftp_opendir(libssh-sftp, path))) {
+av_log(libssh, AV_LOG_ERROR, Error opening sftp dir: %s\n,
ssh_get_error(libssh-session));
+ret = AVERROR(EIO);
+goto fail;
+}
+
+return 0;
+
+ fail:
+libssh_close(h);
+return ret;
+}
+
+static int libssh_read_dir(URLContext *h, AVIODirEntry **next)
+{
+LIBSSHContext *libssh = h-priv_data;
+sftp_attributes attr = NULL;
+AVIODirEntry *entry;
+
+*next = entry = ff_alloc_dir_entry();
+if (!entry)
+return AVERROR(ENOMEM);
+
+do {
+if (attr)
+sftp_attributes_free(attr);
+attr = sftp_readdir(libssh-sftp, libssh-dir);
+if (!attr) {
+av_freep(next);
+if (sftp_dir_eof(libssh-dir))
+return 0;
+return AVERROR(EIO);
+}
+} while (!strcmp(attr-name, .) || !strcmp(attr-name, ..));
+
+entry-name = av_strdup(attr-name);
+entry-group_id = attr-gid;
+entry-user_id = attr-uid;
+entry-size = attr-size;
+entry-access_timestamp = INT64_C(100) * attr-atime;
+entry-modification_timestamp = INT64_C(100) * attr-mtime;
+entry-filemode = attr-permissions 0777;
+switch(attr-type) {
+case SSH_FILEXFER_TYPE_REGULAR:
+entry-type = AVIO_ENTRY_FILE;
+break;
+case SSH_FILEXFER_TYPE_DIRECTORY:
+entry-type = AVIO_ENTRY_DIRECTORY;
+break;
+case SSH_FILEXFER_TYPE_SYMLINK:
+entry-type = AVIO_ENTRY_SYMBOLIC_LINK;
+break;
+case SSH_FILEXFER_TYPE_SPECIAL:
+/* Special type includes: sockets, char devices, block devices and
pipes.
+ It is probably better to return unknown type, to not confuse
anybody. */
+case SSH_FILEXFER_TYPE_UNKNOWN:
+default:
+entry-type = AVIO_ENTRY_UNKNOWN;
+}
+sftp_attributes_free(attr);
+return 0;
+}
+
+static int libssh_close_dir(URLContext *h)
+{
+LIBSSHContext *libssh = h-priv_data;
+if (libssh-dir)
+sftp_closedir(libssh-dir);
+libssh-dir = NULL;
+libssh_close(h);
+return -1;
+}
[FFmpeg-devel] [PATCH 2/3] lavf/libssh: read empty path from url as /
--- libavformat/libssh.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavformat/libssh.c b/libavformat/libssh.c index 150c037..ee8fd7e 100644 --- a/libavformat/libssh.c +++ b/libavformat/libssh.c @@ -204,6 +204,9 @@ static av_cold int libssh_connect(URLContext *h, const char *url, char *path, si path, path_size, url); +if (!(*path)) +av_strlcpy(path, /, path_size); + // a port of 0 will use a port from ~/.ssh/config or the default value 22 if (port 0 || port 65535) port = 0; -- 2.3.6 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/3] [GSoC] lavf/libssh: directory listing and move/delete callbacks
Lukasz Marek (1): lavf/libssh: implement directory listing callbacks Mariusz Szczepańczyk (2): lavf/libssh: read empty path from url as / lavf/libssh: implement move and delete callbacks libavformat/libssh.c | 196 +-- 1 file changed, 190 insertions(+), 6 deletions(-) -- 2.3.6 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 6/22/2015 11:18 PM, Michael Niedermayer wrote: Please stop the finger pointing and work toward a resolution of this its not just one man, iam not even sure he intended to use it himself. I agree I was a too aggressive. However, I am not aware of a single person. As for working towards a resolution, I don't think that will happen, since it shouldn't have been done at all / it should not be done at all is likely not an acceptable solution to those involved. Instead, I will relegate myself to being an annoying guy on IRC, and leave the thread be. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 6/22/2015 10:31 PM, Derek Buitenhuis wrote: That is not on you though, and I apologize for dragging your GSOC application into it. To follow up on this, I do understand how GSOC works, and it is too late to say 'no' to this, and I feel bad for you having negatives dumped on you like this. I suppose you should continue on. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: Add H264 API test
On Mon, Jun 22, 2015 at 12:50:21PM +0300, Ludmila Glinskih wrote: I really don't know how to avoid warnings in printf. in: libavformat/api-h264-test.c: In function ‘video_decode_example’: libavformat/api-h264-test.c:113:25: warning: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘int64_t’ [-Wformat] libavformat/api-h264-test.c:113:25: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 7 has type ‘long unsigned int’ [-Wformat] gcc counts the number of arguments to the function not just the printed arguments so in printf(%d, %10PRId64, %10PRId64, %8d, %8d, 0x%08PRIx32\n, ^ is the 2nd ^ is the 3rd its not exactly logic but thats how gcc counts, this can easily confuse one so the 5th is the first %8d which needs to be a PRId64 or similar the 7th is the '0x%08PRIx32' which needs to be type matching long unsigned int which is 0x%08lx i wonder if theres a complete and clean list somewhere for all the printf() strings for all types, They are in principle written in the C specification but its not exactly the best text to quickly find one for a given type. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf Thanks -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On Sun, Jun 21, 2015 at 05:04:10PM +0200, Mariusz Szczepańczyk wrote:
On 21/06/15 09:37, Timothy Gu wrote:
El sábado, 20 de junio de 2015, Mariusz Szczepańczyk
mszczepanc...@gmail.com mailto:mszczepanc...@gmail.com escribió:
---
doc/APIchanges| 4
libavformat/avio.c| 38 ++
libavformat/avio.h| 19 +++
libavformat/url.h | 2 ++
libavformat/version.h | 2 +-
5 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 6e64a05..a9efd12 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -17,6 +17,10 @@ API changes, most recent first:
8 - FFmpeg 2.7 was cut here 8 -
+2015-xx-xx - xxx - lavf 56.38.100 - avio.h url.h
+ Add avio_move(), avio_delete().
+ Extend URLProtocol with url_move(), url_delete().
+
This goes above the 2.7 release cut line.
Timothy
You're right. Thanks!
Mariusz
doc/APIchanges|4
libavformat/avio.c| 38 ++
libavformat/avio.h| 19 +++
libavformat/url.h |2 ++
libavformat/version.h |2 +-
5 files changed, 64 insertions(+), 1 deletion(-)
1a7bf656f7e0a71b313c14fad1684083b148636a
0001-lavf-avio-Extend-API-with-avio_move-and-avio_delete.patch
From 283f81e40b8776ac485e0e575ba351618a5c2332 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mariusz=20Szczepa=C5=84czyk?= mszczepanc...@gmail.com
Date: Wed, 17 Jun 2015 20:12:00 +0200
Subject: [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Observe your enemies, for they first find out your faults. -- Antisthenes
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 6/21/2015 8:04 PM, Mariusz Szczepańczyk wrote: Anyway, this is a part of my GSoC task that has been accepted and I'm compelled to implement it so I won't be getting into further discussion. Let's just say a large portion of the community didn't and don't think this idea has any place in libav* in the first place, but were ignored, or our complaints pushed aside. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fate: add some tests for ffv1 level 3 with 8/10/16 bps
Attached patch adds some FATE tests for FFV1 level 3 with different bits-per-sample. From aee3721703e8530bb71f85daf4b4438ed170f612 Mon Sep 17 00:00:00 2001 From: Tobias Rapp t.r...@noa-audio.com Date: Fri, 19 Jun 2015 14:30:27 +0200 Subject: [PATCH] fate: add some tests for ffv1 level 3 with 8/10/16 bps --- tests/fate/vcodec.mak | 6 +- tests/ref/vsynth/vsynth1-ffv1.3-420| 4 tests/ref/vsynth/vsynth1-ffv1.3-422p10 | 4 tests/ref/vsynth/vsynth1-ffv1.3-444p16 | 4 tests/ref/vsynth/vsynth1-ffv1.3-bgr| 4 tests/ref/vsynth/vsynth2-ffv1.3-420| 4 tests/ref/vsynth/vsynth2-ffv1.3-422p10 | 4 tests/ref/vsynth/vsynth2-ffv1.3-444p16 | 4 tests/ref/vsynth/vsynth2-ffv1.3-bgr| 4 tests/ref/vsynth/vsynth3-ffv1.3-420| 4 tests/ref/vsynth/vsynth3-ffv1.3-422p10 | 4 tests/ref/vsynth/vsynth3-ffv1.3-444p16 | 4 tests/ref/vsynth/vsynth3-ffv1.3-bgr| 4 tests/ref/vsynth/vsynth_lena-ffv1.3-420| 4 tests/ref/vsynth/vsynth_lena-ffv1.3-422p10 | 4 tests/ref/vsynth/vsynth_lena-ffv1.3-444p16 | 4 tests/ref/vsynth/vsynth_lena-ffv1.3-bgr| 4 17 files changed, 69 insertions(+), 1 deletion(-) create mode 100644 tests/ref/vsynth/vsynth1-ffv1.3-420 create mode 100644 tests/ref/vsynth/vsynth1-ffv1.3-422p10 create mode 100644 tests/ref/vsynth/vsynth1-ffv1.3-444p16 create mode 100644 tests/ref/vsynth/vsynth1-ffv1.3-bgr create mode 100644 tests/ref/vsynth/vsynth2-ffv1.3-420 create mode 100644 tests/ref/vsynth/vsynth2-ffv1.3-422p10 create mode 100644 tests/ref/vsynth/vsynth2-ffv1.3-444p16 create mode 100644 tests/ref/vsynth/vsynth2-ffv1.3-bgr create mode 100644 tests/ref/vsynth/vsynth3-ffv1.3-420 create mode 100644 tests/ref/vsynth/vsynth3-ffv1.3-422p10 create mode 100644 tests/ref/vsynth/vsynth3-ffv1.3-444p16 create mode 100644 tests/ref/vsynth/vsynth3-ffv1.3-bgr create mode 100644 tests/ref/vsynth/vsynth_lena-ffv1.3-420 create mode 100644 tests/ref/vsynth/vsynth_lena-ffv1.3-422p10 create mode 100644 tests/ref/vsynth/vsynth_lena-ffv1.3-444p16 create mode 100644 tests/ref/vsynth/vsynth_lena-ffv1.3-bgr diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak index 1ad5e96..b5d96cb 100644 --- a/tests/fate/vcodec.mak +++ b/tests/fate/vcodec.mak @@ -68,9 +68,13 @@ fate-vsynth%-dv-50: ENCOPTS = -dct int -s pal -pix_fmt yuv422p \ fate-vsynth%-dv-50: DECOPTS = -sws_flags neighbor fate-vsynth%-dv-50: FMT = dv -FATE_VCODEC-$(call ENCDEC, FFV1, AVI) += ffv1 ffv1.0 +FATE_VCODEC-$(call ENCDEC, FFV1, AVI) += ffv1 ffv1.0 ffv1.3-420 ffv1.3-422p10 ffv1.3-444p16 ffv1.3-bgr fate-vsynth%-ffv1: ENCOPTS = -slices 4 fate-vsynth%-ffv1.0: CODEC = ffv1 +fate-vsynth%-ffv1.3-420: ENCOPTS = -vcodec ffv1 -level 3 -pix_fmt yuv420p +fate-vsynth%-ffv1.3-422p10: ENCOPTS = -vcodec ffv1 -level 3 -pix_fmt yuv422p10le +fate-vsynth%-ffv1.3-444p16: ENCOPTS = -vcodec ffv1 -level 3 -pix_fmt yuv444p16le +fate-vsynth%-ffv1.3-bgr: ENCOPTS = -vcodec ffv1 -level 3 -pix_fmt bgr0 FATE_VCODEC-$(call ENCDEC, FFVHUFF, AVI) += ffvhuff ffvhuff444 ffvhuff420p12 ffvhuff422p10left ffvhuff444p16 fate-vsynth%-ffvhuff444: ENCOPTS = -vcodec ffvhuff -pix_fmt yuv444p diff --git a/tests/ref/vsynth/vsynth1-ffv1.3-420 b/tests/ref/vsynth/vsynth1-ffv1.3-420 new file mode 100644 index 000..08c5764 --- /dev/null +++ b/tests/ref/vsynth/vsynth1-ffv1.3-420 @@ -0,0 +1,4 @@ +26b1296a0ef80a3b5c8b63cc57c52bc2 *tests/data/fate/vsynth1-ffv1.3-420.avi +2691268 tests/data/fate/vsynth1-ffv1.3-420.avi +c5ccac874dbf808e9088bc3107860042 *tests/data/fate/vsynth1-ffv1.3-420.out.rawvideo +stddev:0.00 PSNR:999.99 MAXDIFF:0 bytes: 7603200/ 7603200 diff --git a/tests/ref/vsynth/vsynth1-ffv1.3-422p10 b/tests/ref/vsynth/vsynth1-ffv1.3-422p10 new file mode 100644 index 000..d9277a6 --- /dev/null +++ b/tests/ref/vsynth/vsynth1-ffv1.3-422p10 @@ -0,0 +1,4 @@ +b13f8fe6c5e5dc227a7fa631849b7e57 *tests/data/fate/vsynth1-ffv1.3-422p10.avi +4232950 tests/data/fate/vsynth1-ffv1.3-422p10.avi +c31e6caada921ffa3daad3432ef3b754 *tests/data/fate/vsynth1-ffv1.3-422p10.out.rawvideo +stddev:1.85 PSNR: 42.78 MAXDIFF: 29 bytes: 7603200/ 7603200 diff --git a/tests/ref/vsynth/vsynth1-ffv1.3-444p16 b/tests/ref/vsynth/vsynth1-ffv1.3-444p16 new file mode 100644 index 000..686c18c --- /dev/null +++ b/tests/ref/vsynth/vsynth1-ffv1.3-444p16 @@ -0,0 +1,4 @@ +275437a8871af0b31c995b22656ae6db *tests/data/fate/vsynth1-ffv1.3-444p16.avi +17491876 tests/data/fate/vsynth1-ffv1.3-444p16.avi +ee8379fa217dfd023de3aa6974a14d1e *tests/data/fate/vsynth1-ffv1.3-444p16.out.rawvideo +stddev:2.66 PSNR: 39.62 MAXDIFF: 44 bytes: 7603200/ 7603200 diff --git a/tests/ref/vsynth/vsynth1-ffv1.3-bgr b/tests/ref/vsynth/vsynth1-ffv1.3-bgr new file mode 100644 index 000..524c4e2 --- /dev/null +++
[FFmpeg-devel] [PATCH] libavformat: Add H264 API test
I really don't know how to avoid warnings in printf. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavformat: Add H264 API test
Result differs in pkt_duration and time_base.den for some reason.
Right now it tests only one example (adjusted to match the output).
Signed-off-by: Ludmila Glinskih lglins...@gmail.com
---
libavformat/Makefile| 1 +
libavformat/api-h264-test.c | 155
tests/fate/libavformat.mak | 4 ++
tests/ref/fate/api-h264 | 18 +
4 files changed, 178 insertions(+)
create mode 100644 libavformat/api-h264-test.c
create mode 100644 tests/ref/fate/api-h264
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 993ec09..5cc0f6c 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -547,6 +547,7 @@ TESTPROGS = seek
\
url \
TESTPROGS-$(CONFIG_NETWORK) += noproxy
+TESTPROGS-yes += api-h264
TESTPROGS-$(CONFIG_FFRTMPCRYPT_PROTOCOL) += rtmpdh
TOOLS = aviocat \
diff --git a/libavformat/api-h264-test.c b/libavformat/api-h264-test.c
new file mode 100644
index 000..e25c8f0
--- /dev/null
+++ b/libavformat/api-h264-test.c
@@ -0,0 +1,155 @@
+/*
+ * Copyright (c) 2015 Ludmila Glinskih
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/**
+ * H264 codec test.
+ */
+
+#include math.h
+
+#include libavutil/opt.h
+#include libavutil/adler32.h
+#include libavcodec/avcodec.h
+#include libavformat/avformat.h
+#include libavutil/common.h
+#include libavutil/imgutils.h
+#include libavutil/samplefmt.h
+#include libavformat/internal.h
+
+static int video_decode_example(const char *input_filename)
+{
+AVCodec *codec = NULL;
+AVCodecContext *origin_ctx = NULL, *ctx= NULL;
+AVFrame *fr = NULL;
+uint8_t *byte_buffer = NULL;
+AVPacket pkt;
+AVFormatContext *fmt_ctx = NULL;
+int number_of_written_bytes;
+int video_stream;
+int get_frame = 0;
+int byte_buffer_size;
+int i = 0;
+
+
+if (avformat_open_input(fmt_ctx, input_filename, NULL, NULL) 0) {
+fprintf(stderr, Could not open source file %s\n, input_filename);
+exit(1);
+}
+
+if (avformat_find_stream_info(fmt_ctx, NULL) 0) {
+fprintf(stderr, Could not find stream information\n);
+exit(1);
+}
+
+video_stream = -1;
+for (i = 0; i fmt_ctx-nb_streams; i++) {
+if (fmt_ctx-streams[i]-codec-codec_type == AVMEDIA_TYPE_VIDEO) {
+video_stream = i;
+break;
+}
+}
+
+origin_ctx = fmt_ctx-streams[video_stream]-codec;
+
+codec = avcodec_find_decoder(origin_ctx-codec_id);
+if (codec == NULL) {
+return -1;
+}
+ctx = avcodec_alloc_context3(codec);
+if (ctx == NULL) {
+return -1;
+}
+
+if (avcodec_copy_context(ctx, origin_ctx)) {
+return -1;
+}
+
+if (avcodec_open2(ctx, codec, NULL) 0) {
+return -1;
+}
+
+fr = av_frame_alloc();
+if (fr == NULL) {
+return -1;
+}
+
+byte_buffer_size = av_image_get_buffer_size(ctx-pix_fmt, ctx-width,
ctx-height, 16);
+byte_buffer = av_malloc(byte_buffer_size);
+
+printf(#tb %d: %d/%d\n, video_stream,
fmt_ctx-streams[video_stream]-time_base.num,
fmt_ctx-streams[video_stream]-time_base.den);
+i = 0;
+av_init_packet(pkt);
+while (av_read_frame(fmt_ctx, pkt) = 0) {
+if (pkt.stream_index == video_stream) {
+get_frame = 0;
+if (pkt.pts == AV_NOPTS_VALUE)
+pkt.pts = pkt.dts = i;
+avcodec_decode_video2(ctx, fr, get_frame, pkt);
+if (get_frame) {
+number_of_written_bytes = av_image_copy_to_buffer(byte_buffer,
byte_buffer_size,
+(const uint8_t* const *)fr-data,
(const int*) fr-linesize,
+ctx-pix_fmt, ctx-width, ctx-height,
1);
+
Re: [FFmpeg-devel] [PATCH] yuv4mpeg: add rough duration estimate and seeking.
On Mon, Jun 22, 2015 at 11:02 AM, wm4 nfx...@googlemail.com wrote: On Sun, 21 Jun 2015 18:34:33 -0400 Ronald S. Bultje rsbul...@gmail.com wrote: Hi, On Sun, Jun 21, 2015 at 5:17 PM, Hendrik Leppkes h.lepp...@gmail.com wrote: On Sun, Jun 21, 2015 at 10:41 PM, Ronald S. Bultje rsbul...@gmail.com wrote: --- libavformat/yuv4mpeg.h| 1 + libavformat/yuv4mpegdec.c | 26 +++--- 2 files changed, 20 insertions(+), 7 deletions(-) What happens if a seek does not end up on a perfect frame boundary? Wouldn't that entirely screw over any further reading? So is it really that rough, or does it actually work precise enough to do that? It works for all y4m files I see in the wild, but the problem is that the y4m spec is a little confusing. The frame header magic is FRAME, followed by optional per-frame options, and then a \n. This is always empty (i.e. FRAME\n), but in theory it could be non-empty and then this doesn't work. I don't know how much we care about such theoretical files to make a more difficult dur/seek implementation. Why not use generic seeking mode? Add AVFMT_GENERIC_INDEX to the format flags. The utils.c will do seeking by doing byte seeks and using the byte position of previous packets. If you seek forward, it will read and skip packets until the target is reached (for parts of the file that have not been indexed yet). This should be very reliable, but of course seek speed will depend on I/O bandwidth. Generic seeking is rather expensive, and if a format is already strict CBR, doing a seek based on that is probably better. I wonder how hard it would be to write a re-sync function to find the next FRAME header when a seek does actually end up on the wrong spot. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] yuv4mpeg: add rough duration estimate and seeking.
On Sun, 21 Jun 2015 18:34:33 -0400 Ronald S. Bultje rsbul...@gmail.com wrote: Hi, On Sun, Jun 21, 2015 at 5:17 PM, Hendrik Leppkes h.lepp...@gmail.com wrote: On Sun, Jun 21, 2015 at 10:41 PM, Ronald S. Bultje rsbul...@gmail.com wrote: --- libavformat/yuv4mpeg.h| 1 + libavformat/yuv4mpegdec.c | 26 +++--- 2 files changed, 20 insertions(+), 7 deletions(-) What happens if a seek does not end up on a perfect frame boundary? Wouldn't that entirely screw over any further reading? So is it really that rough, or does it actually work precise enough to do that? It works for all y4m files I see in the wild, but the problem is that the y4m spec is a little confusing. The frame header magic is FRAME, followed by optional per-frame options, and then a \n. This is always empty (i.e. FRAME\n), but in theory it could be non-empty and then this doesn't work. I don't know how much we care about such theoretical files to make a more difficult dur/seek implementation. Why not use generic seeking mode? Add AVFMT_GENERIC_INDEX to the format flags. The utils.c will do seeking by doing byte seeks and using the byte position of previous packets. If you seek forward, it will read and skip packets until the target is reached (for parts of the file that have not been indexed yet). This should be very reliable, but of course seek speed will depend on I/O bandwidth. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] yuv4mpeg: add rough duration estimate and seeking.
On Mon, 22 Jun 2015 11:23:55 +0200 Hendrik Leppkes h.lepp...@gmail.com wrote: On Mon, Jun 22, 2015 at 11:02 AM, wm4 nfx...@googlemail.com wrote: On Sun, 21 Jun 2015 18:34:33 -0400 Ronald S. Bultje rsbul...@gmail.com wrote: Hi, On Sun, Jun 21, 2015 at 5:17 PM, Hendrik Leppkes h.lepp...@gmail.com wrote: On Sun, Jun 21, 2015 at 10:41 PM, Ronald S. Bultje rsbul...@gmail.com wrote: --- libavformat/yuv4mpeg.h| 1 + libavformat/yuv4mpegdec.c | 26 +++--- 2 files changed, 20 insertions(+), 7 deletions(-) What happens if a seek does not end up on a perfect frame boundary? Wouldn't that entirely screw over any further reading? So is it really that rough, or does it actually work precise enough to do that? It works for all y4m files I see in the wild, but the problem is that the y4m spec is a little confusing. The frame header magic is FRAME, followed by optional per-frame options, and then a \n. This is always empty (i.e. FRAME\n), but in theory it could be non-empty and then this doesn't work. I don't know how much we care about such theoretical files to make a more difficult dur/seek implementation. Why not use generic seeking mode? Add AVFMT_GENERIC_INDEX to the format flags. The utils.c will do seeking by doing byte seeks and using the byte position of previous packets. If you seek forward, it will read and skip packets until the target is reached (for parts of the file that have not been indexed yet). This should be very reliable, but of course seek speed will depend on I/O bandwidth. Generic seeking is rather expensive, and if a format is already strict CBR, doing a seek based on that is probably better. I wonder how hard it would be to write a re-sync function to find the next FRAME header when a seek does actually end up on the wrong spot. OK, but I'd rather have slow seeking than possibly randomly inaccurate seeking. Maybe the seek mode could be switched on AVFMT_FLAG_FAST_SEEK. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] yuv4mpeg: add rough duration estimate and seeking.
On Mon, 22 Jun 2015 07:52:21 -0400 Ronald S. Bultje rsbul...@gmail.com wrote: Hi, On Mon, Jun 22, 2015 at 6:24 AM, wm4 nfx...@googlemail.com wrote: On Mon, 22 Jun 2015 11:23:55 +0200 Hendrik Leppkes h.lepp...@gmail.com wrote: On Mon, Jun 22, 2015 at 11:02 AM, wm4 nfx...@googlemail.com wrote: On Sun, 21 Jun 2015 18:34:33 -0400 Ronald S. Bultje rsbul...@gmail.com wrote: Hi, On Sun, Jun 21, 2015 at 5:17 PM, Hendrik Leppkes h.lepp...@gmail.com wrote: On Sun, Jun 21, 2015 at 10:41 PM, Ronald S. Bultje rsbul...@gmail.com wrote: --- libavformat/yuv4mpeg.h| 1 + libavformat/yuv4mpegdec.c | 26 +++--- 2 files changed, 20 insertions(+), 7 deletions(-) What happens if a seek does not end up on a perfect frame boundary? Wouldn't that entirely screw over any further reading? So is it really that rough, or does it actually work precise enough to do that? It works for all y4m files I see in the wild, but the problem is that the y4m spec is a little confusing. The frame header magic is FRAME, followed by optional per-frame options, and then a \n. This is always empty (i.e. FRAME\n), but in theory it could be non-empty and then this doesn't work. I don't know how much we care about such theoretical files to make a more difficult dur/seek implementation. Why not use generic seeking mode? Add AVFMT_GENERIC_INDEX to the format flags. The utils.c will do seeking by doing byte seeks and using the byte position of previous packets. If you seek forward, it will read and skip packets until the target is reached (for parts of the file that have not been indexed yet). This should be very reliable, but of course seek speed will depend on I/O bandwidth. Generic seeking is rather expensive, and if a format is already strict CBR, doing a seek based on that is probably better. I wonder how hard it would be to write a re-sync function to find the next FRAME header when a seek does actually end up on the wrong spot. OK, but I'd rather have slow seeking than possibly randomly inaccurate seeking. Maybe the seek mode could be switched on AVFMT_FLAG_FAST_SEEK. Why don't we do that once we start seeing files with frame-headers other than empty FRAME\n in the wild? Right now they are just theoretical... I don't mind. If this happens, it'd be extremely visible anyway, because the pixels won't line up. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fixed EA vp6 files with alpha not picked up by the EA demuxer
I talked with Aurel Jacoubs (the creator of the vp6 deocoder). He said that the implememtation is already capable of decoding this file completly. Apart from that i don't know much about vp6 decoding. However were you able to understand why this patch is required? 2015-06-22 23:22 GMT+02:00 Carl Eugen Hoyos ceho...@ag.or.at: stephan.vedder at gmail.com writes: https://bfme2-see.googlecode.com/svn-history/r129/trunk/data/movies/SmallRing.vp6 Do you know how to decode the alpha channel for this file? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for block functions
On Sun, Jun 14, 2015 at 11:26:25PM +0530, shivraj.pa...@imgtec.com wrote: From: Shivraj Patil shivraj.pa...@imgtec.com This patch adds MSA (MIPS-SIMD-Arch) optimizations for block functions in new file blockdsp_msa.c Signed-off-by: Shivraj Patil shivraj.pa...@imgtec.com --- libavcodec/blockdsp.c| 2 + libavcodec/blockdsp.h| 1 + libavcodec/mips/Makefile | 2 + libavcodec/mips/blockdsp_init_mips.c | 40 + libavcodec/mips/blockdsp_mips.h | 31 + libavcodec/mips/blockdsp_msa.c | 86 6 files changed, 162 insertions(+) create mode 100644 libavcodec/mips/blockdsp_init_mips.c create mode 100644 libavcodec/mips/blockdsp_mips.h create mode 100644 libavcodec/mips/blockdsp_msa.c applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fixed EA vp6 files with alpha not picked up by the EA demuxer
I just noticed that i got a wrong patch file attached. Let me make a new diff. I didn't mean a real crash, i just meant an error output that this file isn't playable 2015-06-22 20:13 GMT+02:00 Michael Niedermayer michae...@gmx.at: On Mon, Jun 22, 2015 at 02:41:07PM +, Carl Eugen Hoyos wrote: stephan.vedder at gmail.com writes: https://bfme2-see.googlecode.com/svn-history/r129/trunk/data/movies/SmallRing.vp6 Before you had to use: ffplay -f ./SmallRing.vp6 since it would use the aac demuxer otherwise (resulting in a crash). How can I reproduce the crash? Crashes are always (very) important, but I cannot reproduce... i see no crash either also no anomaly under valgrind [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fixed EA vp6 files with alpha not picked up by the EA demuxer
I attached the fixed patch now.
2015-06-22 20:43 GMT+02:00 Stephan Vedder stephan.ved...@gmail.com:
I just noticed that i got a wrong patch file attached. Let me make a new
diff.
I didn't mean a real crash, i just meant an error output that this file
isn't playable
2015-06-22 20:13 GMT+02:00 Michael Niedermayer michae...@gmx.at:
On Mon, Jun 22, 2015 at 02:41:07PM +, Carl Eugen Hoyos wrote:
stephan.vedder at gmail.com writes:
https://bfme2-see.googlecode.com/svn-history/r129/trunk/data/movies/SmallRing.vp6
Before you had to use: ffplay -f ./SmallRing.vp6
since it would use the aac demuxer otherwise
(resulting in a crash).
How can I reproduce the crash?
Crashes are always (very) important, but
I cannot reproduce...
i see no crash either also no anomaly under valgrind
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid
they
would be bankrupt already.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
commit b1646ba4cbce2d285f7f268ec49ed0362e5fdf55
Author: Stephan Vedder stephan.ved...@gmail.com
Date: Mon Jun 22 20:56:23 2015 +0200
Fixed ea_probe function to accept vp6a videos
diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
index d6a396b..d999a0b 100644
--- a/libavformat/electronicarts.c
+++ b/libavformat/electronicarts.c
@@ -61,6 +61,7 @@
#define MV0F_TAG MKTAG('M', 'V', '0', 'F')
#define MVIh_TAG MKTAG('M', 'V', 'I', 'h') /* CMV header */
#define MVIf_TAG MKTAG('M', 'V', 'I', 'f') /* CMV I-frame */
+#define AVP6_TAG MKTAG('A', 'V', 'P', '6')
typedef struct EaDemuxContext {
int big_endian;
@@ -458,6 +459,7 @@ static int ea_probe(AVProbeData *p)
case MPCh_TAG:
case MVhd_TAG:
case MVIh_TAG:
+case AVP6_TAG:
break;
default:
return 0;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add ssim filter
Hi, On Mon, Jun 22, 2015 at 12:23 PM, Paul B Mahol one...@gmail.com wrote: +c[0] = ssim(main-data[0], main-linesize[0], +ref-data[0], ref-linesize[0], +s-planewidth[0], s-planeheight[0]); + +c[1] = ssim(main-data[1], main-linesize[1], +ref-data[1], ref-linesize[1], +s-planewidth[1], s-planeheight[1]); + +c[2] = ssim(main-data[2], main-linesize[2], +ref-data[2], ref-linesize[2], +s-planewidth[2], s-planeheight[2]); + +ssimv = c[0] * .8 + .1 * (c[1] + c[2]); + +set_meta(metadata, lavfi.ssim., s-comps[0], c[0]); +set_meta(metadata, lavfi.ssim., s-comps[1], c[1]); +set_meta(metadata, lavfi.ssim., s-comps[2], c[2]); +set_meta(metadata, lavfi.ssim.All, 0, ssimv); So there are just the floats right? Can you convert them to dB values as tiny_ssim does? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add ssim filter
On 6/22/15, Nicolas George geo...@nsup.org wrote: Le quartidi 4 messidor, an CCXXIII, Paul B Mahol a ecrit : Signed-off-by: Paul B Mahol one...@gmail.com --- Changelog| 1 + doc/filters.texi | 53 libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_ssim.c| 340 +++ 5 files changed, 396 insertions(+) create mode 100644 libavfilter/vf_ssim.c Would it make sense to merge it with the psnr filter, sharing code and offering a common user interface for various quality measurements? Just to put it into same file? Moving it into same filter would be also possible but how would then new filter be named then? Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add ssim filter
On 6/22/15, Ronald S. Bultje rsbul...@gmail.com wrote: Hi, On Mon, Jun 22, 2015 at 12:23 PM, Paul B Mahol one...@gmail.com wrote: +c[0] = ssim(main-data[0], main-linesize[0], +ref-data[0], ref-linesize[0], +s-planewidth[0], s-planeheight[0]); + +c[1] = ssim(main-data[1], main-linesize[1], +ref-data[1], ref-linesize[1], +s-planewidth[1], s-planeheight[1]); + +c[2] = ssim(main-data[2], main-linesize[2], +ref-data[2], ref-linesize[2], +s-planewidth[2], s-planeheight[2]); + +ssimv = c[0] * .8 + .1 * (c[1] + c[2]); + +set_meta(metadata, lavfi.ssim., s-comps[0], c[0]); +set_meta(metadata, lavfi.ssim., s-comps[1], c[1]); +set_meta(metadata, lavfi.ssim., s-comps[2], c[2]); +set_meta(metadata, lavfi.ssim.All, 0, ssimv); So there are just the floats right? Can you convert them to dB values as tiny_ssim does? Sure, I hope file is still LGPL ;-) Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add ssim filter
Le quartidi 4 messidor, an CCXXIII, Paul B Mahol a écrit : Signed-off-by: Paul B Mahol one...@gmail.com --- Changelog| 1 + doc/filters.texi | 53 libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_ssim.c| 340 +++ 5 files changed, 396 insertions(+) create mode 100644 libavfilter/vf_ssim.c Would it make sense to merge it with the psnr filter, sharing code and offering a common user interface for various quality measurements? Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fixed EA vp6 files with alpha not picked up by the EA demuxer
On Mon, Jun 22, 2015 at 02:41:07PM +, Carl Eugen Hoyos wrote: stephan.vedder at gmail.com writes: https://bfme2-see.googlecode.com/svn-history/r129/trunk/data/movies/SmallRing.vp6 Before you had to use: ffplay -f ./SmallRing.vp6 since it would use the aac demuxer otherwise (resulting in a crash). How can I reproduce the crash? Crashes are always (very) important, but I cannot reproduce... i see no crash either also no anomaly under valgrind [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] fate: add some tests for ffv1 level 3 with 8/10/16 bps
On Mon, Jun 22, 2015 at 04:58:22PM +0200, Tobias Rapp wrote: On 22.06.2015 14:59, Michael Niedermayer wrote: On Mon, Jun 22, 2015 at 09:38:43AM +0200, Tobias Rapp wrote: Attached patch adds some FATE tests for FFV1 level 3 with different bits-per-sample. fate/vcodec.mak |6 +- ref/vsynth/vsynth1-ffv1.3-420|4 ref/vsynth/vsynth1-ffv1.3-422p10 |4 ref/vsynth/vsynth1-ffv1.3-444p16 |4 ref/vsynth/vsynth1-ffv1.3-bgr|4 ref/vsynth/vsynth2-ffv1.3-420|4 ref/vsynth/vsynth2-ffv1.3-422p10 |4 ref/vsynth/vsynth2-ffv1.3-444p16 |4 ref/vsynth/vsynth2-ffv1.3-bgr|4 ref/vsynth/vsynth3-ffv1.3-420|4 ref/vsynth/vsynth3-ffv1.3-422p10 |4 ref/vsynth/vsynth3-ffv1.3-444p16 |4 ref/vsynth/vsynth3-ffv1.3-bgr|4 ref/vsynth/vsynth_lena-ffv1.3-420|4 ref/vsynth/vsynth_lena-ffv1.3-422p10 |4 ref/vsynth/vsynth_lena-ffv1.3-444p16 |4 ref/vsynth/vsynth_lena-ffv1.3-bgr|4 17 files changed, 69 insertions(+), 1 deletion(-) 09d8d05b6b5cded64fc6e6698e503584daad057c 0001-fate-add-some-tests-for-ffv1-level-3-with-8-10-16-bp.patch From aee3721703e8530bb71f85daf4b4438ed170f612 Mon Sep 17 00:00:00 2001 From: Tobias Rapp t.r...@noa-audio.com Date: Fri, 19 Jun 2015 14:30:27 +0200 Subject: [PATCH] fate: add some tests for ffv1 level 3 with 8/10/16 bps fails on MIPS you are possibly missing some swscale bitexact flag or something Attached a new version of the patch with -sws_flags neighbor+bitexact added to 10/16 bit YUV and RGB. Looking at fate-run.sh the bitexact flag might be redundant, though. applied Noticed that the stddev of all YUV output files is 0.00 now (but not for RGB). YUV420 -YUV422 - YUV420 can be lossless YUV420 - RGB -YUV420 is generally not lossless it would be needed to use a RGB input and output for such test and compare to the RGB reference instead of using YUV not sure we have any test that does that Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 22/06/15 14:11, Derek Buitenhuis wrote: On 6/21/2015 8:04 PM, Mariusz Szczepańczyk wrote: Anyway, this is a part of my GSoC task that has been accepted and I'm compelled to implement it so I won't be getting into further discussion. Let's just say a large portion of the community didn't and don't think this idea has any place in libav* in the first place, but were ignored, or our complaints pushed aside. - Derek Thank you for clarification. I understand there are people who are not happy with additions like this. However, there are also people who think these changes are needed and trying to stop them just because we don't want this here or worse, making fun of their work is not the way to go to be honest. I don't really know how/when this conflict started or have your complaints been answered or not but it seems to me there are some of you who are really frustrated with the direction ffmpeg have taken. So why don't you propose something constructive, e.g. partition into distinct libraries so muxing/demuxing code is not getting spoiled? There must be some kind of solution everyone can agree with. Mariusz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On Mon, Jun 22, 2015 at 06:06:58PM +0100, Derek Buitenhuis wrote: On 6/22/2015 5:33 PM, James Almer wrote: I have no opinion one or way or another regarding this addition, but if this is a GSoC project then i guess the time to show disagreement was back in February when it was a suggested project waiting for applications, and not in the middle of the program long after a student got the project assigned. We did. Several times. It was ignored or pushed aside. When and where ? Also, the Browsing content on the server project was added 17 months ago to the GSoC 2014 page: https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2014?confirm_email=email_confirm=action=diffversion=28old_version=27confirm_email=email_confirm= Thats a long time prior to GSoC 2015 in which anyone could have removed it if they wanted, its a publically editable wiki basically And theres another aspect to this, theres quite some code that needs the rename function (git grep ff_rename). What options exist here 1. leave it so it only works with local files 2. support other protocols than file:// by the API here 3. support other protocols than file:// by some other API 4. remove the code that uses ff_rename (hls, hds, dash, smoothstreaming, ...) I might be wrong but i think people really like none of the options here for 3. also some other API would need to be suggested, this may very well be the solution if someone does have a better idea for a better API, that is one that everyone likes or at least can live with also another use case for this may be simple cleanup on errors, a muxer might (possibly not by default if people prefer) remove files that failed to be created at an early stage that is for example when writing the header fails in the middle and before any content is stored in a file deleting the file is probably what some users would want ... Also lets rather encourage work toward a solution, everyone is happy with instead of disencouraging people from working 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
[FFmpeg-devel] [PATCH] avfilter: add ssim filter
Signed-off-by: Paul B Mahol one...@gmail.com
---
Changelog| 1 +
doc/filters.texi | 53
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_ssim.c| 340 +++
5 files changed, 396 insertions(+)
create mode 100644 libavfilter/vf_ssim.c
diff --git a/Changelog b/Changelog
index a5c6b82..84b723f 100644
--- a/Changelog
+++ b/Changelog
@@ -5,6 +5,7 @@ version next:
- colorkey video filter
- BFSTM/BCSTM demuxer
- little-endian ADPCM_THP decoder
+- ssim filter
version 2.7:
diff --git a/doc/filters.texi b/doc/filters.texi
index 82e23c8..c1381a5 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8834,6 +8834,59 @@ in [-30,0] will filter edges. Default value is 0.
If a chroma option is not explicitly set, the corresponding luma value
is set.
+@section ssim
+
+Obtain the SSIM (Structural SImilarity Metric) between two input videos.
+
+This filter takes in input two input videos, the first input is
+considered the main source and is passed unchanged to the
+output. The second input is used as a reference video for computing
+the SSIM.
+
+Both video inputs must have the same resolution and pixel format for
+this filter to work correctly. Also it assumes that both inputs
+have the same number of frames, which are compared one by one.
+
+The filter stores the calculated SSIM of each frame.
+
+The description of the accepted parameters follows.
+
+@table @option
+@item stats_file, f
+If specified the filter will use the named file to save the PSNR of
+each individual frame.
+@end table
+
+The file printed if @var{stats_file} is selected, contains a sequence of
+key/value pairs of the form @var{key}:@var{value} for each compared
+couple of frames.
+
+A description of each shown parameter follows:
+
+@table @option
+@item n
+sequential number of the input frame, starting from 1
+
+@item Y, U, V, R, G, B
+SSIM of the compared frames for the component specified by the suffix.
+
+@item All
+SSIM of the compared frames for the whole frame.
+
+@item dB
+Same as above but in dB representation.
+@end table
+
+For example:
+@example
+movie=ref_movie.mpg, setpts=PTS-STARTPTS [main];
+[main][ref] ssim=stats_file=stats.log [out]
+@end example
+
+On this example the input file being processed is compared with the
+reference file @file{ref_movie.mpg}. The SSIM of each individual frame
+is stored in @file{stats.log}.
+
@section stereo3d
Convert between different stereoscopic image formats.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fc9f455..55cd055 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -197,6 +197,7 @@ OBJS-$(CONFIG_SIGNALSTATS_FILTER)+=
vf_signalstats.o
OBJS-$(CONFIG_SMARTBLUR_FILTER) += vf_smartblur.o
OBJS-$(CONFIG_SPLIT_FILTER) += split.o
OBJS-$(CONFIG_SPP_FILTER)+= vf_spp.o
+OBJS-$(CONFIG_SSIM_FILTER) += vf_ssim.o dualinput.o
framesync.o
OBJS-$(CONFIG_STEREO3D_FILTER) += vf_stereo3d.o
OBJS-$(CONFIG_SUBTITLES_FILTER) += vf_subtitles.o
OBJS-$(CONFIG_SUPER2XSAI_FILTER) += vf_super2xsai.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 415ed1b..3898498 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -212,6 +212,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(SMARTBLUR, smartblur, vf);
REGISTER_FILTER(SPLIT, split, vf);
REGISTER_FILTER(SPP,spp,vf);
+REGISTER_FILTER(SSIM, ssim, vf);
REGISTER_FILTER(STEREO3D, stereo3d, vf);
REGISTER_FILTER(SUBTITLES, subtitles, vf);
REGISTER_FILTER(SUPER2XSAI, super2xsai, vf);
diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c
new file mode 100644
index 000..7c86074
--- /dev/null
+++ b/libavfilter/vf_ssim.c
@@ -0,0 +1,340 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Caculate the SSIM between two input videos.
+ */
+
+#include libavutil/opt.h
+#include libavutil/pixdesc.h
+#include avfilter.h
+#include dualinput.h
+#include drawutils.h
+#include formats.h
Re: [FFmpeg-devel] [PATCH] avformat/mpegts: recognizes and export private streams
On Mon, Jun 22, 2015 at 04:16:00PM +0200, Wolfgang Lorenz wrote:
One last thing:
Am Fri, 12 Jun 2015 22:06:43 +0200
schrieb Wolfgang Lorenz wl-c...@gmx.de:
Am Fri, 12 Jun 2015 15:53:41 +0200
schrieb Michael Niedermayer michae...@gmx.at:
On Fri, Jun 12, 2015 at 12:38:19PM +0200, Wolfgang Lorenz wrote:
Am Fri, 12 Jun 2015 00:12:37 +0200
schrieb Wolfgang Lorenz wl-c...@gmx.de:
Am Thu, 11 Jun 2015 23:11:37 +0200
schrieb Michael Niedermayer michae...@gmx.at:
On Thu, Jun 11, 2015 at 10:59:23PM +0200, Wolfgang Lorenz wrote:
Hi Micheal,
Am Wed, 10 Jun 2015 23:40:10 +0200
schrieb Michael Niedermayer michae...@gmx.at:
Based on patch by Wolfgang Lorenz wl-c...@gmx.de
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavformat/mpegts.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index eff6819..7b35d7f 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -835,6 +835,13 @@ static int mpegts_set_stream_info(AVStream
*st, PESContext *pes,
st-codec-codec_id = old_codec_id;
st-codec-codec_type = old_codec_type;
}
+if ((st-codec-codec_id == AV_CODEC_ID_NONE ||
st-request_probe == 1)
+!avcodec_is_open(st-codec)
+stream_type == 6) {
I've just seen, mpegts.h contains
#define STREAM_TYPE_PRIVATE_DATA0x06
I think, comparing stream_type to STREAM_TYPE_PRIVATE_DATA, makes this
code a little bit more verbose.
changed
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fixed EA vp6 files with alpha not picked up by the EA demuxer
On Mon, Jun 22, 2015 at 08:58:41PM +0200, Stephan Vedder wrote: I attached the fixed patch now. [...] electronicarts.c |2 ++ 1 file changed, 2 insertions(+) e10466b07ca042720ac60541ca615745edf1434a patch.diff commit b1646ba4cbce2d285f7f268ec49ed0362e5fdf55 Author: Stephan Vedder stephan.ved...@gmail.com Date: Mon Jun 22 20:56:23 2015 +0200 Fixed ea_probe function to accept vp6a videos applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] swscale/x86/rgb2rgb_template: add missing xmm clobbers
Signed-off-by: James Almer jamr...@gmail.com --- libswscale/x86/rgb2rgb_template.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libswscale/x86/rgb2rgb_template.c b/libswscale/x86/rgb2rgb_template.c index e71c7eb..fd04923 100644 --- a/libswscale/x86/rgb2rgb_template.c +++ b/libswscale/x86/rgb2rgb_template.c @@ -1905,7 +1905,7 @@ static void RENAME(interleaveBytes)(const uint8_t *src1, const uint8_t *src2, ui cmp %3, %%REG_a \n\t jb 1b \n\t ::r(dest), r(src1), r(src2), r ((x86_reg)width-15) -: memory, %REG_a +: memory, XMM_CLOBBERS(xmm0, xmm1, xmm2,) %REG_a ); #else __asm__( -- 2.4.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] swscale/x86/rgb2rgb_template: don't call emms on sse2/avx functions
Signed-off-by: James Almer jamr...@gmail.com --- libswscale/x86/rgb2rgb_template.c | 4 1 file changed, 4 insertions(+) diff --git a/libswscale/x86/rgb2rgb_template.c b/libswscale/x86/rgb2rgb_template.c index fd04923..a1f7434 100644 --- a/libswscale/x86/rgb2rgb_template.c +++ b/libswscale/x86/rgb2rgb_template.c @@ -1943,7 +1943,9 @@ static void RENAME(interleaveBytes)(const uint8_t *src1, const uint8_t *src2, ui src2 += src2Stride; } __asm__( +#if !COMPILE_TEMPLATE_SSE2 EMMS \n\t +#endif SFENCE \n\t ::: memory ); @@ -1971,7 +1973,9 @@ static void RENAME(deinterleaveBytes)(const uint8_t *src, uint8_t *dst1, uint8_t dst2 += dst2Stride; } __asm__( +#if !COMPILE_TEMPLATE_SSE2 EMMS \n\t +#endif SFENCE \n\t ::: memory ); -- 2.4.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf: set is_connected flag so url can be properly closed
--- libavformat/avio.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/avio.c b/libavformat/avio.c index bd32944..aff8d10 100644 --- a/libavformat/avio.c +++ b/libavformat/avio.c @@ -485,6 +485,7 @@ int avio_open_dir(AVIODirContext **s, const char *url, AVDictionary **options) if (ret 0) goto fail; +h-is_connected = 1; ctx-url_context = h; *s = ctx; return 0; -- 2.3.6 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] swscale/x86/rgb2rgb_template: fix signedness of v in shuffle_bytes_2103_{mmx, mmxext}
Signed-off-by: James Almer jamr...@gmail.com
---
libswscale/x86/rgb2rgb_template.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libswscale/x86/rgb2rgb_template.c
b/libswscale/x86/rgb2rgb_template.c
index a1f7434..e97ba4f 100644
--- a/libswscale/x86/rgb2rgb_template.c
+++ b/libswscale/x86/rgb2rgb_template.c
@@ -1090,7 +1090,7 @@ static inline void RENAME(shuffle_bytes_2103)(const
uint8_t *src, uint8_t *dst,
: r (s), r (d), m (mask32b), m (mask32r), m (mmx_one)
: memory);
for (; idx15; idx+=4) {
-register int v = *(const uint32_t *)s[idx], g = v 0xff00ff00;
+register unsigned v = *(const uint32_t *)s[idx], g = v 0xff00ff00;
v = 0xff00ff;
*(uint32_t *)d[idx] = (v16) + g + (v16);
}
--
2.4.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] movtextenc.c: Support for Bold, Italic and Underlined styles
On 6/23/15, Philip Langdale phil...@overt.org wrote: I got a bunch of warnings when I compiled it. Please fix. Thanks. -- CC libavcodec/movtextenc.o libavcodec/movtextenc.c: In function ‘mov_text_style_cb’: libavcodec/movtextenc.c:124:17: warning: ‘return’ with a value, in function returning void return AVERROR(ENOMEM); ^ libavcodec/movtextenc.c:138:21: warning: ‘return’ with a value, in function returning void return AVERROR(ENOMEM); ^ libavcodec/movtextenc.c:167:13: warning: ‘return’ with a value, in function returning void return AVERROR(ENOMEM); The function mov_text_style_cb() is a void function, I'll make it int funciton to return a value. ^ libavcodec/movtextenc.c: In function ‘mov_text_encode_frame’: libavcodec/movtextenc.c:242:47: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-tsmb_size, 4); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint32_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ libavcodec/movtextenc.c:243:47: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-tsmb_type, 4); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint32_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ libavcodec/movtextenc.c:244:47: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-style_entries, 2); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint16_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ libavcodec/movtextenc.c:246:51: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-style_attributes[j]-style_start, 2); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint16_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ libavcodec/movtextenc.c:247:51: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-style_attributes[j]-style_end, 2); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint16_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ libavcodec/movtextenc.c:248:51: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-style_fontID, 2); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint16_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ libavcodec/movtextenc.c:251:51: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-style_color, 4); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint32_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ As for these warnings, we discussed that they were fine as long as I am keeping check of alignment and placement into the buffer properly. Defining all these variables as char* would make the code lengthier and less clean. What do you suggest? Thanks, Niklesh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] movtextenc.c: Support for Bold, Italic and Underlined styles
On Mon, 22 Jun 2015 19:58:09 +0530 Niklesh Lalwani niklesh.lalw...@iitb.ac.in wrote: Updated patch. Thanks, Niklesh I got a bunch of warnings when I compiled it. Please fix. Thanks. -- CC libavcodec/movtextenc.o libavcodec/movtextenc.c: In function ‘mov_text_style_cb’: libavcodec/movtextenc.c:124:17: warning: ‘return’ with a value, in function returning void return AVERROR(ENOMEM); ^ libavcodec/movtextenc.c:138:21: warning: ‘return’ with a value, in function returning void return AVERROR(ENOMEM); ^ libavcodec/movtextenc.c:167:13: warning: ‘return’ with a value, in function returning void return AVERROR(ENOMEM); ^ libavcodec/movtextenc.c: In function ‘mov_text_encode_frame’: libavcodec/movtextenc.c:242:47: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-tsmb_size, 4); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint32_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ libavcodec/movtextenc.c:243:47: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-tsmb_type, 4); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint32_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ libavcodec/movtextenc.c:244:47: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-style_entries, 2); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint16_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ libavcodec/movtextenc.c:246:51: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-style_attributes[j]-style_start, 2); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint16_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ libavcodec/movtextenc.c:247:51: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-style_attributes[j]-style_end, 2); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint16_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ libavcodec/movtextenc.c:248:51: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-style_fontID, 2); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint16_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ libavcodec/movtextenc.c:251:51: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-style_color, 4); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint32_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] movtextdec.c: Improve upon dynarrays and text_to_ass
On Mon, 22 Jun 2015 19:56:06 +0530 Niklesh Lalwani niklesh.lalw...@iitb.ac.in wrote: Updated patch. Thanks, Niklesh Pushed. Thanks. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: Add H264 API test
On 6/22/2015 10:50 AM, Ludmila Glinskih wrote: +#include libavformat/internal.h What is this for? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: Add H264 API test
On 6/22/2015 1:32 PM, Vittorio Giovara wrote: video_decode_example can return -1 on error, and this is lost, so you'd better do return video_decode_example(argv[1]); to return the value to the caller. Also sometimes you exit(1) and sometimes you return -1, maybe you could go with only one of them. You shouldn't return -1 as a process exit code. This is a reserved value for proc return codes in POSIX. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add some tests for ffv1 level 3 with 8/10/16 bps
On Mon, Jun 22, 2015 at 09:38:43AM +0200, Tobias Rapp wrote: Attached patch adds some FATE tests for FFV1 level 3 with different bits-per-sample. fate/vcodec.mak |6 +- ref/vsynth/vsynth1-ffv1.3-420|4 ref/vsynth/vsynth1-ffv1.3-422p10 |4 ref/vsynth/vsynth1-ffv1.3-444p16 |4 ref/vsynth/vsynth1-ffv1.3-bgr|4 ref/vsynth/vsynth2-ffv1.3-420|4 ref/vsynth/vsynth2-ffv1.3-422p10 |4 ref/vsynth/vsynth2-ffv1.3-444p16 |4 ref/vsynth/vsynth2-ffv1.3-bgr|4 ref/vsynth/vsynth3-ffv1.3-420|4 ref/vsynth/vsynth3-ffv1.3-422p10 |4 ref/vsynth/vsynth3-ffv1.3-444p16 |4 ref/vsynth/vsynth3-ffv1.3-bgr|4 ref/vsynth/vsynth_lena-ffv1.3-420|4 ref/vsynth/vsynth_lena-ffv1.3-422p10 |4 ref/vsynth/vsynth_lena-ffv1.3-444p16 |4 ref/vsynth/vsynth_lena-ffv1.3-bgr|4 17 files changed, 69 insertions(+), 1 deletion(-) 09d8d05b6b5cded64fc6e6698e503584daad057c 0001-fate-add-some-tests-for-ffv1-level-3-with-8-10-16-bp.patch From aee3721703e8530bb71f85daf4b4438ed170f612 Mon Sep 17 00:00:00 2001 From: Tobias Rapp t.r...@noa-audio.com Date: Fri, 19 Jun 2015 14:30:27 +0200 Subject: [PATCH] fate: add some tests for ffv1 level 3 with 8/10/16 bps fails on MIPS you are possibly missing some swscale bitexact flag or something TESTvsynth2-ffv1 TESTvsynth2-ffv1.0 TESTvsynth2-ffv1.3-420 TESTvsynth2-ffv1.3-422p10 --- ffmpeg/tests/ref/vsynth/vsynth3-ffv1.3-422p10 2015-06-22 14:38:20.507474912 +0200 +++ tests/data/fate/vsynth3-ffv1.3-422p10 2015-06-22 14:55:52.607497076 +0200 @@ -1,4 +1,4 @@ -7c721e6e9441f9bd5a991edb3be520da *tests/data/fate/vsynth3-ffv1.3-422p10.avi -87774 tests/data/fate/vsynth3-ffv1.3-422p10.avi -0cf7cf68724fa5146b1667e4fa08b0e1 *tests/data/fate/vsynth3-ffv1.3-422p10.out.rawvideo -stddev:2.12 PSNR: 41.58 MAXDIFF: 26 bytes:86700/86700 +4dbd6a95e5d9a41f4dd64314a13625a2 *tests/data/fate/vsynth3-ffv1.3-422p10.avi +153730 tests/data/fate/vsynth3-ffv1.3-422p10.avi +cf895f0c0904f1f1d80eebd6598b *tests/data/fate/vsynth3-ffv1.3-422p10.out.rawvideo +stddev:2.12 PSNR: 41.59 MAXDIFF: 26 bytes:86700/86700 Test vsynth3-ffv1.3-422p10 failed. Look at tests/data/fate/vsynth3-ffv1.3-422p10.err for details. make: *** [fate-vsynth3-ffv1.3-422p10] Error 1 make: *** Waiting for unfinished jobs --- ffmpeg/tests/ref/vsynth/vsynth2-ffv1.3-422p10 2015-06-22 14:38:20.475474911 +0200 +++ tests/data/fate/vsynth2-ffv1.3-422p10 2015-06-22 14:56:04.047497317 +0200 @@ -1,4 +1,4 @@ -b6049e5c13cf9996e3cb1b89833ebf7a *tests/data/fate/vsynth2-ffv1.3-422p10.avi -5554840 tests/data/fate/vsynth2-ffv1.3-422p10.avi -8bb1c449e1a2a94fd0d98841c04246bb *tests/data/fate/vsynth2-ffv1.3-422p10.out.rawvideo -stddev:0.39 PSNR: 56.17 MAXDIFF:9 bytes: 7603200/ 7603200 +c3451f168ce4494a5ed235dbcb8ca020 *tests/data/fate/vsynth2-ffv1.3-422p10.avi +9981782 tests/data/fate/vsynth2-ffv1.3-422p10.avi +0dbc203aa0709469e0331f582ab47639 *tests/data/fate/vsynth2-ffv1.3-422p10.out.rawvideo +stddev:0.39 PSNR: 56.22 MAXDIFF:9 bytes: 7603200/ 7603200 Test vsynth2-ffv1.3-422p10 failed. Look at tests/data/fate/vsynth2-ffv1.3-422p10.err for details. make: *** [fate-vsynth2-ffv1.3-422p10] Error 1 --- ffmpeg/tests/ref/vsynth/vsynth1-ffv1.3-422p10 2015-06-22 14:38:20.439474911 +0200 +++ tests/data/fate/vsynth1-ffv1.3-422p10 2015-06-22 14:56:04.351497324 +0200 @@ -1,4 +1,4 @@ -b13f8fe6c5e5dc227a7fa631849b7e57 *tests/data/fate/vsynth1-ffv1.3-422p10.avi -4232950 tests/data/fate/vsynth1-ffv1.3-422p10.avi -c31e6caada921ffa3daad3432ef3b754 *tests/data/fate/vsynth1-ffv1.3-422p10.out.rawvideo -stddev:1.85 PSNR: 42.78 MAXDIFF: 29 bytes: 7603200/ 7603200 +c622b99662ff8b1595440e7319e35333 *tests/data/fate/vsynth1-ffv1.3-422p10.avi +9351672 tests/data/fate/vsynth1-ffv1.3-422p10.avi +e3b0789de649c70f994375361e1c934b *tests/data/fate/vsynth1-ffv1.3-422p10.out.rawvideo +stddev:1.84 PSNR: 42.79 MAXDIFF: 29 bytes: 7603200/ 7603200 Test vsynth1-ffv1.3-422p10 failed. Look at tests/data/fate/vsynth1-ffv1.3-422p10.err for details. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB DNS cache poisoning attacks, popular search engine, Google internet authority dont be evil, please signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Fixed EA vp6 files with alpha not picked up by the EA demuxer
From: feliwir stephan.ved...@gmail.com
---
libavformat/electronicarts.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
index 859fbb8..ba15b65 100644
--- a/libavformat/electronicarts.c
+++ b/libavformat/electronicarts.c
@@ -427,6 +427,7 @@ static int process_ea_header(AVFormatContext *s)
ea-time_base = (AVRational) { avio_rl16(pb), 1000 };
break;
+ case AVP6_TAG:
case MVhd_TAG:
err = process_video_header_vp6(s);
break;
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vda: unlock the pixel buffer base address.
On Sat, Jun 20, 2015 at 05:12:47PM +0200, Clément Bœsch wrote: On Sat, Jun 20, 2015 at 04:25:55PM +0200, Michael Niedermayer wrote: On Sat, Jun 20, 2015 at 01:19:29PM +0200, Sebastien Zwickert wrote: The pixel buffer base address is never unlocked this causes a bug with some pixel format types that are produced natively by the hardware decoder: the first buffer was always used. Unlock the pixel buffer base address fixes the issue. --- ffmpeg_vda.c | 2 ++ 1 file changed, 2 insertions(+) LGTM thanks FYI this is supposed to fix normal cases like: wget http://lucy.pkh.me/samples/natsuno.mp4 ffmpeg -hwaccel vda -i natsuno.mp4 -t 15 out.avi For some reason it's working if requesting kCVPixelFormatType_420YpCbCr8Planar (yuv420p) but not kCVPixelFormatType_422YpCbCr8: (uyvy422, default with ff) or kCVPixelFormatType_32BGRA (rgb32) I can't confirm it fixes the issue because I haven't the hw to test right now, but I believe it does :) Patch tested. LGTM. Thanks. [...] -- Clément B. pgpXAyze4UDit.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: Add H264 API test
On Mon, Jun 22, 2015 at 10:50 AM, Ludmila Glinskih lglins...@gmail.com wrote:
+static int video_decode_example(const char *input_filename)
+{
+AVCodec *codec = NULL;
+AVCodecContext *origin_ctx = NULL, *ctx= NULL;
+AVFrame *fr = NULL;
+uint8_t *byte_buffer = NULL;
+AVPacket pkt;
+AVFormatContext *fmt_ctx = NULL;
+int number_of_written_bytes;
+int video_stream;
+int get_frame = 0;
+int byte_buffer_size;
+int i = 0;
+
+
+if (avformat_open_input(fmt_ctx, input_filename, NULL, NULL) 0) {
+fprintf(stderr, Could not open source file %s\n, input_filename);
+exit(1);
+}
+
+if (avformat_find_stream_info(fmt_ctx, NULL) 0) {
+fprintf(stderr, Could not find stream information\n);
+exit(1);
+}
+
+video_stream = -1;
+for (i = 0; i fmt_ctx-nb_streams; i++) {
+if (fmt_ctx-streams[i]-codec-codec_type == AVMEDIA_TYPE_VIDEO) {
+video_stream = i;
+break;
+}
+}
+
+origin_ctx = fmt_ctx-streams[video_stream]-codec;
+
+codec = avcodec_find_decoder(origin_ctx-codec_id);
+if (codec == NULL) {
+return -1;
+}
+ctx = avcodec_alloc_context3(codec);
+if (ctx == NULL) {
+return -1;
+}
+
+if (avcodec_copy_context(ctx, origin_ctx)) {
+return -1;
+}
+
+if (avcodec_open2(ctx, codec, NULL) 0) {
+return -1;
+}
+
+fr = av_frame_alloc();
+if (fr == NULL) {
+return -1;
+}
+
+byte_buffer_size = av_image_get_buffer_size(ctx-pix_fmt, ctx-width,
ctx-height, 16);
+byte_buffer = av_malloc(byte_buffer_size);
+
+printf(#tb %d: %d/%d\n, video_stream,
fmt_ctx-streams[video_stream]-time_base.num,
fmt_ctx-streams[video_stream]-time_base.den);
+i = 0;
+av_init_packet(pkt);
+while (av_read_frame(fmt_ctx, pkt) = 0) {
+if (pkt.stream_index == video_stream) {
+get_frame = 0;
+if (pkt.pts == AV_NOPTS_VALUE)
+pkt.pts = pkt.dts = i;
+avcodec_decode_video2(ctx, fr, get_frame, pkt);
+if (get_frame) {
+number_of_written_bytes =
av_image_copy_to_buffer(byte_buffer, byte_buffer_size,
+(const uint8_t* const *)fr-data,
(const int*) fr-linesize,
+ctx-pix_fmt, ctx-width,
ctx-height, 1);
+printf(%d, %10PRId64, %10PRId64, %8d, %8d,
0x%08PRIx32\n, video_stream,
+fr-pkt_pts, fr-pkt_dts, fr-pkt_duration,
+number_of_written_bytes, av_adler32_update(0, (const
uint8_t*)byte_buffer, number_of_written_bytes));
+}
+av_free_packet(pkt);
+av_init_packet(pkt);
+}
+i++;
+}
+pkt.data = NULL;
+pkt.size = 0;
+if (pkt.pts == AV_NOPTS_VALUE)
+pkt.pts = pkt.dts = i;
+int flag = 0;
+while (!flag) {
+if (pkt.stream_index != video_stream)
+break;
+get_frame = 0;
+if (avcodec_decode_video2(ctx, fr, get_frame, pkt) 0 ||
get_frame == 0)
+flag = 1;
+if (get_frame) {
+number_of_written_bytes = av_image_copy_to_buffer(byte_buffer,
byte_buffer_size,
+(const uint8_t* const *)fr-data, (const
int*) fr-linesize,
+ctx-pix_fmt, ctx-width, ctx-height,
1);
+printf(%d, %10PRId64, %10PRId64, %8d, %8d,
0x%08PRIx32\n, video_stream,
+fr-pkt_pts, fr-pkt_dts, fr-pkt_duration,
+number_of_written_bytes, av_adler32_update(0, (const
uint8_t*)byte_buffer, number_of_written_bytes));
+}
+i++;
+}
+av_free_packet(pkt);
+av_frame_free(fr);
+avcodec_close(ctx);
+avformat_close_input(fmt_ctx);
+avcodec_free_context(ctx);
+av_freep(byte_buffer);
+return 0;
+}
+
+int main(int argc, char **argv)
+{
+av_register_all();
+video_decode_example(argv[1]);
+return 0;
+}
video_decode_example can return -1 on error, and this is lost, so
you'd better do return video_decode_example(argv[1]); to return the
value to the caller. Also sometimes you exit(1) and sometimes you
return -1, maybe you could go with only one of them.
--
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] yuv4mpeg: add rough duration estimate and seeking.
Ronald S. Bultje rsbultje at gmail.com writes: Why don't we do that once we start seeing files with frame-headers other than empty FRAME\n in the wild? +1 Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] yuv4mpeg: add rough duration estimate and seeking.
Le quartidi 4 messidor, an CCXXIII, Carl Eugen Hoyos a écrit : Why don't we do that once we start seeing files with frame-headers other than empty FRAME\n in the wild? +1 Me2. And do not forget that, technically, 0x46 0x52 0x41 0x4d 0x45 0x0a can very well appear in the frame data; with the bytes values, is is not even that unlikely. Generic seeking can only really work when the start code is guaranteed not to appear in the packets payload. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vda: unlock the pixel buffer base address.
On Mon, Jun 22, 2015 at 03:31:43PM +0200, Clément Bœsch wrote: On Sat, Jun 20, 2015 at 05:12:47PM +0200, Clément Bœsch wrote: On Sat, Jun 20, 2015 at 04:25:55PM +0200, Michael Niedermayer wrote: On Sat, Jun 20, 2015 at 01:19:29PM +0200, Sebastien Zwickert wrote: The pixel buffer base address is never unlocked this causes a bug with some pixel format types that are produced natively by the hardware decoder: the first buffer was always used. Unlock the pixel buffer base address fixes the issue. --- ffmpeg_vda.c | 2 ++ 1 file changed, 2 insertions(+) LGTM thanks FYI this is supposed to fix normal cases like: wget http://lucy.pkh.me/samples/natsuno.mp4 ffmpeg -hwaccel vda -i natsuno.mp4 -t 15 out.avi For some reason it's working if requesting kCVPixelFormatType_420YpCbCr8Planar (yuv420p) but not kCVPixelFormatType_422YpCbCr8: (uyvy422, default with ff) or kCVPixelFormatType_32BGRA (rgb32) I can't confirm it fixes the issue because I haven't the hw to test right now, but I believe it does :) Patch tested. LGTM. Thanks. Side note: should be backported -- Clément B. pgpcMs3zJWH0R.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: Add H264 API test
Hi,
On Mon, Jun 22, 2015 at 5:50 AM, Ludmila Glinskih lglins...@gmail.com
wrote:
+if (avcodec_decode_video2(ctx, fr, get_frame, pkt) 0 ||
get_frame == 0)
+flag = 1;
+if (get_frame) {
This sounds like you want if (avcodec_decode_video2(..) = 0 get_frame
0) {. You can then use a do { .. } while (get_frame) around the loop, saves
2 lines of code.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fixed EA vp6 files with alpha not picked up by the EA demuxer
Oh okay, guess i missed the tabs. However here is a sample file: https://code.google.com/p/bfme2-see/source/browse/trunk/data/movies/SmallRing.vp6?r=129 Before you had to use: ffplay -f ./SmallRing.vp6 since it would use the aac demuxer otherwise (resulting in a crash). With this patch you can simply use: ffplay ./SmallRing.vp6 Am 22.06.2015 um 15:49 schrieb Carl Eugen Hoyos ceho...@ag.or.at: Stephan Vedder stephan.vedder at gmail.com writes: +case AVP6_TAG: Tabs cannot be committed to the FFmpeg repository. Could you provide a sample? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mpegts: recognizes and export private streams
One last thing:
Am Fri, 12 Jun 2015 22:06:43 +0200
schrieb Wolfgang Lorenz wl-c...@gmx.de:
Am Fri, 12 Jun 2015 15:53:41 +0200
schrieb Michael Niedermayer michae...@gmx.at:
On Fri, Jun 12, 2015 at 12:38:19PM +0200, Wolfgang Lorenz wrote:
Am Fri, 12 Jun 2015 00:12:37 +0200
schrieb Wolfgang Lorenz wl-c...@gmx.de:
Am Thu, 11 Jun 2015 23:11:37 +0200
schrieb Michael Niedermayer michae...@gmx.at:
On Thu, Jun 11, 2015 at 10:59:23PM +0200, Wolfgang Lorenz wrote:
Hi Micheal,
Am Wed, 10 Jun 2015 23:40:10 +0200
schrieb Michael Niedermayer michae...@gmx.at:
Based on patch by Wolfgang Lorenz wl-c...@gmx.de
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavformat/mpegts.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index eff6819..7b35d7f 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -835,6 +835,13 @@ static int mpegts_set_stream_info(AVStream
*st, PESContext *pes,
st-codec-codec_id = old_codec_id;
st-codec-codec_type = old_codec_type;
}
+if ((st-codec-codec_id == AV_CODEC_ID_NONE ||
st-request_probe == 1)
+!avcodec_is_open(st-codec)
+stream_type == 6) {
I've just seen, mpegts.h contains
#define STREAM_TYPE_PRIVATE_DATA0x06
I think, comparing stream_type to STREAM_TYPE_PRIVATE_DATA, makes this
code a little bit more verbose.
+st-codec-codec_type = AVMEDIA_TYPE_DATA;
+st-codec-codec_id = AV_CODEC_ID_BIN_DATA;
+st-request_probe = 1;
+}
return 0;
}
[...]
That's it. No more questions.
Cheers,
Wolfgang
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] movtextenc.c: Support for Bold, Italic and Underlined styles
Updated patch. Thanks, Niklesh 0002-movtextenc.c-Support-for-Bold-Italic-and-Underlined-.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: Add H264 API test
On Mon, Jun 22, 2015 at 2:50 PM, Derek Buitenhuis derek.buitenh...@gmail.com wrote: On 6/22/2015 2:46 PM, Vittorio Giovara wrote: afaik in POSIX any non zero value is to be considered an error, also because value ranges on an unsigned byte. -1 ends up greater than 128, which is reserved by POSIX for system signal info (SIGKILL and pals). 'k the return value of video_decode_example() should still be checked though (and maybe use the EXIT_* macros then?) -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: Add H264 API test
On Mon, Jun 22, 2015 at 1:40 PM, Derek Buitenhuis derek.buitenh...@gmail.com wrote: On 6/22/2015 1:32 PM, Vittorio Giovara wrote: video_decode_example can return -1 on error, and this is lost, so you'd better do return video_decode_example(argv[1]); to return the value to the caller. Also sometimes you exit(1) and sometimes you return -1, maybe you could go with only one of them. You shouldn't return -1 as a process exit code. This is a reserved value for proc return codes in POSIX. afaik in POSIX any non zero value is to be considered an error, also because value ranges on an unsigned byte. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fixed EA vp6 files with alpha not picked up by the EA demuxer
Stephan Vedder stephan.vedder at gmail.com writes: + case AVP6_TAG: Tabs cannot be committed to the FFmpeg repository. Could you provide a sample? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fixed EA vp6 files with alpha not picked up by the EA demuxer
On 6/22/15, Stephan Vedder stephan.ved...@gmail.com wrote:
From: feliwir stephan.ved...@gmail.com
---
libavformat/electronicarts.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
index 859fbb8..ba15b65 100644
--- a/libavformat/electronicarts.c
+++ b/libavformat/electronicarts.c
@@ -427,6 +427,7 @@ static int process_ea_header(AVFormatContext *s)
ea-time_base = (AVRational) { avio_rl16(pb), 1000 };
break;
+ case AVP6_TAG:
case MVhd_TAG:
err = process_video_header_vp6(s);
break;
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Tabs are forbiden in FFmpeg C code.
Do you have a sample this patch fixes?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fixed EA vp6 files with alpha not picked up by the EA demuxer
Here is an example file: https://code.google.com/p/bfme2-see/source/browse/trunk/data/movies/SmallRing.vp6?r=129 Before it did chose the AAC demuxer for this file and files of that kind. Resulting in a crash. I can fix the tabs when i am back home Am 22.06.2015 um 15:49 schrieb Carl Eugen Hoyos ceho...@ag.or.at: Stephan Vedder stephan.vedder at gmail.com writes: +case AVP6_TAG: Tabs cannot be committed to the FFmpeg repository. Could you provide a sample? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] movtextdec.c: Improve upon dynarrays and text_to_ass
Updated patch. Thanks, Niklesh 0001-movtextdec.c-Improve-upon-dynarrays-and-text_to_ass.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fixed EA vp6 files with alpha not picked up by the EA demuxer
stephan.vedder at gmail.com writes: https://bfme2-see.googlecode.com/svn-history/r129/trunk/data/movies/SmallRing.vp6 Before you had to use: ffplay -f ./SmallRing.vp6 since it would use the aac demuxer otherwise (resulting in a crash). How can I reproduce the crash? Crashes are always (very) important, but I cannot reproduce... Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
