[FFmpeg-devel] [PATCH] libavformat/icecast.c Add Icecast protocol
From: ePirat
Fixed things.
---
Add Icecast protocol, a convenience wrapper for the HTTP protocol
---
Changelog| 3 +
configure| 1 +
doc/general.texi | 1 +
doc/protocols.texi | 42 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/icecast.c| 228 +++
libavformat/version.h| 4 +-
8 files changed, 279 insertions(+), 2 deletions(-)
create mode 100644 libavformat/icecast.c
diff --git a/Changelog b/Changelog
index 07cf1cf..821525e 100644
--- a/Changelog
+++ b/Changelog
@@ -1,6 +1,9 @@
Entries are sorted chronologically from oldest to youngest within each release,
releases are sorted from youngest to oldest.
+:
+- Icecast protocol
+
version 2.3:
- AC3 fixed-point decoding
- shuffleplanes filter
diff --git a/configure b/configure
index b4ec1e6..a0b2354 100755
--- a/configure
+++ b/configure
@@ -2483,6 +2483,7 @@ gopher_protocol_select="network"
http_protocol_select="tcp_protocol"
httpproxy_protocol_select="tcp_protocol"
https_protocol_select="tls_protocol"
+icecast_protocol_select="http"
librtmp_protocol_deps="librtmp"
librtmpe_protocol_deps="librtmp"
librtmps_protocol_deps="librtmp"
diff --git a/doc/general.texi b/doc/general.texi
index 35db917..9ce0b31 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1055,6 +1055,7 @@ performance on systems without hardware floating point
support).
@item HLS @tab X
@item HTTP @tab X
@item HTTPS@tab X
+@item Icecast @tab X
@item MMSH @tab X
@item MMST @tab X
@item pipe @tab X
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 1cd96cc..cb75d92 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -293,6 +293,48 @@ The required syntax to play a stream specifying a cookie
is:
ffplay -cookies "nlqptid=nltid=tsn; path=/; domain=somedomain.com;"
http://somedomain.com/somestream.m3u8
@end example
+@section Icecast
+
+Icecast protocol
+
+@table @option
+@item ice_genre
+Set the genre of the stream.
+
+@item ice_name
+Set the name of the stream.
+
+@item ice_description
+Set the description of the stream.
+
+@item ice_url
+Set the stream website url.
+
+@item ice_public
+Set if the stream should be public.
+Default is 0 (not public).
+
+@item ice_password
+Password for the mountpoint.
+
+@item legacy_icecast
+If set to 1, enable support for legacy Icecast (Version < 2.4), using the
SOURCE method
+instead of the PUT method.
+
+@item content_type
+Set a specific content type for the stream.
+This MUST be set if streaming else than audio/mpeg
+
+@item user_agent
+Override the User-Agent header. If not specified the protocol will use a
+string describing the libavformat build. ("Lavf/")
+
+@end table
+
+@example
+icecast://[@var{username}[:@var{password}]@@]@var{server}:@var{port}/@var{mountpoint}
+@end example
+
@section mmst
MMS (Microsoft Media Server) protocol over TCP.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 9017e06..d2d0d87 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -484,6 +484,7 @@ OBJS-$(CONFIG_HLS_PROTOCOL) += hlsproto.o
OBJS-$(CONFIG_HTTP_PROTOCOL) += http.o httpauth.o urldecode.o
OBJS-$(CONFIG_HTTPPROXY_PROTOCOL)+= http.o httpauth.o urldecode.o
OBJS-$(CONFIG_HTTPS_PROTOCOL)+= http.o httpauth.o urldecode.o
+OBJS-$(CONFIG_ICECAST_PROTOCOL) += icecast.o
OBJS-$(CONFIG_MMSH_PROTOCOL) += mmsh.o mms.o asf.o
OBJS-$(CONFIG_MMST_PROTOCOL) += mmst.o mms.o asf.o
OBJS-$(CONFIG_MD5_PROTOCOL) += md5proto.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 00de817..5599bae 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -347,6 +347,7 @@ void av_register_all(void)
REGISTER_PROTOCOL(HTTP, http);
REGISTER_PROTOCOL(HTTPPROXY,httpproxy);
REGISTER_PROTOCOL(HTTPS,https);
+REGISTER_PROTOCOL(ICECAST, icecast);
REGISTER_PROTOCOL(MMSH, mmsh);
REGISTER_PROTOCOL(MMST, mmst);
REGISTER_PROTOCOL(MD5, md5);
diff --git a/libavformat/icecast.c b/libavformat/icecast.c
new file mode 100644
index 000..38b4788
--- /dev/null
+++ b/libavformat/icecast.c
@@ -0,0 +1,228 @@
+/*
+ * Icecast Protocol Handler
+ * Copyright (c) 2014 Marvin Scholz
+ *
+ * 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
Re: [FFmpeg-devel] [PATCH 1/3] web/download: Fix redundant git word on snapshot button
On Tue, Jul 22, 2014 at 10:40:41AM -0800, Lou Logan wrote: > On Mon, 21 Jul 2014 20:37:34 +0200, db0company wrote: > > > --- > > src/download |2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/src/download b/src/download > > index 5eb0b0c..7ddb4e4 100644 > > --- a/src/download > > +++ b/src/download > > @@ -137,7 +137,7 @@ > > > > > > > > - Git Snapshot > > + Snapshot > > > > http://git.videolan.org/?p=ffmpeg.git;a=tree"; > > class="btn btn-success"> > >Browse > > Fine with me. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] web/download: Fix link for linux static builds 64-bit kernel 2.6.32 and above
On Tue, Jul 22, 2014 at 10:28:46AM -0800, Lou Logan wrote: > On Mon, 21 Jul 2014 20:37:35 +0200, db0company wrote: > > > --- > > src/download |2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/src/download b/src/download > > index 7ddb4e4..fb30ed0 100644 > > --- a/src/download > > +++ b/src/download > > @@ -72,7 +72,7 @@ > > > > > href="http://ffmpeg.gusari.org/static/";>32-bit and > > 64-bit with kernel 3.2.x and above > > - > href="http://ffmpeg.gusari.org/static/";>64-bit > > + > href="http://johnvansickle.com/ffmpeg/";>64-bit > > with kernel 2.6.32 and above > > > > > > Looks good. Thanks! applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Fix compilation with nasm
hi Le 23 juil. 2014 à 01:37, Michael Niedermayer a écrit : > On Wed, Jul 23, 2014 at 12:52:48AM +0200, Carl Eugen Hoyos wrote: >> On Wednesday 23 July 2014 12:43:06 am Ronald S. Bultje wrote: >>> Hi, >>> >>> On Tue, Jul 22, 2014 at 5:45 PM, Carl Eugen Hoyos wrote: Hi! Attached patch fixes compilation with nasm (and passes fate) here, sorry if it is complete nonsense. >>> >>> You probably want "movd m13, betad", not "movq m13, betaq". >> >> I had tried "betaqd" first... >> >> New patch attached, thank you, Carl Eugen > >> hevc_deblock.asm |4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> 0744658c6ddf8c4cc16dd06608f003b705d792ed >> 0001-avcodec-x86-hevc_deblock-Fix-compilation-with-nasm.patch >> From f437354e0ce05183aeffd7bb2ce2e844b3bd31cc Mon Sep 17 00:00:00 2001 >> From: Carl Eugen Hoyos >> Date: Wed, 23 Jul 2014 00:51:29 +0200 >> Subject: [PATCH] avcodec/x86/hevc_deblock: Fix compilation with nasm. > > LGTM > ok Mickaël ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Backport to 2.2/2.1 (Fwd: [Bug 3295] New: [Patch] Backport ffmpeg commit cdf6eb5a97, vc1: Do not return an error when skipping b frames)
Dear developers, I received the following request from our RPMFusion FFmpeg package user. Please backport the commit cdf6eb5a97 to branches 2.2 and 2.1. Regards, Dominik - Forwarded message from RPM Fusion Bugzilla - Date: Sun, 20 Jul 2014 06:33:53 + From: RPM Fusion Bugzilla Subject: [Bug 3295] New: [Patch] Backport ffmpeg commit cdf6eb5a97, vc1: Do not return an error when skipping b frames To: r...@greysector.net https://bugzilla.rpmfusion.org/show_bug.cgi?id=3295 Bug #: 3295 Summary: [Patch] Backport ffmpeg commit cdf6eb5a97, vc1: Do not return an error when skipping b frames Classification: Unclassified Product: Fedora Version: 20 Platform: All OS/Version: GNU/Linux Status: NEW Severity: normal Priority: P5 Component: ffmpeg AssignedTo: r...@greysector.net ReportedBy: jand...@gmx.net CC: kwiz...@gmail.com Created attachment 1316 --> https://bugzilla.rpmfusion.org/attachment.cgi?id=1316 ffmpeg commit cdf6eb5a97 This fixes an issue that will cause mpv to fall back to software decoding when trying to play VC1 encoded video with hw accel. The fix is in ffmpeg HEAD and the new 2.3 release, but hasn't made it into the other branches of ffmpeg (yet?). The patch is simply diff'd from the ffmpeg git repository and applies cleanly to ffmpeg 2.1.5 (fc20) as well as 2.2.5 (development). - End forwarded message - -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Fix compilation with nasm
Mickaël Raulet gmail.com> writes: > >> Subject: [PATCH] avcodec/x86/hevc_deblock: Fix compilation with nasm. > > > > LGTM > > ok Patch applied. Thanks everybody, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Backport to 2.2/2.1 (Fwd: [Bug 3295] New: [Patch] Backport ffmpeg commit cdf6eb5a97, vc1: Do not return an error when skipping b frames)
On Wed, Jul 23, 2014 at 10:12:14AM +0200, Dominik 'Rathann' Mierzejewski wrote: > Dear developers, > I received the following request from our RPMFusion FFmpeg package user. > Please backport the commit cdf6eb5a97 to branches 2.2 and 2.1. done, will be in the next release from these branches [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: add single file mode
On 2014-07-22 07:16, Eli Kara wrote: > > > HLS version 4 offers the possibility to keep the media file whole instead > > of splitting it. In that case, segments are specified with byte ranges. > > > We introduce a new '-hls_flags' option for the hlsenc muxer, with a single > > flag for the time being, 'single_file'. > > Nicolas, just out of curiosity - is there a valid use case for a single > video file in HLS? After all, the whole point of the protocol is to allow > adaptive streaming, theoretically allowing switching resolutions and > bitrates on-the-fly. > > I'll be the last one to oppose adding something from the standard but I'm > just curious. It depends on how you store your media files. When you already have whole media files, and you just want to be able to stream them while keeping them whole for other purposes, it's useful to have a single file mode. Of course if you want to be able to switch resolution between segments, you will have to split the file. The fact that HLS version >=4 adds support for byte ranges shows that I am not the only one who needs this feature :) -- 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] Backport to 2.2/2.1 (Fwd: [Bug 3295] New: [Patch] Backport ffmpeg commit cdf6eb5a97, vc1: Do not return an error when skipping b frames)
(Bcc'ing the original reporter) Hi Michael, On Wednesday, 23 July 2014 at 10:52, Michael Niedermayer wrote: > On Wed, Jul 23, 2014 at 10:12:14AM +0200, Dominik 'Rathann' Mierzejewski > wrote: > > Dear developers, > > I received the following request from our RPMFusion FFmpeg package user. > > Please backport the commit cdf6eb5a97 to branches 2.2 and 2.1. > > done, will be in the next release from these branches Excellent, thanks a lot. Regards, Dominik -- MPlayer http://mplayerhq.hu | RPMFusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web/projects: move projects to wiki
On Wed, Jul 23, 2014 at 3:06 AM, Timothy Gu wrote: > On Tue, Jul 22, 2014 at 5:26 PM, Lou Logan wrote: >> This allows users to add their own project to the list. >> --- >> A redirect would be nicer, but I'm feeling lazy. I may address that >> later, but for now I just wanted to update the links since I already >> made the page on the wiki. >> >> src/projects | 166 >> + >> src/template_head2 | 2 +- >> 2 files changed, 4 insertions(+), 164 deletions(-) > > [...] > >> diff --git a/src/template_head2 b/src/template_head2 >> index e7eda54..31c4dda 100644 >> --- a/src/template_head2 >> +++ b/src/template_head2 >> @@ -28,7 +28,7 @@ >>Forums >>Bug Reports >>http://trac.ffmpeg.org";>Wiki >> - Projects >> + > href="http://trac.ffmpeg.org/wiki/Projects";>Projects >> >> >>Developers > > I would simply remove the menu item, but feel free to push with it. I agree. + Maybe mention it with a direct link in another page. -- db0 - Deby Barbara Lepage http://db0.fr/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avio: Introduce avio_read_to_bprint(avioctx, bp, max_size)
---
libavformat/avio.h| 9 +
libavformat/aviobuf.c | 18 ++
2 files changed, 27 insertions(+)
diff --git a/libavformat/avio.h b/libavformat/avio.h
index 4004b6f..9b16843 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -31,6 +31,7 @@
#include "libavutil/common.h"
#include "libavutil/dict.h"
#include "libavutil/log.h"
+#include "libavutil/bprint.h"
#include "libavformat/version.h"
@@ -500,4 +501,12 @@ int avio_pause(AVIOContext *h, int pause);
int64_t avio_seek_time(AVIOContext *h, int stream_index,
int64_t timestamp, int flags);
+/**
+ * Read contents of h into print buffer, up to max_size bytes, or up to EOF.
+ *
+ * @return 0 for success (max_size bytes read or EOF reached), negative error
+ * code otherwise
+ */
+int avio_read_to_bprint(AVIOContext *h, AVBPrint *pb, size_t max_size);
+
#endif /* AVFORMAT_AVIO_H */
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 738459e..463d90a 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -953,6 +953,24 @@ int64_t avio_seek_time(AVIOContext *s, int stream_index,
return ret;
}
+int avio_read_to_bprint(AVIOContext *h, AVBPrint *pb, size_t max_size)
+{
+int ret;
+char buf[1024];
+while (max_size) {
+ret = avio_read(h, buf, FFMIN(max_size, sizeof(buf)));
+if (ret == AVERROR_EOF)
+return 0;
+if (ret <= 0)
+return ret;
+av_bprint_append_data(pb, buf, ret);
+if (!av_bprint_is_complete(pb))
+return AVERROR(ENOMEM);
+max_size -= ret;
+}
+return 0;
+}
+
/* output in a dynamic buffer */
typedef struct DynBuffer {
--
1.8.5.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] lavd/lavfi: work with non-mappable files for graph_file option
Example of non-mappable file is /dev/stdin. Previously passing it as
graph_file value returned error.
---
libavdevice/lavfi.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
index d1904dd..f1c88ac 100644
--- a/libavdevice/lavfi.c
+++ b/libavdevice/lavfi.c
@@ -115,23 +115,23 @@ av_cold static int lavfi_read_header(AVFormatContext
*avctx)
}
if (lavfi->graph_filename) {
-uint8_t *file_buf, *graph_buf;
-size_t file_bufsize;
-ret = av_file_map(lavfi->graph_filename,
- &file_buf, &file_bufsize, 0, avctx);
+AVBPrint graph_file_pb;
+AVIOContext *avio = NULL;
+ret = avio_open(&avio, lavfi->graph_filename, AVIO_FLAG_READ);
if (ret < 0)
-goto end;
-
-/* create a 0-terminated string based on the read file */
-graph_buf = av_malloc(file_bufsize + 1);
-if (!graph_buf) {
-av_file_unmap(file_buf, file_bufsize);
-FAIL(AVERROR(ENOMEM));
+FAIL(ret);
+av_bprint_init(&graph_file_pb, 0, AV_BPRINT_SIZE_UNLIMITED);
+ret = avio_read_to_bprint(avio, &graph_file_pb, INT_MAX);
+avio_close(avio);
+av_bprint_chars(&graph_file_pb, '\0', 1);
+if (!ret && !av_bprint_is_complete(&graph_file_pb))
+ret = AVERROR(ENOMEM);
+if (ret) {
+av_bprint_finalize(&graph_file_pb, NULL);
+FAIL(ret);
}
-memcpy(graph_buf, file_buf, file_bufsize);
-graph_buf[file_bufsize] = 0;
-av_file_unmap(file_buf, file_bufsize);
-lavfi->graph_str = graph_buf;
+if ((ret = av_bprint_finalize(&graph_file_pb, &lavfi->graph_str)))
+FAIL(ret);
}
if (!lavfi->graph_str)
--
1.8.5.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Inconsistent UDP output packet size - patch
First, the patch affects the code which is used in a lot of scenarios, not only UDP, and it would change the behaviour in many cases. In some scenarious the introduced effect (delayed writeout) would be undesired. So consider adding special option/flag to enable this new behaviour. "!s->max_packet_size" clause is strange, as Benoit has already said. The second chunk of patch is totally strange to me. I'd just move "s->buf_ptr = s->buffer;" line into previous conditional block, i believe that condition "s->buf_ptr < s->buffer" is not supposed to happen. P. S. In my opinion the issue #2748 is not a bug. The produced stream is perfectly OK and shouldn't break anything, probably except some oversimplified artisanal software. -- Andrey Utkin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Inconsistent UDP output packet size - patch
>>P. S. In my opinion the issue #2748 is not a bug. The produced stream is perfectly OK and shouldn't break anything, probably except some oversimplified artisanal software. Many hardware receivers can't stable playing streams with various packet size 2014-07-23 19:27 GMT+06:00 Andrey Utkin : > First, the patch affects the code which is used in a lot of scenarios, > not only UDP, and it would change the behaviour in many cases. In some > scenarious the introduced effect (delayed writeout) would be > undesired. So consider adding special option/flag to enable this new > behaviour. > > "!s->max_packet_size" clause is strange, as Benoit has already said. > > The second chunk of patch is totally strange to me. I'd just move > "s->buf_ptr = s->buffer;" line into previous conditional block, i > believe that condition "s->buf_ptr < s->buffer" is not supposed to > happen. > > P. S. In my opinion the issue #2748 is not a bug. The produced stream > is perfectly OK and shouldn't break anything, probably except some > oversimplified artisanal software. > > -- > Andrey Utkin > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Inconsistent UDP output packet size - patch
On 23 July 2014 14:32, Konstantin Shpinev wrote: >>>P. S. In my opinion the issue #2748 is not a bug. The produced stream > is perfectly OK and shouldn't break anything, probably except some > oversimplified artisanal software. > > Many hardware receivers can't stable playing streams with various packet > size A lot of analysis equipment will alarm as well. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] h264 parser: detect new extradata on frame parsing.
Try to detect new extradata when parsing frames, and decode it.
Fixes issue #3787
---
libavcodec/h264_parser.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index ea0ab98..c8276a7 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -489,6 +489,40 @@ static int h264_parse(AVCodecParserContext *s,
}
}
+/* See if this is extradata */
+if (h->is_avc &&
+buf_size >= 9 &&
+buf[0] == 1 &&
+(buf[4] & 0xFC) == 0xFC &&
+(buf[5] & 0x1F) &&
+buf[8] == 0x67) {
+
+/* Skip the SPSs */
+int cnt = buf[5] & 0x1f;
+const uint8_t *p = buf + 6;
+while (cnt--) {
+int nalsize = AV_RB16(p) + 2;
+if (nalsize > buf_size - (p - buf) || p[2] != 0x67)
+goto not_extra;
+p += nalsize;
+}
+
+/* Skip the PPSs */
+cnt = *p++;
+if (!cnt)
+goto not_extra;
+while (cnt--) {
+int nalsize = AV_RB16(p) + 2;
+if (nalsize > buf_size - (p - buf) || p[2] != 0x68)
+goto not_extra;
+p += nalsize;
+}
+
+/* Decode (new) extradata */
+return ff_h264_decode_extradata(h, buf, buf_size);
+}
+
+not_extra:
parse_nal_units(s, avctx, buf, buf_size);
if (h->sei_cpb_removal_delay >= 0) {
--
2.0.1.442.g7fe6834
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Inconsistent UDP output packet size - patch
Konstantin, Kieran - could you please give some examples? This would be beneficial at least for justification in commit message. -- Andrey Utkin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264 parser: detect new extradata on frame parsing.
Am 23.07.2014 15:49 schrieb "Benoit Fouet" :
>
> Try to detect new extradata when parsing frames, and decode it.
> Fixes issue #3787
> ---
> libavcodec/h264_parser.c | 34 ++
> 1 file changed, 34 insertions(+)
>
> diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
> index ea0ab98..c8276a7 100644
> --- a/libavcodec/h264_parser.c
> +++ b/libavcodec/h264_parser.c
> @@ -489,6 +489,40 @@ static int h264_parse(AVCodecParserContext *s,
> }
> }
>
> +/* See if this is extradata */
> +if (h->is_avc &&
> +buf_size >= 9 &&
> +buf[0] == 1 &&
> +(buf[4] & 0xFC) == 0xFC &&
> +(buf[5] & 0x1F) &&
> +buf[8] == 0x67) {
> +
> +/* Skip the SPSs */
> +int cnt = buf[5] & 0x1f;
> +const uint8_t *p = buf + 6;
> +while (cnt--) {
> +int nalsize = AV_RB16(p) + 2;
> +if (nalsize > buf_size - (p - buf) || p[2] != 0x67)
> +goto not_extra;
> +p += nalsize;
> +}
> +
> +/* Skip the PPSs */
> +cnt = *p++;
> +if (!cnt)
> +goto not_extra;
> +while (cnt--) {
> +int nalsize = AV_RB16(p) + 2;
> +if (nalsize > buf_size - (p - buf) || p[2] != 0x68)
> +goto not_extra;
> +p += nalsize;
> +}
> +
> +/* Decode (new) extradata */
> +return ff_h264_decode_extradata(h, buf, buf_size);
> +}
> +
> +not_extra:
> parse_nal_units(s, avctx, buf, buf_size);
>
> if (h->sei_cpb_removal_delay >= 0) {
> --
> 2.0.1.442.g7fe6834
>
Having AVC style extradata in the middle of a stream seems like an invalid
file. The stream should only include NALUs, with start code or with size
prefix, but not random extra data.
I'm not liking such a hack, especially in the parser, as the decoder and
parser could even use separate context (parsing is typically done in the
demuxing step)
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264 parser: detect new extradata on frame parsing.
Hi, - Mail original - > Am 23.07.2014 15:49 schrieb "Benoit Fouet" : > > > > Try to detect new extradata when parsing frames, and decode it. > > Fixes issue #3787 > > --- > > libavcodec/h264_parser.c | 34 ++ > > 1 file changed, 34 insertions(+) [...] > Having AVC style extradata in the middle of a stream seems like an > invalid > file. The stream should only include NALUs, with start code or with > size > prefix, but not random extra data. > I cannot comment on this, my knowledge being very limited. If you think that the file attached to #3787 is invalid, could you comment on the bug tracker? > I'm not liking such a hack, especially in the parser, as the decoder > and > parser could even use separate context (parsing is typically done in > the > demuxing step) > The parser already decodes extradata using the same method (see got_first at the beginning of the same h264_parse function). -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264 parser: detect new extradata on frame parsing.
On Wed, Jul 23, 2014 at 03:49:43PM +0200, Benoit Fouet wrote: > Try to detect new extradata when parsing frames, and decode it. > Fixes issue #3787 > --- > libavcodec/h264_parser.c | 34 ++ > 1 file changed, 34 insertions(+) fixed differently skiping such midstream extradata in the parser like your patch does could though also make sense but calling ff_h264_decode_extradata() midstream in the parser could be risky if the context is also used by a decoder [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264 parser: detect new extradata on frame parsing.
On Wed, Jul 23, 2014 at 04:05:43PM +0200, Hendrik Leppkes wrote:
> Am 23.07.2014 15:49 schrieb "Benoit Fouet" :
> >
> > Try to detect new extradata when parsing frames, and decode it.
> > Fixes issue #3787
> > ---
> > libavcodec/h264_parser.c | 34 ++
> > 1 file changed, 34 insertions(+)
> >
> > diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
> > index ea0ab98..c8276a7 100644
> > --- a/libavcodec/h264_parser.c
> > +++ b/libavcodec/h264_parser.c
> > @@ -489,6 +489,40 @@ static int h264_parse(AVCodecParserContext *s,
> > }
> > }
> >
> > +/* See if this is extradata */
> > +if (h->is_avc &&
> > +buf_size >= 9 &&
> > +buf[0] == 1 &&
> > +(buf[4] & 0xFC) == 0xFC &&
> > +(buf[5] & 0x1F) &&
> > +buf[8] == 0x67) {
> > +
> > +/* Skip the SPSs */
> > +int cnt = buf[5] & 0x1f;
> > +const uint8_t *p = buf + 6;
> > +while (cnt--) {
> > +int nalsize = AV_RB16(p) + 2;
> > +if (nalsize > buf_size - (p - buf) || p[2] != 0x67)
> > +goto not_extra;
> > +p += nalsize;
> > +}
> > +
> > +/* Skip the PPSs */
> > +cnt = *p++;
> > +if (!cnt)
> > +goto not_extra;
> > +while (cnt--) {
> > +int nalsize = AV_RB16(p) + 2;
> > +if (nalsize > buf_size - (p - buf) || p[2] != 0x68)
> > +goto not_extra;
> > +p += nalsize;
> > +}
> > +
> > +/* Decode (new) extradata */
> > +return ff_h264_decode_extradata(h, buf, buf_size);
> > +}
> > +
> > +not_extra:
> > parse_nal_units(s, avctx, buf, buf_size);
> >
> > if (h->sei_cpb_removal_delay >= 0) {
> > --
> > 2.0.1.442.g7fe6834
> >
>
> Having AVC style extradata in the middle of a stream seems like an invalid
> file. The stream should only include NALUs, with start code or with size
> prefix, but not random extra data.
From a quick look at the flv spec i dont see why this would be invalid
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have often repented speaking, but never of holding my tongue.
-- Xenocrates
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avio: Introduce avio_read_to_bprint(avioctx, bp, max_size)
On Wed, Jul 23, 2014 at 04:12:38PM +0300, Andrey Utkin wrote: > --- > libavformat/avio.h| 9 + > libavformat/aviobuf.c | 18 ++ > 2 files changed, 27 insertions(+) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavd/lavfi: work with non-mappable files for graph_file option
On Wed, Jul 23, 2014 at 04:12:39PM +0300, Andrey Utkin wrote: > Example of non-mappable file is /dev/stdin. Previously passing it as > graph_file value returned error. > --- > libavdevice/lavfi.c | 30 +++--- > 1 file changed, 15 insertions(+), 15 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] x86: hevcdsp: align
This should be mostly cosmetics.
--
Christophe
From 77b78cba2d6a27f20293e6ecfce047b9f3c79335 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Tue, 22 Jul 2014 10:57:34 +0200
Subject: [PATCH 01/10] x86: hevcdsp: align
---
libavcodec/x86/hevcdsp_init.c | 56 +--
1 file changed, 27 insertions(+), 29 deletions(-)
diff --git a/libavcodec/x86/hevcdsp_init.c b/libavcodec/x86/hevcdsp_init.c
index 6759863..f7c35fd 100644
--- a/libavcodec/x86/hevcdsp_init.c
+++ b/libavcodec/x86/hevcdsp_init.c
@@ -424,24 +424,23 @@ void ff_hevcdsp_init_x86(HEVCDSPContext *c, const int bit_depth)
if (bit_depth == 8) {
if (EXTERNAL_MMXEXT(mm_flags)) {
-c->transform_dc_add[0]= ff_hevc_idct4_dc_add_8_mmxext;
-c->transform_dc_add[1]= ff_hevc_idct8_dc_add_8_mmxext;
-
+c->transform_dc_add[0]= ff_hevc_idct4_dc_add_8_mmxext;
+c->transform_dc_add[1]= ff_hevc_idct8_dc_add_8_mmxext;
}
if (EXTERNAL_SSE2(mm_flags)) {
-c->hevc_v_loop_filter_chroma = ff_hevc_v_loop_filter_chroma_8_sse2;
-c->hevc_h_loop_filter_chroma = ff_hevc_h_loop_filter_chroma_8_sse2;
-if (ARCH_X86_64) {
-c->hevc_v_loop_filter_luma = ff_hevc_v_loop_filter_luma_8_sse2;
-c->hevc_h_loop_filter_luma = ff_hevc_h_loop_filter_luma_8_sse2;
-}
-
-c->transform_dc_add[2]= ff_hevc_idct16_dc_add_8_sse2;
-c->transform_dc_add[3]= ff_hevc_idct32_dc_add_8_sse2;
+c->hevc_v_loop_filter_chroma = ff_hevc_v_loop_filter_chroma_8_sse2;
+c->hevc_h_loop_filter_chroma = ff_hevc_h_loop_filter_chroma_8_sse2;
+if (ARCH_X86_64) {
+c->hevc_v_loop_filter_luma = ff_hevc_v_loop_filter_luma_8_sse2;
+c->hevc_h_loop_filter_luma = ff_hevc_h_loop_filter_luma_8_sse2;
+}
+
+c->transform_dc_add[2]= ff_hevc_idct16_dc_add_8_sse2;
+c->transform_dc_add[3]= ff_hevc_idct32_dc_add_8_sse2;
}
if (EXTERNAL_SSSE3(mm_flags) && ARCH_X86_64) {
-c->hevc_v_loop_filter_luma = ff_hevc_v_loop_filter_luma_8_ssse3;
-c->hevc_h_loop_filter_luma = ff_hevc_h_loop_filter_luma_8_ssse3;
+c->hevc_v_loop_filter_luma = ff_hevc_v_loop_filter_luma_8_ssse3;
+c->hevc_h_loop_filter_luma = ff_hevc_h_loop_filter_luma_8_ssse3;
}
if (EXTERNAL_SSE4(mm_flags) && ARCH_X86_64) {
@@ -460,27 +459,26 @@ void ff_hevcdsp_init_x86(HEVCDSPContext *c, const int bit_depth)
}
} else if (bit_depth == 10) {
if (EXTERNAL_MMXEXT(mm_flags)) {
-c->transform_dc_add[0]= ff_hevc_idct4_dc_add_10_mmxext;
+c->transform_dc_add[0]= ff_hevc_idct4_dc_add_10_mmxext;
}
if (EXTERNAL_SSE2(mm_flags)) {
-c->hevc_v_loop_filter_chroma = ff_hevc_v_loop_filter_chroma_10_sse2;
-c->hevc_h_loop_filter_chroma = ff_hevc_h_loop_filter_chroma_10_sse2;
-if (ARCH_X86_64) {
-c->hevc_v_loop_filter_luma = ff_hevc_v_loop_filter_luma_10_sse2;
-c->hevc_h_loop_filter_luma = ff_hevc_h_loop_filter_luma_10_sse2;
-}
-
-c->transform_dc_add[1]= ff_hevc_idct8_dc_add_10_sse2;
-c->transform_dc_add[2]= ff_hevc_idct16_dc_add_10_sse2;
-c->transform_dc_add[3]= ff_hevc_idct32_dc_add_10_sse2;
-}
+c->hevc_v_loop_filter_chroma = ff_hevc_v_loop_filter_chroma_10_sse2;
+c->hevc_h_loop_filter_chroma = ff_hevc_h_loop_filter_chroma_10_sse2;
+if (ARCH_X86_64) {
+c->hevc_v_loop_filter_luma = ff_hevc_v_loop_filter_luma_10_sse2;
+c->hevc_h_loop_filter_luma = ff_hevc_h_loop_filter_luma_10_sse2;
+}
+
+c->transform_dc_add[1]= ff_hevc_idct8_dc_add_10_sse2;
+c->transform_dc_add[2]= ff_hevc_idct16_dc_add_10_sse2;
+c->transform_dc_add[3]= ff_hevc_idct32_dc_add_10_sse2;
+}
if (EXTERNAL_SSSE3(mm_flags) && ARCH_X86_64) {
-c->hevc_v_loop_filter_luma = ff_hevc_v_loop_filter_luma_10_ssse3;
-c->hevc_h_loop_filter_luma = ff_hevc_h_loop_filter_luma_10_ssse3;
+c->hevc_v_loop_filter_luma = ff_hevc_v_loop_filter_luma_10_ssse3;
+c->hevc_h_loop_filter_luma = ff_hevc_h_loop_filter_luma_10_ssse3;
}
if (EXTERNAL_SSE4(mm_flags) && ARCH_X86_64) {
-
EPEL_LINKS(c->put_hevc_epel, 0, 0, pel_pixels, 10, sse4);
EPEL_LINKS(c->put_hevc_epel, 0, 1, epel_h, 10, sse4);
EPEL_LINKS(c->put_hevc_epel, 1, 0, epel_v, 10, sse4);
--
1.9.2.msysgit.0
Re: [FFmpeg-devel] [PATCH] avcodec: increase FF_INPUT_BUFFER_PADDING_SIZE to 32
On Sun, Jul 20, 2014 at 10:43:30PM +0200, Andreas Cadhalpun wrote: > On 12.06.2014 08:42, Christophe Gisquet wrote: > >Hi, > > > >2014-06-11 21:29 GMT+02:00 Michael Niedermayer : > >>-#define FF_INPUT_BUFFER_PADDING_SIZE 16 > >>+#define FF_INPUT_BUFFER_PADDING_SIZE 32 > > > >So, following the discussion on how API users may be affected by this > >change, does that need an API bump? > > One effect of this change is that now mplayer2 fails to build, because it > uses this check: > #if MP_INPUT_BUFFER_PADDING_SIZE < FF_INPUT_BUFFER_PADDING_SIZE > #error MP_INPUT_BUFFER_PADDING_SIZE is too small! > #endif > > MP_INPUT_BUFFER_PADDING_SIZE is defined as 16. Increasing that to 32 allows > building mplayer2 again. That is probably needlessly conservative. For MPlayer we decided matching FFmpeg exactly is silly and set it to 64 instead. > So I think an API bump wouldn't have been a bad idea. As the person who added this: I intentionally accepted the maintenance burden of this, it is exactly there because I expected it might change at any time. The real problem in this case, is that it's not really an API change. It seems the padding requirement has been 32 since some time (always?), it just was never "documented". Bumping API for this change would be equivalent to bumping it for a bug fix. Which is a horribly bad thing since it means everyone using the old API will _necessarily_ be using a buggy version. The only real option would have been to change everything to only require those 16 bytes padding we claimed to require, at least for the old versions. Which I'm afraid we won't find anyone willing to do (and to be honest I'd consider a bit of waste of resources). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] hevcdsp: change types of SAO parameters
Hi,
this change is actually from openhevc. I just changed the type, not
the order used. The values are casted to int by the sao functions
anyway.
--
Christophe
From 79ece6bf3e8fe541761220b452bb6c1a2813bd61 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Wed, 23 Jul 2014 13:39:40 +0200
Subject: [PATCH 02/10] hevcdsp: change types of SAO parameters
---
libavcodec/hevcdsp.h | 4 ++--
libavcodec/hevcdsp_template.c | 8
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevcdsp.h b/libavcodec/hevcdsp.h
index 8564deb..ba42984 100644
--- a/libavcodec/hevcdsp.h
+++ b/libavcodec/hevcdsp.h
@@ -31,11 +31,11 @@ typedef struct SAOParams {
int offset_abs[3][4]; ///< sao_offset_abs
int offset_sign[3][4]; ///< sao_offset_sign
-int band_position[3]; ///< sao_band_position
+uint8_t band_position[3]; ///< sao_band_position
int eo_class[3];///< sao_eo_class
-int offset_val[3][5]; ///offset_val[c_idx];
+int16_t *sao_offset_val = sao->offset_val[c_idx];
int sao_left_class = sao->band_position[c_idx];
stride_dst /= sizeof(pixel);
@@ -368,7 +368,7 @@ static void FUNC(sao_edge_filter)(uint8_t *_dst, uint8_t *_src,
{ { -1, -1 }, { 1, 1 } }, // 45 degree
{ { 1, -1 }, { -1, 1 } }, // 135 degree
};
-int *sao_offset_val = sao->offset_val[c_idx];
+int16_t *sao_offset_val = sao->offset_val[c_idx];
int sao_eo_class= sao->eo_class[c_idx];
pixel *dst = (pixel *)_dst;
pixel *src = (pixel *)_src;
@@ -406,7 +406,7 @@ static void FUNC(sao_edge_filter_0)(uint8_t *_dst, uint8_t *_src,
int x, y;
pixel *dst = (pixel *)_dst;
pixel *src = (pixel *)_src;
-int *sao_offset_val = sao->offset_val[c_idx];
+int16_t *sao_offset_val = sao->offset_val[c_idx];
int sao_eo_class= sao->eo_class[c_idx];
int init_x = 0, init_y = 0, width = _width, height = _height;
@@ -459,7 +459,7 @@ static void FUNC(sao_edge_filter_1)(uint8_t *_dst, uint8_t *_src,
int x, y;
pixel *dst = (pixel *)_dst;
pixel *src = (pixel *)_src;
-int *sao_offset_val = sao->offset_val[c_idx];
+int16_t *sao_offset_val = sao->offset_val[c_idx];
int sao_eo_class= sao->eo_class[c_idx];
int init_x = 0, init_y = 0, width = _width, height = _height;
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hevcdsp: change types of SAO parameters
Le mercredi 23 juillet 2014, Christophe Gisquet < christophe.gisq...@gmail.com> a écrit : > Hi, > > this change is actually from openhevc. I just changed the type, not > the order used. The values are casted to int by the sao functions > anyway. > > -- > Christophe > Ok Mickael ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] hevc_mvs: avoid deriving tmvp in amvp
Hi,
this may have consequences on threading, so it is a bit more important
than being able to avoid deriving the other candidates.
--
Christophe
From 7dd44119e24c9808314479ecde4c77287baa Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Wed, 23 Jul 2014 18:27:44 +0200
Subject: [PATCH 03/10] hevc_mvs: avoid deriving tmvp in amvp
Reduces on a sequence number of calls from 933685 to 586271.
---
libavcodec/hevc_mvs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/hevc_mvs.c b/libavcodec/hevc_mvs.c
index 52cfb29..1d4c002 100644
--- a/libavcodec/hevc_mvs.c
+++ b/libavcodec/hevc_mvs.c
@@ -751,7 +751,8 @@ scalef:
mvpcand_list[numMVPCandLX++] = mxB;
//temporal motion vector prediction candidate
-if (numMVPCandLX < 2 && s->sh.slice_temporal_mvp_enabled_flag) {
+if (numMVPCandLX < 2 && s->sh.slice_temporal_mvp_enabled_flag &&
+mvp_lx_flag == numMVPCandLX) {
Mv mv_col;
int available_col = temporal_luma_motion_vector(s, x0, y0, nPbW,
nPbH, ref_idx,
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hevc_mvs: avoid deriving tmvp in amvp
Patch ok Le mercredi 23 juillet 2014, Christophe Gisquet < christophe.gisq...@gmail.com> a écrit : > Hi, > > this may have consequences on threading, so it is a bit more important > than being able to avoid deriving the other candidates. > > -- > Christophe > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hevcdsp: change types of SAO parameters
On Wed, Jul 23, 2014 at 07:38:34PM +0200, Mickaël Raulet wrote: > Le mercredi 23 juillet 2014, Christophe Gisquet < > christophe.gisq...@gmail.com> a écrit : > > > Hi, > > > > this change is actually from openhevc. I just changed the type, not > > the order used. The values are casted to int by the sao functions > > anyway. > > > > -- > > Christophe > > > > Ok applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/4] frame-mt: hevc: implement and use step progress API
The idea is that the current granularity is too small for bigger coding structures, than can be 64x64 for both hevc and vp9. Instead, the simplest way to describe the new type of progress is that of a step function. I bet the patchset will be far from consensual, and it's unlikely I'll get it through in a shape that satisfies everyone. It's mostly a proof of concept. In the table below, 1T indicates the performance on one core, while max means the default thread count. Furthermore, to benchmark the modification, I also added some intrinsics (denoted by +idct). The effect of the patchset is in the column +patch. The configurations tested are: 1) HEAD on a 6-cores system 2) HEAD + intrinsics (~openhevc) on the same system 3) HEAD + intrinsics on a 2-cores system (with hyperthreading) Finally, the numbers reported are the decoding times in seconds. 1Tmax +idct +patch 1: 26.2 9.5 7.26.2 2: 5.74.9 3: 13.2 6.56.3 Christophe Gisquet (4): libavcodec: new API for frame threading by step hevc: use new step progress API hevc: actual benefits from new step threading API hevc: use new step threading API for DBF-only cases libavcodec/hevc.c | 19 +++-- libavcodec/hevc_filter.c | 26 -- libavcodec/hevc_mvs.c | 4 +-- libavcodec/hevc_refs.c | 2 +- libavcodec/pthread_frame.c | 68 -- libavcodec/thread.h| 24 6 files changed, 121 insertions(+), 22 deletions(-) -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] libavcodec: new API for frame threading by step
The new _progress3 functions allow reporting the x,y position in
decoding.
ff_thread_report_progress3_raster_end allows signaling the end of
a raster line and updates unconditionally the position to the
start of next raster line.
ff_thread_report_progress3_increment tries to increment position
if it lies on the same raster line as current position.
---
libavcodec/pthread_frame.c | 68 --
libavcodec/thread.h| 24
2 files changed, 90 insertions(+), 2 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 2a67f4d..9896bba 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -488,6 +488,51 @@ void ff_thread_report_progress(ThreadFrame *f, int n, int
field)
pthread_mutex_unlock(&p->progress_mutex);
}
+void ff_thread_report_progress3_raster_end(ThreadFrame *f, int y)
+{
+PerThreadContext *p;
+volatile int *progress = f->progress ? (int*)f->progress->data : NULL;
+
+if (!progress || progress[0] > y || progress[1] > y )
+return;
+
+p = f->owner->internal->thread_ctx;
+
+if (f->owner->debug&FF_DEBUG_THREADS)
+av_log(f->owner, AV_LOG_DEBUG, "%p finished line %d\n", progress, y);
+
+pthread_mutex_lock(&p->progress_mutex);
+progress[0] = y;
+progress[1] = y;
+progress[2] = 0;
+pthread_cond_broadcast(&p->progress_cond);
+pthread_mutex_unlock(&p->progress_mutex);
+}
+
+void ff_thread_report_progress3_increment(ThreadFrame *f, int x, int y, int
step)
+{
+PerThreadContext *p;
+volatile int *progress = f->progress ? (int*)f->progress->data : NULL;
+
+if (!progress || (progress[0]!=-1 && y != progress[0])) return;
+// Until a line is completed, increments on x from next line are ignored,
+// therefore allow horizontal jumps in case they are on the expect line
+if (progress[0] != progress[1] && progress[2]+step != x) return;
+
+p = f->owner->internal->thread_ctx;
+
+if (f->owner->debug&FF_DEBUG_THREADS)
+av_log(f->owner, AV_LOG_DEBUG, "%p finished up to (%d,%d)/%d\n",
+ progress, x, y, step);
+
+pthread_mutex_lock(&p->progress_mutex);
+progress[0] = y;
+progress[1] = y + step;
+progress[2] = x;
+pthread_cond_broadcast(&p->progress_cond);
+pthread_mutex_unlock(&p->progress_mutex);
+}
+
void ff_thread_await_progress(ThreadFrame *f, int n, int field)
{
PerThreadContext *p;
@@ -506,6 +551,25 @@ void ff_thread_await_progress(ThreadFrame *f, int n, int
field)
pthread_mutex_unlock(&p->progress_mutex);
}
+void ff_thread_await_progress3(ThreadFrame *f, int x, int y)
+{
+PerThreadContext *p;
+volatile int *progress = f->progress ? (int*)f->progress->data : NULL;
+
+if (!progress || progress[0] >= y ||
+(progress[2] >= x && progress[1] >= y)) return;
+
+p = f->owner->internal->thread_ctx;
+
+if (f->owner->debug&FF_DEBUG_THREADS)
+av_log(f->owner, AV_LOG_DEBUG, "thread awaiting (%d,%d) point in
%p\n", x, y, progress);
+
+pthread_mutex_lock(&p->progress_mutex);
+while (progress[0] < y && (progress[2] < x || progress[1] < y))
+pthread_cond_wait(&p->progress_cond, &p->progress_mutex);
+pthread_mutex_unlock(&p->progress_mutex);
+}
+
void ff_thread_finish_setup(AVCodecContext *avctx) {
PerThreadContext *p = avctx->internal->thread_ctx;
@@ -766,13 +830,13 @@ static int thread_get_buffer_internal(AVCodecContext
*avctx, ThreadFrame *f, int
if (avctx->internal->allocate_progress) {
int *progress;
-f->progress = av_buffer_alloc(2 * sizeof(int));
+f->progress = av_buffer_alloc(3 * sizeof(int));
if (!f->progress) {
return AVERROR(ENOMEM);
}
progress = (int*)f->progress->data;
-progress[0] = progress[1] = -1;
+progress[0] = progress[1] = progress[2] = -1;
}
pthread_mutex_lock(&p->parent->buffer_mutex);
diff --git a/libavcodec/thread.h b/libavcodec/thread.h
index c848d7a..ca1bf81 100644
--- a/libavcodec/thread.h
+++ b/libavcodec/thread.h
@@ -140,4 +140,28 @@ void ff_reset_entries(AVCodecContext *avctx);
void ff_thread_report_progress2(AVCodecContext *avctx, int field, int thread,
int n);
void ff_thread_await_progress2(AVCodecContext *avctx, int field, int thread,
int shift);
+/**
+ * Report end of a line in raster order: change current raster line and refresh
+ * position.
+ * @param f The picture being decoded.
+ * @param y Ordinate of the finished line.
+ */
+void ff_thread_report_progress3_raster_end(ThreadFrame *f, int y);
+/**
+ * Report progress inside a raster line. If the progress does not correspond to
+ * an increment, it is ignored.
+ * @param f The picture being decoded.
+ * @param x Abscissa of the progress
+ * @param y Ordinate of the progress
+ * @param step Allowed increment
+ */
+void ff_thread_report_progress3_increment(ThreadFrame *f, int x, int y, int
[FFmpeg-devel] [PATCH 2/4] hevc: use new step progress API
Use new API without introducing changes to synchronization points,
i.e. same behaviour.
---
libavcodec/hevc.c| 19 ++-
libavcodec/hevc_filter.c | 10 +-
libavcodec/hevc_mvs.c| 4 ++--
libavcodec/hevc_refs.c | 2 +-
4 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index 1fee4dd..913385a 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -1614,12 +1614,13 @@ static void chroma_mc_bi(HEVCContext *s, uint8_t *dst0,
ptrdiff_t dststride, AVF
}
static void hevc_await_progress(HEVCContext *s, HEVCFrame *ref,
-const Mv *mv, int y0, int height)
+const Mv *mv, int x, int y)
{
-int y = (mv->y >> 2) + y0 + height + 9;
-
-if (s->threads_type == FF_THREAD_FRAME )
-ff_thread_await_progress(&ref->tf, y, 0);
+if (s->threads_type == FF_THREAD_FRAME) {
+x += (mv->x >> 2) + 9;
+y += (mv->y >> 2) + 9;
+ff_thread_await_progress3(&ref->tf, x, y);
+}
}
static void hls_prediction_unit(HEVCContext *s, int x0, int y0,
@@ -1739,13 +1740,13 @@ static void hls_prediction_unit(HEVCContext *s, int x0,
int y0,
ref0 = refPicList[0].ref[current_mv.ref_idx[0]];
if (!ref0)
return;
-hevc_await_progress(s, ref0, ¤t_mv.mv[0], y0, nPbH);
+hevc_await_progress(s, ref0, ¤t_mv.mv[0], x0+nPbW, y0+nPbH);
}
if (current_mv.pred_flag & PF_L1) {
ref1 = refPicList[1].ref[current_mv.ref_idx[1]];
if (!ref1)
return;
-hevc_await_progress(s, ref1, ¤t_mv.mv[1], y0, nPbH);
+hevc_await_progress(s, ref1, ¤t_mv.mv[1], x0+nPbW, y0+nPbH);
}
if (current_mv.pred_flag == PF_L0) {
@@ -2625,7 +2626,7 @@ static int hevc_frame_start(HEVCContext *s)
fail:
if (s->ref && s->threads_type == FF_THREAD_FRAME)
-ff_thread_report_progress(&s->ref->tf, INT_MAX, 0);
+ff_thread_report_progress3_raster_end(&s->ref->tf, INT_MAX);
s->ref = NULL;
return ret;
}
@@ -2984,7 +2985,7 @@ static int decode_nal_units(HEVCContext *s, const uint8_t
*buf, int length)
fail:
if (s->ref && s->threads_type == FF_THREAD_FRAME)
-ff_thread_report_progress(&s->ref->tf, INT_MAX, 0);
+ff_thread_report_progress3_raster_end(&s->ref->tf, INT_MAX);
return ret;
}
diff --git a/libavcodec/hevc_filter.c b/libavcodec/hevc_filter.c
index 7b41dd4..62f0ebb 100644
--- a/libavcodec/hevc_filter.c
+++ b/libavcodec/hevc_filter.c
@@ -702,16 +702,16 @@ void ff_hevc_hls_filter(HEVCContext *s, int x, int y, int
ctb_size)
sao_filter_CTB(s, x - ctb_size, y);
if (y && x_end) {
sao_filter_CTB(s, x, y - ctb_size);
-if (s->threads_type & FF_THREAD_FRAME )
-ff_thread_report_progress(&s->ref->tf, y, 0);
+if (s->threads_type & FF_THREAD_FRAME)
+ff_thread_report_progress3_raster_end(&s->ref->tf, y);
}
if (x_end && y_end) {
sao_filter_CTB(s, x , y);
-if (s->threads_type & FF_THREAD_FRAME )
-ff_thread_report_progress(&s->ref->tf, y + ctb_size, 0);
+if (s->threads_type & FF_THREAD_FRAME)
+ff_thread_report_progress3_raster_end(&s->ref->tf, y+ctb_size);
}
} else if (s->threads_type & FF_THREAD_FRAME && x_end)
-ff_thread_report_progress(&s->ref->tf, y + ctb_size - 4, 0);
+ff_thread_report_progress3_raster_end(&s->ref->tf, y + ctb_size - 4);
}
void ff_hevc_hls_filters(HEVCContext *s, int x_ctb, int y_ctb, int ctb_size)
diff --git a/libavcodec/hevc_mvs.c b/libavcodec/hevc_mvs.c
index 1d4c002..4564d71 100644
--- a/libavcodec/hevc_mvs.c
+++ b/libavcodec/hevc_mvs.c
@@ -244,7 +244,7 @@ static int temporal_luma_motion_vector(HEVCContext *s, int
x0, int y0,
x &= -16;
y &= -16;
if (s->threads_type == FF_THREAD_FRAME)
-ff_thread_await_progress(&ref->tf, y, 0);
+ff_thread_await_progress3(&ref->tf, x, y);
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);
@@ -258,7 +258,7 @@ static int temporal_luma_motion_vector(HEVCContext *s, int
x0, int y0,
x &= -16;
y &= -16;
if (s->threads_type == FF_THREAD_FRAME)
-ff_thread_await_progress(&ref->tf, y, 0);
+ff_thread_await_progress3(&ref->tf, x, y);
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);
diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index 136cc6f..2625517 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -370,7 +370,7 @@ static HEVCFrame *generate_missing_ref(HEVC
[FFmpeg-devel] [PATCH 4/4] hevc: use new step threading API for DBF-only cases
In that case, there's an offset of 4 between the CTB line and the
raster line.
---
libavcodec/hevc_filter.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hevc_filter.c b/libavcodec/hevc_filter.c
index abf8b24..8b5ae6b 100644
--- a/libavcodec/hevc_filter.c
+++ b/libavcodec/hevc_filter.c
@@ -716,8 +716,12 @@ void ff_hevc_hls_filter(HEVCContext *s, int x, int y, int
ctb_size)
if (s->threads_type & FF_THREAD_FRAME)
ff_thread_report_progress3_raster_end(&s->ref->tf, y+ctb_size);
}
-} else if (s->threads_type & FF_THREAD_FRAME && x_end)
-ff_thread_report_progress3_raster_end(&s->ref->tf, y + ctb_size - 4);
+} else if (s->threads_type & FF_THREAD_FRAME) {
+if (x_end)
+ff_thread_report_progress3_raster_end(&s->ref->tf, y + ctb_size -
4);
+else
+ff_thread_report_progress3_increment(&s->ref->tf, x + 4, y - 4,
ctb_size);
+}
}
void ff_hevc_hls_filters(HEVCContext *s, int x_ctb, int y_ctb, int ctb_size)
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] hevc: actual benefits from new step threading API
The new API allows tracking the position of the first raster line
being decoded, so allow updating it whenever SAO is called.
---
libavcodec/hevc_filter.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hevc_filter.c b/libavcodec/hevc_filter.c
index 62f0ebb..abf8b24 100644
--- a/libavcodec/hevc_filter.c
+++ b/libavcodec/hevc_filter.c
@@ -696,10 +696,16 @@ void ff_hevc_hls_filter(HEVCContext *s, int x, int y, int
ctb_size)
deblocking_filter_CTB(s, x, y);
if (s->sps->sao_enabled) {
int y_end = y >= s->sps->height - ctb_size;
-if (y && x)
+if (y && x) {
sao_filter_CTB(s, x - ctb_size, y - ctb_size);
-if (x && y_end)
+if (s->threads_type & FF_THREAD_FRAME)
+ff_thread_report_progress3_increment(&s->ref->tf, x,
y-ctb_size, ctb_size);
+}
+if (x && y_end) {
sao_filter_CTB(s, x - ctb_size, y);
+if (s->threads_type & FF_THREAD_FRAME)
+ff_thread_report_progress3_increment(&s->ref->tf, x, y,
ctb_size);
+}
if (y && x_end) {
sao_filter_CTB(s, x, y - ctb_size);
if (s->threads_type & FF_THREAD_FRAME)
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] libavcodec: new API for frame threading by step
Hi,
2014-07-23 21:13 GMT+02:00 Christophe Gisquet :
> ---
> libavcodec/pthread_frame.c | 68
> --
> libavcodec/thread.h| 24
> 2 files changed, 90 insertions(+), 2 deletions(-)
Didn't refresh the patch with update documentation. Here it is.
--
Christophe
From d5b3654dff953a0ee52a03c05147eab8064704d3 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Fri, 18 Jul 2014 19:19:06 +0200
Subject: [PATCH 1/4] libavcodec: new API for frame threading by step
The new _progress3 functions allow reporting the x,y position in
decoding.
ff_thread_report_progress3_raster_end allows signaling the end of
a raster line and updates unconditionally the position to the
start of next raster line.
ff_thread_report_progress3_increment tries to increment position
if it lies on the same raster line as current position.
---
doc/multithreading.txt | 23 +++-
libavcodec/pthread_frame.c | 68 --
libavcodec/thread.h| 24
3 files changed, 112 insertions(+), 3 deletions(-)
diff --git a/doc/multithreading.txt b/doc/multithreading.txt
index 2b992fc..30e7219 100644
--- a/doc/multithreading.txt
+++ b/doc/multithreading.txt
@@ -1,7 +1,7 @@
FFmpeg multithreading methods
==
-FFmpeg provides two methods for multithreading codecs.
+FFmpeg provides three methods for multithreading codecs.
Slice threading decodes multiple parts of a frame at the same time, using
AVCodecContext execute() and execute2().
@@ -11,6 +11,9 @@ It accepts N future frames and delays decoded pictures by N-1 frames.
The later frames are decoded in separate threads while the user is
displaying the current one.
+Frame step threading is similar to frame threading except the progress is
+measured in a finer way.
+
Restrictions on clients
==
@@ -26,6 +29,9 @@ Frame threading -
Clients must be able to handle this; the pkt_dts and pkt_pts fields in
AVFrame will work as usual.
+Frame step threading -
+* Same as frame threading
+
Restrictions on codec implementations
==
@@ -42,6 +48,10 @@ Frame threading -
* The contents of buffers must not be written to after ff_thread_report_progress()
has been called on them. This includes draw_edges().
+Frame step threadin -
+* The progress must be in raster scan.
+* Raster lines must be reported in order.
+
Porting codecs to frame threading
==
@@ -68,3 +78,14 @@ called anywhere, as it's useful too and the implementation is trivial when you'r
doing this. Note that draw_edges() needs to be called before reporting progress.
Before accessing a reference frame or its MVs, call ff_thread_await_progress().
+
+Porting codecs to frame step threading
+==
+
+Instead of using {report,await}_progress() with the ordinate:
+- You can signal a raster line end by passing the line ordinate to
+ ff_thread_report_progress3_raster_end;
+- You should signal intermediate progress by passing the x,y progress
+ as well as the expected step since last progress to
+ ff_thread_report_progress3_increment;
+- ff_thread_await_progress3 now takes x,y parameters.
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 2a67f4d..9896bba 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -488,6 +488,51 @@ void ff_thread_report_progress(ThreadFrame *f, int n, int field)
pthread_mutex_unlock(&p->progress_mutex);
}
+void ff_thread_report_progress3_raster_end(ThreadFrame *f, int y)
+{
+PerThreadContext *p;
+volatile int *progress = f->progress ? (int*)f->progress->data : NULL;
+
+if (!progress || progress[0] > y || progress[1] > y )
+return;
+
+p = f->owner->internal->thread_ctx;
+
+if (f->owner->debug&FF_DEBUG_THREADS)
+av_log(f->owner, AV_LOG_DEBUG, "%p finished line %d\n", progress, y);
+
+pthread_mutex_lock(&p->progress_mutex);
+progress[0] = y;
+progress[1] = y;
+progress[2] = 0;
+pthread_cond_broadcast(&p->progress_cond);
+pthread_mutex_unlock(&p->progress_mutex);
+}
+
+void ff_thread_report_progress3_increment(ThreadFrame *f, int x, int y, int step)
+{
+PerThreadContext *p;
+volatile int *progress = f->progress ? (int*)f->progress->data : NULL;
+
+if (!progress || (progress[0]!=-1 && y != progress[0])) return;
+// Until a line is completed, increments on x from next line are ignored,
+// therefore allow horizontal jumps in case they are on the expect line
+if (progress[0] != progress[1] && progress[2]+step != x) return;
+
+p = f->owner->internal->thread_ctx;
+
+if (f->owner->debug&FF_DEBUG_THREADS)
+av_log(f->owner, AV_LOG_DEBUG, "%p finished up to (%d,%d)/%d\n",
+ progress, x, y, step);
+
Re: [FFmpeg-devel] [PATCH] avcodec: increase FF_INPUT_BUFFER_PADDING_SIZE to 32
On Wed, 23 Jul 2014 19:34:50 +0200 Reimar Döffinger wrote: > On Sun, Jul 20, 2014 at 10:43:30PM +0200, Andreas Cadhalpun wrote: > > On 12.06.2014 08:42, Christophe Gisquet wrote: > > >Hi, > > > > > >2014-06-11 21:29 GMT+02:00 Michael Niedermayer : > > >>-#define FF_INPUT_BUFFER_PADDING_SIZE 16 > > >>+#define FF_INPUT_BUFFER_PADDING_SIZE 32 > > > > > >So, following the discussion on how API users may be affected by this > > >change, does that need an API bump? > > > > One effect of this change is that now mplayer2 fails to build, because it > > uses this check: > > #if MP_INPUT_BUFFER_PADDING_SIZE < FF_INPUT_BUFFER_PADDING_SIZE > > #error MP_INPUT_BUFFER_PADDING_SIZE is too small! > > #endif > > > > MP_INPUT_BUFFER_PADDING_SIZE is defined as 16. Increasing that to 32 allows > > building mplayer2 again. > > That is probably needlessly conservative. For MPlayer we decided > matching FFmpeg exactly is silly and set it to 64 instead. > > > So I think an API bump wouldn't have been a bad idea. > > As the person who added this: I intentionally accepted the > maintenance burden of this, it is exactly there because I > expected it might change at any time. > The real problem in this case, is that it's not really an > API change. > It seems the padding requirement has been 32 since some time > (always?), it just was never "documented". I'm not sure how you expect people to use the API correctly if it's managed this chaotically. And yes, implicit buffer padding required by all API _is_ part of the API, an extremely important one, even. You know, in a low level language like C it's an absolutely heresy to write past buffer boundaries (even if it's in a "controlled" way), and being unclear about how large the padding is, is just FUCKING BULLSHIT. > Bumping API for this change would be equivalent to bumping > it for a bug fix. > Which is a horribly bad thing since it means everyone using the > old API will _necessarily_ be using a buggy version. > The only real option would have been to change everything to > only require those 16 bytes padding we claimed to require, > at least for the old versions. > Which I'm afraid we won't find anyone willing to do (and to > be honest I'd consider a bit of waste of resources). > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hevc_mvs: avoid deriving tmvp in amvp
On Wed, Jul 23, 2014 at 09:01:38PM +0200, Mickaël Raulet wrote: > Patch ok > > Le mercredi 23 juillet 2014, Christophe Gisquet < > christophe.gisq...@gmail.com> a écrit : > > > Hi, > > > > this may have consequences on threading, so it is a bit more important > > than being able to avoid deriving the other candidates. applied thanks [...] -- 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
Re: [FFmpeg-devel] [PATCH] x86: hevcdsp: align
Le 23 juil. 2014 à 19:33, Christophe Gisquet a écrit : > This should be mostly cosmetics. > > Okay. This would also need to clean all transform_dc_ since they are not use anymore with Rext add-ons, but this will done/change in a near future. patch okay as it is for now. Mickaël ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] dmMediaConverter
On Fri, 18 Jul 2014 12:47:38 -0700, Dalacu Marius wrote: > Hi, i am the developer of dmMediaConverter, a simple FFmpeg frontend. > I am writing here in hope that my program will appear on FFmpeg-Based > Projects (https://www.ffmpeg.org/projects.html). > In case you like the app and i am not infringe any rules, thank you, > Best regards, > Marius Dalacu. > > http://dmsimpleapps.blogspot.ro/2014/04/dmmediaconverter.html Hi, Sorry for the delay for a response. The projects list has moved to the FFmpeg Wiki, and now any project author can list their own project. https://trac.ffmpeg.org/wiki/Projects Lou ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web/projects: move projects to wiki
On Wed, 23 Jul 2014 12:19:32 +0200, db0 company wrote: > On Wed, Jul 23, 2014 at 3:06 AM, Timothy Gu wrote: > > I would simply remove the menu item, but feel free to push with it. > > I agree. + Maybe mention it with a direct link in another page. I removed the menu item and pushed. Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86: hevcdsp: align
On Wed, Jul 23, 2014 at 10:08:37PM +0200, Mickaël Raulet wrote: > > Le 23 juil. 2014 à 19:33, Christophe Gisquet a > écrit : > > > This should be mostly cosmetics. > > > > > > Okay. This would also need to clean all transform_dc_ since they are not > use anymore with Rext add-ons, but this will done/change in a near future. > > patch okay as it is for now. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] web/download: Rename builds anchors so old links posted elsewhere still work
On Tue, 22 Jul 2014 10:36:31 -0800, Lou Logan wrote: > On Tue, 22 Jul 2014 10:34:13 -0800, Lou Logan wrote: > > > The "Mac" should be removed from this title since Apple dropped that > > from the OS X naming schemes. I know it's in the anchors, but we can > > keep it in those for link preservation. > > ...but this can be ignored, addressed in another patch, or fixed later > since it isn't really relevant to this patch. I just wanted to mention > it. I fixed this not-even-worth-calling-a-nit. > > No other comments from me. Actually I'd like to wait on this anchor patch since I contacted Alexander to add some redirects instead, so the new, cleaner names can be used. If that's not possible then I'll push this patch. Sorry for the noise. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/rtpenc_chain: Set timebase
Avoid warning that its not set
Signed-off-by: Michael Niedermayer
---
libavformat/rtpenc_chain.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/rtpenc_chain.c b/libavformat/rtpenc_chain.c
index dea1f70..a023450 100644
--- a/libavformat/rtpenc_chain.c
+++ b/libavformat/rtpenc_chain.c
@@ -21,6 +21,7 @@
#include "avformat.h"
#include "avio_internal.h"
+#include "internal.h"
#include "rtpenc_chain.h"
#include "rtp.h"
#include "libavutil/opt.h"
@@ -75,6 +76,7 @@ int ff_rtp_chain_mux_open(AVFormatContext **out,
AVFormatContext *s,
rtpctx->start_time_realtime = s->start_time_realtime;
avcodec_copy_context(rtpctx->streams[0]->codec, st->codec);
+avpriv_set_pts_info(rtpctx->streams[0], 64, st->codec->time_base.num,
st->codec->time_base.den);
if (handle) {
ret = ffio_fdopen(&rtpctx->pb, handle);
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] [WEB] style: add "warning" style similar to .info but has a red border
On Sun, Jul 20, 2014 at 10:03 AM, Timothy Gu wrote:
> Signed-off-by: Timothy Gu
> ---
> src/less/style.less | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
Ping
>
> diff --git a/src/less/style.less b/src/less/style.less
> index 6a26684..0c9ea03 100644
> --- a/src/less/style.less
> +++ b/src/less/style.less
> @@ -15,6 +15,7 @@
> @Cseconddarkdark: darken(@Cseconddark, 10%);
> @Csecondlight: lighten(@Csecond, 15%);
> @Csecondlightlight: lighten(@Csecondlight, 20%);
> +@Cwarning: #ae4c4c;
>
> // *
> //
> // SIZES
> @@ -180,17 +181,24 @@ a.well {
> }
> }
>
> -.info {
> +.info, .warning {
> margin: 10px;
> padding: 10px;
> background-color: @Cmainlight;
> -border-left: 10px @Csecond solid;
> color: @Cinvert;
> code {
> background-color: @Cmain;
> }
> }
>
> +.info {
> +border-left: 10px @Csecond solid;
> +}
> +
> +.warning {
> +border-left: 10px @Cwarning solid;
> +}
> +
> .with-icon {
> padding: 30px;
> .pull-left {
> --
> 1.9.1
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Use makeinfo to generate html doc for the new website
On Sun, Jul 20, 2014 at 2:26 PM, Timothy Gu wrote:
> texi2html is deprecated by upstream in favor of makeinfo/texi2any. See:
>
> - https://www.gnu.org/software/texinfo/manual/texinfo/html_node/texi2html.html
> - https://wiki.debian.org/Texi2htmlTransition
> - https://lists.debian.org/debian-devel/2013/05/msg01516.html
>
> This is actually two separate changes. But as makeinfo and texi2html
> adopt 2 (very) different init file syntaxes, it is easier to do the two
> transitions at once.
>
> Based on a patch by Andreas Cadhalpun .
>
> Fixes Trac ticket #3232.
>
> Signed-off-by: Timothy Gu
> ---
>
> Removed some now-extraneous settings.
>
> configure | 5 +-
> doc/Makefile | 8 +-
> doc/platform.texi | 2 +-
> doc/t2h.init | 123 --
> doc/t2h.pm| 220
> ++
> 5 files changed, 226 insertions(+), 132 deletions(-)
> delete mode 100644 doc/t2h.init
> create mode 100644 doc/t2h.pm
Ping
>
> diff --git a/configure b/configure
> index 742dfe1..6b3a850 100755
> --- a/configure
> +++ b/configure
> @@ -1789,7 +1789,6 @@ HAVE_LIST="
> perl
> pod2man
> sdl
> -texi2html
> threads
> vdpau_x11
> xlib
> @@ -2607,7 +2606,7 @@ ffserver_select="ffm_muxer rtp_protocol rtsp_demuxer"
> # documentation
> podpages_deps="perl"
> manpages_deps="perl pod2man"
> -htmlpages_deps="perl texi2html"
> +htmlpages_deps="perl makeinfo"
> txtpages_deps="perl makeinfo"
> doc_deps_any="manpages htmlpages podpages txtpages"
>
> @@ -4844,7 +4843,6 @@ else
> fi
> enabled sdl && add_cflags $sdl_cflags && add_extralibs $sdl_libs
>
> -texi2html --help 2> /dev/null | grep -q 'init-file' && enable texi2html ||
> disable texi2html
> makeinfo --version > /dev/null 2>&1 && enable makeinfo || disable makeinfo
> perl -v> /dev/null 2>&1 && enable perl || disable perl
> pod2man --help > /dev/null 2>&1 && enable pod2man || disable pod2man
> @@ -5323,7 +5321,6 @@ echo "threading support ${thread_type-no}"
> echo "safe bitstream reader ${safe_bitstream_reader-no}"
> echo "SDL support ${sdl-no}"
> echo "opencl enabled${opencl-no}"
> -echo "texi2html enabled ${texi2html-no}"
> echo "perl enabled ${perl-no}"
> echo "pod2man enabled ${pod2man-no}"
> echo "makeinfo enabled ${makeinfo-no}"
> diff --git a/doc/Makefile b/doc/Makefile
> index 99f588a..8eb1d5d 100644
> --- a/doc/Makefile
> +++ b/doc/Makefile
> @@ -80,14 +80,14 @@ $(GENTEXI): doc/avoptions_%.texi:
> doc/print_options$(HOSTEXESUF)
> $(M)doc/print_options $* > $@
>
> doc/%.html: TAG = HTML
> -doc/%.html: doc/%.texi $(SRC_PATH)/doc/t2h.init $(GENTEXI)
> +doc/%.html: doc/%.texi $(SRC_PATH)/doc/t2h.pm $(GENTEXI)
> $(Q)$(TEXIDEP)
> - $(M)texi2html -I doc -monolithic --D=config-not-all --init-file
> $(SRC_PATH)/doc/t2h.init --output $@ $<
> + $(M)makeinfo --html -I doc --no-split -D config-not-all
> --init-file=$(SRC_PATH)/doc/t2h.pm --output $@ $<
>
> doc/%-all.html: TAG = HTML
> -doc/%-all.html: doc/%.texi $(SRC_PATH)/doc/t2h.init $(GENTEXI)
> +doc/%-all.html: doc/%.texi $(SRC_PATH)/doc/t2h.pm $(GENTEXI)
> $(Q)$(TEXIDEP)
> - $(M)texi2html -I doc -monolithic --D=config-all --init-file
> $(SRC_PATH)/doc/t2h.init --output $@ $<
> + $(M)makeinfo --html -I doc --no-split -D config-all
> --init-file=$(SRC_PATH)/doc/t2h.pm --output $@ $<
>
> doc/%.pod: TAG = POD
> doc/%.pod: doc/%.texi $(SRC_PATH)/doc/texi2pod.pl $(GENTEXI)
> diff --git a/doc/platform.texi b/doc/platform.texi
> index c71121f..b529500 100644
> --- a/doc/platform.texi
> +++ b/doc/platform.texi
> @@ -275,7 +275,7 @@ llrint() in its C library.
> Install your Cygwin with all the "Base" packages, plus the
> following "Devel" ones:
> @example
> -binutils, gcc4-core, make, git, mingw-runtime, texi2html
> +binutils, gcc4-core, make, git, mingw-runtime, texinfo
> @end example
>
> In order to run FATE you will also need the following "Utils" packages:
> diff --git a/doc/t2h.init b/doc/t2h.init
> deleted file mode 100644
> index 9dd8f91..000
> --- a/doc/t2h.init
> +++ /dev/null
> @@ -1,123 +0,0 @@
> -# no horiz rules between sections
> -$end_section = \&FFmpeg_end_section;
> -sub FFmpeg_end_section($$)
> -{
> -}
> -
> -my $TEMPLATE_HEADER1 = $ENV{"FFMPEG_HEADER1"} || < -
> -
> -
> -
> -
> -FFmpeg documentation
> -
> -EOT
> -
> -my $TEMPLATE_HEADER2 = $ENV{"FFMPEG_HEADER2"} || < -
> -
> -
> -EOT
> -
> -my $TEMPLATE_FOOTER = $ENV{"FFMPEG_FOOTER"} || < -
> -
> -
> -EOT
> -
> -$SMALL_RULE = '';
> -$BODYTEXT = '';
> -
> -$print_page_foot = \&FFmpeg_print_page_foot;
> -sub FFmpeg_print_page_foot($$)
> -{
> -my $fh = shift;
> -my $program_string = defined &T2H_DEFAULT_program_string ?
> -T2H_DEFAULT_program_string() : program_string();
> -print $fh '' . "\n";
> -print $fh '' . $program_st
Re: [FFmpeg-devel] [PATCH] Add generate-doc.sh to generate makeinfo-based ffmpeg docs
On Sun, Jul 20, 2014 at 2:22 PM, Timothy Gu wrote:
> Signed-off-by: Timothy Gu
> ---
> README| 12 +---
> generate-doc.sh | 41 +
> src/template_doctitle | 1 -
> 3 files changed, 42 insertions(+), 12 deletions(-)
> create mode 100755 generate-doc.sh
> delete mode 100644 src/template_doctitle
Ping
>
> diff --git a/README b/README
> index 93854ee..7f15db2 100644
> --- a/README
> +++ b/README
> @@ -15,17 +15,7 @@ GENERATE THE DOCUMENTATION
>
> /!\ None of the generated versions of the website contain the documentation.
>
> -To generate the documentation pages:
> -- Add the HTML wrappers to your environment:
> - $ export FFMPEG_HEADER1="$(cat src/template_head1 src/template_doctitle
> src/template_head_prod)"
> - $ export FFMPEG_HEADER2="$(cat src/template_head2 src/template_doctitle
> src/template_head3)"
> - $ export FFMPEG_FOOTER="$(cat src/template_footer1
> src/template_footer_prod src/template_footer2)"
> -- Get the main ffmpeg repo:
> - $ git clone git://source.ffmpeg.org/ffmpeg.git
> -- Compile the documentation using the ffmpeg main repo Makefile:
> - $ make doc
> -- Copy the generated HTML files inside the website:
> - $ cp /path/to/ffmpeg/doc/*.html /path/to/ffmpeg-web/htdocs/
> +To generate the documentation pages, just `./generate-doc.sh `.
>
> In case of a major CSS update, please also update the `style.min.css` file in
> the main FFmpeg repo:
> diff --git a/generate-doc.sh b/generate-doc.sh
> new file mode 100755
> index 000..f953a9a
> --- /dev/null
> +++ b/generate-doc.sh
> @@ -0,0 +1,41 @@
> +#!/bin/sh
> +#
> +# Copyright (c) 2014 Tiancheng "Timothy" Gu.
> +#
> +# Permission to use, copy, modify, and/or distribute this software for any
> +# purpose with or without fee is hereby granted, provided that the above
> +# copyright notice and this permission notice appear in all copies.
> +#
> +# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> +# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> +# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
> +# SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> +# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> ACTION
> +# OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
> +# CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> +
> +die() {
> +echo $1
> +exit 1
> +}
> +
> +if [ $# != 1 ]; then
> +die "Usage: $0 "
> +fi
> +
> +src=$1
> +current_dir=$(pwd)
> +
> +export FFMPEG_HEADER1="$(cat src/template_head1)"
> +export FFMPEG_HEADER2="$(cat src/template_head_prod src/template_head2)"
> +export FFMPEG_HEADER3="$(cat src/template_head3)"
> +export FFMPEG_FOOTER="$(cat src/template_footer1 src/template_footer_prod
> src/template_footer2)"
> +
> +rm -rf build-doc
> +mkdir build-doc && cd build-doc
> +$src/configure --enable-gpl --disable-yasm || die "configure failed"
> +make doc || die "doc not made"
> +cp doc/*.html ../htdocs/ || die "copy failed"
> +
> +cd ..
> +rm -rf build-doc
> \ No newline at end of file
> diff --git a/src/template_doctitle b/src/template_doctitle
> deleted file mode 100644
> index 5e4dbec..000
> --- a/src/template_doctitle
> +++ /dev/null
> @@ -1 +0,0 @@
> -FFmpeg Documentation
> --
> 1.9.1
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Use makeinfo to generate html doc for the new website
On Wed, Jul 23, 2014 at 05:20:10PM -0700, Timothy Gu wrote: > On Sun, Jul 20, 2014 at 2:26 PM, Timothy Gu wrote: > > texi2html is deprecated by upstream in favor of makeinfo/texi2any. See: > > > > - > > https://www.gnu.org/software/texinfo/manual/texinfo/html_node/texi2html.html > > - https://wiki.debian.org/Texi2htmlTransition > > - https://lists.debian.org/debian-devel/2013/05/msg01516.html > > > > This is actually two separate changes. But as makeinfo and texi2html > > adopt 2 (very) different init file syntaxes, it is easier to do the two > > transitions at once. > > > > Based on a patch by Andreas Cadhalpun . > > > > Fixes Trac ticket #3232. > > > > Signed-off-by: Timothy Gu > > --- > > > > Removed some now-extraneous settings. > > > > configure | 5 +- > > doc/Makefile | 8 +- > > doc/platform.texi | 2 +- > > doc/t2h.init | 123 -- > > doc/t2h.pm| 220 > > ++ > > 5 files changed, 226 insertions(+), 132 deletions(-) > > delete mode 100644 doc/t2h.init > > create mode 100644 doc/t2h.pm > > Ping does this patchset affect how the html output looks ? also applying this patchset will not affect how our server generates the html, as it does not execute files from git. If its intended to also change what the server does, this would need some volunteer to update the scripts used. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavfi/src_movie: remove frame from priv context
On Sun, May 11, 2014 at 06:08:08AM +0200, Lukasz Marek wrote: > This variable is used only inside one function. > There is no need to store it in context. > > This also may prevent crush by double free frame. > > Signed-off-by: Lukasz Marek > --- > libavfilter/src_movie.c | 28 +--- > 1 file changed, 13 insertions(+), 15 deletions(-) this seems to have been forgotten applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB DNS cache poisoning attacks, popular search engine, Google internet authority dont be evil, please signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavfi/src_movie: minor simplifications
On Sun, May 11, 2014 at 06:08:09AM +0200, Lukasz Marek wrote: > Signed-off-by: Lukasz Marek > --- > libavfilter/src_movie.c | 8 +++- > 1 file changed, 3 insertions(+), 5 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB DNS cache poisoning attacks, popular search engine, Google internet authority dont be evil, please signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] web/style: Add a comment in the generated css file for the doc in the main repo
---
README |2 +-
src/css_credit |6 ++
2 files changed, 7 insertions(+), 1 deletions(-)
create mode 100644 src/css_credit
diff --git a/README b/README
index 93854ee..2276820 100644
--- a/README
+++ b/README
@@ -29,7 +29,7 @@ To generate the documentation pages:
In case of a major CSS update, please also update the `style.min.css` file in
the main FFmpeg repo:
- $ cat /path/to/ffmpeg-web/htdocs/css/{bootstrap.min.css,style.min.css} >
/path/to/ffmpeg/doc/style.min.css
+ $ cat /path/to/ffmpeg-web/src/css_credit
/path/to/ffmpeg-web/htdocs/css/{bootstrap.min.css,style.min.css} >
/path/to/ffmpeg/doc/style.min.css
WEBSITE DEVELOPERS INSTRUCTIONS
diff --git a/src/css_credit b/src/css_credit
new file mode 100644
index 000..27efb02
--- /dev/null
+++ b/src/css_credit
@@ -0,0 +1,6 @@
+/*
+ * This file has been generated from the website repo:
+ * git://ffmpeg.org/ffmpeg-web
+ * Any modification must be applied on the src/less/style.less source file
first.
+ */
+
--
1.7.0.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
