Re: [FFmpeg-devel] [PATCH 3/6] aacenc: Move local encoder specific tables to a separate file
On Wed, Jul 29, 2015 at 1:44 AM, Rostislav Pehlivanov wrote: > This commit moves any tables specific to the encoder from aacenc > and aaccoder to a separate file called 'aacenctab.c/.h'. > This was done as a clean up attempt as the encoder was filled with > tables pasted in between functions which made it confusing to follow > and track where each table and definition had been used. > This commit solves this by simply exporting the smaller tables out to > the aacenctab.h while the larger ones are compiled using aacenctab.c > and are referenced from the header file. > --- Applied. Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] fate reference for samidec
On Thu, Aug 06, 2015 at 11:50:56PM -0700, Yayoi Ukai wrote: > The (attached) file is a sample for this reference. uploaded to fate suite [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec: use looking up crop table method when do clip
based on last h264qpel optimization patch i have pushed
do i need separate this patch to double? cause one file to change loongson arch
use looking up crop table method may boost up decode on loongson, and with this
patch x86 pass fate too
but i have not tested on other arch
test on loongson-3b
time ./ffmepg -i 1280x720.mp4 -f rawvideo -an -vframes 4096 -y /dev/null
no patch:
real 0m58.2s
user 4m59.1s
sys 0m5.8s
with patch:
real 0m53.9s
user 4m33.2s
sys 0m6.2s
---
From 68e88b17d113875d829a9936284d3551fd499139 Mon Sep 17 00:00:00 2001
From: ZhouXiaoyong
Date: Fri, 7 Aug 2015 16:33:10 +0800
Subject: [PATCH] avcodec: use looking up crop table method when do clip
Signed-off-by: ZhouXiaoyong
---
libavcodec/bit_depth_template.c | 4 ++--
libavcodec/mips/h264qpel_mmi.c | 4
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/bit_depth_template.c b/libavcodec/bit_depth_template.c
index 8018489..759cd30 100644
--- a/libavcodec/bit_depth_template.c
+++ b/libavcodec/bit_depth_template.c
@@ -72,7 +72,7 @@
# define pixel4 uint32_t
# define dctcoef int16_t
-# define INIT_CLIP
+# define INIT_CLIP const uint8_t *cm = ff_crop_tab + MAX_NEG_CROP;
# define no_rnd_avg_pixel4 no_rnd_avg32
# definernd_avg_pixel4rnd_avg32
# define AV_RN2P AV_RN16
@@ -84,7 +84,7 @@
# define PIXEL_SPLAT_X4(x) ((x)*0x01010101U)
# define av_clip_pixel(a) av_clip_uint8(a)
-# define CLIP(a) av_clip_uint8(a)
+# define CLIP(a) cm[a]
#endif
#define FUNC3(a, b, c) a ## _ ## b ## c
diff --git a/libavcodec/mips/h264qpel_mmi.c b/libavcodec/mips/h264qpel_mmi.c
index e04a2d5..ebb21c7 100644
--- a/libavcodec/mips/h264qpel_mmi.c
+++ b/libavcodec/mips/h264qpel_mmi.c
@@ -1308,6 +1308,7 @@ static void avg_h264_qpel16_v_lowpass_mmi(uint8_t *dst,
const uint8_t *src,
static void put_h264_qpel4_hv_lowpass_mmi(uint8_t *dst, const uint8_t *src,
int dstStride, int srcStride)
{
+INIT_CLIP
int i;
int16_t _tmp[36];
int16_t *tmp = _tmp;
@@ -1376,6 +1377,7 @@ static void put_h264_qpel4_hv_lowpass_mmi(uint8_t *dst,
const uint8_t *src,
static void put_h264_qpel8_hv_lowpass_mmi(uint8_t *dst, const uint8_t *src,
int dstStride, int srcStride)
{
+INIT_CLIP
int16_t _tmp[104];
int16_t *tmp = _tmp;
int i;
@@ -1479,6 +1481,7 @@ static void put_h264_qpel16_hv_lowpass_mmi(uint8_t *dst,
const uint8_t *src,
static void avg_h264_qpel4_hv_lowpass_mmi(uint8_t *dst, const uint8_t *src,
int dstStride, int srcStride)
{
+INIT_CLIP
int i;
int16_t _tmp[36];
int16_t *tmp = _tmp;
@@ -1549,6 +1552,7 @@ static void avg_h264_qpel4_hv_lowpass_mmi(uint8_t *dst,
const uint8_t *src,
static void avg_h264_qpel8_hv_lowpass_mmi(uint8_t *dst, const uint8_t *src,
int dstStride, int srcStride)
{
+INIT_CLIP
int16_t _tmp[104];
int16_t *tmp = _tmp;
int i;
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Problem Still Exists on avcodec/vdpau_hevc: Remove experimental flag
Hello, I wanted to inform interleaving problem still exisits even with Nvidia 355.06 driver. More info here: https://github.com/FFmpeg/FFmpeg/commit/aa10f0aab0e2729e0a5edbd7b6838658d6 3421e1 Kind Regards, Ali ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swscale: Implement alphablendaway for planar 4:4:4 formats
On Thu, Aug 06, 2015 at 10:24:52PM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Thu, Aug 6, 2015 at 4:27 PM, Michael Niedermayer
> wrote:
>
> > From: Michael Niedermayer
> >
> > Fixes Ticket4746
> >
> > TODO: implement packed formats and subsampled formats
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > doc/scaler.texi | 13 ++
> > libswscale/Makefile |3 +-
> > libswscale/alphablend.c | 55 +++
> > libswscale/options.c |3 ++
> > libswscale/swscale_internal.h | 12 +
> > libswscale/utils.c| 97
> > +
> > 6 files changed, 182 insertions(+), 1 deletion(-)
> > create mode 100644 libswscale/alphablend.c
> >
> > diff --git a/doc/scaler.texi b/doc/scaler.texi
> > index 23d6393..4c55334 100644
> > --- a/doc/scaler.texi
> > +++ b/doc/scaler.texi
> > @@ -122,6 +122,19 @@ a_dither).
> >
> > @end table
> >
> > +@item alphablend
> > +Set the alpha blending to use when the input has alpha but the output
> > does not.
> > +Default value is @samp{black}.
> > +
> > +@table @samp
> > +@item black
> > +Blend onto black
> > +
> > +@item none
> > +No blending
> > +
> > +@end table
> > +
> > @end table
>
>
> I must admit I'm not a fan of having just two values for something like
> this. It seems to me you want 2 options, "blendmode", being "none" or
> "background" (or a float/alpha between 1.0/0.0), and the actual background
> color (black, white, blue, r=a,g=b,c=d). "black" vs. "none" seems like a
> future compat nightmare. Is it that hard to implement a proper rgb/yuv
> value solution?
The color value convertion support is in drawutils which is in
libavfilter. also drawutils lacks support for >8bit formats
so to get arbitrary color support with a clean non duplicated
implementation it would require moving drawutils
or the color related code from it to libavutil and extending it to
support all pixel formats. Unless iam missing something
Also i wanted to implement support for a checkerboard background
(which some applications use as default and it shows what
is transparent much better than black would)
So i would suggest that we implement ATM a "none" + "solidcolor" or
"background" or what name is preferred
and ill add a black/white checkerboard mode later and once drawutils
exist in libavutil we can then easily add a "blendcolor" AVOption
to specify the exact color
If noone objects then ill work on that (except drawutils moving and
extending)
[...]
--
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
[FFmpeg-devel] [PATCH v7] Add support for Audible AA files
From 0568a9385aa024ff015adab1c8f085de73edc644 Mon Sep 17 00:00:00 2001
From: Vesselin Bontchev
Date: Sun, 19 Jul 2015 23:16:36 +0200
Subject: [PATCH] Add support for Audible AA files
https://en.wikipedia.org/wiki/Audible.com#Quality
---
doc/demuxers.texi| 6 +
doc/general.texi | 2 +
libavformat/Makefile | 1 +
libavformat/aadec.c | 305 +++
libavformat/allformats.c | 1 +
5 files changed, 315 insertions(+)
create mode 100644 libavformat/aadec.c
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index e45e1af..c86e8a4 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -18,6 +18,12 @@ enabled demuxers.
The description of some of the currently available demuxers follows.
+@section aa
+
+Audible Format 2, 3, and 4 demuxer.
+
+This demuxer is used to demux Audible Format 2, 3, and 4 (.aa) files.
+
@section applehttp
Apple HTTP Live Streaming demuxer.
diff --git a/doc/general.texi b/doc/general.texi
index a260e79..2b782e0 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -228,6 +228,8 @@ library:
@item 8088flex TMV @tab @tab X
@item AAX @tab @tab X
@tab Audible Enhanced Audio format, used in audiobooks.
+@item AA@tab @tab X
+@tab Audible Format 2, 3, and 4, used in audiobooks.
@item ACT Voice @tab @tab X
@tab contains G.729 audio
@item Adobe Filmstrip @tab X @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index cc73fd8..466da51 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -59,6 +59,7 @@ OBJS-$(CONFIG_SHARED)+= log2_tab.o golomb_tab.o
# muxers/demuxers
OBJS-$(CONFIG_A64_MUXER) += a64.o rawenc.o
+OBJS-$(CONFIG_AA_DEMUXER)+= aadec.o
OBJS-$(CONFIG_AAC_DEMUXER) += aacdec.o apetag.o img2.o rawdec.o
OBJS-$(CONFIG_AC3_DEMUXER) += ac3dec.o rawdec.o
OBJS-$(CONFIG_AC3_MUXER) += rawenc.o
diff --git a/libavformat/aadec.c b/libavformat/aadec.c
new file mode 100644
index 000..e336283
--- /dev/null
+++ b/libavformat/aadec.c
@@ -0,0 +1,305 @@
+/*
+ * Audible AA demuxer
+ * Copyright (c) 2015 Vesselin Bontchev
+ *
+ * Header parsing is borrowed from https://github.com/jteeuwen/audible project.
+ * Copyright (c) 2001-2014, Jim Teeuwen
+ *
+ * Redistribution and use in source and binary forms, with or without modification,
+ * are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright notice, this
+ *list of conditions and the following disclaimer.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR
+ * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "avformat.h"
+#include "internal.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/tea.h"
+#include "libavutil/opt.h"
+
+#define AA_MAGIC 1469084982 /* this identifies an audible .aa file */
+#define MAX_CODEC_SECOND_SIZE 3982
+#define MAX_TOC_ENTRIES 16
+#define MAX_DICTIONARY_ENTRIES 128
+#define TEA_BLOCK_SIZE 8
+
+typedef struct AADemuxContext {
+AVClass *class;
+uint8_t *aa_fixed_key;
+int aa_fixed_key_len;
+int32_t codec_second_size;
+struct AVTEA *tea_ctx;
+uint8_t file_key[16];
+int64_t current_chapter_size;
+int64_t current_codec_second_size;
+int chapter_idx;
+} AADemuxContext;
+
+static int32_t get_second_size(char *codec_name)
+{
+int32_t result = -1;
+
+if (!strcmp(codec_name, "mp332")) {
+result = 3982;
+} else if (!strcmp(codec_name, "acelp16")) {
+result = 2000;
+} else if (!strcmp(codec_name, "acelp85")) {
+result = 1045;
+}
+
+return result;
+}
+
+static int aa_read_header(AVFormatContext *s)
+{
+int i, j, idx, largest_idx = -1;
+uint32_t nkey, nval, toc_size, npairs, header_seed, start;
+char key[128], val[128], codec_name[64] = {0};
+uint8_t output[24], dst[8], src[8];
+int64_t largest_size = -1, current_size = -1;
+struct toc_entry {
+uint32_t offset;
+uint32_t size;
+} TOC[MAX_TOC_ENTRIES];
+union {
+uint8_t key[16];
+uint32_t part[4];
+} header_key;
+AADemuxContext *c =
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On Thu, 6 Aug 2015 23:26:05 +0200 Andreas Cadhalpun wrote: > On 06.08.2015 00:53, wm4 wrote: > > Well, you sure like to list a lot of projects. > > No, I don't. I'd like it much more if the list was empty. > > > But what you don't say > > is that many of these are either definitely dead (mplayer2 comes to > > mind), > > One is not many. But OK, let's get rid of mplayer2 [1]. So why does mplayer2 have to die, but other projects are extremely important to keep and thus no deprecated API should be dropped? I didn't attempt to check how many projects really rely on deprecated features, but... > > or are ancient releases of software which fixed their API usage > > later (like my own project, and probably most other reasonable active > > projects). > > Now I'm curious what your own project is. > I thought you were involved with mpv, but that still uses the deprecated > FF_API_AUDIOCONVERT [2]. It is mpv. Yes, there are 3 audioconvert.h include statements, but usage of any of the symbols was removed almost 2.5 years ago. You only need a trivial patch to fix it. (Or make the upstream project aware. I didn't know about this, but removed the includes yesterday when I read your post. Why didn't I ever get a bug report from you about this?) How many more projects are there that can be trivially updated, but you weren't aware of? I also doubt that software like vlc, kodi, or chromium actually use deprecated API in their git development branches. Why do you want to compile old releases against bleeding edge libav/ffmpeg? > Projects like blender, gst-libav or mplayer are reasonably recent in Debian > and active upstream. But still they use deprecated APIs. > > > Why do we have to suffer because Debian tries to compile ancient > > releases against newer ffmpeg/libav releases? (How does that even make > > sense?) > > This is just your prejudice that doesn't have much to do with reality. I've had very much experience with distro reality. They tend to make everyone's life harder (including their own) by demanding that EVERY project uses the same libav* build. Well, if you want to do this, you're free to do so. But it's not our problem. Feel free to put as much effort into it as you like. > > And then there's the category of projects that are "alive", but barely > > care about anything unless being severely prodded. I'm not sure why we > > should suffer forever just to accommodate these projects. They had more > > than enough time. > > It's actually the other projects that have to suffer, because FFmpeg/Libav > breaks it's API. Time alone is not enough, there also needs to be good > documentation about API replacements and that is currently insufficient. This is all very tiring. We're trying to improve the APIs everyone likes to complain so much about. But staying compatible forever is just not feasible. It leads to accumulation of strange things, even if it's minor changes like the PIXFMT renames. Do you think anyone has it easier to develop a program using the libs when confronted with tons of legacy symbols? > > I feel like I'm repeating myself and others, but I don't remember > > whether you acknowledged these arguments. > > I'm seeing more dramatic words than good arguments in your mail. OK, let's be polemic: I'm seeing outright lies from you. Not nearly enough important software as you make it seem depends on deprecated features, and even if, many of them are trivially fixable. Of course older releases of them use deprecated features, because at the time they were not deprecated yet, or were still within the grace period. And I don't see why you see this as "proof". (Note that sometimes it's preferable to use deprecated features, because distros are on ancient libav* versions to keep unmaintained software depending on it going. This also very much sucks for the project authors, btw.) > >> Better documentation would surely be helpful. > > > > Many of these are non-trivial. Project authors either update their > > code, or the project dies. It's simple. If you don't want this, keep an > > old ffmpeg/libav package around for them. But you distro peoples want a > > single libavcodec package, no matter how much this fucking tortures > > everyone. > > So instead of keeping a little bit of deprecated code, everyone should > keep multiple copies of libavcodec? > This is several orders of magnitude worse. Why is it worse? Disk space is very cheap, and the libs aren't that big after all. But I know, you distro folks would rather waste a lot of time trying to make all projects use the same libs, instead of going the easy way. By the way, why the hell do I have to have two versions of Qt and 2 versions of Python on my Debian system? These are much heavier than libav*. > Best regards, > Andreas > > > 1: https://bugs.debian.org/794817 > 2: > https://github.com/mpv-player/mpv/blob/master/audio/filter/af_lavcac3enc.c#L29 ___ ffmpeg-devel mailing list ffmpeg-d
Re: [FFmpeg-devel] [PATCH] swscale: Implement alphablendaway for planar 4:4:4 formats
Hi,
On Fri, Aug 7, 2015 at 6:43 AM, Michael Niedermayer
wrote:
> On Thu, Aug 06, 2015 at 10:24:52PM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Thu, Aug 6, 2015 at 4:27 PM, Michael Niedermayer
> > wrote:
> >
> > > From: Michael Niedermayer
> > >
> > > Fixes Ticket4746
> > >
> > > TODO: implement packed formats and subsampled formats
> > >
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > doc/scaler.texi | 13 ++
> > > libswscale/Makefile |3 +-
> > > libswscale/alphablend.c | 55 +++
> > > libswscale/options.c |3 ++
> > > libswscale/swscale_internal.h | 12 +
> > > libswscale/utils.c| 97
> > > +
> > > 6 files changed, 182 insertions(+), 1 deletion(-)
> > > create mode 100644 libswscale/alphablend.c
> > >
> > > diff --git a/doc/scaler.texi b/doc/scaler.texi
> > > index 23d6393..4c55334 100644
> > > --- a/doc/scaler.texi
> > > +++ b/doc/scaler.texi
> > > @@ -122,6 +122,19 @@ a_dither).
> > >
> > > @end table
> > >
> > > +@item alphablend
> > > +Set the alpha blending to use when the input has alpha but the output
> > > does not.
> > > +Default value is @samp{black}.
> > > +
> > > +@table @samp
> > > +@item black
> > > +Blend onto black
> > > +
> > > +@item none
> > > +No blending
> > > +
> > > +@end table
> > > +
> > > @end table
> >
> >
> > I must admit I'm not a fan of having just two values for something like
> > this. It seems to me you want 2 options, "blendmode", being "none" or
> > "background" (or a float/alpha between 1.0/0.0), and the actual
> background
> > color (black, white, blue, r=a,g=b,c=d). "black" vs. "none" seems like a
> > future compat nightmare. Is it that hard to implement a proper rgb/yuv
> > value solution?
>
> The color value convertion support is in drawutils which is in
> libavfilter. also drawutils lacks support for >8bit formats
> so to get arbitrary color support with a clean non duplicated
> implementation it would require moving drawutils
> or the color related code from it to libavutil and extending it to
> support all pixel formats. Unless iam missing something
>
> Also i wanted to implement support for a checkerboard background
> (which some applications use as default and it shows what
> is transparent much better than black would)
>
> So i would suggest that we implement ATM a "none" + "solidcolor" or
> "background" or what name is preferred
> and ill add a black/white checkerboard mode later and once drawutils
> exist in libavutil we can then easily add a "blendcolor" AVOption
> to specify the exact color
>
> If noone objects then ill work on that (except drawutils moving and
> extending)
Sounds ok.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Problem Still Exists on avcodec/vdpau_hevc: Remove experimental flag
On Fri, 7 Aug 2015 09:45:23 + (UTC) Ali KIZIL wrote: > Hello, > > I wanted to inform interleaving problem still exisits even with > Nvidia 355.06 driver. More info here: > > https://github.com/FFmpeg/FFmpeg/commit/aa10f0aab0e2729e0a5edbd7b6838658d6 > 3421e1 I replied on github too, but yes, this is a known problem. They fixed it for video being rendered for display but didn't fix the read-back path used by ffmpeg.c --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movtextdec.c: Add support for font names
The leak was happening because the m->count_f was initialised to 0 at the
wrong place which was used in freeing the mem allocs. I am posting a patch
to fix that.
Thanks,
Niklesh
On Fri, Aug 7, 2015 at 5:11 AM, Michael Niedermayer
wrote:
> On Thu, Aug 06, 2015 at 09:17:17AM +0530, Niklesh Lalwani wrote:
> > Changes incorporated.
> > Updated patch attached.
> >
> > Thanks,
> > Niklesh
> >
> > On Thu, Aug 6, 2015 at 7:51 AM, Philip Langdale
> wrote:
> >
> > > On Thu, 6 Aug 2015 07:13:07 +0530
> > > Niklesh Lalwani wrote:
> > >
> > > > On Thu, Aug 6, 2015 at 2:02 AM, Philip Langdale
> > > > wrote:
> > > >
> > > > > On Thu, 6 Aug 2015 00:12:07 +0530
> > > > > Niklesh Lalwani wrote:
> > > > >
> > > > > > From 90f466bb6a5d3cd24d7ea4d9fd8a2915cc68cdb2 Mon Sep 17 00:00:00
> > > > > > 2001 From: Niklesh
> > > > > > Date: Thu, 6 Aug 2015 00:06:15 +0530
> > > > > > Subject: [PATCH] movtextdec.c: Add support for font names
> > > > > >
> > > > > > Signed-off-by: Niklesh
> > > > > > ---
> > > > > > libavcodec/movtextdec.c | 109
> > > > > > ++-- 1 file changed,
> > > > > > 106 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
> > > > > > index 869358c..451056c 100644
> > > > > > --- a/libavcodec/movtextdec.c
> > > > > > +++ b/libavcodec/movtextdec.c
> > > > > > @@ -36,10 +36,17 @@
> > > > > > #define HCLR_BOX (1<<2)
> > > > > >
> > > > > > typedef struct {
> > > > > > +uint16_t fontID;
> > > > > > +uint8_t font_name_length;
> > > > > > +uint8_t font[20];
> > > > > > +} FontRecord;
> > > > > > +
> > > > > > +typedef struct {
> > > > > > uint16_t style_start;
> > > > > > uint16_t style_end;
> > > > > > uint8_t style_flag;
> > > > > > uint8_t fontsize;
> > > > > > +uint16_t style_fontID;
> > > > > > } StyleBox;
> > > > > >
> > > > > > typedef struct {
> > > > > > @@ -56,11 +63,13 @@ typedef struct {
> > > > > > StyleBox *s_temp;
> > > > > > HighlightBox h;
> > > > > > HilightcolorBox c;
> > > > > > +FontRecord **ftab;
> > > > > > +FontRecord *ftab_temp;
> > > > > > uint8_t box_flags;
> > > > > > -uint16_t style_entries;
> > > > > > +uint16_t style_entries, ftab_entries;
> > > > > > uint64_t tracksize;
> > > > > > int size_var;
> > > > > > -int count_s;
> > > > > > +int count_s, count_f;
> > > > > > } MovTextContext;
> > > > > >
> > > > > > typedef struct {
> > > > > > @@ -80,6 +89,80 @@ static void mov_text_cleanup(MovTextContext
> *m)
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > +static void mov_text_cleanup_ftab(MovTextContext *m)
> > > > > > +{
> > > > > > +int i;
> > > > > > +for(i = 0; i < m->count_f; i++) {
> > > > > > +av_freep(&m->ftab[i]);
> > > > > > +}
> > > > > > +av_freep(&m->ftab);
> > > > > > +}
> > > > > > +
> > > > > > +static int mov_text_t3xg(AVCodecContext *avctx, MovTextContext
> > > > > > *m)
> > > > >
> > > > > I'm pretty sure it's "tx3g"
> > > > >
> > > > > > +{
> > > > > > +char *t3xg_ptr = avctx->extradata;
> > > > > > +int i, tracksize;
> > > > > > +
> > > > > > +tracksize = 38; /* Size till ftab_entries */
> > > > >
> > > > > I'd say box size. It's not technically a track.
> > > > >
> > > > > And make the 38 a constant.
> > > > >
> > > > > > +if (avctx->extradata_size < tracksize)
> > > > > > +return -1;
> > > > > > +
> > > > > > +m->ftab_entries = 0;
> > > > > > +// Display Flags
> > > > > > +t3xg_ptr += 4;
> > > > > > +// Alignment
> > > > > > +t3xg_ptr += 2;
> > > > > > +// Background Color
> > > > > > +t3xg_ptr += 4;
> > > > > > +// BoxRecord
> > > > > > +t3xg_ptr += 8;
> > > > > > +// StyleRecord
> > > > > > +t3xg_ptr += 12;
> > > > > > +// FontRecord
> > > > > > +// FontRecord Size
> > > > > > +t3xg_ptr += 4;
> > > > > > +// ftab
> > > > > > +t3xg_ptr += 4;
> > > > > > +
> > > > > > +tracksize += 2;
> > > > > > +if (avctx->extradata_size < tracksize)
> > > > > > +return -1;
> > > > >
> > > > > Why not just initialize tracksize to 40? The extra += 2 isn't
> > > > > optional.
> > > > >
> > > > > > +
> > > > > > +m->ftab_entries = AV_RB16(t3xg_ptr);
> > > > > > +t3xg_ptr += 2;
> > > > > > +
> > > > > > +for (i = 0; i < m->ftab_entries; i++) {
> > > > > > +
> > > > > > +tracksize += 3;
> > > > > > +if (avctx->extradata_size < tracksize) {
> > > > > > +m->ftab_entries = 0;
> > > > > > +return -1;
> > > > > > +}
> > > > >
> > > > > You need to clean up any ftab entries that have already been
> > > > > processed.
> > > > >
> > > > > > +m->ftab_temp = av_malloc(sizeof(*m->ftab_temp));
> > > > > > +if (!m->ftab_temp) {
> > > > > > +mov_text_cleanup_ftab(m);
> > > > > > +return AVERROR(ENOMEM);
> > > > > > +}
> > > > > > +m->ftab_tem
[FFmpeg-devel] [PATCH] movtextdec: Fix memory leaks by freeing mem allocs correctly
From: Niklesh
Initialize m->count_f to 0 at the correct place to free memory allocs properly.
Signed-off-by: Niklesh
---
libavcodec/movtextdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
index 83b0231..fc6993e 100644
--- a/libavcodec/movtextdec.c
+++ b/libavcodec/movtextdec.c
@@ -107,6 +107,7 @@ static int mov_text_tx3g(AVCodecContext *avctx,
MovTextContext *m)
char *tx3g_ptr = avctx->extradata;
int i, box_size, font_length;
+m->count_f = 0;
m->ftab_entries = 0;
box_size = BOX_SIZE_INITIAL; /* Size till ftab_entries */
if (avctx->extradata_size < box_size)
@@ -363,7 +364,6 @@ static int mov_text_decode_frame(AVCodecContext *avctx,
m->style_entries = 0;
m->box_flags = 0;
m->count_s = 0;
-m->count_f = 0;
// Note that the spec recommends lines be no longer than 2048 characters.
av_bprint_init(&buf, 0, AV_BPRINT_SIZE_UNLIMITED);
if (text_length + 2 != avpkt->size) {
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Ticket4753 question
https://trac.ffmpeg.org/ticket/4753: The issue seems to come from the fact that there are multiple frames per packet. In fact, the duration field of the packet is set incorrectly, and reports the duration of a single frame only (80). Unfortunately, I do not know about where/how this needs to be done, but can do this if a dev outlines the process. Thanks, Ganesh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Ticket4753 question
On 8/7/15, Ganesh Ajjanagadde wrote: > https://trac.ffmpeg.org/ticket/4753: > The issue seems to come from the fact that there are multiple frames per > packet. > In fact, the duration field of the packet is set incorrectly, > and reports the duration of a single frame only (80). > Unfortunately, I do not know about where/how this needs to be done, > but can do this if a dev outlines the process. Write trivial g729_parser which splits input into 8 byte packets. Problem is how to tell parser from demuxer that another non 8 byte mode is in operation. Because decoder operates in one of two modes, either 8 byte or 10 byte. > > Thanks, > Ganesh > ___ > 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
[FFmpeg-devel] [PATCH 1/2] better demo ffmpeg filters; demos chaining the filters
Hi ffmpeg developers, I want to submit the following patch. It's a minor thing that improves the filtering_video.c to demo chaining of vfilters. >From ceda852421e51712352ab2b1230b715ea0073f6a Mon Sep 17 00:00:00 2001 From: Harshit Mittal Date: Wed, 5 Aug 2015 12:41:49 -0700 Subject: [PATCH 1/2] better demo ffmpeg filters; demos chaining the filters --- doc/examples/filtering_video.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/examples/filtering_video.c b/doc/examples/filtering_video.c index c02040a..7c710e2 100644 --- a/doc/examples/filtering_video.c +++ b/doc/examples/filtering_video.c @@ -38,7 +38,7 @@ #include #include -const char *filter_descr = "scale=78:24"; +const char *filter_descr = "[in] scale=78:24 [scl]; [scl] transpose=cclock"; static AVFormatContext *fmt_ctx; static AVCodecContext *dec_ctx; -- 2.5.0 >From ef9df636f2e6181c887c8109081f4b72ee794cec Mon Sep 17 00:00:00 2001 From: Harshit Mittal Date: Thu, 6 Aug 2015 12:40:40 -0700 Subject: [PATCH 2/2] demo without the pads --- doc/examples/filtering_video.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/doc/examples/filtering_video.c b/doc/examples/filtering_video.c index 7c710e2..5685380 100644 --- a/doc/examples/filtering_video.c +++ b/doc/examples/filtering_video.c @@ -38,7 +38,10 @@ #include #include -const char *filter_descr = "[in] scale=78:24 [scl]; [scl] transpose=cclock"; +const char *filter_descr = "scale=78:24,transpose=cclock"; +/* other way: + scale=78:24 [scl]; [scl] transpose=cclock // assumes "[in]" and "[out]" to be input output pads respectively + */ static AVFormatContext *fmt_ctx; static AVCodecContext *dec_ctx; -- 2.5.0 FROM: https://github.com/FFmpeg/FFmpeg/pull/145 ffmpeg_vfilters_demo.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Ticket4753 question
On Fri, Aug 7, 2015 at 11:59 AM, Paul B Mahol wrote: > On 8/7/15, Ganesh Ajjanagadde wrote: >> https://trac.ffmpeg.org/ticket/4753: >> The issue seems to come from the fact that there are multiple frames per >> packet. >> In fact, the duration field of the packet is set incorrectly, >> and reports the duration of a single frame only (80). >> Unfortunately, I do not know about where/how this needs to be done, >> but can do this if a dev outlines the process. > > Write trivial g729_parser which splits input into 8 byte packets. Thanks, I have implemented the 8 byte case. > > Problem is how to tell parser from demuxer that another non 8 byte > mode is in operation. > Because decoder operates in one of two modes, either 8 byte or 10 byte. This is tricky. A dirty but simple solution would be to add a field to the priv_data of the avctx, i.e to G729Context to represent the format, and use that in the parser. I have not seen any other parser do this though. Note that the parser is quite limited in what it can see: the AVCodecParserContext can't contain this information as far as I can tell, so only AVCodecContext can. In this case I don't know how to do this without resorting to the priv_data. Any suggestions? > >> >> Thanks, >> Ganesh >> ___ >> 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
Hello, On Friday, 07 August 2015 at 15:36, wm4 wrote: > On Thu, 6 Aug 2015 23:26:05 +0200 > Andreas Cadhalpun wrote: > > On 06.08.2015 00:53, wm4 wrote: [...] > > > Why do we have to suffer because Debian tries to compile ancient > > > releases against newer ffmpeg/libav releases? (How does that even make > > > sense?) > > > > This is just your prejudice that doesn't have much to do with reality. > > I've had very much experience with distro reality. They tend to make > everyone's life harder (including their own) by demanding that EVERY > project uses the same libav* build. Actually, speaking with my distro hat on, that's more or less the idea, though I wouldn't say we (Fedora/RPMFusion) are demanding anything. We do want to ship a single ffmpeg build per distro release and have each depending project link against it. If that means back/forward-porting code to adapt the other projects to API changes then that's the package maintainer's job. > Well, if you want to do this, you're free to do so. But it's not our > problem. Feel free to put as much effort into it as you like. Indeed. Though we may ask politely that FFmpeg project supports a given ffmpeg release for the ~13 months of a given Fedora release lifecycle. We would very much appreciate porting-to-new-API guides as that would make providing patches to depending project upstreams a lot easier. [...] > > >> Better documentation would surely be helpful. > > > > > > Many of these are non-trivial. Project authors either update their > > > code, or the project dies. It's simple. If you don't want this, keep an > > > old ffmpeg/libav package around for them. But you distro peoples want a > > > single libavcodec package, no matter how much this fucking tortures > > > everyone. > > > > So instead of keeping a little bit of deprecated code, everyone should > > keep multiple copies of libavcodec? > > This is several orders of magnitude worse. > > Why is it worse? Disk space is very cheap, and the libs aren't that big > after all. But I know, you distro folks would rather waste a lot of > time trying to make all projects use the same libs, instead of going > the easy way. Yes, we do. Once the initial porting work is done, we can fix security issues and other bugs in one place, by updating one package. That's a big maintenance win. However, at least in Fedora, if a project can't be ported to current library APIs (for example because it's dead) then we either drop it or introduce a compat package with an older version of the library. There is strong preference for the first option though. > By the way, why the hell do I have to have two versions of Qt and 2 > versions of Python on my Debian system? These are much heavier than > libav*. You're right, but there are also much more users of Qt and Python and there are (I think) much more extensive API changes between Qt 4 and 5, and between python-2.x and 3.x. They were also designed as parallel installable from the beginning. Regards, Dominik (FFmpeg (co-)maintainer in RPMFusion/Fedora) -- MPlayer http://mplayerhq.hu | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: modify tty state when stderr is redirected
On Tue, Aug 4, 2015 at 8:54 PM, Ganesh Ajjanagadde wrote: > On Mon, Aug 3, 2015 at 10:47 AM, Nicolas George wrote: >> Le sextidi 16 thermidor, an CCXXIII, Hendrik Leppkes a écrit : >>> Trashing the state even more often just because there is one example >>> where this can already happen is not a valid reasoning. >> >> The changes should be applied because they are the RIGHT behaviour, as I >> explained in this mail: >> >> http://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176480.html >> >> The second patch gives a 10-second solutions that will fix ALL trashed ttys, >> for FFmpeg and every other program on the system. >> >> Furthermore, the third patch ensures that the particular case that this >> absurd heuristic fixed does not happen anyway. > > Above explanation gives good justification for this patch. > Is there anything I can do to get the patch series applied? ping > >> >> Regards, >> >> -- >> Nicolas George >> >> ___ >> 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] Ticket4753 question
On 8/7/15, Ganesh Ajjanagadde wrote: > On Fri, Aug 7, 2015 at 11:59 AM, Paul B Mahol wrote: >> On 8/7/15, Ganesh Ajjanagadde wrote: >>> https://trac.ffmpeg.org/ticket/4753: >>> The issue seems to come from the fact that there are multiple frames per >>> packet. >>> In fact, the duration field of the packet is set incorrectly, >>> and reports the duration of a single frame only (80). >>> Unfortunately, I do not know about where/how this needs to be done, >>> but can do this if a dev outlines the process. >> >> Write trivial g729_parser which splits input into 8 byte packets. > > Thanks, I have implemented the 8 byte case. > >> >> Problem is how to tell parser from demuxer that another non 8 byte >> mode is in operation. >> Because decoder operates in one of two modes, either 8 byte or 10 byte. > > This is tricky. A dirty but simple solution would be to add a field to > the priv_data of the avctx, > i.e to G729Context to represent the format, and use that in the parser. > I have not seen any other parser do this though. > > Note that the parser is quite limited in what it can see: > the AVCodecParserContext can't contain this information as far as I can > tell, > so only AVCodecContext can. > In this case I don't know how to do this without resorting to the priv_data. At decoder level you can not guess it, neither at demuxer level and AFAIK only wav does put multiple frames into single packet. The only way is via option but AFAIK you can not read decoder options from parser. > > Any suggestions? > >> >>> >>> Thanks, >>> Ganesh >>> ___ >>> 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 > ___ > 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] Ticket4753 question
On Fri, Aug 7, 2015 at 4:09 PM, Paul B Mahol wrote: > On 8/7/15, Ganesh Ajjanagadde wrote: >> On Fri, Aug 7, 2015 at 11:59 AM, Paul B Mahol wrote: >>> On 8/7/15, Ganesh Ajjanagadde wrote: https://trac.ffmpeg.org/ticket/4753: The issue seems to come from the fact that there are multiple frames per packet. In fact, the duration field of the packet is set incorrectly, and reports the duration of a single frame only (80). Unfortunately, I do not know about where/how this needs to be done, but can do this if a dev outlines the process. >>> >>> Write trivial g729_parser which splits input into 8 byte packets. >> >> Thanks, I have implemented the 8 byte case. >> >>> >>> Problem is how to tell parser from demuxer that another non 8 byte >>> mode is in operation. >>> Because decoder operates in one of two modes, either 8 byte or 10 byte. >> >> This is tricky. A dirty but simple solution would be to add a field to >> the priv_data of the avctx, >> i.e to G729Context to represent the format, and use that in the parser. >> I have not seen any other parser do this though. >> >> Note that the parser is quite limited in what it can see: >> the AVCodecParserContext can't contain this information as far as I can >> tell, >> so only AVCodecContext can. >> In this case I don't know how to do this without resorting to the priv_data. > > At decoder level you can not guess it, neither at demuxer level and > AFAIK only wav does > put multiple frames into single packet. The only way is via option but > AFAIK you can not read decoder options from parser. I must be missing something, g729dec.c decode_frame does set packet_type to the appropriate mode based on avpkt->size. In fact, this is how currently the two modes (8k vs 6.4k) are differentiated. Why can't this be used to set a flag in avctx->priv_data (barring the ugliness)? > >> >> Any suggestions? >> >>> Thanks, Ganesh ___ 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 >> ___ >> 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Ticket4753 question
Dana 7. 8. 2015. 22:44 osoba "Ganesh Ajjanagadde" napisala je: > > On Fri, Aug 7, 2015 at 4:09 PM, Paul B Mahol wrote: > > On 8/7/15, Ganesh Ajjanagadde wrote: > >> On Fri, Aug 7, 2015 at 11:59 AM, Paul B Mahol wrote: > >>> On 8/7/15, Ganesh Ajjanagadde wrote: > https://trac.ffmpeg.org/ticket/4753: > The issue seems to come from the fact that there are multiple frames per > packet. > In fact, the duration field of the packet is set incorrectly, > and reports the duration of a single frame only (80). > Unfortunately, I do not know about where/how this needs to be done, > but can do this if a dev outlines the process. > >>> > >>> Write trivial g729_parser which splits input into 8 byte packets. > >> > >> Thanks, I have implemented the 8 byte case. > >> > >>> > >>> Problem is how to tell parser from demuxer that another non 8 byte > >>> mode is in operation. > >>> Because decoder operates in one of two modes, either 8 byte or 10 byte. > >> > >> This is tricky. A dirty but simple solution would be to add a field to > >> the priv_data of the avctx, > >> i.e to G729Context to represent the format, and use that in the parser. > >> I have not seen any other parser do this though. > >> > >> Note that the parser is quite limited in what it can see: > >> the AVCodecParserContext can't contain this information as far as I can > >> tell, > >> so only AVCodecContext can. > >> In this case I don't know how to do this without resorting to the priv_data. > > > > At decoder level you can not guess it, neither at demuxer level and > > AFAIK only wav does > > put multiple frames into single packet. The only way is via option but > > AFAIK you can not read decoder options from parser. > > I must be missing something, g729dec.c decode_frame does set packet_type > to the appropriate mode based on avpkt->size. > In fact, this is how currently the two modes (8k vs 6.4k) are differentiated. > Why can't this be used to set a flag in avctx->priv_data (barring the ugliness)? For example 80 is multiple of 8 and 10 you can't use that to guess mode. > > > > >> > >> Any suggestions? > >> > >>> > > Thanks, > Ganesh > ___ > 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 > >> ___ > >> 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 > ___ > 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] Ticket4753 question
On Fri, Aug 7, 2015 at 6:05 PM, Paul B Mahol wrote: > Dana 7. 8. 2015. 22:44 osoba "Ganesh Ajjanagadde" > napisala je: >> >> On Fri, Aug 7, 2015 at 4:09 PM, Paul B Mahol wrote: >> > On 8/7/15, Ganesh Ajjanagadde wrote: >> >> On Fri, Aug 7, 2015 at 11:59 AM, Paul B Mahol wrote: >> >>> On 8/7/15, Ganesh Ajjanagadde wrote: >> https://trac.ffmpeg.org/ticket/4753: >> The issue seems to come from the fact that there are multiple frames > per >> packet. >> In fact, the duration field of the packet is set incorrectly, >> and reports the duration of a single frame only (80). >> Unfortunately, I do not know about where/how this needs to be done, >> but can do this if a dev outlines the process. >> >>> >> >>> Write trivial g729_parser which splits input into 8 byte packets. >> >> >> >> Thanks, I have implemented the 8 byte case. >> >> >> >>> >> >>> Problem is how to tell parser from demuxer that another non 8 byte >> >>> mode is in operation. >> >>> Because decoder operates in one of two modes, either 8 byte or 10 > byte. >> >> >> >> This is tricky. A dirty but simple solution would be to add a field to >> >> the priv_data of the avctx, >> >> i.e to G729Context to represent the format, and use that in the parser. >> >> I have not seen any other parser do this though. >> >> >> >> Note that the parser is quite limited in what it can see: >> >> the AVCodecParserContext can't contain this information as far as I can >> >> tell, >> >> so only AVCodecContext can. >> >> In this case I don't know how to do this without resorting to the > priv_data. >> > >> > At decoder level you can not guess it, neither at demuxer level and >> > AFAIK only wav does >> > put multiple frames into single packet. The only way is via option but >> > AFAIK you can not read decoder options from parser. >> >> I must be missing something, g729dec.c decode_frame does set packet_type >> to the appropriate mode based on avpkt->size. >> In fact, this is how currently the two modes (8k vs 6.4k) are > differentiated. >> Why can't this be used to set a flag in avctx->priv_data (barring the > ugliness)? > > For example 80 is multiple of 8 and 10 you can't use that to guess mode. True, but that is a general failing of the decoder currently present. By setting the priv_data, we are making as good an effort as the decoder currently does. >> >> > >> >> >> >> Any suggestions? >> >> >> >>> >> >> Thanks, >> Ganesh >> ___ >> 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 >> >> ___ >> >> 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 >> ___ >> 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add new Videotoolbox hwaccel.
> On 03 Aug 2015, at 10:27, Clément Bœsch wrote: > > On Fri, Jul 31, 2015 at 08:57:49PM +0200, Clément Bœsch wrote: >> On Thu, Jul 30, 2015 at 05:12:21PM +0800, Zhang Rui wrote: >> [...] >>> BTW: >>> I think current patch is OK enough. >> >> I will push it soon (unless Sebastien has write access?) >> > > Applied. Thanks! I've write access but was in a hurry professional these last weeks. > >>> Async-mode could be an experimental option. >> >> Sebastien, do you plan to work on this? I quickly tried to add the async >> flag as decoding but as expected it's not enought to make it work. I >> suppose we need a queue or something. >> > > ping, I'll be working on that otherwise. Indeed, with the async decoding enabled a queue is required to reorder the decoded frames. I spent some times today and got an experimental implementation that allows to enable the async decoding mode. I’ll provide a patch here for the async support this weekend. Regards, — Sebastien Zwickert ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On Fri, 7 Aug 2015 19:28:26 +0200 Dominik 'Rathann' Mierzejewski wrote: > Hello, > > On Friday, 07 August 2015 at 15:36, wm4 wrote: > > On Thu, 6 Aug 2015 23:26:05 +0200 > > Andreas Cadhalpun wrote: > > > On 06.08.2015 00:53, wm4 wrote: > [...] > > > > Why do we have to suffer because Debian tries to compile ancient > > > > releases against newer ffmpeg/libav releases? (How does that even make > > > > sense?) > > > > > > This is just your prejudice that doesn't have much to do with reality. > > > > I've had very much experience with distro reality. They tend to make > > everyone's life harder (including their own) by demanding that EVERY > > project uses the same libav* build. > > Actually, speaking with my distro hat on, that's more or less the idea, > though I wouldn't say we (Fedora/RPMFusion) are demanding anything. > We do want to ship a single ffmpeg build per distro release and have > each depending project link against it. If that means > back/forward-porting code to adapt the other projects to API changes > then that's the package maintainer's job. That's a commendable goal, but also somewhat counterproductive. If the devs of a project say that the software can't run with a newer or older ffmpeg version, it probably has its reasons. I think it's not unreasonable to ship a software with the dependencies recommended by its developers. But the main effect is that the distro's entire multimedia infrastructure is held back because some relatively unimportant programs still weren't ported to newer ffmpeg. And somehow maintainers seem to blame the API improvement progress in ffmpeg/Libav (especially Libav), instead of the maintainers of these programs. (But duplicating Python or Qt is apparently OK.) > > Well, if you want to do this, you're free to do so. But it's not our > > problem. Feel free to put as much effort into it as you like. > > Indeed. Though we may ask politely that FFmpeg project supports a given > ffmpeg release for the ~13 months of a given Fedora release lifecycle. If someone takes it on... until recently we actually had a maintainer who managed a dozen release branches or so, but I doubt other current FFmpeg devs are so enthusiastic about it. > We would very much appreciate porting-to-new-API guides as that would > make providing patches to depending project upstreams a lot easier. Actually Libav, which did pretty much all API changes (as opposed to additions), has migration guides: https://wiki.libav.org/Migration/10 https://wiki.libav.org/Migration/11 Of course FFmpeg merged only the git commits, but (apparently) didn't provide any migration guides. I think there were also ideas to provide more examples, such as for libavresample in order to make the lavc resampler deprecation easier. Not sure what happened to this. At least FFmpeg has a resampler example: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/resampling_audio.c > [...] > > > >> Better documentation would surely be helpful. > > > > > > > > Many of these are non-trivial. Project authors either update their > > > > code, or the project dies. It's simple. If you don't want this, keep an > > > > old ffmpeg/libav package around for them. But you distro peoples want a > > > > single libavcodec package, no matter how much this fucking tortures > > > > everyone. > > > > > > So instead of keeping a little bit of deprecated code, everyone should > > > keep multiple copies of libavcodec? > > > This is several orders of magnitude worse. > > > > Why is it worse? Disk space is very cheap, and the libs aren't that big > > after all. But I know, you distro folks would rather waste a lot of > > time trying to make all projects use the same libs, instead of going > > the easy way. > > Yes, we do. Once the initial porting work is done, we can fix security > issues and other bugs in one place, by updating one package. That's > a big maintenance win. Applying a single patch to 2 very similar codebases is very simple. Uploading multiple packages automatically surely is trivial. Keep in mind that a FFmpeg maintainer would have to do the same thing. > However, at least in Fedora, if a project can't be ported to current library > APIs (for example because it's dead) then we either drop it or introduce > a compat package with an older version of the library. There is strong > preference for the first option though. > > > By the way, why the hell do I have to have two versions of Qt and 2 > > versions of Python on my Debian system? These are much heavier than > > libav*. > > You're right, but there are also much more users of Qt and Python > and there are (I think) much more extensive API changes between Qt 4 and > 5, and between python-2.x and 3.x. They were also designed as parallel > installable from the beginning. So is it ok if FFmpeg changes more radically between releases, and use different pkg-config names on each major (incompatible) bump? > Regards, > Dominik (FFmpeg (co-)maintainer in RPMFusion/
[FFmpeg-devel] [rfc] ffmpeg security issue mailing list
hello, some of you know that we have a list for security / CVE issues. some of you did not know this. i think it is a private list due to not wanting people to make exploits before we have a chance to fix them. of course, if no one is subscribed to review/fix issues then they will never get fixed. so if you are a regular developer who wants access to this list, please speak up. i do not run nor admin the security email/list (nor do i know who does) so please dont ask me questions about it. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [rfc] ffmpeg security issue mailing list
On Fri, Aug 07, 2015 at 07:46:55PM -0400, compn wrote: > hello, > > some of you know that we have a list for security / CVE issues. > some of you did not know this. > > i think it is a private list due to not wanting people to make exploits > before we have a chance to fix them. of course, if no one is subscribed > to review/fix issues then they will never get fixed. > > so if you are a regular developer who wants access to this list, please > speak up. > > i do not run nor admin the security email/list (nor do i know who does) > so please dont ask me questions about it. I guess, i "de facto" admin the security "email/list". if someone wants to help with security issues, mail me but there are no open security issues and if there was one i very likely would fix it ASAP [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] avcodec/samidec: use ff_htmlmarkup_to_ass()
---
libavcodec/samidec.c| 59 +
tests/ref/fate/sub-sami | 18 +++
2 files changed, 44 insertions(+), 33 deletions(-)
diff --git a/libavcodec/samidec.c b/libavcodec/samidec.c
index 47850e2..41826a7 100644
--- a/libavcodec/samidec.c
+++ b/libavcodec/samidec.c
@@ -27,6 +27,7 @@
#include "ass.h"
#include "libavutil/avstring.h"
#include "libavutil/bprint.h"
+#include "htmlsubtitles.h"
typedef struct {
AVBPrint source;
@@ -41,11 +42,12 @@ static int sami_paragraph_to_ass(AVCodecContext *avctx,
const char *src)
char *tag = NULL;
char *dupsrc = av_strdup(src);
char *p = dupsrc;
+char *pcopy = NULL;
+int index = 0;
+int second_paragraph = 0;
-av_bprint_clear(&sami->content);
for (;;) {
char *saveptr = NULL;
-int prev_chr_is_space = 0;
AVBPrint *dst = &sami->content;
/* parse & extract paragraph tag */
@@ -77,37 +79,46 @@ static int sami_paragraph_to_ass(AVCodecContext *avctx,
const char *src)
goto end;
}
-/* extract the text, stripping most of the tags */
+/* check for the second paragrph */
+pcopy = av_strdup(p);
while (*p) {
if (*p == '<') {
-if (!av_strncasecmp(p, "full);
-if (sami->source.len)
-av_bprintf(&sami->full, "{\\i1}%s{\\i0}\\N", sami->source.str);
-av_bprintf(&sami->full, "%s", sami->content.str);
+ff_htmlmarkup_to_ass(avctx, dst, p);
+
+/* add the source if there are any. */
+av_bprint_clear(&sami->full);
+if (sami->source.len) {
+av_bprintf(&sami->full, "{\\i1}%s{\\i0}\\N", sami->source.str);
+av_bprintf(&sami->full, "%s", sami->content.str);
+if (second_paragraph) {
+second_paragraph = 0;
+p = pcopy;
+p += index;
+index = 0;
+continue;
+}
+} else {
+av_bprintf(&sami->full, "%s", sami->content.str);
+}
+av_bprint_clear(&sami->content);
+
+}
end:
+av_free(pcopy);
av_free(dupsrc);
return ret;
}
diff --git a/tests/ref/fate/sub-sami b/tests/ref/fate/sub-sami
index caa85a2..3c73526 100644
--- a/tests/ref/fate/sub-sami
+++ b/tests/ref/fate/sub-sami
@@ -10,12 +10,12 @@ Style:
Default,Arial,16,&Hff,&Hff,&H0,&H0,0,0,0,0,100,100,0,0,1,1,0,2,10
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
-Dialogue: 0,0:00:00.00,0:00:00.01,Default,,0,0,0,,{\i1}Pres. John F. Kennedy
{\i0}\N
-Dialogue: 0,0:00:00.01,0:00:08.80,Default,,0,0,0,,{\i1}Pres. John F. Kennedy
{\i0}\NLet the word go forth, from this time and place to friend and foe alike
that the torch
-Dialogue: 0,0:00:08.80,0:00:19.50,Default,,0,0,0,,{\i1}Pres. John F. Kennedy
{\i0}\Nhas been passed to a new generation of Americans, born in this century,
tempered by war,
-Dialogue: 0,0:00:19.50,0:00:28.00,Default,,0,0,0,,{\i1}Pres. John F. Kennedy
{\i0}\Ndisciplined by a hard and bitter peace, proud of our ancient heritage,
and unwilling to witness
-Dialogue: 0,0:00:28.00,0:00:38.00,Default,,0,0,0,,{\i1}Pres. John F. Kennedy
{\i0}\Nor permit the slow undoing of those human rights to which this nation
has always
-Dialogue: 0,0:00:38.00,0:00:46.00,Default,,0,0,0,,{\i1}Pres. John F. Kennedy
{\i0}\Nbeen committed and to which we are committed today at home and around
the world.
-Dialogue: 0,0:00:46.00,0:01:01.00,Default,,0,0,0,,{\i1}Pres. John F. Kennedy
{\i0}\NLet every nation know, whether it wishes us well or ill, that we shall
pay any price, bear any burden,
-Dialogue: 0,0:01:01.00,0:01:13.00,Default,,0,0,0,,{\i1}Pres. John F. Kennedy
{\i0}\Nmeet any hardship, support any friend, oppose any foe, to ensure the
survival and success of liberty.
-Dialogue: 0,0:01:13.00,9:59:59.99,Default,,0,0,0,,{\i1}End of:
{\i0}\NPresident John F. Kennedy Speech
+Dialogue: 0,0:00:00.00,0:00:00.01,Default,,0,0,0,,{\i1}Pres. John F.
Kennedy{\i0}\N
+Dialogue: 0,0:00:00.01,0:00:08.80,Default,,0,0,0,,{\i1}Pres. John F.
Kennedy{\i0}\NLet the word go forth,\Nfrom this time and place to friend and
foe\Nalike that the torch
+Dialogue: 0,0:00:08.80,0:00:19.50,Default,,0,0,0,,{\i1}Pres. John F.
Kennedy{\i0}\Nhas been passed to a new generation of Americans,\Nborn in this
century, tempered by war,
+Dialogue: 0,0:00:19.50,0:00:28.00,Default,,0,0,0,,{\i1}Pres. John F.
Kennedy{\i0}\Ndisciplined by a hard and bitter peace,\Nproud of our ancient
heritage, and unwilling to witness
+Dialogue: 0,0:00:28.00,0:00:38.00,Default,,0,0,0,,{\i1}Pres. John F.
Kennedy{\i0}\Nor permit the slow undoing of those human rights\Nto which this
nation has always,
+Dialogue: 0,0:00:38.00,0:00:46.00,Default,,0,0,0,,{\i1}Pres. John F.
Kennedy{\i0}\Nbeen committed and to which we are\Ncommitted today at home and
around the world.
+Dialogue: 0,0:00:46.00,0:01:01.00,Default,
[FFmpeg-devel] [PATCH 1/4] avcodec/strdec: factor out HTML parsing code
This code will be used in SAMI decoder in a later commit.
---
libavcodec/Makefile| 4 +-
libavcodec/htmlsubtitles.c | 198 +
libavcodec/htmlsubtitles.h | 29 +++
libavcodec/srtdec.c| 149 +-
4 files changed, 231 insertions(+), 149 deletions(-)
create mode 100644 libavcodec/htmlsubtitles.c
create mode 100644 libavcodec/htmlsubtitles.h
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index e61b9cd..8201aa0 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -447,7 +447,7 @@ OBJS-$(CONFIG_RV20_DECODER)+= rv10.o
OBJS-$(CONFIG_RV20_ENCODER)+= rv20enc.o
OBJS-$(CONFIG_RV30_DECODER)+= rv30.o rv34.o rv30dsp.o
OBJS-$(CONFIG_RV40_DECODER)+= rv40.o rv34.o rv40dsp.o
-OBJS-$(CONFIG_SAMI_DECODER)+= samidec.o ass.o
+OBJS-$(CONFIG_SAMI_DECODER)+= samidec.o ass.o htmlsubtitles.o
OBJS-$(CONFIG_S302M_DECODER) += s302m.o
OBJS-$(CONFIG_S302M_ENCODER) += s302menc.o
OBJS-$(CONFIG_SANM_DECODER)+= sanm.o
@@ -471,7 +471,7 @@ OBJS-$(CONFIG_SONIC_DECODER) += sonic.o
OBJS-$(CONFIG_SONIC_ENCODER) += sonic.o
OBJS-$(CONFIG_SONIC_LS_ENCODER)+= sonic.o
OBJS-$(CONFIG_SP5X_DECODER)+= sp5xdec.o
-OBJS-$(CONFIG_SRT_DECODER) += srtdec.o ass.o
+OBJS-$(CONFIG_SRT_DECODER) += srtdec.o ass.o htmlsubtitles.o
OBJS-$(CONFIG_SRT_ENCODER) += srtenc.o ass_split.o
OBJS-$(CONFIG_STL_DECODER) += textdec.o ass.o
OBJS-$(CONFIG_SUBRIP_DECODER) += srtdec.o ass.o
diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
new file mode 100644
index 000..b766130
--- /dev/null
+++ b/libavcodec/htmlsubtitles.c
@@ -0,0 +1,198 @@
+/*
+ *
+ * Copyright (c) 2010 Aurelien Jacobs
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avstring.h"
+#include "libavutil/common.h"
+#include "libavutil/parseutils.h"
+#include "ass.h"
+#include "htmlsubtitles.h"
+
+static int html_color_parse(AVCodecContext *avctx, const char *str)
+{
+uint8_t rgba[4];
+if (av_parse_color(rgba, str, strcspn(str, "\" >"), avctx) < 0)
+return -1;
+return rgba[0] | rgba[1] << 8 | rgba[2] << 16;
+}
+
+enum {
+PARAM_UNKNOWN = -1,
+PARAM_SIZE,
+PARAM_COLOR,
+PARAM_FACE,
+PARAM_NUMBER
+};
+
+typedef struct SrtStack {
+char tag[128];
+char param[PARAM_NUMBER][128];
+} SrtStack;
+
+static void rstrip_spaces_buf(AVBPrint *buf)
+{
+while (buf->len > 0 && buf->str[buf->len - 1] == ' ')
+buf->str[--buf->len] = 0;
+}
+
+void ff_htmlmarkup_to_ass(AVCodecContext *avctx, AVBPrint *dst, const char *in)
+{
+char *param, buffer[128], tmp[128];
+int len, tag_close, sptr = 1, line_start = 1, an = 0, end = 0, count;
+SrtStack stack[16];
+
+stack[0].tag[0] = 0;
+strcpy(stack[0].param[PARAM_SIZE], "{\\fs}");
+strcpy(stack[0].param[PARAM_COLOR], "{\\c}");
+strcpy(stack[0].param[PARAM_FACE], "{\\fn}");
+
+for (; !end && *in; in++) {
+switch (*in) {
+case '\r':
+break;
+case '\n':
+if (line_start) {
+end = 1;
+break;
+}
+
+/* check if it is end of the paragraph or not*/
+in++;
+count = 1;
+while(*in == ' ') {
+in++;
+count++;
+}
+if (*in == '\0' || *in == '\n'){
+in = in - count;
+break;
+}
+in = in - count;
+
+/*if not the end of the paragraph, add line break */
+rstrip_spaces_buf(dst);
+av_bprintf(dst, "\\N");
+line_start = 1;
+break;
+case ' ':
+if (!line_start)
+av_bprint_chars(dst, *in, 1);
+break;
+case '{':/* skip all {\xxx} substrings except for {\an%d}
+and all microdvd like styles such as {Y:xxx} */
+len = 0;
+an += sscanf(in, "{\\an%*1u}%n", &len) >= 0 && len > 0;
+if ((an != 1 && (len = 0, sscanf(in, "{\\%*[^}]}%n", &len)
[FFmpeg-devel] [PATCH 3/4] avformat/samidec: fix tag close
---
libavformat/samidec.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavformat/samidec.c b/libavformat/samidec.c
index 948e1ed..bc9b745 100644
--- a/libavformat/samidec.c
+++ b/libavformat/samidec.c
@@ -68,11 +68,17 @@ static int sami_read_header(AVFormatContext *s)
while (!ff_text_eof(&tr)) {
AVPacket *sub;
const int64_t pos = ff_text_pos(&tr) - (c != 0);
-int is_sync, n = ff_smil_extract_next_text_chunk(&tr, &buf, &c);
+int is_sync, is_body, n = ff_smil_extract_next_text_chunk(&tr, &buf,
&c);
if (n == 0)
break;
+is_body = !av_strncasecmp(buf.str, "http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] fate reference for samidec
---
tests/fate/subtitles.mak | 3 ++
tests/ref/fate/sub-sami2 | 91
2 files changed, 94 insertions(+)
create mode 100644 tests/ref/fate/sub-sami2
diff --git a/tests/fate/subtitles.mak b/tests/fate/subtitles.mak
index d8b2034..0a6c33d 100644
--- a/tests/fate/subtitles.mak
+++ b/tests/fate/subtitles.mak
@@ -46,6 +46,9 @@ fate-sub-realtext: CMD = fmtstdout ass -i
$(TARGET_SAMPLES)/sub/RealText_capabil
FATE_SUBTITLES_ASS-$(call DEMDEC, SAMI, SAMI) += fate-sub-sami
fate-sub-sami: CMD = fmtstdout ass -i
$(TARGET_SAMPLES)/sub/SAMI_capability_tester.smi
+FATE_SUBTITLES_ASS-$(call DEMDEC, SAMI, SAMI) += fate-sub-sami2
+fate-sub-sami2: CMD = fmtstdout ass -i
$(TARGET_SAMPLES)/sub/SAMI_ass_capability_tester.smi
+
FATE_SUBTITLES_ASS-$(call DEMDEC, SRT, SUBRIP) += fate-sub-srt
fate-sub-srt: CMD = fmtstdout ass -i
$(TARGET_SAMPLES)/sub/SubRip_capability_tester.srt
diff --git a/tests/ref/fate/sub-sami2 b/tests/ref/fate/sub-sami2
new file mode 100644
index 000..5703652
--- /dev/null
+++ b/tests/ref/fate/sub-sami2
@@ -0,0 +1,91 @@
+[Script Info]
+; Script generated by FFmpeg/Lavc
+ScriptType: v4.00+
+PlayResX: 384
+PlayResY: 288
+
+[V4+ Styles]
+Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour,
OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY,
Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR,
MarginV, Encoding
+Style:
Default,Arial,16,&Hff,&Hff,&H0,&H0,0,0,0,0,100,100,0,0,1,1,0,2,10,10,10,0
+
+[Events]
+Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
+Dialogue: 0,0:00:01.51,0:00:01.51,Default,,0,0,0,,by Psyence
Fictionist\npsyencefiction...@gmail.com
+Dialogue: 0,0:00:01.51,0:00:08.61,Default,,0,0,0,,Sync by: honeybunny and
Kerensky\Nwww.Addic7ed.com
+Dialogue: 0,0:00:10.11,0:00:10.11,Default,,0,0,0,,\N{\b1}사랑과 배신\N탐욕과 살육의
이야기죠{\b0}
+Dialogue:
0,0:00:10.11,0:00:13.98,Default,,0,0,0,,\N{\c&H800080&}The{\c}{\c&HCBC0FF&}re{\c}
{\c&HFF&}is{\c} {\c&HA5FF&}lo{\c}{\c&H&}ve{\c}
{\c&H8000&}and{\c}{\c&H00&}
bet{\c}{\c&HFF&}rayal{\c},\N{\b1}{\c&H808080&}g{\c}r{\c&H808080&}e{\c}e{\c&H808080&}d{\c}
and {\c&HFF&}m{\c}{\c&H808080&}u{\c}{\c&HFF&}rder{\c}{\b0}.
+Dialogue: 0,0:00:17.67,0:00:17.67,Default,,0,0,0,,\N{\c&H&}선악의 정의에
대해서\N대립하는 가치관을 가진{\c}
+Dialogue:
0,0:00:17.67,0:00:21.72,Default,,0,0,0,,\N{\c&HCBC0FF&}{\fs6}It's{\fs}
{\fs8}set{\fs}{\fs10} in {\fs}{\fs12}this{\fs}{\fs14}
intere{\fs}{\fs14}sting{\fs}\N{\fs16} world{\fs}{\fs18} of{\fs}
{\fs20}cont{\fs}{\fs22}rasting{\fs}{\fs24} ideology{\fs}{\c}
+Dialogue: 0,0:00:21.84,0:00:21.84,Default,,0,0,0,,\N{\u1}매력적인 세계에서\N이 모든 것이
펼쳐집니다{\u1}
+Dialogue:
0,0:00:21.84,0:00:23.58,Default,,0,0,0,,\N{\i1}{\c&H9966CC&}of{\c}{\c&HC2A3E0&}
what's{\c} {\c&HE0D1F0&}right{\c} {\c&HFCFAFE&}and{\c} wrong.{\i0}
+Dialogue: 0,0:00:23.69,0:00:23.69,Default,,0,0,0,,\N{\i1}이 주제를 심오한 철학으로\N담아내고
있어요{\i0}
+Dialogue:
0,0:00:23.69,0:00:25.67,Default,,0,0,0,,\N{\fs20}{\c&HFF&}{\s1}It{\s0}{\c}{\fs}
has {\fs15}{\c&H00&}a{\c}{\fs} great
{\fs16}{\c&HFFCC00&}philosophy{\c}{\fs} about it.
+Dialogue: 0,0:00:40.22,0:00:40.22,Default,,0,0,0,,\N{\s1}"왕좌의 게임"은 웨스테로스라는
가상왕국의\N권력 분쟁 이야기입니다{\s0}
+Dialogue: 0,0:00:40.22,0:00:47.94,Default,,0,0,0,,\N{\c&HA5FF&}{\fs26}"Game of
Thrones"{\fs}{\c} {\c&H2A2AA5&}{\b1}is{\b0}{\c}{\c&H&}{\fs24}{\i1}
about{\i0}{\fs}{\c} {\c&H336699&}{\fs14}power{\fs}{\c}{\c&HFF&}
struggles{\c}\N{\c&HA5FF&}{\fs8}in a fantasy{\fs}{\c&HCBC0FF&}
kingdom{\c&HA5FF&}, called {\fs6}Westeros.{\fs}{\c}
+Dialogue: 0,0:00:48.06,0:00:48.06,Default,,0,0,0,,\N철의 왕좌를 둘러싼\N권력 분쟁이죠
+Dialogue: 0,0:00:48.06,0:00:50.76,Default,,0,0,0,,\N{\c&H8000&}And it's a
power struggle\Nfor the Iron Throne,{\c}
+Dialogue: 0,0:00:50.88,0:00:50.88,Default,,0,0,0,,\N{\fs20}왕국의 권력 정점이라고\N할 수
있는 자리에요{\fs}
+Dialogue: 0,0:00:50.88,0:00:53.13,Default,,0,0,0,,\Nwhich is the seat of
power\Nin this kingdom.
+Dialogue: 0,0:00:53.25,0:00:53.25,Default,,0,0,0,,\N전운이 감도네, 네드
+Dialogue: 0,0:00:53.25,0:00:55.07,Default,,0,0,0,,\NThere's a war coming, Ned.
+Dialogue: 0,0:00:56.01,0:00:56.01,Default,,0,0,0,,\N\N언제 누구와 싸우게 될지는 몰라\N하지만
분명 전쟁이 일어날걸세
+Dialogue: 0,0:00:56.01,0:01:00.09,Default,,0,0,0,,\NI don't know when, I don't
know who\Nwould be fighting, but it's coming.
+Dialogue: 0,0:01:01.10,0:01:01.10,Default,,0,0,0,,\N이야기의 핵심은 두 주요 가문의\N권력을 둘러싼
갈등입니다
+Dialogue: 0,0:01:01.10,0:01:07.04,Default,,0,0,0,,\N{\i1}At the core of it
there's a conflict for\Npower between two great houses initially.{\i0}
+Dialogue: 0,0:01:07.16,0:01:07.16,Default,,0,0,0,,\N스타크 가문과 라니스터 가문이죠
+Dialogue: 0,0:01:07.16,0:01:10.04,Default,,0,0,0,,\NHouse Stark and House
Lannister.
+Dialogue: 0,0:01:10.16,0:01:10.16,Default,,0,0,0,,\N그 외에 여러 가문이\N서로 경쟁합니다
+Dialogue: 0,0:01:10.16,0:01:13.25,Default,,0,0,0,,\NThe other major houses
are\Nall contenders as well.
+Dialogue: 0,0:01:13.37,0:01:13.37,Default,,0,0,0,,\N흥미진진하게 정치적으로\N얽혀있는 상황이죠
+Dialogue: 0,
Re: [FFmpeg-devel] [PATCH 4/4] fate reference for samidec
Hello,
Sorry, I didn't mean to spam the mailing list...I noticed that commit
message was not quite right.. Sample file is attached for this
reference. (again) And besides these messages (title on these previous
3 email), nothing is changed from previous patches.
Thank you for reviewing and have a super wonderful day!!
Yayoi
On Fri, Aug 7, 2015 at 11:03 PM, Yayoi wrote:
> ---
> tests/fate/subtitles.mak | 3 ++
> tests/ref/fate/sub-sami2 | 91
>
> 2 files changed, 94 insertions(+)
> create mode 100644 tests/ref/fate/sub-sami2
>
> diff --git a/tests/fate/subtitles.mak b/tests/fate/subtitles.mak
> index d8b2034..0a6c33d 100644
> --- a/tests/fate/subtitles.mak
> +++ b/tests/fate/subtitles.mak
> @@ -46,6 +46,9 @@ fate-sub-realtext: CMD = fmtstdout ass -i
> $(TARGET_SAMPLES)/sub/RealText_capabil
> FATE_SUBTITLES_ASS-$(call DEMDEC, SAMI, SAMI) += fate-sub-sami
> fate-sub-sami: CMD = fmtstdout ass -i
> $(TARGET_SAMPLES)/sub/SAMI_capability_tester.smi
>
> +FATE_SUBTITLES_ASS-$(call DEMDEC, SAMI, SAMI) += fate-sub-sami2
> +fate-sub-sami2: CMD = fmtstdout ass -i
> $(TARGET_SAMPLES)/sub/SAMI_ass_capability_tester.smi
> +
> FATE_SUBTITLES_ASS-$(call DEMDEC, SRT, SUBRIP) += fate-sub-srt
> fate-sub-srt: CMD = fmtstdout ass -i
> $(TARGET_SAMPLES)/sub/SubRip_capability_tester.srt
>
> diff --git a/tests/ref/fate/sub-sami2 b/tests/ref/fate/sub-sami2
> new file mode 100644
> index 000..5703652
> --- /dev/null
> +++ b/tests/ref/fate/sub-sami2
> @@ -0,0 +1,91 @@
> +[Script Info]
> +; Script generated by FFmpeg/Lavc
> +ScriptType: v4.00+
> +PlayResX: 384
> +PlayResY: 288
> +
> +[V4+ Styles]
> +Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour,
> OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX,
> ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL,
> MarginR, MarginV, Encoding
> +Style:
> Default,Arial,16,&Hff,&Hff,&H0,&H0,0,0,0,0,100,100,0,0,1,1,0,2,10,10,10,0
> +
> +[Events]
> +Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect,
> Text
> +Dialogue: 0,0:00:01.51,0:00:01.51,Default,,0,0,0,,by Psyence
> Fictionist\npsyencefiction...@gmail.com
> +Dialogue: 0,0:00:01.51,0:00:08.61,Default,,0,0,0,,Sync by: honeybunny and
> Kerensky\Nwww.Addic7ed.com
> +Dialogue: 0,0:00:10.11,0:00:10.11,Default,,0,0,0,,\N{\b1}사랑과 배신\N탐욕과 살육의
> 이야기죠{\b0}
> +Dialogue:
> 0,0:00:10.11,0:00:13.98,Default,,0,0,0,,\N{\c&H800080&}The{\c}{\c&HCBC0FF&}re{\c}
> {\c&HFF&}is{\c} {\c&HA5FF&}lo{\c}{\c&H&}ve{\c}
> {\c&H8000&}and{\c}{\c&H00&}
> bet{\c}{\c&HFF&}rayal{\c},\N{\b1}{\c&H808080&}g{\c}r{\c&H808080&}e{\c}e{\c&H808080&}d{\c}
> and {\c&HFF&}m{\c}{\c&H808080&}u{\c}{\c&HFF&}rder{\c}{\b0}.
> +Dialogue: 0,0:00:17.67,0:00:17.67,Default,,0,0,0,,\N{\c&H&}선악의 정의에
> 대해서\N대립하는 가치관을 가진{\c}
> +Dialogue:
> 0,0:00:17.67,0:00:21.72,Default,,0,0,0,,\N{\c&HCBC0FF&}{\fs6}It's{\fs}
> {\fs8}set{\fs}{\fs10} in {\fs}{\fs12}this{\fs}{\fs14}
> intere{\fs}{\fs14}sting{\fs}\N{\fs16} world{\fs}{\fs18} of{\fs}
> {\fs20}cont{\fs}{\fs22}rasting{\fs}{\fs24} ideology{\fs}{\c}
> +Dialogue: 0,0:00:21.84,0:00:21.84,Default,,0,0,0,,\N{\u1}매력적인 세계에서\N이 모든 것이
> 펼쳐집니다{\u1}
> +Dialogue:
> 0,0:00:21.84,0:00:23.58,Default,,0,0,0,,\N{\i1}{\c&H9966CC&}of{\c}{\c&HC2A3E0&}
> what's{\c} {\c&HE0D1F0&}right{\c} {\c&HFCFAFE&}and{\c} wrong.{\i0}
> +Dialogue: 0,0:00:23.69,0:00:23.69,Default,,0,0,0,,\N{\i1}이 주제를 심오한
> 철학으로\N담아내고 있어요{\i0}
> +Dialogue:
> 0,0:00:23.69,0:00:25.67,Default,,0,0,0,,\N{\fs20}{\c&HFF&}{\s1}It{\s0}{\c}{\fs}
> has {\fs15}{\c&H00&}a{\c}{\fs} great
> {\fs16}{\c&HFFCC00&}philosophy{\c}{\fs} about it.
> +Dialogue: 0,0:00:40.22,0:00:40.22,Default,,0,0,0,,\N{\s1}"왕좌의 게임"은 웨스테로스라는
> 가상왕국의\N권력 분쟁 이야기입니다{\s0}
> +Dialogue: 0,0:00:40.22,0:00:47.94,Default,,0,0,0,,\N{\c&HA5FF&}{\fs26}"Game
> of Thrones"{\fs}{\c} {\c&H2A2AA5&}{\b1}is{\b0}{\c}{\c&H&}{\fs24}{\i1}
> about{\i0}{\fs}{\c} {\c&H336699&}{\fs14}power{\fs}{\c}{\c&HFF&}
> struggles{\c}\N{\c&HA5FF&}{\fs8}in a fantasy{\fs}{\c&HCBC0FF&}
> kingdom{\c&HA5FF&}, called {\fs6}Westeros.{\fs}{\c}
> +Dialogue: 0,0:00:48.06,0:00:48.06,Default,,0,0,0,,\N철의 왕좌를 둘러싼\N권력 분쟁이죠
> +Dialogue: 0,0:00:48.06,0:00:50.76,Default,,0,0,0,,\N{\c&H8000&}And it's a
> power struggle\Nfor the Iron Throne,{\c}
> +Dialogue: 0,0:00:50.88,0:00:50.88,Default,,0,0,0,,\N{\fs20}왕국의 권력 정점이라고\N할 수
> 있는 자리에요{\fs}
> +Dialogue: 0,0:00:50.88,0:00:53.13,Default,,0,0,0,,\Nwhich is the seat of
> power\Nin this kingdom.
> +Dialogue: 0,0:00:53.25,0:00:53.25,Default,,0,0,0,,\N전운이 감도네, 네드
> +Dialogue: 0,0:00:53.25,0:00:55.07,Default,,0,0,0,,\NThere's a war coming,
> Ned.
> +Dialogue: 0,0:00:56.01,0:00:56.01,Default,,0,0,0,,\N\N언제 누구와 싸우게 될지는 몰라\N하지만
> 분명 전쟁이 일어날걸세
> +Dialogue: 0,0:00:56.01,0:01:00.09,Default,,0,0,0,,\NI don't know when, I
> don't know who\Nwould be fighting, but it's coming.
> +Dialogue: 0,0:01:01.10,0:01:01.10,Default,,0,0,0,,\N이야기의 핵심은 두 주요 가문의\N권력을
> 둘러싼 갈등입니다
>
