[FFmpeg-devel] avformat/hlsenc: pull request for single file mode
Hi, The hlsenc muxer only supports HLS version 3, and I needed byterange support (version 4), so I added it :) You will find a pull request on Github (hlsenc branch): https://github.com/FFmpeg/FFmpeg/pull/76 There are four patches. Two fix small issues in the muxer (target duration computation and default subtitles format), the other two clean the muxer and add a single file mode. I tested my patches with and without the new single file mode, on media files with and without video streams. This is my first work on FFmpeg, so feel free to point any mistake. Note that the work was done for my job, and the company I work for officially authorizeded me to contribute to FFmpeg under the terms of its license. Regards, -- Nicolas Martyanoff http://wandrian.net khae...@gmail.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avformat/hlsenc: pull request for single file mode
Nicolas Martyanoff gmail.com> writes: > default subtitles format This patch is not ok (just reencode a random file with subtitles to find out) and I don't think "HLS streams must use the WebVTT subtitle format." is true. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avformat/hlsenc: pull request for single file mode
On 2014-07-09 10:09, Carl Eugen Hoyos wrote: > Nicolas Martyanoff gmail.com> writes: > > > default subtitles format > > This patch is not ok (just reencode a random file > with subtitles to find out) You are right, you cannot just transcode a dvdsub stream into a webvtt one. I'll remove the patch. > and I don't think "HLS streams must use the WebVTT subtitle format." > is true. http://tools.ietf.org/html/draft-pantos-http-live-streaming-13 -- Nicolas Martyanoff http://wandrian.net khae...@gmail.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avformat/hlsenc: pull request for single file mode
I added a new patch to the pull request, introducing a flag to disable filenames in segment names: https://github.com/galdor/FFmpeg/commit/246bccaee75aea8ae5a46145bb38ff8071e5f6ef -- Nicolas Martyanoff http://wandrian.net khae...@gmail.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] hls: add underlying format option for hls input format
Hi,
By default, hls will autodetect the input format of the downloaded segments.
This new option allows to force some specific format, which is useful for
hardware decoders that accept only TS (by supplying
hls_force_input_format="mpegtsraw" option to avformat_open_input).
The situation has been mentioned in the FFmpeg-users mailing list, so
this patch might be useful:
https://lists.ffmpeg.org/pipermail/ffmpeg-user/2013-October/018306.html
This option should probably be documented somewhere, but I failed to
find an appropriate place. Please comment, so I can update the patch.
Thanks,
Ivan
Signed-off-by: Ivan Grokhotkov
---
libavformat/hls.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 3897723..7ed5fc0 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -1318,6 +1318,7 @@ static int hls_read_header(AVFormatContext *s)
for (i = 0; i < c->n_playlists; i++) {
struct playlist *pls = c->playlists[i];
AVInputFormat *in_fmt = NULL;
+AVDictionaryEntry *dict_entry;
if (pls->n_segments == 0)
continue;
@@ -1336,6 +1337,12 @@ static int hls_read_header(AVFormatContext *s)
ffio_init_context(&pls->pb, pls->read_buffer, INITIAL_BUFFER_SIZE, 0,
pls,
read_data, NULL, NULL);
pls->pb.seekable = 0;
+
+dict_entry = av_dict_get(s->metadata, "hls_force_input_format", NULL,
0);
+if (dict_entry){
+in_fmt = av_find_input_format(dict_entry->value);
+}
+
ret = av_probe_input_buffer(&pls->pb, &in_fmt, pls->segments[0]->url,
NULL, 0, 0);
if (ret < 0) {
--
1.8.4.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] AVFoundation: Add -pixel_format option
This broke compiling on OS X < 10.8 (I am on 10.7)
clang -I. -I/src/ffmpeg/ -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -DPIC -DHAVE_AV_CONFIG_H -I/sw/include -std=c99
-fomit-frame-pointer -fPIC -pthread -I/sw/include -I/sw/include
-I/sw/include/bs2b -I/sw/include -I/sw/include/freetype2 -I/sw/include
-I/sw/include/opus -I/sw/include -I/sw/include
-I/sw/include/schroedinger-1.0 -I/sw/include/liboil-0.3 -I/sw/include
-I/sw/include -I/sw/include -I/sw/include -I/sw/include/SDL
-D_GNU_SOURCE=1 -D_THREAD_SAFE -g -Wdeclaration-after-statement -Wall
-Wdisabled-optimization -Wpointer-arith -Wredundant-decls
-Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes
-Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body
-Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign
-O3 -fno-math-errno -fno-signed-zeros -Qunused-arguments
-Werror=implicit-function-declaration -Werror=missing-prototypes
-Werror=return-type -MMD -MF libavdevice/avfoundation.d -MT
libavdevice/avfoundation.o -c -o libavdevice/avfoundation.o
/src/ffmpeg/libavdevice/avfoundation.m
/src/ffmpeg/libavdevice/avfoundation.m:73:32: error: use of undeclared
identifier 'kCVPixelFormatType_OneComponent8'
{ AV_PIX_FMT_GRAY8,kCVPixelFormatType_OneComponent8 },
^
1 error generated.
https://developer.apple.com/library/mac/documentation/QuartzCore/Reference/CVPixelFormatDescriptionRef/Reference/reference.html
says that kCVPixelFormatType_OneComponent8 is 10.8+ only.
Possible configure patch (it successfully deactivates the avfoundation
indev on 10.7, but I get lots of general C errors in config.log rather
than just undeclared kCVPixelFormatType_OneComponent8 like I was
expecting) ?:
8< 8< 8< 8<
diff --git a/configure b/configure
index e20bf8e..395fb7d 100755
--- a/configure
+++ b/configure
@@ -4695,7 +4695,7 @@ for func in $MATH_FUNCS; do
done
# these are off by default, so fail if requested and not available
-enabled avfoundation_indev && { check_header_oc
AVFoundation/AVFoundation.h || disable avfoundation_indev; }
+enabled avfoundation_indev && { check_lib2
AVFoundation/AVFoundation.h kCVPixelFormatType_OneComponent8
-Wl,-framework,AVFoundation || disable avfoundation_indev; }
enabled avisynth && { { check_lib2 "windows.h" LoadLibrary; } ||
{ check_lib2 "dlfcn.h" dlopen -ldl; } ||
die "ERROR: LoadLibrary/dlopen not
found for avisynth"; }
8< 8< 8< 8<
--
Disclaimer:
By sending an email to ANY of my addresses you are agreeing that:
1. I am by definition, "the intended recipient"
2. All information in the email is mine to do with as I see fit and
make such financial profit, political mileage, or good joke as it
lends itself to.
3. I may take the contents as representing the views of your company.
4. This overrides any disclaimer or statement of confidentiality that
may be included with your message.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hls: add underlying format option for hls input format
On Wed, Jul 09, 2014 at 03:23:01PM +0400, Ivan Grokhotkov wrote:
> Hi,
>
> By default, hls will autodetect the input format of the downloaded segments.
> This new option allows to force some specific format, which is useful for
> hardware decoders that accept only TS (by supplying
> hls_force_input_format="mpegtsraw" option to avformat_open_input).
>
> The situation has been mentioned in the FFmpeg-users mailing list, so
> this patch might be useful:
> https://lists.ffmpeg.org/pipermail/ffmpeg-user/2013-October/018306.html
>
> This option should probably be documented somewhere, but I failed to
> find an appropriate place. Please comment, so I can update the patch.
>
>
> Thanks,
> Ivan
>
>
> Signed-off-by: Ivan Grokhotkov
> ---
> libavformat/hls.c | 7 +++
> 1 file changed, 7 insertions(+)
>
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 3897723..7ed5fc0 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -1318,6 +1318,7 @@ static int hls_read_header(AVFormatContext *s)
> for (i = 0; i < c->n_playlists; i++) {
> struct playlist *pls = c->playlists[i];
> AVInputFormat *in_fmt = NULL;
> +AVDictionaryEntry *dict_entry;
>
> if (pls->n_segments == 0)
> continue;
> @@ -1336,6 +1337,12 @@ static int hls_read_header(AVFormatContext *s)
> ffio_init_context(&pls->pb, pls->read_buffer, INITIAL_BUFFER_SIZE, 0,
> pls,
> read_data, NULL, NULL);
> pls->pb.seekable = 0;
> +
> +dict_entry = av_dict_get(s->metadata, "hls_force_input_format",
> NULL, 0);
> +if (dict_entry){
> +in_fmt = av_find_input_format(dict_entry->value);
> +}
this should be using AVOptions like other demuxers not metadata
documentation could be put in doc/demuxers.texi
[...]
--
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] AVFormat: LRC demuxer and muxer
LRC is widely used to represent music lyrics.
It is useful to have lavf decode LRC during playback or transcode it to
other subtitle formats.
I know there once was a rejected patch here:
http://ffmpeg.org/pipermail/ffmpeg-devel/2010-December/084342.html
So this is why I rewrote another implementation.
This demuxer and muxer implementation supports multiple timestamp tags
and offset handling, which does not exist in Peter Ross's one mentioned
above.
From 64686e1d8e9dd77ad1830f715d5a0485c8d81aa9 Mon Sep 17 00:00:00 2001
From: Star Brilliant
Date: Wed, 9 Jul 2014 14:24:05 +0800
Subject: [PATCH] AVFormat: LRC demuxer and muxer
---
Changelog| 1 +
doc/general.texi | 1 +
libavformat/Makefile | 2 +
libavformat/allformats.c | 1 +
libavformat/lrc.h| 38
libavformat/lrcdec.c | 220
+++
libavformat/lrcenc.c | 132
7 files changed, 395 insertions(+)
create mode 100644 libavformat/lrc.h
create mode 100644 libavformat/lrcdec.c
create mode 100644 libavformat/lrcenc.c
diff --git a/Changelog b/Changelog
index fa443dc..75bde5b 100644
--- a/Changelog
+++ b/Changelog
@@ -29,6 +29,7 @@ version :
- showcqt multimedia filter
- zoompan filter
- signalstats filter
+- LRC demuxer and muxer
version 2.2:
diff --git a/doc/general.texi b/doc/general.texi
index 86569a2..c008261 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -310,6 +310,7 @@ library:
@tab Used by Linux Media Labs MPEG-4 PCI boards
@item LOAS @tab @tab X
@tab contains LATM multiplexed AAC audio
+@item LRC @tab X @tab X
@item LVF @tab @tab X
@item LXF @tab @tab X
@tab VR native stream format, used by Leitch/Harris' video servers.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index ecae4d0..05f5fcd 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -202,6 +202,8 @@ OBJS-$(CONFIG_LATM_DEMUXER) += rawdec.o
OBJS-$(CONFIG_LATM_MUXER)+= latmenc.o rawenc.o
OBJS-$(CONFIG_LMLM4_DEMUXER) += lmlm4.o
OBJS-$(CONFIG_LOAS_DEMUXER) += loasdec.o rawdec.o
+OBJS-$(CONFIG_LRC_DEMUXER) += lrcdec.o subtitles.o
+OBJS-$(CONFIG_LRC_MUXER) += lrcenc.o
OBJS-$(CONFIG_LVF_DEMUXER) += lvfdec.o
OBJS-$(CONFIG_LXF_DEMUXER) += lxfdec.o
OBJS-$(CONFIG_M4V_DEMUXER) += m4vdec.o rawdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index dc5557c..fff05ee 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -163,6 +163,7 @@ void av_register_all(void)
REGISTER_MUXDEMUX(LATM, latm);
REGISTER_DEMUXER (LMLM4,lmlm4);
REGISTER_DEMUXER (LOAS, loas);
+REGISTER_MUXDEMUX(LRC, lrc);
REGISTER_DEMUXER (LVF, lvf);
REGISTER_DEMUXER (LXF, lxf);
REGISTER_MUXDEMUX(M4V, m4v);
diff --git a/libavformat/lrc.h b/libavformat/lrc.h
new file mode 100644
index 000..831a9cf
--- /dev/null
+++ b/libavformat/lrc.h
@@ -0,0 +1,38 @@
+/*
+ * LRC lyrics file format decoder
+ * Copyright (c) 2014 StarBrilliant
+ *
+ * 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
+ */
+
+#ifndef AVFORMAT_LRC_H
+#define AVFORMAT_LRC_H
+
+#include "metadata.h"
+
+static const AVMetadataConv ffpriv_lrc_metadata_conv[] = {
+{"ti", "title"},
+{"al", "album"},
+{"ar", "artist"},
+{"au", "author"},
+{"by", "creator"},
+{"re", "encoder"},
+{"ve", "encoder_version"},
+{0, 0}
+};
+
+#endif
diff --git a/libavformat/lrcdec.c b/libavformat/lrcdec.c
new file mode 100644
index 000..cf9f956
--- /dev/null
+++ b/libavformat/lrcdec.c
@@ -0,0 +1,220 @@
+/*
+ * LRC lyrics file format decoder
+ * Copyright (c) 2014 StarBrilliant
+ *
+ * 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 distri
Re: [FFmpeg-devel] add hls muxer support extra entries outside m3u8playlist
On Mon, May 19, 2014 at 10:36:48AM +0800, 740936897 wrote:
> HI, all:
> currently, HLS muxer does't support to remove segment file, only hls_wrap is
> set.
> if hls_wrap is set, the segment number will cycle, eg, from 0~10.
> if hls_wrap is not set, the segment number will increase continuously, but
> result to many many segment files.
> I fix this problem, add a HLS muxer option : hls_extra_size.
> if segment file size > (hls_extra_size + hls_list_size), segment file will
> be removed.
>
>
> follow is the content of patch. forgive my poor english ^_^
>
>
>
> From 774743cfd112ed164858359e06292035ae0932cf Mon Sep 17 00:00:00 2001
> From: wenjie.zhao
> Date: Sat, 17 May 2014 08:57:34 +0800
> Subject: [PATCH] add hls muxer support extra entries outside m3u8 playlist
> this extra entries will be deleted later.
>
>
> ---
> libavformat/hlsenc.c | 31 +--
> 1 files changed, 29 insertions(+), 2 deletions(-)
>
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 1b5ef0e..041a288 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -21,6 +21,7 @@
>
> #include
> #include
> +#include
>
> #include "libavutil/mathematics.h"
> #include "libavutil/parseutils.h"
> @@ -33,6 +34,7 @@
>
> typedef struct ListEntry {
> char name[1024];
> +char filename[1024]; // segment file path
> int duration;
> struct ListEntry *next;
> } ListEntry;
> @@ -54,6 +56,13 @@ typedef struct HLSContext {
> int nb_entries;
> ListEntry *list;
> ListEntry *end_list;
> +
> +// extra entries size
> +int extra_size;
> +ListEntry *extra_list;
> +ListEntry *extra_end_list;
> +int nb_extra_entries;
> +
> char *basename;
> AVIOContext *pb;
> } HLSContext;
> @@ -91,6 +100,7 @@ static int append_entry(HLSContext *hls, uint64_t duration)
> return AVERROR(ENOMEM);
>
> av_strlcpy(en->name, av_basename(hls->avf->filename), sizeof(en->name));
> +av_strlcpy(en->filename, hls->avf->filename, sizeof(en->filename));
>
> en->duration = duration;
> en->next = NULL;
> @@ -105,7 +115,23 @@ static int append_entry(HLSContext *hls, uint64_t
> duration)
> if (hls->size && hls->nb_entries >= hls->size) {
> en = hls->list;
> hls->list = en->next;
> -av_free(en);
> +if (!hls->extra_list)
> +hls->extra_list = en;
> +else
> +hls->extra_end_list->next = en;
> +
> +hls->extra_end_list = en;
> +hls->nb_extra_entries ++;
> +
> +if (hls->extra_size && hls->nb_extra_entries > hls->extra_size) {
> +en = hls->extra_list;
> +hls->extra_list = en->next;
> +
> +// remove useless file
> +unlink(en->filename);
thats not ok, you dont know if its a local file
it could be anything thats supported by AVIO / URLProtocols
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AVFoundation: Add -pixel_format option
Hanspeter Niederstrasser gmail.com> writes:
> -enabled avfoundation_indev && { check_header_oc
> AVFoundation/AVFoundation.h || disable avfoundation_indev; }
> +enabled avfoundation_indev && { check_lib2
> AVFoundation/AVFoundation.h kCVPixelFormatType_OneComponent8
Put an "#ifdef kCVPixelFormatType_OneComponent8" around
the usage as done in libavformat/v4l2-common.c (if it works).
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AVFormat: LRC demuxer and muxer
Star Brilliant hotmail.com> writes:
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
It looks as if your mailer broke the patch, consider
to attach the patch.
(Sorry if I am wrong on this.)
> +static const AVMetadataConv ffpriv_lrc_metadata_conv[] = {
This should not be part of a header (it gets duplicated).
Please use a C file lrc.c that only contains this
symbol and define it in the header.
> +if(p[offset] && p[offset] == '[' &&
> + p[offset + 1] >= 'a' && p[offset + 1] <= 'z')
> +return offset;
> +else
> +return -1;
You may ignore this:
Since it makes future patches smaller, some developers
prefer:
if(p[offset]...) {
return offset;
} else {
return -1;
}
> +if(!memcmp(p->buf + offset, "[ti:", 4) ||
> + !memcmp(p->buf + offset, "[al:", 4) ||
> + !memcmp(p->buf + offset, "[ar:", 4))
> +return AVPROBE_SCORE_MAX;
MAX score is not ok for 32bit, use MAX/2 (or less).
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avformat/hlsenc: pull request for single file mode
I added a new patch to the pull request, introducing a '-hls_media_filename' option to provide a filename (in single file mode) or a filename pattern (in default mode). https://github.com/galdor/FFmpeg/commit/cd45075eed0444ae0fd2410a8784bc472b315341 -- Nicolas Martyanoff http://wandrian.net khae...@gmail.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AVFoundation: Add -pixel_format option
Carl Eugen Hoyos ag.or.at> writes: > Put an "#ifdef kCVPixelFormatType_OneComponent8" around > the usage as done in libavformat/v4l2-common.c (if it works). I suspect it does not work, perhaps you can find the right incantation? (__MAC_OS_X_VERSION_MAX_ALLOWED > 1080 ?) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AVFormat: LRC demuxer and muxer
On 2014-07-09 21:42, Carl Eugen Hoyos wrote:
It looks as if your mailer broke the patch, consider
to attach the patch.
(Sorry if I am wrong on this.)
I am really sorry that I misconfigured my Thunderbird.
So I attached my patch.
I fixed things you mentioned in the last mail.
Thanks.
>From a978f99b96bb406ab50d28e3aab09bcc149aa184 Mon Sep 17 00:00:00 2001
From: Star Brilliant
Date: Wed, 9 Jul 2014 14:24:05 +0800
Subject: [PATCH] AVFormat: LRC demuxer and muxer
---
Changelog| 1 +
doc/general.texi | 1 +
libavformat/Makefile | 2 +
libavformat/allformats.c | 1 +
libavformat/lrc.c| 34 +++
libavformat/lrc.h| 29 ++
libavformat/lrcdec.c | 238 +++
libavformat/lrcenc.c | 141
8 files changed, 447 insertions(+)
create mode 100644 libavformat/lrc.c
create mode 100644 libavformat/lrc.h
create mode 100644 libavformat/lrcdec.c
create mode 100644 libavformat/lrcenc.c
diff --git a/Changelog b/Changelog
index fa443dc..75bde5b 100644
--- a/Changelog
+++ b/Changelog
@@ -29,6 +29,7 @@ version :
- showcqt multimedia filter
- zoompan filter
- signalstats filter
+- LRC demuxer and muxer
version 2.2:
diff --git a/doc/general.texi b/doc/general.texi
index 86569a2..c008261 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -310,6 +310,7 @@ library:
@tab Used by Linux Media Labs MPEG-4 PCI boards
@item LOAS @tab @tab X
@tab contains LATM multiplexed AAC audio
+@item LRC @tab X @tab X
@item LVF @tab @tab X
@item LXF @tab @tab X
@tab VR native stream format, used by Leitch/Harris' video servers.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index ecae4d0..3218c4c 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -202,6 +202,8 @@ OBJS-$(CONFIG_LATM_DEMUXER) += rawdec.o
OBJS-$(CONFIG_LATM_MUXER)+= latmenc.o rawenc.o
OBJS-$(CONFIG_LMLM4_DEMUXER) += lmlm4.o
OBJS-$(CONFIG_LOAS_DEMUXER) += loasdec.o rawdec.o
+OBJS-$(CONFIG_LRC_DEMUXER) += lrcdec.o lrc.o subtitles.o
+OBJS-$(CONFIG_LRC_MUXER) += lrcenc.o lrc.o
OBJS-$(CONFIG_LVF_DEMUXER) += lvfdec.o
OBJS-$(CONFIG_LXF_DEMUXER) += lxfdec.o
OBJS-$(CONFIG_M4V_DEMUXER) += m4vdec.o rawdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index dc5557c..fff05ee 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -163,6 +163,7 @@ void av_register_all(void)
REGISTER_MUXDEMUX(LATM, latm);
REGISTER_DEMUXER (LMLM4,lmlm4);
REGISTER_DEMUXER (LOAS, loas);
+REGISTER_MUXDEMUX(LRC, lrc);
REGISTER_DEMUXER (LVF, lvf);
REGISTER_DEMUXER (LXF, lxf);
REGISTER_MUXDEMUX(M4V, m4v);
diff --git a/libavformat/lrc.c b/libavformat/lrc.c
new file mode 100644
index 000..67eeede
--- /dev/null
+++ b/libavformat/lrc.c
@@ -0,0 +1,34 @@
+/*
+ * LRC lyrics file format decoder
+ * Copyright (c) 2014 StarBrilliant
+ *
+ * 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 "metadata.h"
+#include "lrc.h"
+
+const AVMetadataConv ffpriv_lrc_metadata_conv[] = {
+{"ti", "title"},
+{"al", "album"},
+{"ar", "artist"},
+{"au", "author"},
+{"by", "creator"},
+{"re", "encoder"},
+{"ve", "encoder_version"},
+{0, 0}
+};
diff --git a/libavformat/lrc.h b/libavformat/lrc.h
new file mode 100644
index 000..93274d5
--- /dev/null
+++ b/libavformat/lrc.h
@@ -0,0 +1,29 @@
+/*
+ * LRC lyrics file format decoder
+ * Copyright (c) 2014 StarBrilliant
+ *
+ * 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
Re: [FFmpeg-devel] [PATCH] AVFormat: LRC demuxer and muxer
On 7/9/2014 2:42 PM, Carl Eugen Hoyos wrote: >> +if(!memcmp(p->buf + offset, "[ti:", 4) || >> + !memcmp(p->buf + offset, "[al:", 4) || >> + !memcmp(p->buf + offset, "[ar:", 4)) >> +return AVPROBE_SCORE_MAX; > > MAX score is not ok for 32bit, use MAX/2 (or less). Too elaborate on this, since Carl worded it very poorly (it sounds like he is talking about 32bit vs 64bit archs): libavformat apparently has 'strong' and 'weak' probes, and you are only allowed to use MAX/2 for 'weak' probes. Checking only 4 bytes (32 bits) is considered weak, and thus limited to MAX/2. I hope that makes it a tad clearer. Cheers, - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AVFormat: LRC demuxer and muxer
> +/*
> + * LRC lyrics file format decoder
> + * Copyright (c) 2014 StarBrilliant
For copyright purposes we generally use real names.
> +#include "libavcodec/internal.h"
Ew. What are you using from this?
> +#include "libavutil/bprint.h"
> +#include "libavutil/dict.h"
> +
> +typedef struct LRCContext {
> +FFDemuxSubtitlesQueue q;
> +int ts_offset;
Is int enough for a timestamp difference?
> +if(sscanf(p, "[-%d:%d.%d]", &mm, &ss, &cs) == 3) {\
'-' is a printf/scanf modifier, I'm not sure this will work.
> +*start = -(mm*6LL + ss*1000LL + cs*10LL); // just in case
> negative pts
Why are you mangling the timestamps? Negative timestamps are technically valid.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AVFormat: LRC demuxer and muxer
On 7/9/2014 3:24 PM, Derek Buitenhuis wrote: > '-' is a printf/scanf modifier, I'm not sure this will work. Sorry, ignore this part. It's before the % so it will obviously work. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AVFormat: LRC demuxer and muxer
于 2014年07月09日 22:24, Derek Buitenhuis 写道:
+/*
+ * LRC lyrics file format decoder
+ * Copyright (c) 2014 StarBrilliant
For copyright purposes we generally use real names.
Thank you for your reminder.
But I consider my real name piracy.
If this really causes trouble to FFmpeg team, I will change it.
+#include "libavcodec/internal.h"
Ew. What are you using from this?
I copied this line from assdec.c, I used to think it is useful.
Removing it is okay.
+#include "libavutil/bprint.h"
+#include "libavutil/dict.h"
+
+typedef struct LRCContext {
+FFDemuxSubtitlesQueue q;
+int ts_offset;
Is int enough for a timestamp difference?
bprint is used for string and buffer manipulation. Again this #include
is adapted from assdec.c.
timestamp difference is far from enough, since LRC comes with arbitrary
line order.
Another reason is repeated line feature. LRC can have single line that
is sung multiple times assigned with different timestamps.
This is why I use FFDemuxSubtitlesQueue to sort those lines.
ts_offset is a metadata item. By specifying "offset" in metadata, the
whole lyrics would shift in timestamps to get sync with different
versions of music.
My implementation does offset shifting on demuxing. So I have to keep a
ts_offset member.
+*start = -(mm*6LL + ss*1000LL + cs*10LL); // just in case negative
pts
Why are you mangling the timestamps? Negative timestamps are technically valid.
Negative timestamps are not effective in real LRCs. However, with the
feature called "offset" mentioned just above. A normal timestamp can
easily become negative.
Since most players ignore uneffective lines (LRC has no official spec,
it is a de-facto standard). So I will let the players drop those
negative timestamps, instead of losing data at FFmpeg layer.
Finally, I attached an incremental patch, fixing an #include issue and a
mistype.
>From 09ec0f4f8d26a6da760694bc35f6530952915933 Mon Sep 17 00:00:00 2001
From: Star Brilliant
Date: Wed, 9 Jul 2014 22:52:12 +0800
Subject: [PATCH] AVFormat: LRC demuxer and muxer
---
libavformat/lrcdec.c | 3 +--
libavformat/lrcenc.c | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavformat/lrcdec.c b/libavformat/lrcdec.c
index 49bdd13..373c2ac 100644
--- a/libavformat/lrcdec.c
+++ b/libavformat/lrcdec.c
@@ -27,7 +27,6 @@
#include "lrc.h"
#include "metadata.h"
#include "subtitles.h"
-#include "libavcodec/internal.h"
#include "libavutil/bprint.h"
#include "libavutil/dict.h"
@@ -195,7 +194,7 @@ static int lrc_read_header(AVFormatContext *s)
return AVERROR(ENOMEM);
}
sub->pos = pos;
-sub->pts = ts_start + lrc->ts_offset*1LL;
+sub->pts = ts_start - lrc->ts_offset*1LL;
sub->duration = -1;
}
}
diff --git a/libavformat/lrcenc.c b/libavformat/lrcenc.c
index b874b77..6fae053 100644
--- a/libavformat/lrcenc.c
+++ b/libavformat/lrcenc.c
@@ -28,7 +28,6 @@
#include "metadata.h"
#include "subtitles.h"
#include "version.h"
-#include "libavcodec/internal.h"
#include "libavutil/bprint.h"
#include "libavutil/dict.h"
#include "libavutil/log.h"
--
2.0.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AVFormat: LRC demuxer and muxer
On 7/9/2014 3:55 PM, Star Brilliant wrote:
>>> +#include "libavutil/bprint.h"
>>> +#include "libavutil/dict.h"
>>> +
>>> +typedef struct LRCContext {
>>> +FFDemuxSubtitlesQueue q;
>>> +int ts_offset;
>>
>> Is int enough for a timestamp difference?
>
> bprint is used for string and buffer manipulation. Again this #include
> is adapted from assdec.c.
>
> timestamp difference is far from enough, since LRC comes with arbitrary
> line order.
> Another reason is repeated line feature. LRC can have single line that
> is sung multiple times assigned with different timestamps.
> This is why I use FFDemuxSubtitlesQueue to sort those lines.
>
> ts_offset is a metadata item. By specifying "offset" in metadata, the
> whole lyrics would shift in timestamps to get sync with different
> versions of music.
> My implementation does offset shifting on demuxing. So I have to keep a
> ts_offset member.
You misunderstand what I am asking. int may be 32bits, and timestamps generate
64.
is LRC guaranteed to only have 32bit timestamps?
>>> +*start = -(mm*6LL + ss*1000LL + cs*10LL); // just in case
>>> negative pts
>>
>> Why are you mangling the timestamps? Negative timestamps are technically
>> valid.
>
> Negative timestamps are not effective in real LRCs. However, with the
> feature called "offset" mentioned just above. A normal timestamp can
> easily become negative.
> Since most players ignore uneffective lines (LRC has no official spec,
> it is a de-facto standard). So I will let the players drop those
> negative timestamps, instead of losing data at FFmpeg layer.
Sorry, I misunderstood the code. I thought you we're making it positive (double
negative -> positive).
That said, there is still a bug. %d will read negative integers already, you
do not need to check for '-'.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AVFormat: LRC demuxer and muxer
On 2014-07-09 23:09, Derek Buitenhuis wrote:
You misunderstand what I am asking. int may be 32bits, and timestamps generate
64.
is LRC guaranteed to only have 32bit timestamps?
I find no portable way to scanf a 64-bit integer in C90 standard.
sscanf(buf, "%" SCNd64, &ptr); is a C99 thing.
Does lavfutil provide something to read a 64-bit integer?
+*start = -(mm*6LL + ss*1000LL + cs*10LL); // just in case negative
pts
Why are you mangling the timestamps? Negative timestamps are technically valid.
Negative timestamps are not effective in real LRCs. However, with the
feature called "offset" mentioned just above. A normal timestamp can
easily become negative.
Since most players ignore uneffective lines (LRC has no official spec,
it is a de-facto standard). So I will let the players drop those
negative timestamps, instead of losing data at FFmpeg layer.
Sorry, I misunderstood the code. I thought you we're making it positive (double
negative -> positive).
That said, there is still a bug. %d will read negative integers already, you
do not need to check for '-'.
I check for negative before positive. Anyway, if I use only one sscanf,
I will have to do this:
if(sscanf(p, "[%d:%d.%d]", &mm, &ss, &cs) == 3) {
if(mm >= 0)
*start = mm*6LL + ss*1000LL + cs*10LL;
else
*start = mm*6LL - ss*1000LL - cs*10LL;
}
Which one do you think is better?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] Add libfribidi support to configure script
---
configure | 22 ++
1 file changed, 22 insertions(+)
diff --git a/configure b/configure
index e20bf8e..cb7d392 100755
--- a/configure
+++ b/configure
@@ -209,6 +209,7 @@ External library support:
--enable-libfdk-aac enable AAC de/encoding via libfdk-aac [no]
--enable-libfliteenable flite (voice synthesis) support via libflite
[no]
--enable-libfreetype enable libfreetype [no]
+ --enable-libfribidi enable libfribidi [no]
--enable-libgme enable Game Music Emu via libgme [no]
--enable-libgsm enable GSM de/encoding via libgsm [no]
--enable-libiec61883 enable iec61883 via libiec61883 [no]
@@ -1215,6 +1216,25 @@ require_libfreetype(){
add_extralibs $(get_safe ${pkg}_libs)
}
+require_libfribidi(){
+log require_libfribidi "$@"
+pkg="fribidi"
+check_cmd $pkg_config --exists --print-errors $pkg \
+ || die "ERROR: $pkg not found"
+pkg_cflags=$($pkg_config --cflags $pkg_config_flags $pkg)
+pkg_libs=$($pkg_config --libs $pkg_config_flags $pkg)
+{
+echo "#include "
+echo "char* check_func(void) { return (char*) fribidi_version_info; }"
+echo "int main(void) { return 0; }"
+} | check_ld "cc" $pkg_cflags $pkg_libs \
+ && set_safe ${pkg}_cflags $pkg_cflags \
+ && set_safe ${pkg}_libs $pkg_libs \
+ || die "ERROR: $pkg not found"
+add_cflags$(get_safe ${pkg}_cflags)
+add_extralibs $(get_safe ${pkg}_libs)
+}
+
hostcc_e(){
eval printf '%s\\n' $HOSTCC_E
}
@@ -1332,6 +1352,7 @@ EXTERNAL_LIBRARY_LIST="
libflite
libfontconfig
libfreetype
+libfribidi
libgme
libgsm
libiec61883
@@ -4719,6 +4740,7 @@ enabled libflite && require2 libflite
"flite/flite.h" flite_init $flite
enabled fontconfig&& enable libfontconfig
enabled libfontconfig && require_pkg_config fontconfig
"fontconfig/fontconfig.h" FcInit
enabled libfreetype && require_libfreetype
+enabled libfribidi&& require_libfribidi
enabled libgme&& require libgme gme/gme.h gme_new_emu -lgme
-lstdc++
enabled libgsm&& { for gsm_hdr in "gsm.h" "gsm/gsm.h"; do
check_lib "${gsm_hdr}" gsm_create -lgsm &&
break;
--
1.8.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] drawtext: Use libfribidi to correctly render Arabic text - Fixes ticket #3758
I've added this as a "fribidi=1" option to drawtext rather than enabling it by
default, so as not to break anything.
Difference can be seen by compiling with --enable-libfribidi and comparing:
ffplay -loglevel debug -f lavfi -i
"color=color=white,drawtext=fontfile=/usr/share/fonts/dejavu/DejaVuSans.ttf:text=أحمد"
ffplay -loglevel debug -f lavfi -i
"color=color=white,drawtext=fribidi=1:fontfile=/usr/share/fonts/dejavu/DejaVuSans.ttf:text=أحمد"
A slight note: This does create some -Wundef warnings on compilation, but
they're from libfribidi itself rather than this code.
I opted to leave them alone rather than start defining macros just to keep
things quiet, but if necessary that can be changed.
---
doc/filters.texi | 8 +++
libavfilter/vf_drawtext.c | 137 --
2 files changed, 139 insertions(+), 6 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index ada33a7..a9e7360 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -3653,6 +3653,8 @@ To enable compilation of this filter, you need to
configure FFmpeg with
@code{--enable-libfreetype}.
To enable default font fallback and the @var{font} option you need to
configure FFmpeg with @code{--enable-libfontconfig}.
+To enable the @var{fribidi} option, you need to configure FFmpeg with
+@code{--enable-libfribidi}.
@subsection Syntax
@@ -3707,6 +3709,9 @@ This parameter is mandatory if the fontconfig support is
disabled.
The font size to be used for drawing text.
The default value of @var{fontsize} is 16.
+@item fribidi
+If set to 1, pass the text through libfribidi before rendering. By default 0.
+
@item ft_load_flags
The flags to be used for loading the fonts.
@@ -4010,6 +4015,9 @@ For more information about libfreetype, check:
For more information about fontconfig, check:
@url{http://freedesktop.org/software/fontconfig/fontconfig-user.html}.
+For more information about libfribidi, check:
+@url{http://fribidi.org/}.
+
@section edgedetect
Detect and draw edges. The filter uses the Canny Edge Detection algorithm.
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index 0d829a6..ecdc569 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -59,6 +59,10 @@
#include "internal.h"
#include "video.h"
+#if CONFIG_LIBFRIBIDI
+#include
+#endif
+
#include
#include FT_FREETYPE_H
#include FT_GLYPH_H
@@ -182,6 +186,9 @@ typedef struct DrawTextContext {
int tc24hmax; ///< 1 if timecode is wrapped to 24 hours,
0 otherwise
int reload; ///< reload text file for each frame
int start_number; ///< starting frame number for n/frame_num
var
+#if CONFIG_LIBFRIBIDI
+int fribidi;///< 1 if using fribidi
+#endif
AVDictionary *metadata;
} DrawTextContext;
@@ -226,6 +233,10 @@ static const AVOption drawtext_options[]= {
{"fix_bounds", "if true, check and fix text coords to avoid clipping",
OFFSET(fix_bounds), AV_OPT_TYPE_INT, {.i64=1}, 0, 1, FLAGS},
{"start_number", "start frame number for n/frame_num variable",
OFFSET(start_number), AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX, FLAGS},
+#if CONFIG_LIBFRIBIDI
+{"fribidi", "pass text through libfribidi before rendering",
OFFSET(fribidi), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, FLAGS},
+#endif
+
/* FT_LOAD_* flags */
{ "ft_load_flags", "set font loading flags for libfreetype",
OFFSET(ft_load_flags), AV_OPT_TYPE_FLAGS, { .i64 = FT_LOAD_DEFAULT }, 0,
INT_MAX, FLAGS, "ft_load_flags" },
{ "default", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
FT_LOAD_DEFAULT }, .flags = FLAGS, .unit = "ft_load_flags"
},
@@ -482,6 +493,113 @@ static int load_textfile(AVFilterContext *ctx)
return 0;
}
+static inline int is_newline(uint32_t c)
+{
+return c == '\n' || c == '\r' || c == '\f' || c == '\v';
+}
+
+#if CONFIG_LIBFRIBIDI
+static int fribidi_text(AVFilterContext *ctx)
+{
+DrawTextContext *s = ctx->priv;
+uint8_t *tmp;
+int ret = 0;
+static FriBidiFlags flags = FRIBIDI_FLAGS_DEFAULT | \
+FRIBIDI_FLAGS_ARABIC;
+FriBidiChar *unicodestr = NULL;
+FriBidiStrIndex len;
+FriBidiParType direction = FRIBIDI_PAR_ON;
+FriBidiStrIndex line_start = 0;
+FriBidiStrIndex line_end = 0;
+FriBidiLevel *embedding_levels = NULL;
+FriBidiArabicProp *ar_props = NULL;
+FriBidiCharType *bidi_types = NULL;
+FriBidiStrIndex i,j;
+
+len = strlen(s->text);
+if (!(unicodestr = av_malloc(len * sizeof(*unicodestr {
+ret = AVERROR(ENOMEM);
+goto out;
+}
+len = fribidi_charset_to_unicode(FRIBIDI_CHAR_SET_UTF8,
+ s->text, len, unicodestr);
+
+bidi_types = av_malloc(len * sizeof(*bidi_types));
+if (!bidi_types) {
+ret = AVERROR(ENOMEM);
+goto out;
+}
+
+fribidi_get_bidi_types(un
Re: [FFmpeg-devel] [PATCH 2/2] drawtext: Use libfribidi to correctly render Arabic text - Fixes ticket #3758
Thanks for the patch. A first quick set of remarks.
Le primidi 21 messidor, an CCXXII, Marc Jeffreys a écrit :
> I've added this as a "fribidi=1" option to drawtext rather than enabling
> it by default, so as not to break anything.
Do you have any idea about what it could break? IMHO, if ffmpeg is capable
of correctly rendering Arabic text, it should do it by default.
Also, I do not like the name: it is about the implementation and not the
function. If we were to change the implementation (using another library),
we would either have to change the option name or have an inconsistency.
> Difference can be seen by compiling with --enable-libfribidi and comparing:
I think you should merge the change in configure with this patch.
>
> ffplay -loglevel debug -f lavfi -i
> "color=color=white,drawtext=fontfile=/usr/share/fonts/dejavu/DejaVuSans.ttf:text=أحمد"
>
> ffplay -loglevel debug -f lavfi -i
> "color=color=white,drawtext=fribidi=1:fontfile=/usr/share/fonts/dejavu/DejaVuSans.ttf:text=أحمد"
>
> A slight note: This does create some -Wundef warnings on compilation, but
> they're from libfribidi itself rather than this code.
> I opted to leave them alone rather than start defining macros just to keep
> things quiet, but if necessary that can be changed.
>
> ---
> doc/filters.texi | 8 +++
> libavfilter/vf_drawtext.c | 137
> --
> 2 files changed, 139 insertions(+), 6 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index ada33a7..a9e7360 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -3653,6 +3653,8 @@ To enable compilation of this filter, you need to
> configure FFmpeg with
> @code{--enable-libfreetype}.
> To enable default font fallback and the @var{font} option you need to
> configure FFmpeg with @code{--enable-libfontconfig}.
> +To enable the @var{fribidi} option, you need to configure FFmpeg with
> +@code{--enable-libfribidi}.
>
> @subsection Syntax
>
> @@ -3707,6 +3709,9 @@ This parameter is mandatory if the fontconfig support
> is disabled.
> The font size to be used for drawing text.
> The default value of @var{fontsize} is 16.
>
> +@item fribidi
> +If set to 1, pass the text through libfribidi before rendering. By default 0.
I believe the doc should explain what it does to a normal, multimedia-savvy
user, but not require knowledge of subtle free-software implementations of
things that are only vaguely related to multimedia.
> +
> @item ft_load_flags
> The flags to be used for loading the fonts.
>
> @@ -4010,6 +4015,9 @@ For more information about libfreetype, check:
> For more information about fontconfig, check:
> @url{http://freedesktop.org/software/fontconfig/fontconfig-user.html}.
>
> +For more information about libfribidi, check:
> +@url{http://fribidi.org/}.
> +
> @section edgedetect
>
> Detect and draw edges. The filter uses the Canny Edge Detection algorithm.
> diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
> index 0d829a6..ecdc569 100644
> --- a/libavfilter/vf_drawtext.c
> +++ b/libavfilter/vf_drawtext.c
> @@ -59,6 +59,10 @@
> #include "internal.h"
> #include "video.h"
>
> +#if CONFIG_LIBFRIBIDI
> +#include
> +#endif
> +
> #include
> #include FT_FREETYPE_H
> #include FT_GLYPH_H
> @@ -182,6 +186,9 @@ typedef struct DrawTextContext {
> int tc24hmax; ///< 1 if timecode is wrapped to 24
> hours, 0 otherwise
> int reload; ///< reload text file for each frame
> int start_number; ///< starting frame number for
> n/frame_num var
> +#if CONFIG_LIBFRIBIDI
> +int fribidi;///< 1 if using fribidi
> +#endif
> AVDictionary *metadata;
> } DrawTextContext;
>
> @@ -226,6 +233,10 @@ static const AVOption drawtext_options[]= {
> {"fix_bounds", "if true, check and fix text coords to avoid clipping",
> OFFSET(fix_bounds), AV_OPT_TYPE_INT, {.i64=1}, 0, 1, FLAGS},
> {"start_number", "start frame number for n/frame_num variable",
> OFFSET(start_number), AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX, FLAGS},
>
> +#if CONFIG_LIBFRIBIDI
> +{"fribidi", "pass text through libfribidi before rendering",
> OFFSET(fribidi), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, FLAGS},
> +#endif
> +
> /* FT_LOAD_* flags */
> { "ft_load_flags", "set font loading flags for libfreetype",
> OFFSET(ft_load_flags), AV_OPT_TYPE_FLAGS, { .i64 = FT_LOAD_DEFAULT }, 0,
> INT_MAX, FLAGS, "ft_load_flags" },
> { "default", NULL, 0, AV_OPT_TYPE_CONST, { .i64
> = FT_LOAD_DEFAULT }, .flags = FLAGS, .unit =
> "ft_load_flags" },
> @@ -482,6 +493,113 @@ static int load_textfile(AVFilterContext *ctx)
> return 0;
> }
>
> +static inline int is_newline(uint32_t c)
> +{
> +return c == '\n' || c == '\r' || c == '\f' || c == '\v';
> +}
> +
> +#if CONFIG_LIBFRIBIDI
> +static int fribidi_text(AVFilterContext *ctx)
> +{
> +DrawTex
Re: [FFmpeg-devel] [PATCH 2/2] drawtext: Use libfribidi to correctly render Arabic text - Fixes ticket #3758
Date: Wed, 9 Jul 2014 18:31:22 +0200
From: geo...@nsup.org
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 2/2] drawtext: Use libfribidi to correctly
render Arabic text - Fixes ticket #3758
> Do you have any idea about what it could break? IMHO, if ffmpeg is capable
> of correctly rendering Arabic text, it should do it by default.
The only case that comes to mind is if someone is reversing the arabic text
before sending it to ffmpeg, to counteract the existing issue. But you're
right; default-on would probably be better in the long-term.
> Also, I do not like the name: it is about the implementation and not the
> function. If we were to change the implementation (using another library),
> we would either have to change the option name or have an inconsistency.
Good point. I've been at a loss for names to to use, however. Perhaps, if
we default to using this, we could have something like "raw_text=1" to switch
the behaviour off.
> I think you should merge the change in configure with this patch.
I was following http://ffmpeg.org/developer.html#Development-Policy ,
point 5:
"Also do not forget that if part B depends on part A, but A does not
depend on B, then A can and should be committed first and separate from B."
Parts A and B being the configure patch and this patch, respectively.
But I'm happy to do a merge if necessary.
>> +@item fribidi
>> +If set to 1, pass the text through libfribidi before rendering. By default
>> 0.
> I believe the doc should explain what it does to a normal, multimedia-savvy
> user, but not require knowledge of subtle free-software implementations of
> things that are only vaguely related to multimedia.
I'll see what I can do.
> Can you explain what scripts will be correctly rendered with this
> implementation?
>
> If code has to be added for each script, then maybe using a more high-level
> library than fribidi would be better.
I'm not an expert in this field, but my understanding is:
- All right-to-left/left-to-right reading issues should be resolved.
- This won't fix any non-arabic scripts which require glyph substitution
(But I don't think these are that common).
- It may break some custom fonts (An ideal implementation would look at the
Opentype layout tables in the font itself).
And yes, a better implementation might use something like harfbuzz,
but a small fix is perhaps better than none.
>> +fribidi_shape(flags, embedding_levels, len, ar_props, unicodestr);
>> +
>> +for (line_end = 0, line_start = 0; line_end < len; line_end++) {
>> +if (is_newline(unicodestr[line_end]) || line_end == len - 1) {
>> +if (fribidi_reorder_line(flags, bidi_types, line_end -
>> line_start,
>> + line_start, direction,
>> embedding_levels,
>> + unicodestr, NULL) == 0) {
>> +ret = AVERROR(ENOMEM);
> According to the doc, ENOMEM is the most likely but not the only
> possibility. Can you elaborate?
Looking through the source of fribidi-0.19.6, I can't actually see a case in
which
this function ever fails. So I suppose we should go by the documentation, just
to be safe.
> Freeing NULL is legal, precisely in order to make these tests unnecessary.
Noted. I'll fix that.
I won't be able to make any more changes to my code until tomorrow morning, but
I
can try to respond to any technical points. I'll resubmit as soon as I can.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add dvdsub workaround for some players
On Wed, Jul 09, 2014 at 06:43:58PM +0200, Oliver Fromme wrote: > I mentioned this issue before, now here is a small patch for it. > The issue affects dvdsub subtitles (a.k.a. VOBSUB). > > Some players -- in particular hardware players -- cut off > the lowest row of pixels if the number of rows in the subtitle > is odd. > > The patch below implements a work-around for that. If the > number of rows is odd, it is simply rounded up to an even > number, adding an invisible (i.e. fully transparent) row. > The work-around can be enabled or disabled with a new > option -even_rows_fix. The default is disabled, so there > is no change of behaviour for users who don't care about it. > > The overhead for the fix is low, and in many cases even zero: > For subtitles with an odd number of rows (i.e. in 50% of > cases on average), the size increases by two bytes because > a fully transparent row is encoded as 0x00 0x00. However, > in the VOBSUB standard, all data packets are padded to 2KB > anyway, so in most cases the additional bytes just use some > part of the padding, so there is no overhead. Only in the > rare case that the 2KB boundary is hit (0.1% chance), a full > 2KB block is added. > > Suggested commit message (if you think this is too concise, > you can also use what I've written above): > > Implement work-around for some players having problems with > odd-sized dvdsub subtitles. If enabled with -even_rows_fix 1, > the number of rows is rounded up to an even number. patch applied can you also post one that adds "even_rows_fix" to the docs ? thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AVFormat: LRC demuxer and muxer
On Wed, Jul 09, 2014 at 10:55:47PM +0800, Star Brilliant wrote: > 于 2014年07月09日 22:24, Derek Buitenhuis 写道: > >>+/* > >>+ * LRC lyrics file format decoder > >>+ * Copyright (c) 2014 StarBrilliant > > > >For copyright purposes we generally use real names. > > Thank you for your reminder. > But I consider my real name piracy. no problem, pseudonyms are ok [...] -- 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] AVFormat: LRC demuxer and muxer
On Wed, Jul 09, 2014 at 11:37:31PM +0800, Star Brilliant wrote: > On 2014-07-09 23:09, Derek Buitenhuis wrote: > >You misunderstand what I am asking. int may be 32bits, and timestamps > >generate 64. > >is LRC guaranteed to only have 32bit timestamps? > > I find no portable way to scanf a 64-bit integer in C90 standard. > sscanf(buf, "%" SCNd64, &ptr); is a C99 thing. SCNd64 is used in libavformat already, so its use is ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavformat/segment: change segment_list_size behavior to match hls_list_size behavior.
Make the segment muxer keep segment_list_size segments instead of
segment_list_size + 1 segments. This patch also changes the
documentation for segment_list_size to reduce possible confusion over
how many segments are kept.
Signed-off-by: Simon Thelen
---
doc/muxers.texi | 2 +-
libavformat/segment.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index dc2a08b..7bf47a2 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -822,7 +822,7 @@ Select the listing format.
@end table
@item segment_list_size @var{size}
-Update the list file so that it contains at most the last @var{size}
+Update the list file so that it contains at most @var{size}
segments. If 0 the list file will contain all the segments. Default
value is 0.
diff --git a/libavformat/segment.c b/libavformat/segment.c
index f5e25a2..623b076 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -333,7 +333,7 @@ static int segment_end(AVFormatContext *s, int
write_trailer, int is_last)
seg->segment_list_entries_end = entry;
/* drop first item */
-if (seg->list_size && seg->segment_count > seg->list_size) {
+if (seg->list_size && seg->segment_count >= seg->list_size) {
entry = seg->segment_list_entries;
seg->segment_list_entries = seg->segment_list_entries->next;
av_free(entry->filename);
--
2.0.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/segment: change segment_list_size behavior to match hls_list_size behavior.
On 09/07/14 at 21:40, Simon Thelen wrote: > Make the segment muxer keep segment_list_size segments instead of > segment_list_size + 1 segments. This patch also changes the > documentation for segment_list_size to reduce possible confusion over > how many segments are kept. What I forgot to mention was that this allows the segment list to be limited to containing only one segment which used to be impossible because a segment_list_size of 0 kept all the segments and a segment_list_size of 1 kept 2 segments. I can add that to the commit message if you want. -- Simon Thelen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avformat/hlsenc: pull request for single file mode
09.07.2014 12:26, Nicolas Martyanoff kirjoitti: > Hi, Hi, and thanks for the patches. > The hlsenc muxer only supports HLS version 3, and I needed byterange support > (version 4), so I added it :) > > You will find a pull request on Github (hlsenc branch): > > https://github.com/FFmpeg/FFmpeg/pull/76 > > There are four patches. Two fix small issues in the muxer (target duration > computation and default subtitles format), the other two clean the muxer and > add a single file mode. > > I tested my patches with and without the new single file mode, on media files > with and without video streams. > > This is my first work on FFmpeg, so feel free to point any mistake. > > Note that the work was done for my job, and the company I work for officially > authorizeded me to contribute to FFmpeg under the terms of its license. avformat/hlsenc: correctly compute target duration - seems clearly correct => applied avformat/hlsenc: cleaning - looks good to me, and there is no maintainer so I guess this is OK - well, actually, maybe you could use more than one word in the subject :) avformat/hlsenc: add single file mode - Adds HLSContext.ref_stream etc, shouldn't that be a separate patch? - HLSContext.file_idx is never read AFAICS avformat/hslenc: add a flag disabling the filename in segment names - hsl - should probably require single_file as well? - see below avformat/hlsenc: add an option to set the media filename - should probably check not used together with separated segments? - see below "no_filename" for "do not use the name of the media file in segment names" were unclear enough that I had to take a look at the code what is going on. For anyone else wondering (correct me if I'm wrong), currently: (1) The output file name from the user is used as the output media playlist filename. (2) The media file/segment file names are generated from the basename of the output playlist filename. (3) The media file/segments URLs in the media playlist get -hls_base_url prepended to them, so they are base_url + media filename. These two patches would - add "no_filename" flag to only use hls_base_url for (3), allowing to select an arbitrary URL. - allow to select the file for (2) I wonder if it would be clearer to have -hls_media_file - "the generated output media file" (requires "single_file") -hls_media_url - "output media file url used in the playlist" (requires "single_file" and !hls_base_url) Or would it just be unclear to have both conflicting hls_media_url and hls_base_url? -- Anssi Hannula ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] understanding usage of av_compare_ts() in avformat/hlsenc
08.07.2014 13:19, Nicolas Martyanoff kirjoitti:
> Hi,
Hi,
> I am currently working on improving the hlsenc muxer to support byteranges
> (HLS version 4), and it is starting to work :) But there is a line that really
> puzzles me:
>
>
> if (can_split && av_compare_ts(pkt->pts - hls->start_pts, st->time_base,
>end_pts, AV_TIME_BASE_Q) >= 0) {
>
> // libavformat/hlsenc.c 282
>
>
> Afaik, av_compare_ts() compares two presentation timestamps with potentially
> different time bases, and returns a value indicating if the first timestamp is
> larger (i.e. more recent) than the second one.
>
> However in this code, the first argument is the difference between two
> presentation timestamp, i.e. a time length. I do not get how comparing a time
> length and a presentation timestamp makes any kind of sense.
>
> Does anyone know what I am missing here ?
I guess you may have gotten this already, but anyway:
The end_pts is actually a time length as well, not an actual PTS, since
it is just (number_of_segments * length_of_segment).
> Thank you in advance.
--
Anssi Hannula
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] understanding usage of av_compare_ts() in avformat/hlsenc
On 2014-07-10 01:41, Anssi Hannula wrote:
> 08.07.2014 13:19, Nicolas Martyanoff kirjoitti:
> > Hi,
>
> Hi,
>
> > I am currently working on improving the hlsenc muxer to support byteranges
> > (HLS version 4), and it is starting to work :) But there is a line that
> > really
> > puzzles me:
> >
> >
> > if (can_split && av_compare_ts(pkt->pts - hls->start_pts, st->time_base,
> >end_pts, AV_TIME_BASE_Q) >= 0) {
> >
> > // libavformat/hlsenc.c 282
> >
> >
> > Afaik, av_compare_ts() compares two presentation timestamps with potentially
> > different time bases, and returns a value indicating if the first timestamp
> > is
> > larger (i.e. more recent) than the second one.
> >
> > However in this code, the first argument is the difference between two
> > presentation timestamp, i.e. a time length. I do not get how comparing a
> > time
> > length and a presentation timestamp makes any kind of sense.
> >
> > Does anyone know what I am missing here ?
>
> I guess you may have gotten this already, but anyway:
>
> The end_pts is actually a time length as well, not an actual PTS, since
> it is just (number_of_segments * length_of_segment).
Yes, I got it :) Thank you anyway.
--
Nicolas Martyanoff
http://wandrian.net
khae...@gmail.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] gitignore: add examples/transcoding
Signed-off-by: Lukasz Marek --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 4506ab9..89b319a 100644 --- a/.gitignore +++ b/.gitignore @@ -50,6 +50,7 @@ /doc/examples/resampling_audio /doc/examples/scaling_video /doc/examples/transcode_aac +/doc/examples/transcoding /doc/fate.txt /doc/print_options /lcov/ -- 1.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/6] lavf: add directory listing API
On 08.07.2014 14:49, Lukasz Marek wrote:
On 7 July 2014 23:59, wm4
new patch attached.
TBH I cannot tell which patch I prefer the most.
Last option I see would be to create separate context for listing dir,
but it would just have one void* variable for URLContext.
I will resent all other paches from this set later.
No major changes tho.
>From c7c43d16e03bce4b7488a9cba4140f47532aa3da Mon Sep 17 00:00:00 2001
From: Lukasz Marek
Date: Sat, 5 Jul 2014 18:11:59 +0200
Subject: [PATCH] lavf: add directory listing API
TODO: bump minor, update doc/APIchanges
API allows protocol implementations to provide API that
allows to list directory content.
API is similar to POSIX opendir/readdir/closedir.
Signed-off-by: Lukasz Marek
---
libavformat/avio.c | 74 ++-
libavformat/avio.h | 85 +-
libavformat/url.h | 55 +++
3 files changed, 212 insertions(+), 2 deletions(-)
diff --git a/libavformat/avio.c b/libavformat/avio.c
index 0a2a0a9..125f9f9 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -23,12 +23,14 @@
#include "libavutil/dict.h"
#include "libavutil/opt.h"
#include "libavutil/time.h"
+#include "libavutil/avassert.h"
#include "os_support.h"
#include "avformat.h"
#if CONFIG_NETWORK
#include "network.h"
#endif
#include "url.h"
+#include "avio_internal.h"
static URLProtocol *first_protocol = NULL;
@@ -286,6 +288,43 @@ fail:
return ret;
}
+void ffurl_close_dir(URLContext *s)
+{
+if (s) {
+s->prot->url_close_dir(s);
+ffurl_close(s);
+}
+}
+
+int ffurl_open_dir(URLContext **s, const char *url,
+ const AVIOInterruptCB *int_cb, AVDictionary **options)
+{
+int ret;
+
+if ((ret = ffurl_alloc(s, url, AVIO_FLAG_READ, int_cb)) < 0)
+return ret;
+if (!(*s)->prot->url_open_dir || !(*s)->prot->url_read_dir || !(*s)->prot->url_close_dir) {
+ret = AVERROR(ENOSYS);
+goto fail;
+}
+if ((*s)->prot->priv_data_class &&
+(ret = av_opt_set_dict((*s)->priv_data, options)) < 0)
+goto fail;
+if ((ret = av_opt_set_dict(*s, options)) < 0)
+goto fail;
+if ((ret = (*s)->prot->url_open_dir(*s)) < 0)
+goto fail;
+return 0;
+ fail:
+ffurl_close_dir(*s);
+return ret;
+}
+
+int ffurl_next_dir_entry(URLContext *s, const AVIODirEntry **next)
+{
+return s->prot->url_read_dir(s, next);
+}
+
static inline int retry_transfer_wrapper(URLContext *h, uint8_t *buf,
int size, int size_min,
int (*transfer_func)(URLContext *h,
@@ -389,7 +428,6 @@ int ffurl_close(URLContext *h)
return ffurl_closep(&h);
}
-
const char *avio_find_protocol_name(const char *url)
{
URLProtocol *p = url_find_protocol(url);
@@ -416,6 +454,40 @@ int avio_check(const char *url, int flags)
return ret;
}
+void avio_close_dir(AVIOContext *s)
+{
+if (s) {
+ffurl_close_dir(s->opaque);
+av_free(s);
+}
+}
+
+int avio_open_dir(AVIOContext **s, const char *url,
+ const AVIOInterruptCB *int_cb, AVDictionary **options)
+{
+URLContext *h;
+int ret;
+av_assert0(s);
+if ((ret = ffurl_open_dir(&h, url, int_cb, options)) < 0)
+return ret;
+
+*s = avio_alloc_context(NULL, 0, h->flags, h, NULL, NULL, NULL);
+if (!*s) {
+avio_close_dir(*s);
+return AVERROR(ENOMEM);
+}
+if (h->prot) {
+(*s)->next_dir_entry = (int(*)(void *, const AVIODirEntry**))h->prot->url_read_dir;
+}
+(*s)->av_class = &ffio_url_class;
+return 0;
+}
+
+int avio_read_dir(AVIOContext *s, AVIODirEntry const **next)
+{
+return ffurl_next_dir_entry(s->opaque, next);
+}
+
int64_t ffurl_size(URLContext *h)
{
int64_t pos, size;
diff --git a/libavformat/avio.h b/libavformat/avio.h
index 4004b6f..26d3be1 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -34,7 +34,6 @@
#include "libavformat/version.h"
-
#define AVIO_SEEKABLE_NORMAL 0x0001 /**< Seeking works like for a local file */
/**
@@ -54,6 +53,41 @@ typedef struct AVIOInterruptCB {
} AVIOInterruptCB;
/**
+ * Directory entry types.
+ */
+enum AVIODirEntryType {
+AVIO_ENTRY_UNKNOWN,
+AVIO_ENTRY_BLOCK_DEVICE,
+AVIO_ENTRY_CHARACTER_DEVICE,
+AVIO_ENTRY_DIRECTORY,
+AVIO_ENTRY_NAMED_PIPE,
+AVIO_ENTRY_SYMBOLIC_LINK,
+AVIO_ENTRY_SOCKET,
+AVIO_ENTRY_FILE
+};
+
+/**
+ * Describes single entry of the directory.
+ *
+ * Only name and type fileds are guaranteed be set.
+ * The other fields are protocol or/and platform dependent and might be unknown.
+ */
+typedef struct AVIODirEntry {
+char *name; /**< Filename without a path. */
+int utf8; /**< Set to 1 when name is encoded with UTF-8, 0 otherwise.
+ Name can
Re: [FFmpeg-devel] avformat/hlsenc: pull request for single file mode
On 2014-07-10 01:32, Anssi Hannula wrote: > avformat/hlsenc: cleaning > - looks good to me, and there is no maintainer so I guess this is OK > - well, actually, maybe you could use more than one word in the subject :) I'll change the title to something such as 'make the code easier to read' :) > avformat/hlsenc: add single file mode > - Adds HLSContext.ref_stream etc, shouldn't that be a separate patch? I guess I could, but the code is incorrect without it. I added it when I realized it would not work when a file has two video streams (or two audio streams and no video streams). If you think it's better to have two patches, the first one being incorrect, I can split it. > - HLSContext.file_idx is never read AFAICS It is used to generate the TS filename in hls_create_file(). > avformat/hslenc: add a flag disabling the filename in segment names > - hsl Oops > - should probably require single_file as well? Indeed, I'll fix it. > - see below > > avformat/hlsenc: add an option to set the media filename > - should probably check not used together with separated segments? It also works with separated segments. For example: -hls_media_filename foo-%d.ts Will generate foo-0.ts, foo-1.ts, foo-2.ts, etc. Without this patch, separated files are named %d.ts. > - see below > > > "no_filename" for "do not use the name of the media file in segment > names" were unclear enough that I had to take a look at the code what is > going on. > > For anyone else wondering (correct me if I'm wrong), currently: > (1) The output file name from the user is used as the output media > playlist filename. > (2) The media file/segment file names are generated from the basename of > the output playlist filename. > (3) The media file/segments URLs in the media playlist get -hls_base_url > prepended to them, so they are base_url + media filename. This is indeed how it worked before my patches. > These two patches would > - add "no_filename" flag to only use hls_base_url for (3), allowing to > select an arbitrary URL. > - allow to select the file for (2) Correct. > I wonder if it would be clearer to have > -hls_media_file - "the generated output media file" > (requires "single_file") Not that as explained before, -hls_media_file is valid and used for !single_file (i.e. individual files). > -hls_media_url - "output media file url used in the playlist" > (requires "single_file" and !hls_base_url) > > Or would it just be unclear to have both conflicting hls_media_url and > hls_base_url? I do not know. On the one hand, it seems redundant to have two different options to specify the same thing, i.e. the URL used for segments. On the other hand, with (HLS_SINGLE_FILE | HLS_NO_FILENAME), there is no "base URL", only a "normal" URL. It would be useful to have the point of view of someone using this muxer. Thank you for taking the time to review my patches ! I'll update my patches tomorrow. Regards, -- Nicolas Martyanoff http://wandrian.net khae...@gmail.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add dvdsub workaround for some players
On Wed, Jul 09, 2014 at 10:58:55PM +0200, Oliver Fromme wrote: > Michael Niedermayer wrote: > > On Wed, Jul 09, 2014 at 06:43:58PM +0200, Oliver Fromme wrote: > > > [...] > > > Implement work-around for some players having problems with > > > odd-sized dvdsub subtitles. If enabled with -even_rows_fix 1, > > > the number of rows is rounded up to an even number. > > > > patch applied > > Thank you. > > > can you also post one that adds "even_rows_fix" to the docs ? > > Yes, but I'm not sure where exactly. So far, the ffmpeg > man page doesn't have a section about subtitle encoders > at all, it only has one for decoders. > > Should I add such a section and a short description of the > dvdsub encoder? Then I can put the text for "even_rows_fix" > there. probably, yes [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] gitignore: add examples/transcoding
On Thu, Jul 10, 2014 at 01:25:40AM +0200, Lukasz Marek wrote: > Signed-off-by: Lukasz Marek > --- > .gitignore | 1 + > 1 file changed, 1 insertion(+) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avformat/hlsenc: pull request for single file mode
10.07.2014 02:40, Nicolas Martyanoff kirjoitti: > On 2014-07-10 01:32, Anssi Hannula wrote: >> avformat/hlsenc: cleaning >> - looks good to me, and there is no maintainer so I guess this is OK >> - well, actually, maybe you could use more than one word in the subject :) > I'll change the title to something such as 'make the code easier to read' :) > >> avformat/hlsenc: add single file mode >> - Adds HLSContext.ref_stream etc, shouldn't that be a separate patch? > I guess I could, but the code is incorrect without it. I added it when I > realized it would not work when a file has two video streams (or two audio > streams and no video streams). > > If you think it's better to have two patches, the first one being incorrect, I > can split it. Maybe I'm missing something, but I don't see how not working with two video streams has anything to do with single file mode? Assuming there is actually some relation, could you have the ref changes in a first patch and single file in another patch, or would the ref changes break something else? >> - HLSContext.file_idx is never read AFAICS > It is used to generate the TS filename in hls_create_file(). I don't see hls->file_idx accessed there... only the local int file_idx. >> avformat/hslenc: add a flag disabling the filename in segment names >> - hsl > Oops >> - should probably require single_file as well? > Indeed, I'll fix it. > >> - see below >> >> avformat/hlsenc: add an option to set the media filename >> - should probably check not used together with separated segments? > It also works with separated segments. For example: > > -hls_media_filename foo-%d.ts > > Will generate foo-0.ts, foo-1.ts, foo-2.ts, etc. > > Without this patch, separated files are named %d.ts. Right. This should be documented in doc/muxers.texi, though. Same goes for your other new parameters, BTW, I forgot about that. >> - see below >> >> >> "no_filename" for "do not use the name of the media file in segment >> names" were unclear enough that I had to take a look at the code what is >> going on. >> >> For anyone else wondering (correct me if I'm wrong), currently: >> (1) The output file name from the user is used as the output media >> playlist filename. >> (2) The media file/segment file names are generated from the basename of >> the output playlist filename. >> (3) The media file/segments URLs in the media playlist get -hls_base_url >> prepended to them, so they are base_url + media filename. > This is indeed how it worked before my patches. > >> These two patches would >> - add "no_filename" flag to only use hls_base_url for (3), allowing to >> select an arbitrary URL. >> - allow to select the file for (2) > Correct. > >> I wonder if it would be clearer to have >> -hls_media_file - "the generated output media file" >> (requires "single_file") > Not that as explained before, -hls_media_file is valid and used for > !single_file (i.e. individual files). > >> -hls_media_url - "output media file url used in the playlist" >> (requires "single_file" and !hls_base_url) >> >> Or would it just be unclear to have both conflicting hls_media_url and >> hls_base_url? > I do not know. On the one hand, it seems redundant to have two different > options to specify the same thing, i.e. the URL used for segments. On the > other hand, with (HLS_SINGLE_FILE | HLS_NO_FILENAME), there is no "base URL", > only a "normal" URL. > > It would be useful to have the point of view of someone using this muxer. > > > Thank you for taking the time to review my patches ! > > I'll update my patches tomorrow. > > Regards, > -- Anssi Hannula ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] alpha/pixblockdsp: move code out of dsputil
Signed-off-by: James Almer
---
Untested like previous Alpha patches.
libavcodec/alpha/Makefile| 1 +
libavcodec/alpha/dsputil_alpha.c | 5 ---
libavcodec/alpha/dsputil_alpha.h | 4 --
libavcodec/alpha/motion_est_alpha.c | 45
libavcodec/alpha/pixblockdsp_alpha.c | 80
libavcodec/pixblockdsp.c | 2 +
libavcodec/pixblockdsp.h | 2 +
7 files changed, 85 insertions(+), 54 deletions(-)
create mode 100644 libavcodec/alpha/pixblockdsp_alpha.c
diff --git a/libavcodec/alpha/Makefile b/libavcodec/alpha/Makefile
index 34e5275..42cabfe 100644
--- a/libavcodec/alpha/Makefile
+++ b/libavcodec/alpha/Makefile
@@ -8,3 +8,4 @@ OBJS-$(CONFIG_IDCTDSP) +=
alpha/idctdsp_alpha.o\
alpha/idctdsp_alpha_asm.o\
alpha/simple_idct_alpha.o
OBJS-$(CONFIG_MPEGVIDEO)+= alpha/mpegvideo_alpha.o
+OBJS-$(CONFIG_PIXBLOCKDSP) += alpha/pixblockdsp_alpha.o
diff --git a/libavcodec/alpha/dsputil_alpha.c b/libavcodec/alpha/dsputil_alpha.c
index 06a1a6d..d99a74b 100644
--- a/libavcodec/alpha/dsputil_alpha.c
+++ b/libavcodec/alpha/dsputil_alpha.c
@@ -98,13 +98,8 @@ void add_pixels_clamped_mvi(const int16_t *block, uint8_t
*pixels,
av_cold void ff_dsputil_init_alpha(DSPContext *c, AVCodecContext *avctx)
{
-const int high_bit_depth = avctx->bits_per_raw_sample > 8;
-
/* amask clears all bits that correspond to present features. */
if (amask(AMASK_MVI) == 0) {
-if (!high_bit_depth)
-c->get_pixels = get_pixels_mvi;
-c->diff_pixels = diff_pixels_mvi;
c->sad[0] = pix_abs16x16_mvi_asm;
c->sad[1] = pix_abs8x8_mvi;
c->pix_abs[0][0]= pix_abs16x16_mvi_asm;
diff --git a/libavcodec/alpha/dsputil_alpha.h b/libavcodec/alpha/dsputil_alpha.h
index bc29469..a48765f 100644
--- a/libavcodec/alpha/dsputil_alpha.h
+++ b/libavcodec/alpha/dsputil_alpha.h
@@ -22,10 +22,6 @@
#include
#include
-void get_pixels_mvi(int16_t *restrict block,
-const uint8_t *restrict pixels, int line_size);
-void diff_pixels_mvi(int16_t *block, const uint8_t *s1, const uint8_t *s2,
- int stride);
int pix_abs8x8_mvi(void *v, uint8_t *pix1, uint8_t *pix2, int line_size, int
h);
int pix_abs16x16_mvi_asm(void *v, uint8_t *pix1, uint8_t *pix2, int line_size,
int h);
int pix_abs16x16_x2_mvi(void *v, uint8_t *pix1, uint8_t *pix2, int line_size,
int h);
diff --git a/libavcodec/alpha/motion_est_alpha.c
b/libavcodec/alpha/motion_est_alpha.c
index a7c33e4..246b4a7 100644
--- a/libavcodec/alpha/motion_est_alpha.c
+++ b/libavcodec/alpha/motion_est_alpha.c
@@ -22,51 +22,6 @@
#include "dsputil_alpha.h"
#include "asm.h"
-void get_pixels_mvi(int16_t *restrict block,
-const uint8_t *restrict pixels, int line_size)
-{
-int h = 8;
-
-do {
-uint64_t p;
-
-p = ldq(pixels);
-stq(unpkbw(p), block);
-stq(unpkbw(p >> 32), block + 4);
-
-pixels += line_size;
-block += 8;
-} while (--h);
-}
-
-void diff_pixels_mvi(int16_t *block, const uint8_t *s1, const uint8_t *s2,
- int stride) {
-int h = 8;
-uint64_t mask = 0x4040;
-
-mask |= mask << 16;
-mask |= mask << 32;
-do {
-uint64_t x, y, c, d, a;
-uint64_t signs;
-
-x = ldq(s1);
-y = ldq(s2);
-c = cmpbge(x, y);
-d = x - y;
-a = zap(mask, c); /* We use 0x4040404040404040 here... */
-d += 4 * a; /* ...so we can use s4addq here. */
-signs = zap(-1, c);
-
-stq(unpkbw(d) | (unpkbw(signs) << 8), block);
-stq(unpkbw(d >> 32) | (unpkbw(signs >> 32) << 8), block + 4);
-
-s1 += stride;
-s2 += stride;
-block += 8;
-} while (--h);
-}
-
static inline uint64_t avg2(uint64_t a, uint64_t b)
{
return (a | b) - (((a ^ b) & BYTE_VEC(0xfe)) >> 1);
diff --git a/libavcodec/alpha/pixblockdsp_alpha.c
b/libavcodec/alpha/pixblockdsp_alpha.c
new file mode 100644
index 000..69b1be5
--- /dev/null
+++ b/libavcodec/alpha/pixblockdsp_alpha.c
@@ -0,0 +1,80 @@
+/*
+ * SIMD-optimized pixel operations
+ *
+ * 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 Publi
Re: [FFmpeg-devel] [PATCH] alpha/pixblockdsp: move code out of dsputil
On 09/07/14 10:16 PM, James Almer wrote:
> +av_cold void ff_pixblockdsp_init_alpha(PixblockDSPContext *c, AVCodecContext
> *avctx,
> + unsigned high_bit_depth)
> +{
> +int cpu_flags = av_get_cpu_flags();
Copy-paste mistake. This can be removed.
> +
> +if (amask(AMASK_MVI) == 0) {
> +if (!high_bit_depth)
> +c->get_pixels = get_pixels_mvi;
> +c->diff_pixels = diff_pixels_mvi;
> +}
> +}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AVFormat: LRC demuxer and muxer
On 2014-07-10 02:27, Michael Niedermayer wrote:
On Wed, Jul 09, 2014 at 11:37:31PM +0800, Star Brilliant wrote:
On 2014-07-09 23:09, Derek Buitenhuis wrote:
You misunderstand what I am asking. int may be 32bits, and timestamps generate
64.
is LRC guaranteed to only have 32bit timestamps?
I find no portable way to scanf a 64-bit integer in C90 standard.
sscanf(buf, "%" SCNd64, &ptr); is a C99 thing.
SCNd64 is used in libavformat already, so its use is ok
I have rearranged the code.
Here's the new patch.
Thanks.
>From de3043bf93ff741ce8d8621c708e930250e3a759 Mon Sep 17 00:00:00 2001
From: Star Brilliant
Date: Wed, 9 Jul 2014 14:24:05 +0800
Subject: [PATCH] AVFormat: LRC demuxer and muxer
---
Changelog| 1 +
doc/general.texi | 1 +
libavformat/Makefile | 2 +
libavformat/allformats.c | 1 +
libavformat/lrc.c| 34 +++
libavformat/lrc.h| 29 ++
libavformat/lrcdec.c | 238 +++
libavformat/lrcenc.c | 142
8 files changed, 448 insertions(+)
create mode 100644 libavformat/lrc.c
create mode 100644 libavformat/lrc.h
create mode 100644 libavformat/lrcdec.c
create mode 100644 libavformat/lrcenc.c
diff --git a/Changelog b/Changelog
index fa443dc..75bde5b 100644
--- a/Changelog
+++ b/Changelog
@@ -29,6 +29,7 @@ version :
- showcqt multimedia filter
- zoompan filter
- signalstats filter
+- LRC demuxer and muxer
version 2.2:
diff --git a/doc/general.texi b/doc/general.texi
index 86569a2..c008261 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -310,6 +310,7 @@ library:
@tab Used by Linux Media Labs MPEG-4 PCI boards
@item LOAS @tab @tab X
@tab contains LATM multiplexed AAC audio
+@item LRC @tab X @tab X
@item LVF @tab @tab X
@item LXF @tab @tab X
@tab VR native stream format, used by Leitch/Harris' video servers.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index ecae4d0..3218c4c 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -202,6 +202,8 @@ OBJS-$(CONFIG_LATM_DEMUXER) += rawdec.o
OBJS-$(CONFIG_LATM_MUXER)+= latmenc.o rawenc.o
OBJS-$(CONFIG_LMLM4_DEMUXER) += lmlm4.o
OBJS-$(CONFIG_LOAS_DEMUXER) += loasdec.o rawdec.o
+OBJS-$(CONFIG_LRC_DEMUXER) += lrcdec.o lrc.o subtitles.o
+OBJS-$(CONFIG_LRC_MUXER) += lrcenc.o lrc.o
OBJS-$(CONFIG_LVF_DEMUXER) += lvfdec.o
OBJS-$(CONFIG_LXF_DEMUXER) += lxfdec.o
OBJS-$(CONFIG_M4V_DEMUXER) += m4vdec.o rawdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index dc5557c..fff05ee 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -163,6 +163,7 @@ void av_register_all(void)
REGISTER_MUXDEMUX(LATM, latm);
REGISTER_DEMUXER (LMLM4,lmlm4);
REGISTER_DEMUXER (LOAS, loas);
+REGISTER_MUXDEMUX(LRC, lrc);
REGISTER_DEMUXER (LVF, lvf);
REGISTER_DEMUXER (LXF, lxf);
REGISTER_MUXDEMUX(M4V, m4v);
diff --git a/libavformat/lrc.c b/libavformat/lrc.c
new file mode 100644
index 000..67eeede
--- /dev/null
+++ b/libavformat/lrc.c
@@ -0,0 +1,34 @@
+/*
+ * LRC lyrics file format decoder
+ * Copyright (c) 2014 StarBrilliant
+ *
+ * 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 "metadata.h"
+#include "lrc.h"
+
+const AVMetadataConv ffpriv_lrc_metadata_conv[] = {
+{"ti", "title"},
+{"al", "album"},
+{"ar", "artist"},
+{"au", "author"},
+{"by", "creator"},
+{"re", "encoder"},
+{"ve", "encoder_version"},
+{0, 0}
+};
diff --git a/libavformat/lrc.h b/libavformat/lrc.h
new file mode 100644
index 000..93274d5
--- /dev/null
+++ b/libavformat/lrc.h
@@ -0,0 +1,29 @@
+/*
+ * LRC lyrics file format decoder
+ * Copyright (c) 2014 StarBrilliant
+ *
+ * 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
+
Re: [FFmpeg-devel] [PATCH] alpha/pixblockdsp: move code out of dsputil
On Wed, Jul 09, 2014 at 10:18:30PM -0300, James Almer wrote:
> On 09/07/14 10:16 PM, James Almer wrote:
> > +av_cold void ff_pixblockdsp_init_alpha(PixblockDSPContext *c,
> > AVCodecContext *avctx,
> > + unsigned high_bit_depth)
> > +{
> > +int cpu_flags = av_get_cpu_flags();
>
> Copy-paste mistake. This can be removed.
fixed
also added missing include
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] Processing h264 decoder in wavefront order in FFmpeg
Hi, I am trying to parallel the h264 decoder in FFmpeg using wavefront processing. I know that the function ff_h264_decode_mb_cabac performs entropy decoding, and ff_h264_hl_decode_mb performs inverse quanization, inverse DCT and motion compensation per MB. And loop_filter applies the deblocking filter per row. I adjusted the values of mb_x and mb_y from the original scanline order to wavefront order. E.g. (0,0), (1,0),(2,0),(0,1),(3,0),(1,1)… but it showed a lot of warning messages as follows. [h264 @ 0x204e310] left block unavailable for requested intra mode at 117 31 [h264 @ 0x204e310] left block unavailable for requested intra4x4 mode -1 at 87 46 [h264 @ 0x204e310] top block unavailable for requested intra mode at 73 53 [h264 @ 0x204e310] top block unavailable for requested intra mode at 92 44 [...] Do any dependencies for the scanline order still exist in these functions after I change the processing order? - Winand ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] Add libfribidi support to configure script
On Wed, Jul 09, 2014 at 05:07:04PM +0100, Marc Jeffreys wrote:
> ---
> configure | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/configure b/configure
> index e20bf8e..cb7d392 100755
> --- a/configure
> +++ b/configure
> @@ -209,6 +209,7 @@ External library support:
>--enable-libfdk-aac enable AAC de/encoding via libfdk-aac [no]
>--enable-libfliteenable flite (voice synthesis) support via
> libflite [no]
>--enable-libfreetype enable libfreetype [no]
> + --enable-libfribidi enable libfribidi [no]
>--enable-libgme enable Game Music Emu via libgme [no]
>--enable-libgsm enable GSM de/encoding via libgsm [no]
>--enable-libiec61883 enable iec61883 via libiec61883 [no]
> @@ -1215,6 +1216,25 @@ require_libfreetype(){
> add_extralibs $(get_safe ${pkg}_libs)
> }
>
> +require_libfribidi(){
> +log require_libfribidi "$@"
> +pkg="fribidi"
> +check_cmd $pkg_config --exists --print-errors $pkg \
> + || die "ERROR: $pkg not found"
> +pkg_cflags=$($pkg_config --cflags $pkg_config_flags $pkg)
> +pkg_libs=$($pkg_config --libs $pkg_config_flags $pkg)
> +{
> +echo "#include "
> +echo "char* check_func(void) { return (char*) fribidi_version_info;
> }"
> +echo "int main(void) { return 0; }"
> +} | check_ld "cc" $pkg_cflags $pkg_libs \
> + && set_safe ${pkg}_cflags $pkg_cflags \
> + && set_safe ${pkg}_libs $pkg_libs \
> + || die "ERROR: $pkg not found"
> +add_cflags$(get_safe ${pkg}_cflags)
> +add_extralibs $(get_safe ${pkg}_libs)
> +}
> +
> hostcc_e(){
> eval printf '%s\\n' $HOSTCC_E
> }
> @@ -1332,6 +1352,7 @@ EXTERNAL_LIBRARY_LIST="
> libflite
> libfontconfig
> libfreetype
> +libfribidi
> libgme
> libgsm
> libiec61883
> @@ -4719,6 +4740,7 @@ enabled libflite && require2 libflite
> "flite/flite.h" flite_init $flite
> enabled fontconfig&& enable libfontconfig
> enabled libfontconfig && require_pkg_config fontconfig
> "fontconfig/fontconfig.h" FcInit
> enabled libfreetype && require_libfreetype
> +enabled libfribidi&& require_libfribidi
Please just do require_pkg_config fribidi fribidi.h fribidi_version_info
The require_libfreetype is a very special case because it has a very weird
way of doing includes (it's #include MACRO, which doesn't fit well in
require_pkg_config)
Also, as requested in the other thread, please have this hunk squashed
with the feature patch.
[...]
--
Clément B.
pgplf85LuZd3T.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/9] hevc: misc cleanups
The 4 first patches reduce memory allocations as, in a simplified view, only the previous ctb line is needed for the various prediction mechanisms. The actual required allocation is much smaller, but would require too many changes. And the margin of this mail is too small to explain it. The next 2 are another instance of "don't just implement the specs as is": the list of MVs does not need to be fully derived, so don't waste time on it. This is a semi-serious patchset, the intent is more to point out potential improvements. Christophe Gisquet (9): hevc: reduce allocation for split_cu_flag hevc: reduce allocation for skip_flag hevc: reduce allocation for tab_ipm hevc: reduce cu depth allocation hevc: derive partial merge list hevc: derive partially amvp list hevc: use intreadwrite hevc: simplify rounding hevc: reorder loops libavcodec/hevc.c | 38 +- libavcodec/hevc.h | 4 +-- libavcodec/hevc_cabac.c | 4 +-- libavcodec/hevc_mvs.c | 71 ++--- 4 files changed, 67 insertions(+), 50 deletions(-) -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/9] hevc: derive partial merge list
The merge list only needs to be derived up to the merge index.
---
libavcodec/hevc_mvs.c | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/libavcodec/hevc_mvs.c b/libavcodec/hevc_mvs.c
index 2b017dd..0302c88 100644
--- a/libavcodec/hevc_mvs.c
+++ b/libavcodec/hevc_mvs.c
@@ -315,6 +315,7 @@ static void derive_spatial_merge_candidates(HEVCContext *s,
int x0, int y0,
int nPbW, int nPbH,
int log2_cb_size,
int singleMCLFlag, int part_idx,
+int merge_idx,
struct MvField mergecandlist[])
{
HEVCLocalContext *lc = s->HEVClc;
@@ -383,8 +384,11 @@ static void derive_spatial_merge_candidates(HEVCContext
*s, int x0, int y0,
is_available_a1 = 0;
}
-if (is_available_a1)
-mergecandlist[nb_merge_cand++] = TAB_MVF_PU(A1);
+if (is_available_a1) {
+mergecandlist[0] = TAB_MVF_PU(A1);
+if (merge_idx == 0) return;
+nb_merge_cand++;
+}
// above spatial merge candidate
is_available_b1 = AVAILABLE(cand_up, B1);
@@ -415,8 +419,11 @@ static void derive_spatial_merge_candidates(HEVCContext
*s, int x0, int y0,
if (is_available_b1 && is_available_b0)
check_MER = !COMPARE_MV_REFIDX(B0, B1);
-if (is_available_b0 && check_MER)
-mergecandlist[nb_merge_cand++] = TAB_MVF_PU(B0);
+if (is_available_b0 && check_MER) {
+mergecandlist[nb_merge_cand] = TAB_MVF_PU(B0);
+if (merge_idx == nb_merge_cand) return;
+nb_merge_cand++;
+}
// left bottom spatial merge candidate
check_MER = 1;
@@ -430,8 +437,11 @@ static void derive_spatial_merge_candidates(HEVCContext
*s, int x0, int y0,
if (is_available_a1 && is_available_a0)
check_MER = !COMPARE_MV_REFIDX(A0, A1);
-if (is_available_a0 && check_MER)
-mergecandlist[nb_merge_cand++] = TAB_MVF_PU(A0);
+if (is_available_a0 && check_MER) {
+mergecandlist[nb_merge_cand] = TAB_MVF_PU(A0);
+if (merge_idx == nb_merge_cand) return;
+nb_merge_cand++;
+}
// above left spatial merge candidate
check_MER = 1;
@@ -447,8 +457,11 @@ static void derive_spatial_merge_candidates(HEVCContext
*s, int x0, int y0,
if (is_available_b1 && is_available_b2)
check_MER_1 = !COMPARE_MV_REFIDX(B2, B1);
-if (is_available_b2 && check_MER && check_MER_1 && nb_merge_cand != 4)
-mergecandlist[nb_merge_cand++] = TAB_MVF_PU(B2);
+if (is_available_b2 && check_MER && check_MER_1 && nb_merge_cand != 4) {
+mergecandlist[nb_merge_cand] = TAB_MVF_PU(B2);
+if (merge_idx == nb_merge_cand) return;
+nb_merge_cand++;
+}
// temporal motion vector candidate
if (s->sh.slice_temporal_mvp_enabled_flag &&
@@ -470,6 +483,7 @@ static void derive_spatial_merge_candidates(HEVCContext *s,
int x0, int y0,
mergecandlist[nb_merge_cand].mv[1] = mv_l1_col;
mergecandlist[nb_merge_cand].ref_idx[1] = 0;
}
+if (merge_idx == nb_merge_cand) return;
nb_merge_cand++;
}
}
@@ -500,6 +514,7 @@ static void derive_spatial_merge_candidates(HEVCContext *s,
int x0, int y0,
mergecandlist[nb_merge_cand].mv[0].y = l0_cand.mv[0].y;
mergecandlist[nb_merge_cand].mv[1].x = l1_cand.mv[1].x;
mergecandlist[nb_merge_cand].mv[1].y = l1_cand.mv[1].y;
+if (merge_idx == nb_merge_cand) return;
nb_merge_cand++;
}
}
@@ -515,6 +530,7 @@ static void derive_spatial_merge_candidates(HEVCContext *s,
int x0, int y0,
mergecandlist[nb_merge_cand].ref_idx[0] = zero_idx < nb_refs ?
zero_idx : 0;
mergecandlist[nb_merge_cand].ref_idx[1] = zero_idx < nb_refs ?
zero_idx : 0;
+if (merge_idx == nb_merge_cand) return;
nb_merge_cand++;
zero_idx++;
}
@@ -545,7 +561,8 @@ void ff_hevc_luma_mv_merge_mode(HEVCContext *s, int x0, int
y0, int nPbW,
ff_hevc_set_neighbour_available(s, x0, y0, nPbW, nPbH);
derive_spatial_merge_candidates(s, x0, y0, nPbW, nPbH, log2_cb_size,
-singleMCLFlag, part_idx, mergecand_list);
+singleMCLFlag, part_idx,
+merge_idx, mergecand_list);
if (mergecand_list[merge_idx].pred_flag == PF_BI &&
(nPbW2 + nPbH2) == 12) {
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 6/9] hevc: derive partially amvp list
When the candidate has been found, no need to derive others.
---
libavcodec/hevc_mvs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/hevc_mvs.c b/libavcodec/hevc_mvs.c
index 0302c88..952a431 100644
--- a/libavcodec/hevc_mvs.c
+++ b/libavcodec/hevc_mvs.c
@@ -737,6 +737,11 @@ void ff_hevc_luma_mv_mvp_mode(HEVCContext *s, int x0, int
y0, int nPbW,
availableFlagLXA0 = MP_MX_LT(A1, pred_flag_index_l1, mxA);
}
+if(availableFlagLXA0 && !mvp_lx_flag) {
+mv->mv[LX] = mxA;
+return;
+}
+
// B candidates
// above right spatial merge candidate
xB0= x0 + nPbW;
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/9] hevc: reduce allocation for split_cu_flag
Allocate this flag with a CU granularity. Furthermore, its prediction only requires one line of flags to be stored, so for simplicity's sake, store only current and previous CTB lines. Reduces allocation by around 2MB for a 1080p stream. --- libavcodec/hevc.c | 5 +++-- libavcodec/hevc.h | 2 +- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c index 99298a8..f8a495f 100644 --- a/libavcodec/hevc.c +++ b/libavcodec/hevc.c @@ -85,7 +85,6 @@ static int pic_arrays_init(HEVCContext *s, const HEVCSPS *sps) int log2_min_cb_size = sps->log2_min_cb_size; int width= sps->width; int height = sps->height; -int pic_size = width * height; int pic_size_in_ctb = ((width >> log2_min_cb_size) + 1) * ((height >> log2_min_cb_size) + 1); int ctb_count= sps->ctb_width * sps->ctb_height; @@ -96,7 +95,7 @@ static int pic_arrays_init(HEVCContext *s, const HEVCSPS *sps) s->sao = av_mallocz_array(ctb_count, sizeof(*s->sao)); s->deblock = av_mallocz_array(ctb_count, sizeof(*s->deblock)); -s->split_cu_flag = av_malloc(pic_size); +s->split_cu_flag = av_malloc(16*sps->min_cb_width); if (!s->sao || !s->deblock || !s->split_cu_flag) goto fail; @@ -1909,6 +1908,8 @@ static int hls_coding_quadtree(HEVCContext *s, int x0, int y0, HEVCLocalContext *lc = s->HEVClc; const int cb_size= 1 << log2_cb_size; int ret; +int log2_min_cb_size = s->sps->log2_min_cb_size; +int min_cb_width = s->sps->min_cb_width; int qp_block_mask = (1<<(s->sps->log2_ctb_size - s->pps->diff_cu_qp_delta_depth)) - 1; lc->ct.depth = cb_depth; diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h index 5f964c3..44d6a6c 100644 --- a/libavcodec/hevc.h +++ b/libavcodec/hevc.h @@ -80,7 +80,7 @@ /** * Value of the luma sample at position (x, y) in the 2D array tab. */ -#define SAMPLE(tab, x, y) ((tab)[(y) * s->sps->width + (x)]) +#define SAMPLE(tab, x, y) ((tab)[(((y)>>log2_min_cb_size)&15) * min_cb_width + ((x)>>log2_min_cb_size)]) #define SAMPLE_CTB(tab, x, y) ((tab)[(y) * min_cb_width + (x)]) #define SAMPLE_CBF(tab, x, y) ((tab)[((y) & ((1
[FFmpeg-devel] [PATCH 4/9] hevc: reduce cu depth allocation
--- libavcodec/hevc.c | 4 ++-- libavcodec/hevc_cabac.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c index 2b37f53..4d3513a 100644 --- a/libavcodec/hevc.c +++ b/libavcodec/hevc.c @@ -100,7 +100,7 @@ static int pic_arrays_init(HEVCContext *s, const HEVCSPS *sps) goto fail; s->skip_flag= av_malloc(16*s->sps->min_cb_width); -s->tab_ct_depth = av_malloc_array(sps->min_cb_height, sps->min_cb_width); +s->tab_ct_depth = av_malloc(16*sps->min_cb_width); if (!s->skip_flag || !s->tab_ct_depth) goto fail; @@ -1682,7 +1682,7 @@ static av_always_inline void set_ct_depth(HEVCContext *s, int x0, int y0, int y; for (y = 0; y < length; y++) -memset(&s->tab_ct_depth[(y_cb + y) * s->sps->min_cb_width + x_cb], +memset(&s->tab_ct_depth[((y_cb + y)&15) * s->sps->min_cb_width + x_cb], ct_depth, length); } diff --git a/libavcodec/hevc_cabac.c b/libavcodec/hevc_cabac.c index 40f5ce1..0923c13 100644 --- a/libavcodec/hevc_cabac.c +++ b/libavcodec/hevc_cabac.c @@ -708,9 +708,9 @@ int ff_hevc_split_coding_unit_flag_decode(HEVCContext *s, int ct_depth, int x0, int y_cb = y0 >> s->sps->log2_min_cb_size; if (s->HEVClc->ctb_left_flag || x0b) -depth_left = s->tab_ct_depth[(y_cb) * s->sps->min_cb_width + x_cb - 1]; +depth_left = s->tab_ct_depth[(y_cb&15) * s->sps->min_cb_width + x_cb - 1]; if (s->HEVClc->ctb_up_flag || y0b) -depth_top = s->tab_ct_depth[(y_cb - 1) * s->sps->min_cb_width + x_cb]; +depth_top = s->tab_ct_depth[((y_cb - 1)&15) * s->sps->min_cb_width + x_cb]; inc += (depth_left > ct_depth); inc += (depth_top > ct_depth); -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/9] hevc: reduce allocation for skip_flag
Save only 2 CTB lines worth of data (i.e. at worst 16 lines).
---
libavcodec/hevc.c | 4 ++--
libavcodec/hevc.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index f8a495f..bed2f5f 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -99,7 +99,7 @@ static int pic_arrays_init(HEVCContext *s, const HEVCSPS *sps)
if (!s->sao || !s->deblock || !s->split_cu_flag)
goto fail;
-s->skip_flag= av_malloc(pic_size_in_ctb);
+s->skip_flag= av_malloc(16*s->sps->min_cb_width);
s->tab_ct_depth = av_malloc_array(sps->min_cb_height, sps->min_cb_width);
if (!s->skip_flag || !s->tab_ct_depth)
goto fail;
@@ -1782,7 +1782,7 @@ static int hls_coding_unit(HEVCContext *s, int x0, int
y0, int log2_cb_size)
if (s->sh.slice_type != I_SLICE) {
uint8_t skip_flag = ff_hevc_skip_flag_decode(s, x0, y0, x_cb, y_cb);
-x = y_cb * min_cb_width + x_cb;
+x = (y_cb&15) * min_cb_width + x_cb;
for (y = 0; y < length; y++) {
memset(&s->skip_flag[x], skip_flag, length);
x += min_cb_width;
diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
index 44d6a6c..8fd8655 100644
--- a/libavcodec/hevc.h
+++ b/libavcodec/hevc.h
@@ -81,7 +81,7 @@
* Value of the luma sample at position (x, y) in the 2D array tab.
*/
#define SAMPLE(tab, x, y) ((tab)[(((y)>>log2_min_cb_size)&15) * min_cb_width +
((x)>>log2_min_cb_size)])
-#define SAMPLE_CTB(tab, x, y) ((tab)[(y) * min_cb_width + (x)])
+#define SAMPLE_CTB(tab, x, y) ((tab)[((y)&15) * min_cb_width + (x)])
#define SAMPLE_CBF(tab, x, y) ((tab)[((y) & ((1nal_unit_type
== NAL_IDR_N_LP)
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/9] hevc: reduce allocation for tab_ipm
Minimal size for PUs is 4x4, so 2 CTB lines represent at most 32 lines.
is_pcm is used for simplicity in the inloop filter, so it can't be
modified equivalently.
---
libavcodec/hevc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index bed2f5f..2b37f53 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -105,7 +105,7 @@ static int pic_arrays_init(HEVCContext *s, const HEVCSPS
*sps)
goto fail;
s->cbf_luma = av_malloc_array(sps->min_tb_width, sps->min_tb_height);
-s->tab_ipm = av_mallocz(min_pu_size);
+s->tab_ipm = av_mallocz(32*sps->min_pu_width);
s->is_pcm = av_malloc(min_pu_size);
if (!s->tab_ipm || !s->cbf_luma || !s->is_pcm)
goto fail;
@@ -1605,9 +1605,9 @@ static int luma_intra_pred_mode(HEVCContext *s, int x0,
int y0, int pu_size,
int y0b = y0 & ((1 << s->sps->log2_ctb_size) - 1);
int cand_up = (lc->ctb_up_flag || y0b) ?
-s->tab_ipm[(y_pu - 1) * min_pu_width + x_pu] : INTRA_DC;
+s->tab_ipm[((y_pu - 1)&31) * min_pu_width + x_pu] :
INTRA_DC;
int cand_left = (lc->ctb_left_flag || x0b) ?
-s->tab_ipm[y_pu * min_pu_width + x_pu - 1] : INTRA_DC;
+s->tab_ipm[(y_pu&31) * min_pu_width + x_pu - 1] :
INTRA_DC;
int y_ctb = (y0 >> (s->sps->log2_ctb_size)) << (s->sps->log2_ctb_size);
@@ -1662,7 +1662,7 @@ static int luma_intra_pred_mode(HEVCContext *s, int x0,
int y0, int pu_size,
if (!size_in_pus)
size_in_pus = 1;
for (i = 0; i < size_in_pus; i++) {
-memset(&s->tab_ipm[(y_pu + i) * min_pu_width + x_pu],
+memset(&s->tab_ipm[((y_pu + i)&31) * min_pu_width + x_pu],
intra_pred_mode, size_in_pus);
for (j = 0; j < size_in_pus; j++) {
@@ -1742,7 +1742,7 @@ static void
intra_prediction_unit_default_value(HEVCContext *s,
if (size_in_pus == 0)
size_in_pus = 1;
for (j = 0; j < size_in_pus; j++)
-memset(&s->tab_ipm[(y_pu + j) * min_pu_width + x_pu], INTRA_DC,
size_in_pus);
+memset(&s->tab_ipm[((y_pu + j)&31) * min_pu_width + x_pu], INTRA_DC,
size_in_pus);
if (lc->cu.pred_mode == MODE_INTRA)
for (j = 0; j < size_in_pus; j++)
for (k = 0; k < size_in_pus; k++)
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 9/9] hevc: reorder loops
---
libavcodec/hevc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index f2bbe91..873f1dc 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -1452,8 +1452,8 @@ static void hls_prediction_unit(HEVCContext *s, int x0,
int y0,
x_pu = x0 >> s->sps->log2_min_pu_size;
y_pu = y0 >> s->sps->log2_min_pu_size;
-for (i = 0; i < nPbW >> s->sps->log2_min_pu_size; i++)
-for (j = 0; j < nPbH >> s->sps->log2_min_pu_size; j++)
+for (j = 0; j < nPbH >> s->sps->log2_min_pu_size; j++)
+for (i = 0; i < nPbW >> s->sps->log2_min_pu_size; i++)
tab_mvf[(y_pu + j) * min_pu_width + x_pu + i] = current_mv;
} else { /* MODE_INTER */
lc->pu.merge_flag = ff_hevc_merge_flag_decode(s);
@@ -1468,8 +1468,8 @@ static void hls_prediction_unit(HEVCContext *s, int x0,
int y0,
x_pu = x0 >> s->sps->log2_min_pu_size;
y_pu = y0 >> s->sps->log2_min_pu_size;
-for (i = 0; i < nPbW >> s->sps->log2_min_pu_size; i++)
-for (j = 0; j < nPbH >> s->sps->log2_min_pu_size; j++)
+for (j = 0; j < nPbH >> s->sps->log2_min_pu_size; j++)
+for (i = 0; i < nPbW >> s->sps->log2_min_pu_size; i++)
tab_mvf[(y_pu + j) * min_pu_width + x_pu + i] = current_mv;
} else {
enum InterPredIdc inter_pred_idc = PRED_L0;
@@ -1517,8 +1517,8 @@ static void hls_prediction_unit(HEVCContext *s, int x0,
int y0,
x_pu = x0 >> s->sps->log2_min_pu_size;
y_pu = y0 >> s->sps->log2_min_pu_size;
-for (i = 0; i < nPbW >> s->sps->log2_min_pu_size; i++)
-for(j = 0; j < nPbH >> s->sps->log2_min_pu_size; j++)
+for(j = 0; j < nPbH >> s->sps->log2_min_pu_size; j++)
+for (i = 0; i < nPbW >> s->sps->log2_min_pu_size; i++)
tab_mvf[(y_pu + j) * min_pu_width + x_pu + i] = current_mv;
}
}
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 7/9] hevc: use intreadwrite
When dealing with MVs, both components may be processed at a time.
---
libavcodec/hevc.c | 3 +--
libavcodec/hevc_mvs.c | 23 +--
2 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index 4d3513a..f2bbe91 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -1500,8 +1500,7 @@ static void hls_prediction_unit(HEVCContext *s, int x0,
int y0,
}
if (s->sh.mvd_l1_zero_flag == 1 && inter_pred_idc == PRED_BI) {
-lc->pu.mvd.x = 0;
-lc->pu.mvd.y = 0;
+AV_ZERO32(&lc->pu.mvd);
} else {
ff_hevc_hls_mvd_coding(s, x0, y0, 1);
}
diff --git a/libavcodec/hevc_mvs.c b/libavcodec/hevc_mvs.c
index 952a431..e900bd0 100644
--- a/libavcodec/hevc_mvs.c
+++ b/libavcodec/hevc_mvs.c
@@ -125,6 +125,7 @@ static int isDiffMER(HEVCContext *s, int xN, int yN, int
xP, int yP)
yN >> plevel == yP >> plevel;
}
+#define MATCH_MV(x) (AV_RN32(&A.x) == AV_RN32(&B.x))
#define MATCH(x) (A.x == B.x)
// check if the mv's and refidx are the same between A and B
@@ -134,12 +135,12 @@ static int compareMVrefidx(struct MvField A, struct
MvField B)
int b_pf = B.pred_flag;
if (a_pf == b_pf) {
if (a_pf == PF_BI) {
-return MATCH(ref_idx[0]) && MATCH(mv[0].x) && MATCH(mv[0].y) &&
- MATCH(ref_idx[1]) && MATCH(mv[1].x) && MATCH(mv[1].y);
+return MATCH(ref_idx[0]) && MATCH_MV(mv[0]) &&
+ MATCH(ref_idx[1]) && MATCH_MV(mv[1]);
} else if (a_pf == PF_L0) {
-return MATCH(ref_idx[0]) && MATCH(mv[0].x) && MATCH(mv[0].y);
+return MATCH(ref_idx[0]) && MATCH_MV(mv[0]);
} else if (a_pf == PF_L1) {
-return MATCH(ref_idx[1]) && MATCH(mv[1].x) && MATCH(mv[1].y);
+return MATCH(ref_idx[1]) && MATCH_MV(mv[1]);
}
}
return 0;
@@ -505,15 +506,12 @@ static void derive_spatial_merge_candidates(HEVCContext
*s, int x0, int y0,
if ((l0_cand.pred_flag & PF_L0) && (l1_cand.pred_flag & PF_L1) &&
(refPicList[0].list[l0_cand.ref_idx[0]] !=
refPicList[1].list[l1_cand.ref_idx[1]] ||
- l0_cand.mv[0].x != l1_cand.mv[1].x ||
- l0_cand.mv[0].y != l1_cand.mv[1].y)) {
+ AV_RN32(&l0_cand.mv[0]) != AV_RN32(&l1_cand.mv[1]))) {
mergecandlist[nb_merge_cand].ref_idx[0] = l0_cand.ref_idx[0];
mergecandlist[nb_merge_cand].ref_idx[1] = l1_cand.ref_idx[1];
mergecandlist[nb_merge_cand].pred_flag= PF_BI;
-mergecandlist[nb_merge_cand].mv[0].x = l0_cand.mv[0].x;
-mergecandlist[nb_merge_cand].mv[0].y = l0_cand.mv[0].y;
-mergecandlist[nb_merge_cand].mv[1].x = l1_cand.mv[1].x;
-mergecandlist[nb_merge_cand].mv[1].y = l1_cand.mv[1].y;
+AV_WN32(&mergecandlist[nb_merge_cand].mv[0],
AV_RN32(&l0_cand.mv[0]));
+AV_WN32(&mergecandlist[nb_merge_cand].mv[1],
AV_RN32(&l1_cand.mv[1]));
if (merge_idx == nb_merge_cand) return;
nb_merge_cand++;
}
@@ -523,10 +521,7 @@ static void derive_spatial_merge_candidates(HEVCContext
*s, int x0, int y0,
// append Zero motion vector candidates
while (nb_merge_cand < s->sh.max_num_merge_cand) {
mergecandlist[nb_merge_cand].pred_flag= PF_L0 + ((s->sh.slice_type
== B_SLICE) << 1);
-mergecandlist[nb_merge_cand].mv[0].x = 0;
-mergecandlist[nb_merge_cand].mv[0].y = 0;
-mergecandlist[nb_merge_cand].mv[1].x = 0;
-mergecandlist[nb_merge_cand].mv[1].y = 0;
+AV_ZERO64(mergecandlist[nb_merge_cand].mv);
mergecandlist[nb_merge_cand].ref_idx[0] = zero_idx < nb_refs ?
zero_idx : 0;
mergecandlist[nb_merge_cand].ref_idx[1] = zero_idx < nb_refs ?
zero_idx : 0;
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 8/9] hevc: simplify rounding
---
libavcodec/hevc_mvs.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/hevc_mvs.c b/libavcodec/hevc_mvs.c
index e900bd0..b2bea4e 100644
--- a/libavcodec/hevc_mvs.c
+++ b/libavcodec/hevc_mvs.c
@@ -276,8 +276,8 @@ static int temporal_luma_motion_vector(HEVCContext *s, int
x0, int y0,
(y0 >> s->sps->log2_ctb_size) == (y >> s->sps->log2_ctb_size) &&
y < s->sps->height &&
x < s->sps->width) {
-x = ((x >> 4) << 4);
-y = ((y >> 4) << 4);
+x &= -16;
+y &= -16;
x_pu = x >> s->sps->log2_min_pu_size;
y_pu = y >> s->sps->log2_min_pu_size;
temp_col = TAB_MVF(x_pu, y_pu);
@@ -288,8 +288,8 @@ static int temporal_luma_motion_vector(HEVCContext *s, int
x0, int y0,
if (tab_mvf && !availableFlagLXCol) {
x = x0 + (nPbW >> 1);
y = y0 + (nPbH >> 1);
-x = ((x >> 4) << 4);
-y = ((y >> 4) << 4);
+x &= -16;
+y &= -16;
x_pu = x >> s->sps->log2_min_pu_size;
y_pu = y >> s->sps->log2_min_pu_size;
temp_col = TAB_MVF(x_pu, y_pu);
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
