Re: [FFmpeg-devel] [PATCH] [PATCH] lavfi: add inverse telecine filter
Timothy Gu gmail.com> writes: > > This is an exact inverse of the telecine filter > > unlike previously existing pullup and fieldmatch > > ones. > > What's the difference between the three seemingly > similar filters? The other two are similar (speed and license are different): They try to detect the telecined frames and reconstruct the original progressive stream even if cuts were made. They sometimes miss telecined frames. This filter does not detect anything, it applies a fixed pattern to the input stream: It fails very badly if the input was cut (and the pattern changed), it works perfectly for streams that contain a constant pattern. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sftp: support reading config from ~/.ssh/config
11.03.2015, 00:51:39 by Timothy Gu: > Does this patch change the default behavior in any way? No, at least it's not intended to change for users who don't have a ~/.ssh/config. If there are users who have a config lying around and expecting it to be ignored, let's say they don's specify a username in the sftp:// url and expect the default value to be used while they have non-default config setting, the behaviour changes. But I think that's hypothetical, users who have an ssh config are probably replicating their settings explicitely in their current sftp:// urls. Florian ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: Add support to process_command in vf_eq.c
On date Wednesday 2015-03-11 10:55:07 +0530, Arwa Arif encoded: > On Tue, Mar 10, 2015 at 2:41 PM, Stefano Sabatini > wrote: [...] > > > There are no parameters accepted by the expressions. I will add some > > > examples in the doc. > > > > Look how it is done in hue. In general an expression is useful if you > > want to express something in function of the time or the number of > > frame or something else. > > [...] > So, I should add these options: > 1. frame count > 2. frame rate > 3. timestamp expressed in seconds > 4. timebase Frame count and time in seconds are probably the most important. About timebase, that's only useful if you provide the timebase (you need timestamp and timebase to get a time). So I'd say that time (in seconds) and frame count are the most important parameters. -- FFmpeg = Fiendish Free Moronic Philosofic Educated God ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sftp: support reading config from ~/.ssh/config
On 11.03.2015, at 10:13, Florian Jacob wrote: > 11.03.2015, 00:51:39 by Timothy Gu: >> Does this patch change the default behavior in any way? > > No, at least it's not intended to change for users who don't have a > ~/.ssh/config. > > If there are users who have a config lying around and expecting it to be > ignored, let's say they don's specify a username in the sftp:// url and > expect > the default value to be used while they have non-default config setting, the > behaviour changes. > > But I think that's hypothetical, users who have an ssh config are probably > replicating their settings explicitely in their current sftp:// urls. Well, I can think of one case: users that enable compression in the config file. That makes sense for interactive session and when copying normal files, but for multimedia it is mostly nonsense. Do we have a way to apply ffmpeg-specific options? If so, should they default to disabling compression? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] [PATCH] lavfi: add inverse telecine filter
On Wed, Mar 11, 2015 at 07:12:16AM +, Carl Eugen Hoyos wrote: > Timothy Gu gmail.com> writes: > > > > This is an exact inverse of the telecine filter > > > unlike previously existing pullup and fieldmatch > > > ones. > > > > What's the difference between the three seemingly > > similar filters? > > The other two are similar (speed and license are > different): They try to detect the telecined > frames and reconstruct the original progressive > stream even if cuts were made. They sometimes miss > telecined frames. > This filter does not detect anything, it applies a > fixed pattern to the input stream: It fails very > badly if the input was cut (and the pattern > changed), > it works perfectly for streams that > contain a constant pattern. Did this happen even once with real material? > > Carl Eugen > -- Clément B. pgpEMpEqlJoN0.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sftp: support reading config from ~/.ssh/config
Le primidi 21 ventôse, an CCXXIII, Reimar Döffinger a écrit : > Well, I can think of one case: users that enable compression in the config > file. > That makes sense for interactive session and when copying normal files, but > for multimedia it is mostly nonsense. Yes, but that applies to all SSH-based transfers systems, starting with scp and rsync. People have to be aware of that (or do not care). > Do we have a way to apply ffmpeg-specific options? I do not think so, the format of the configuration file is very rudimentary. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sftp: support reading config from ~/.ssh/config
Am Mittwoch, 11. März 2015, 10:27:55 schrieb Reimar Döffinger: > On 11.03.2015, at 10:13, Florian Jacob wrote: > > 11.03.2015, 00:51:39 by Timothy Gu: > >> Does this patch change the default behavior in any way? > > > > No, at least it's not intended to change for users who don't have a > > ~/.ssh/config. > > > > If there are users who have a config lying around and expecting it to be > > ignored, let's say they don's specify a username in the sftp:// url and > > expect the default value to be used while they have non-default config > > setting, the behaviour changes. > > > > But I think that's hypothetical, users who have an ssh config are probably > > replicating their settings explicitely in their current sftp:// urls. > > Well, I can think of one case: users that enable compression in the config > file. That makes sense for interactive session and when copying normal > files, but for multimedia it is mostly nonsense. Good thought. With the patch, it's possible for the user to use a separate config for turning compression off, through hostname aliases and differentiated by the hostname that the user uses to connect. For example: Host example.com Port 12345 Host example-nocompression Hostname example.com Port 12345 Compression no and then use ffplay "sftp://example-nocompression/path/to/video.mkv"; This way, the user can configure that they don't want to use compression for ffmpeg (or anything else where they use example-nocompression as a hostname) > Do we have a way to apply > ffmpeg-specific options? We can force to use no compression in the code, by adding this line: ssh_options_set(libssh->session, SSH_OPTIONS_COMPRESSION, "no"); after parsing the config file. I just looked into the config parsing code, changes to the compression options before parsing will actually be overwritten by the config file. This would also mean that the user can't configure to use compression for ffmpeg even if they want to, though, but this wasn't possible before either. > If so, should they default to disabling compression? I only use ffmpeg to play videos in already-compressed formats, so it would make sense in my use case, but I don't know whether ffmpeg can be used in a way where you would actually want ssh compression. One might could argue that connections that benefit and work faster with the compression option are too slow to stream media, anyway. Other thoughts? I can send in another patch if wanted. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fixed memory leak in EvalContext::channel_values
I'm not familiar with writing fate tests but it's something I'll look into - Ole Andre Birkedal 2015-03-10 14:42 GMT+01:00 Michael Niedermayer : > On Tue, Mar 10, 2015 at 02:23:26PM +0100, Ole Andre Birkedal wrote: > > There are some doubles being allocated in aeval_config_output which is > > called by avfilter_graph_config. They are not being deleted and I am (on > my > > filter graph) seeing two doubles (16 bytes on my system) of leaked > memory. > > > > - Ole Andre Birkedal > > > aeval.c |1 + > > 1 file changed, 1 insertion(+) > > 5359214c3c0481bb0b16a92748283e6eeb8205bc fix_channel_values.patch > > From e4c6316a2d90624277f933fe64b5c8397793b6ca Mon Sep 17 00:00:00 2001 > > From: Ole Andre Birkedal > > Date: Tue, 10 Mar 2015 14:12:30 +0100 > > Subject: [PATCH] Fixed a memory leak in EvalContext::channel_values > > applied > > can you also add a fate test for aeval ? > we have one for aevalsrc which didt catch this leak > > thanks > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The educated differ from the uneducated as much as the living from the > dead. -- Aristotle > > ___ > 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] sftp: support reading config from ~/.ssh/config
Le primidi 21 ventôse, an CCXXIII, Florian Jacob a écrit : > > Do we have a way to apply > > ffmpeg-specific options? > We can force to use no compression in the code, by adding this line: > > ssh_options_set(libssh->session, SSH_OPTIONS_COMPRESSION, "no"); > > after parsing the config file. I think that is not what Reimar had in mind, but rather something like this: ssh_set_app_tag(libssh->session, "ffmpeg"); ssh_set_app_tag(libssh->session, "multimedia"); Match tag=multimedia Compression off Unfortunately, there is no "tag" criterion for the Match directive. Maybe the OpenSSH guys would be amenable to a patch. > This would also mean that the user can't configure to use > compression for ffmpeg even if they want to, though, but this wasn't possible > before either. > One might could argue that connections that benefit and work faster with the > compression option are too slow to stream media, anyway. > > Other thoughts? I firmly believe in the following principles: 1. If the user made an explicit choice, the application must obey, even if the choice seems stupid. In the case of SSH: compression is disabled by default, so enabling it is an explicit choice. 2. Applications should as much as possible try to both leave the choice to the user and have a sensible default, but if for some reason it is not possible (poor API on a library), then priority should be given to user choice. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sftp: support reading config from ~/.ssh/config
On 11.03.2015, at 11:00, Florian Jacob wrote: > Am Mittwoch, 11. März 2015, 10:27:55 schrieb Reimar Döffinger: >> On 11.03.2015, at 10:13, Florian Jacob > wrote: >> If so, should they default to disabling compression? > I only use ffmpeg to play videos in already-compressed formats, so it would > make sense in my use case, but I don't know whether ffmpeg can be used in a > way > where you would actually want ssh compression. > > One might could argue that connections that benefit and work faster with the > compression option are too slow to stream media, anyway. Uh, I use compression on 30 MBit/s connections. For textual log files it about doubles the transfer speed. > Other thoughts? > > > I can send in another patch if wanted. I don't know if it makes sense, just pointing out one case where it makes a potentially user-visible behaviour change. You could have a "force uncompressed" stream option to make it configurable, possibly enabled by default... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sftp: support reading config from ~/.ssh/config
On 11.03.2015, at 11:15, Nicolas George wrote: > I firmly believe in the following principles: > > 1. If the user made an explicit choice, the application must obey, even if > the choice seems stupid. > > In the case of SSH: compression is disabled by default, so enabling it is > an explicit choice. It's a bit more complex here. 1) it is a choice made for ssh, not for FFmpeg and not even for sftp 2) we previously did not respect that choice, thus it is a behaviour change I have no strong feelings about it, but you did ask if this change might have undesireable or unexpected consequences... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Reorganized libpostproc code
Hi On Tue, Mar 10, 2015 at 11:57:56PM -0400, Tucker DiNapoli wrote: > From: Tucker DiNapoli > > The only changes were formating and moving code. > --- > libpostproc/postprocess.c | 436 ++-- > libpostproc/postprocess_c.c| 1328 > > libpostproc/postprocess_internal.h | 30 +- > libpostproc/postprocess_template.c | 124 ++-- > 4 files changed, 1468 insertions(+), 450 deletions(-) > create mode 100644 libpostproc/postprocess_c.c like james said, the changes need to be split, the code needs to work after each patch and each patch should contain only related changed also submit patches early if possible, dont accumulate a huge patchset before submission as someone might spot an issue in patch #1 and that might cause potentially lots of rework in subsequent patches also the code does not work after this patch: make -k fate-filter-pp fate-filter-pp1 fate-filter-pp2 fate-filter-pp3 fate-filter-pp4 fate-filter-pp5 fate-filter-pp6 (you can also run make fate to run all tests not just the postprocess tests) [...] --- ./tests/ref/fate/filter-pp5 2015-03-11 00:31:17.874675798 +0100 +++ tests/data/fate/filter-pp5 2015-03-11 11:27:01.911504671 +0100 @@ -1 +1 @@ -pp5 5fc6703d42bd98942e5dd104ce220291 +pp5 \ No newline at end of file Test filter-pp5 failed. Look at tests/data/fate/filter-pp5.err for details. make: *** [fate-filter-pp5] Error 139 --- ./tests/ref/fate/filter-pp6 2015-03-11 00:31:17.874675798 +0100 +++ tests/data/fate/filter-pp6 2015-03-11 11:27:01.911504671 +0100 @@ -1 +1 @@ -pp6 93b508d07bfcf4703aa7dff2d2ef5c03 +pp6 \ No newline at end of file Test filter-pp6 failed. Look at tests/data/fate/filter-pp6.err for details. make: *** [fate-filter-pp6] Error 139 --- ./tests/ref/fate/filter-pp2 2015-03-11 00:31:17.874675798 +0100 +++ tests/data/fate/filter-pp2 2015-03-11 11:27:01.911504671 +0100 @@ -1 +1 @@ -pp2 975d4c1d489e42ddbd4a27464e8355af +pp2 \ No newline at end of file Test filter-pp2 failed. Look at tests/data/fate/filter-pp2.err for details. make: *** [fate-filter-pp2] Error 139 --- ./tests/ref/fate/filter-pp 2015-03-11 00:31:17.874675798 +0100 +++ tests/data/fate/filter-pp 2015-03-11 11:27:01.911504671 +0100 @@ -1 +1 @@ -pp 3730f1ed7bf244ce059d110e21f39bbd +pp \ No newline at end of file --- ./tests/ref/fate/filter-pp4 2015-03-11 00:31:17.874675798 +0100 +++ tests/data/fate/filter-pp4 2015-03-11 11:27:01.911504671 +0100 @@ -1 +1 @@ -pp4 0a2895c619ab9c6c22fd7cffb25070a8 +pp4 \ No newline at end of file Test filter-pp failed. Look at tests/data/fate/filter-pp.err for details. make: *** [fate-filter-pp] Error 139 Test filter-pp4 failed. Look at tests/data/fate/filter-pp4.err for details. make: *** [fate-filter-pp4] Error 139 --- ./tests/ref/fate/filter-pp3 2015-03-11 00:31:17.874675798 +0100 +++ tests/data/fate/filter-pp3 2015-03-11 11:27:01.911504671 +0100 @@ -1 +1 @@ -pp3 ef0f10f1859af2f75717e8c9d64ee38a +pp3 \ No newline at end of file Test filter-pp3 failed. Look at tests/data/fate/filter-pp3.err for details. make: *** [fate-filter-pp3] Error 139 --- ./tests/ref/fate/filter-pp1 2015-03-11 00:31:17.874675798 +0100 +++ tests/data/fate/filter-pp1 2015-03-11 11:27:01.911504671 +0100 @@ -1 +1 @@ -pp1 cb9f884e27a5be11f72afc9b517efd10 +pp1 \ No newline at end of file Test filter-pp1 failed. Look at tests/data/fate/filter-pp1.err for details. make: *** [fate-filter-pp1] Error 139 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
Le decadi 20 ventôse, an CCXXIII, Nicolas George a écrit :
> I will try to propose another patch for pure validation.
See the attached patches.
Regards,
--
Nicolas George
From cef95aaec223b6644db6e52f9c6452d7aa01648b Mon Sep 17 00:00:00 2001
From: Nicolas George
Date: Tue, 10 Mar 2015 13:43:17 +0100
Subject: [PATCH 1/2] lavf/http: full validation of headers option string.
Signed-off-by: Nicolas George
---
libavformat/http.c | 58 --
1 file changed, 52 insertions(+), 6 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index 55dcb6e..2d8f5dc 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -25,6 +25,7 @@
#include
#endif /* CONFIG_ZLIB */
+#include "libavutil/avassert.h"
#include "libavutil/avstring.h"
#include "libavutil/opt.h"
@@ -292,6 +293,55 @@ int ff_http_averror(int status_code, int default_averror)
return default_averror;
}
+static void validate_headers_option(void *log, unsigned char *header)
+{
+unsigned char *p = header;
+const char *error = NULL;
+int tag;
+
+/* *( header-field CRLF ) */
+while (*p) {
+/* header-field = field-name ":" OWS field-value OWS
+ field-name = token = 1*tchar */
+tag = 0;
+while ((unsigned)((*p | 32) - 'a') < 26 || (unsigned)(*p - '0') < 10 ||
+ *p == '!' || *p == '#' || *p == '$' || *p == '%' || *p == '&' ||
+ *p =='\'' || *p == '*' || *p == '+' || *p == '-' || *p == '.' ||
+ *p == '^' || *p == '_' || *p == '`' || *p == '|' || *p == '~') {
+p++;
+tag = 1;
+}
+if (!tag || *p != ':') {
+error = "no valid field name";
+goto fail;
+}
+/* field-value = *( field-content / obs-fold )
+ field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]
+ field-vchar = VCHAR / obs-text
+ VCHAR = visible USASCII character
+ obs-text = %x80-FF
+ obs-fold = CRLF 1*( SP / HTAB ) */
+while (*p) {
+while (*p >= 32 || *p == '\t')
+p++;
+if (p[0] != '\r' || p[1] != '\n') {
+error = *p ? "invalid character in vield value" :
+ "missing trailing CRLF";
+goto fail;
+}
+p += 2;
+if (*p != ' ' && *p != '\t')
+break;
+p++;
+}
+}
+return;
+
+fail:
+av_log(log, AV_LOG_WARNING, "Invalid HTTP header at offset %u: %s\n",
+ (unsigned)(p - header), error);
+}
+
static int http_open(URLContext *h, const char *uri, int flags,
AVDictionary **options)
{
@@ -310,12 +360,8 @@ static int http_open(URLContext *h, const char *uri, int flags,
if (options)
av_dict_copy(&s->chained_options, *options, 0);
-if (s->headers) {
-int len = strlen(s->headers);
-if (len < 2 || strcmp("\r\n", s->headers + len - 2))
-av_log(h, AV_LOG_WARNING,
- "No trailing CRLF found in HTTP header.\n");
-}
+if (s->headers)
+validate_headers_option(s, s->headers);
ret = http_open_cnx(h, options);
if (ret < 0)
--
2.1.4
From 68591d1dc097cae158eb8bcb08abc884dc414a3d Mon Sep 17 00:00:00 2001
From: Nicolas George
Date: Wed, 11 Mar 2015 11:50:21 +0100
Subject: [PATCH 2/2] doc/protocols: insist on HTTP headers syntax.
Signed-off-by: Nicolas George
---
doc/protocols.texi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 5f6dfa8..b46a36d 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -230,7 +230,8 @@ Set a specific content type for the POST messages.
@item headers
Set custom HTTP headers, can override built in default headers. The
-value must be a string encoding the headers.
+value must be a string encoding the headers, with lines terminated by CRLF,
+including the final one.
@item multiple_requests
Use persistent connections if set to 1, default is 0.
--
2.1.4
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] [PATCH] lavfi: add inverse telecine filter
On 11 March 2015 at 15:10, Clément Bœsch wrote: > On Wed, Mar 11, 2015 at 07:12:16AM +, Carl Eugen Hoyos wrote: > > Timothy Gu gmail.com> writes: > > > > > > This is an exact inverse of the telecine filter > > > > unlike previously existing pullup and fieldmatch > > > > ones. > > > > > > What's the difference between the three seemingly > > > similar filters? > > > > The other two are similar (speed and license are > > different): They try to detect the telecined > > frames and reconstruct the original progressive > > stream even if cuts were made. They sometimes miss > > telecined frames. > > This filter does not detect anything, it applies a > > fixed pattern to the input stream: It fails very > > badly if the input was cut (and the pattern > > changed), > > > it works perfectly for streams that > > contain a constant pattern. > > Did this happen even once with real material? > > We aim to have it work perfectly for such streams. It has not been tested on a proper telecine stream yet. As the description mentions, this work is still under progress. I am collecting suitable test samples and would like to discuss the algorithm for any suggestions. Should I add the algorithm in the description to gain feedback on it? > > > > Carl Eugen > > > > -- > Clément B. > > ___ > 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] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On Tue, 10 Mar 2015 18:02:12 +0100 Reimar Döffinger wrote: > On 10.03.2015, at 12:10, wm4 wrote: > > > On Mon, 09 Mar 2015 18:56:57 +0100 > > Reimar Döffinger wrote: > >>> > >>> What I do is simply restart decoding with the packet that failed the > >>> hardware decoder. Don't need to buffer anything, you still have the > >>> AVPacket in question anyway. > >> > >> Uh, so you simply assume that decoding the same frame twice doesn't break > >> anything? How do you enable multithreading? Do you just assume you can do > >> that in the middle of decoding? > >> Or do you create a new decoder? In which case, how do you ensure that the > >> new SPS wasn't in an earlier packet due to bad muxing for example? > >> Also the buffering issue is the other way, when you try to go from > >> multithreading to HW decode, how do you handle that? > >> If it works well I'd be totally in favour, but I strongly suspect it only > >> works because you both got lucky and don't even try the hard things and > >> still need more code on the user side. > > > > Just create a new context. > > There is nothing "just" about creating a new context, not for those who want > seamless switching between hardware and software decoding. > I am not one of those people admittedly, but I do see it as an issue. Then lavc should provide a proper mechanism for this. The get_format thing doesn't work if the hardware decoder and the software decoder are different AVCodecs. > > Really, there are (or will be) hardware decoders which do not fit into > > the hwaccel model. So you need to open a new codec anyway to handle > > fallbacks correctly. I think the current way how hardware decoding > > fallback is supposed to work in lavc sucks by design, has multiple > > implementation problems (like this one!), and is a dead-end. > > That may well be, but that doesn't mean it should be our goal to make things > work worse and be even more effort for users. > ___ > 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] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On 11.03.2015, at 12:34, wm4 wrote: > On Tue, 10 Mar 2015 18:02:12 +0100 > Reimar Döffinger wrote: Also the buffering issue is the other way, when you try to go from multithreading to HW decode, how do you handle that? If it works well I'd be totally in favour, but I strongly suspect it only works because you both got lucky and don't even try the hard things and still need more code on the user side. >>> >>> Just create a new context. >> >> There is nothing "just" about creating a new context, not for those who want >> seamless switching between hardware and software decoding. >> I am not one of those people admittedly, but I do see it as an issue. > > Then lavc should provide a proper mechanism for this. > > The get_format thing doesn't work if the hardware decoder and the > software decoder are different AVCodecs. No disagreement here. That doesn't make any of the not working suggestions a solution though, and I don't find it appropriate to "attack" (ok, a bit exaggerated) people trying to make the code we have work for them. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On 09.03.2015, at 15:54, Hendrik Leppkes wrote: > > Of course avcodec shouldn't crash when you use it, but a patch to > disallow this combination would never be accepted by yourself and some > others that "like" this cheap (albeit wrong) method for fallback. I forgot to reply: of course I would accept a patch that returns PATCHWELCOME for HEVC if the alternative is that the code crashes and explodes into the users' face... Or just not advertise hwaccel if multi-threading is enabled. Breaking code that currently works like H.264 to disallow this I would indeed mind though. > So the only solution is to add the extra magic that makes it not > crash, and someone should produce a patch for that if their setup can > reproduce it. Though that as preferred by me indeed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
On Tue, Mar 10, 2015 at 02:09:10PM +0100, Nicolas George wrote: > Le decadi 20 ventôse, an CCXXIII, Carl Eugen Hoyos a écrit : > > Please add a reference to ticket #3268 > > to the commit message. > > I was about to reply "locally added", but no, because it does not fix that > ticket. what is the problem ? can you elaborate? > > Re-thinking on the whole discussion, I withdraw this patch, it is wrong. This > part of the code is an API, not an UI, so it is better if it is strict. I > will try to propose another patch for pure validation. > > Regarding the trac ticket itself, I wrote this, and I stick to it: > > # I am not in favour of fixing the shortcomings of the user's shell in > # FFmpeg's libraries > > # If we are talking about end-user interface, the changes should happen in > # cmdutils.c. > > In other words, I vote for closing #3268 as WONTFIX and suggesting windows > users to use a better shell (maybe the so-called powershell introduced in > the recent windows versions can do it). theres a bug in OUR code it should be fixed in our code. The line ending characters differ between platforms and users do in general not know about these differences nor should they need to. the command line input will in the overwhelming number of cases be in the platforms native "line ending encoding". the strings passed on API level will certainly often be in the platforms native encoding as well, in the case of headers they might be in the CRLF encoding too, and considering that these are generic options, some applications will export them generically and not have special cases to re encode the strings, and i think quite independant of the option passing API. > > If people really want to fix microsoft's shortcomings in FFmpeg, then it > must happen in the UI, not the API, i.e. in cmdutils.c. Maybe something like > that: "ffmpeg ... -expand -headers 'Cookies: chocolate\r\n'" (-expand being > a new option meaning "perform escape-character expansion on the following > option argument"). But I do not intend to work on it, because anybody can > get a shell where $'\r\n' works. I think thats alot of effort on the users part you ask here for IMO User interfaces should be designed so they do what the user wants with minimun effort on the users part. Aka i belive its not the human who should have to adapt to interface to a computer (in the extreemest case that would be flipping bits one by one in memory) but rather the computer should adapt to how humans interact where it is possible and works reliable [...] -- 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] sftp: support reading config from ~/.ssh/config
On 11.03.2015 11:15, Nicolas George wrote: Le primidi 21 ventôse, an CCXXIII, Florian Jacob a écrit : Do we have a way to apply ffmpeg-specific options? We can force to use no compression in the code, by adding this line: ssh_options_set(libssh->session, SSH_OPTIONS_COMPRESSION, "no"); after parsing the config file. I think that is not what Reimar had in mind, but rather something like this: ssh_set_app_tag(libssh->session, "ffmpeg"); ssh_set_app_tag(libssh->session, "multimedia"); Match tag=multimedia Compression off Unfortunately, there is no "tag" criterion for the Match directive. Maybe the OpenSSH guys would be amenable to a patch. This would also mean that the user can't configure to use compression for ffmpeg even if they want to, though, but this wasn't possible before either. One might could argue that connections that benefit and work faster with the compression option are too slow to stream media, anyway. Other thoughts? I firmly believe in the following principles: 1. If the user made an explicit choice, the application must obey, even if the choice seems stupid. In the case of SSH: compression is disabled by default, so enabling it is an explicit choice. 2. Applications should as much as possible try to both leave the choice to the user and have a sensible default, but if for some reason it is not possible (poor API on a library), then priority should be given to user choice. Isn't this compression transparent? I can play media files with both compression on and off. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sftp: support reading config from ~/.ssh/config
On 11.03.2015, at 13:05, Lukasz Marek wrote: > On 11.03.2015 11:15, Nicolas George wrote: >> >> >> I firmly believe in the following principles: >> >> 1. If the user made an explicit choice, the application must obey, even if >>the choice seems stupid. >> >>In the case of SSH: compression is disabled by default, so enabling it is >>an explicit choice. >> >> 2. Applications should as much as possible try to both leave the choice to >>the user and have a sensible default, but if for some reason it is not >>possible (poor API on a library), then priority should be given to user >>choice. > > Isn't this compression transparent? I can play media files with both > compression on and off. Of course, it's just a pointless waste of server CPU time for already compressed files. If badly implemented it will in addition waste bandwidth and client CPU power as well. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
Le primidi 21 ventôse, an CCXXIII, Michael Niedermayer a écrit : > what is the problem ? > can you elaborate? The problem raised in this trac ticket is that windows users seem unable to put control characters in their command lines. I thought it was a shortcoming of the windows command line interpreter, but I have come to suspect it may be a deeper flaw in the way command-line arguments are passed to programs. I have submitted the question to a friend who knows windows well. > theres a bug in OUR code it should be fixed in our code. No, there is no bug in our code. The issue is definitely not a bug in lavf: lavf takes a C string, and except for \0, a C string can contain any character without any problem. And this API is not even as bad as some people claim: passing a list of values is always clumsy. It may be a shortcoming in our command-line interface IF AND ONLY IF it is established that some OSes can not pass arbitrary C string as arguments to main(). A shortcoming, not a bug. > The line ending characters differ between platforms and users do in > general not know about these differences nor should they need to. You seem to be under the misapprehension the issue is about different line ending encodings. It is not, it never was. > IMO > User interfaces should be designed so they do what the user wants with > minimun effort on the users part. True, but this "minimum effort" must be measured globally, not locally. It may seem convenient to make a special case for this or that option. If you only look at the effort required to invoke that particular option, that is true. But you also have to count the effort to remember which option has a special case. When you have hundreds of options like FFmpeg, you want, as much as possible, that ALL OPTIONS BEHAVE EXACTLY THE SAME. Any other consideration is secondary. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sftp: support reading config from ~/.ssh/config
Le primidi 21 ventôse, an CCXXIII, Reimar Döffinger a écrit : > Of course, it's just a pointless waste of server CPU time for already > compressed files. Possibly not just CPU time, user time too: on my box (rather fast for that kind of thing), the speed drops from 2500 Mo/s (based on used CPU time, actual speed 500 Mo/s due to other limits) to 31 Mo/s. You can see the difference on gigabit ethernet under good circumstances. On a less powerful CPU (Atom 1.8 GHz), the figures are 4 Mo/s vs. 15 Mo/s. I know ADSL links where it would make a difference, and it may also make a difference for remotely reading a high-bitrate Blu-ray. But still, I do not consider it an issue, as I still think users enabling compression for SSH (nit: for SSH, not just "interactive SSH", i.e. scp and SFTP too) should know what they are doing. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
On Wed, Mar 11, 2015 at 01:24:28PM +0100, Nicolas George wrote: > Le primidi 21 ventôse, an CCXXIII, Michael Niedermayer a écrit : > > what is the problem ? > > can you elaborate? > > The problem raised in this trac ticket is that windows users seem unable to > put control characters in their command lines. the question or well rather my question is why do they need to put control characters in there in the first place. There should be no need for that [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
Le primidi 21 ventôse, an CCXXIII, Michael Niedermayer a écrit : > the question or well rather my question is why do they need to put > control characters in there in the first place. > There should be no need for that Control characters are the only characters that are not valid in a HTTP header value, therefore they are the only usable delimiters to group several headers in a single string, unless you want to implement one more level of escaping. Or do you have another solution in mind? Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Reorganized libpostproc code
Hi, On Wed, Mar 11, 2015 at 2:06 AM, James Almer wrote: > On 11/03/15 12:57 AM, Tucker DiNapoli wrote: > > From: Tucker DiNapoli > > A couple comments below. > > > > > The only changes were formating and moving code. > > This needs to be split into several different patches. Also, why does > "moving code" end up with the > addition of one thousand new lines? > > > --- > > libpostproc/postprocess.c | 436 ++-- > > libpostproc/postprocess_c.c| 1328 > > > libpostproc/postprocess_internal.h | 30 +- > > libpostproc/postprocess_template.c | 124 ++-- > > 4 files changed, 1468 insertions(+), 450 deletions(-) > > create mode 100644 libpostproc/postprocess_c.c > > If you want to properly refactor the code, it may be a good chance to move > the target specific > assembly to their own separate folders (x86, ppc, etc). > Look at the other libraries to see how it's normally done. > > Admittedly outside of the scope of your qualification task, so don't worry > too much for now. > > [...] > > > @@ -573,8 +217,13 @@ static av_always_inline void do_a_deblock_C(uint8_t > *src, int step, > > #include "postprocess_template.c" > > #define TEMPLATE_PP_SSE2 1 > > #include "postprocess_template.c" > > +#define TEMPLATE_PP_AVX2 1 > > +#include "postprocess_template.c" > > #else > > -#if HAVE_SSE2_INLINE > > +#if HAVE_AVX2_INLINE > > I'm not sure people will be happy with inline AVX2 code being introduced > to the tree. Last time i > tried with AVX it was not well received and eventually replaced with a > yasm port. > I guess it's an acceptable start, considering at some point all the asm > should be ported to yasm > anyway. No this is not OK. No inline avx2. I spent weeks cleaning up the old crap (in libswresample) to eventually end up with code that was 25%? faster than the inline stuff. I don't mind cleaning up crap but let's not poop anew. I'm happy to accept it as a qualification task completion but this code honestly shouldn't go into the tree. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
On Wed, Mar 11, 2015 at 02:59:04PM +0100, Nicolas George wrote: > Le primidi 21 ventôse, an CCXXIII, Michael Niedermayer a écrit : > > the question or well rather my question is why do they need to put > > control characters in there in the first place. > > There should be no need for that > > Control characters are the only characters that are not valid in a HTTP > header value, therefore they are the only usable delimiters to group several > headers in a single string, unless you want to implement one more level of > escaping. > > Or do you have another solution in mind? well i sure do not want more escaping and yes i do, or lets say i think i do. If the user passes just one header "line" then either he adds CRLF at the end or he doesnt. These 2 cases can be easily distnguished and teh code can add CRLF if its missing this is basically carls patch and i think its good and simplifies useage, doing this at cmdutils level is not a good idea IMHO as other applications as well need to pass header strings from the user to lavf. and requiring every app, GUI based ones included to sanitize the string before passing it on or requireing the user to litterally add the CRLF somehow seems very inconvenient to me The case of multiple header lines is trickier, http uses CRLF as seperator IIRC. My idea was to be a bit more flexible here and allow any line ending character and normalize these to CRLF before sending them. This is your first patch i belive. This would allow users to just use a quote and the enter key after each header i assume on the command line. While in a textfield of a GUI it can be entered easily 1 line per header. Maybe iam missing something here but it seems convenient to allow this than to strictly require CRLF [...] -- 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 2/4] x86: xvid_idct: port MMX IDCT to yasm
On Wed, Mar 11, 2015 at 03:09:51PM +0100, Christophe Gisquet wrote: > 2015-03-11 2:26 GMT+01:00 Michael Niedermayer : > > this breaks > > make libavcodec/dct-test > > ... > > LD libavcodec/dct-test > > libavcodec/dct-test.o:(.rodata+0xe8): undefined reference to > > `ff_xvid_idct_mmx' > > libavcodec/dct-test.o:(.rodata+0x108): undefined reference to > > `ff_xvid_idct_mmxext' > > This is because they are no longer build for ARCH_X86_64. What would > be the preference here? Not testing them then, or keep testing them > (and therefore, do compile them)? personally iam in favor of more things being tested, but iam fine with either [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] x86: xvid_idct: port MMX IDCT to yasm
Hi, 2015-03-11 15:20 GMT+01:00 Michael Niedermayer : > personally iam in favor of more things being tested, but iam fine > with either I'll see what the opinions are in ~30H then. It looks to be around 4.5KB more data, which isn't huge, and doesn't cause a noticeable increase in compile time. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] mips/asmdefs: use asm/sgidefs.h header on linux
On Sat, Mar 07, 2015 at 12:42:30PM +, James Cowgill wrote: > On Sat, 2015-03-07 at 13:32 +0100, Michael Niedermayer wrote: > > On Sat, Mar 07, 2015 at 10:56:45AM +, James Cowgill wrote: > > > Unfortunately android < api 21 (lollipop) doesn't have the sgidefs.h > > > header, > > > but the linux kernel does have an almost equivalent asm/sgidefs.h which > > > will > > > do so use that header if we can. > > > > > > Change _ABI64 to _MIPS_SIM_ABI64 which is defined in both headers. > > > > > > Signed-off-by: James Cowgill > > > > tryng to build for androidmips: > > In file included from ffmpeg/libavcodec/mips/mpegaudiodsp_mips_float.c:58: > > ffmpeg/libavutil/mips/asmdefs.h:30:5: warning: "HAVE_ASM_SGIDEFS_H" is not > > defined > > ffmpeg/libavutil/mips/asmdefs.h:33:21: error: sgidefs.h: No such file or > > directory > > ffmpeg/libavutil/mips/asmdefs.h:36:18: warning: "_MIPS_SIM_ABI64" is not > > defined > > > > i guess you are missing a include config.h in this > > Woops sorry - I don't have access to any mips machines at the weekend so > it wasn't tested a huge amount (time for qemu...) any news on this ? id like to put some fix in 2.6.1 or should i just revert the commit causing this ? thanks [...] -- 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
[FFmpeg-devel] DCA Decoder
I've been working on adding XLL for the last couple months, it's still not quite complete, basically I have to combine the Core and XLL samples before it's output, and I also have to finish the latter stages of decoding the XLL like channel decorreclation, and post processing. There are a few issues thought. 1: My code doesn't have the most recent chances from master, how do I fix this? 2: I read that you'd prefer for code to be small and self contained, but how can I do that when the later functions directly require earlier ones? 3: I've been using the variable names the white paper uses which doesn't match your guidelines, obviously they need to be renamed but I'm not sure what else you guys want me to do with that? 4: currently almost all of the variables are being stored in DCAContext and accessed in different functions this way, I assume this is looked down upon and you'll want me to change this style to use the variables in the disparate functions when it's called rather than passing it around the backend, is this correct? That said, I've rewritten the ExSS code, ExSS Asset Descriptor, XLL, and XLL ChSet functions are completely ready to go. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On 3/11/2015 2:42 PM, Marcus Johnson wrote: > I've been working on adding XLL for the last couple months, it's still not > quite complete, basically I have to combine the Core and XLL samples before > it's output, and I also have to finish the latter stages of decoding the > XLL like channel decorreclation, and post processing. There is a patch on Libav's mailing list that will likely soon be merged that implements the XLL extension. Have you looked at that or talk to its author? Working together seems better than duplicated effort. > 1: My code doesn't have the most recent chances from master, how do I fix > this? git pull --rebase ? (backup to a branch first) > 2: I read that you'd prefer for code to be small and self contained, but > how can I do that when the later functions directly require earlier ones? Not sure I follow? > 3: I've been using the variable names the white paper uses which doesn't > match your guidelines, obviously they need to be renamed but I'm not sure > what else you guys want me to do with that? Can't really tell without looking > 4: currently almost all of the variables are being stored in DCAContext and > accessed in different functions this way, I assume this is looked down upon > and you'll want me to change this style to use the variables in the > disparate functions when it's called rather than passing it around the > backend, is this correct? Can't really tell without looking. > That said, I've rewritten the ExSS code, ExSS Asset Descriptor, XLL, and > XLL ChSet functions are completely ready to go. Does this include a fixed point implementation to make it actually lossless? IIRC this is the only thign the existing patch set from Niels lacks. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3] mips/asmdefs: use _ABI64 as defined by gcc
Unfortunately android < api 21 (lollipop) doesn't have the sgidefs.h header, the easiest way around this is to just use the preprocessor definitions from gcc / clang. Signed-off-by: James Cowgill --- Hi, Sorry I forgot about this a little. I think that doing it this way is better than messing around with different headers which may not exist. I know it works on GCC and Clang. Thanks, James libavutil/mips/asmdefs.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/libavutil/mips/asmdefs.h b/libavutil/mips/asmdefs.h index a3a5ee3..fdf82a0 100644 --- a/libavutil/mips/asmdefs.h +++ b/libavutil/mips/asmdefs.h @@ -27,9 +27,7 @@ #ifndef AVUTIL_MIPS_ASMDEFS_H #define AVUTIL_MIPS_ASMDEFS_H -#include - -#if _MIPS_SIM == _ABI64 +#if defined(_ABI64) && _MIPS_SIM == _ABI64 # define PTRSIZE" 8 " # define PTRLOG " 3 " # define PTR_ADDU "daddu " -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
I thought the patch on LibAV was completely removed? it was purged from the codebase like 9 months ago or something, I stumbled on that while trying to fix some of the issues with the white paper I was having. I haven't bothered with the Core decoder, but everything I've extracted so far is fixed point. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On Wed, Mar 11, 2015 at 4:02 PM, Marcus Johnson wrote: > I thought the patch on LibAV was completely removed? http://thread.gmane.org/gmane.comp.video.libav.devel/66825/focus=66826 It'll probably be merged soon'ish. It still has some open TODOs, but at this point its probably a much better idea to work on improving this instead of creating a parallel implementation. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/ac3dec: Fix undefined shifts
Found-by: Clang -fsanitize=shift
Reported-by: Thierry Foucu
Signed-off-by: Michael Niedermayer
---
libavcodec/ac3dec.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index 2f78d73..3200bcb 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -112,7 +112,7 @@ static const uint8_t ac3_default_coeffs[8][5][2] = {
static inline int
symmetric_dequant(int code, int levels)
{
-return ((code - (levels >> 1)) << 24) / levels;
+return ((code - (levels >> 1)) * (1 << 24)) / levels;
}
/*
@@ -470,7 +470,7 @@ static void calc_transform_coeffs_cpl(AC3DecodeContext *s)
int cpl_coord = s->cpl_coords[ch][band] << 5;
for (bin = band_start; bin < band_end; bin++) {
s->fixed_coeffs[ch][bin] =
-MULH(s->fixed_coeffs[CPL_CH][bin] << 4, cpl_coord);
+MULH(s->fixed_coeffs[CPL_CH][bin] * (1 << 4),
cpl_coord);
}
if (ch == 2 && s->phase_flags[band]) {
for (bin = band_start; bin < band_end; bin++)
@@ -567,8 +567,7 @@ static void ac3_decode_transform_coeffs_ch(AC3DecodeContext
*s, int ch_index, ma
av_log(s->avctx, AV_LOG_ERROR, "bap %d is invalid in plain
AC-3\n", bap);
bap = 15;
}
-mantissa = get_sbits(gbc, quantization_tab[bap]);
-mantissa <<= 24 - quantization_tab[bap];
+mantissa = (unsigned)get_sbits(gbc, quantization_tab[bap]) << (24
- quantization_tab[bap]);
break;
}
coeffs[freq] = mantissa >> exps[freq];
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] (no subject)
sir, i really want to contribute to your project on "SUBTITLES". i have good coding skill in c and i very well know how to use git. but i have no idea of fansubbing but i will learn it as soon as possible. please guide me here, i will be very thankful. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On Wed, Mar 11, 2015 at 04:07:00PM +0100, Hendrik Leppkes wrote: > On Wed, Mar 11, 2015 at 4:02 PM, Marcus Johnson > wrote: > > I thought the patch on LibAV was completely removed? > > http://thread.gmane.org/gmane.comp.video.libav.devel/66825/focus=66826 > > It'll probably be merged soon'ish. It still has some open TODOs, but > at this point its probably a much better idea to work on improving > this instead of creating a parallel implementation. whats important is a patchset based on and tested on FFmpeg, at least if people want a working decoder in FFmpeg [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On 3/11/2015 8:25 PM, Michael Niedermayer wrote: > whats important is a patchset based on and tested on FFmpeg, at least > if people want a working decoder in FFmpeg No, what's important is that the best possible code is used. Origin is irrelevant. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On Wed, Mar 11, 2015 at 09:04:39PM +, Derek Buitenhuis wrote: > On 3/11/2015 8:25 PM, Michael Niedermayer wrote: > > whats important is a patchset based on and tested on FFmpeg, at least > > if people want a working decoder in FFmpeg > > No, what's important is that the best possible code is used. Origin is > irrelevant. you misunderstood me Thats analogous to saying "no its not important to put fuel in a car, its important to drive the best car" Of course the best possible code should be used but that either is based on FFmpeg and tested on FFmpeg already or it needs to be git rebased / merged onto FFmpeg and then tested. the 2nd is more work, so i suggest that new code is based on top of FFmpeg already. Merge/rebase that patchset from Libav if you want to work on top of it. The more code is rebased and merged around the higher the risk of bugs Also if someone has testcases for all the new DCA features, i would be interrested to have them so i can test these things if/when needed Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On 3/11/2015 9:36 PM, Michael Niedermayer wrote: > Thats analogous to saying "no its not important to put fuel in a > car, its important to drive the best car" No what I propose is to look at both and decide which is best. Simply being submitted to FFmpeg first does not make it better. > the 2nd is more work, so i suggest that new code is based on top of > FFmpeg already. Merge/rebase that patchset from Libav if you want > to work on top of it. Yeah, merge one patchset in FFmpeg, and if it turns out the other functions better, the resulting mess is best summed up as "a clusterf*ck"... > The more code is rebased and merged around the higher the risk of > bugs This is a strawman argument (or perhaps just FUD). > Also if someone has testcases for all the new DCA features, i would > be interrested to have them so i can test these things if/when needed >From what I understand, neither of them implements fixed point yet in the core DCA decoder, which means neither is actually lossless or bit-exact. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] Moved postprocessing routines from postprocess.c to seperate file
On Wed, Mar 11, 2015 at 01:51:12PM -0400, Tucker DiNapoli wrote: > This moves c functions to process blocks horozontally into a seperate > file, so that none of the postprocessing algorithms are in the main > postprecess.c file [...] > diff --git a/libpostproc/postprocess_c.c b/libpostproc/postprocess_c.c > new file mode 100644 > index 000..bf22e95 > --- /dev/null > +++ b/libpostproc/postprocess_c.c > @@ -0,0 +1,373 @@ > +/** > +* C implementation of postprocessing routines > +* Copyright (C) 2001-2002 Michael Niedermayer (michae...@gmx.at) > +* Copyright (c) 2015 Tucker DiNapoli > +* > +* 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 > +**/ libpostproc is under GPL this is the LGPL license also i suggest you add your name to the copyright when you made significant changes to the code not when its copy and pasted [...] -- 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 2/2] Moved templated c postprocessing routines into seperate file
On Wed, Mar 11, 2015 at 01:51:13PM -0400, Tucker DiNapoli wrote: > Currently different versions of the postprocessing routines are > generated from a template. Ultimately I intend to remove this by > replacing the inline assembly with seperate yasm files. The c routines > will still be needed, so they need to be moved to a seperate file. > The routines were added to the file introduced by the last commit. > --- > libpostproc/postprocess.c | 7 +- > libpostproc/postprocess_c.c | 829 > > 2 files changed, 830 insertions(+), 6 deletions(-) code should not be duplicated for each C function you add to postprocess_c.c the corresponding C code should be removed from the template (unless its needed for tha asm to function) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On 3/11/2015 2:42 PM, Marcus Johnson wrote: > I've been working on adding XLL for the last couple months, it's still not > quite complete, basically I have to combine the Core and XLL samples before > it's output, and I also have to finish the latter stages of decoding the > XLL like channel decorreclation, and post processing. Forgot to ask: Is it available in a branch somewhere to review? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/h264_mb: Fix undefined shifts
Found-by: Clang -fsanitize=shift
Reported-by: Thierry Foucu
Signed-off-by: Michael Niedermayer
---
libavcodec/h264_mb.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavcodec/h264_mb.c b/libavcodec/h264_mb.c
index dd406c7..a4653aa 100644
--- a/libavcodec/h264_mb.c
+++ b/libavcodec/h264_mb.c
@@ -213,7 +213,7 @@ static av_always_inline void mc_dir_part(H264Context *h,
H264Picture *pic,
const int mx = h->mv_cache[list][scan8[n]][0] + src_x_offset * 8;
int my= h->mv_cache[list][scan8[n]][1] + src_y_offset * 8;
const int luma_xy = (mx & 3) + ((my & 3) << 2);
-ptrdiff_t offset = ((mx >> 2) << pixel_shift) + (my >> 2) *
h->mb_linesize;
+ptrdiff_t offset = (mx >> 2) * (1 << pixel_shift) + (my >> 2) *
h->mb_linesize;
uint8_t *src_y= pic->f.data[0] + offset;
uint8_t *src_cb, *src_cr;
int extra_width = 0;
@@ -288,9 +288,9 @@ static av_always_inline void mc_dir_part(H264Context *h,
H264Picture *pic,
emu |= (my >> 3) < 0 || (my >> 3) + 8 >= (pic_height >> 1);
}
-src_cb = pic->f.data[1] + ((mx >> 3) << pixel_shift) +
+src_cb = pic->f.data[1] + ((mx >> 3) * (1 << pixel_shift)) +
(my >> ysh) * h->mb_uvlinesize;
-src_cr = pic->f.data[2] + ((mx >> 3) << pixel_shift) +
+src_cr = pic->f.data[2] + ((mx >> 3) * (1 << pixel_shift)) +
(my >> ysh) * h->mb_uvlinesize;
if (emu) {
@@ -302,7 +302,7 @@ static av_always_inline void mc_dir_part(H264Context *h,
H264Picture *pic,
}
chroma_op(dest_cb, src_cb, h->mb_uvlinesize,
height >> (chroma_idc == 1 /* yuv420 */),
- mx & 7, (my << (chroma_idc == 2 /* yuv422 */)) & 7);
+ mx & 7, ((unsigned)my << (chroma_idc == 2 /* yuv422 */)) & 7);
if (emu) {
h->vdsp.emulated_edge_mc(h->edge_emu_buffer, src_cr,
@@ -312,7 +312,7 @@ static av_always_inline void mc_dir_part(H264Context *h,
H264Picture *pic,
src_cr = h->edge_emu_buffer;
}
chroma_op(dest_cr, src_cr, h->mb_uvlinesize, height >> (chroma_idc == 1 /*
yuv420 */),
- mx & 7, (my << (chroma_idc == 2 /* yuv422 */)) & 7);
+ mx & 7, ((unsigned)my << (chroma_idc == 2 /* yuv422 */)) & 7);
}
static av_always_inline void mc_part_std(H264Context *h, int n, int square,
@@ -485,7 +485,7 @@ static av_always_inline void prefetch_motion(H264Context
*h, int list,
const int mx = (h->mv_cache[list][scan8[0]][0] >> 2) + 16 * h->mb_x +
8;
const int my = (h->mv_cache[list][scan8[0]][1] >> 2) + 16 * h->mb_y;
uint8_t **src = h->ref_list[list][refn].f.data;
-int off = (mx << pixel_shift) +
+int off = mx * (1<< pixel_shift) +
(my + (h->mb_x & 3) * 4) * h->mb_linesize +
(64 << pixel_shift);
h->vdsp.prefetch(src[0] + off, h->linesize, 4);
@@ -493,7 +493,7 @@ static av_always_inline void prefetch_motion(H264Context
*h, int list,
h->vdsp.prefetch(src[1] + off, h->linesize, 4);
h->vdsp.prefetch(src[2] + off, h->linesize, 4);
} else {
-off= (((mx>>1)+64)<>1) +
(h->mb_x&7))*h->uvlinesize;
+off= ((mx>>1)+64) * (1<>1) +
(h->mb_x&7))*h->uvlinesize;
h->vdsp.prefetch(src[1] + off, src[2] - src[1], 2);
}
}
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/vp9: Fix undefined shifts in decode_frame_header()
Found-by: Clang -fsanitize=shift
Reported-by: Thierry Foucu
Signed-off-by: Michael Niedermayer
---
libavcodec/vp9.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 265dc7e..0405c05 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -689,10 +689,10 @@ static int decode_frame_header(AVCodecContext *ctx,
for (j = 1; j < 4; j++) {
s->segmentation.feat[i].lflvl[j][0] =
av_clip_uintp2(lflvl + ((s->lf_delta.ref[j] +
- s->lf_delta.mode[0]) << sh), 6);
+ s->lf_delta.mode[0]) * (1 << sh)), 6);
s->segmentation.feat[i].lflvl[j][1] =
av_clip_uintp2(lflvl + ((s->lf_delta.ref[j] +
- s->lf_delta.mode[1]) << sh), 6);
+ s->lf_delta.mode[1]) * (1 << sh)), 6);
}
}
--
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] avutil/buffer: Avoid moving the AVBufferRef to a new place in memory in av_buffer_realloc()
On Thu, Jan 15, 2015 at 01:04:55AM +0100, Michael Niedermayer wrote: > This allows reallocating AVBufferRefs without the need to update > all pointers to it > > Signed-off-by: Michael Niedermayer > --- > libavutil/buffer.c |3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) applied [...] -- 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] avutil/buffer: Avoid moving the AVBufferRef to a new place in memory in av_buffer_make_writable()
On Thu, Jan 15, 2015 at 01:04:56AM +0100, Michael Niedermayer wrote: > This allows making a AVBufferRef writable without the need to > update all pointers to it > > Signed-off-by: Michael Niedermayer > --- applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/colormatrix:add slice threading
On Mon, Mar 09, 2015 at 10:01:47PM -0700, Yayoi wrote: > --- > separate a struct variable declaraion and assignment statements. > --- > > libavfilter/vf_colormatrix.c | 146 > --- > 1 file changed, 94 insertions(+), 52 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/http: support auto reconnect
---
libavformat/http.c | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index 55dcb6e..86380b2 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -93,6 +93,7 @@ typedef struct HTTPContext {
AVDictionary *chained_options;
int send_expect_100;
char *method;
+int reconnect;
} HTTPContext;
#define OFFSET(x) offsetof(HTTPContext, x)
@@ -123,6 +124,7 @@ static const AVOption options[] = {
{ "offset", "initial byte offset", OFFSET(off), AV_OPT_TYPE_INT64, { .i64
= 0 }, 0, INT64_MAX, D },
{ "end_offset", "try to limit the request to bytes preceding this offset",
OFFSET(end_off), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, D },
{ "method", "Override the HTTP method", OFFSET(method),
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, E },
+{ "reconnect", "auto reconnect after disconnect before EOF",
OFFSET(reconnect), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, D },
{ NULL }
};
@@ -908,10 +910,12 @@ static int http_buf_read_compressed(URLContext *h,
uint8_t *buf, int size)
}
#endif /* CONFIG_ZLIB */
+static int64_t http_seek_internal(URLContext *h, int64_t off, int whence, int
force_reconnect);
+
static int http_read_stream(URLContext *h, uint8_t *buf, int size)
{
HTTPContext *s = h->priv_data;
-int err, new_location;
+int err, new_location, read_ret, seek_ret;
if (!s->hd)
return AVERROR_EOF;
@@ -945,7 +949,19 @@ static int http_read_stream(URLContext *h, uint8_t *buf,
int size)
if (s->compressed)
return http_buf_read_compressed(h, buf, size);
#endif /* CONFIG_ZLIB */
-return http_buf_read(h, buf, size);
+read_ret = http_buf_read(h, buf, size);
+if (read_ret < 0 && s->reconnect && !h->is_streamed && s->filesize > 0 &&
s->off < s->filesize) {
+av_log(h, AV_LOG_INFO, "Will reconnect at %"PRId64".\n", s->off);
+seek_ret = http_seek_internal(h, s->off, SEEK_SET, 1);
+if (seek_ret != s->off) {
+av_log(h, AV_LOG_ERROR, "Failed to reconnect at %"PRId64".\n",
s->off);
+return read_ret;
+}
+
+read_ret = http_buf_read(h, buf, size);
+}
+
+return read_ret;
}
// Like http_read_stream(), but no short reads.
@@ -1104,7 +1120,7 @@ static int http_close(URLContext *h)
return ret;
}
-static int64_t http_seek(URLContext *h, int64_t off, int whence)
+static int64_t http_seek_internal(URLContext *h, int64_t off, int whence, int
force_reconnect)
{
HTTPContext *s = h->priv_data;
URLContext *old_hd = s->hd;
@@ -1115,8 +1131,9 @@ static int64_t http_seek(URLContext *h, int64_t off, int
whence)
if (whence == AVSEEK_SIZE)
return s->filesize;
-else if ((whence == SEEK_CUR && off == 0) ||
- (whence == SEEK_SET && off == s->off))
+else if (!force_reconnect &&
+ ((whence == SEEK_CUR && off == 0) ||
+ (whence == SEEK_SET && off == s->off)))
return s->off;
else if ((s->filesize == -1 && whence == SEEK_END) || h->is_streamed)
return AVERROR(ENOSYS);
@@ -1151,6 +1168,11 @@ static int64_t http_seek(URLContext *h, int64_t off, int
whence)
return off;
}
+static int64_t http_seek(URLContext *h, int64_t off, int whence)
+{
+return http_seek_internal(h, off, whence, 0);
+}
+
static int http_get_file_handle(URLContext *h)
{
HTTPContext *s = h->priv_data;
--
2.0.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
