[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 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 +++ b/tests/ref/vsynth/vsynth1-ffv1.3-bgr @@ -0,0 +1,4 @@
Re: [FFmpeg-devel] [PATCH] yuv4mpeg: add rough duration estimate and seeking.
On Sun, 21 Jun 2015 18:34:33 -0400 "Ronald S. Bultje" wrote: > Hi, > > On Sun, Jun 21, 2015 at 5:17 PM, Hendrik Leppkes > wrote: > > > On Sun, Jun 21, 2015 at 10:41 PM, Ronald S. Bultje > > 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, Jun 22, 2015 at 11:02 AM, wm4 wrote: > On Sun, 21 Jun 2015 18:34:33 -0400 > "Ronald S. Bultje" wrote: > >> Hi, >> >> On Sun, Jun 21, 2015 at 5:17 PM, Hendrik Leppkes >> wrote: >> >> > On Sun, Jun 21, 2015 at 10:41 PM, Ronald S. Bultje >> > 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
[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
---
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
+
+#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
Re: [FFmpeg-devel] [PATCH] yuv4mpeg: add rough duration estimate and seeking.
On Mon, 22 Jun 2015 11:23:55 +0200 Hendrik Leppkes wrote: > On Mon, Jun 22, 2015 at 11:02 AM, wm4 wrote: > > On Sun, 21 Jun 2015 18:34:33 -0400 > > "Ronald S. Bultje" wrote: > > > >> Hi, > >> > >> On Sun, Jun 21, 2015 at 5:17 PM, Hendrik Leppkes > >> wrote: > >> > >> > On Sun, Jun 21, 2015 at 10:41 PM, Ronald S. Bultje > >> > 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 2/2] lavf/file: implement move and delete callbacks
On Sat, Jun 20, 2015 at 02:52:49PM +0200, Mariusz Szczepańczyk wrote: > --- > libavformat/file.c | 38 ++ > 1 file changed, 38 insertions(+) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] 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 > >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?= > 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] yuv4mpeg: add rough duration estimate and seeking.
Hi, On Mon, Jun 22, 2015 at 6:24 AM, wm4 wrote: > On Mon, 22 Jun 2015 11:23:55 +0200 > Hendrik Leppkes wrote: > > > On Mon, Jun 22, 2015 at 11:02 AM, wm4 wrote: > > > On Sun, 21 Jun 2015 18:34:33 -0400 > > > "Ronald S. Bultje" wrote: > > > > > >> Hi, > > >> > > >> On Sun, Jun 21, 2015 at 5:17 PM, Hendrik Leppkes > > > >> 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... Ronald ___ 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, %10"PRId64", %10"PRId64", %8d, %8d, 0x%08"PRIx32"\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%08"PRIx32"' 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 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
Re: [FFmpeg-devel] [PATCH] libavformat: Add H264 API test
On Mon, Jun 22, 2015 at 12:50:22PM +0300, Ludmila Glinskih wrote:
> Result differs in pkt_duration and time_base.den for some reason.
> Right now it tests only one example (adjusted to match the output).
>
[...]
> +pkt.data = NULL;
> +pkt.size = 0;
> +if (pkt.pts == AV_NOPTS_VALUE)
> +pkt.pts = pkt.dts = i;
> +int flag = 0;
should be moved to the top of the function, some compilers dont
like mixed declarations and code.
> +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, %10"PRId64", %10"PRId64", %8d, %8d,
> 0x%08"PRIx32"\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]);
missing check on argc before use of the first argument
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
signature.asc
Description: Digital 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 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 Mon, Jun 22, 2015 at 10:50 AM, Ludmila Glinskih 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, %10"PRId64", %10"PRId64", %8d, %8d,
> 0x%08"PRIx32"\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, %10"PRId64", %10"PRId64", %8d, %8d,
> 0x%08"PRIx32"\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 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] 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] libavformat: Add H264 API test
Hi,
On Mon, Jun 22, 2015 at 5:50 AM, Ludmila Glinskih
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] 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 > 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
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 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] 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
[FFmpeg-devel] [PATCH] Fixed EA vp6 files with alpha not picked up by the EA demuxer
From: feliwir
---
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] libavformat: Add H264 API test
On Mon, Jun 22, 2015 at 1:40 PM, Derek Buitenhuis 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 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] libavformat: Add H264 API test
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). - 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
On 6/22/15, Stephan Vedder wrote:
> From: feliwir
>
> ---
> 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] libavformat: Add H264 API test
On Mon, Jun 22, 2015 at 2:50 PM, Derek Buitenhuis 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] 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 : > > Stephan Vedder 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] 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 : > > Stephan Vedder 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 :
> Am Fri, 12 Jun 2015 15:53:41 +0200
> schrieb Michael Niedermayer :
>
> > 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 :
> > >
> > > > Am Thu, 11 Jun 2015 23:11:37 +0200
> > > > schrieb Michael Niedermayer :
> > > >
> > > > > 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 :
> > > > > >
> > > > > > > Based on patch by Wolfgang Lorenz
> > > > > > > Signed-off-by: Michael Niedermayer
> > > > > > > ---
> > > > > > > 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 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 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] Fixed EA vp6 files with alpha not picked up by the EA demuxer
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
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 : > > 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 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 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 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 \ + -sws_flags neighbor
[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 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
Re: [FFmpeg-devel] [PATCH] avfilter: add ssim filter
Hi, On Mon, Jun 22, 2015 at 12:23 PM, Paul B Mahol 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 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=diff&version=28&old_version=27&confirm_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
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: > 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 > >>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] avfilter: add ssim filter
On 6/22/15, Ronald S. Bultje wrote: > Hi, > > On Mon, Jun 22, 2015 at 12:23 PM, Paul B Mahol 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] 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 : > On Mon, Jun 22, 2015 at 02:41:07PM +, Carl Eugen Hoyos wrote: > > 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 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 > > This patch adds MSA (MIPS-SIMD-Arch) optimizations for block functions in new > file blockdsp_msa.c > > Signed-off-by: Shivraj Patil > --- > 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 attached the fixed patch now.
2015-06-22 20:43 GMT+02:00 Stephan Vedder :
> 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 :
>
>> On Mon, Jun 22, 2015 at 02:41:07PM +, Carl Eugen Hoyos wrote:
>> > 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
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] yuv4mpeg: add rough duration estimate and seeking.
On Mon, 22 Jun 2015 07:52:21 -0400 "Ronald S. Bultje" wrote: > Hi, > > On Mon, Jun 22, 2015 at 6:24 AM, wm4 wrote: > > > On Mon, 22 Jun 2015 11:23:55 +0200 > > Hendrik Leppkes wrote: > > > > > On Mon, Jun 22, 2015 at 11:02 AM, wm4 wrote: > > > > On Sun, 21 Jun 2015 18:34:33 -0400 > > > > "Ronald S. Bultje" wrote: > > > > > > > >> Hi, > > > >> > > > >> On Sun, Jun 21, 2015 at 5:17 PM, Hendrik Leppkes > > > > > >> 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
[FFmpeg-devel] [PATCH] avfilter: add ssim filter
Signed-off-by: Paul B Mahol
---
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 :
- 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"
+#include
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 > --- > 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] avfilter: add ssim filter
On 6/22/15, Nicolas George wrote: > Le quartidi 4 messidor, an CCXXIII, Paul B Mahol a ecrit : >> Signed-off-by: Paul B Mahol >> --- >> 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 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] Fixed EA vp6 files with alpha not picked up by the EA demuxer
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 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=diff&version=28&old_version=27&confirm_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
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 : > 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 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 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 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 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 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 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()
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. Humbly, -- Reynaldo H. Verdejo Pinochet Open Source Group Samsung Research America / Silicon Valley ___ 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 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 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
[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
Signed-off-by: Lukasz Marek
---
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);
+
[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] 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
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 > 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
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 :
>
> > Am Fri, 12 Jun 2015 15:53:41 +0200
> > schrieb Michael Niedermayer :
> >
> > > 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 :
> > > >
> > > > > Am Thu, 11 Jun 2015 23:11:37 +0200
> > > > > schrieb Michael Niedermayer :
> > > > >
> > > > > > 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 :
> > > > > > >
> > > > > > > > Based on patch by Wolfgang Lorenz
> > > > > > > > Signed-off-by: Michael Niedermayer
> > > > > > > > ---
> > > > > > > > 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
[FFmpeg-devel] [PATCH 1/3] swscale/x86/rgb2rgb_template: add missing xmm clobbers
Signed-off-by: James Almer
---
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 --- 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 3/3] swscale/x86/rgb2rgb_template: fix signedness of v in shuffle_bytes_2103_{mmx, mmxext}
Signed-off-by: James Almer
---
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 (; idx<15; 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] = (v>>16) + g + (v<<16);
}
--
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 Mon, 22 Jun 2015 19:58:09 +0530 Niklesh Lalwani 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 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 2/2] movtextenc.c: Support for Bold, Italic and Underlined styles
On 6/23/15, Philip Langdale 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
