Re: [FFmpeg-devel] [PATCH] avcodec/libx264: expose nv21 input support
On Sat, Aug 01, 2015 at 06:42:15AM +0800, Yu Xiaolei wrote: libx264 added support for NV21 input recently. --- libavcodec/libx264.c | 6 ++ 1 file changed, 6 insertions(+) applied btw, if you want git write access, send me your public SSH key 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
Re: [FFmpeg-devel] [PATCH 2/2] libavformat/dsfdec: Error dsf_read_header fixed.
On Fri, Jul 31, 2015 at 08:56:49PM -0400, Ganesh Ajjanagadde wrote:
On Fri, Jul 31, 2015 at 8:08 PM, Michael Niedermayer
mich...@niedermayer.cc wrote:
On Fri, Jul 31, 2015 at 07:33:01PM -0400, Ganesh Ajjanagadde wrote:
On Fri, Jul 31, 2015 at 7:01 PM, Ihar A. Tumashyk itumas...@gmail.com
wrote:
Sample rate is written as is in header . Is *should not* be devined by
8. Refer spec.:
http://dsd-guide.com/sites/default/files/white-
papers/DSFFileFormatSpec_E.pdf
After this patch ffprobe will corretly show sample rate for DSF files.
Signed-off-by: Ihar A. Tumashyk itumas...@gmail.com
---
libavformat/dsfdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dsfdec.c b/libavformat/dsfdec.c
index ae198b2..3e162ae 100644
--- a/libavformat/dsfdec.c
+++ b/libavformat/dsfdec.c
@@ -105,7 +105,7 @@ static int dsf_read_header(AVFormatContext *s)
st-codec-codec_type = AVMEDIA_TYPE_AUDIO;
st-codec-channels = avio_rl32(pb);
-st-codec-sample_rate = avio_rl32(pb) / 8;
+st-codec-sample_rate = avio_rl32(pb);
switch(avio_rl32(pb)) {
case 1: st-codec-codec_id = AV_CODEC_ID_DSD_LSBF_PLANAR; break;
LGTM, thanks for clarifying intent of previous patch.
I am a little puzzled as to why this was never caught till now,
Changing the sample rate like in the patch breaks playback (it plays
much too quick)
you can find samples to test at:
http://www.2l.no/hires/
I really need to stop trusting these spec files that much,
they are often incomplete as in this case. Ironically,
wikipedia here gives a much better description of the format:
https://en.wikipedia.org/wiki/Direct_Stream_Digital,
where they mention that essentially this signal is oversampled by a factor of
8.
As the wiki entry indicates, max frequency of PCM is 352.8 kHz.
In fact, I think previous patch should be reverted:
the wikipedia article says that newer format is called DSD-wide and
uses 8-bit word length.
ffprobe yields the downsampled frequency of 352.8 kHz which is what
actually gets used when one demuxes/
operates on the data per wikipedia.
Thus, I believe previous behavior was correct.
converting between DSD-PCM reduces the sample rate by 8.
at present, the DSD-PCM conversion happens libavcodec/dsddec.c.
however, a 'codec' cannot change sample_rate, so the divide by 8 is performed
earlier in libavformat.
yes, this is a hack.
i have a patch set that moves DSD-PCM conversion into swresample, where it
belongs,
along with adding a DST decoder and support for additional file formats.
If anyone is interested, I can repost.
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
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] libavformat/dsfdec: Error dsf_read_header fixed.
On Fri, Jul 31, 2015 at 08:56:49PM -0400, Ganesh Ajjanagadde wrote:
On Fri, Jul 31, 2015 at 8:08 PM, Michael Niedermayer
mich...@niedermayer.cc wrote:
On Fri, Jul 31, 2015 at 07:33:01PM -0400, Ganesh Ajjanagadde wrote:
On Fri, Jul 31, 2015 at 7:01 PM, Ihar A. Tumashyk itumas...@gmail.com
wrote:
Sample rate is written as is in header . Is *should not* be devined by
8. Refer spec.:
http://dsd-guide.com/sites/default/files/white-
papers/DSFFileFormatSpec_E.pdf
After this patch ffprobe will corretly show sample rate for DSF files.
Signed-off-by: Ihar A. Tumashyk itumas...@gmail.com
---
libavformat/dsfdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dsfdec.c b/libavformat/dsfdec.c
index ae198b2..3e162ae 100644
--- a/libavformat/dsfdec.c
+++ b/libavformat/dsfdec.c
@@ -105,7 +105,7 @@ static int dsf_read_header(AVFormatContext *s)
st-codec-codec_type = AVMEDIA_TYPE_AUDIO;
st-codec-channels = avio_rl32(pb);
-st-codec-sample_rate = avio_rl32(pb) / 8;
+st-codec-sample_rate = avio_rl32(pb);
switch(avio_rl32(pb)) {
case 1: st-codec-codec_id = AV_CODEC_ID_DSD_LSBF_PLANAR; break;
LGTM, thanks for clarifying intent of previous patch.
I am a little puzzled as to why this was never caught till now,
Changing the sample rate like in the patch breaks playback (it plays
much too quick)
you can find samples to test at:
http://www.2l.no/hires/
I really need to stop trusting these spec files that much,
they are often incomplete as in this case. Ironically,
wikipedia here gives a much better description of the format:
https://en.wikipedia.org/wiki/Direct_Stream_Digital,
where they mention that essentially this signal is oversampled by a factor of
8.
As the wiki entry indicates, max frequency of PCM is 352.8 kHz.
In fact, I think previous patch should be reverted:
the wikipedia article says that newer format is called DSD-wide and
uses 8-bit word length.
ffprobe yields the downsampled frequency of 352.8 kHz which is what
actually gets used when one demuxes/
operates on the data per wikipedia.
Thus, I believe previous behavior was correct.
ok, reverted
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
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/4] blowfish: add av_blowfish_alloc()
On Fri, Jul 31, 2015 at 05:58:48PM -0300, James Almer wrote:
On 31/07/15 5:40 PM, Michael Niedermayer wrote:
On Fri, Jul 31, 2015 at 02:18:07PM -0300, James Almer wrote:
Signed-off-by: James Almer jamr...@gmail.com
---
doc/APIchanges | 3 +++
libavutil/blowfish.c | 15 +++
libavutil/blowfish.h | 10 ++
libavutil/version.h | 5 -
4 files changed, 32 insertions(+), 1 deletion(-)
[...]
@@ -30,12 +31,21 @@
* @{
*/
+#if FF_API_CRYPTO_CONTEXT
#define AV_BF_ROUNDS 16
typedef struct AVBlowfish {
uint32_t p[AV_BF_ROUNDS + 2];
uint32_t s[4][256];
} AVBlowfish;
+#else
+typedef struct AVBlowfish AVBlowfish;
+#endif
Is it intended to remove all means to allocate the context on the
stack ?
this would avoid dealing with malloc/free and malloc failure handling
and could be a signifiant advantage also if any usecase is in a API
that lacks the possibility to fail, like maybe some crypto callbacks
with void return
I have no preferences regarding the context, really, I'm just trying to get
the
API for all the modules consistent. Not sure what would be the use of an alloc
function if the context is not opaque, though.
ive no oppinion on the API at all, just remembered that usage without
alloc was something we thought about in some of the things in avutil
long ago. That is some of the APIs in there where designed so they
could be used without *alloc() and the implied complexity.
iam not against droping that if thats what people prefer
It would also be possible to add the alloc code and leave the on stack
usage possibility or try to change the struct to be opaque and still
usable o the stack. There are many possibilities, i dont know which
people prefer.
And you're right, rtmp for example needs some considerable changes to actually
use the alloc functions.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: modify tty state when stderr is redirected
On Fri, Jul 31, 2015 at 10:51:31AM +0200, Nicolas George wrote: Le tridi 13 thermidor, an CCXXIII, Michael Niedermayer a écrit : no disagreement here but as the shell does not do that (well at least not bash here) it causes moderate inconvenience to the developers in everyday work if the terminal needs to be reset after a fate failure And what happens after a FATE failure? Based on my experience, frequently, developers would copy-paste the failing FATE command line and re-run it interactively. And since stderr is no longer redirected, the tty gets trashed. No need of a failure, even: just try this: ffmpeg -lavfi testsrc -f framecrc | head ... ffmpeg is killed by SIGPIPE, which is not caught: terminal trashed. Thats interresting, i tried this and it did not trash my terminal also ive almost never seen ffmpeg trash my terminal with the current code. No matter how i run it GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. 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] libavformat/dsfdec: Error dsf_read_header fixed.
On Fri, Jul 31, 2015 at 07:33:01PM -0400, Ganesh Ajjanagadde wrote:
On Fri, Jul 31, 2015 at 7:01 PM, Ihar A. Tumashyk itumas...@gmail.com wrote:
Sample rate is written as is in header . Is *should not* be devined by
8. Refer spec.:
http://dsd-guide.com/sites/default/files/white-
papers/DSFFileFormatSpec_E.pdf
After this patch ffprobe will corretly show sample rate for DSF files.
Signed-off-by: Ihar A. Tumashyk itumas...@gmail.com
---
libavformat/dsfdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dsfdec.c b/libavformat/dsfdec.c
index ae198b2..3e162ae 100644
--- a/libavformat/dsfdec.c
+++ b/libavformat/dsfdec.c
@@ -105,7 +105,7 @@ static int dsf_read_header(AVFormatContext *s)
st-codec-codec_type = AVMEDIA_TYPE_AUDIO;
st-codec-channels = avio_rl32(pb);
-st-codec-sample_rate = avio_rl32(pb) / 8;
+st-codec-sample_rate = avio_rl32(pb);
switch(avio_rl32(pb)) {
case 1: st-codec-codec_id = AV_CODEC_ID_DSD_LSBF_PLANAR; break;
LGTM, thanks for clarifying intent of previous patch.
I am a little puzzled as to why this was never caught till now,
Changing the sample rate like in the patch breaks playback (it plays
much too quick)
you can find samples to test at:
http://www.2l.no/hires/
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
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/mov: fix regression in processing .aax files
On Fri, Jul 31, 2015 at 01:36:58PM +0300, Vesselin Bontchev wrote:
mov.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
3ce53f8e77ea37ccba5bbee3c18648b169804cf3
0001-avformat-mov-fix-regression-in-processing-.aax-files.patch
From 418d573659dd011de503e45622307974cf437df5 Mon Sep 17 00:00:00 2001
From: Vesselin Bontchev vesselin.bontc...@yandex.com
Date: Fri, 31 Jul 2015 12:16:08 +0200
Subject: [PATCH] avformat/mov: fix regression in processing .aax files
Commit 0a551cbe introduced activation_bytes option, and not specifying
this option (while calling ffmpeg / ffprobe) causes the program to quit
early. Before this commit, ffprobe was capable of processing metadata in
.aax files.
---
libavformat/mov.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index fdba34c..6a81848 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -849,13 +849,13 @@ static int mov_read_adrm(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
/* verify activation data */
if (!activation_bytes || c-activation_bytes_size != 4) {
not part of this patch but
both check for c-activation_bytes_size != 4
is this intended? isnt the 2nd unreachable that way ?
-av_log(c-fc, AV_LOG_FATAL, [aax] activation_bytes option is
missing!\n);
-ret = AVERROR(EINVAL);
+av_log(c-fc, AV_LOG_WARNING, [aax] activation_bytes option is
missing!\n);
+ret = 0; /* allow ffprobe to continue working on .aax files */
goto fail;
}
if (c-activation_bytes_size != 4) {
-av_log(c-fc, AV_LOG_FATAL, [aax] activation_bytes value needs to
be 4 bytes!\n);
-ret = AVERROR(EINVAL);
+av_log(c-fc, AV_LOG_WARNING, [aax] activation_bytes value needs to
be 4 bytes!\n);
+ret = 0; /* allow ffprobe to continue working on .aax files */
goto fail;
}
are both needed for ffprobe ?
wouldnt ffprobe simply have it not set and take the first if() always
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The educated differ from the uneducated as much as the living from the
dead. -- 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/2] libavformat/dsfdec: Error dsf_read_header fixed.
On Fri, Jul 31, 2015 at 8:08 PM, Michael Niedermayer
mich...@niedermayer.cc wrote:
On Fri, Jul 31, 2015 at 07:33:01PM -0400, Ganesh Ajjanagadde wrote:
On Fri, Jul 31, 2015 at 7:01 PM, Ihar A. Tumashyk itumas...@gmail.com
wrote:
Sample rate is written as is in header . Is *should not* be devined by
8. Refer spec.:
http://dsd-guide.com/sites/default/files/white-
papers/DSFFileFormatSpec_E.pdf
After this patch ffprobe will corretly show sample rate for DSF files.
Signed-off-by: Ihar A. Tumashyk itumas...@gmail.com
---
libavformat/dsfdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dsfdec.c b/libavformat/dsfdec.c
index ae198b2..3e162ae 100644
--- a/libavformat/dsfdec.c
+++ b/libavformat/dsfdec.c
@@ -105,7 +105,7 @@ static int dsf_read_header(AVFormatContext *s)
st-codec-codec_type = AVMEDIA_TYPE_AUDIO;
st-codec-channels = avio_rl32(pb);
-st-codec-sample_rate = avio_rl32(pb) / 8;
+st-codec-sample_rate = avio_rl32(pb);
switch(avio_rl32(pb)) {
case 1: st-codec-codec_id = AV_CODEC_ID_DSD_LSBF_PLANAR; break;
LGTM, thanks for clarifying intent of previous patch.
I am a little puzzled as to why this was never caught till now,
Changing the sample rate like in the patch breaks playback (it plays
much too quick)
you can find samples to test at:
http://www.2l.no/hires/
I really need to stop trusting these spec files that much,
they are often incomplete as in this case. Ironically,
wikipedia here gives a much better description of the format:
https://en.wikipedia.org/wiki/Direct_Stream_Digital,
where they mention that essentially this signal is oversampled by a factor of 8.
As the wiki entry indicates, max frequency of PCM is 352.8 kHz.
In fact, I think previous patch should be reverted:
the wikipedia article says that newer format is called DSD-wide and
uses 8-bit word length.
ffprobe yields the downsampled frequency of 352.8 kHz which is what
actually gets used when one demuxes/
operates on the data per wikipedia.
Thus, I believe previous behavior was correct.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
___
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 8/8] doc/example: Add http multi-client example code
On Sat, Aug 01, 2015 at 01:13:28AM +0200, Stephan Holljes wrote: On Fri, Jul 31, 2015 at 4:29 PM, Nicolas George geo...@nsup.org wrote: I have no more remarks on the whole series, I believe it can be applied. If your public Git tree is ready for pulls, you can do a final rebase and send a pull request directly. If not, I can do the same with my tree. Regards, -- Nicolas George I just rebased, added a description and made a pull-request. (My command was: git request-pull master http://git.klaxa.eu/git/ffmpeg simple_http_server_api_implementation I hope that's correct?) merged btw, if you want direct write access (could make sense for future maintaince of teh code for example but not limited to that) then send me your public ssh key thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] ffmpeg: modify tty state when stderr is redirected
On Fri, Jul 31, 2015 at 9:06 AM, Nicolas George geo...@nsup.org wrote: Le tridi 13 thermidor, an CCXXIII, Ganesh Ajjanagadde a écrit : Thanks for disentangling the separate issues very neatly with a mathematical precision. And thank you for turning them into patches. They are exactly what I had in mind (I probably would have added a snide remark against packagers that did not put tty restore in the default config, but that is just me). Hopefully this will satisfy Michael as well. BTW, this is offtopic, but this tty freezing business is one of those things that makes me wonder why stuff on *-nix does not have better defaults? What is the excuse for a shell not cleaning up children it spawns? Is it POSIX compatibility? Or is the excuse that some obscure shell script out there depends on tty state being modified after running a command? I would like the default to be saner, but I doubt I have the energy/expertise to work upstream with all this stuff. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] FFmpegs future and resigning as leader
Hi all Ive been in FFmepg since 14 years and been the leader since 11 years and i feel that iam not the best person for the leader position. I had hoped for a long time that the fork situation would resolve and both sides somehow merging back into one team. All the Libav developers joining FFmpeg again. But even now as the last distributions are preparing to remove Libav, still theres no hint of that happening. Maybe even the opposite. The community is split and its very difficult to be the leader when one is on one side of this split and the other tries everything to push me out I hope my resignation will make it easier for the teams to find back together and avoid a more complete split which would otherwise be the result sooner or later as the trees diverge and merging all improvments becomes too difficult for me to do. also before my resignation, i offer all maintainers who dont yet have, direct write access as i likely will not comb through the ML anymore or not as frequently to apply patches, please send me your public SSH key if you are de facto maintaining or working on some part of FFmpeg or are listed in MAINTAINERs. If people want to continue merges from libav, someone else will have to do these. Indeed i fully admit the work and pressure caused by the merges is a main reason for my resignation. FFmpeg belongs to the FFmpeg developers and the FFmpeg community! will i ever return ? ... i might ..., if theres a nice and friendly environment, no hostile forks or at least none i have to interact with. But i will certainly not return as leader, this is not really a role i ever truly liked, more one i ended up with. Especially as somehow leader is being interpreted by everyone as the guy who does all work noone else does, and takes all responsibility noone else wants to take am i still available for consulting jobs releated to FFmpeg? yes, of course i cant gurantee it for the very distant future but currently yes. And in the very distant future, its a maybe, so just ask if theres something ... what about root, git admin roles, ...? Well iam happy to pass them on to whoever the community chooses and trusts. But please be very carefull who you choose! until someone else is choosen i can continue doing the basic things like security updates and opening git accounts, aka theres no urgency in choosing someone, rather please choose wise than quick. what about GSoC? I agreed to mentor and admin that and i will of course finish that for this summer. I may or may not be available in future FFmpeg GSoCs. If you now think ohh god what should i do, michael resigned very simple, FFmpeg is yours, that is everyones. try your best to make FFmpeg be the best. Post patches, review patches, apply patches, discuss code and design. Report bugs, bisect, debug and fix bugs, add features, help users. Do friendly merges, and if you like do hostile merges. Its all up to you now! PS: To push a merge, i think this wasnt documented, you need to add a Merged-by: to the commit message, thats the only check, i have no special premissions or anything to push merges. PS2: Be carefull about who will be in charge of key infrastructure! and also where power moves when thouse in charge then resign. PS3: I would suggest a new leader if there was a clear pick, a year or 2 ago i would have suggested stefano or clement but they are not so active currently. Maybe a good candidate will appear in the future or stefano ubitux will become more active again in which case i would suggest one of them as leader if the community wants to have a leader and they agree. Thanks to everyone, for everything they did and will do in the future for FFmpeg and the community ! -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] ffmpeg: modify tty state when stderr is redirected
Le tridi 13 thermidor, an CCXXIII, Ganesh Ajjanagadde a écrit : Thanks for disentangling the separate issues very neatly with a mathematical precision. And thank you for turning them into patches. They are exactly what I had in mind (I probably would have added a snide remark against packagers that did not put tty restore in the default config, but that is just me). Hopefully this will satisfy Michael as well. 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] [PATCHv2] ffmpeg: modify tty state when stderr is redirected
On Fri, Jul 31, 2015 at 7:48 AM, Nicolas George geo...@nsup.org wrote: Le tridi 13 thermidor, an CCXXIII, Ganesh Ajjanagadde a écrit : Nevertheless, echo $? invoked right after this yields 2 for both. The reason this happens is the md5sum wrapper sees that the output file has not been written, and errors out there (see the .err files for precisely what I mean). This is why I did not notice it. Ok. Seeing the above, I think just the change in ffmpeg.c along with telling people of the workarounds for both bashrc and zshrc should be enough, with no modification to run-tests.sh. Indeed, but the change to add -nostdin to FATE is also right: FATE is not an interactive process, it should not listen for interactive commands. If the cat paws the q key while FATE is running, it will cause a failure, it should not. There are three issues, and one right fix for each of them: 1. ffmpeg reads command on stdin and needs stdin to be a tty in cbreak mode: the test must be on stdin, not any other file descriptor. Actually, no test at all should work too, since tcgetattr() would fail anyway. - The patch that has just been reverted was right. Indeed, tcgetattr is enough, no need for isatty. I removed the isatty stuff, removes an ugly ifdef and simplifies the code. Made this patch 1. 2. ffmpeg can crash, ffmpeg can not catch all signals (example: memory-leak, OOM killer, SIGKILL, uncatchable): the shell should be configured to restore the tty in a sane state. - ttyctl -f in ~/.zshrc, bash_tty_mode=$(stty -g); PROMPT_COMMAND='stty $bash_tty_mode' in ~/.bashrc; that can be added in the FAQ or the wiki. Added to FAQ, I think faq gets read more by end users. Note that this is useful for them as well, not just developers who want to run fate, etc. Made this patch 2. 3. FATE is non-interactive: it should not listen to interactive commands. - run FATE with -nostdin. Made this patch 3. Thanks for disentangling the separate issues very neatly with a mathematical precision. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] api-seek-test: first version
Works only with video stream.
First pass without seeking -- counts crcs of a frames and store it in an array.
After that it seeks a lot in different places and checks if crcs of these
frames and crcs of frames in array are the same.
---
tests/api/Makefile| 1 +
tests/api/api-seek-test.c | 278 ++
tests/fate/api.mak| 6 +
3 files changed, 285 insertions(+)
create mode 100644 tests/api/api-seek-test.c
diff --git a/tests/api/Makefile b/tests/api/Makefile
index 704987e..59cbc7c 100644
--- a/tests/api/Makefile
+++ b/tests/api/Makefile
@@ -1,5 +1,6 @@
APITESTPROGS-$(call ENCDEC, FLAC, FLAC) += api-flac
APITESTPROGS-$(call DEMDEC, H264, H264) += api-h264
+APITESTPROGS-yes += api-seek
APITESTPROGS += $(APITESTPROGS-yes)
APITESTOBJS := $(APITESTOBJS:%=$(APITESTSDIR)%)
$(APITESTPROGS:%=$(APITESTSDIR)/%-test.o)
diff --git a/tests/api/api-seek-test.c b/tests/api/api-seek-test.c
new file mode 100644
index 000..99fe90c
--- /dev/null
+++ b/tests/api/api-seek-test.c
@@ -0,0 +1,278 @@
+/*
+ * Copyright (c) 2015 Ludmila Glinskih
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/**
+ * Seek test.
+ */
+
+#include libavutil/adler32.h
+#include libavcodec/avcodec.h
+#include libavformat/avformat.h
+#include libavutil/imgutils.h
+
+int64_t *pts_array;
+int64_t *crc_array;
+int size_of_array;
+int number_of_elements;
+
+static int add_crc_to_array(int64_t crc, int64_t pts)
+{
+if (size_of_array = number_of_elements) {
+if (size_of_array == 0)
+size_of_array = 10;
+size_of_array *= 2;
+crc_array = av_realloc(crc_array, size_of_array * sizeof(int64_t));
+pts_array = av_realloc(pts_array, size_of_array * sizeof(int64_t));
+if ((crc_array == NULL) || (pts_array == NULL)) {
+av_log(NULL, AV_LOG_ERROR, Can't allocate array to store crcs\n);
+return AVERROR(ENOMEM);
+}
+}
+crc_array[number_of_elements] = crc;
+pts_array[number_of_elements] = pts;
+number_of_elements++;
+return 0;
+}
+
+static int compare_crc_in_array(int64_t crc, int64_t pts)
+{
+int i;
+for (i = 0; i number_of_elements; i++) {
+if (pts_array[i] == pts) {
+if (crc_array[i] == crc) {
+printf(Comparing 0x%08lx %PRId64 %d is OK\n, crc, pts, i);
+return 0;
+}
+else {
+av_log(NULL, AV_LOG_ERROR, Incorrect crc of a frame after
seeking\n);
+return -1;
+}
+}
+}
+av_log(NULL, AV_LOG_ERROR, Incorrect pts of a frame after seeking\n);
+return -1;
+}
+
+static int compute_crc_of_packets(AVFormatContext *fmt_ctx, int video_stream,
+AVCodecContext *ctx, AVFrame *fr, uint64_t
ts_start, uint64_t ts_end, int no_seeking)
+{
+int number_of_written_bytes;
+int got_frame = 0;
+int result;
+int end_of_stream = 0;
+int byte_buffer_size;
+uint8_t *byte_buffer;
+int64_t crc;
+AVPacket pkt;
+
+byte_buffer_size = av_image_get_buffer_size(ctx-pix_fmt, ctx-width,
ctx-height, 16);
+byte_buffer = av_malloc(byte_buffer_size);
+if (!byte_buffer) {
+av_log(NULL, AV_LOG_ERROR, Can't allocate buffer\n);
+return AVERROR(ENOMEM);
+}
+
+if (!no_seeking) {
+result = av_seek_frame(fmt_ctx, video_stream, ts_start,
AVSEEK_FLAG_ANY);
+printf(Seeking to %PRId64, computing crc for frames with pts
%PRId64\n, ts_start, ts_end);
+if (result 0) {
+av_log(NULL, AV_LOG_ERROR, Error in seeking\n);
+return result;
+}
+avcodec_flush_buffers(ctx);
+}
+
+av_init_packet(pkt);
+do {
+if (!end_of_stream)
+if (av_read_frame(fmt_ctx, pkt) 0)
+end_of_stream = 1;
+if (end_of_stream) {
+pkt.data = NULL;
+pkt.size = 0;
+
[FFmpeg-devel] [PATCH 3/3] tests/fate-run: make FATE non-interactive
FATE is non-interactive; it should not listen to user commands
Signed-off-by: Ganesh Ajjanagadde gajjanaga...@gmail.com
---
tests/fate-run.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index b88730a..7aa5df2 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -93,7 +93,7 @@ probeframes(){
ffmpeg(){
dec_opts=-hwaccel $hwaccel -threads $threads -thread_type $thread_type
-ffmpeg_args=-nostats -cpuflags $cpuflags
+ffmpeg_args=-nostdin -nostats -cpuflags $cpuflags
for arg in $@; do
[ x${arg} = x-i ] ffmpeg_args=${ffmpeg_args} ${dec_opts}
ffmpeg_args=${ffmpeg_args} ${arg}
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Ticket 4197: pkg-config and build system
At the risk of stirring up old feelings about this, I am interested in achieving closure on Ticket4197: https://trac.ffmpeg.org/ticket/4197 Regards, Ganesh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] movtextdec.c: Add support for font names
From: Niklesh niklesh.lalw...@iitb.ac.in
The font names are extracted from the font table, present in text sample entry.
More than one fonts can be present, which is taken care of in the patch.
Signed-off-by: Niklesh niklesh.lalw...@iitb.ac.in
---
libavcodec/movtextdec.c | 86 +++--
1 file changed, 83 insertions(+), 3 deletions(-)
diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
index 869358c..7d4dead 100644
--- a/libavcodec/movtextdec.c
+++ b/libavcodec/movtextdec.c
@@ -36,10 +36,17 @@
#define HCLR_BOX (12)
typedef struct {
+uint16_t fontID;
+uint8_t font_name_length;
+uint8_t font[20];
+} FontRecord;
+
+typedef struct {
uint16_t style_start;
uint16_t style_end;
uint8_t style_flag;
uint8_t fontsize;
+uint16_t style_fontID;
} StyleBox;
typedef struct {
@@ -56,11 +63,13 @@ typedef struct {
StyleBox *s_temp;
HighlightBox h;
HilightcolorBox c;
+FontRecord **ftab;
+FontRecord *ftab_temp;
uint8_t box_flags;
-uint16_t style_entries;
+uint16_t style_entries, ftab_entries;
uint64_t tracksize;
int size_var;
-int count_s;
+int count_s, count_f;
} MovTextContext;
typedef struct {
@@ -80,6 +89,56 @@ static void mov_text_cleanup(MovTextContext *m)
}
}
+static void mov_text_cleanup_ftab(MovTextContext *m)
+{
+int i;
+for(i = 0; i m-count_f; i++) {
+av_freep(m-ftab[i]);
+}
+av_freep(m-ftab);
+}
+
+static int mov_text_t3xg(AVCodecContext *avctx, MovTextContext *m)
+{
+char *t3xg_ptr = avctx-extradata;
+int i;
+// Display Flags
+t3xg_ptr += 4;
+// Alignment
+t3xg_ptr += 2;
+// Background Color
+t3xg_ptr += 4;
+// BoxRecord
+t3xg_ptr += 8;
+// StyleRecord
+t3xg_ptr += 12;
+// FontRecord
+// FontRecord Size
+t3xg_ptr += 4;
+// ftab
+t3xg_ptr += 4;
+m-ftab_entries = AV_RB16(t3xg_ptr);
+t3xg_ptr += 2;
+for (i = 0; i m-ftab_entries; i++) {
+m-ftab_temp = av_malloc(sizeof(*m-ftab_temp));
+if (!m-ftab_temp) {
+mov_text_cleanup_ftab(m);
+return AVERROR(ENOMEM);
+}
+m-ftab_temp-fontID = AV_RB16(t3xg_ptr);
+t3xg_ptr += 2;
+m-ftab_temp-font_name_length = *t3xg_ptr++;
+memcpy(m-ftab_temp-font, t3xg_ptr, m-ftab_temp-font_name_length);
+av_dynarray_add(m-ftab, m-count_f, m-ftab_temp);
+if (!m-ftab) {
+mov_text_cleanup_ftab(m);
+return AVERROR(ENOMEM);
+}
+t3xg_ptr += 10;
+}
+return 0;
+}
+
static int decode_hlit(const uint8_t *tsmb, MovTextContext *m, AVPacket *avpkt)
{
m-box_flags |= HLIT_BOX;
@@ -118,7 +177,7 @@ static int decode_styl(const uint8_t *tsmb, MovTextContext
*m, AVPacket *avpkt)
tsmb += 2;
m-s_temp-style_end = AV_RB16(tsmb);
tsmb += 2;
-// fontID = AV_RB16(tsmb);
+m-s_temp-style_fontID = AV_RB16(tsmb);
tsmb += 2;
m-s_temp-style_flag = AV_RB8(tsmb);
tsmb++;
@@ -147,6 +206,8 @@ static int text_to_ass(AVBPrint *buf, const char *text,
const char *text_end,
MovTextContext *m)
{
int i = 0;
+int j = 0;
+int k = 0;
int text_pos = 0;
while (text text_end) {
if (m-box_flags STYL_BOX) {
@@ -164,6 +225,14 @@ static int text_to_ass(AVBPrint *buf, const char *text,
const char *text_end,
if (m-s[i]-style_flag STYLE_FLAG_UNDERLINE)
av_bprintf(buf, {\\u1});
av_bprintf(buf, {\\fs%d}, m-s[i]-fontsize);
+av_bprintf(buf, {\\fn);
+for (j = 0; j m-ftab_entries; j++) {
+if (m-s[i]-style_fontID == m-ftab[j]-fontID) {
+for (k = 0; k m-ftab[0]-font_name_length; k++)
+av_bprintf(buf, %c, m-ftab[j]-font[k]);
+}
+}
+av_bprintf(buf, });
}
}
}
@@ -215,6 +284,8 @@ static int mov_text_init(AVCodecContext *avctx) {
* it's very common to find files where the default style is broken
* and respecting it results in a worse experience than ignoring it.
*/
+MovTextContext *m = avctx-priv_data;
+mov_text_t3xg(avctx, m);
return ff_ass_subtitle_header_default(avctx);
}
@@ -265,6 +336,7 @@ static int mov_text_decode_frame(AVCodecContext *avctx,
m-style_entries = 0;
m-box_flags = 0;
m-count_s = 0;
+m-count_f = 0;
// Note that the spec recommends lines be no longer than 2048 characters.
av_bprint_init(buf, 0, AV_BPRINT_SIZE_UNLIMITED);
if (text_length + 2 != avpkt-size) {
@@ -313,6 +385,13 @@ static int mov_text_decode_frame(AVCodecContext *avctx,
return avpkt-size;
}
+static int mov_text_decode_close(AVCodecContext *avctx)
+{
+MovTextContext
[FFmpeg-devel] [PATCH 1/3] ffmpeg: modify tty state when stderr is redirected
Removes unnecessary isatty(), fixes Ticket2964
Signed-off-by: Ganesh Ajjanagadde gajjanaga...@gmail.com
---
ffmpeg.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index 5575e2f..fe250e5 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -32,14 +32,12 @@
#include limits.h
#include stdint.h
-#if HAVE_ISATTY
#if HAVE_IO_H
#include io.h
#endif
#if HAVE_UNISTD_H
#include unistd.h
#endif
-#endif
#include libavformat/avformat.h
#include libavdevice/avdevice.h
@@ -370,11 +368,7 @@ void term_init(void)
#if HAVE_TERMIOS_H
if(!run_as_daemon){
struct termios tty;
-int istty = 1;
-#if HAVE_ISATTY
-istty = isatty(0) isatty(2);
-#endif
-if (istty tcgetattr (0, tty) == 0) {
+if (tcgetattr (0, tty) == 0) {
oldtty = tty;
restore_tty = 1;
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On Thu, 30 Jul 2015 17:05:12 +0200 Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: Hi, On 28.07.2015 15:36, Vittorio Giovara wrote: This set contains the removal of all deprecated features marked as such until 2012/early 2013. This was announced several times in the past months and agreed at several meetings (since fosdem and recently at the sprint). With more than two year span, downstream users should have had enough time to update their API usage (or comment otherwise). Unfortunately this is just wishful thinking. As it is, your proposed removal of deprecated features is going to break about three quarters of all packages using the libav* libraries in Debian: i am against removing this api in ffmpeg, if my vote counts for anything. anyway to keep the old api and have the new api at the same time? yes, this means letting the old api rot, i have no problem with this. just to give time for projects to update. or maybe even create a wrapper ? bah. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] New Server
On Fri, Jul 24, 2015 at 07:06:02PM +0200, Michael Niedermayer wrote: Hi all as you all probably know FFmpeg/Mplayer/... is searching for a new free server hosting ... We received the following offers for a new server and hosting. If you think any of them are a bad choice then please speak now! i ommited one non free offer and one unspecific offer from a company who alternatively would want to finnancially sponsor us. as well as at least one which would be technically insufficient If i forgot some offer or theres a mistake in the list below please reply and add/correct the offer ASAP! I also intend to add a mention link to the footer of the FFmpeg webpage for whoever is choosen, several of the sponsors below did not ask for that though. If you object to that, again, please speak now. I intend to accept 2 of the offers below for redundancy, again if you think something else should be done, speak now! I almost forgot replying. And i guess if i dont reply noone will feel authorative and reply anytime soon ... there are only 2 options noone had a argument against. OVH and vlc had arguments in public, hetzner (virus issue 50euro/mo, also public) kierans box is too weak/old to host all our services but works fine for trac atm against nexcess / futurehosting.com i receved a private argument from a rtmpdump developer, as they are US based and hosting rtmpdump in the US is expected by them to be problematic. That leaves DreamHack and the Telepoint/MediaHub offer. I thus accept these 2 offers Thanks alot ! [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
Le tridi 13 thermidor, an CCXXIII, Hendrik Leppkes a écrit : They have had 2-3 years to update, what makes you think they will ever if we don't force them at some point? What makes you think they will ever do it even if we try to force them? They will just stick to an older version of FFmpeg, and that would be worse for everyone else. Well, not all would do that, but some of them, too many, would. Removing it not only serves some purpose of cleanlyness as some people like to pretend, but it actually removes a whole bunch of problems which new users of the API commonly run into because they accidentally use the old API (usually because some ancient example they found used it as well). Not having this old and wrong API at all anymore will prevent a lot of these cases and instead help guide the users towards the new and properly-working and tested API. I can propose the following middle term: - Making the old features disabled by default but very easy to enable if you know how. A single #include libavutil/depcrecated_api.h, for example, or a header that needs to be replaced by another manually at install time (packagers can use a diversion mechanism to create a ffmpeg-deprecated-dev package). - The features stay there but are utterly unsupported. If there is a bug, do not fix it. If there is a security issue, a build failure or anything of the kind, or if it makes it harder to add new features, remove anything in the way. If it breaks third party projects, not our problem. The second point is nice, because it is the least effort policy: we do not make effort to support the deprecated APIs, but we do not make effort to remove them either. 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] New Server
On Fri, 31 Jul 2015 17:35:11 +0200 Michael Niedermayer mich...@niedermayer.cc wrote: On Fri, Jul 24, 2015 at 07:06:02PM +0200, Michael Niedermayer wrote: Hi all as you all probably know FFmpeg/Mplayer/... is searching for a new free server hosting ... We received the following offers for a new server and hosting. If you think any of them are a bad choice then please speak now! i ommited one non free offer and one unspecific offer from a company who alternatively would want to finnancially sponsor us. as well as at least one which would be technically insufficient If i forgot some offer or theres a mistake in the list below please reply and add/correct the offer ASAP! I also intend to add a mention link to the footer of the FFmpeg webpage for whoever is choosen, several of the sponsors below did not ask for that though. If you object to that, again, please speak now. I intend to accept 2 of the offers below for redundancy, again if you think something else should be done, speak now! I almost forgot replying. And i guess if i dont reply noone will feel authorative and reply anytime soon ... there are only 2 options noone had a argument against. OVH and vlc had arguments in public, hetzner (virus issue 50euro/mo, also public) kierans box is too weak/old to host all our services but works fine for trac atm against nexcess / futurehosting.com i receved a private argument from a rtmpdump developer, as they are US based and hosting rtmpdump in the US is expected by them to be problematic. That leaves DreamHack and the Telepoint/MediaHub offer. I thus accept these 2 offers Thanks alot ! [...] yes , thanks to all who offered and thanks to dreamhack and telepoint/mediahub especially (also Nikolay Aleksandrov for answering my question about abuse/virus internet police mails). also thanks michael for helping/doing a lot of work with the server issues and all other devs who put in the extra hours to keep the servers running. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpegs future and resigning as leader
On Fri, Jul 31, 2015 at 05:37:12PM +0200, Clément Bœsch wrote: On Fri, Jul 31, 2015 at 03:53:04PM +0200, Michael Niedermayer wrote: Hi all Ive been in FFmepg since 14 years and been the leader since 11 years and i feel that iam not the best person for the leader position. I had hoped for a long time that the fork situation would resolve and both sides somehow merging back into one team. All the Libav developers joining FFmpeg again. But even now as the last distributions are preparing to remove Libav, still theres no hint of that happening. Maybe even the opposite. The community is split and its very difficult to be the leader when one is on one side of this split and the other tries everything to push me out I hope my resignation will make it easier for the teams to find back together and avoid a more complete split which would otherwise be the result sooner or later as the trees diverge and merging all improvments becomes too difficult for me to do. also before my resignation, i offer all maintainers who dont yet have, direct write access as i likely will not comb through the ML anymore or not as frequently to apply patches, please send me your public SSH key if you are de facto maintaining or working on some part of FFmpeg or are listed in MAINTAINERs. If people want to continue merges from libav, someone else will have to do these. Indeed i fully admit the work and pressure caused by the merges is a main reason for my resignation. FFmpeg belongs to the FFmpeg developers and the FFmpeg community! If some FFmpeg developers are still willing to do that (that is, maybe partially on their respective maintainership areas), may we ask you to document more your process? If that is possible, maybe not limited to these merges. ill try to document things You have been doing an outstanding work for years, and this includes notably: - development - reviews - patch merges - merge of libav - releases heres my release checklist (slightly cleaned up, not sure how usefull it is or if this is too terse thats just pretty much what i used as notes for it) someone could put that in doc/ if wanted, having it in git might simplify work on it fix copyright years rename version next in changeolog to X.Y add -dev tag on commit after release branched add seperator for release position in APIChanges previous name suggestions: cmopn: einstein ? microchip_ michaelni: Von Neumann microchip_ lorentz, poincaré, desitter, de broglie, etc - http://phys.kent.edu/~manley/physicists.html michaelni: Gauss, Galois, Viterbi, Darwin, Feynman (check spelling) RELEASE, VERSION, Doxygen files should contain the correct version make sure qatar is pulled run fate run abi-test delete Changelog, if its outdated make sure you didnt include binaries test make install test on arm, mingw, mips, linux32 gpg sign make sure permissions are ok also gpg permissions upload update IRC topics of all 3 channels if needed update download page check we dont have unmaintained release branches git tags push tags to repo, dont forget github update doxygen links in src/documentation for website update versions on trac tar --exclude-vcs -cvjf ffmpeg-0.7.8.tar.bz2 ffmpeg-0.7. ./configure --cc='ccache gcc' --samples=/home/michael/fatesamples/fate/fate-suite/ make -j12 check make -j12 test ffplay by hand update security page, get CVEs [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpegs future and resigning as leader
On Fri, Jul 31, 2015 at 03:53:04PM +0200, Michael Niedermayer wrote: Hi all Ive been in FFmepg since 14 years and been the leader since 11 years and i feel that iam not the best person for the leader position. I had hoped for a long time that the fork situation would resolve and both sides somehow merging back into one team. All the Libav developers joining FFmpeg again. But even now as the last distributions are preparing to remove Libav, still theres no hint of that happening. Maybe even the opposite. The community is split and its very difficult to be the leader when one is on one side of this split and the other tries everything to push me out I hope my resignation will make it easier for the teams to find back together and avoid a more complete split which would otherwise be the result sooner or later as the trees diverge and merging all improvments becomes too difficult for me to do. also before my resignation, i offer all maintainers who dont yet have, direct write access as i likely will not comb through the ML anymore or not as frequently to apply patches, please send me your public SSH key if you are de facto maintaining or working on some part of FFmpeg or are listed in MAINTAINERs. If people want to continue merges from libav, someone else will have to do these. Indeed i fully admit the work and pressure caused by the merges is a main reason for my resignation. FFmpeg belongs to the FFmpeg developers and the FFmpeg community! If some FFmpeg developers are still willing to do that (that is, maybe partially on their respective maintainership areas), may we ask you to document more your process? If that is possible, maybe not limited to these merges. You have been doing an outstanding work for years, and this includes notably: - development - reviews - patch merges - merge of libav - releases - security fixes - GSoC/OPW/... mentoring - misc logistic - sysadmin So in order for the community to continue this, I'd say we probably need to have some help for: - guidelines on the merge strategies - step-by-step on the release process - some overview on the sysadmin state (like, what happens with the recent server offers?) I know this is asking a lot, but I believe it's important for the future of the project and a good bootstrap to distribute tasks between those willing to, even if it's just temporary. [...] PS: To push a merge, i think this wasnt documented, you need to add a Merged-by: to the commit message, thats the only check, i have no special premissions or anything to push merges. ...typically not just abrupt random hint like this :) [...] PS3: I would suggest a new leader if there was a clear pick, a year or 2 ago i would have suggested stefano or clement but they are not so active currently. Maybe a good candidate will appear in the future or stefano ubitux will become more active again in which case i would suggest one of them as leader if the community wants to have a leader and they agree. Heh, while I appreciate to see myself mentioned here, it is obvious to everyone that this was (and is) not something very realistic. On the other hand, I think this is an extremely great opportunity for the toxicity between the two projects to end, so I'm willing to help the best as I can during the time window that would lead to a viable solution. So far, I can see that things can go either very well, or extremely wrong, depending on various factors. - Libav refuses any cooperation (or some FFmpeg devs disrupt the process) and use this as an opportunity to proclaim more independence, which would lead to indeed a real fork, ending in the death of one or the two projects. This leading to the loss of features/fixes on either one or both sides. - Libav and FFmpeg can come into agreements and maybe join forces, or at least stops the acid burns for the users, leading to less stress for everyone involved. But in any case, this won't be solved today, and at least for the next days, weeks and maybe month, the FFmpeg machine need to continue to work, so we probably need some little help. I just tried to probe for a meeting with Libav developers, and I'd like to hear more about what both sides think of all of this. Thanks to everyone, for everything they did and will do in the future for FFmpeg and the community ! As I said to you already privately, this comes as a surprise, but hey, it's crazy how long you kept up with all of this. I hope you can enjoy some less stressful time disconnected from everything, and thank you very much for everything you've done so far. See you space cowboy. -- Clément B. pgpDa1JxlQYHQ.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpegs future and resigning as leader
On Fri, Jul 31, 2015 at 05:37:12PM +0200, Clément Bœsch wrote: [...] So in order for the community to continue this, I'd say we probably need to have some help for: - guidelines on the merge strategies - step-by-step on the release process - some overview on the sysadmin state (like, what happens with the recent server offers?) i accepted the 2 offers which noone objected against (on the ML), so FFmpeg should get 2 boxes that things can be moved to and which should be dependable it does need volunteers doing the work. Maybe lou, beastd, tim nich, roberto and you would be willing to help move things to them it was discussed to move things into virtual machines (qemu) for higher security, isolation and ease of future moving. moving to the new servers could be done before or after moving to VMs of course or while doing it in the same step [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH dshow more debug timestamp info
On Fri, Jul 31, 2015 at 10:11:29AM -0600, Roger Pack wrote: On 7/30/15, Michael Niedermayer mich...@niedermayer.cc wrote: On Thu, Jul 30, 2015 at 03:56:30PM -0600, Roger Pack wrote: See attached. Possibly useful for debugging async issues that crop up from time to time. Thanks! should i apply this to ffmpeg git ? its not clear to me if this is intended for git or just for others to test/debug ? Yeah apply it, it may be useful for certain debug purposes later. applied please send me your public SSH key! thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpegs future and resigning as leader
On Fri, 31 Jul 2015 15:53:04 +0200 Michael Niedermayer mich...@niedermayer.cc wrote: Hi all oh no glorious leader has resigned. oh well. thanks for putting up with all of that crap, michael. ffmpeg has become one of those projects that is required on all puters now. without your hard work it may have fallen to gstreamer or some other horrible wrapper. ;) i do have one thing to ask of everyone, moving forward, can we please not blame michael for every single thing now? instead of complaining , send patches instead. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On Fri, Jul 31, 2015 at 5:12 PM, compn te...@mi.rr.com wrote: On Thu, 30 Jul 2015 17:05:12 +0200 Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: Hi, On 28.07.2015 15:36, Vittorio Giovara wrote: This set contains the removal of all deprecated features marked as such until 2012/early 2013. This was announced several times in the past months and agreed at several meetings (since fosdem and recently at the sprint). With more than two year span, downstream users should have had enough time to update their API usage (or comment otherwise). Unfortunately this is just wishful thinking. As it is, your proposed removal of deprecated features is going to break about three quarters of all packages using the libav* libraries in Debian: i am against removing this api in ffmpeg, if my vote counts for anything. anyway to keep the old api and have the new api at the same time? yes, this means letting the old api rot, i have no problem with this. just to give time for projects to update. or maybe even create a wrapper ? bah. They have had 2-3 years to update, what makes you think they will ever if we don't force them at some point? Some of the API is known to exhibit failure under some conditions and having it actually confuses new developers as we have duplicate API that behaves differently (and wrongly, even). Removing it not only serves some purpose of cleanlyness as some people like to pretend, but it actually removes a whole bunch of problems which new users of the API commonly run into because they accidentally use the old API (usually because some ancient example they found used it as well). Not having this old and wrong API at all anymore will prevent a lot of these cases and instead help guide the users towards the new and properly-working and tested API. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 8/8] doc/example: Add http multi-client example code
I have no more remarks on the whole series, I believe it can be applied. If your public Git tree is ready for pulls, you can do a final rebase and send a pull request directly. If not, I can do the same with my tree. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] blowfish: add av_blowfish_alloc()
On 31/07/15 3:33 PM, Paul B Mahol wrote: For what is this useful? So these four modules are consistent with the rest of the crypto modules. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] des: add av_des_alloc()
On 7/31/15, James Almer jamr...@gmail.com wrote:
Signed-off-by: James Almer jamr...@gmail.com
---
doc/APIchanges | 1 +
libavutil/des.c | 13 -
libavutil/des.h | 24 ++--
3 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 7d1984f..cce2ddb 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -19,6 +19,7 @@ API changes, most recent first:
xxx - Add av_blowfish_alloc().
xxx - Add av_rc4_alloc().
xxx - Add av_xtea_alloc().
+ xxx - Add av_des_alloc().
2015-xx-xx - lavc 56.35.0 - avcodec.h
x - Rename CODEC_FLAG* defines to AV_CODEC_FLAG*.
diff --git a/libavutil/des.c b/libavutil/des.c
index 57ad0a4..e7e9178 100644
--- a/libavutil/des.c
+++ b/libavutil/des.c
@@ -22,9 +22,15 @@
#include avutil.h
#include common.h
#include intreadwrite.h
+#include mem.h
#include des.h
-typedef struct AVDES AVDES;
+#if !FF_API_CRYPTO_CONTEXT
+struct AVDES {
+uint64_t round_keys[3][16];
+int triple_des;
+};
Here and in others, shouldn't this be:
struct AVDES {
uint64_t round_keys[3][16];
int triple_des;
} AVDES;
?
+#endif
#define T(a, b, c, d, e, f, g, h) 64-a,64-b,64-c,64-d,64-e,64-f,64-g,64-h
static const uint8_t IP_shuffle[] = {
@@ -286,6 +292,11 @@ static uint64_t des_encdec(uint64_t in, uint64_t K[16],
int decrypt) {
return in;
}
+AVDES *av_des_alloc(void)
+{
+return av_mallocz(sizeof(struct AVDES));
+}
+
int av_des_init(AVDES *d, const uint8_t *key, int key_bits, av_unused int
decrypt) {
if (key_bits != 64 key_bits != 192)
return -1;
diff --git a/libavutil/des.h b/libavutil/des.h
index 2feb046..224745e 100644
--- a/libavutil/des.h
+++ b/libavutil/des.h
@@ -24,16 +24,32 @@
#include stdint.h
-struct AVDES {
+/**
+ * @defgroup lavu_des DES
+ * @ingroup lavu_crypto
+ * @{
+ */
+
+#if FF_API_CRYPTO_CONTEXT
+typedef struct AVDES {
uint64_t round_keys[3][16];
int triple_des;
-};
+} AVDES;
+#else
+typedef struct AVDES AVDES;
+#endif
+
+/**
+ * Allocate an AVDES context.
+ */
+AVDES *av_des_alloc(void);
/**
* @brief Initializes an AVDES context.
*
* @param key_bits must be 64 or 192
* @param decrypt 0 for encryption/CBC-MAC, 1 for decryption
+ * @return zero on success, negative value otherwise
*/
int av_des_init(struct AVDES *d, const uint8_t *key, int key_bits, int
decrypt);
@@ -58,4 +74,8 @@ void av_des_crypt(struct AVDES *d, uint8_t *dst, const
uint8_t *src, int count,
*/
void av_des_mac(struct AVDES *d, uint8_t *dst, const uint8_t *src, int
count);
+/**
+ * @}
+ */
+
#endif /* AVUTIL_DES_H */
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] rc4: add av_rc4_alloc()
Signed-off-by: James Almer jamr...@gmail.com
---
doc/APIchanges | 1 +
libavutil/rc4.c | 13 -
libavutil/rc4.h | 25 +++--
3 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index d222fc6..5fcbabb 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -17,6 +17,7 @@ API changes, most recent first:
2015-xx-xx - lavu 54.30.0
xxx - Add av_blowfish_alloc().
+ xxx - Add av_rc4_alloc().
2015-xx-xx - lavc 56.35.0 - avcodec.h
x - Rename CODEC_FLAG* defines to AV_CODEC_FLAG*.
diff --git a/libavutil/rc4.c b/libavutil/rc4.c
index 4e52ba5..e507b4a 100644
--- a/libavutil/rc4.c
+++ b/libavutil/rc4.c
@@ -22,9 +22,20 @@
*/
#include avutil.h
#include common.h
+#include mem.h
#include rc4.h
-typedef struct AVRC4 AVRC4;
+#if !FF_API_CRYPTO_CONTEXT
+struct AVRC4 {
+uint8_t state[256];
+int x, y;
+};
+#endif
+
+AVRC4 *av_rc4_alloc(void)
+{
+return av_mallocz(sizeof(struct AVRC4));
+}
int av_rc4_init(AVRC4 *r, const uint8_t *key, int key_bits, int decrypt) {
int i, j;
diff --git a/libavutil/rc4.h b/libavutil/rc4.h
index 9362fd8..47c9793 100644
--- a/libavutil/rc4.h
+++ b/libavutil/rc4.h
@@ -22,17 +22,34 @@
#define AVUTIL_RC4_H
#include stdint.h
+#include version.h
-struct AVRC4 {
+/**
+ * @defgroup lavu_rc4 RC4
+ * @ingroup lavu_crypto
+ * @{
+ */
+
+#if FF_API_CRYPTO_CONTEXT
+typedef struct AVRC4 {
uint8_t state[256];
int x, y;
-};
+} AVRC4;
+#else
+typedef struct AVRC4 AVRC4;
+#endif
+
+/**
+ * Allocate an AVRC4 context.
+ */
+AVRC4 *av_rc4_alloc(void);
/**
* @brief Initializes an AVRC4 context.
*
* @param key_bits must be a multiple of 8
* @param decrypt 0 for encryption, 1 for decryption, currently has no effect
+ * @return zero on success, negative value otherwise
*/
int av_rc4_init(struct AVRC4 *d, const uint8_t *key, int key_bits, int
decrypt);
@@ -47,4 +64,8 @@ int av_rc4_init(struct AVRC4 *d, const uint8_t *key, int
key_bits, int decrypt);
*/
void av_rc4_crypt(struct AVRC4 *d, uint8_t *dst, const uint8_t *src, int
count, uint8_t *iv, int decrypt);
+/**
+ * @}
+ */
+
#endif /* AVUTIL_RC4_H */
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] des: add av_des_alloc()
Signed-off-by: James Almer jamr...@gmail.com
---
doc/APIchanges | 1 +
libavutil/des.c | 13 -
libavutil/des.h | 24 ++--
3 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 7d1984f..cce2ddb 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -19,6 +19,7 @@ API changes, most recent first:
xxx - Add av_blowfish_alloc().
xxx - Add av_rc4_alloc().
xxx - Add av_xtea_alloc().
+ xxx - Add av_des_alloc().
2015-xx-xx - lavc 56.35.0 - avcodec.h
x - Rename CODEC_FLAG* defines to AV_CODEC_FLAG*.
diff --git a/libavutil/des.c b/libavutil/des.c
index 57ad0a4..e7e9178 100644
--- a/libavutil/des.c
+++ b/libavutil/des.c
@@ -22,9 +22,15 @@
#include avutil.h
#include common.h
#include intreadwrite.h
+#include mem.h
#include des.h
-typedef struct AVDES AVDES;
+#if !FF_API_CRYPTO_CONTEXT
+struct AVDES {
+uint64_t round_keys[3][16];
+int triple_des;
+};
+#endif
#define T(a, b, c, d, e, f, g, h) 64-a,64-b,64-c,64-d,64-e,64-f,64-g,64-h
static const uint8_t IP_shuffle[] = {
@@ -286,6 +292,11 @@ static uint64_t des_encdec(uint64_t in, uint64_t K[16],
int decrypt) {
return in;
}
+AVDES *av_des_alloc(void)
+{
+return av_mallocz(sizeof(struct AVDES));
+}
+
int av_des_init(AVDES *d, const uint8_t *key, int key_bits, av_unused int
decrypt) {
if (key_bits != 64 key_bits != 192)
return -1;
diff --git a/libavutil/des.h b/libavutil/des.h
index 2feb046..224745e 100644
--- a/libavutil/des.h
+++ b/libavutil/des.h
@@ -24,16 +24,32 @@
#include stdint.h
-struct AVDES {
+/**
+ * @defgroup lavu_des DES
+ * @ingroup lavu_crypto
+ * @{
+ */
+
+#if FF_API_CRYPTO_CONTEXT
+typedef struct AVDES {
uint64_t round_keys[3][16];
int triple_des;
-};
+} AVDES;
+#else
+typedef struct AVDES AVDES;
+#endif
+
+/**
+ * Allocate an AVDES context.
+ */
+AVDES *av_des_alloc(void);
/**
* @brief Initializes an AVDES context.
*
* @param key_bits must be 64 or 192
* @param decrypt 0 for encryption/CBC-MAC, 1 for decryption
+ * @return zero on success, negative value otherwise
*/
int av_des_init(struct AVDES *d, const uint8_t *key, int key_bits, int
decrypt);
@@ -58,4 +74,8 @@ void av_des_crypt(struct AVDES *d, uint8_t *dst, const
uint8_t *src, int count,
*/
void av_des_mac(struct AVDES *d, uint8_t *dst, const uint8_t *src, int count);
+/**
+ * @}
+ */
+
#endif /* AVUTIL_DES_H */
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpegs future and resigning as leader
On Fri, 31 Jul 2015 15:53:04 +0200 Michael Niedermayer mich...@niedermayer.cc wrote: Hi all Ive been in FFmepg since 14 years and been the leader since 11 years and i feel that iam not the best person for the leader position. I had hoped for a long time that the fork situation would resolve and both sides somehow merging back into one team. All the Libav developers joining FFmpeg again. But even now as the last distributions are preparing to remove Libav, still theres no hint of that happening. Maybe even the opposite. The community is split and its very difficult to be the leader when one is on one side of this split and the other tries everything to push me out I hope my resignation will make it easier for the teams to find back together and avoid a more complete split which would otherwise be the result sooner or later as the trees diverge and merging all improvments becomes too difficult for me to do. also before my resignation, i offer all maintainers who dont yet have, direct write access as i likely will not comb through the ML anymore or not as frequently to apply patches, please send me your public SSH key if you are de facto maintaining or working on some part of FFmpeg or are listed in MAINTAINERs. If people want to continue merges from libav, someone else will have to do these. Indeed i fully admit the work and pressure caused by the merges is a main reason for my resignation. FFmpeg belongs to the FFmpeg developers and the FFmpeg community! will i ever return ? ... i might ..., if theres a nice and friendly environment, no hostile forks or at least none i have to interact with. But i will certainly not return as leader, this is not really a role i ever truly liked, more one i ended up with. Especially as somehow leader is being interpreted by everyone as the guy who does all work noone else does, and takes all responsibility noone else wants to take am i still available for consulting jobs releated to FFmpeg? yes, of course i cant gurantee it for the very distant future but currently yes. And in the very distant future, its a maybe, so just ask if theres something ... what about root, git admin roles, ...? Well iam happy to pass them on to whoever the community chooses and trusts. But please be very carefull who you choose! until someone else is choosen i can continue doing the basic things like security updates and opening git accounts, aka theres no urgency in choosing someone, rather please choose wise than quick. what about GSoC? I agreed to mentor and admin that and i will of course finish that for this summer. I may or may not be available in future FFmpeg GSoCs. If you now think ohh god what should i do, michael resigned very simple, FFmpeg is yours, that is everyones. try your best to make FFmpeg be the best. Post patches, review patches, apply patches, discuss code and design. Report bugs, bisect, debug and fix bugs, add features, help users. Do friendly merges, and if you like do hostile merges. Its all up to you now! PS: To push a merge, i think this wasnt documented, you need to add a Merged-by: to the commit message, thats the only check, i have no special premissions or anything to push merges. PS2: Be carefull about who will be in charge of key infrastructure! and also where power moves when thouse in charge then resign. PS3: I would suggest a new leader if there was a clear pick, a year or 2 ago i would have suggested stefano or clement but they are not so active currently. Maybe a good candidate will appear in the future or stefano ubitux will become more active again in which case i would suggest one of them as leader if the community wants to have a leader and they agree. Thanks to everyone, for everything they did and will do in the future for FFmpeg and the community ! I didn't always agree with your way of maintaining FFmpeg, but the work you did was impressive. I also hope that this will eventually lead to FFmpeg and Libav being one project again. And I hope that this is not the end of you as FFmpeg contributor. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] New Server
Hi All, We're the proposer of the OVH option. Of course the project people should select the best options but for me is difficult to argue that the option we propose is not one of the best. Our offer is a 2 years prepaid high end server under the administrative and tech management of the ffmpeg community (the contact for the server will be person you decide, with no relation with our company except 3.000 euros prepaid transfer we'll do). The server would be hosted in a top 5 provider in europe (may be top 1/2 for dedicated servers, nº 3 hosting provider in the world according netcraft in Jan 2014, 700.000 customers today) with 100% uptime for their site since two years (0 outages since April 2013). For us is difficult to understand it's discarded based on some not-so-conclusive test (also not applied over the other options in the same way). In any case, our offer is still alive next week if you think it twice. Best regards, AG. Antonio Guillermo Martínez Largo Libnova, SL Paseo de la Castellana, 153 - Madrid [t] +34 91 449 08 94 [f] +34 91 141 21 21 www.libnova.es -Mensaje original- De: Michael Niedermayer [mailto:mich...@niedermayer.cc] Enviado el: viernes, 31 de julio de 2015 17:35 Para: FFmpeg development discussions and patches; mplayer-dev-...@mplayerhq.hu; rtmpd...@mplayerhq.hu; dvdnav-disc...@mplayerhq.hu CC: Antonio Guillermo Martínez (libnova); Joshua Ward; Nikolay Aleksandrov; Markus Viitamäki Asunto: Re: [FFmpeg-devel] New Server On Fri, Jul 24, 2015 at 07:06:02PM +0200, Michael Niedermayer wrote: Hi all as you all probably know FFmpeg/Mplayer/... is searching for a new free server hosting ... We received the following offers for a new server and hosting. If you think any of them are a bad choice then please speak now! i ommited one non free offer and one unspecific offer from a company who alternatively would want to finnancially sponsor us. as well as at least one which would be technically insufficient If i forgot some offer or theres a mistake in the list below please reply and add/correct the offer ASAP! I also intend to add a mention link to the footer of the FFmpeg webpage for whoever is choosen, several of the sponsors below did not ask for that though. If you object to that, again, please speak now. I intend to accept 2 of the offers below for redundancy, again if you think something else should be done, speak now! I almost forgot replying. And i guess if i dont reply noone will feel authorative and reply anytime soon ... there are only 2 options noone had a argument against. OVH and vlc had arguments in public, hetzner (virus issue 50euro/mo, also public) kierans box is too weak/old to host all our services but works fine for trac atm against nexcess / futurehosting.com i receved a private argument from a rtmpdump developer, as they are US based and hosting rtmpdump in the US is expected by them to be problematic. That leaves DreamHack and the Telepoint/MediaHub offer. I thus accept these 2 offers Thanks alot ! [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] xtea: add av_xtea_alloc()
Signed-off-by: James Almer jamr...@gmail.com
---
doc/APIchanges | 1 +
libavutil/xtea.c | 12
libavutil/xtea.h | 10 ++
3 files changed, 23 insertions(+)
diff --git a/doc/APIchanges b/doc/APIchanges
index 5fcbabb..7d1984f 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -18,6 +18,7 @@ API changes, most recent first:
2015-xx-xx - lavu 54.30.0
xxx - Add av_blowfish_alloc().
xxx - Add av_rc4_alloc().
+ xxx - Add av_xtea_alloc().
2015-xx-xx - lavc 56.35.0 - avcodec.h
x - Rename CODEC_FLAG* defines to AV_CODEC_FLAG*.
diff --git a/libavutil/xtea.c b/libavutil/xtea.c
index 1750cbc..b95f322 100644
--- a/libavutil/xtea.c
+++ b/libavutil/xtea.c
@@ -31,8 +31,20 @@
#include avutil.h
#include common.h
#include intreadwrite.h
+#include mem.h
#include xtea.h
+#if !FF_API_CRYPTO_CONTEXT
+struct AVXTEA {
+uint32_t key[16];
+};
+#endif
+
+AVXTEA *av_xtea_alloc(void)
+{
+return av_mallocz(sizeof(struct AVXTEA));
+}
+
void av_xtea_init(AVXTEA *ctx, const uint8_t key[16])
{
int i;
diff --git a/libavutil/xtea.h b/libavutil/xtea.h
index 6f1e71e..4281fd8 100644
--- a/libavutil/xtea.h
+++ b/libavutil/xtea.h
@@ -23,6 +23,7 @@
#define AVUTIL_XTEA_H
#include stdint.h
+#include version.h
/**
* @file
@@ -32,9 +33,18 @@
* @{
*/
+#if FF_API_CRYPTO_CONTEXT
typedef struct AVXTEA {
uint32_t key[16];
} AVXTEA;
+#else
+typedef struct AVXTEA AVXTEA;
+#endif
+
+/**
+ * Allocate an AVXTEA context.
+ */
+AVXTEA *av_xtea_alloc(void);
/**
* Initialize an AVXTEA context.
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] blowfish: add av_blowfish_alloc()
Signed-off-by: James Almer jamr...@gmail.com
---
doc/APIchanges | 3 +++
libavutil/blowfish.c | 15 +++
libavutil/blowfish.h | 10 ++
libavutil/version.h | 5 -
4 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 29e9da9..d222fc6 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2014-08-09
API changes, most recent first:
+2015-xx-xx - lavu 54.30.0
+ xxx - Add av_blowfish_alloc().
+
2015-xx-xx - lavc 56.35.0 - avcodec.h
x - Rename CODEC_FLAG* defines to AV_CODEC_FLAG*.
x - Rename CODEC_CAP_* defines to AV_CODEC_CAP_*.
diff --git a/libavutil/blowfish.c b/libavutil/blowfish.c
index 3821427..4f7e4df 100644
--- a/libavutil/blowfish.c
+++ b/libavutil/blowfish.c
@@ -24,8 +24,18 @@
#include avutil.h
#include common.h
#include intreadwrite.h
+#include mem.h
#include blowfish.h
+#if !FF_API_CRYPTO_CONTEXT
+#define AV_BF_ROUNDS 16
+
+struct AVBlowfish {
+uint32_t p[AV_BF_ROUNDS + 2];
+uint32_t s[4][256];
+};
+#endif
+
static const uint32_t orig_p[AV_BF_ROUNDS + 2] = {
0x243F6A88, 0x85A308D3, 0x13198A2E, 0x03707344,
0xA4093822, 0x299F31D0, 0x082EFA98, 0xEC4E6C89,
@@ -300,6 +310,11 @@ static const uint32_t orig_s[4][256] = {
+ ctx-s[3][ Xl 0xFF])\
^ P;
+AVBlowfish *av_blowfish_alloc(void)
+{
+return av_mallocz(sizeof(struct AVBlowfish));
+}
+
av_cold void av_blowfish_init(AVBlowfish *ctx, const uint8_t *key, int key_len)
{
uint32_t data, data_l, data_r;
diff --git a/libavutil/blowfish.h b/libavutil/blowfish.h
index 0b00453..d163fd3 100644
--- a/libavutil/blowfish.h
+++ b/libavutil/blowfish.h
@@ -23,6 +23,7 @@
#define AVUTIL_BLOWFISH_H
#include stdint.h
+#include version.h
/**
* @defgroup lavu_blowfish Blowfish
@@ -30,12 +31,21 @@
* @{
*/
+#if FF_API_CRYPTO_CONTEXT
#define AV_BF_ROUNDS 16
typedef struct AVBlowfish {
uint32_t p[AV_BF_ROUNDS + 2];
uint32_t s[4][256];
} AVBlowfish;
+#else
+typedef struct AVBlowfish AVBlowfish;
+#endif
+
+/**
+ * Allocate an AVBlowfish context.
+ */
+AVBlowfish *av_blowfish_alloc(void);
/**
* Initialize an AVBlowfish context.
diff --git a/libavutil/version.h b/libavutil/version.h
index b10f3e1..653f530 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -56,7 +56,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 54
-#define LIBAVUTIL_VERSION_MINOR 29
+#define LIBAVUTIL_VERSION_MINOR 30
#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
@@ -125,6 +125,9 @@
#ifndef FF_API_HMAC
#define FF_API_HMAC (LIBAVUTIL_VERSION_MAJOR 55)
#endif
+#ifndef FF_API_CRYPTO_CONTEXT
+#define FF_API_CRYPTO_CONTEXT (LIBAVUTIL_VERSION_MAJOR 56)
+#endif
#ifndef FF_CONST_AVUTIL55
#if LIBAVUTIL_VERSION_MAJOR = 55
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] des: add av_des_alloc()
On 31/07/15 3:42 PM, Paul B Mahol wrote:
On 7/31/15, James Almer jamr...@gmail.com wrote:
Signed-off-by: James Almer jamr...@gmail.com
---
doc/APIchanges | 1 +
libavutil/des.c | 13 -
libavutil/des.h | 24 ++--
3 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 7d1984f..cce2ddb 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -19,6 +19,7 @@ API changes, most recent first:
xxx - Add av_blowfish_alloc().
xxx - Add av_rc4_alloc().
xxx - Add av_xtea_alloc().
+ xxx - Add av_des_alloc().
2015-xx-xx - lavc 56.35.0 - avcodec.h
x - Rename CODEC_FLAG* defines to AV_CODEC_FLAG*.
diff --git a/libavutil/des.c b/libavutil/des.c
index 57ad0a4..e7e9178 100644
--- a/libavutil/des.c
+++ b/libavutil/des.c
@@ -22,9 +22,15 @@
#include avutil.h
#include common.h
#include intreadwrite.h
+#include mem.h
#include des.h
-typedef struct AVDES AVDES;
+#if !FF_API_CRYPTO_CONTEXT
+struct AVDES {
+uint64_t round_keys[3][16];
+int triple_des;
+};
Here and in others, shouldn't this be:
struct AVDES {
uint64_t round_keys[3][16];
int triple_des;
} AVDES;
?
No, the struct is typedeffed in the header now.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add new Videotoolbox hwaccel.
On Thu, Jul 30, 2015 at 05:12:21PM +0800, Zhang Rui wrote: [...] BTW: I think current patch is OK enough. I will push it soon (unless Sebastien has write access?) Async-mode could be an experimental option. Sebastien, do you plan to work on this? I quickly tried to add the async flag as decoding but as expected it's not enought to make it work. I suppose we need a queue or something. -- Clément B. pgp3J5Wo2tyaL.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpegs future and resigning as leader
On Fri, Jul 31, 2015 at 09:27:00PM +0200, Michael Niedermayer wrote: On Fri, Jul 31, 2015 at 05:37:12PM +0200, Clément Bœsch wrote: [...] So in order for the community to continue this, I'd say we probably need to have some help for: - guidelines on the merge strategies The merge process i used is quite simple one trick i forgot as it happens with multi user git when doing a merge someone else occasionally pushes something before one can push the finished merge to update/rebase a local merge onto some updated origin the attached script works most of the time. note, this works only with a single commit/merge locally if you have multiple merges which arent pushed it wont work also the result should be looked at quickly before pushing [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus #!/bin/bash set -e # set -v # set -x git diff HEAD | grep . exit 1 || true git show | grep '^Merge: [a-f0-9][a-f0-9]* [a-f0-9][a-f0-9]*$' /dev/null #TOMERGE=`git show | grep 'Merge commit' | sed 's/.*'\''\(.*\)'\''/\1/'` TOMERGE=`git show | grep '^Merge:' | sed 's/Merge: [a-f0-9][a-f0-9]* \(.*\)/\1/'` OLDCOMMIT=`git show | grep '^commit ' | sed 's/commit//'` git diff HEAD^ mergerebase.tmp git reset --hard HEAD^ git pull --rebase git merge --stat --no-commit --log $TOMERGE -Xrename-threshold=10 -Xpatience | sort git diff HEAD | patch -p1 -R patch -p1 mergerebase.tmp git commit -a -C $OLDCOMMIT signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpegs future and resigning as leader
On Fri, Jul 31, 2015 at 09:54:52PM +0200, Michael Niedermayer wrote: On Fri, Jul 31, 2015 at 09:27:00PM +0200, Michael Niedermayer wrote: On Fri, Jul 31, 2015 at 05:37:12PM +0200, Clément Bœsch wrote: [...] So in order for the community to continue this, I'd say we probably need to have some help for: - guidelines on the merge strategies The merge process i used is quite simple one trick i forgot another thing that comes to mind when merges are done 1 commit at a time bisect works fine if merging more commits in a single merge then bisect will end on the libav tree and whatever test one has will generally not work on libav in a meaningfull way. So using only 1 commit per merge helps with future bisectability alot. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- 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 1/4] blowfish: add av_blowfish_alloc()
On Fri, Jul 31, 2015 at 02:18:07PM -0300, James Almer wrote:
Signed-off-by: James Almer jamr...@gmail.com
---
doc/APIchanges | 3 +++
libavutil/blowfish.c | 15 +++
libavutil/blowfish.h | 10 ++
libavutil/version.h | 5 -
4 files changed, 32 insertions(+), 1 deletion(-)
[...]
@@ -30,12 +31,21 @@
* @{
*/
+#if FF_API_CRYPTO_CONTEXT
#define AV_BF_ROUNDS 16
typedef struct AVBlowfish {
uint32_t p[AV_BF_ROUNDS + 2];
uint32_t s[4][256];
} AVBlowfish;
+#else
+typedef struct AVBlowfish AVBlowfish;
+#endif
Is it intended to remove all means to allocate the context on the
stack ?
this would avoid dealing with malloc/free and malloc failure handling
and could be a signifiant advantage also if any usecase is in a API
that lacks the possibility to fail, like maybe some crypto callbacks
with void return
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add atadenoise
---
doc/filters.texi| 38
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vf_atadenoise.c | 421
4 files changed, 461 insertions(+)
create mode 100755 libavfilter/vf_atadenoise.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 4c4beea..af8e895 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2967,6 +2967,44 @@ Slower shaper using OpenType for substitutions and
positioning
The default is @code{auto}.
@end table
+@section atadenoise
+Apply an Adaptive Temporal Averaging Denoiser to the video input.
+
+The filter accepts the following options:
+
+@table @option
+@item 0a
+Set threshold A for 1st plane. Default is 0.02.
+Valid range is 0 to 0.3.
+
+@item 0b
+Set threshold B for 1st plane. Default is 0.04.
+Valid range is 0 to 0.5.
+
+@item 1a
+Set threshold A for 2nd plane. Default is 0.02.
+Valid range is 0 to 0.3.
+
+@item 1b
+Set threshold B for 2nd plane. Default is 0.04.
+Valid range is 0 to 0.5.
+
+@item 2a
+Set threshold A for 3rd plane. Default is 0.02.
+Valid range is 0 to 0.3.
+
+@item 2b
+Set threshold B for 3rd plane. Default is 0.04.
+Valid range is 0 to 0.5.
+
+Threshold A is designed to react on abrupt changes in the input signal and
+threshold B is designed to react on continuous changes in the input signal.
+
+@item s
+Set number of frames filter will use for averaging. Default is 33. Must be odd
+number in range [5, 129].
+@end table
+
@section bbox
Compute the bounding box for the non-black pixels in the input frame
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 5d03e86..f1a88d3 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -98,6 +98,7 @@ OBJS-$(CONFIG_ANULLSINK_FILTER) +=
asink_anullsink.o
OBJS-$(CONFIG_ASS_FILTER)+= vf_subtitles.o
OBJS-$(CONFIG_ALPHAEXTRACT_FILTER) += vf_extractplanes.o
OBJS-$(CONFIG_ALPHAMERGE_FILTER) += vf_alphamerge.o
+OBJS-$(CONFIG_ATADENOISE_FILTER) += vf_atadenoise.o
OBJS-$(CONFIG_BBOX_FILTER) += bbox.o vf_bbox.o
OBJS-$(CONFIG_BLACKDETECT_FILTER)+= vf_blackdetect.o
OBJS-$(CONFIG_BLACKFRAME_FILTER) += vf_blackframe.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index ceac705..750ba55 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -113,6 +113,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(ALPHAEXTRACT, alphaextract, vf);
REGISTER_FILTER(ALPHAMERGE, alphamerge, vf);
+REGISTER_FILTER(ATADENOISE, atadenoise, vf);
REGISTER_FILTER(ASS,ass,vf);
REGISTER_FILTER(BBOX, bbox, vf);
REGISTER_FILTER(BLACKDETECT,blackdetect,vf);
diff --git a/libavfilter/vf_atadenoise.c b/libavfilter/vf_atadenoise.c
new file mode 100755
index 000..6ab82c7
--- /dev/null
+++ b/libavfilter/vf_atadenoise.c
@@ -0,0 +1,421 @@
+/*
+ * Copyright (c) 2015 Paul B Mahol
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * Adaptive Temporal Averaging Denoiser,
+ * based on paper Video Denoising Based on Adaptive Temporal Averaging by
+ * David Bartovčak and Miroslav Vrankić
+ */
+
+#include libavutil/opt.h
+#include libavutil/pixdesc.h
+#include avfilter.h
+
+#define FF_BUFQUEUE_SIZE 129
+#include bufferqueue.h
+
+#include formats.h
+#include internal.h
+#include video.h
+
+#define SIZE FF_BUFQUEUE_SIZE
+
+typedef struct ATADenoiseContext {
+const AVClass *class;
+
+float fthra[4], fthrb[4];
+int thra[4], thrb[4];
+
+int nb_planes;
+int planewidth[4];
+int planeheight[4];
+
+struct FFBufQueue q;
+void *data[4][SIZE];
+int linesize[4][SIZE];
+int size, mid;
+int available;
+
+int (*filter_slice)(AVFilterContext *ctx, void *arg, int jobnr, int
nb_jobs);
+} ATADenoiseContext;
+
+#define OFFSET(x) offsetof(ATADenoiseContext, x)
+#define FLAGS AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption atadenoise_options[] = {
+{ 0a, set threshold A for 1st plane, OFFSET(fthra[0]),
AV_OPT_TYPE_FLOAT, {.dbl=0.02}, 0, 0.3, FLAGS },
+{ 0b, set threshold B for 1st plane,
Re: [FFmpeg-devel] FFmpegs future and resigning as leader
On Fri, Jul 31, 2015 at 05:37:12PM +0200, Clément Bœsch wrote:
[...]
So in order for the community to continue this, I'd say we probably need
to have some help for:
- guidelines on the merge strategies
The merge process i used is quite simple
1.
merge.conflictstyle=diff3 (in git config somewhere)
2.
git fetch --all
3.
git log ..qatar/master--pretty='%H %s'
4. pick one hash at a time into (start with the oldest)
git merge --stat --log hash here -Xrename-threshold=10 -Xpatience | sort
then open files in text editor and edit code in conflict markers to
simplify. Also simple search and replace is very usefull like if a
variable rename is merged, do a merge + do the rename over the conflict
markered code
if needed you can copy and paste a conflict block into the murge script
which will show it in a nicer colored form
then run the spitfire script as often as you want during the process
(no arguments required)
it will fix up license headers, and simplify all conflicts which have
after any renaming or editing become trivial. So doing a merge of a
rename initially might result in hundreads of conflicts and after
redoing the rename and spitfire you then possibly have only 10 or
so left to resolve by hand.
There are hundreads of other tools out there to resolve merge
conflicts, above is just what i used for 99% of my merges
ahh and sedf, which runs a sed command over the files specified after
it,
all very basic scripts really, no magic
ahh and to add fate samples, you need to be in the samples group
on the server you are one of the roots so that should be fine
and then to update fate samples drop em locally in your directory
and use a script like this:
rsync -vauL --chmod=Dg+s,Duo+x,ug+rw,o+r,o-w,+X
ffmpeg.org:/home/samples/fate-suite/ ~/fatesamples/fate/fate-suite
rsync -vauL --chmod=Dg+s,Duo+x,ug+rw,o+r,o-w,+X
f...@fate.ffmpeg.org:/var/www/fateweb/fate-suite/ ~/fatesamples/fate/fate-suite
echo dry runs next
rsync -vanL --no-g --chmod=Dg+s,Duo+x,ug+rw,o+r,o-w,+X
~/fatesamples/fate/fate-suite/ f...@fate.ffmpeg.org:/var/www/fateweb/fate-suite
rsync -vanL --no-g --chmod=Dg+s,Duo+x,ug+rw,o+r,o-w,+X
~/fatesamples/fate/fate-suite/ ffmpeg.org:/home/samples/fate-suite
echo NEXT will be upload check the 2 above!
rsync -vaL --no-g --chmod=Dg+s,Duo+x,ug+rw,o+r,o-w,+X
~/fatesamples/fate/fate-suite/ f...@fate.ffmpeg.org:/var/www/fateweb/fate-suite
rsync -vaL --no-g --chmod=Dg+s,Duo+x,ug+rw,o+r,o-w,+X
~/fatesamples/fate/fate-suite/ ffmpeg.org:/home/samples/fate-suite
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
#!/bin/sh
grep -A9 '' | grep -B9 '' murge.X
grep -A '' murge.X | egrep -v '===|||\|\|\|\|\|\|\|'
murge.theirs
grep -B '' murge.X | egrep -v '===|||\|\|\|\|\|\|\|'
murge.ours
grep -B '' murge.X | grep -A '' | egrep -v
'===|||\|\|\|\|\|\|\|' murge.common
colordiff -du $* murge.ours murge.theirs
grep . murge.common /dev/null colordiff -du $* murge.common murge.theirs
grep . murge.common /dev/null colordiff -du $* murge.common murge.ours
rm murge.theirs murge.common murge.ours murge.X
#!/usr/bin/python
import sys
import os
import stat
import re
import subprocess;
def cleanhunk(out, ours, old, theirs, func):
global taken_ours, taken_theirs
if func :
ours = func(ours)
old = func(old)
if ours == theirs or theirs == old:
out.write(ours)
taken_ours += 1
return 1
elif ours == old :
out.write(theirs)
taken_theirs += 1
return 2
else :
return 0
def docosmetics( s ):
sys.stderr.write( before: \n + s + \n )
#we ommit * due to pointer definitions like (MpegEncContext *s
s = re.sub(([])0-9a-zA-Z]) ?( *)(=|\+=|-=|%=|/=|\+|-|||=|=|==|!=||/|%) ?( *)([(0-9a-zA-Z]), \\g1 \\g2\\g3\\g4 \\g5, s);
s = re.sub(([])0-9a-zA-Z]) ?( *)(=)\n, \\g1 \\g2\\g3\n, s);
s = re.sub(//([A-Za-z0-9]), // \\g1, s);
s = re.sub(\){, ) {, s);
s = re.sub((if|while|for)\(, \\g1 (, s);
s = re.sub(}else, } else, s);
s = re.sub(else{, else {, s);
#HACK repair #includes
s = re.sub((#include.*) / (.*), \\g1/\\g2, s);
s = re.sub((#include.*) / (.*), \\g1/\\g2, s);
#HACK repair a@b
s = re.sub( ([0-9a-zA-Z]*@), \\g1, s);
sys.stderr.write( after: \n + s + \n )
return s
def cleanfile( filename, fix_libav ):
global taken_ours, taken_theirs
taken_ours = taken_theirs = taken_conflict = taken_trick = 0
fffix = 0
state = 0
ours = theirs = old =
sys.stderr.write( filename + \n )
infile = open(filename)
outfile= open(spitfire.tmp, wb)
instring = infile.read()
infile.close()
if fix_libav:
m = re.subn(This file is part of Libav, This file is part of FFmpeg, instring)
fffix += m[1]
m = re.subn(Libav is free software; you can
[FFmpeg-devel] [PATCH] libavformat/matroskadec.c: Parse stream durations set by mkvmerge and populate them in AVStream.
Signed-off-by: Sasi Inguva is...@google.com
---
libavformat/matroskadec.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 1807cae..03b564e 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -41,6 +41,7 @@
#include libavutil/lzo.h
#include libavutil/mathematics.h
#include libavutil/opt.h
+#include libavutil/parseutils.h
#include libavutil/time_internal.h
#include libavcodec/bytestream.h
@@ -1418,10 +1419,25 @@ static void matroska_convert_tags(AVFormatContext *s)
chapter[j].chapter-metadata, NULL);
} else if (tags[i].target.trackuid) {
MatroskaTrack *track = matroska-tracks.elem;
-for (j = 0; j matroska-tracks.nb_elem; j++)
-if (track[j].uid == tags[i].target.trackuid track[j].stream)
+for (j = 0; j matroska-tracks.nb_elem; j++) {
+if (track[j].uid == tags[i].target.trackuid
track[j].stream) {
+MatroskaTag *track_tags = tags[i].tag.elem;
+int64_t track_duration_ms;
+for (int ind = 0; ind tags[i].tag.nb_elem; ++ind) {
+if (track_tags[ind].name
+!av_strcasecmp(track_tags[ind].name, duration)
+track_tags[ind].string
+(av_parse_time(track_duration_ms,
track_tags[ind].string, 1) == 0)) {
+track[j].stream-duration =
av_rescale_q(track_duration_ms,
+
(AVRational){ 1, 100 },
+
track[j].stream-time_base);
+}
+}
+
matroska_convert_tag(s, tags[i].tag,
track[j].stream-metadata, NULL);
+}
+}
} else {
matroska_convert_tag(s, tags[i].tag, s-metadata,
tags[i].target.type);
--
2.5.0.rc2.392.g76e840b
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpegs future and resigning as leader
On 31 Jul, wm4 wrote : Thanks to everyone, for everything they did and will do in the future for FFmpeg and the community ! I didn't always agree with your way of maintaining FFmpeg, but the work you did was impressive. I also hope that this will eventually lead to FFmpeg and Libav being one project again. And I hope that this is not the end of you as FFmpeg contributor. I hate to agree with my archenemy, who is working for the competition (j/k), but a big +1 from me. Thanks a lot. -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On Fri, Jul 31, 2015 at 5:47 PM, Nicolas George geo...@nsup.org wrote: Le tridi 13 thermidor, an CCXXIII, Hendrik Leppkes a écrit : They have had 2-3 years to update, what makes you think they will ever if we don't force them at some point? What makes you think they will ever do it even if we try to force them? They will just stick to an older version of FFmpeg, and that would be worse for everyone else. Well, not all would do that, but some of them, too many, would. Removing it not only serves some purpose of cleanlyness as some people like to pretend, but it actually removes a whole bunch of problems which new users of the API commonly run into because they accidentally use the old API (usually because some ancient example they found used it as well). Not having this old and wrong API at all anymore will prevent a lot of these cases and instead help guide the users towards the new and properly-working and tested API. I can propose the following middle term: - Making the old features disabled by default but very easy to enable if you know how. A single #include libavutil/depcrecated_api.h, for example, or a header that needs to be replaced by another manually at install time (packagers can use a diversion mechanism to create a ffmpeg-deprecated-dev package). - The features stay there but are utterly unsupported. If there is a bug, do not fix it. If there is a security issue, a build failure or anything of the kind, or if it makes it harder to add new features, remove anything in the way. If it breaks third party projects, not our problem. The second point is nice, because it is the least effort policy: we do not make effort to support the deprecated APIs, but we do not make effort to remove them either. Your second point is the one thing I really would hate to see, which was also one of my arguments for removing deprecated API in the first place. What will happen is that distributions will enable it (because obscure-app-37 needs it), people will develop new apps on those distributions, and accidentally use this old broken API in their new code, because they are just following some ancient example code they found on the interwebs somewhere. On top of that, having code with known problems, even worse, security problems, is just a Bad Idea. If we offer an API, it should at least be somewhat supported, even if not tested every day due to being deprecated. If we don't want to support it anymore, and would even be willing to let it break and have security issues, we should just kill it entirely. No-one is going to be helped by a broken insecure obsolete API. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] blowfish: add av_blowfish_alloc()
On 31/07/15 5:40 PM, Michael Niedermayer wrote:
On Fri, Jul 31, 2015 at 02:18:07PM -0300, James Almer wrote:
Signed-off-by: James Almer jamr...@gmail.com
---
doc/APIchanges | 3 +++
libavutil/blowfish.c | 15 +++
libavutil/blowfish.h | 10 ++
libavutil/version.h | 5 -
4 files changed, 32 insertions(+), 1 deletion(-)
[...]
@@ -30,12 +31,21 @@
* @{
*/
+#if FF_API_CRYPTO_CONTEXT
#define AV_BF_ROUNDS 16
typedef struct AVBlowfish {
uint32_t p[AV_BF_ROUNDS + 2];
uint32_t s[4][256];
} AVBlowfish;
+#else
+typedef struct AVBlowfish AVBlowfish;
+#endif
Is it intended to remove all means to allocate the context on the
stack ?
this would avoid dealing with malloc/free and malloc failure handling
and could be a signifiant advantage also if any usecase is in a API
that lacks the possibility to fail, like maybe some crypto callbacks
with void return
I have no preferences regarding the context, really, I'm just trying to get the
API for all the modules consistent. Not sure what would be the use of an alloc
function if the context is not opaque, though.
And you're right, rtmp for example needs some considerable changes to actually
use the alloc functions.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/matroskadec.c: Parse stream durations set by mkvmerge and populate them in AVStream.
On Fri, 31 Jul 2015 13:00:02 -0700
Sasi Inguva is...@google.com wrote:
Signed-off-by: Sasi Inguva is...@google.com
---
libavformat/matroskadec.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 1807cae..03b564e 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -41,6 +41,7 @@
#include libavutil/lzo.h
#include libavutil/mathematics.h
#include libavutil/opt.h
+#include libavutil/parseutils.h
#include libavutil/time_internal.h
#include libavcodec/bytestream.h
@@ -1418,10 +1419,25 @@ static void matroska_convert_tags(AVFormatContext *s)
chapter[j].chapter-metadata,
NULL);
} else if (tags[i].target.trackuid) {
MatroskaTrack *track = matroska-tracks.elem;
-for (j = 0; j matroska-tracks.nb_elem; j++)
-if (track[j].uid == tags[i].target.trackuid
track[j].stream)
+for (j = 0; j matroska-tracks.nb_elem; j++) {
+if (track[j].uid == tags[i].target.trackuid
track[j].stream) {
Adding the { and } seems redundant, but personally I don't mind.
+MatroskaTag *track_tags = tags[i].tag.elem;
+int64_t track_duration_ms;
+for (int ind = 0; ind tags[i].tag.nb_elem; ++ind) {
+if (track_tags[ind].name
+!av_strcasecmp(track_tags[ind].name, duration)
+track_tags[ind].string
+(av_parse_time(track_duration_ms,
track_tags[ind].string, 1) == 0)) {
Who says the syntax mkvmerge writes and the syntax av_parse_time() will
always be the same? I'm not sure if we should rely on this.
+track[j].stream-duration =
av_rescale_q(track_duration_ms,
+
(AVRational){ 1, 100 },
+
track[j].stream-time_base);
+}
+}
+
matroska_convert_tag(s, tags[i].tag,
track[j].stream-metadata, NULL);
+}
+}
} else {
matroska_convert_tag(s, tags[i].tag, s-metadata,
tags[i].target.type);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/6] aacenc: remove redundant argument from coder functions
On Wed, Jul 29, 2015 at 1:44 AM, Rostislav Pehlivanov atomnu...@gmail.com wrote: This commit removes a redundant argument from the functions in aaccoder. The argument lambda was redundant as it was just a copy of s-lambda, to which all functions have access to anyway. This cleans up the function pointers a bit which is helpful as there are a lot of other search_for_* functions under development and with them populated it gets messy. LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] ffmpeg: modify tty state when stderr is redirected
Le tridi 13 thermidor, an CCXXIII, Ganesh Ajjanagadde a écrit : Nevertheless, echo $? invoked right after this yields 2 for both. The reason this happens is the md5sum wrapper sees that the output file has not been written, and errors out there (see the .err files for precisely what I mean). This is why I did not notice it. Ok. Seeing the above, I think just the change in ffmpeg.c along with telling people of the workarounds for both bashrc and zshrc should be enough, with no modification to run-tests.sh. Indeed, but the change to add -nostdin to FATE is also right: FATE is not an interactive process, it should not listen for interactive commands. If the cat paws the q key while FATE is running, it will cause a failure, it should not. There are three issues, and one right fix for each of them: 1. ffmpeg reads command on stdin and needs stdin to be a tty in cbreak mode: the test must be on stdin, not any other file descriptor. Actually, no test at all should work too, since tcgetattr() would fail anyway. - The patch that has just been reverted was right. 2. ffmpeg can crash, ffmpeg can not catch all signals (example: memory-leak, OOM killer, SIGKILL, uncatchable): the shell should be configured to restore the tty in a sane state. - ttyctl -f in ~/.zshrc, bash_tty_mode=$(stty -g); PROMPT_COMMAND='stty $bash_tty_mode' in ~/.bashrc; that can be added in the FAQ or the wiki. 3. FATE is non-interactive: it should not listen to interactive commands. - run FATE with -nostdin. 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 1/4] blowfish: add av_blowfish_alloc()
On 31/07/15 11:09 PM, Michael Niedermayer wrote:
On Fri, Jul 31, 2015 at 05:58:48PM -0300, James Almer wrote:
On 31/07/15 5:40 PM, Michael Niedermayer wrote:
On Fri, Jul 31, 2015 at 02:18:07PM -0300, James Almer wrote:
Signed-off-by: James Almer jamr...@gmail.com
---
doc/APIchanges | 3 +++
libavutil/blowfish.c | 15 +++
libavutil/blowfish.h | 10 ++
libavutil/version.h | 5 -
4 files changed, 32 insertions(+), 1 deletion(-)
[...]
@@ -30,12 +31,21 @@
* @{
*/
+#if FF_API_CRYPTO_CONTEXT
#define AV_BF_ROUNDS 16
typedef struct AVBlowfish {
uint32_t p[AV_BF_ROUNDS + 2];
uint32_t s[4][256];
} AVBlowfish;
+#else
+typedef struct AVBlowfish AVBlowfish;
+#endif
Is it intended to remove all means to allocate the context on the
stack ?
this would avoid dealing with malloc/free and malloc failure handling
and could be a signifiant advantage also if any usecase is in a API
that lacks the possibility to fail, like maybe some crypto callbacks
with void return
I have no preferences regarding the context, really, I'm just trying to get
the
API for all the modules consistent. Not sure what would be the use of an
alloc
function if the context is not opaque, though.
ive no oppinion on the API at all, just remembered that usage without
alloc was something we thought about in some of the things in avutil
long ago. That is some of the APIs in there where designed so they
could be used without *alloc() and the implied complexity.
iam not against droping that if thats what people prefer
It would also be possible to add the alloc code and leave the on stack
usage possibility or try to change the struct to be opaque and still
usable o the stack. There are many possibilities, i dont know which
people prefer.
Ok. Since the scheduled removal can be undone at any time (effectively making
this patchset only add the alloc functions) it's not something we would be stuck
with as soon as it's committed, so I'll push this set as is in a few days if
nobody is against it. We can then see how to proceed.
Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: modify tty state when stderr is redirected
On Fri, Jul 31, 2015 at 10:15 PM, Michael Niedermayer mich...@niedermayer.cc wrote: On Fri, Jul 31, 2015 at 10:51:31AM +0200, Nicolas George wrote: Le tridi 13 thermidor, an CCXXIII, Michael Niedermayer a écrit : no disagreement here but as the shell does not do that (well at least not bash here) it causes moderate inconvenience to the developers in everyday work if the terminal needs to be reset after a fate failure And what happens after a FATE failure? Based on my experience, frequently, developers would copy-paste the failing FATE command line and re-run it interactively. And since stderr is no longer redirected, the tty gets trashed. No need of a failure, even: just try this: ffmpeg -lavfi testsrc -f framecrc | head ... ffmpeg is killed by SIGPIPE, which is not caught: terminal trashed. Thats interresting, i tried this and it did not trash my terminal also ive almost never seen ffmpeg trash my terminal with the current code. No matter how i run it GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu) I think Nicolas meant ffmpeg -lavfi testsrc -f framecrc - | head (note the trailing -). This does illustrate the trashing. BTW, note that not all trashing may be easily observed, so the method I used for testing is doing an stty -a before and after command invocation (redirecting to a log), and then doing a diff. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. ___ 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 2/2] libavformat/dsfdec: Error dsf_read_header fixed.
On Fri, Jul 31, 2015 at 9:29 PM, Peter Ross pr...@xvid.org wrote:
On Fri, Jul 31, 2015 at 08:56:49PM -0400, Ganesh Ajjanagadde wrote:
On Fri, Jul 31, 2015 at 8:08 PM, Michael Niedermayer
mich...@niedermayer.cc wrote:
On Fri, Jul 31, 2015 at 07:33:01PM -0400, Ganesh Ajjanagadde wrote:
On Fri, Jul 31, 2015 at 7:01 PM, Ihar A. Tumashyk itumas...@gmail.com
wrote:
Sample rate is written as is in header . Is *should not* be devined by
8. Refer spec.:
http://dsd-guide.com/sites/default/files/white-
papers/DSFFileFormatSpec_E.pdf
After this patch ffprobe will corretly show sample rate for DSF files.
Signed-off-by: Ihar A. Tumashyk itumas...@gmail.com
---
libavformat/dsfdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dsfdec.c b/libavformat/dsfdec.c
index ae198b2..3e162ae 100644
--- a/libavformat/dsfdec.c
+++ b/libavformat/dsfdec.c
@@ -105,7 +105,7 @@ static int dsf_read_header(AVFormatContext *s)
st-codec-codec_type = AVMEDIA_TYPE_AUDIO;
st-codec-channels = avio_rl32(pb);
-st-codec-sample_rate = avio_rl32(pb) / 8;
+st-codec-sample_rate = avio_rl32(pb);
switch(avio_rl32(pb)) {
case 1: st-codec-codec_id = AV_CODEC_ID_DSD_LSBF_PLANAR; break;
LGTM, thanks for clarifying intent of previous patch.
I am a little puzzled as to why this was never caught till now,
Changing the sample rate like in the patch breaks playback (it plays
much too quick)
you can find samples to test at:
http://www.2l.no/hires/
I really need to stop trusting these spec files that much,
they are often incomplete as in this case. Ironically,
wikipedia here gives a much better description of the format:
https://en.wikipedia.org/wiki/Direct_Stream_Digital,
where they mention that essentially this signal is oversampled by a factor
of 8.
As the wiki entry indicates, max frequency of PCM is 352.8 kHz.
In fact, I think previous patch should be reverted:
the wikipedia article says that newer format is called DSD-wide and
uses 8-bit word length.
ffprobe yields the downsampled frequency of 352.8 kHz which is what
actually gets used when one demuxes/
operates on the data per wikipedia.
Thus, I believe previous behavior was correct.
converting between DSD-PCM reduces the sample rate by 8.
at present, the DSD-PCM conversion happens libavcodec/dsddec.c.
however, a 'codec' cannot change sample_rate, so the divide by 8 is performed
earlier in libavformat.
yes, this is a hack.
i have a patch set that moves DSD-PCM conversion into swresample, where it
belongs,
along with adding a DST decoder and support for additional file formats.
If anyone is interested, I can repost.
Was there a reason why previous patch set was ignored or not applied?
(Relevant mailing list link would help to get a sense for it).
At the minimum though, this hack should have relevant comments for it
in the source code.
This would have removed some of the confusion.
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
___
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] libavformat/matroskadec.c: Parse stream durations set by mkvmerge and populate them in AVStream.
The syntax is the normal syntax HH:MM:SS used everywhere.
av_parse_time can parse both [-]HH:MM:SS[.m...]]] and [-]S+[.m...]
syntax for duration. So if mkvmerge outputs 1200.00 secs in duration it
would be able to parse that also .
On Fri, Jul 31, 2015 at 3:31 PM, wm4 nfx...@googlemail.com wrote:
On Fri, 31 Jul 2015 13:00:02 -0700
Sasi Inguva is...@google.com wrote:
Signed-off-by: Sasi Inguva is...@google.com
---
libavformat/matroskadec.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 1807cae..03b564e 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -41,6 +41,7 @@
#include libavutil/lzo.h
#include libavutil/mathematics.h
#include libavutil/opt.h
+#include libavutil/parseutils.h
#include libavutil/time_internal.h
#include libavcodec/bytestream.h
@@ -1418,10 +1419,25 @@ static void
matroska_convert_tags(AVFormatContext *s)
chapter[j].chapter-metadata,
NULL);
} else if (tags[i].target.trackuid) {
MatroskaTrack *track = matroska-tracks.elem;
-for (j = 0; j matroska-tracks.nb_elem; j++)
-if (track[j].uid == tags[i].target.trackuid
track[j].stream)
+for (j = 0; j matroska-tracks.nb_elem; j++) {
+if (track[j].uid == tags[i].target.trackuid
track[j].stream) {
Adding the { and } seems redundant, but personally I don't mind.
+MatroskaTag *track_tags = tags[i].tag.elem;
+int64_t track_duration_ms;
+for (int ind = 0; ind tags[i].tag.nb_elem; ++ind)
{
+if (track_tags[ind].name
+!av_strcasecmp(track_tags[ind].name,
duration)
+track_tags[ind].string
+(av_parse_time(track_duration_ms,
track_tags[ind].string, 1) == 0)) {
Who says the syntax mkvmerge writes and the syntax av_parse_time() will
always be the same? I'm not sure if we should rely on this.
+track[j].stream-duration =
av_rescale_q(track_duration_ms,
+
(AVRational){ 1, 100 },
+
track[j].stream-time_base);
+}
+}
+
matroska_convert_tag(s, tags[i].tag,
track[j].stream-metadata,
NULL);
+}
+}
} else {
matroska_convert_tag(s, tags[i].tag, s-metadata,
tags[i].target.type);
___
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] libavcodec/utils: av_get_exact_bits_per_sample fixed to return 1 for DSD codecs.
On Fri, Jul 31, 2015 at 6:52 PM, Ihar A. Tumashyk itumas...@gmail.com wrote:
All DSD codes have 1 bit per sample.
https://en.wikipedia.org/wiki/Direct_Stream_Digital
Signed-off-by: Ihar A. Tumashyk itumas...@gmail.com
---
libavcodec/utils.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 5dbd0cf..52bfe01 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -3311,6 +3311,11 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
int av_get_exact_bits_per_sample(enum AVCodecID codec_id)
{
switch (codec_id) {
+case AV_CODEC_ID_DSD_LSBF:
+case AV_CODEC_ID_DSD_MSBF:
+case AV_CODEC_ID_DSD_LSBF_PLANAR:
+case AV_CODEC_ID_DSD_MSBF_PLANAR:
+return 1;
case AV_CODEC_ID_8SVX_EXP:
case AV_CODEC_ID_8SVX_FIB:
case AV_CODEC_ID_ADPCM_CT:
@@ -3321,10 +3326,6 @@ int av_get_exact_bits_per_sample(enum AVCodecID
codec_id)
case AV_CODEC_ID_ADPCM_G722:
case AV_CODEC_ID_ADPCM_YAMAHA:
return 4;
-case AV_CODEC_ID_DSD_LSBF:
-case AV_CODEC_ID_DSD_MSBF:
-case AV_CODEC_ID_DSD_LSBF_PLANAR:
-case AV_CODEC_ID_DSD_MSBF_PLANAR:
case AV_CODEC_ID_PCM_ALAW:
case AV_CODEC_ID_PCM_MULAW:
case AV_CODEC_ID_PCM_S8:
--
2.1.4
LGTM, but I am not the maintainer for it.
Out of curiosity, did you run into this via code inspection or trying
to fix something?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] libavformat/dsfdec: Error dsf_read_header fixed.
Sample rate is written as is in header . Is *should not* be devined by
8. Refer spec.:
http://dsd-guide.com/sites/default/files/white-
papers/DSFFileFormatSpec_E.pdf
After this patch ffprobe will corretly show sample rate for DSF files.
Signed-off-by: Ihar A. Tumashyk itumas...@gmail.com
---
libavformat/dsfdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dsfdec.c b/libavformat/dsfdec.c
index ae198b2..3e162ae 100644
--- a/libavformat/dsfdec.c
+++ b/libavformat/dsfdec.c
@@ -105,7 +105,7 @@ static int dsf_read_header(AVFormatContext *s)
st-codec-codec_type = AVMEDIA_TYPE_AUDIO;
st-codec-channels = avio_rl32(pb);
-st-codec-sample_rate = avio_rl32(pb) / 8;
+st-codec-sample_rate = avio_rl32(pb);
switch(avio_rl32(pb)) {
case 1: st-codec-codec_id = AV_CODEC_ID_DSD_LSBF_PLANAR; break;
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/utils: av_get_exact_bits_per_sample fixed to return 1 for DSD codecs.
01.08.2015 у 02:01 Ganesh Ajjanagadde напісаў:
On Fri, Jul 31, 2015 at 6:52 PM, Ihar A. Tumashyk itumas...@gmail.com wrote:
All DSD codes have 1 bit per sample.
https://en.wikipedia.org/wiki/Direct_Stream_Digital
Signed-off-by: Ihar A. Tumashyk itumas...@gmail.com
---
libavcodec/utils.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 5dbd0cf..52bfe01 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -3311,6 +3311,11 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
int av_get_exact_bits_per_sample(enum AVCodecID codec_id)
{
switch (codec_id) {
+case AV_CODEC_ID_DSD_LSBF:
+case AV_CODEC_ID_DSD_MSBF:
+case AV_CODEC_ID_DSD_LSBF_PLANAR:
+case AV_CODEC_ID_DSD_MSBF_PLANAR:
+return 1;
case AV_CODEC_ID_8SVX_EXP:
case AV_CODEC_ID_8SVX_FIB:
case AV_CODEC_ID_ADPCM_CT:
@@ -3321,10 +3326,6 @@ int av_get_exact_bits_per_sample(enum AVCodecID codec_id)
case AV_CODEC_ID_ADPCM_G722:
case AV_CODEC_ID_ADPCM_YAMAHA:
return 4;
-case AV_CODEC_ID_DSD_LSBF:
-case AV_CODEC_ID_DSD_MSBF:
-case AV_CODEC_ID_DSD_LSBF_PLANAR:
-case AV_CODEC_ID_DSD_MSBF_PLANAR:
case AV_CODEC_ID_PCM_ALAW:
case AV_CODEC_ID_PCM_MULAW:
case AV_CODEC_ID_PCM_S8:
--
2.1.4
LGTM, but I am not the maintainer for it.
Out of curiosity, did you run into this via code inspection or trying
to fix something?
Yes, I'm working with DSF files and found that ffprobe returns wrong
sample rates for these files. This is
because it divided by 8 while reading but (as compensation maybe to have
correct bitrate) bps is 8.
Refer my next patch [PATCH 2/2] libavformat/dsfdec: Error
dsf_read_header fixed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 8/8] doc/example: Add http multi-client example code
On Sat, Aug 1, 2015 at 1:13 AM, Stephan Holljes klaxa1...@googlemail.com wrote: On Fri, Jul 31, 2015 at 4:29 PM, Nicolas George geo...@nsup.org wrote: I have no more remarks on the whole series, I believe it can be applied. If your public Git tree is ready for pulls, you can do a final rebase and send a pull request directly. If not, I can do the same with my tree. Regards, -- Nicolas George I just rebased, added a description and made a pull-request. (My command was: git request-pull master http://git.klaxa.eu/git/ffmpeg simple_http_server_api_implementation I hope that's correct?) I am currently working on tests to be run with FATE. In that regard, I want test both: the command line feature and the multi-client API. Should I test the command line feature like in tests/fate/ffprobe.mak or test it on the API level? Also: Should I use the existing sample implementation in doc/examples/ or use the API to construct concrete tests (probably with fork() and waitpid() or a different form to do threading to simulate multiple clients)? I forgot to add: Comparable to libavformat/seek-test.c. Regards, Stephan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 8/8] doc/example: Add http multi-client example code
On Fri, Jul 31, 2015 at 4:29 PM, Nicolas George geo...@nsup.org wrote: I have no more remarks on the whole series, I believe it can be applied. If your public Git tree is ready for pulls, you can do a final rebase and send a pull request directly. If not, I can do the same with my tree. Regards, -- Nicolas George I just rebased, added a description and made a pull-request. (My command was: git request-pull master http://git.klaxa.eu/git/ffmpeg simple_http_server_api_implementation I hope that's correct?) I am currently working on tests to be run with FATE. In that regard, I want test both: the command line feature and the multi-client API. Should I test the command line feature like in tests/fate/ffprobe.mak or test it on the API level? Also: Should I use the existing sample implementation in doc/examples/ or use the API to construct concrete tests (probably with fork() and waitpid() or a different form to do threading to simulate multiple clients)? Regards, Stephan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] libavformat/dsfdec: Error dsf_read_header fixed.
On Fri, Jul 31, 2015 at 7:01 PM, Ihar A. Tumashyk itumas...@gmail.com wrote:
Sample rate is written as is in header . Is *should not* be devined by
8. Refer spec.:
http://dsd-guide.com/sites/default/files/white-
papers/DSFFileFormatSpec_E.pdf
After this patch ffprobe will corretly show sample rate for DSF files.
Signed-off-by: Ihar A. Tumashyk itumas...@gmail.com
---
libavformat/dsfdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dsfdec.c b/libavformat/dsfdec.c
index ae198b2..3e162ae 100644
--- a/libavformat/dsfdec.c
+++ b/libavformat/dsfdec.c
@@ -105,7 +105,7 @@ static int dsf_read_header(AVFormatContext *s)
st-codec-codec_type = AVMEDIA_TYPE_AUDIO;
st-codec-channels = avio_rl32(pb);
-st-codec-sample_rate = avio_rl32(pb) / 8;
+st-codec-sample_rate = avio_rl32(pb);
switch(avio_rl32(pb)) {
case 1: st-codec-codec_id = AV_CODEC_ID_DSD_LSBF_PLANAR; break;
LGTM, thanks for clarifying intent of previous patch.
I am a little puzzled as to why this was never caught till now,
but then again this is quite recent code with very little testing and commits:
git log libavformat/dsfdec.c
shows very few.
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec/utils: av_get_exact_bits_per_sample fixed to return 1 for DSD codecs.
All DSD codes have 1 bit per sample.
https://en.wikipedia.org/wiki/Direct_Stream_Digital
Signed-off-by: Ihar A. Tumashyk itumas...@gmail.com
---
libavcodec/utils.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 5dbd0cf..52bfe01 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -3311,6 +3311,11 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
int av_get_exact_bits_per_sample(enum AVCodecID codec_id)
{
switch (codec_id) {
+case AV_CODEC_ID_DSD_LSBF:
+case AV_CODEC_ID_DSD_MSBF:
+case AV_CODEC_ID_DSD_LSBF_PLANAR:
+case AV_CODEC_ID_DSD_MSBF_PLANAR:
+return 1;
case AV_CODEC_ID_8SVX_EXP:
case AV_CODEC_ID_8SVX_FIB:
case AV_CODEC_ID_ADPCM_CT:
@@ -3321,10 +3326,6 @@ int av_get_exact_bits_per_sample(enum AVCodecID codec_id)
case AV_CODEC_ID_ADPCM_G722:
case AV_CODEC_ID_ADPCM_YAMAHA:
return 4;
-case AV_CODEC_ID_DSD_LSBF:
-case AV_CODEC_ID_DSD_MSBF:
-case AV_CODEC_ID_DSD_LSBF_PLANAR:
-case AV_CODEC_ID_DSD_MSBF_PLANAR:
case AV_CODEC_ID_PCM_ALAW:
case AV_CODEC_ID_PCM_MULAW:
case AV_CODEC_ID_PCM_S8:
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Simple HTTP Server API Implementation
The following changes since commit 5870b3d2a3afdae0ed42fa9fd010684ee18feca8: MAINTAINERS: update my maintership (2015-07-31 20:25:07 +0200) are available in the git repository at: http://git.klaxa.eu/git/ffmpeg simple_http_server_api_implementation for you to fetch changes up to 25410c524ddee98c579c7a9ddaf0535278a6dae0: doc/example: Add http multi-client example code (2015-08-01 00:58:32 +0200) (from the branch description for simple_http_server_api_implementation local branch) This patchset splits ff_listen_bind into ff_listen and ff_accept to support handling more than one client, while still maintaining compatibility to the existing API. The *_handshake-group of functions are the communication function between libavformat and the application using it. The client can set and get variables via the AVOption system. Basic implementations for tcp and http have been added. Sample code for multi-client usage is included in the doc/examples directory. Stephan Holljes (8): lavf/network: split ff_listen_bind into ff_listen and ff_accept lavf/avio: add ffurl_accept and ffurl_handshake lavf/avio: add avio_accept and avio_handshake lavf/tcp: add tcp_accept lavf/tcp: increase range for listen and call the underlying socket operations accordingly lavf/http: Implement server side network code. doc/protocols: document experimental mutli-client api doc/example: Add http multi-client example code doc/examples/Makefile | 1 + doc/examples/http_multiclient.c | 155 +++ doc/protocols.texi | 2 ++ libavformat/avio.c | 20 +++ libavformat/avio.h | 29 +++ libavformat/aviobuf.c | 17 + libavformat/http.c | 182 - libavformat/network.c | 27 ++ libavformat/network.h | 20 +++ libavformat/tcp.c | 33 ++--- libavformat/url.h | 25 + 11 files changed, 476 insertions(+), 35 deletions(-) create mode 100644 doc/examples/http_multiclient.c ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/utils: av_get_exact_bits_per_sample fixed to return 1 for DSD codecs.
On Fri, Jul 31, 2015 at 07:01:54PM -0400, Ganesh Ajjanagadde wrote:
On Fri, Jul 31, 2015 at 6:52 PM, Ihar A. Tumashyk itumas...@gmail.com wrote:
All DSD codes have 1 bit per sample.
https://en.wikipedia.org/wiki/Direct_Stream_Digital
Signed-off-by: Ihar A. Tumashyk itumas...@gmail.com
---
libavcodec/utils.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 5dbd0cf..52bfe01 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -3311,6 +3311,11 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
int av_get_exact_bits_per_sample(enum AVCodecID codec_id)
{
switch (codec_id) {
+case AV_CODEC_ID_DSD_LSBF:
+case AV_CODEC_ID_DSD_MSBF:
+case AV_CODEC_ID_DSD_LSBF_PLANAR:
+case AV_CODEC_ID_DSD_MSBF_PLANAR:
+return 1;
case AV_CODEC_ID_8SVX_EXP:
case AV_CODEC_ID_8SVX_FIB:
case AV_CODEC_ID_ADPCM_CT:
@@ -3321,10 +3326,6 @@ int av_get_exact_bits_per_sample(enum AVCodecID
codec_id)
case AV_CODEC_ID_ADPCM_G722:
case AV_CODEC_ID_ADPCM_YAMAHA:
return 4;
-case AV_CODEC_ID_DSD_LSBF:
-case AV_CODEC_ID_DSD_MSBF:
-case AV_CODEC_ID_DSD_LSBF_PLANAR:
-case AV_CODEC_ID_DSD_MSBF_PLANAR:
case AV_CODEC_ID_PCM_ALAW:
case AV_CODEC_ID_PCM_MULAW:
case AV_CODEC_ID_PCM_S8:
--
2.1.4
LGTM, [...]
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/libx264: expose nv21 input support
libx264 added support for NV21 input recently.
---
libavcodec/libx264.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 5da816e..c017685 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -381,6 +381,9 @@ static int convert_pix_fmt(enum AVPixelFormat pix_fmt)
case AV_PIX_FMT_NV12: return X264_CSP_NV12;
case AV_PIX_FMT_NV16:
case AV_PIX_FMT_NV20: return X264_CSP_NV16;
+#ifdef X264_CSP_NV21
+case AV_PIX_FMT_NV21: return X264_CSP_NV21;
+#endif
};
return 0;
}
@@ -770,6 +773,9 @@ static const enum AVPixelFormat pix_fmts_8bit[] = {
AV_PIX_FMT_YUVJ444P,
AV_PIX_FMT_NV12,
AV_PIX_FMT_NV16,
+#ifdef X264_CSP_NV21
+AV_PIX_FMT_NV21,
+#endif
AV_PIX_FMT_NONE
};
static const enum AVPixelFormat pix_fmts_9bit[] = {
--
2.4.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: modify tty state when stderr is redirected
On Thu, Jul 30, 2015 at 10:58:57PM -0400, Ganesh Ajjanagadde wrote:
On Thu, Jul 30, 2015 at 9:53 PM, Michael Niedermayer
mich...@niedermayer.cc wrote:
On Thu, Jul 30, 2015 at 05:57:54PM -0400, Ganesh Ajjanagadde wrote:
On Thu, Jul 30, 2015 at 5:49 PM, Michael Niedermayer
mich...@niedermayer.cc wrote:
On Thu, Jul 30, 2015 at 02:43:01PM +0200, Michael Niedermayer wrote:
On Wed, Jul 29, 2015 at 05:28:16PM -0400, Ganesh Ajjanagadde wrote:
On Wed, Jul 29, 2015 at 3:27 PM, Michael Niedermayer
mich...@niedermayer.cc wrote:
On Wed, Jul 29, 2015 at 02:43:52PM -0400, Ganesh Ajjanagadde wrote:
On Mon, Jul 27, 2015 at 9:56 AM, Ganesh Ajjanagadde
gajjanaga...@gmail.com wrote:
This fixes Ticket2964
Signed-off-by: Ganesh Ajjanagadde gajjanaga...@gmail.com
---
ffmpeg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index 751c7d3..98f812e 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -372,7 +372,7 @@ void term_init(void)
struct termios tty;
int istty = 1;
#if HAVE_ISATTY
-istty = isatty(0) isatty(2);
+istty = isatty(0);
#endif
if (istty tcgetattr (0, tty) == 0) {
oldtty = tty;
ping
i dont mind applying this but i dont remember why it was there
so this might break somethig and someone might then have to revert
See the long discussion I had (with my initial patch series) for full
details.
A short summary is as follows:
in order to accept q and other stuff, ffmpeg has to change the
terminal mode.
Once terminal mode is changed, on event of hard signal like SIGSEGV,
it is not the responsibility of ffmpeg to clean up and restore the
terminal state
that now appears as messed up.
I had a patch to do this, but this requires registering signal handler
for such signals,
and others had valid objections since the core dump is no longer
clean.
Thus, terminal restoration should be handled by the shell.
Fortunately, zsh has such functionality (thanks Nicolas for pointing
this out!) via ttyctl -f
to freeze terminal, i.e prevent any process from damaging the
terminal state on exit.
In bash it is harder to do this; AFAIK requires manual intervention.
Unless fate tests redirect 2(stderr) and do not redirect 0(stdin),
functionality is identical.
Even otherwise, by above argument, I think this is the right thing to
do.
patch applied
note, if something breaks, ill revert this one, but hopefully it
will work fine
any failure in fate trashes the terminal, thus reverted
To reproduce, add a abort() into wav_read_header()
run make fate-acodec-adpcm-ima_wav
Yes, but the trashing cleanup is not ffmpeg's job; the shell should do it.
no disagreement here but as the shell does not do that (well at least
not bash here)
it causes moderate inconvenience to the developers
in everyday work if the terminal needs to be reset after a fate
failure
Ok, in that case I will reopen the ticket.
Note that this rules out straightforward fixes.
The only idea I have left is to create wrapper functions around ffmpeg
invocations (e.g in fate) like:
function ffmpeg_wrapper()
{
STTYOPTS=$(stty --save)
ffmpeg $@
stty ${STTYOPTS}
}.
What do people think of this?
i dont think this solves the problem, not everything calls ffmpeg
through such wrapper
ATM ffmpeg in practice doesnt leave the terminal in a messed up state
from te users point of view when it crashes. And there should be no
regression here.
I dont think it would be an improvment if #2964 is fixed
and then instead have ffmpeg randomly mess up the terminal instead
2964: (aka the
user can quit a process by pressing 'q' instead of crtl-c when its
stderr is oddly redirected and stderr actually is what the whole
system uses to communicate so the user cannot even see the message
about pressing 'q')
I think #2964 is less important than a regression with messing up the
terminal. So to fix #2964 a solution would need to be found which
does not cause the terminal to be messed up on crashes in real
world cases. I dont know how to do that. And i dont know enough
about this subject to say if its practically possible or not.
[...]
--
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
Re: [FFmpeg-devel] [PATCHv2] ffmpeg: modify tty state when stderr is redirected
Le duodi 12 thermidor, an CCXXIII, Ganesh Ajjanagadde a écrit :
ffmpeg(){
+stty_opts=$(stty --save)
dec_opts=-hwaccel $hwaccel -threads $threads -thread_type $thread_type
ffmpeg_args=-nostats -cpuflags $cpuflags
for arg in $@; do
@@ -99,6 +100,7 @@ ffmpeg(){
ffmpeg_args=${ffmpeg_args} ${arg}
done
run ffmpeg ${ffmpeg_args}
+stty ${stty_opts}
Does this work? With that change, the return code of the wrapper function is
no longer the return code of run ffmpeg but the return code of stty,
always success.
There is a much simpler fix: add -nostdin to ffmpeg_args, along with
-nostats.
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] ffmpeg: modify tty state when stderr is redirected
Le tridi 13 thermidor, an CCXXIII, Michael Niedermayer a écrit : no disagreement here but as the shell does not do that (well at least not bash here) it causes moderate inconvenience to the developers in everyday work if the terminal needs to be reset after a fate failure And what happens after a FATE failure? Based on my experience, frequently, developers would copy-paste the failing FATE command line and re-run it interactively. And since stderr is no longer redirected, the tty gets trashed. No need of a failure, even: just try this: ffmpeg -lavfi testsrc -f framecrc | head ... ffmpeg is killed by SIGPIPE, which is not caught: terminal trashed. The stderr test is bogus and only works on a few cases, the tip of the iceberg. I strongly urge you to fix your shell configuration instead. I have no idea why it is not the default configuration, apparently distributors do not care about trashed ttys. But enabling it is quite trivial. It is not as simple and as efficient with bash as it is with zsh (ttyctl -f), but still quite simple: add this in your .bashrc: bash_tty_state=$(stty -g) PROMPT_COMMAND='stty $bash_tty_state' ... nothing more (except if you already have a PROMPT_COMMAND). 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] [PATCHv2] ffmpeg: modify tty state when stderr is redirected
On Fri, Jul 31, 2015 at 4:32 AM, Nicolas George geo...@nsup.org wrote:
Le duodi 12 thermidor, an CCXXIII, Ganesh Ajjanagadde a écrit :
ffmpeg(){
+stty_opts=$(stty --save)
dec_opts=-hwaccel $hwaccel -threads $threads -thread_type $thread_type
ffmpeg_args=-nostats -cpuflags $cpuflags
for arg in $@; do
@@ -99,6 +100,7 @@ ffmpeg(){
ffmpeg_args=${ffmpeg_args} ${arg}
done
run ffmpeg ${ffmpeg_args}
+stty ${stty_opts}
Does this work? With that change, the return code of the wrapper function is
no longer the return code of run ffmpeg but the return code of stty,
always success.
It does at least in Michael's example, but clobbers the exit code,
which is why I did not notice it.
Try a make fate-acodec-adpcm-ima_wav, after inserting an abort() in
wav_read_header().
With above patch,
make errors out:
TESTacodec-adpcm-ima_wav
--- ./tests/ref/acodec/adpcm-ima_wav2015-07-29 23:05:55.951506099 -0400
+++ tests/data/fate/acodec-adpcm-ima_wav2015-07-31 07:25:24.029781733 -0400
@@ -1,4 +1,2 @@
56b75c3a6dacedcf2ce7b0586aa33594 *tests/data/fate/acodec-adpcm-ima_wav.wav
267324 tests/data/fate/acodec-adpcm-ima_wav.wav
-78a2af1c895792d0c221d127bdd48ece *tests/data/fate/acodec-adpcm-ima_wav.out.wav
-stddev: 903.51 PSNR: 37.21 MAXDIFF:34026 bytes: 1058400/ 1061748
Test acodec-adpcm-ima_wav failed. Look at
tests/data/fate/acodec-adpcm-ima_wav.err for details.
tests/Makefile:203: recipe for target 'fate-acodec-adpcm-ima_wav' failed
make: *** [fate-acodec-adpcm-ima_wav] Error 1
without this patch to run-tests,
make errors out:
TESTacodec-adpcm-ima_wav
--- ./tests/ref/acodec/adpcm-ima_wav2015-07-29 23:05:55.951506099 -0400
+++ tests/data/fate/acodec-adpcm-ima_wav2015-07-31 07:25:54.486446785 -0400
@@ -1,4 +0,0 @@
-56b75c3a6dacedcf2ce7b0586aa33594 *tests/data/fate/acodec-adpcm-ima_wav.wav
-267324 tests/data/fate/acodec-adpcm-ima_wav.wav
-78a2af1c895792d0c221d127bdd48ece *tests/data/fate/acodec-adpcm-ima_wav.out.wav
-stddev: 903.51 PSNR: 37.21 MAXDIFF:34026 bytes: 1058400/ 1061748
Test acodec-adpcm-ima_wav failed. Look at
tests/data/fate/acodec-adpcm-ima_wav.err for details.
tests/Makefile:203: recipe for target 'fate-acodec-adpcm-ima_wav' failed
make: *** [fate-acodec-adpcm-ima_wav] Error 134
Nevertheless, echo $? invoked right after this yields 2 for both.
The reason this happens is the md5sum wrapper sees that the output
file has not been written,
and errors out there (see the .err files for precisely what I mean).
This is why I did not notice it.
There is a much simpler fix: add -nostdin to ffmpeg_args, along with
-nostats.
Seeing the above, I think just the change in ffmpeg.c along with
telling people of the workarounds for both bashrc and zshrc
should be enough, with no modification to run-tests.sh.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mov: fix regression in processing .aax files
From 418d573659dd011de503e45622307974cf437df5 Mon Sep 17 00:00:00 2001
From: Vesselin Bontchev vesselin.bontc...@yandex.com
Date: Fri, 31 Jul 2015 12:16:08 +0200
Subject: [PATCH] avformat/mov: fix regression in processing .aax files
Commit 0a551cbe introduced activation_bytes option, and not specifying
this option (while calling ffmpeg / ffprobe) causes the program to quit
early. Before this commit, ffprobe was capable of processing metadata in
.aax files.
---
libavformat/mov.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index fdba34c..6a81848 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -849,13 +849,13 @@ static int mov_read_adrm(MOVContext *c, AVIOContext *pb, MOVAtom atom)
/* verify activation data */
if (!activation_bytes || c-activation_bytes_size != 4) {
-av_log(c-fc, AV_LOG_FATAL, [aax] activation_bytes option is missing!\n);
-ret = AVERROR(EINVAL);
+av_log(c-fc, AV_LOG_WARNING, [aax] activation_bytes option is missing!\n);
+ret = 0; /* allow ffprobe to continue working on .aax files */
goto fail;
}
if (c-activation_bytes_size != 4) {
-av_log(c-fc, AV_LOG_FATAL, [aax] activation_bytes value needs to be 4 bytes!\n);
-ret = AVERROR(EINVAL);
+av_log(c-fc, AV_LOG_WARNING, [aax] activation_bytes value needs to be 4 bytes!\n);
+ret = 0; /* allow ffprobe to continue working on .aax files */
goto fail;
}
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
