[FFmpeg-devel] [RFC]Print a warning if a subtitle demuxer changes utf16 to utf8.
Hi!
The user should be told by libavformat if it does something unexpected.
Related to ticket #4059.
Please comment, Carl Eugen
diff --git a/libavformat/assdec.c b/libavformat/assdec.c
index ccbf4c0..c62e76f 100644
--- a/libavformat/assdec.c
+++ b/libavformat/assdec.c
@@ -112,7 +112,7 @@ static int ass_read_header(AVFormatContext *s)
int res = 0;
AVStream *st;
FFTextReader tr;
-ff_text_init_avio(&tr, s->pb);
+ff_text_init_avio(s, &tr, s->pb);
st = avformat_new_stream(s, NULL);
if (!st)
diff --git a/libavformat/realtextdec.c b/libavformat/realtextdec.c
index 19af108..fff85d6 100644
--- a/libavformat/realtextdec.c
+++ b/libavformat/realtextdec.c
@@ -65,7 +65,7 @@ static int realtext_read_header(AVFormatContext *s)
char c = 0;
int res = 0, duration = read_ts("60"); // default duration is 60 seconds
FFTextReader tr;
-ff_text_init_avio(&tr, s->pb);
+ff_text_init_avio(s, &tr, s->pb);
if (!st)
return AVERROR(ENOMEM);
diff --git a/libavformat/samidec.c b/libavformat/samidec.c
index 4dbf2cf..948e1ed 100644
--- a/libavformat/samidec.c
+++ b/libavformat/samidec.c
@@ -54,7 +54,7 @@ static int sami_read_header(AVFormatContext *s)
char c = 0;
int res = 0, got_first_sync_point = 0;
FFTextReader tr;
-ff_text_init_avio(&tr, s->pb);
+ff_text_init_avio(s, &tr, s->pb);
if (!st)
return AVERROR(ENOMEM);
diff --git a/libavformat/srtdec.c b/libavformat/srtdec.c
index 02d75f1..b35e50f 100644
--- a/libavformat/srtdec.c
+++ b/libavformat/srtdec.c
@@ -87,7 +87,7 @@ static int srt_read_header(AVFormatContext *s)
AVStream *st = avformat_new_stream(s, NULL);
int res = 0;
FFTextReader tr;
-ff_text_init_avio(&tr, s->pb);
+ff_text_init_avio(s, &tr, s->pb);
if (!st)
return AVERROR(ENOMEM);
diff --git a/libavformat/subtitles.c b/libavformat/subtitles.c
index 95faca6..b270dc5 100644
--- a/libavformat/subtitles.c
+++ b/libavformat/subtitles.c
@@ -24,7 +24,7 @@
#include "libavutil/avassert.h"
#include "libavutil/avstring.h"
-void ff_text_init_avio(FFTextReader *r, AVIOContext *pb)
+void ff_text_init_avio(AVFormatContext *s, FFTextReader *r, AVIOContext *pb)
{
int i;
r->pb = pb;
@@ -45,13 +45,16 @@ void ff_text_init_avio(FFTextReader *r, AVIOContext *pb)
r->buf_pos += 3;
}
}
+if (s && (r->type == FF_UTF16LE || r->type == FF_UTF16BE))
+av_log(s, AV_LOG_WARNING,
+ "UTF16 is automatically converted to UTF8, do not specify a
character encoding\n");
}
void ff_text_init_buf(FFTextReader *r, void *buf, size_t size)
{
memset(&r->buf_pb, 0, sizeof(r->buf_pb));
ffio_init_context(&r->buf_pb, buf, size, 0, NULL, NULL, NULL, NULL);
-ff_text_init_avio(r, &r->buf_pb);
+ff_text_init_avio(NULL, r, &r->buf_pb);
}
int64_t ff_text_pos(FFTextReader *r)
diff --git a/libavformat/subtitles.h b/libavformat/subtitles.h
index 903c24d..c549584 100644
--- a/libavformat/subtitles.h
+++ b/libavformat/subtitles.h
@@ -53,10 +53,11 @@ typedef struct {
* The purpose of FFTextReader is to transparently convert read data to UTF-8
* if the stream had a UTF-16 BOM.
*
+ * @param s AVFormatContext to provide av_log context
* @param r object which will be initialized
* @param pb stream to read from (referenced as long as FFTextReader is in use)
*/
-void ff_text_init_avio(FFTextReader *r, AVIOContext *pb);
+void ff_text_init_avio(AVFormatContext *s, FFTextReader *r, AVIOContext *pb);
/**
* Similar to ff_text_init_avio(), but sets it up to read from a bounded
buffer.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Autodetect xcb
Hi! I don't remember a report about xlib autodetection and we won't get a bug-report without it. Please comment, Carl Eugen diff --git a/configure b/configure index 0a1b154..15bf471 100755 --- a/configure +++ b/configure @@ -251,7 +251,7 @@ External library support: --enable-libx264 enable H.264 encoding via x264 [no] --enable-libx265 enable HEVC encoding via x265 [no] --enable-libxavs enable AVS encoding via xavs [no] - --enable-libxcb enable X11 grabbing using XCB [no] + --enable-libxcb enable X11 grabbing using XCB [autodetect] --enable-libxcb-shm enable X11 grabbing shm communication [auto] --enable-libxcb-xfixes enable X11 grabbing mouse rendering [auto] --enable-libxvid enable Xvid encoding via xvidcore, @@ -2723,7 +2723,7 @@ set_default sws_max_filter_size # Enable hwaccels by default. enable dxva2 vaapi vda vdpau xvmc -enable xlib +enable xlib libxcb # build settings SHFLAGS='-shared -Wl,-soname,$$(@F)' ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
On Tue, Oct 28, 2014 at 1:25 AM, Clément Bœsch wrote:
> On Mon, Oct 27, 2014 at 08:54:11PM +0100, Clément Bœsch wrote:
> [...]
> > Can you add a FATE test similar to this? See tests/fate/filter-video.mak.
>
> similar to hqx I meant
>
> --
> Clément B.
>
Updated patch.
I will try adding the FATE test by tonight.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
From e5278383f143fd9c184710ddd4535d8b198fcff9 Mon Sep 17 00:00:00 2001
From: Arwa Arif
Date: Sat, 25 Oct 2014 22:04:51 +0530
Subject: [PATCH] [PATCH]lavfi: add xbr filter
---
doc/filters.texi |7 +
libavfilter/Makefile |1 +
libavfilter/allfilters.c |1 +
libavfilter/vf_xbr.c | 318 ++
4 files changed, 327 insertions(+)
create mode 100644 libavfilter/vf_xbr.c
diff --git a/doc/filters.texi b/doc/filters.texi
index c70ddf3..5fa1d08 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -9159,6 +9159,13 @@ Only deinterlace frames marked as interlaced.
Default value is @samp{all}.
@end table
+@section xbr
+
+A high-quality magnification filter which is designed for pixel art. It follows a set
+of edge-detection rules @url{http://www.libretro.com/forums/viewtopic.php?f=6&t=134}.
+This filter was originally created by Hyllian. The current implementation scales the
+image by scale factor 2.
+
@anchor{yadif}
@section yadif
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 6d868e7..2c56e38 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -198,6 +198,7 @@ OBJS-$(CONFIG_VIDSTABDETECT_FILTER) += vidstabutils.o vf_vidstabdetect.
OBJS-$(CONFIG_VIDSTABTRANSFORM_FILTER) += vidstabutils.o vf_vidstabtransform.o
OBJS-$(CONFIG_VIGNETTE_FILTER) += vf_vignette.o
OBJS-$(CONFIG_W3FDIF_FILTER) += vf_w3fdif.o
+OBJS-$(CONFIG_XBR_FILTER)+= vf_xbr.o
OBJS-$(CONFIG_YADIF_FILTER) += vf_yadif.o
OBJS-$(CONFIG_ZMQ_FILTER)+= f_zmq.o
OBJS-$(CONFIG_ZOOMPAN_FILTER)+= vf_zoompan.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index d88a9ad..2352d44 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -213,6 +213,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(VIDSTABTRANSFORM, vidstabtransform, vf);
REGISTER_FILTER(VIGNETTE, vignette, vf);
REGISTER_FILTER(W3FDIF, w3fdif, vf);
+REGISTER_FILTER(XBR,xbr,vf);
REGISTER_FILTER(YADIF, yadif, vf);
REGISTER_FILTER(ZMQ,zmq,vf);
REGISTER_FILTER(ZOOMPAN,zoompan,vf);
diff --git a/libavfilter/vf_xbr.c b/libavfilter/vf_xbr.c
new file mode 100644
index 000..a000baf
--- /dev/null
+++ b/libavfilter/vf_xbr.c
@@ -0,0 +1,318 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * Copyright (c) 2014 Arwa Arif
+ *
+ * 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
+ * XBR Filter is used for depixelization of image.
+ * This is based on Hyllian's 2xBR shader.
+ * 2xBR Filter v0.2.5
+ * @see : http://www.libretro.com/forums/viewtopic.php?f=6&t=134
+ * Future work : To implement x3 and x4 scale, and threading.
+ */
+
+#include "libavutil/opt.h"
+#include "libavutil/avassert.h"
+#include "libavutil/pixdesc.h"
+#include "internal.h"
+
+typedef struct {
+uint32_t rgbtoyuv[1<<24];
+} xBRContext;
+
+/**
+* Calculates the weight of difference of the pixels, by transforming these
+* pixels into their Y'UV parts. It then uses the threshold used by HQx filters:
+* 48*Y + 7*U + 6*V, to give it those smooth looking edges.
+**/
+static int d(AVFrame *in,int x1,int y1,int x2,int y2,const uint32_t *r2y){
+
+#define YMASK 0xff
+#define UMASK 0x00ff00
+#define VMASK 0xff
+
+int r1 = *(in->data[0] + y1 * in->linesize[0] + x1*3);
+int g1 = *(in->data[0] + y1 * in->linesize[0] + x1*3 + 1);
+int b1 = *(in->data[0] + y1 * in->linesize[0] + x1*3 + 2);
+
+int r2 = *(in->data[0] + y2 * in->linesize[0] + x2*3);
+int g2 = *(in->data[0] + y2 * in->linesize[0] + x2*3 + 1);
+int b2 = *(in->data[0] + y2 * in->linesize[0] + x2*3 + 2);
+
+
Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
On Tue, Oct 28, 2014 at 01:45:06PM +0530, arwa arif wrote: > On Tue, Oct 28, 2014 at 1:25 AM, Clément Bœsch wrote: > > > On Mon, Oct 27, 2014 at 08:54:11PM +0100, Clément Bœsch wrote: > > [...] > > > Can you add a FATE test similar to this? See tests/fate/filter-video.mak. > > > > similar to hqx I meant > > > > -- > > Clément B. > > > > Updated patch. > I will try adding the FATE test by tonight. > If you can also fix your style and the tabs that would be great. [...] -- Clément B. pgpj7EYptJPsJ.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
On Tue, Oct 28, 2014 at 1:52 PM, Clément Bœsch wrote: > On Tue, Oct 28, 2014 at 01:45:06PM +0530, arwa arif wrote: > > On Tue, Oct 28, 2014 at 1:25 AM, Clément Bœsch wrote: > > > > > On Mon, Oct 27, 2014 at 08:54:11PM +0100, Clément Bœsch wrote: > > > [...] > > > > Can you add a FATE test similar to this? See > tests/fate/filter-video.mak. > > > > > > similar to hqx I meant > > > > > > -- > > > Clément B. > > > > > > > Updated patch. > > I will try adding the FATE test by tonight. > > > > If you can also fix your style and the tabs that would be great. > > [...] > > -- > Clément B. > > I have fixed the tabs. And, what style do you want me to fix? > ___ > 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] lavfi: add xbr filter
On Tue, Oct 28, 2014 at 02:01:15PM +0530, arwa arif wrote: > On Tue, Oct 28, 2014 at 1:52 PM, Clément Bœsch wrote: > > > On Tue, Oct 28, 2014 at 01:45:06PM +0530, arwa arif wrote: > > > On Tue, Oct 28, 2014 at 1:25 AM, Clément Bœsch wrote: > > > > > > > On Mon, Oct 27, 2014 at 08:54:11PM +0100, Clément Bœsch wrote: > > > > [...] > > > > > Can you add a FATE test similar to this? See > > tests/fate/filter-video.mak. > > > > > > > > similar to hqx I meant > > > > > > > > -- > > > > Clément B. > > > > > > > > > > Updated patch. > > > I will try adding the FATE test by tonight. > > > > > > > If you can also fix your style and the tabs that would be great. > > > > [...] > > > > -- > > Clément B. > > > > > I have fixed the tabs. And, what style do you want me to fix? > One tab was remaining. At least the prototypes don't respect the coding style; I pointed it out in previous mails. [...] -- Clément B. pgpd37dz8x4oz.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Print a warning if a subtitle demuxer changes utf16 to utf8.
On Tue, Oct 28, 2014 at 08:35:12AM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> The user should be told by libavformat if it does something unexpected.
> Related to ticket #4059.
>
> Please comment, Carl Eugen
[...]
> -void ff_text_init_avio(FFTextReader *r, AVIOContext *pb)
> +void ff_text_init_avio(AVFormatContext *s, FFTextReader *r, AVIOContext *pb)
> {
> int i;
> r->pb = pb;
> @@ -45,13 +45,16 @@ void ff_text_init_avio(FFTextReader *r, AVIOContext *pb)
> r->buf_pos += 3;
> }
> }
> +if (s && (r->type == FF_UTF16LE || r->type == FF_UTF16BE))
> +av_log(s, AV_LOG_WARNING,
> + "UTF16 is automatically converted to UTF8, do not specify a
> character encoding\n");
av_log() accepts a NULL pointer, this is confusing: you don't want to warn
when there is no log context?
> }
>
> void ff_text_init_buf(FFTextReader *r, void *buf, size_t size)
> {
> memset(&r->buf_pb, 0, sizeof(r->buf_pb));
> ffio_init_context(&r->buf_pb, buf, size, 0, NULL, NULL, NULL, NULL);
> -ff_text_init_avio(r, &r->buf_pb);
> +ff_text_init_avio(NULL, r, &r->buf_pb);
> }
>
> int64_t ff_text_pos(FFTextReader *r)
> diff --git a/libavformat/subtitles.h b/libavformat/subtitles.h
> index 903c24d..c549584 100644
> --- a/libavformat/subtitles.h
> +++ b/libavformat/subtitles.h
> @@ -53,10 +53,11 @@ typedef struct {
> * The purpose of FFTextReader is to transparently convert read data to UTF-8
> * if the stream had a UTF-16 BOM.
> *
> + * @param s AVFormatContext to provide av_log context
> * @param r object which will be initialized
> * @param pb stream to read from (referenced as long as FFTextReader is in
> use)
> */
> -void ff_text_init_avio(FFTextReader *r, AVIOContext *pb);
> +void ff_text_init_avio(AVFormatContext *s, FFTextReader *r, AVIOContext *pb);
If you want to use it only for logging, make it void*
[...]
Not commenting on the patch itself.
--
Clément B.
pgpwkf2saGh2F.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Print a warning if a subtitle demuxer changes utf16 to utf8.
On Tue, 28 Oct 2014 08:35:12 +0100 Carl Eugen Hoyos wrote: > Hi! > > The user should be told by libavformat if it does something unexpected. > Related to ticket #4059. > > Please comment, Carl Eugen Why should it print a warning in this case, but not other cases when the subtitle packets are already in UTF-8, such as Matroska? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Print a warning if a subtitle demuxer changes utf16 to utf8.
Le septidi 7 brumaire, an CCXXIII, Carl Eugen Hoyos a écrit : > The user should be told by libavformat if it does something unexpected. > Related to ticket #4059. I do not object to this quick fix, but the correct fix would be to set the codec context sub_charenc and sub_charenc_mode correctly in the demuxer. 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] [RFC]Print a warning if a subtitle demuxer changes utf16 to utf8.
On Tue, 28 Oct 2014 09:58:48 +0100 Nicolas George wrote: > Le septidi 7 brumaire, an CCXXIII, Carl Eugen Hoyos a écrit : > > The user should be told by libavformat if it does something unexpected. > > Related to ticket #4059. > > I do not object to this quick fix, but the correct fix would be to set the > codec context sub_charenc and sub_charenc_mode correctly in the demuxer. > > Regards, > Since when is subchar_enc to be set in the demuxers? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Print a warning if a subtitle demuxer changes utf16 to utf8.
On Tuesday 28 October 2014 09:56:28 am Clément Bœsch wrote: > > +if (s && (r->type == FF_UTF16LE || r->type == FF_UTF16BE)) > > +av_log(s, AV_LOG_WARNING, > > + "UTF16 is automatically converted to UTF8, do not specify > > a character encoding\n"); > > av_log() accepts a NULL pointer, this is confusing: you don't want to warn > when there is no log context? It spams the console (from probing) without this check > > -void ff_text_init_avio(FFTextReader *r, AVIOContext *pb); > > +void ff_text_init_avio(AVFormatContext *s, FFTextReader *r, AVIOContext > > *pb); > > If you want to use it only for logging, make it void* Why is this better? I mean the function is not public and only used from within libavformat, so why not using the actual type? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Print a warning if a subtitle demuxer changes utf16 to utf8.
On Tuesday 28 October 2014 09:57:12 am wm4 wrote: > > The user should be told by libavformat if it does something unexpected. > > Related to ticket #4059. > > Why should it print a warning in this case, but not other cases when > the subtitle packets are already in UTF-8, such as Matroska? I'd like to print a warning in that case as well, how can I reproduce it? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Print a warning if a subtitle demuxer changes utf16 to utf8.
Le septidi 7 brumaire, an CCXXIII, Carl Eugen Hoyos a écrit : > I'd like to print a warning in that case as well, how can I > reproduce it? There is nothing to reproduce: text subtitles in Matroska are UTF-8, period. 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] [FFmpeg-cvslog] xcbgrab: XCB-based screen capture
Le sextidi 6 brumaire, an CCXXIII, compn a écrit :
> so its name is changed in the makefile, but not the device name?
It seems that Anton noticed it too on the other side.
> from x11grab.c:
>
> static const AVOption options[] = {
> { "draw_mouse", "draw the mouse pointer", OFFSET(draw_mouse),
> AV_OPT_TYPE_INT, {.i64 = 1}, 0, 1, DEC },
> { "follow_mouse", "move the grabbing region when the mouse pointer
> reaches within specified amount of pixels to the edge of region",
> OFFSET(follow_mouse), AV_OPT_TYPE_INT, {.i64 = 0}, -1, INT_MAX, DEC,
> "follow_mouse" },
> { "centered", "keep the mouse pointer at the center of grabbing
> region when following",
> 0, AV_OPT_TYPE_CONST, {.i64 = -1}, INT_MIN, INT_MAX, DEC,
> "follow_mouse" },
I am sorry, I do not understand the point you are trying to make by quoting
that piece of code. Are there options present in FFmpeg's x11grab that are
absent from this new xcbgrab, possibly because they were absent from libav's
x11grab? Or is it just related to your next point?
> is this file based on x11grab.c ? if so , copyrights need to be
> modified.
Depends on what you call "based on". This file is certainly based on
x11grab.c in the sense that it has been written to imitate x11grab.c in
terms of features and working logic, but that does not elicit copyright.
Regarding the code itself, my understanding reading Luca's messages is that
it is a new implementation. Of course, the parts that are far from the
back-end library and straightforward are bound to look similar.
> i've confused myself with x11grab x11grab_xlib and x11grab_xcb , is the
> name of this demuxer correct?
Well, this can be confusing if you did not follow the evolution of X.
X11 is the name of the protocol.
Xlib is the usual name of the most common library used to write client
applications.
libX11 is the technical name of Xlib, i.e. the file name and SONAME.
XCB is the usual name of the new client library produced by X.org /
Freedesktop.
Technically, XCB is slightly lower-level but more efficient than Xlib.
From an user's point of view, whether an application uses XCB or Xlib should
not matter. This is even truer nowadays, because most users have X.org's
implementation of Xlib, which is a wrapper around XCB.
Therefore, I think it is logical to have both devices called "x11grab", i.e.
"grab from an X11 server".
The same goes whenever there are several feature-equivalent implementations
for the same thing: you do not have both httpopenssl:// and httpgnutls://,
you just have https:// using one of the library internally.
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] [RFC]Print a warning if a subtitle demuxer changes utf16 to utf8.
On Tue, Oct 28, 2014 at 10:02:18AM +0100, Carl Eugen Hoyos wrote: > On Tuesday 28 October 2014 09:56:28 am Clément Bœsch wrote: > > > > +if (s && (r->type == FF_UTF16LE || r->type == FF_UTF16BE)) > > > +av_log(s, AV_LOG_WARNING, > > > + "UTF16 is automatically converted to UTF8, do not specify > > > a character encoding\n"); > > > > av_log() accepts a NULL pointer, this is confusing: you don't want to warn > > when there is no log context? > > It spams the console (from probing) without this check > So the behaviour depends on its state; this should be said in the doxy. > > > -void ff_text_init_avio(FFTextReader *r, AVIOContext *pb); > > > +void ff_text_init_avio(AVFormatContext *s, FFTextReader *r, AVIOContext > > > *pb); > > > > If you want to use it only for logging, make it void* > > Why is this better? > > I mean the function is not public and only used from within libavformat, > so why not using the actual type? > Because it suggests you're going to access the content of the format context (like, maybe you are reading and writing avctx->sub_charenc or something?) > Thank you, Carl Eugen -- Clément B. pgppGhwm0dT4t.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Print a warning if a subtitle demuxer changes utf16 to utf8.
On Tue, 28 Oct 2014 10:03:18 +0100 Carl Eugen Hoyos wrote: > On Tuesday 28 October 2014 09:57:12 am wm4 wrote: > > > > The user should be told by libavformat if it does something unexpected. > > > Related to ticket #4059. > > > > Why should it print a warning in this case, but not other cases when > > the subtitle packets are already in UTF-8, such as Matroska? > > I'd like to print a warning in that case as well, how can I > reproduce it? echo -e '1\n00:00:00,000 --> 00:00:10,000\näöü' > test.srt mkvmerge -o test.mks test.srt ffmpeg -subcharenc latin1 -i test.mks out.srt Broken as shit. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/6] dv: increase reading bits to 10
Hi,
2014-10-26 23:37 GMT+01:00 Michael Niedermayer :
>> -#define TEX_VLC_BITS 9
>> +#define TEX_VLC_BITS 10
>
> this probably needs an update to these:
>
> libavcodec/dv.c:RL_VLC_ELEM ff_dv_rl_vlc[1184];
> libavcodec/dv.c:av_assert1(dv_vlc.table_size == 1184);
So the related assert does not trigger here, because it is not
compiled in. Strangely I had no fate failures. Probably the tests do
not exercise some of the vlcs.
Here's an updated patch.
--
Christophe
From 8d1905d01f2974559780a6b3aac3ecd6945f7897 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Tue, 14 Oct 2014 02:02:36 +0200
Subject: [PATCH 1/2] dv: increase VLC reading bits to 10
This also requires a bump in the table size of bit patterns to 1664.
From 356 to 348 cycles.
---
libavcodec/dv.c | 4 ++--
libavcodec/dv.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/dv.c b/libavcodec/dv.c
index 6cd8a89..2bc7fc5 100644
--- a/libavcodec/dv.c
+++ b/libavcodec/dv.c
@@ -50,7 +50,7 @@
#include "simple_idct.h"
/* XXX: also include quantization */
-RL_VLC_ELEM ff_dv_rl_vlc[1184];
+RL_VLC_ELEM ff_dv_rl_vlc[1664];
static inline void dv_calc_mb_coordinates(const AVDVProfile *d, int chan,
int seq, int slot, uint16_t *tbl)
@@ -243,7 +243,7 @@ av_cold int ff_dvvideo_init(AVCodecContext *avctx)
* to accelerate the parsing of partial codes */
init_vlc(&dv_vlc, TEX_VLC_BITS, j, new_dv_vlc_len,
1, 1, new_dv_vlc_bits, 2, 2, 0);
-av_assert1(dv_vlc.table_size == 1184);
+av_assert1(dv_vlc.table_size == 1664);
for (i = 0; i < dv_vlc.table_size; i++) {
int code = dv_vlc.table[i][0];
diff --git a/libavcodec/dv.h b/libavcodec/dv.h
index e68d7b0..5d28263 100644
--- a/libavcodec/dv.h
+++ b/libavcodec/dv.h
@@ -90,9 +90,9 @@ enum dv_pack_type {
*/
#define DV_MAX_BPM 8
-#define TEX_VLC_BITS 9
+#define TEX_VLC_BITS 10
-extern RL_VLC_ELEM ff_dv_rl_vlc[1184];
+extern RL_VLC_ELEM ff_dv_rl_vlc[1664];
int ff_dv_init_dynamic_tables(DVVideoContext *s, const AVDVProfile *d);
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] dvenc: mark encoder as intra
Fate tests ran for this+vlc patch on top of master's 39680ca (ie
including the previous series of patches):
fate-lavf-dv_fmt fate-vsynth2-dv fate-vsynth2-dv-411
fate-vsynth2-dv-50 fate-vsynth1-dv fate-vsy nth1-dv-411
fate-vsynth1-dv-50 fate-seek-lavf-dv_fmt fate-seek-vsynth2-dv
fate-seek-vsynth2-dv-50 fate- seek-vsynth2-dv-411
The encoder already supported "slice" (actually segment) threading.
--
Christophe
From b1f2ee04b003216a496c124f895da246ef4f69e9 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Wed, 15 Oct 2014 18:37:34 +0200
Subject: [PATCH 2/2] dvenc: mark encoder as intra
And thus allow various multithreading.
---
libavcodec/dvenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dvenc.c b/libavcodec/dvenc.c
index a3868c4..5d810e3 100644
--- a/libavcodec/dvenc.c
+++ b/libavcodec/dvenc.c
@@ -758,7 +758,7 @@ AVCodec ff_dvvideo_encoder = {
.init = dvvideo_encode_init,
.encode2= dvvideo_encode_frame,
.close = dvvideo_encode_close,
-.capabilities = CODEC_CAP_SLICE_THREADS,
+.capabilities = CODEC_CAP_SLICE_THREADS | CODEC_CAP_FRAME_THREADS | CODEC_CAP_INTRA_ONLY,
.pix_fmts = (const enum AVPixelFormat[]) {
AV_PIX_FMT_YUV411P, AV_PIX_FMT_YUV422P,
AV_PIX_FMT_YUV420P, AV_PIX_FMT_NONE
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/6] dv: increase reading bits to 10
On Tue, Oct 28, 2014 at 10:48:52AM +0100, Christophe Gisquet wrote: > Hi, > > 2014-10-26 23:37 GMT+01:00 Michael Niedermayer : > >> -#define TEX_VLC_BITS 9 > >> +#define TEX_VLC_BITS 10 > > > > this probably needs an update to these: > > > > libavcodec/dv.c:RL_VLC_ELEM ff_dv_rl_vlc[1184]; > > libavcodec/dv.c:av_assert1(dv_vlc.table_size == 1184); > > So the related assert does not trigger here, because it is not > compiled in. Strangely I had no fate failures. Probably the tests do > not exercise some of the vlcs. > > Here's an updated patch. > > -- > Christophe > dv.c |4 ++-- > dv.h |4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > e9afa3df912ef45e88f6936143b2bb2f413fe8bb > 0001-dv-increase-VLC-reading-bits-to-10.patch > From 8d1905d01f2974559780a6b3aac3ecd6945f7897 Mon Sep 17 00:00:00 2001 > From: Christophe Gisquet > Date: Tue, 14 Oct 2014 02:02:36 +0200 > Subject: [PATCH 1/2] dv: increase VLC reading bits to 10 > > This also requires a bump in the table size of bit patterns to 1664. > From 356 to 348 cycles. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] xcbgrab: XCB-based screen capture
On Tue, Oct 28, 2014 at 10:05:29AM +0100, Nicolas George wrote: > Le sextidi 6 brumaire, an CCXXIII, compn a écrit : > > so its name is changed in the makefile, but not the device name? [...] > Therefore, I think it is logical to have both devices called "x11grab", i.e. > "grab from an X11 server". > > The same goes whenever there are several feature-equivalent implementations > for the same thing: you do not have both httpopenssl:// and httpgnutls://, > you just have https:// using one of the library internally. this makes it impossible to switch between them without recompiling though for development and testing it may be usefull to enable both though one example are fate clients, which if these parts are mutually exclusive potentially wont compile test both or if they can be enabled at build time one wouldnt be able to select which to use at runtime as their names equal we maybe should introduce in addition to the default https & x11grab a x11grab_xcb and x11grab_x11 or something like that [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] dvenc: mark encoder as intra
On Tue, Oct 28, 2014 at 10:58:11AM +0100, Christophe Gisquet wrote: > Fate tests ran for this+vlc patch on top of master's 39680ca (ie > including the previous series of patches): > > fate-lavf-dv_fmt fate-vsynth2-dv fate-vsynth2-dv-411 > fate-vsynth2-dv-50 fate-vsynth1-dv fate-vsy nth1-dv-411 > fate-vsynth1-dv-50 fate-seek-lavf-dv_fmt fate-seek-vsynth2-dv > fate-seek-vsynth2-dv-50 fate- seek-vsynth2-dv-411 > > The encoder already supported "slice" (actually segment) threading. > > -- > Christophe > dvenc.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > f9ef9375c48e4ea0caa40bfc41495f31fad06452 > 0002-dvenc-mark-encoder-as-intra.patch > From b1f2ee04b003216a496c124f895da246ef4f69e9 Mon Sep 17 00:00:00 2001 > From: Christophe Gisquet > Date: Wed, 15 Oct 2014 18:37:34 +0200 > Subject: [PATCH 2/2] dvenc: mark encoder as intra > > And thus allow various multithreading. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/5] mxfdec: Break out parts of mxf_read_header() into separate functions
This is part of a series of patches that fix tickets 3278 and 4040
(http://trac.ffmpeg.org/ticket/3278 http://trac.ffmpeg.org/ticket/4040),
plus some refactoring.
I uploaded a file called deadlock3.mxf (and corresponding deadlock3.txt)
to incoming that demonstrates another issue similar to Ticket3278 (see
patch 2/5).
/TomasFrom 55117f8fd8d209830db8932a1c59f0b309e3ac44 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Tue, 28 Oct 2014 13:33:04 +0100
Subject: [PATCH 1/5] mxfdec: Break out parts of mxf_read_header() into
separate functions
---
libavformat/mxfdec.c | 69 +++-
1 file changed, 47 insertions(+), 22 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index b01dd0c..31adece 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2031,6 +2031,51 @@ static int mxf_read_local_tags(MXFContext *mxf,
KLVPacket *klv, MXFMetadataReadF
}
/**
+ * Matches any partition pack key, in other words:
+ * - HeaderPartition
+ * - BodyPartition
+ * - FooterPartition
+ * @return non-zero if the key is a partition pack key, zero otherwise
+ */
+static int mxf_is_partition_pack_key(UID key)
+{
+//NOTE: this is a little lax since it doesn't constraint key[14]
+return !memcmp(key, mxf_header_partition_pack_key, 13) &&
+key[13] >= 2 && key[13] <= 4;
+}
+
+/**
+ * Parses a metadata KLV
+ * @return <0 on error, 0 otherwise
+ */
+static int mxf_parse_klv(MXFContext *mxf, KLVPacket klv, MXFMetadataReadFunc
*read,
+ int ctx_size, enum MXFMetadataSetType
type)
+{
+AVFormatContext *s = mxf->fc;
+int res;
+if (klv.key[5] == 0x53) {
+res = mxf_read_local_tags(mxf, &klv, read, ctx_size, type);
+} else {
+uint64_t next = avio_tell(s->pb) + klv.length;
+res = read(mxf, s->pb, 0, klv.length, klv.key, klv.offset);
+
+/* only seek forward, else this can loop for a long time */
+if (avio_tell(s->pb) > next) {
+av_log(s, AV_LOG_ERROR, "read past end of KLV @ %#"PRIx64"\n",
+ klv.offset);
+return AVERROR_INVALIDDATA;
+}
+
+avio_seek(s->pb, next, SEEK_SET);
+}
+if (res < 0) {
+av_log(s, AV_LOG_ERROR, "error reading header metadata\n");
+return res;
+}
+return 0;
+}
+
+/**
* Seeks to the previous partition, if possible
* @return <= 0 if we should stop parsing, > 0 if we should keep going
*/
@@ -2292,8 +2337,7 @@ static int mxf_read_header(AVFormatContext *s)
if (mxf_parse_handle_essence(mxf) <= 0)
break;
continue;
-} else if (!memcmp(klv.key, mxf_header_partition_pack_key, 13) &&
- klv.key[13] >= 2 && klv.key[13] <= 4 &&
mxf->current_partition) {
+} else if (mxf_is_partition_pack_key(klv.key) &&
mxf->current_partition) {
/* next partition pack - keep going, seek to previous partition or
stop */
if(mxf_parse_handle_partition_or_eof(mxf) <= 0)
break;
@@ -2304,27 +2348,8 @@ static int mxf_read_header(AVFormatContext *s)
for (metadata = mxf_metadata_read_table; metadata->read; metadata++) {
if (IS_KLV_KEY(klv.key, metadata->key)) {
-int res;
-if (klv.key[5] == 0x53) {
-res = mxf_read_local_tags(mxf, &klv, metadata->read,
metadata->ctx_size, metadata->type);
-} else {
-uint64_t next = avio_tell(s->pb) + klv.length;
-res = metadata->read(mxf, s->pb, 0, klv.length, klv.key,
klv.offset);
-
-/* only seek forward, else this can loop for a long time */
-if (avio_tell(s->pb) > next) {
-av_log(s, AV_LOG_ERROR, "read past end of KLV @
%#"PRIx64"\n",
- klv.offset);
-return AVERROR_INVALIDDATA;
-}
-
-avio_seek(s->pb, next, SEEK_SET);
-}
-if (res < 0) {
-av_log(s, AV_LOG_ERROR, "error reading header metadata\n");
-ret = res;
+if ((ret = mxf_parse_klv(mxf, klv, metadata->read,
metadata->ctx_size, metadata->type)) < 0)
goto fail;
-}
break;
} else {
av_log(s, AV_LOG_VERBOSE, "Dark key " PRIxUID "\n",
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] mxfdec: Break out parts of mxf_read_header() into separate functions
This fixes the actual issue (Ticket 3278). See also deadlock3.mxf on
FTP.
/TomasFrom 783aaa31271266587fad8f60a588ed755744a765 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Tue, 28 Oct 2014 13:38:18 +0100
Subject: [PATCH 2/5] mxfdec: Parse PreviousPartition in
mxf_seek_to_previous_partition()
Without this patch the demuxer can get stuck in a loop if PreviousPartition
points somewhere where there's no PartitionPack, or if klv_read_packet() syncs
back up to the current partition.
This should fix Ticket3278 properly and unbreak Ticket4040.
---
libavformat/mxfdec.c | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 31adece..5c9d808 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -89,6 +89,7 @@ typedef struct {
int64_t header_byte_count;
int64_t index_byte_count;
int pack_length;
+int64_t pack_ofs; ///< absolute offset of pack in file,
including run-in
} MXFPartition;
typedef struct {
@@ -472,6 +473,7 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
memset(partition, 0, sizeof(*partition));
mxf->partitions_count++;
partition->pack_length = avio_tell(pb) - klv_offset + size;
+partition->pack_ofs= klv_offset;
switch(uid[13]) {
case 2:
@@ -547,6 +549,7 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
partition->index_sid, partition->body_sid);
/* sanity check PreviousPartition if set */
+//NOTE: this isn't actually enough, see mxf_seek_to_previous_partition()
if (partition->previous_partition &&
mxf->run_in + partition->previous_partition >= klv_offset) {
av_log(mxf->fc, AV_LOG_ERROR,
@@ -2076,23 +2079,53 @@ static int mxf_parse_klv(MXFContext *mxf, KLVPacket
klv, MXFMetadataReadFunc *re
}
/**
- * Seeks to the previous partition, if possible
+ * Seeks to the previous partition and parses it, if possible
* @return <= 0 if we should stop parsing, > 0 if we should keep going
*/
static int mxf_seek_to_previous_partition(MXFContext *mxf)
{
AVIOContext *pb = mxf->fc->pb;
+KLVPacket klv;
+int64_t current_partition_ofs;
+int ret;
if (!mxf->current_partition ||
mxf->run_in + mxf->current_partition->previous_partition <=
mxf->last_forward_tell)
return 0; /* we've parsed all partitions */
/* seek to previous partition */
+current_partition_ofs = mxf->current_partition->pack_ofs; //includes
run-in
avio_seek(pb, mxf->run_in + mxf->current_partition->previous_partition,
SEEK_SET);
mxf->current_partition = NULL;
av_dlog(mxf->fc, "seeking to previous partition\n");
+/* Make sure this is actually a PartitionPack, and if so parse it.
+ * See deadlock2.mxf
+ */
+if ((ret = klv_read_packet(&klv, pb)) < 0) {
+av_log(mxf->fc, AV_LOG_ERROR, "failed to read PartitionPack KLV\n");
+return ret;
+}
+
+if (!mxf_is_partition_pack_key(klv.key)) {
+av_log(mxf->fc, AV_LOG_ERROR, "PreviousPartition @ %" PRIx64 " isn't a
PartitionPack\n", klv.offset);
+return AVERROR_INVALIDDATA;
+}
+
+/* We can't just check ofs >= current_partition_ofs because
PreviousPartition
+ * can point to just before the current partition, causing
klv_read_packet()
+ * to sync back up to it. See deadlock3.mxf
+ */
+if (klv.offset >= current_partition_ofs) {
+av_log(mxf->fc, AV_LOG_ERROR, "PreviousPartition for PartitionPack @ %"
+ PRIx64 " indirectly points to itself\n", current_partition_ofs);
+return AVERROR_INVALIDDATA;
+}
+
+if ((ret = mxf_parse_klv(mxf, klv, mxf_read_partition_pack, 0, 0)) < 0)
+return ret;
+
return 1;
}
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/5] Revert "avformat/mxfdec: detect loops during header parsing
From 662adc4db39b1925c90fc78fb83d58c0e3e6dfd4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Tue, 28 Oct 2014 13:33:47 +0100
Subject: [PATCH 3/5] Revert "avformat/mxfdec: detect loops during header
parsing"
This reverts commit 1c010fd035c1a14dc73827b84f21f593e969a5d6.
---
libavformat/mxfdec.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 5c9d808..ef4b368 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2294,8 +2294,6 @@ static int mxf_read_header(AVFormatContext *s)
MXFContext *mxf = s->priv_data;
KLVPacket klv;
int64_t essence_offset = 0;
-int64_t last_pos = -1;
-uint64_t last_pos_index = 1;
int ret;
mxf->last_forward_tell = INT64_MAX;
@@ -2313,12 +2311,7 @@ static int mxf_read_header(AVFormatContext *s)
while (!avio_feof(s->pb)) {
const MXFMetadataReadTableEntry *metadata;
-if (avio_tell(s->pb) == last_pos) {
-av_log(mxf->fc, AV_LOG_ERROR, "MXF structure loop detected\n");
-return AVERROR_INVALIDDATA;
-}
-if ((1ULL<<61) % last_pos_index++ == 0)
-last_pos = avio_tell(s->pb);
+
if (klv_read_packet(&klv, s->pb) < 0) {
/* EOF - seek to previous partition or stop */
if(mxf_parse_handle_partition_or_eof(mxf) <= 0)
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/5] mxfdec: Merge last_partition and footer_partition
From 86ce75449ef2febb584d7f337a4035ef2cee2b1a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Tue, 28 Oct 2014 14:27:06 +0100
Subject: [PATCH 4/5] mxfdec: Merge last_partition and footer_partition
FooterPartition offset specified in RIP takes precedence over any value written
in PartitionPacks. This fixes the same issue f06f6da tries to fix without
introducing an extra variable.
---
libavformat/mxfdec.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index ef4b368..fd08bf7 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -227,7 +227,6 @@ typedef struct {
struct AVAES *aesc;
uint8_t *local_tags;
int local_tags_count;
-uint64_t last_partition;
uint64_t footer_partition;
KLVPacket current_klv_data;
int current_klv_index;
@@ -2141,30 +2140,27 @@ static int mxf_parse_handle_essence(MXFContext *mxf)
if (mxf->parsing_backward) {
return mxf_seek_to_previous_partition(mxf);
} else {
-uint64_t offset = mxf->footer_partition ? mxf->footer_partition
-: mxf->last_partition;
-
-if (!offset) {
-av_dlog(mxf->fc, "no last partition\n");
+if (!mxf->footer_partition) {
+av_dlog(mxf->fc, "no FooterPartition\n");
return 0;
}
-av_dlog(mxf->fc, "seeking to last partition\n");
+av_dlog(mxf->fc, "seeking to FooterPartition\n");
/* remember where we were so we don't end up seeking further back than
this */
mxf->last_forward_tell = avio_tell(pb);
if (!pb->seekable) {
-av_log(mxf->fc, AV_LOG_INFO, "file is not seekable - not parsing
last partition\n");
+av_log(mxf->fc, AV_LOG_INFO, "file is not seekable - not parsing
FooterPartition\n");
return -1;
}
-/* seek to last partition and parse backward */
-if ((ret = avio_seek(pb, mxf->run_in + offset, SEEK_SET)) < 0) {
+/* seek to FooterPartition and parse backward */
+if ((ret = avio_seek(pb, mxf->run_in + mxf->footer_partition,
SEEK_SET)) < 0) {
av_log(mxf->fc, AV_LOG_ERROR,
- "failed to seek to last partition @ 0x%" PRIx64
+ "failed to seek to FooterPartition @ 0x%" PRIx64
" (%"PRId64") - partial file?\n",
- mxf->run_in + offset, ret);
+ mxf->run_in + mxf->footer_partition, ret);
return ret;
}
@@ -2202,7 +2198,7 @@ static void mxf_compute_essence_containers(MXFContext
*mxf)
continue; /* BodySID == 0 -> no essence */
if (x >= mxf->partitions_count - 1)
-break; /* last partition - can't compute length (and we
don't need to) */
+break; /* FooterPartition - can't compute length (and we
don't need to) */
/* essence container spans to the next partition */
p->essence_length = mxf->partitions[x+1].this_partition -
p->essence_offset;
@@ -2283,7 +2279,7 @@ static void mxf_read_random_index_pack(AVFormatContext *s)
goto end;
avio_skip(s->pb, klv.length - 12);
-mxf->last_partition = avio_rb64(s->pb);
+mxf->footer_partition = avio_rb64(s->pb);
end:
avio_seek(s->pb, mxf->run_in, SEEK_SET);
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/5] mxfdec: Tighten RIP length bounds in mxf_read_random_index_pack()
From d1827479c17186db7bda472e92b272bbdf4ddcfb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Tue, 28 Oct 2014 14:36:27 +0100
Subject: [PATCH 5/5] mxfdec: Tighten RIP length bounds in
mxf_read_random_index_pack()
---
libavformat/mxfdec.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index fd08bf7..8da87e4 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2261,16 +2261,33 @@ static void mxf_read_random_index_pack(AVFormatContext *s)
{
MXFContext *mxf = s->priv_data;
uint32_t length;
-int64_t file_size;
+int64_t file_size, max_rip_length, min_rip_length;
KLVPacket klv;
if (!s->pb->seekable)
return;
file_size = avio_size(s->pb);
+
+/* S377m says to check the RIP length for "silly" values, without defining "silly".
+ * The limit below assumes a file with nothing but partition packs and a RIP.
+ * Before changing this, consider that a muxer may place each sample in its own partition.
+ *
+ * 105 is the size of the smallest possible PartitionPack
+ * 12 is the size of each RIP entry
+ * 28 is the size of the RIP header and footer, assuming an 8-byte BER
+ */
+max_rip_length = ((file_size - mxf->run_in) / 105) * 12 + 28;
+max_rip_length = FFMIN(max_rip_length, INT_MAX); //2 GiB and up is also silly
+
+/* We're only interested in RIPs with at least two entries.. */
+min_rip_length = 16+1+24+4;
+
+/* See S377m section 11 */
avio_seek(s->pb, file_size - 4, SEEK_SET);
length = avio_rb32(s->pb);
-if (length <= 32 || length >= FFMIN(file_size, INT_MAX))
+
+if (length < min_rip_length || length > max_rip_length)
goto end;
avio_seek(s->pb, file_size - length, SEEK_SET);
if (klv_read_packet(&klv, s->pb) < 0 ||
@@ -2281,6 +2298,12 @@ static void mxf_read_random_index_pack(AVFormatContext *s)
avio_skip(s->pb, klv.length - 12);
mxf->footer_partition = avio_rb64(s->pb);
+/* sanity check */
+if (mxf->run_in + mxf->footer_partition >= file_size) {
+av_log(s, AV_LOG_WARNING, "bad FooterPartition in RIP - ignoring\n");
+mxf->footer_partition = 0;
+}
+
end:
avio_seek(s->pb, mxf->run_in, SEEK_SET);
}
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/5] mxfdec: Parse PreviousPartition in mxf_seek_to_previous_partition()
On 2014-10-28 15:31, tomas.har...@codemill.se wrote:
This fixes the actual issue (Ticket 3278). See also deadlock3.mxf on
FTP.
/Tomas
Oops, wrong subject - I should probably set up git-send-email..
Reattached patch just to be sure.
/TomasFrom 783aaa31271266587fad8f60a588ed755744a765 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Tue, 28 Oct 2014 13:38:18 +0100
Subject: [PATCH 2/5] mxfdec: Parse PreviousPartition in
mxf_seek_to_previous_partition()
Without this patch the demuxer can get stuck in a loop if PreviousPartition
points somewhere where there's no PartitionPack, or if klv_read_packet() syncs
back up to the current partition.
This should fix Ticket3278 properly and unbreak Ticket4040.
---
libavformat/mxfdec.c | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 31adece..5c9d808 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -89,6 +89,7 @@ typedef struct {
int64_t header_byte_count;
int64_t index_byte_count;
int pack_length;
+int64_t pack_ofs; ///< absolute offset of pack in file,
including run-in
} MXFPartition;
typedef struct {
@@ -472,6 +473,7 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
memset(partition, 0, sizeof(*partition));
mxf->partitions_count++;
partition->pack_length = avio_tell(pb) - klv_offset + size;
+partition->pack_ofs= klv_offset;
switch(uid[13]) {
case 2:
@@ -547,6 +549,7 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
partition->index_sid, partition->body_sid);
/* sanity check PreviousPartition if set */
+//NOTE: this isn't actually enough, see mxf_seek_to_previous_partition()
if (partition->previous_partition &&
mxf->run_in + partition->previous_partition >= klv_offset) {
av_log(mxf->fc, AV_LOG_ERROR,
@@ -2076,23 +2079,53 @@ static int mxf_parse_klv(MXFContext *mxf, KLVPacket
klv, MXFMetadataReadFunc *re
}
/**
- * Seeks to the previous partition, if possible
+ * Seeks to the previous partition and parses it, if possible
* @return <= 0 if we should stop parsing, > 0 if we should keep going
*/
static int mxf_seek_to_previous_partition(MXFContext *mxf)
{
AVIOContext *pb = mxf->fc->pb;
+KLVPacket klv;
+int64_t current_partition_ofs;
+int ret;
if (!mxf->current_partition ||
mxf->run_in + mxf->current_partition->previous_partition <=
mxf->last_forward_tell)
return 0; /* we've parsed all partitions */
/* seek to previous partition */
+current_partition_ofs = mxf->current_partition->pack_ofs; //includes
run-in
avio_seek(pb, mxf->run_in + mxf->current_partition->previous_partition,
SEEK_SET);
mxf->current_partition = NULL;
av_dlog(mxf->fc, "seeking to previous partition\n");
+/* Make sure this is actually a PartitionPack, and if so parse it.
+ * See deadlock2.mxf
+ */
+if ((ret = klv_read_packet(&klv, pb)) < 0) {
+av_log(mxf->fc, AV_LOG_ERROR, "failed to read PartitionPack KLV\n");
+return ret;
+}
+
+if (!mxf_is_partition_pack_key(klv.key)) {
+av_log(mxf->fc, AV_LOG_ERROR, "PreviousPartition @ %" PRIx64 " isn't a
PartitionPack\n", klv.offset);
+return AVERROR_INVALIDDATA;
+}
+
+/* We can't just check ofs >= current_partition_ofs because
PreviousPartition
+ * can point to just before the current partition, causing
klv_read_packet()
+ * to sync back up to it. See deadlock3.mxf
+ */
+if (klv.offset >= current_partition_ofs) {
+av_log(mxf->fc, AV_LOG_ERROR, "PreviousPartition for PartitionPack @ %"
+ PRIx64 " indirectly points to itself\n", current_partition_ofs);
+return AVERROR_INVALIDDATA;
+}
+
+if ((ret = mxf_parse_klv(mxf, klv, mxf_read_partition_pack, 0, 0)) < 0)
+return ret;
+
return 1;
}
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: AVC Intra support
I´m not happy with the for-loop I coded yesterday night, so I made a new patch.
Regards,
Thomas
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -42,6 +42,8 @@
#include "libavutil/time_internal.h"
#include "libavcodec/bytestream.h"
#include "libavcodec/dnxhddata.h"
+#include "libavcodec/h264.h"
+#include "libavcodec/internal.h"
#include "audiointerleave.h"
#include "avformat.h"
#include "avio_internal.h"
@@ -98,6 +100,7 @@
{ AV_CODEC_ID_DVVIDEO, 15 },
{ AV_CODEC_ID_DNXHD, 24 },
{ AV_CODEC_ID_JPEG2000, 34 },
+{ AV_CODEC_ID_H264, 35 },
{ AV_CODEC_ID_NONE }
};
@@ -274,6 +277,11 @@
{
0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x08,0x00
},
{
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x04,0x01,0x02,0x02,0x03,0x01,0x01,0x00
},
mxf_write_cdci_desc },
+// H.264
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x0D,0x01,0x03,0x01,0x02,0x10,0x60,0x01
},
+ {
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x05,0x00
},
+ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x00,0x00,0x00
},
+ mxf_write_mpegvideo_desc },
{ {
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
},
{
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
},
{
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
},
@@ -989,17 +997,21 @@
MXFStreamContext *sc = st->priv_data;
int profile_and_level = (st->codec->profile<<4) | st->codec->level;
-mxf_write_cdci_common(s, st, mxf_mpegvideo_descriptor_key, 8+5);
+if (st->codec->codec_id != AV_CODEC_ID_H264) {
+mxf_write_cdci_common(s, st, mxf_mpegvideo_descriptor_key, 8+5);
-// bit rate
-mxf_write_local_tag(pb, 4, 0x8000);
-avio_wb32(pb, sc->video_bit_rate);
-
-// profile and level
-mxf_write_local_tag(pb, 1, 0x8007);
-if (!st->codec->profile)
-profile_and_level |= 0x80; // escape bit
-avio_w8(pb, profile_and_level);
+// bit rate
+mxf_write_local_tag(pb, 4, 0x8000);
+avio_wb32(pb, sc->video_bit_rate);
+
+// profile and level
+mxf_write_local_tag(pb, 1, 0x8007);
+if (!st->codec->profile)
+profile_and_level |= 0x80; // escape bit
+avio_w8(pb, profile_and_level);
+}
+else
+mxf_write_cdci_common(s, st, mxf_mpegvideo_descriptor_key, 0);
}
static void mxf_write_generic_sound_common(AVFormatContext *s, AVStream *st,
const UID key, unsigned size)
@@ -1572,6 +1584,96 @@
return 1;
}
+static const struct {
+UID uid;
+int frame_size;
+int profile;
+uint8_t interlaced;
+} mxf_h264_codec_uls[] = {
+{{
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x20,0x01
}, 0, 110, 0 }, // AVC High 10 Intra
+{{
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x21,0x01
}, 232960, 0, 1 }, // AVC Intra 50 1080i60
+{{
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x21,0x02
}, 281088, 0, 1 }, // AVC Intra 50 1080i50
+{{
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x21,0x03
}, 232960, 0, 0 }, // AVC Intra 50 1080p30
+{{
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x21,0x04
}, 281088, 0, 0 }, // AVC Intra 50 1080p25
+{{
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x21,0x08
}, 116736, 0, 0 }, // AVC Intra 50 720p60
+{{
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x21,0x09
}, 140800, 0, 0 }, // AVC Intra 50 720p50
+{{
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x30,0x01
}, 0, 122, 0 }, // AVC High 422 Intra
+{{
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x01
}, 472576, 0, 1 }, // AVC Intra 100 1080i60
+{{
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x02
}, 568832, 0, 1 }, // AVC Intra 100 1080i50
+{{
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x03
}, 472576, 0, 0 }, // AVC Intra 100 1080p30
+{{
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x04
}, 568832, 0, 0 }, // AVC Intra 100 1080p25
+{{
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x08
}, 236544, 0, 0 }, // AVC Intra 100 720p60
+{{
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x09
}, 284672, 0, 0 }, // AVC Intra 100 720p50
+};
+
+static int mxf_parse_h264_frame(AVFormatContext *s, AVStream *st,
+AVPacket *pkt, MXFIndexEntry *e)
+{
+MXFContext *mxf = s->priv_data;
+MXFStreamContext *sc = st->priv_data;
+static const int mxf_h264_num_codec_uls =
sizeof(mxf_h264_codec_uls)/sizeof(mxf_h264_codec_uls[0]);
Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: AVC Intra support
On Tuesday 28 October 2014 03:36:05 pm Thomas Mundt wrote:
> -mxf_write_cdci_common(s, st, mxf_mpegvideo_descriptor_key, 8+5);
> -// bit rate
> -mxf_write_local_tag(pb, 4, 0x8000);
> -avio_wb32(pb, sc->video_bit_rate);
> -
> -// profile and level
> -mxf_write_local_tag(pb, 1, 0x8007);
> -if (!st->codec->profile)
> -profile_and_level |= 0x80; // escape bit
> -avio_w8(pb, profile_and_level);
It makes reviewing your patch much easier if you do not re-indent
these lines: Just leave them unchanged, consider sending a
followup to fix the indentation.
(Or leave it to the committer.)
> +}
> +else
> +mxf_write_cdci_common(s, st, mxf_mpegvideo_descriptor_key, 0);
While here, please make this:
} else {
mxf_write_cdci_common(=;
}
to follow the preferred coding style.
And please consider to commit your patch locally, create a
patchfile with "git format-patch HEAD^" and attach it to your
mail.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] xcbgrab: XCB-based screen capture
On Tue, 28 Oct 2014 10:05:29 +0100
Nicolas George wrote:
> Le sextidi 6 brumaire, an CCXXIII, compn a écrit :
> > from x11grab.c:
> >
> > AV_OPT_TYPE_INT, {.i64 = 1}, 0, 1, DEC }, { "follow_mouse", "move
> > the grabbing region when the mouse pointer reaches within specified
> > amount of pixels to the edge of region", OFFSET(follow_mouse),
from xcbgrab.c:
+{ "follow_mouse", "Move the grabbing region when the mouse
pointer reaches within specified amount of pixels to the edge of
region.",
> Or is it just related to your next point?
yes
>
> > is this file based on x11grab.c ? if so , copyrights need to be
> > modified.
>
> Regarding the code itself, my understanding reading Luca's
> messages is that it is a new implementation. Of course, the parts
> that are far from the back-end library and straightforward are bound
> to look similar.
the message of follow_mouse is a direct copy (with a punctuation fix).
my question is, if its a copy/paste of the option description, do we
have to put some original author attribution into the copyright list at
the top of xcbgrab.c ?
-compn
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: AVC Intra support
Okay. I will do so next patch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] xcbgrab: XCB-based screen capture
On Tue, 28 Oct 2014 12:48:43 +0100 Michael Niedermayer wrote: > On Tue, Oct 28, 2014 at 10:05:29AM +0100, Nicolas George wrote: > > Le sextidi 6 brumaire, an CCXXIII, compn a écrit : > > > so its name is changed in the makefile, but not the device name? > [...] > > Therefore, I think it is logical to have both devices called > > "x11grab", i.e. "grab from an X11 server". > > > > The same goes whenever there are several feature-equivalent > > implementations for the same thing: you do not have both > > httpopenssl:// and httpgnutls://, you just have https:// using one > > of the library internally. > > this makes it impossible to switch between them without recompiling > though > > for development and testing it may be usefull to enable both though > > one example are fate clients, which if these parts are mutually > exclusive potentially wont compile test both or if they can be > enabled at build time one wouldnt be able to select which to use at > runtime as their names equal > > we maybe should introduce in addition to the default https & x11grab > a x11grab_xcb and x11grab_x11 or something like that is it the goal of ffmpeg to have multiple implementations of different features? ffmpeg can be compiled with native rtmp or librtmp. can we compile both and switch between them? like -network native or -network librtmp ? same with codecs, for example xvid decoding vs native? demuxers, such as gpac, mp4box or mkvtoolsnix vs native? encoders are already ok by having different encoder names. i dont mind. mplayer has this , by using native network or ffmpeg:// code. or -demuxer lavf or codecs by changing codec names around. iirc vlc has similar options. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] xcbgrab: XCB-based screen capture
Le septidi 7 brumaire, an CCXXIII, compn a écrit : > the message of follow_mouse is a direct copy (with a punctuation fix). > > my question is, if its a copy/paste of the option description, do we > have to put some original author attribution into the copyright list at > the top of xcbgrab.c ? In other words: is this sentence enough to grant copyright? Only a judge can tell you that with any sort of definitiveness, and I must say I have no idea what the answer would be; you would probably get three different answers if you asked two different judges anyway. Barring that, and unless the original author complained (note that the original author for that particular feature submitted to libav anyway), I believe we can trust Luca's judgement. 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] [FFmpeg-cvslog] xcbgrab: XCB-based screen capture
Le septidi 7 brumaire, an CCXXIII, Michael Niedermayer a écrit : > this makes it impossible to switch between them without recompiling > though > > for development and testing it may be usefull to enable both though > > one example are fate clients, which if these parts are mutually > exclusive potentially wont compile test both or if they can be > enabled at build time one wouldnt be able to select which to use at > runtime as their names equal > > we maybe should introduce in addition to the default https & x11grab > a x11grab_xcb and x11grab_x11 or something like that That is true. On the other hand, this code has mostly been laying around without major changes and without being an annoyance, and it is pretty possible that the new code will just supersedes it and keep the good situation intact. I suggest we can decide what to do about alternate implementation if and when the need arises, be it because an user has troubles that are fixed by the Xlib implementation or because someone wants to develop or implement tests. (As for tests, considering they would need a dummy X11 server, I bet they are not coming anytime soon.) Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [Binathi/ffmpeg] d83ead: Forks new process to allow ffserver run in daemon ...
Branch: refs/heads/master Home: https://github.com/Binathi/ffmpeg Commit: d83ead999c0343b74d66b58d02c3ef381ac43b69 https://github.com/Binathi/ffmpeg/commit/d83ead999c0343b74d66b58d02c3ef381ac43b69 Author: Binathi Date: 2014-10-28 (Tue, 28 Oct 2014) Changed paths: M doc/ffserver.conf M ffserver.c Log Message: --- Forks new process to allow ffserver run in daemon mode ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [Binathi/ffmpeg] d83ead: Forks new process to allow ffserver run in daemon ...
Branch: refs/heads/master Home: https://github.com/Binathi/ffmpeg Commit: d83ead999c0343b74d66b58d02c3ef381ac43b69 https://github.com/Binathi/ffmpeg/commit/d83ead999c0343b74d66b58d02c3ef381ac43b69 Author: Binathi Date: 2014-10-28 (Tue, 28 Oct 2014) Changed paths: M doc/ffserver.conf M ffserver.c Log Message: --- Forks new process to allow ffserver run in daemon mode ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Binathi/ffmpeg] d83ead: Forks new process to allow ffserver run in daemon ...
Le septidi 7 brumaire, an CCXXIII, Binathi a écrit : > Branch: refs/heads/master > Home: https://github.com/Binathi/ffmpeg > Commit: d83ead999c0343b74d66b58d02c3ef381ac43b69 > > https://github.com/Binathi/ffmpeg/commit/d83ead999c0343b74d66b58d02c3ef381ac43b69 > Author: Binathi > Date: 2014-10-28 (Tue, 28 Oct 2014) > > Changed paths: > M doc/ffserver.conf > M ffserver.c > > Log Message: > --- > Forks new process to allow ffserver run in daemon mode I am sorry, but that it still not correct. You uploaded a snapshot of the source code to the tree, that makes it completely distinct from official FFmpeg repository. You need to make a clone of the official repository and work your patches in a branch started from the head. Then you must produce a patch and send it to the mailing list, using git format-patch or git send-email. I strongly suggest that just before actually sending the patch, you read it yourself carefully, and you compare it to patches sent to the mailing list that are quickly accepted. If your patch is very different from the ones on the mailing list, there is probably something you need to fix. In this particular instance, I see that your pull request has "3,894 additions, 4,389 deletions" on ffserver.c: this is way too much for such a small feature, or for any reasonable feature for that matter. It seems you lost all the code's indentation somewhere, and the thousands of changes are mostly that. You would probably be better of re-starting with a completely new clone of the official repository (I insist: clone; do not download any source code using your browser), and then use the -w option of diff to help you import manually your changes from the first working tree. 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] lavfi: add xbr filter
On date Tuesday 2014-10-28 13:45:06 +0530, arwa arif encoded:
> On Tue, Oct 28, 2014 at 1:25 AM, Clément Bœsch wrote:
>
> > On Mon, Oct 27, 2014 at 08:54:11PM +0100, Clément Bœsch wrote:
> > [...]
> > > Can you add a FATE test similar to this? See tests/fate/filter-video.mak.
> >
> > similar to hqx I meant
> >
> > --
> > Clément B.
> >
>
> Updated patch.
> I will try adding the FATE test by tonight.
>
>
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >
> From e5278383f143fd9c184710ddd4535d8b198fcff9 Mon Sep 17 00:00:00 2001
> From: Arwa Arif
> Date: Sat, 25 Oct 2014 22:04:51 +0530
> Subject: [PATCH] [PATCH]lavfi: add xbr filter
>
> ---
> doc/filters.texi |7 +
> libavfilter/Makefile |1 +
> libavfilter/allfilters.c |1 +
> libavfilter/vf_xbr.c | 318
> ++
> 4 files changed, 327 insertions(+)
> create mode 100644 libavfilter/vf_xbr.c
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index c70ddf3..5fa1d08 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -9159,6 +9159,13 @@ Only deinterlace frames marked as interlaced.
> Default value is @samp{all}.
> @end table
>
> +@section xbr
> +
> +A high-quality magnification filter which is designed for pixel art. It
> follows a set
Apply a high-quality magnification filter ...
(verbal form, for consistency).
> +of edge-detection rules
> @url{http://www.libretro.com/forums/viewtopic.php?f=6&t=134}.
> +This filter was originally created by Hyllian. The current implementation
> scales the
> +image by scale factor 2.
Drop "The current implementation ...".
How much effort would it take to implement the remaining scaling modes?
> +
> @anchor{yadif}
> @section yadif
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 6d868e7..2c56e38 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -198,6 +198,7 @@ OBJS-$(CONFIG_VIDSTABDETECT_FILTER) +=
> vidstabutils.o vf_vidstabdetect.
> OBJS-$(CONFIG_VIDSTABTRANSFORM_FILTER) += vidstabutils.o
> vf_vidstabtransform.o
> OBJS-$(CONFIG_VIGNETTE_FILTER) += vf_vignette.o
> OBJS-$(CONFIG_W3FDIF_FILTER) += vf_w3fdif.o
> +OBJS-$(CONFIG_XBR_FILTER)+= vf_xbr.o
> OBJS-$(CONFIG_YADIF_FILTER) += vf_yadif.o
> OBJS-$(CONFIG_ZMQ_FILTER)+= f_zmq.o
> OBJS-$(CONFIG_ZOOMPAN_FILTER)+= vf_zoompan.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index d88a9ad..2352d44 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -213,6 +213,7 @@ void avfilter_register_all(void)
> REGISTER_FILTER(VIDSTABTRANSFORM, vidstabtransform, vf);
> REGISTER_FILTER(VIGNETTE, vignette, vf);
> REGISTER_FILTER(W3FDIF, w3fdif, vf);
> +REGISTER_FILTER(XBR,xbr,vf);
> REGISTER_FILTER(YADIF, yadif, vf);
> REGISTER_FILTER(ZMQ,zmq,vf);
> REGISTER_FILTER(ZOOMPAN,zoompan,vf);
> diff --git a/libavfilter/vf_xbr.c b/libavfilter/vf_xbr.c
> new file mode 100644
> index 000..a000baf
> --- /dev/null
> +++ b/libavfilter/vf_xbr.c
> @@ -0,0 +1,318 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * Copyright (c) 2014 Arwa Arif
> + *
> + * 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
> + * XBR Filter is used for depixelization of image.
> + * This is based on Hyllian's 2xBR shader.
> + * 2xBR Filter v0.2.5
> + * @see : http://www.libretro.com/forums/viewtopic.php?f=6&t=134
> + * Future work : To implement x3 and x4 scale, and threading.
> + */
> +
> +#include "libavutil/opt.h"
> +#include "libavutil/avassert.h"
> +#include "libavutil/pixdesc.h"
> +#include "internal.h"
> +
> +typedef struct {
> +uint32_t rgbtoyuv[1<<24];
We should avoid this 64MiB. Also the table should be possibly static,
so you don't have to fill it per each xBR instance.
> +} xBRContext;
> +
> +/**
> +* Calculates the weight of difference of the pixels, by transforming these
> +* pixels into their Y'UV
Re: [FFmpeg-devel] [PATCH 1/5] mxfdec: Break out parts of mxf_read_header() into separate functions
On Tue, Oct 28, 2014 at 03:29:28PM +0100, tomas.har...@codemill.se wrote: > This is part of a series of patches that fix tickets 3278 and 4040 > (http://trac.ffmpeg.org/ticket/3278 > http://trac.ffmpeg.org/ticket/4040), plus some refactoring. > > I uploaded a file called deadlock3.mxf (and corresponding > deadlock3.txt) to incoming that demonstrates another issue similar > to Ticket3278 (see patch 2/5). > > /Tomas > mxfdec.c | 69 > ++- > 1 file changed, 47 insertions(+), 22 deletions(-) > 5333e33e87e3502b7932d70ad6f59de0eaf0fe0d > 0001-mxfdec-Break-out-parts-of-mxf_read_header-into-separ.patch > From 55117f8fd8d209830db8932a1c59f0b309e3ac44 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= > Date: Tue, 28 Oct 2014 13:33:04 +0100 > Subject: [PATCH 1/5] mxfdec: Break out parts of mxf_read_header() into > separate functions applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] mxfdec: Parse PreviousPartition in mxf_seek_to_previous_partition()
On Tue, Oct 28, 2014 at 03:35:42PM +0100, tomas.har...@codemill.se wrote: > On 2014-10-28 15:31, tomas.har...@codemill.se wrote: > >This fixes the actual issue (Ticket 3278). See also deadlock3.mxf > >on FTP. > > > >/Tomas > > Oops, wrong subject - I should probably set up git-send-email.. > Reattached patch just to be sure. > > /Tomas > mxfdec.c | 35 ++- > 1 file changed, 34 insertions(+), 1 deletion(-) > e9f0cab706d12531462b21577cdacca6261f1d1c > 0002-mxfdec-Parse-PreviousPartition-in-mxf_seek_to_previo.patch > From 783aaa31271266587fad8f60a588ed755744a765 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= > Date: Tue, 28 Oct 2014 13:38:18 +0100 > Subject: [PATCH 2/5] mxfdec: Parse PreviousPartition in > mxf_seek_to_previous_partition() > > Without this patch the demuxer can get stuck in a loop if PreviousPartition > points somewhere where there's no PartitionPack, or if klv_read_packet() syncs > back up to the current partition. > > This should fix Ticket3278 properly and unbreak Ticket4040. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] mxfdec: Merge last_partition and footer_partition
On Tue, Oct 28, 2014 at 03:33:23PM +0100, tomas.har...@codemill.se wrote: > mxfdec.c | 24 ++-- > 1 file changed, 10 insertions(+), 14 deletions(-) > b8324b93726e1e92289ab8ffe2a3ffebb973c53b > 0004-mxfdec-Merge-last_partition-and-footer_partition.patch > From 86ce75449ef2febb584d7f337a4035ef2cee2b1a Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= > Date: Tue, 28 Oct 2014 14:27:06 +0100 > Subject: [PATCH 4/5] mxfdec: Merge last_partition and footer_partition > > FooterPartition offset specified in RIP takes precedence over any value > written > in PartitionPacks. This fixes the same issue f06f6da tries to fix without > introducing an extra variable. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] mxfdec: Tighten RIP length bounds in mxf_read_random_index_pack()
On Tue, Oct 28, 2014 at 03:33:50PM +0100, tomas.har...@codemill.se wrote: > From d1827479c17186db7bda472e92b272bbdf4ddcfb Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= > Date: Tue, 28 Oct 2014 14:36:27 +0100 > Subject: [PATCH 5/5] mxfdec: Tighten RIP length bounds in > mxf_read_random_index_pack() applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] Revert "avformat/mxfdec: detect loops during header parsing
On Tue, Oct 28, 2014 at 03:32:42PM +0100, tomas.har...@codemill.se wrote: > From 662adc4db39b1925c90fc78fb83d58c0e3e6dfd4 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= > Date: Tue, 28 Oct 2014 13:33:47 +0100 > Subject: [PATCH 3/5] Revert "avformat/mxfdec: detect loops during header > parsing" > > This reverts commit 1c010fd035c1a14dc73827b84f21f593e969a5d6. > --- > libavformat/mxfdec.c | 9 + > 1 file changed, 1 insertion(+), 8 deletions(-) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
On Tue, Oct 28, 2014 at 06:30:34PM +0100, Stefano Sabatini wrote:
[...]
> How much effort would it take to implement the remaining scaling modes?
>
According to
https://ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164574.html
"I think 4x can be done fast enough, but 3x will take time."
[...]
> > +typedef struct {
> > +uint32_t rgbtoyuv[1<<24];
>
> We should avoid this 64MiB. Also the table should be possibly static,
> so you don't have to fill it per each xBR instance.
>
So, I requested to do it exactly the same as HQx because this part is
common according to the specifications. This should be kept the same
vf_hqx, and then factorized.
Now about removing this allocation, I did benchmark this LUT vs
computation (see attached patch for comp. version). And the problem is
that it's slightly slower, probably due to the /1000.
I wasn't able to make it bitexact with the current code using bithacks,
and while this sounds like a tolerable inaccuracy, it actually isn't and
has an impact of the output. For example, doing this (on top of attached
patch):
diff --git a/libavfilter/vf_hqx.c b/libavfilter/vf_hqx.c
index 41a77cf..f4d8006 100644
--- a/libavfilter/vf_hqx.c
+++ b/libavfilter/vf_hqx.c
@@ -29,6 +29,7 @@
#include "libavutil/opt.h"
#include "libavutil/avassert.h"
+#include "libavutil/colorspace.h"
#include "libavutil/pixdesc.h"
#include "internal.h"
@@ -58,9 +59,9 @@ static av_always_inline uint32_t rgb2yuv(uint32_t c)
const int r = c >> 16 & 0xff;
const int g = c >> 8 & 0xff;
const int b = c & 0xff;
-const uint32_t y = (uint32_t)(( 299*r + 587*g + 114*b)/1000);
-const uint32_t u = (uint32_t)((-169*r - 331*g + 500*b)/1000) + 128;
-const uint32_t v = (uint32_t)(( 500*r - 419*g - 81*b)/1000) + 128;
+const uint32_t y = RGB_TO_Y(r, g, b);
+const uint32_t u = RGB_TO_U(r, g, b, 0);
+const uint32_t v = RGB_TO_V(r, g, b, 0);
return y<<16 | u<<8 | v;
}
...leads to this: https://lut.im/S9sJXgGU/ttB0B1j1 vs
https://lut.im/9iRC6VMx/ef3PKqYd (look at the sorcerers typically, or
bomberman)
Even with a higher bit depth and checking the rounding, I had differences.
So for now, I prefer to keep the LUT unless someone has a better idea. And
anyway, this is orthogonal to this patch.
[...]
--
Clément B.
From 411b4e217f893a4ca1077d9814af02cf5349054a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20B=C5=93sch?=
Date: Mon, 27 Oct 2014 23:49:47 +0100
Subject: [PATCH] avfilter/hqx/WIP: remove LUT
---
libavfilter/vf_hqx.c | 88
1 file changed, 34 insertions(+), 54 deletions(-)
diff --git a/libavfilter/vf_hqx.c b/libavfilter/vf_hqx.c
index 4783381..41a77cf 100644
--- a/libavfilter/vf_hqx.c
+++ b/libavfilter/vf_hqx.c
@@ -38,12 +38,10 @@ typedef struct {
const AVClass *class;
int n;
hqxfunc_t func;
-uint32_t rgbtoyuv[1<<24];
} HQXContext;
typedef struct ThreadData {
AVFrame *in, *out;
-const uint32_t *rgbtoyuv;
} ThreadData;
#define OFFSET(x) offsetof(HQXContext, x)
@@ -55,9 +53,15 @@ static const AVOption hqx_options[] = {
AVFILTER_DEFINE_CLASS(hqx);
-static av_always_inline uint32_t rgb2yuv(const uint32_t *r2y, uint32_t c)
+static av_always_inline uint32_t rgb2yuv(uint32_t c)
{
-return r2y[c & 0xff];
+const int r = c >> 16 & 0xff;
+const int g = c >> 8 & 0xff;
+const int b = c & 0xff;
+const uint32_t y = (uint32_t)(( 299*r + 587*g + 114*b)/1000);
+const uint32_t u = (uint32_t)((-169*r - 331*g + 500*b)/1000) + 128;
+const uint32_t v = (uint32_t)(( 500*r - 419*g - 81*b)/1000) + 128;
+return y<<16 | u<<8 | v;
}
static av_always_inline int yuv_diff(uint32_t yuv1, uint32_t yuv2)
@@ -97,7 +101,7 @@ static av_always_inline uint32_t interp_3px(uint32_t c1, int w1, uint32_t c2, in
#define SHF(x, rot, n) (((x) >> ((rot) ? 7-DROP4(n) : DROP4(n)) & 1) << DROP4(p##n))
/* used to check if there is YUV difference between 2 pixels */
-#define WDIFF(c1, c2) yuv_diff(rgb2yuv(r2y, c1), rgb2yuv(r2y, c2))
+#define WDIFF(c1, c2) yuv_diff(rgb2yuv(c1), rgb2yuv(c2))
/* bootstrap template for every interpolation code. It defines the shuffled
* masks and surrounding pixels. The rot flag is used to indicate if it's a
@@ -114,8 +118,7 @@ static av_always_inline uint32_t interp_3px(uint32_t c1, int w1, uint32_t c2, in
/* Assuming p0..p8 is mapped to pixels 0..8, this function interpolates the
* top-left pixel in the total of the 2x2 pixels to interpolates. The function
* is also used for the 3 other pixels */
-static av_always_inline uint32_t hq2x_interp_1x1(const uint32_t *r2y, int k,
- const uint32_t *w,
+static av_always_inline uint32_t hq2x_interp_1x1(int k, const uint32_t *w,
int p0, int p1, int p2,
int p3, int p4, int p5,
Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
On Tue, Oct 28, 2014 at 07:16:45PM +0100, Clément Bœsch wrote:
> On Tue, Oct 28, 2014 at 06:30:34PM +0100, Stefano Sabatini wrote:
> [...]
> > How much effort would it take to implement the remaining scaling modes?
> >
>
> According to
> https://ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164574.html
>
> "I think 4x can be done fast enough, but 3x will take time."
>
> [...]
> > > +typedef struct {
> > > +uint32_t rgbtoyuv[1<<24];
> >
> > We should avoid this 64MiB. Also the table should be possibly static,
> > so you don't have to fill it per each xBR instance.
> >
>
> So, I requested to do it exactly the same as HQx because this part is
> common according to the specifications. This should be kept the same
> vf_hqx, and then factorized.
>
> Now about removing this allocation, I did benchmark this LUT vs
> computation (see attached patch for comp. version). And the problem is
> that it's slightly slower, probably due to the /1000.
why do you divide at all ?
cant you do the computations with full precission ?
also instead of doing 2 rgb2yuv and then taking their difference you
can do the difference in rgb space and convert the rgb difference to
a yuv difference
its just aM - bM = (a-b)M
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
Sent from my BlackBerry 10 smartphone on the Rogers network.
Original Message
From: Michael Niedermayer
Sent: Tuesday, October 28, 2014 17:51
To: FFmpeg development discussions and patches
Reply To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
On Tue, Oct 28, 2014 at 07:16:45PM +0100, Clément Bœsch wrote:
> On Tue, Oct 28, 2014 at 06:30:34PM +0100, Stefano Sabatini wrote:
> [...]
> > How much effort would it take to implement the remaining scaling modes?
> >
>
> According to
> https://ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164574.html
>
> "I think 4x can be done fast enough, but 3x will take time."
>
> [...]
> > > +typedef struct {
> > > + uint32_t rgbtoyuv[1<<24];
> >
> > We should avoid this 64MiB. Also the table should be possibly static,
> > so you don't have to fill it per each xBR instance.
> >
>
> So, I requested to do it exactly the same as HQx because this part is
> common according to the specifications. This should be kept the same
> vf_hqx, and then factorized.
>
> Now about removing this allocation, I did benchmark this LUT vs
> computation (see attached patch for comp. version). And the problem is
> that it's slightly slower, probably due to the /1000.
why do you divide at all ?
cant you do the computations with full precission ?
also instead of doing 2 rgb2yuv and then taking their difference you
can do the difference in rgb space and convert the rgb difference to
a yuv difference
its just aM - bM = (a-b)M
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
Sent from my BlackBerry 10 smartphone on the Rogers network.
Original Message
From: Michael Niedermayer
Sent: Tuesday, October 28, 2014 17:51
To: FFmpeg development discussions and patches
Reply To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
On Tue, Oct 28, 2014 at 07:16:45PM +0100, Clément Bœsch wrote:
> On Tue, Oct 28, 2014 at 06:30:34PM +0100, Stefano Sabatini wrote:
> [...]
> > How much effort would it take to implement the remaining scaling modes?
> >
>
> According to
> https://ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164574.html
>
> "I think 4x can be done fast enough, but 3x will take time."
>
> [...]
> > > +typedef struct {
> > > + uint32_t rgbtoyuv[1<<24];
> >
> > We should avoid this 64MiB. Also the table should be possibly static,
> > so you don't have to fill it per each xBR instance.
> >
>
> So, I requested to do it exactly the same as HQx because this part is
> common according to the specifications. This should be kept the same
> vf_hqx, and then factorized.
>
> Now about removing this allocation, I did benchmark this LUT vs
> computation (see attached patch for comp. version). And the problem is
> that it's slightly slower, probably due to the /1000.
why do you divide at all ?
cant you do the computations with full precission ?
also instead of doing 2 rgb2yuv and then taking their difference you
can do the difference in rgb space and convert the rgb difference to
a yuv difference
its just aM - bM = (a-b)M
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
Sent from my BlackBerry 10 smartphone on the Rogers network.
Original Message
From: Michael Niedermayer
Sent: Tuesday, October 28, 2014 17:51
To: FFmpeg development discussions and patches
Reply To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
On Tue, Oct 28, 2014 at 07:16:45PM +0100, Clément Bœsch wrote:
> On Tue, Oct 28, 2014 at 06:30:34PM +0100, Stefano Sabatini wrote:
> [...]
> > How much effort would it take to implement the remaining scaling modes?
> >
>
> According to
> https://ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164574.html
>
> "I think 4x can be done fast enough, but 3x will take time."
>
> [...]
> > > +typedef struct {
> > > + uint32_t rgbtoyuv[1<<24];
> >
> > We should avoid this 64MiB. Also the table should be possibly static,
> > so you don't have to fill it per each xBR instance.
> >
>
> So, I requested to do it exactly the same as HQx because this part is
> common according to the specifications. This should be kept the same
> vf_hqx, and then factorized.
>
> Now about removing this allocation, I did benchmark this LUT vs
> computation (see attached patch for comp. version). And the problem is
> that it's slightly slower, probably due to the /1000.
why do you divide at all ?
cant you do the computations with full precission ?
also instead of doing 2 rgb2yuv and then taking their difference you
can do the difference in rgb space and convert the rgb difference to
a yuv difference
its just aM - bM = (a-b)M
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
Ыы
Sent from my BlackBerry 10 smartphone on the Rogers network.
Original Message
From: Michael Niedermayer
Sent: Tuesday, October 28, 2014 17:51
To: FFmpeg development discussions and patches
Reply To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
On Tue, Oct 28, 2014 at 07:16:45PM +0100, Clément Bœsch wrote:
> On Tue, Oct 28, 2014 at 06:30:34PM +0100, Stefano Sabatini wrote:
> [...]
> > How much effort would it take to implement the remaining scaling modes?
> >
>
> According to
> https://ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164574.html
>
> "I think 4x can be done fast enough, but 3x will take time."
>
> [...]
> > > +typedef struct {
> > > + uint32_t rgbtoyuv[1<<24];
> >
> > We should avoid this 64MiB. Also the table should be possibly static,
> > so you don't have to fill it per each xBR instance.
> >
>
> So, I requested to do it exactly the same as HQx because this part is
> common according to the specifications. This should be kept the same
> vf_hqx, and then factorized.
>
> Now about removing this allocation, I did benchmark this LUT vs
> computation (see attached patch for comp. version). And the problem is
> that it's slightly slower, probably due to the /1000.
why do you divide at all ?
cant you do the computations with full precission ?
also instead of doing 2 rgb2yuv and then taking their difference you
can do the difference in rgb space and convert the rgb difference to
a yuv difference
its just aM - bM = (a-b)M
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add xbr filter
On Tue, Oct 28, 2014 at 10:51:27PM +0100, Michael Niedermayer wrote:
> On Tue, Oct 28, 2014 at 07:16:45PM +0100, Clément Bœsch wrote:
> > On Tue, Oct 28, 2014 at 06:30:34PM +0100, Stefano Sabatini wrote:
> > [...]
> > > How much effort would it take to implement the remaining scaling modes?
> > >
> >
> > According to
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164574.html
> >
> > "I think 4x can be done fast enough, but 3x will take time."
> >
> > [...]
> > > > +typedef struct {
> > > > +uint32_t rgbtoyuv[1<<24];
> > >
> > > We should avoid this 64MiB. Also the table should be possibly static,
> > > so you don't have to fill it per each xBR instance.
> > >
> >
> > So, I requested to do it exactly the same as HQx because this part is
> > common according to the specifications. This should be kept the same
> > vf_hqx, and then factorized.
> >
>
> > Now about removing this allocation, I did benchmark this LUT vs
> > computation (see attached patch for comp. version). And the problem is
> > that it's slightly slower, probably due to the /1000.
>
> why do you divide at all ?
> cant you do the computations with full precission ?
I wasn't able to... but I was probably doing it wrong.
And anyway, so far I observed this:
lut: 127fps
nolut+div: 119fps
nolut+nodiv: 123fps
So even with "fast" computation, it's still slower than the LUT. It probably
doesn't matter that much in practice, and dropping that huge table might be
worth the performance impact (feel free to discuss).
Note that looking at the original code (which was working on rgb565 only),
it was bitexact. The rgb 24-bit was added in the "modern" hqx with float
point. So we can probably tolerate the inaccuracy. Still, if you find a
way of keeping full accuracy with the modern implementation...
Typically, I tried stuff like this:
const uint32_t y = (uint32_t)((1225*r + 2404*g + 467*b + (1<<11)) >> 12);
const uint32_t u = (uint32_t)((-692*r - 1356*g + 2048*b + (1<<11)) >> 12) +
128;
const uint32_t v = (uint32_t)((2048*r - 1716*g - 332*b + (1<<11)) >> 12) +
128;
...but I'm probably doing it very wrong somewhere (sign issue maybe?), haven't
looked deeper. I went up to 15 bits, still didn't match, so I was probably
doing something stupid.
> also instead of doing 2 rgb2yuv and then taking their difference you
> can do the difference in rgb space and convert the rgb difference to
> a yuv difference
> its just aM - bM = (a-b)M
Ah, sounds like a good idea, I guess I'll try that.
[...]
--
Clément B.
pgpCf8hLrzRCH.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: AVC Intra support
Carl Eugen, I changed the indentations and attached a unified diff. Since I´m on windows I used turtoise git. I hope that´s okay. Regards, Thomas avci_mxf.diff Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] movenc: Always write the trun data_offset
The MOV_TRUN_DATA_OFFSET flag was always getting set, so data_offset is being expected and read. The offset was computed correctly anyway during fragment-flush. Alternatively, I could have selectively set the flag only when base-data-offset is defined, but certain players (Chrome) seem to fail when no data-offset is provided in the trun. --- libavformat/movenc.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/libavformat/movenc.c b/libavformat/movenc.c index a43752a..923cf92 100644 --- a/libavformat/movenc.c +++ b/libavformat/movenc.c @@ -3187,13 +3187,8 @@ static int mov_write_trun_tag(AVIOContext *pb, MOVMuxContext *mov, avio_wb24(pb, flags); avio_wb32(pb, track->entry); /* sample count */ -if (mov->flags & FF_MOV_FLAG_OMIT_TFHD_OFFSET && -!(mov->flags & FF_MOV_FLAG_SEPARATE_MOOF) && -track->track_id != 1) -avio_wb32(pb, 0); /* Later tracks follow immediately after the previous one */ -else -avio_wb32(pb, moof_size + 8 + track->data_offset + - track->cluster[0].pos); /* data offset */ +avio_wb32(pb, moof_size + 8 + track->data_offset + + track->cluster[0].pos); /* data offset */ if (flags & MOV_TRUN_FIRST_SAMPLE_FLAGS) avio_wb32(pb, get_sample_flags(track, &track->cluster[0])); -- 1.9.3 (Apple Git-50) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/atomic: add support for the new memory model aware gcc built-ins
On Mon, Oct 27, 2014 at 11:25:01PM -0300, James Almer wrote: > __sync built-ins are considered legacy and will be deprecated. > These new memory model aware built-ins have been available since GCC 4.7.0 > > Use them by default when available except for __atomic_compare_exchange_n(), > which is slower, and is instead implemented as a fallback for when and if gcc > removes the legacy __sync built-ins. > > Signed-off-by: James Almer > --- > configure | 4 +++- > libavutil/atomic_gcc.h | 17 + > 2 files changed, 20 insertions(+), 1 deletion(-) LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Problem uploading results to f...@fate.ffmpeg.org
Hello, I have ran the FATE test suite on my Fedora host using this: ( make V=2 -j2 SAMPLES=/var/fate/samples THREADS=2 fate) and I can't seem to authenticate and upload the results. I had previously sent a key to for authentication. But I had some problems uploading my test results. I have generated a new key for my system and sent to the admin for authentication. I"ll like to have some more assistance in submitting my results successfully since I am having problems using the wiki. Thanks, Amalia ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Problem uploading results to f...@fate.ffmpeg.org
Hi, On Tuesday, October 28, 2014, Ngassa Finjap wrote: > Hello, > > I have ran the FATE test suite on my Fedora host using this: ( make V=2 -j2 > SAMPLES=/var/fate/samples THREADS=2 fate) and I can't seem to authenticate > and upload the results. I had previously sent a key to for authentication. > To submit the results to the server, you have to use the tests/fate.sh script and a config file. See https://www.ffmpeg.org/fate.html for more info. > I"ll like to have some more assistance in submitting my results successfully since I am having problems using the wiki. What wiki article are you following? Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] FFMPEG : Redirecting Matroska muxed data to socket
Hi all, I am using FFMPEG library to mux H.264 and AAC frames to Matroska (.mkv) file. I can do that both using command line and C program. Now, instead of writing the muxed matroska data into file I want to write these muxed data directly on to socket or pipe. My actual goal is to write a C program that send muxed data to socket and server will receive this muxed data. I tried using protocol tcp. They are working with the matroska format. So, My C program is able to send muxed data successfully over socket and server is able to receive this muxed data. But when I apply ffprobe command over the received file, I am getting duration and bitrate field N/A. and when I tried to play this file with vlc i am unable to seek the file and getting garbage duration. Below the output of the ffprobe. ffprobe version N-65784-g50a35f0 Copyright (c) 2007-2014 the FFmpeg developers built on Aug 25 2014 12:31:36 with gcc 4.7 (Ubuntu/Linaro 4.7.3-1ubuntu1) configuration: libavutil 54. 5.100 / 54. 5.100 libavcodec 56. 0.101 / 56. 0.101 libavformat56. 1.100 / 56. 1.100 libavdevice56. 0.100 / 56. 0.100 libavfilter 5. 0.101 / 5. 0.101 libswscale 3. 0.100 / 3. 0.100 libswresample 1. 1.100 / 1. 1.100 Input #0, matroska,webm, from 'Array.mkv': Metadata: ENCODER : Lavf54.29.104 *Duration: N/A*, start: 1412858260.281000, *bitrate: N/A* Stream #0:0: Video: mjpeg, yuvj422p(pc, bt470bg), 2000x1496 [SAR 1:1 DAR 250:187], 27 fps, 27 tbr, 1k tbn, 1k tbc (default) Stream #0:1: Video: mjpeg, yuvj422p(pc, bt470bg), 2000x1496 [SAR 1:1 DAR 250:187], 27 fps, 27 tbr, 1k tbn, 1k tbc (default) Stream #0:2: Video: mjpeg, yuvj422p(pc, bt470bg), 2000x1496 [SAR 1:1 DAR 250:187], 27 fps, 27 tbr, 1k tbn, 1k tbc (default) Stream #0:3: Video: mjpeg, yuvj422p(pc, bt470bg), 2000x1496 [SAR 1:1 DAR 250:187], 27 fps, 27 tbr, 1k tbn, 1k tbc (default) As You can see Duration and Bitrate field shows N/A. However I am getting correct startTime. Any help or advice? Thank you in advance. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/libutvideodec: Support YUV422P10
Michael Niedermayer in gmane.comp.video.ffmpeg.devel (Sat, 25 Oct 2014 00:14:14 +0200): >patch applied FFmpeg does not (cross)compile anymore on Ubuntu (GCC 4.9.1) after this patch: libavcodec/libutvideodec.cpp: In function 'int utvideo_decode_init(AVCodecContext*)': libavcodec/libutvideodec.cpp:97:19: error: 'UTVF_v210' was not declared in this scope if (format == UTVF_v210) ^ libavcodec/libutvideodec.cpp: In function 'int utvideo_decode_frame(AVCodecContext*, void*, int*, AVPacket*)': libavcodec/libutvideodec.cpp:146:10: warning: 'AVFrame::reference' is deprecated (declared at ./libavutil/frame.h:273) [-Wdeprecated-declarations] pic->reference = 0; ^ libavcodec/libutvideodec.cpp:146:10: warning: 'AVFrame::reference' is deprecated (declared at ./libavutil/frame.h:273) [-Wdeprecated-declarations] make: *** [libavcodec/libutvideodec.o] Error 1 Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
