Re: [FFmpeg-devel] IRC meeting on Saturday 2015-09-12, UTC 15:00
On Thu, Sep 10, 2015 at 10:46 AM, Michael Niedermayer wrote: > On Mon, Sep 07, 2015 at 11:37:47AM +0200, Stefano Sabatini wrote: >> Hi, >> >> I propose to have an official IRC meeting on the next Saturday, and I >> propose the tentative time of 15:00 UTC, but feel free to propose a >> different time if this can't suit you. >> >> The IRC meeting channel will be public and the log will be published >> at the end of the meeting. >> >> This meeting is also meant as a preparation for the real-life meeting >> that will be held in Paris at the next VDD >> (http://www.videolan.org/videolan/events/vdd15/) for the FFmpeg >> developers who will attend it. >> >> I propose these topics of the day (suggested by ubitux on IRC): >> 1. ABI compatibility policy > >> 2. general policy decision process > > heres a suggestion, maybe useful as input for discussions on > Saturday ... > > FFmpeg used and uses "unanimous consent" in patch reviews > any person could make a suggestion > to improve a patch and it has to be taken care of one way or another > before the patch is ok. This system worked quite well almost all the > time. So i would suggest to use the same / a similar system for > policy decisions > > * Everyone should be able to comment and propose options/choices > * There should be enough time to understand, discuss and amend > proposals > * People should try to understand the other people and avoid strawman > arguments and other non constructive discussion tactics, people/the > commuity should step in if discussions become non constructive and > hostile and try to get people back toward constructive discussion. > * People should be able to declare reservations to a proposal without > blocking the proposal and as a seperate choice veto it in a blocking > fashion. A veto should be public with full name of the developer, > reason why it is bad for the community/project and ideally a > alternative proposal. Also developers vetoing a proposal must be > willing and able to work on finding an better solution. So you can add a deadline for the alternate proposal. For example, if the person who vetoed doesn't come up with an alternate proposal within 30 days, the original proposal must be passed. > * The authors of proposals should try to amend proposals based on > raised issues & reservations and restart the process if changes > where made. There could be a maximum number of such restarts after > which only vetos would block > > If this doesnt work due to too many vetos then it could be adjusted > to require 2 or more vetos to reject a proposal, but IMHO i dont think > this would be needed. Simply having ones full name in public with a > veto should result in people using the veto right wisely. > > A "unanimous consent" system also should push toward cooperation > and discussions intended to find compromises and understanding the > others. Because simply trying to be loud and push and troll are > unlikely effective means to find an agreement. also such a system, if > it works, would ensure noones oppinion or suggestion is just pushed > aside > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > There will always be a question for which you do not know the correct answer. > > ___ > 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] IRC meeting on Saturday 2015-09-12, UTC 15:00
FYI: Here is my experience with Python.org Step 1: If it the decision is not so important (simple patch etc.) and if 3 reviewers say yes, it will be merged. Also, it seems there are no maintainers for specific parts of the code, but instead they have "reviewers" and only reviewers can review the patch. And once they approved the patch, the patch will be submitted automated system and "reviewers" do not merge the patch by themselves. Step 2: If it is decided that the patch or change is worthy of escalation, it will be reviewed by more people. (I recall 6 but I am not sure) and they vote. (I am not sure which condition justify escalation.) Then, they will repeat the voting and escalation process and the final decision is made by a vote of the "committee" (majority rules, I am also not sure how they choose the committee etc. the python.org person might have told me but I don't remember..) I got really confused when I first came to FFmpeg. I thought it would be very similar to Python, and I didn't know that an Open Source Free Software Project could be run so dramatically different.. but it made sense though. and I see a lot of good things about the existing FFmpeg system too.. I think deciding point would be.. (I am just summarizing what is discussed so far.) - Deciding what events or arguments can causes/trigger the escalation. (I guess it means when do you need more than arguing over the email?) - Once it is decided to be escalated/vote, how the vote leads to the decisions. (majority rules or veto rules?) (and who qualifies to vote for after escalation?) (Well, basically current patch review is everyone votes right?) - Well, you can always try one and you can come back later to see how well it is working. (you need to test any system so...and there will be one problem in one system and the other (oh democracy..).. so.. You can see how happy you are and come back next year..or next time. now your guys are leaderless by the leader's own decision and your guys are pretty okay.. so i think you are fine. :) ) -- -- On Fri, Sep 11, 2015 at 6:11 AM, Ronald S. Bultje wrote: > Hi, > > On Fri, Sep 11, 2015 at 8:46 AM, Nicolas George wrote: > >> Le quintidi 25 fructidor, an CCXXIII, Michael Niedermayer a écrit : >> > I have a few problems with using the UN security council as >> > comparission >> > [..] > >> The project needs a way of making a decision when people do not agree. > > > +1, that's exactly what I meant. > > (Thank you for putting it into words.) > > Ronald > ___ > 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] "configure" breaks on MSYS2 MINGW64
Hi,
building current FFmpeg breaks on MSYS2 MINGW64
(http://sourceforge.net/projects/msys2/) with error "Unknown OS
'mingw64_nt-6.0'." from "configure".
Probably "mingw64_nt-6.0" results from "uname -s" on MSYS2 MINGW64:
$ uname -s
MINGW64_NT-6.0
The attached patch seems to fix it.
Regards, Peter
diff -rc ./a/ffmpeg/configure ./b/ffmpeg/configure
*** ./a/ffmpeg/configureFri Sep 11 19:20:03 2015
--- ./b/ffmpeg/configureSat Sep 12 10:16:52 2015
***
*** 3297,3303
exesuf() {
case $1 in
! mingw32*|win32|win64|cygwin*|*-dos|freedos|opendos|os/2*|symbian)
echo .exe ;;
esac
}
--- 3297,3303
exesuf() {
case $1 in
!
mingw32*|mingw64*|win32|win64|cygwin*|*-dos|freedos|opendos|os/2*|symbian) echo
.exe ;;
esac
}
***
*** 4342,4348
enabled_any pic shared x86_64 ||
{ check_cflags -mdynamic-no-pic && add_asflags -mdynamic-no-pic; }
;;
! mingw32*)
if test $target_os = "mingw32ce"; then
disable network
else
--- 4342,4348
enabled_any pic shared x86_64 ||
{ check_cflags -mdynamic-no-pic && add_asflags -mdynamic-no-pic; }
;;
! mingw32*|mingw64*)
if test $target_os = "mingw32ce"; then
disable network
else
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] "configure" breaks on MSYS2 MINGW64
On Sat, Sep 12, 2015 at 5:06 PM, Peter Belkner wrote: > Hi, > > building current FFmpeg breaks on MSYS2 MINGW64 > (http://sourceforge.net/projects/msys2/) with error "Unknown OS > 'mingw64_nt-6.0'." from "configure". > > Probably "mingw64_nt-6.0" results from "uname -s" on MSYS2 MINGW64: > >$ uname -s >MINGW64_NT-6.0 > > The attached patch seems to fix it. > `diff -u ` will prefer. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] "configure" breaks on MSYS2 MINGW64
On 12.09.2015 11:15, Geek.Song wrote:
diff -u
--- ./a/ffmpeg/configure2015-09-11 19:20:03.0 +0200
+++ ./b/ffmpeg/configure2015-09-12 11:36:32.78060 +0200
@@ -3297,7 +3297,7 @@
exesuf() {
case $1 in
-mingw32*|win32|win64|cygwin*|*-dos|freedos|opendos|os/2*|symbian) echo
.exe ;;
+
mingw32*|mingw64*|win32|win64|cygwin*|*-dos|freedos|opendos|os/2*|symbian) echo
.exe ;;
esac
}
@@ -4342,7 +4342,7 @@
enabled_any pic shared x86_64 ||
{ check_cflags -mdynamic-no-pic && add_asflags -mdynamic-no-pic; }
;;
-mingw32*)
+mingw32*|mingw64*)
if test $target_os = "mingw32ce"; then
disable network
else
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] IRC meeting on Saturday 2015-09-12, UTC 15:00
Hi, On Sat, Sep 12, 2015 at 4:21 AM, Yayoi Ukai wrote: > On Thu, Sep 10, 2015 at 10:46 AM, Michael Niedermayer > wrote: > > On Mon, Sep 07, 2015 at 11:37:47AM +0200, Stefano Sabatini wrote: > >> Hi, > >> > >> I propose to have an official IRC meeting on the next Saturday, and I > >> propose the tentative time of 15:00 UTC, but feel free to propose a > >> different time if this can't suit you. > >> > >> The IRC meeting channel will be public and the log will be published > >> at the end of the meeting. > >> > >> This meeting is also meant as a preparation for the real-life meeting > >> that will be held in Paris at the next VDD > >> (http://www.videolan.org/videolan/events/vdd15/) for the FFmpeg > >> developers who will attend it. > >> > >> I propose these topics of the day (suggested by ubitux on IRC): > >> 1. ABI compatibility policy > > > >> 2. general policy decision process > > > > heres a suggestion, maybe useful as input for discussions on > > Saturday ... > > > > FFmpeg used and uses "unanimous consent" in patch reviews > > any person could make a suggestion > > to improve a patch and it has to be taken care of one way or another > > before the patch is ok. This system worked quite well almost all the > > time. So i would suggest to use the same / a similar system for > > policy decisions > > > > * Everyone should be able to comment and propose options/choices > > * There should be enough time to understand, discuss and amend > > proposals > > * People should try to understand the other people and avoid strawman > > arguments and other non constructive discussion tactics, people/the > > commuity should step in if discussions become non constructive and > > hostile and try to get people back toward constructive discussion. > > * People should be able to declare reservations to a proposal without > > blocking the proposal and as a seperate choice veto it in a blocking > > fashion. A veto should be public with full name of the developer, > > reason why it is bad for the community/project and ideally a > > alternative proposal. Also developers vetoing a proposal must be > > willing and able to work on finding an better solution. > > So you can add a deadline for the alternate proposal. For example, > if the person who vetoed doesn't come up with an alternate proposal > within 30 days, > the original proposal must be passed. It means everyone can slow a proposal by 30 days. Why do we need vetos? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/avienc: add muxer option "write_channel_mask"
On Thu, Sep 10, 2015 at 04:43:42PM +0200, Tobias Rapp wrote: > On 10.09.2015 15:28, Tobias Rapp wrote: > >On 10.09.2015 14:57, Derek Buitenhuis wrote: > >>On 9/10/2015 1:25 PM, Tobias Rapp wrote: > >>>My use-case is handling recorded AVI files which have an > >>>unknown/empty/unsupported channel layout. Instead of writing the guessed > >>>channel layout into the output file, using "-write_channel_mask off" > >>>allows to write an empty channel mask instead. > >> > >>Are such files even valid? > > > >I guess so as the docs at [1] say in chapter "Details about dwChannelMask": > > > >"If, for example in a multi-channel audio authoring application, no > >speaker location is desired on any of the mono streams, the > >dwChannelMask should explicitly be set to 0." > > > >BTW: I just noticed that FATE is failing after applying the patch so > >I'll need to take a closer look and update the patch before it can be > >applied. > > Forgot to add a reference to AVClass in AVIContext. Attached an > updated version of the patch. > > /Tobias > avienc.c | 23 +-- > riff.h|5 + > riffenc.c |5 +++-- > 3 files changed, 29 insertions(+), 4 deletions(-) > 0965d232568ffd0c4ac8156de8efd547eb963cd7 > 0001-avformat-avienc-add-muxer-option-write_channel_mask.patch > From 6b2c3feb43870398005ea307d6d9ee4736dd2d11 Mon Sep 17 00:00:00 2001 > From: Tobias Rapp > Date: Thu, 10 Sep 2015 14:04:18 +0200 > Subject: [PATCH] avformat/avienc: add muxer option "write_channel_mask" applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- 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] "configure" breaks on MSYS2 MINGW64
On 12 September 2015 at 19:40, Peter Belkner wrote: > On 12.09.2015 11:15, Geek.Song wrote: > >> diff -u > > LGTM. I had an identical patch ready to fix the same problem so this one is fine. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] "configure" breaks on MSYS2 MINGW64
On Sat, Sep 12, 2015 at 2:57 PM, Matt Oliver wrote: > On 12 September 2015 at 19:40, Peter Belkner wrote: > >> On 12.09.2015 11:15, Geek.Song wrote: >> >>> diff -u >> >> > LGTM. > I had an identical patch ready to fix the same problem so this one is fine. LGTM too, applied. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] IRC meeting on Saturday 2015-09-12, UTC 15:00
On Sat, Sep 12, 2015 at 06:50:50AM -0400, Ronald S. Bultje wrote: > Hi, > > On Sat, Sep 12, 2015 at 4:21 AM, Yayoi Ukai wrote: > > > On Thu, Sep 10, 2015 at 10:46 AM, Michael Niedermayer > > wrote: > > > On Mon, Sep 07, 2015 at 11:37:47AM +0200, Stefano Sabatini wrote: > > >> Hi, > > >> > > >> I propose to have an official IRC meeting on the next Saturday, and I > > >> propose the tentative time of 15:00 UTC, but feel free to propose a > > >> different time if this can't suit you. > > >> > > >> The IRC meeting channel will be public and the log will be published > > >> at the end of the meeting. > > >> > > >> This meeting is also meant as a preparation for the real-life meeting > > >> that will be held in Paris at the next VDD > > >> (http://www.videolan.org/videolan/events/vdd15/) for the FFmpeg > > >> developers who will attend it. > > >> > > >> I propose these topics of the day (suggested by ubitux on IRC): > > >> 1. ABI compatibility policy > > > > > >> 2. general policy decision process > > > > > > heres a suggestion, maybe useful as input for discussions on > > > Saturday ... > > > > > > FFmpeg used and uses "unanimous consent" in patch reviews > > > any person could make a suggestion > > > to improve a patch and it has to be taken care of one way or another > > > before the patch is ok. This system worked quite well almost all the > > > time. So i would suggest to use the same / a similar system for > > > policy decisions > > > > > > * Everyone should be able to comment and propose options/choices > > > * There should be enough time to understand, discuss and amend > > > proposals > > > * People should try to understand the other people and avoid strawman > > > arguments and other non constructive discussion tactics, people/the > > > commuity should step in if discussions become non constructive and > > > hostile and try to get people back toward constructive discussion. > > > * People should be able to declare reservations to a proposal without > > > blocking the proposal and as a seperate choice veto it in a blocking > > > fashion. A veto should be public with full name of the developer, > > > reason why it is bad for the community/project and ideally a > > > alternative proposal. Also developers vetoing a proposal must be > > > willing and able to work on finding an better solution. > > > > So you can add a deadline for the alternate proposal. For example, > > if the person who vetoed doesn't come up with an alternate proposal > > within 30 days, > > the original proposal must be passed. > > > It means everyone can slow a proposal by 30 days. > > Why do we need vetos? let me awnser a different question first Why do we need developers/contributors? to write and maintain code amongth many other reasons If we depend on these developers/contributors then IMO we should take their oppinons and objections serious and if one of them is willing to risk her/his good name to oppose a proposal in public and maybe also plans to put signifiant time into creating a better compromise proposal then i belive this is something that should not just be brushed away easily, and especially not "quick quick" while everyones minds are maybe heated about some debate vetos would be one way to achive this iam not saying that we absolutely need vetos but i think that we should not pass proposals that would cause any one developer to leave the project or to make people be seriously unhappy. People contribute for fun, for social reasons and because they have to (like because they are paied for it) a proposal that makes contributions less fun is a bad proposal as it will result in fewer contributions. [...] -- 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] IRC meeting on Saturday 2015-09-12, UTC 15:00
On Sat, Sep 12, 2015 at 3:24 PM, Michael Niedermayer wrote: > On Sat, Sep 12, 2015 at 06:50:50AM -0400, Ronald S. Bultje wrote: >> Hi, >> >> On Sat, Sep 12, 2015 at 4:21 AM, Yayoi Ukai wrote: >> >> > On Thu, Sep 10, 2015 at 10:46 AM, Michael Niedermayer >> > wrote: >> > > On Mon, Sep 07, 2015 at 11:37:47AM +0200, Stefano Sabatini wrote: >> > >> Hi, >> > >> >> > >> I propose to have an official IRC meeting on the next Saturday, and I >> > >> propose the tentative time of 15:00 UTC, but feel free to propose a >> > >> different time if this can't suit you. >> > >> >> > >> The IRC meeting channel will be public and the log will be published >> > >> at the end of the meeting. >> > >> >> > >> This meeting is also meant as a preparation for the real-life meeting >> > >> that will be held in Paris at the next VDD >> > >> (http://www.videolan.org/videolan/events/vdd15/) for the FFmpeg >> > >> developers who will attend it. >> > >> >> > >> I propose these topics of the day (suggested by ubitux on IRC): >> > >> 1. ABI compatibility policy >> > > >> > >> 2. general policy decision process >> > > >> > > heres a suggestion, maybe useful as input for discussions on >> > > Saturday ... >> > > >> > > FFmpeg used and uses "unanimous consent" in patch reviews >> > > any person could make a suggestion >> > > to improve a patch and it has to be taken care of one way or another >> > > before the patch is ok. This system worked quite well almost all the >> > > time. So i would suggest to use the same / a similar system for >> > > policy decisions >> > > >> > > * Everyone should be able to comment and propose options/choices >> > > * There should be enough time to understand, discuss and amend >> > > proposals >> > > * People should try to understand the other people and avoid strawman >> > > arguments and other non constructive discussion tactics, people/the >> > > commuity should step in if discussions become non constructive and >> > > hostile and try to get people back toward constructive discussion. >> > > * People should be able to declare reservations to a proposal without >> > > blocking the proposal and as a seperate choice veto it in a blocking >> > > fashion. A veto should be public with full name of the developer, >> > > reason why it is bad for the community/project and ideally a >> > > alternative proposal. Also developers vetoing a proposal must be >> > > willing and able to work on finding an better solution. >> > >> > So you can add a deadline for the alternate proposal. For example, >> > if the person who vetoed doesn't come up with an alternate proposal >> > within 30 days, >> > the original proposal must be passed. >> >> >> It means everyone can slow a proposal by 30 days. >> > >> Why do we need vetos? > > let me awnser a different question first > Why do we need developers/contributors? > to write and maintain code amongth many other reasons > > If we depend on these developers/contributors then IMO we should take > their oppinons and objections serious and if one of them is willing > to risk her/his good name to oppose a proposal in public and maybe also > plans to put signifiant time into creating a better compromise proposal > then i belive this is something that should not just be brushed away > easily, and especially not "quick quick" while > everyones minds are maybe heated about some debate > > vetos would be one way to achive this > iam not saying that we absolutely need vetos but i think that we > should not pass proposals that would cause any one developer to leave > the project or to make people be seriously unhappy. > People contribute for fun, for social reasons and because they have to > (like because they are paied for it) What if these "objections" make everyone else unhappy and have no fun anymore, because there is no good technical reason behind them, just personal preference (in an area where the objecting developer is not a maintainer)? We have had such cases before, endless arguments on the ML and in the end the majority of developers was just annoyed and eventually dropped it because it was too much effort (and the objecting party also not constructively providing an alternative) Unless there is a clear and documented technical reason for an objection (in which case one would hope the issue solves itself anyway), a majority should be able to move forward, and not just get annoyed and frustrated when submitting improvements. > > a proposal that makes contributions less fun is a bad proposal as it > will result in fewer contributions. > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Opposition brings concord. Out of discord comes the fairest harmony. > -- Heraclitus > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http:
Re: [FFmpeg-devel] IRC meeting on Saturday 2015-09-12, UTC 15:00
Hi, On Sat, Sep 12, 2015 at 9:39 AM, Hendrik Leppkes wrote: > On Sat, Sep 12, 2015 at 3:24 PM, Michael Niedermayer > wrote: > > On Sat, Sep 12, 2015 at 06:50:50AM -0400, Ronald S. Bultje wrote: > >> Hi, > >> > >> On Sat, Sep 12, 2015 at 4:21 AM, Yayoi Ukai > wrote: > >> > >> > On Thu, Sep 10, 2015 at 10:46 AM, Michael Niedermayer < > michae...@gmx.at> > >> > wrote: > >> > > On Mon, Sep 07, 2015 at 11:37:47AM +0200, Stefano Sabatini wrote: > >> > >> Hi, > >> > >> > >> > >> I propose to have an official IRC meeting on the next Saturday, > and I > >> > >> propose the tentative time of 15:00 UTC, but feel free to propose a > >> > >> different time if this can't suit you. > >> > >> > >> > >> The IRC meeting channel will be public and the log will be > published > >> > >> at the end of the meeting. > >> > >> > >> > >> This meeting is also meant as a preparation for the real-life > meeting > >> > >> that will be held in Paris at the next VDD > >> > >> (http://www.videolan.org/videolan/events/vdd15/) for the FFmpeg > >> > >> developers who will attend it. > >> > >> > >> > >> I propose these topics of the day (suggested by ubitux on IRC): > >> > >> 1. ABI compatibility policy > >> > > > >> > >> 2. general policy decision process > >> > > > >> > > heres a suggestion, maybe useful as input for discussions on > >> > > Saturday ... > >> > > > >> > > FFmpeg used and uses "unanimous consent" in patch reviews > >> > > any person could make a suggestion > >> > > to improve a patch and it has to be taken care of one way or another > >> > > before the patch is ok. This system worked quite well almost all the > >> > > time. So i would suggest to use the same / a similar system for > >> > > policy decisions > >> > > > >> > > * Everyone should be able to comment and propose options/choices > >> > > * There should be enough time to understand, discuss and amend > >> > > proposals > >> > > * People should try to understand the other people and avoid > strawman > >> > > arguments and other non constructive discussion tactics, > people/the > >> > > commuity should step in if discussions become non constructive and > >> > > hostile and try to get people back toward constructive discussion. > >> > > * People should be able to declare reservations to a proposal > without > >> > > blocking the proposal and as a seperate choice veto it in a > blocking > >> > > fashion. A veto should be public with full name of the developer, > >> > > reason why it is bad for the community/project and ideally a > >> > > alternative proposal. Also developers vetoing a proposal must be > >> > > willing and able to work on finding an better solution. > >> > > >> > So you can add a deadline for the alternate proposal. For example, > >> > if the person who vetoed doesn't come up with an alternate proposal > >> > within 30 days, > >> > the original proposal must be passed. > >> > >> > >> It means everyone can slow a proposal by 30 days. > >> > > > >> Why do we need vetos? > > > > let me awnser a different question first > > Why do we need developers/contributors? > > to write and maintain code amongth many other reasons > > > > If we depend on these developers/contributors then IMO we should take > > their oppinons and objections serious and if one of them is willing > > to risk her/his good name to oppose a proposal in public and maybe also > > plans to put signifiant time into creating a better compromise proposal > > then i belive this is something that should not just be brushed away > > easily, and especially not "quick quick" while > > everyones minds are maybe heated about some debate > > > > vetos would be one way to achive this > > iam not saying that we absolutely need vetos but i think that we > > should not pass proposals that would cause any one developer to leave > > the project or to make people be seriously unhappy. > > People contribute for fun, for social reasons and because they have to > > (like because they are paied for it) > > What if these "objections" make everyone else unhappy and have no fun > anymore, because there is no good technical reason behind them, just > personal preference (in an area where the objecting developer is not a > maintainer)? I want to give the specific example of the "leadership" vote that happened just around "The Fork" in early 2011. Suddenly, out of nowhere, a bunch of mplungarians arose that claimed (and received!) voting rights and helped "The Fork" arise (I'm sure that was not their intention, but it was the consequence nonetheless). Now just imagine for a second that in addition to voting rights, we gave each developer (including mplungarians) veto rights. This is outrageous. To solve this problem, veto rights should, if they exist at all, be restricted to some of the most valuable developers by whatever metric, and be strictly limited in number (e.g. no more than 2-3 people can have veto rights at all). Since that will cause unease for #4/#5, the obvious alternative would be to
Re: [FFmpeg-devel] IRC meeting on Saturday 2015-09-12, UTC 15:00
Le sextidi 26 fructidor, an CCXXIII, Michael Niedermayer a écrit : > If we depend on these developers/contributors then IMO we should take > their oppinons and objections serious and if one of them is willing > to risk her/his good name to oppose a proposal in public and maybe also > plans to put signifiant time into creating a better compromise proposal > then i belive this is something that should not just be brushed away > easily, and especially not "quick quick" while > everyones minds are maybe heated about some debate > > vetos would be one way to achive this No, vetoes are not a way to achieve this. Quite the opposite, in fact. Vetoes are weapons. Weapons for diplomacy, but weapons nonetheless. We do not want weapons in the project. Contributors should heed objections to their proposal because it is the correct, polite thing to do. If we can not be polite to each other most of the time, then the project is doomed, vetoes will not help. To say it another way: if we work well together, we do not need vetoes, if we do not work well together, vetoes would make it worse. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc/developer: clarify merge requests
From: Michael Niedermayer
Signed-off-by: Michael Niedermayer
---
doc/developer.texi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/developer.texi b/doc/developer.texi
index b8259e7..a3f2846 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -38,7 +38,7 @@ There are 3 ways by which code gets into ffmpeg.
see @ref{Submitting patches} for details.
@item Directly committing changes to the main tree.
@item Committing changes to a git clone, for example on github.com or
- gitorious.org. And asking us to merge these changes.
+ gitorious.org. And posting a merge request to the ffmpeg-devel mailing
list.
@end itemize
Whichever way, changes should be reviewed by the maintainer of the code
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] IRC meeting on Saturday 2015-09-12, UTC 15:00
On date Monday 2015-09-07 11:37:47 +0200, Stefano Sabatini encoded: > Hi, > > I propose to have an official IRC meeting on the next Saturday, and I > propose the tentative time of 15:00 UTC, but feel free to propose a > different time if this can't suit you. > > The IRC meeting channel will be public and the log will be published > at the end of the meeting. > > This meeting is also meant as a preparation for the real-life meeting > that will be held in Paris at the next VDD > (http://www.videolan.org/videolan/events/vdd15/) for the FFmpeg > developers who will attend it. > > I propose these topics of the day (suggested by ubitux on IRC): > 1. ABI compatibility policy > 2. general policy decision process > 3. VDD15 > 4. Any other business The meeting will start in less than one hour at 15 UTC. To attend the meeting join the #ffmpeg-meeting channel on freenode. Updated topics of the day: 1. ABI compatibility policy 2. general policy decision process 3. VDD15 4. Any other business 5. Outreachy funding for the next round (winter 2015) 6. use of Github/Gitorious for pull requests 7. Any other business *IMPORTANT NOTE*: the meeting channel is public and the log will be published after the meeting. See you soon on IRC. -- FFmpeg = Free and Fast Mysterious Programmable Enlightened Geisha ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer: clarify merge requests
On date Saturday 2015-09-12 15:56:34 +0200, Michael Niedermayer encoded:
> From: Michael Niedermayer
>
> Signed-off-by: Michael Niedermayer
> ---
> doc/developer.texi |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index b8259e7..a3f2846 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -38,7 +38,7 @@ There are 3 ways by which code gets into ffmpeg.
>see @ref{Submitting patches} for details.
> @item Directly committing changes to the main tree.
> @item Committing changes to a git clone, for example on github.com or
> - gitorious.org. And asking us to merge these changes.
> + gitorious.org. And posting a merge request to the ffmpeg-devel mailing
> list.
> @end itemize
LGTM, thanks.
--
FFmpeg = Formidable and Faithless Mythic Peaceful Eager Geisha
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer: clarify merge requests
Le sextidi 26 fructidor, an CCXXIII, Michael Niedermayer a écrit : > + gitorious.org. And posting a merge request to the ffmpeg-devel mailing > list. Please no. The patches themselves need to go to the mailing list. If these tools can not do that, then they are not usable for this project. (Also, gitorious is dead.) 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] doc/developer: clarify merge requests
On date Saturday 2015-09-12 16:27:56 +0200, Nicolas George encoded: > Le sextidi 26 fructidor, an CCXXIII, Michael Niedermayer a écrit : > > + gitorious.org. And posting a merge request to the ffmpeg-devel > > mailing list. > > Please no. The patches themselves need to go to the mailing list. If these > tools can not do that, then they are not usable for this project. > > (Also, gitorious is dead.) Sorry to split the hair, this is just asking to use the mailing-list rather than generically "ask" (for example using the github tools). Wheter we should adopt pull-request or not is a different matter. -- FFmpeg = Fanciful & Formidable Miracolous Ponderous Efficient Gnome ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer: clarify merge requests
On Sat, Sep 12, 2015 at 10:50 AM, Stefano Sabatini wrote: > On date Saturday 2015-09-12 16:27:56 +0200, Nicolas George encoded: >> Le sextidi 26 fructidor, an CCXXIII, Michael Niedermayer a écrit : >> > + gitorious.org. And posting a merge request to the ffmpeg-devel >> > mailing list. >> >> Please no. The patches themselves need to go to the mailing list. If these >> tools can not do that, then they are not usable for this project. >> >> (Also, gitorious is dead.) > > Sorry to split the hair, this is just asking to use the mailing-list > rather than generically "ask" (for example using the github tools). > > Wheter we should adopt pull-request or not is a different matter. True enough. However, I think this should be squashed with whatever other changes or clarifications we have regarding policy on pull requests/github: together they represent one functional change. > -- > FFmpeg = Fanciful & Formidable Miracolous Ponderous Efficient Gnome > ___ > 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]lavf/img2dec: Improve jpeg detection
Michael Niedermayer gmx.at> writes: > > img2dec.c | 26 -- > > 1 file changed, 20 insertions(+), 6 deletions(-) > > 322ea95b4166f9aa6a8a2d10366b665c933ab162 patchimg2mjpeg.diff > > diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c > > LGTM Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: Switch bitrate to 64bit with the bump
Hi!
Attached is a new patch that should be ready to be applied no matter if we
drop compatibility or not.
Please comment (quickly if possible), Carl Eugen
diff --git a/doc/APIchanges b/doc/APIchanges
index 958035c..415463a 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2015-08-28
API changes, most recent first:
+2015-xx-xx -
+ bit_rate/rc_max_rate/rc_min_rate where changed to 64bit, make sure you update
+ any printf() or other type sensitive code
+
2015-xx-xx - lavu 55.0.100 / lavu 55.0.0
xxx - Change type of AVPixFmtDescriptor.flags from uint8_t to uint64_t.
xxx - Change type of AVComponentDescriptor fields from uint16_t to int
diff --git a/ffserver.c b/ffserver.c
index 8b6e441..e031ec1 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -1789,7 +1789,7 @@ static inline void print_stream_params(AVIOContext *pb,
FFServerStream *stream)
avio_printf(pb, "%d%s%d"
"%s%s\n",
-i, type, st->codec->bit_rate/1000,
+i, type, (int64_t)st->codec->bit_rate/1000,
codec ? codec->name : "", parameters);
}
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index a5faff5..545f8f4 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1530,7 +1530,11 @@ typedef struct AVCodecContext {
* - decoding: Set by user, may be overwritten by libavcodec
* if this info is available in the stream
*/
+#if AV_HAVE_INCOMPATIBLE_LIBAV_ABI
int bit_rate;
+#else
+int64_t bit_rate;
+#endif
/**
* number of bits the bitstream is allowed to diverge from the reference.
@@ -2461,14 +2465,22 @@ typedef struct AVCodecContext {
* - encoding: Set by user.
* - decoding: Set by user, may be overwritten by libavcodec.
*/
+#if AV_HAVE_INCOMPATIBLE_LIBAV_ABI
int rc_max_rate;
+#else
+int64_t rc_max_rate;
+#endif
/**
* minimum bitrate
* - encoding: Set by user.
* - decoding: unused
*/
+#if AV_HAVE_INCOMPATIBLE_LIBAV_ABI
int rc_min_rate;
+#else
+int64_t rc_min_rate;
+#endif
#if FF_API_MPV_OPT
/**
diff --git a/libavcodec/dcaenc.c b/libavcodec/dcaenc.c
index 23587a7..79da8f4 100644
--- a/libavcodec/dcaenc.c
+++ b/libavcodec/dcaenc.c
@@ -145,7 +145,7 @@ static int encode_init(AVCodecContext *avctx)
c->samplerate_index = i;
if (avctx->bit_rate < 32000 || avctx->bit_rate > 384) {
-av_log(avctx, AV_LOG_ERROR, "Bit rate %i not supported.",
avctx->bit_rate);
+av_log(avctx, AV_LOG_ERROR, "Bit rate %"PRId64" not supported.",
(int64_t)avctx->bit_rate);
return AVERROR(EINVAL);
}
for (i = 0; ff_dca_bit_rates[i] < avctx->bit_rate; i++)
diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
index 5df0c90..98a817b 100644
--- a/libavcodec/libfdk-aacenc.c
+++ b/libavcodec/libfdk-aacenc.c
@@ -215,8 +215,8 @@ static av_cold int aac_encode_init(AVCodecContext *avctx)
}
if ((err = aacEncoder_SetParam(s->handle, AACENC_BITRATE,
avctx->bit_rate)) != AACENC_OK) {
-av_log(avctx, AV_LOG_ERROR, "Unable to set the bitrate %d: %s\n",
- avctx->bit_rate, aac_get_error(err));
+av_log(avctx, AV_LOG_ERROR, "Unable to set the bitrate %"PRId64":
%s\n",
+ (int64_t)avctx->bit_rate, aac_get_error(err));
goto error;
}
}
diff --git a/libavcodec/libgsmenc.c b/libavcodec/libgsmenc.c
index 45fdb8e..69ce439 100644
--- a/libavcodec/libgsmenc.c
+++ b/libavcodec/libgsmenc.c
@@ -62,8 +62,8 @@ static av_cold int libgsm_encode_init(AVCodecContext *avctx) {
if (avctx->bit_rate != 13000 /* Official */ &&
avctx->bit_rate != 13200 /* Very common */ &&
avctx->bit_rate != 0 /* Unknown; a.o. mov does not set bitrate when
decoding */ ) {
-av_log(avctx, AV_LOG_ERROR, "Bitrate 13000bps required for GSM, got
%dbps\n",
- avctx->bit_rate);
+av_log(avctx, AV_LOG_ERROR, "Bitrate 13000bps required for GSM, got
%"PRId64"bps\n",
+ (int64_t)avctx->bit_rate);
if (avctx->strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL)
return -1;
}
diff --git a/libavcodec/libopusenc.c b/libavcodec/libopusenc.c
index a170b71..8ac02f9 100644
--- a/libavcodec/libopusenc.c
+++ b/libavcodec/libopusenc.c
@@ -180,12 +180,12 @@ static av_cold int libopus_encode_init(AVCodecContext
*avctx)
avctx->bit_rate = 64000 * opus->stream_count +
32000 * coupled_stream_count;
av_log(avctx, AV_LOG_WARNING,
- "No bit rate set. Defaulting to %d bps.\n", avctx->bit_rate);
+ "No bit rate set. Defaulting to %"PRId64" bps.\n",
(int64_t)avctx->bit_rate);
}
if (avctx->bit_rate < 500 || avctx->bit_rate > 256000 * avctx->channels) {
-av_log(avctx, AV_LOG_ERROR, "The bit rate %d bps is
Re: [FFmpeg-devel] IRC meeting on Saturday 2015-09-12, UTC 15:00
On date Saturday 2015-09-12 16:13:53 +0200, Stefano Sabatini encoded: > On date Monday 2015-09-07 11:37:47 +0200, Stefano Sabatini encoded: > > Hi, > > > > I propose to have an official IRC meeting on the next Saturday, and I > > propose the tentative time of 15:00 UTC, but feel free to propose a > > different time if this can't suit you. > > > > The IRC meeting channel will be public and the log will be published > > at the end of the meeting. > > > > This meeting is also meant as a preparation for the real-life meeting > > that will be held in Paris at the next VDD > > (http://www.videolan.org/videolan/events/vdd15/) for the FFmpeg > > developers who will attend it. [...] > The meeting will start in less than one hour at 15 UTC. > > To attend the meeting join the #ffmpeg-meeting channel on freenode. > > Updated topics of the day: > 1. ABI compatibility policy > 2. general policy decision process > 3. VDD15 > 4. Any other business > 5. Outreachy funding for the next round (winter 2015) > 6. use of Github/Gitorious for pull requests > 7. Any other business > > *IMPORTANT NOTE*: the meeting channel is public and the log will be > published after the meeting. IRC meeting log is in attachment. Thanks all for attending the meeting. -- FFmpeg = Frenzy and Fierce Multimedia Programmable Elegant Gospel FFmpeg IRC meeting on Saturday 2015-09-12, 15 UTC Topics of the day: 1. ABI compatibility policy 2. general policy decision process 3. VDD15 4. Outreachy funding for the next round (winter 2015) 5. use of Github/Gitorious for pull requests 6. Any other business Sep 12 17:00:59 allright time to go Sep 12 17:01:18 i summoned this meeting to discuss some relevant topics Sep 12 17:01:27 * Shiz (~s...@hydrogenium.shiz.me) has joined #ffmpeg-meeting Sep 12 17:01:49 this is also meant as a sort of preparatory meeting for the real-life meeting which will be held in paris the next weekend Sep 12 17:02:07 you can see in the topics the pastebin containing the topics of the day to discuss Sep 12 17:02:22 http://pastebin.com/e6Q0pY6Z Sep 12 17:02:29 first topic is Sep 12 17:02:41 ABI compatibility policy Sep 12 17:03:25 please note that i just compiled the list of topics but i'm not very involved with ffmpeg development, so don't expect me to chat a lot about the merit of each topic Sep 12 17:03:32so are we going to just do a vote on that? or do you want to re-discuss it also? Sep 12 17:03:50 wasn't wm4 the person who proposed it in the first place? where is he? Sep 12 17:03:54 I don't know, maybe someone can spend a few words describing the proposed options Sep 12 17:04:02(there was a long … “discussion” :) … on the mailinglist already on the abi compat subject, and it’s fair to say that we disagreed) Sep 12 17:04:13 well the options are pretty simple, do or don't Sep 12 17:04:23 then we can delay the voting to any other means, not necessarily we have to decide/vote right now Sep 12 17:04:39 nevcairiel: indeed, that is the root alternative; there are a few subquestions after this is decided. Sep 12 17:04:50 atomnuker: wm4 kind of ragequited irc because it wasn't going fast enough apparently; try to /invite him Sep 12 17:05:06 do we spent effort to maintain the ABI compat, which in itself is not and cannot really be fully tested due to mis-matching behavior, or well, do we simply not Sep 12 17:05:13 I'll ping him on ffmpeg-devel, that should get his attention Sep 12 17:05:50 we probably need to agree about how we "advertise" the policy Sep 12 17:06:02 be it a news, or a dedicated pages to "current goals" Sep 12 17:06:18 just to ease taking decisions and keeping up with them Sep 12 17:06:23so the discussion was more about how it was advertised or “how the patch was concealing its purpose”, right? Sep 12 17:07:12 * Easyfab (~chatzi...@ip-62-241-112-16.evc.net) has joined #ffmpeg-meeting Sep 12 17:07:21 * Easyfab (~chatzi...@ip-62-241-112-16.evc.net) has left #ffmpeg-meeting Sep 12 17:07:23 BBB: from my PoV, right; I have mixed opinions on the decision itself. Sep 12 17:07:31who was actually advocating _for_ keeping the abi compat options (as opposed to the discussion around it being concealed)? Sep 12 17:07:47 I don't think anyone was directly for keeping it Sep 12 17:07:48 * Easyfab (~chatzi...@ip-62-241-112-16.evc.net) has joined #ffmpeg-meeting Sep 12 17:08:18 The discussion mostly went in circles around the policy issue Sep 12 17:08:24 * llogan2 (lou@2600:3c01::f03c:91ff:fe70:2ed2) has joined #ffmpeg-meeting Sep 12 17:08:50right, I’m re-reading it now Sep 12 17:09:14carl eugen and nicolas george didn’t like us removing it without an explicit, dedicated discussion that allows us to decide whether we want to change policy on abi compat or not Sep 12 17:09:17so … Sep 12 17:09:36cehoyos isn’t here, is he? Sep 12 17:09:45 dont think so Sep 12
[FFmpeg-devel] [PATCH]Bump probesize and analyzeduration to 64bit (again)
Hi!
Attached patch implements making probesize and analyzeduration 64bit
unless api compatibility was requested.
I will add a line to doc/APIchanges and do a minor version bump.
Please review, this cannot wait, Carl Eugen
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index b7f18c1..26c2464 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1391,7 +1391,7 @@ typedef struct AVFormatContext {
#define AVFMT_FLAG_KEEP_SIDE_DATA 0x4 ///< Don't merge side data but keep
it separate.
#define AVFMT_FLAG_FAST_SEEK 0x8 ///< Enable fast, but inaccurate seeks
for some formats
-#if FF_API_PROBESIZE_32
+#if AV_HAVE_INCOMPATIBLE_LIBAV_ABI
/**
* @deprecated deprecated in favor of probesize2
*/
@@ -1755,7 +1755,7 @@ typedef struct AVFormatContext {
* via AVOptions (NO direct access).
* Can be set to 0 to let avformat choose using a heuristic.
*/
-#if FF_API_PROBESIZE_32
+#if AV_HAVE_INCOMPATIBLE_LIBAV_ABI
int64_t max_analyze_duration2;
#else
int64_t max_analyze_duration;
@@ -1767,7 +1767,7 @@ typedef struct AVFormatContext {
* Demuxing only, set by the caller before avformat_open_input()
* via AVOptions (NO direct access).
*/
-#if FF_API_PROBESIZE_32
+#if AV_HAVE_INCOMPATIBLE_LIBAV_ABI
int64_t probesize2;
#else
int64_t probesize;
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index ed0a86b..c35cc9d 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2513,7 +2513,7 @@ static int mpegts_read_header(AVFormatContext *s)
uint8_t buf[8 * 1024] = {0};
int len;
int64_t pos, probesize =
-#if FF_API_PROBESIZE_32
+#if AV_HAVE_INCOMPATIBLE_LIBAV_ABI
s->probesize ? s->probesize : s->probesize2;
#else
s->probesize;
diff --git a/libavformat/options_table.h b/libavformat/options_table.h
index 773814a..6e66c27 100644
--- a/libavformat/options_table.h
+++ b/libavformat/options_table.h
@@ -36,7 +36,7 @@
static const AVOption avformat_options[] = {
{"avioflags", NULL, OFFSET(avio_flags), AV_OPT_TYPE_FLAGS, {.i64 = DEFAULT },
INT_MIN, INT_MAX, D|E, "avioflags"},
{"direct", "reduce buffering", 0, AV_OPT_TYPE_CONST, {.i64 = AVIO_FLAG_DIRECT
}, INT_MIN, INT_MAX, D|E, "avioflags"},
-#if FF_API_PROBESIZE_32
+#if AV_HAVE_INCOMPATIBLE_LIBAV_ABI
{"probesize", "set probing size", OFFSET(probesize2), AV_OPT_TYPE_INT64, {.i64
= 500 }, 32, INT64_MAX, D},
#else
{"probesize", "set probing size", OFFSET(probesize), AV_OPT_TYPE_INT64, {.i64
= 500 }, 32, INT64_MAX, D},
@@ -58,7 +58,7 @@ static const AVOption avformat_options[] = {
{"nobuffer", "reduce the latency introduced by optional buffering", 0,
AV_OPT_TYPE_CONST, {.i64 = AVFMT_FLAG_NOBUFFER }, 0, INT_MAX, D, "fflags"},
{"seek2any", "allow seeking to non-keyframes on demuxer level when supported",
OFFSET(seek2any), AV_OPT_TYPE_INT, {.i64 = 0 }, 0, 1, D},
{"bitexact", "do not write random/volatile data", 0, AV_OPT_TYPE_CONST, { .i64
= AVFMT_FLAG_BITEXACT }, 0, 0, E, "fflags" },
-#if FF_API_PROBESIZE_32
+#if AV_HAVE_INCOMPATIBLE_LIBAV_ABI
{"analyzeduration", "specify how many microseconds are analyzed to probe the
input", OFFSET(max_analyze_duration2), AV_OPT_TYPE_INT64, {.i64 = 0 }, 0,
INT64_MAX, D},
#else
{"analyzeduration", "specify how many microseconds are analyzed to probe the
input", OFFSET(max_analyze_duration), AV_OPT_TYPE_INT64, {.i64 = 0 }, 0,
INT64_MAX, D},
diff --git a/libavformat/utils.c b/libavformat/utils.c
index db988c0..e5729a7 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3085,14 +3085,14 @@ int avformat_find_stream_info(AVFormatContext *ic,
AVDictionary **options)
// new streams might appear, no options for those
int orig_nb_streams = ic->nb_streams;
int flush_codecs;
-#if FF_API_PROBESIZE_32
+#if AV_HAVE_INCOMPATIBLE_LIBAV_ABI
int64_t max_analyze_duration = ic->max_analyze_duration2;
#else
int64_t max_analyze_duration = ic->max_analyze_duration;
#endif
int64_t max_stream_analyze_duration;
int64_t max_subtitle_analyze_duration;
-#if FF_API_PROBESIZE_32
+#if AV_HAVE_INCOMPATIBLE_LIBAV_ABI
int64_t probesize = ic->probesize2;
#else
int64_t probesize = ic->probesize;
diff --git a/libavformat/version.h b/libavformat/version.h
index 18be8b2..1e26f9c 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -65,9 +65,6 @@
#ifndef FF_API_URL_FEOF
#define FF_API_URL_FEOF (LIBAVFORMAT_VERSION_MAJOR < 58)
#endif
-#ifndef FF_API_PROBESIZE_32
-#define FF_API_PROBESIZE_32 (LIBAVFORMAT_VERSION_MAJOR < 58)
-#endif
#ifndef FF_API_R_FRAME_RATE
#define FF_API_R_FRAME_RATE1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposed patches to mpjpeg demux
Michael, thanks! Is the other change (mpjpegdec.c) still in review, or had it been overlooked due to not being included in the amended patch? -Best. - Alex -- Alex Agranovsky Sighthound, Inc www.sighthound.com On September 11, 2015 at 6:43:31 PM, Michael Niedermayer (michae...@gmx.at) wrote: On Thu, Sep 10, 2015 at 05:23:09PM -0400, Alex Agranovsky wrote: > Quick update: format.c patch needs to be amended, to include a NULL check. > > > > -- > Alex Agranovsky > Sighthound, Inc > www.sighthound.com > > On September 10, 2015 at 12:04:55 PM, Alex Agranovsky (a...@sighthound.com) > wrote: > > Please look at the attached patches. They accomplish the following: > > 1) change to format.c: allows the demux to be matched by Content-Type, even > if the incoming Content-Type header contains parameters, such as > 'multipart/x-mixed-replace;boundary=ffserver’. Currently the comparison seems > to occur verbatim, thus preventing the selection of mpjpegdec demux, even > when running against MJPEG served by ffserver. > P.S. I’m not sure if parameters are ever needed to be included for this > comparison, but considering we’re dealing with probing, seems unlikely applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes ___ 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]Bump probesize and analyzeduration to 64bit (again)
On Sat, Sep 12, 2015 at 08:04:34PM +0200, Carl Eugen Hoyos wrote: > Hi! > > Attached patch implements making probesize and analyzeduration 64bit > unless api compatibility was requested. > > I will add a line to doc/APIchanges and do a minor version bump. > > Please review, this cannot wait, Carl Eugen > avformat.h |6 +++--- > mpegts.c|2 +- > options_table.h |4 ++-- > utils.c |4 ++-- > version.h |3 --- > 5 files changed, 8 insertions(+), 11 deletions(-) > 6e597c93aee2ba3fe7c804e1a2b1916c302d8ba6 patchprobesize64.diff should be ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 "Rare item" - "Common item with rare defect or maybe just a lie" "Professional" - "'Toy' made in china, not functional except as doorstop" "Experts will know" - "The seller hopes you are not an expert" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Bump probesize and analyzeduration to 64bit (again)
On 9/12/2015 3:04 PM, Carl Eugen Hoyos wrote: > Hi! > > Attached patch implements making probesize and analyzeduration 64bit > unless api compatibility was requested. > > I will add a line to doc/APIchanges and do a minor version bump. > > Please review, this cannot wait, Carl Eugen You're removing probesize2 and max_analyze_duration2, which supposedly were added to replace the deprecated probesize and max_analyze_duration fields, all while undeprecating the latter in the meantime. The FF_API_PROBESIZE_32 wrapper is faulty as well to begin with. It's scheduling the removal of probesize2 and max_analyze_duration2, which are supposedly the non-deprecated replacements. This all seems like a weird change. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] "configure" breaks on MSYS2 MINGW64
On Sat, Sep 12, 2015 at 10:57:37PM +1000, Matt Oliver wrote: > On 12 September 2015 at 19:40, Peter Belkner wrote: > > > On 12.09.2015 11:15, Geek.Song wrote: > > > >> diff -u > > > > > LGTM. > I had an identical patch ready to fix the same problem so this one is fine. i think you dont have git write access ? if not, then send me your public ssh key [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Bump probesize and analyzeduration to 64bit (again)
On Sat, Sep 12, 2015 at 03:25:05PM -0300, James Almer wrote: > On 9/12/2015 3:04 PM, Carl Eugen Hoyos wrote: > > Hi! > > > > Attached patch implements making probesize and analyzeduration 64bit > > unless api compatibility was requested. > > > > I will add a line to doc/APIchanges and do a minor version bump. > > > > Please review, this cannot wait, Carl Eugen > > You're removing probesize2 and max_analyze_duration2, which supposedly > were added to replace the deprecated probesize and max_analyze_duration > fields, all while undeprecating the latter in the meantime. > The FF_API_PROBESIZE_32 wrapper is faulty as well to begin with. It's > scheduling the removal of probesize2 and max_analyze_duration2, which > are supposedly the non-deprecated replacements. probesize2 and max_analyze_duration2 are documented as "NO direct access" so API wise these 2 fields should be fine to remove from the struct [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ADPCM: Bump THP channel limit to 14
On 9/11/15, Paul B Mahol wrote:
> On 9/11/15, Rodger Combs wrote:
>> ---
>> libavcodec/adpcm.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
>> index 52d0d44..ba38041 100644
>> --- a/libavcodec/adpcm.c
>> +++ b/libavcodec/adpcm.c
>> @@ -84,7 +84,7 @@ static const int swf_index_tables[4][16] = {
>> /* end of tables */
>>
>> typedef struct ADPCMDecodeContext {
>> -ADPCMChannelStatus status[10];
>> +ADPCMChannelStatus status[14];
>> int vqa_version;/**< VQA version. Used for
>> ADPCM_IMA_WS
>> */
>> int has_status;
>> } ADPCMDecodeContext;
>> @@ -109,7 +109,7 @@ static av_cold int adpcm_decode_init(AVCodecContext *
>> avctx)
>> break;
>> case AV_CODEC_ID_ADPCM_THP:
>> case AV_CODEC_ID_ADPCM_THP_LE:
>> -max_channels = 10;
>> +max_channels = 14;
>> break;
>> }
>> if (avctx->channels < min_channels || avctx->channels > max_channels)
>> {
>> @@ -1431,7 +1431,7 @@ static int adpcm_decode_frame(AVCodecContext
>> *avctx,
>> void *data,
>> case AV_CODEC_ID_ADPCM_THP:
>> case AV_CODEC_ID_ADPCM_THP_LE:
>> {
>> -int table[10][16];
>> +int table[14][16];
>
> Perhaps this should be moved to private context and nb of channels
> raised to 64
Anyway patch should be good as is.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Bump probesize and analyzeduration to 64bit (again)
On 9/12/2015 3:28 PM, Michael Niedermayer wrote: > On Sat, Sep 12, 2015 at 03:25:05PM -0300, James Almer wrote: >> On 9/12/2015 3:04 PM, Carl Eugen Hoyos wrote: >>> Hi! >>> >>> Attached patch implements making probesize and analyzeduration 64bit >>> unless api compatibility was requested. >>> >>> I will add a line to doc/APIchanges and do a minor version bump. >>> >>> Please review, this cannot wait, Carl Eugen >> >> You're removing probesize2 and max_analyze_duration2, which supposedly >> were added to replace the deprecated probesize and max_analyze_duration >> fields, all while undeprecating the latter in the meantime. >> The FF_API_PROBESIZE_32 wrapper is faulty as well to begin with. It's >> scheduling the removal of probesize2 and max_analyze_duration2, which >> are supposedly the non-deprecated replacements. > > probesize2 and max_analyze_duration2 are documented as > "NO direct access" > so API wise these 2 fields should be fine to remove from the struct "NO direct access" will now apply to the new max_analyze_duration and probesize fields when incompatible-libav-abi is not used. Is that intended? If so then it should be ok. We could also wait for the final decision about abi compatibility and just make this change without the AV_HAVE_INCOMPATIBLE_LIBAV_ABI check, but that can be removed in a different commit as well i guess. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposed patches to mpjpeg demux
On Sat, Sep 12, 2015 at 02:06:28PM -0400, Alex Agranovsky wrote: > Michael, thanks! > > Is the other change (mpjpegdec.c) still in review, or had it been overlooked > due to not being included in the amended patch? i didnt overlook them but they include several changes that could be argued to be independant so they need to be split into seperate patches / commits. can you do that split ? thanks > > -Best. > - Alex > > -- > Alex Agranovsky > Sighthound, Inc > www.sighthound.com > > On September 11, 2015 at 6:43:31 PM, Michael Niedermayer (michae...@gmx.at) > wrote: > > On Thu, Sep 10, 2015 at 05:23:09PM -0400, Alex Agranovsky wrote: > > Quick update: format.c patch needs to be amended, to include a NULL check. > > > > > > > > -- > > Alex Agranovsky > > Sighthound, Inc > > www.sighthound.com > > > > On September 10, 2015 at 12:04:55 PM, Alex Agranovsky (a...@sighthound.com) > > wrote: > > > > Please look at the attached patches. They accomplish the following: > > > > > 1) change to format.c: allows the demux to be matched by Content-Type, even > > if the incoming Content-Type header contains parameters, such as > > 'multipart/x-mixed-replace;boundary=ffserver’. Currently the comparison > > seems to occur verbatim, thus preventing the selection of mpjpegdec demux, > > even when running against MJPEG served by ffserver. > > P.S. I’m not sure if parameters are ever needed to be included for this > > comparison, but considering we’re dealing with probing, seems unlikely > > applied > > thanks > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > No human being will ever know the Truth, for even if they happen to say it > by chance, they would not even known they had done so. -- Xenophanes > ___ > 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 -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Bump probesize and analyzeduration to 64bit (again)
On Sat, Sep 12, 2015 at 03:37:08PM -0300, James Almer wrote: > On 9/12/2015 3:28 PM, Michael Niedermayer wrote: > > On Sat, Sep 12, 2015 at 03:25:05PM -0300, James Almer wrote: > >> On 9/12/2015 3:04 PM, Carl Eugen Hoyos wrote: > >>> Hi! > >>> > >>> Attached patch implements making probesize and analyzeduration 64bit > >>> unless api compatibility was requested. > >>> > >>> I will add a line to doc/APIchanges and do a minor version bump. > >>> > >>> Please review, this cannot wait, Carl Eugen > >> > >> You're removing probesize2 and max_analyze_duration2, which supposedly > >> were added to replace the deprecated probesize and max_analyze_duration > >> fields, all while undeprecating the latter in the meantime. > >> The FF_API_PROBESIZE_32 wrapper is faulty as well to begin with. It's > >> scheduling the removal of probesize2 and max_analyze_duration2, which > >> are supposedly the non-deprecated replacements. > > > > probesize2 and max_analyze_duration2 are documented as > > "NO direct access" > > so API wise these 2 fields should be fine to remove from the struct > > "NO direct access" will now apply to the new max_analyze_duration and > probesize fields when incompatible-libav-abi is not used. Is that intended? > If so then it should be ok. > > We could also wait for the final decision about abi compatibility and just > make this change without the AV_HAVE_INCOMPATIBLE_LIBAV_ABI check, but that > can be removed in a different commit as well i guess. I think theres consense about "abi compatibility" so i would tend to suggest to move forward with that in mind. The open points seemed about details IIUC which IMHO should not hold things up, especially as the code after the bump isnt exactly ABI stable atm [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposed patches to mpjpeg demux
Sure thing — will split and resubmit. -- Alex Agranovsky Sighthound, Inc www.sighthound.com On September 12, 2015 at 2:37:52 PM, Michael Niedermayer (michae...@gmx.at) wrote: On Sat, Sep 12, 2015 at 02:06:28PM -0400, Alex Agranovsky wrote: > Michael, thanks! > > Is the other change (mpjpegdec.c) still in review, or had it been overlooked > due to not being included in the amended patch? i didnt overlook them but they include several changes that could be argued to be independant so they need to be split into seperate patches / commits. can you do that split ? thanks > > -Best. > - Alex > > -- > Alex Agranovsky > Sighthound, Inc > www.sighthound.com > > On September 11, 2015 at 6:43:31 PM, Michael Niedermayer (michae...@gmx.at) > wrote: > > On Thu, Sep 10, 2015 at 05:23:09PM -0400, Alex Agranovsky wrote: > > Quick update: format.c patch needs to be amended, to include a NULL check. > > > > > > > > -- > > Alex Agranovsky > > Sighthound, Inc > > www.sighthound.com > > > > On September 10, 2015 at 12:04:55 PM, Alex Agranovsky (a...@sighthound.com) > > wrote: > > > > Please look at the attached patches. They accomplish the following: > > > > > 1) change to format.c: allows the demux to be matched by Content-Type, even > > if the incoming Content-Type header contains parameters, such as > > 'multipart/x-mixed-replace;boundary=ffserver’. Currently the comparison > > seems to occur verbatim, thus preventing the selection of mpjpegdec demux, > > even when running against MJPEG served by ffserver. > > P.S. I’m not sure if parameters are ever needed to be included for this > > comparison, but considering we’re dealing with probing, seems unlikely > > applied > > thanks > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > No human being will ever know the Truth, for even if they happen to say it > by chance, they would not even known they had done so. -- Xenophanes > ___ > 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 -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Bump probesize and analyzeduration to 64bit (again)
On 9/12/2015 3:42 PM, Michael Niedermayer wrote: > I think theres consense about "abi compatibility" so i would tend to > suggest to move forward with that in mind. In that case we should go ahead and don't bother with the AV_HAVE_INCOMPATIBLE_LIBAV_ABI check at all for this change. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Bump probesize and analyzeduration to 64bit (again)
James Almer gmail.com> writes: > "NO direct access" will now apply to the new > max_analyze_duration and probesize fields when > incompatible-libav-abi is not used. Is that > intended? This is how the patch was ok'ed before. I am 100% fine with moving the 64 bit fields, but it is imo unrelated to this patch. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ADPCM: Bump THP channel limit to 14
On Sat, Sep 12, 2015 at 06:36:33PM +, Paul B Mahol wrote:
> On 9/11/15, Paul B Mahol wrote:
> > On 9/11/15, Rodger Combs wrote:
> >> ---
> >> libavcodec/adpcm.c | 6 +++---
> >> 1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
> >> index 52d0d44..ba38041 100644
> >> --- a/libavcodec/adpcm.c
> >> +++ b/libavcodec/adpcm.c
> >> @@ -84,7 +84,7 @@ static const int swf_index_tables[4][16] = {
> >> /* end of tables */
> >>
> >> typedef struct ADPCMDecodeContext {
> >> -ADPCMChannelStatus status[10];
> >> +ADPCMChannelStatus status[14];
> >> int vqa_version;/**< VQA version. Used for
> >> ADPCM_IMA_WS
> >> */
> >> int has_status;
> >> } ADPCMDecodeContext;
> >> @@ -109,7 +109,7 @@ static av_cold int adpcm_decode_init(AVCodecContext *
> >> avctx)
> >> break;
> >> case AV_CODEC_ID_ADPCM_THP:
> >> case AV_CODEC_ID_ADPCM_THP_LE:
> >> -max_channels = 10;
> >> +max_channels = 14;
> >> break;
> >> }
> >> if (avctx->channels < min_channels || avctx->channels > max_channels)
> >> {
> >> @@ -1431,7 +1431,7 @@ static int adpcm_decode_frame(AVCodecContext
> >> *avctx,
> >> void *data,
> >> case AV_CODEC_ID_ADPCM_THP:
> >> case AV_CODEC_ID_ADPCM_THP_LE:
> >> {
> >> -int table[10][16];
> >> +int table[14][16];
> >
> > Perhaps this should be moved to private context and nb of channels
> > raised to 64
>
> Anyway patch should be good as is.
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is what and why we do it that matters, not just one of them.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Allow mpjpeg headers parsing to succeed upon EOF, if required headers are present
libavformat/mpjpegdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c index b8281fc..8413ae7 100644 --- a/libavformat/mpjpegdec.c +++ b/libavformat/mpjpegdec.c @@ -165,7 +165,7 @@ static int parse_multipart_header(AVFormatContext *s) ret = get_line(s->pb, line, sizeof(line)); if (ret < 0) - return ret; + break; if (line[0] == '\0') break; -- Alex Agranovsky Sighthound, Inc www.sighthound.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Coverity Scan access
Just a reminder if an *active developer* wants access to Coverity Scan reports just ask. You can get low volume, occasional emails detailing found defects, and/or access the info via the Coverity Scan site. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] mpjpeg: CRLF terminating a sequence of MIME headers should not cause an error
libavformat/mpjpegdec.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
index 8413ae7..c1ca508 100644
--- a/libavformat/mpjpegdec.c
+++ b/libavformat/mpjpegdec.c
@@ -43,11 +43,22 @@ static int get_line(AVIOContext *pb, char *line, int
line_size)
static int split_tag_value(char **tag, char **value, char *line)
{
char *p = line;
+ int foundData = 0;
- while (*p != '\0' && *p != ':')
+ *tag = NULL;
+ *value = NULL;
+
+
+ while (*p != '\0' && *p != ':') {
+ if (!av_isspace(*p)) {
+ foundData = 1;
+ }
p++;
- if (*p != ':')
- return AVERROR_INVALIDDATA;
+ }
+ if (*p != ':') {
+ /* don't fail the parser if dealing with an empty line */
+ return foundData?AVERROR_INVALIDDATA:0;
+ }
*p = '\0';
*tag = line;
@@ -166,12 +177,15 @@ static int parse_multipart_header(AVFormatContext *s)
ret = get_line(s->pb, line, sizeof(line));
if (ret < 0)
break;
+ /* CRLF terminates a sequence of MIME headers */
+ if (value==NULL || tag==NULL)
+ break;
if (line[0] == '\0')
break;
ret = split_tag_value(&tag, &value, line);
- if (ret < 0)
+ if (ret < 0 || tag == NULL || value == NULL)
return ret;
if (!av_strcasecmp(tag, "Content-type")) {
--
Alex Agranovsky
Sighthound, Inc
www.sighthound.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add stereowiden filter
Signed-off-by: Paul B Mahol
---
libavfilter/Makefile | 1 +
libavfilter/af_stereowiden.c | 167 +++
libavfilter/allfilters.c | 1 +
3 files changed, 169 insertions(+)
create mode 100644 libavfilter/af_stereowiden.c
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index d3e282f..d3f5595 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -79,6 +79,7 @@ OBJS-$(CONFIG_RESAMPLE_FILTER) += af_resample.o
OBJS-$(CONFIG_SIDECHAINCOMPRESS_FILTER) += af_sidechaincompress.o
OBJS-$(CONFIG_SILENCEDETECT_FILTER) += af_silencedetect.o
OBJS-$(CONFIG_SILENCEREMOVE_FILTER) += af_silenceremove.o
+OBJS-$(CONFIG_STEREOWIDEN_FILTER)+= af_stereowiden.o
OBJS-$(CONFIG_TREBLE_FILTER) += af_biquads.o
OBJS-$(CONFIG_VOLUME_FILTER) += af_volume.o
OBJS-$(CONFIG_VOLUMEDETECT_FILTER) += af_volumedetect.o
diff --git a/libavfilter/af_stereowiden.c b/libavfilter/af_stereowiden.c
new file mode 100644
index 000..5ad98c8
--- /dev/null
+++ b/libavfilter/af_stereowiden.c
@@ -0,0 +1,167 @@
+/*
+ * Copyright (C) 2012 VLC authors and VideoLAN
+ * Author : Sukrit Sangwan < sukritsangwan at gmail dot com >
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/channel_layout.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "audio.h"
+#include "formats.h"
+
+typedef struct StereoWidenContext {
+const AVClass *class;
+
+float delay;
+float feedback;
+float crossfeed;
+float drymix;
+
+float *buffer;
+float *write;
+int length;
+} StereoWidenContext;
+
+#define OFFSET(x) offsetof(StereoWidenContext, x)
+#define A AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption stereowiden_options[] = {
+{ "delay", "set delay time",OFFSET(delay), AV_OPT_TYPE_FLOAT,
{.dbl=20}, 0, 9000, A },
+{ "feedback", "set feedback gain", OFFSET(feedback), AV_OPT_TYPE_FLOAT,
{.dbl=.3}, 0, 0.9, A },
+{ "crossfeed", "set cross feed",OFFSET(crossfeed), AV_OPT_TYPE_FLOAT,
{.dbl=.3}, 0, 0.8, A },
+{ "drymix","set dry-mix", OFFSET(drymix),AV_OPT_TYPE_FLOAT,
{.dbl=.8}, 0, 1.0, A },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(stereowiden);
+
+static int query_formats(AVFilterContext *ctx)
+{
+AVFilterFormats *formats = NULL;
+AVFilterChannelLayouts *layout = NULL;
+
+ff_add_format(&formats, AV_SAMPLE_FMT_FLT);
+ff_set_common_formats(ctx, formats);
+ff_add_channel_layout(&layout, AV_CH_LAYOUT_STEREO);
+ff_set_common_channel_layouts(ctx, layout);
+
+formats = ff_all_samplerates();
+if (!formats)
+return AVERROR(ENOMEM);
+return ff_set_common_samplerates(ctx, formats);
+}
+
+static int config_input(AVFilterLink *inlink)
+{
+AVFilterContext *ctx = inlink->dst;
+StereoWidenContext *s = ctx->priv;
+
+s->length = 2 * s->delay * inlink->sample_rate / 1000;
+s->buffer = av_calloc(s->length, sizeof(s->buffer));
+if (!s->buffer)
+return AVERROR(ENOMEM);
+s->write = s->buffer;
+
+return 0;
+}
+
+static int filter_frame(AVFilterLink *inlink, AVFrame *in)
+{
+AVFilterContext *ctx = inlink->dst;
+AVFilterLink *outlink = ctx->outputs[0];
+StereoWidenContext *s = ctx->priv;
+const float *src = (const float *)in->data[0];
+const float drymix = s->drymix;
+const float crossfeed = s->crossfeed;
+const float feedback = s->feedback;
+AVFrame *out = NULL;
+float *dst;
+int n;
+
+if (av_frame_is_writable(in)) {
+out = in;
+} else {
+AVFrame *out = ff_get_audio_buffer(inlink, in->nb_samples);
+if (!out) {
+av_frame_free(&in);
+return AVERROR(ENOMEM);
+}
+av_frame_copy_props(out, in);
+}
+dst = (float *)out->data[0];
+
+for (n = 0; n < in->nb_samples; n++, src += 2, dst += 2) {
+const float left = src[0], right = src[1];
+float *read = s->write + 2;
+
+if (read > s->buffer + s->length)
+read = s->buffer;
+
+dst[0] = drymix * left - crossfeed * right - feedback * read[1];
+dst[1] = drymix * right - crossfeed * left - feedback
Re: [FFmpeg-devel] [PATCH] mpjpeg: CRLF terminating a sequence of MIME headers should not cause an error
Amended: one of the new blocks ended up in a wrong location.
libavformat/mpjpegdec.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
index 8413ae7..1661b9d 100644
--- a/libavformat/mpjpegdec.c
+++ b/libavformat/mpjpegdec.c
@@ -43,11 +43,20 @@ static int get_line(AVIOContext *pb, char *line, int
line_size)
static int split_tag_value(char **tag, char **value, char *line)
{
char *p = line;
+ int foundData = 0;
- while (*p != '\0' && *p != ':')
+ *tag = NULL;
+ *value = NULL;
+
+
+ while (*p != '\0' && *p != ':') {
+ if (!av_isspace(*p)) {
+ foundData = 1;
+ }
p++;
+ }
if (*p != ':')
- return AVERROR_INVALIDDATA;
+ return foundData?AVERROR_INVALIDDATA:0;
*p = '\0';
*tag = line;
@@ -67,7 +76,7 @@ static int check_content_type(char *line)
char *tag, *value;
int ret = split_tag_value(&tag, &value, line);
- if (ret < 0)
+ if (ret < 0 || tag == NULL || value == NULL)
return ret;
if (av_strcasecmp(tag, "Content-type") ||
@@ -173,7 +182,9 @@ static int parse_multipart_header(AVFormatContext *s)
ret = split_tag_value(&tag, &value, line);
if (ret < 0)
return ret;
-
+ if (value==NULL || tag==NULL)
+ break;
+
if (!av_strcasecmp(tag, "Content-type")) {
if (av_strcasecmp(value, "image/jpeg")) {
av_log(s, AV_LOG_ERROR,
--
Alex Agranovsky
Sighthound, Inc
www.sighthound.com
On September 12, 2015 at 4:50:54 PM, Alex Agranovsky (a...@sighthound.com)
wrote:
libavformat/mpjpegdec.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
index 8413ae7..c1ca508 100644
--- a/libavformat/mpjpegdec.c
+++ b/libavformat/mpjpegdec.c
@@ -43,11 +43,22 @@ static int get_line(AVIOContext *pb, char *line, int
line_size)
static int split_tag_value(char **tag, char **value, char *line)
{
char *p = line;
+ int foundData = 0;
- while (*p != '\0' && *p != ':')
+ *tag = NULL;
+ *value = NULL;
+
+
+ while (*p != '\0' && *p != ':') {
+ if (!av_isspace(*p)) {
+ foundData = 1;
+ }
p++;
- if (*p != ':')
- return AVERROR_INVALIDDATA;
+ }
+ if (*p != ':') {
+ /* don't fail the parser if dealing with an empty line */
+ return foundData?AVERROR_INVALIDDATA:0;
+ }
*p = '\0';
*tag = line;
@@ -166,12 +177,15 @@ static int parse_multipart_header(AVFormatContext *s)
ret = get_line(s->pb, line, sizeof(line));
if (ret < 0)
break;
+ /* CRLF terminates a sequence of MIME headers */
+ if (value==NULL || tag==NULL)
+ break;
if (line[0] == '\0')
break;
ret = split_tag_value(&tag, &value, line);
- if (ret < 0)
+ if (ret < 0 || tag == NULL || value == NULL)
return ret;
if (!av_strcasecmp(tag, "Content-type")) {
--
Alex Agranovsky
Sighthound, Inc
www.sighthound.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] mpjpeg: trim header name/value of MIME headers while probing
libavformat/mpjpegdec.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
index 1661b9d..009bbaf 100644
--- a/libavformat/mpjpegdec.c
+++ b/libavformat/mpjpegdec.c
@@ -40,6 +40,19 @@ static int get_line(AVIOContext *pb, char *line, int
line_size)
return 0;
}
+
+static void trim_right(char* p)
+{
+ char* end;
+ if (!p || !*p)
+ return;
+ end=p+strlen(p)-1;
+ while (end!=p && av_isspace(*end)) {
+ *end='\0';
+ end--;
+ }
+}
+
static int split_tag_value(char **tag, char **value, char *line)
{
char *p = line;
@@ -60,6 +73,7 @@ static int split_tag_value(char **tag, char **value, char
*line)
*p = '\0';
*tag = line;
+ trim_right(*tag);
p++;
@@ -67,6 +81,7 @@ static int split_tag_value(char **tag, char **value, char
*line)
p++;
*value = p;
+ trim_right(*value);
return 0;
}
--
Alex Agranovsky
Sighthound, Inc
www.sighthound.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Allow mpjpeg headers parsing to succeed upon EOF, if required headers are present
On Sat, Sep 12, 2015 at 04:33:17PM -0400, Alex Agranovsky wrote: > libavformat/mpjpegdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c > index b8281fc..8413ae7 100644 > --- a/libavformat/mpjpegdec.c > +++ b/libavformat/mpjpegdec.c > @@ -165,7 +165,7 @@ static int parse_multipart_header(AVFormatContext *s) > > ret = get_line(s->pb, line, sizeof(line)); > if (ret < 0) > - return ret; > + break; Applying: Allow mpjpeg headers parsing to succeed upon EOF, if required headers are present fatal: corrupt patch at line 7 also for strict correctness this should probably only break for AVERROR_EOF [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpjpeg: trim header name/value of MIME headers while probing
On Sat, Sep 12, 2015 at 05:10:06PM -0400, Alex Agranovsky wrote: > libavformat/mpjpegdec.c | 15 +++ > 1 file changed, 15 insertions(+) patching file libavformat/mpjpegdec.c patch: malformed patch at line 6: return 0; it seems the patches have been corrupted somewhere in the mail processing, can you send the as attachment ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpjpeg: CRLF terminating a sequence of MIME headers should not cause an error
On Sat, Sep 12, 2015 at 05:05:04PM -0400, Alex Agranovsky wrote:
> Amended: one of the new blocks ended up in a wrong location.
>
> libavformat/mpjpegdec.c | 19 +++
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
> index 8413ae7..1661b9d 100644
> --- a/libavformat/mpjpegdec.c
> +++ b/libavformat/mpjpegdec.c
> @@ -43,11 +43,20 @@ static int get_line(AVIOContext *pb, char *line, int
> line_size)
> static int split_tag_value(char **tag, char **value, char *line)
> {
> char *p = line;
> + int foundData = 0;
>
> - while (*p != '\0' && *p != ':')
> + *tag = NULL;
> + *value = NULL;
> +
> +
> + while (*p != '\0' && *p != ':') {
> + if (!av_isspace(*p)) {
> + foundData = 1;
> + }
> p++;
> + }
> if (*p != ':')
> - return AVERROR_INVALIDDATA;
> + return foundData?AVERROR_INVALIDDATA:0;
>
> *p = '\0';
> *tag = line;
> @@ -67,7 +76,7 @@ static int check_content_type(char *line)
> char *tag, *value;
> int ret = split_tag_value(&tag, &value, line);
>
> - if (ret < 0)
> + if (ret < 0 || tag == NULL || value == NULL)
> return ret;
doesnt this result in a probe score of AVPROBE_SCORE_MAX for an
empty line, or am i misreading the code ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: Switch bitrate to 64bit with the bump
On Sat, Sep 12, 2015 at 07:52:42PM +0200, Carl Eugen Hoyos wrote: > Hi! > > Attached is a new patch that should be ready to be applied no matter if we > drop compatibility or not. > > Please comment (quickly if possible), Carl Eugen i think there are a few changes missing: libavcodec/cook.c: In function ‘dump_cook_context’: libavcodec/cook.c:1031:5: warning: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘int64_t’ [-Wformat] libavdevice/fbdev_dec.c: In function ‘fbdev_read_header’: libavdevice/fbdev_dec.c:143:12: warning: format ‘%d’ expects argument of type ‘int’, but argument 10 has type ‘int64_t’ [-Wformat] ffserver.c: In function ‘print_stream_params’: ffserver.c:1793:21: warning: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘int64_t’ [-Wformat] the entries in libavcodec/options_table.h need updating as well [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Allow mpjpeg headers parsing to succeed upon EOF, if required headers are present
Modified patch is attached. -- Alex Agranovsky Sighthound, Inc www.sighthound.com On September 12, 2015 at 5:37:51 PM, Michael Niedermayer (michae...@gmx.at) wrote: On Sat, Sep 12, 2015 at 04:33:17PM -0400, Alex Agranovsky wrote: > libavformat/mpjpegdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c > index b8281fc..8413ae7 100644 > --- a/libavformat/mpjpegdec.c > +++ b/libavformat/mpjpegdec.c > @@ -165,7 +165,7 @@ static int parse_multipart_header(AVFormatContext *s) > > ret = get_line(s->pb, line, sizeof(line)); > if (ret < 0) > - return ret; > + break; Applying: Allow mpjpeg headers parsing to succeed upon EOF, if required headers are present fatal: corrupt patch at line 7 also for strict correctness this should probably only break for AVERROR_EOF [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel patch1.diff Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpjpeg: CRLF terminating a sequence of MIME headers should not cause an error
You’re correct, sir. New patch is attached.
--
Alex Agranovsky
Sighthound, Inc
www.sighthound.com
On September 12, 2015 at 5:54:23 PM, Michael Niedermayer (michae...@gmx.at)
wrote:
On Sat, Sep 12, 2015 at 05:05:04PM -0400, Alex Agranovsky wrote:
> Amended: one of the new blocks ended up in a wrong location.
>
> libavformat/mpjpegdec.c | 19 +++
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
> index 8413ae7..1661b9d 100644
> --- a/libavformat/mpjpegdec.c
> +++ b/libavformat/mpjpegdec.c
> @@ -43,11 +43,20 @@ static int get_line(AVIOContext *pb, char *line, int
> line_size)
> static int split_tag_value(char **tag, char **value, char *line)
> {
> char *p = line;
> + int foundData = 0;
>
> - while (*p != '\0' && *p != ':')
> + *tag = NULL;
> + *value = NULL;
> +
> +
> + while (*p != '\0' && *p != ':') {
> + if (!av_isspace(*p)) {
> + foundData = 1;
> + }
> p++;
> + }
> if (*p != ':')
> - return AVERROR_INVALIDDATA;
> + return foundData?AVERROR_INVALIDDATA:0;
>
> *p = '\0';
> *tag = line;
> @@ -67,7 +76,7 @@ static int check_content_type(char *line)
> char *tag, *value;
> int ret = split_tag_value(&tag, &value, line);
>
> - if (ret < 0)
> + if (ret < 0 || tag == NULL || value == NULL)
> return ret;
doesnt this result in a probe score of AVPROBE_SCORE_MAX for an
empty line, or am i misreading the code ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
patch2b.diff
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Allow mpjpeg headers parsing to succeed upon EOF, if required headers are present
On Sat, Sep 12, 2015 at 06:49:41PM -0400, Alex Agranovsky wrote:
> Modified patch is attached.
>
> --
> Alex Agranovsky
> Sighthound, Inc
> www.sighthound.com
>
> On September 12, 2015 at 5:37:51 PM, Michael Niedermayer (michae...@gmx.at)
> wrote:
>
> On Sat, Sep 12, 2015 at 04:33:17PM -0400, Alex Agranovsky wrote:
> > libavformat/mpjpegdec.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
> > index b8281fc..8413ae7 100644
> > --- a/libavformat/mpjpegdec.c
> > +++ b/libavformat/mpjpegdec.c
> > @@ -165,7 +165,7 @@ static int parse_multipart_header(AVFormatContext *s)
> >
> > ret = get_line(s->pb, line, sizeof(line));
> > if (ret < 0)
> > - return ret;
> > + break;
>
> Applying: Allow mpjpeg headers parsing to succeed upon EOF, if required
> headers are present
> fatal: corrupt patch at line 7
>
> also for strict correctness this should probably only break for AVERROR_EOF
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Dictatorship naturally arises out of democracy, and the most aggravated
> form of tyranny and slavery out of the most extreme liberty. -- Plato
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> mpjpegdec.c |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
> 95570908ce1b8c6a97e45954d4f5a801a525d22c patch1.diff
> diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
> index b8281fc..e4d76f3 100644
> --- a/libavformat/mpjpegdec.c
> +++ b/libavformat/mpjpegdec.c
> @@ -154,8 +154,11 @@ static int parse_multipart_header(AVFormatContext *s)
> int ret, size = -1;
>
> ret = get_line(s->pb, line, sizeof(line));
> -if (ret < 0)
> +if (ret < 0) {
> +if (ret==AVERROR_EOF)
> +break;
> return ret;
> +}
this is a different hunk and it fails to build:
ffmpeg/libavformat/mpjpegdec.c: In function ‘parse_multipart_header’:
ffmpeg/libavformat/mpjpegdec.c:159:13: error: break statement not within loop
or switch
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Observe your enemies, for they first find out your faults. -- Antisthenes
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpjpeg: trim header name/value of MIME headers while probing
Attached. -- Alex Agranovsky Sighthound, Inc www.sighthound.com On September 12, 2015 at 5:41:56 PM, Michael Niedermayer (michae...@gmx.at) wrote: On Sat, Sep 12, 2015 at 05:10:06PM -0400, Alex Agranovsky wrote: > libavformat/mpjpegdec.c | 15 +++ > 1 file changed, 15 insertions(+) patching file libavformat/mpjpegdec.c patch: malformed patch at line 6: return 0; it seems the patches have been corrupted somewhere in the mail processing, can you send the as attachment ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel patch3.diff Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpjpeg: CRLF terminating a sequence of MIME headers should not cause an error
On Sat, Sep 12, 2015 at 07:04:26PM -0400, Alex Agranovsky wrote:
> You’re correct, sir. New patch is attached.
>
>
> --
> Alex Agranovsky
> Sighthound, Inc
> www.sighthound.com
>
> On September 12, 2015 at 5:54:23 PM, Michael Niedermayer (michae...@gmx.at)
> wrote:
>
> On Sat, Sep 12, 2015 at 05:05:04PM -0400, Alex Agranovsky wrote:
> > Amended: one of the new blocks ended up in a wrong location.
> >
> > libavformat/mpjpegdec.c | 19 +++
> > 1 file changed, 15 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
> > index 8413ae7..1661b9d 100644
> > --- a/libavformat/mpjpegdec.c
> > +++ b/libavformat/mpjpegdec.c
> > @@ -43,11 +43,20 @@ static int get_line(AVIOContext *pb, char *line, int
> > line_size)
> > static int split_tag_value(char **tag, char **value, char *line)
> > {
> > char *p = line;
> > + int foundData = 0;
> >
> > - while (*p != '\0' && *p != ':')
> > + *tag = NULL;
> > + *value = NULL;
> > +
> > +
> > + while (*p != '\0' && *p != ':') {
> > + if (!av_isspace(*p)) {
> > + foundData = 1;
> > + }
> > p++;
> > + }
> > if (*p != ':')
> > - return AVERROR_INVALIDDATA;
> > + return foundData?AVERROR_INVALIDDATA:0;
> >
> > *p = '\0';
> > *tag = line;
> > @@ -67,7 +76,7 @@ static int check_content_type(char *line)
> > char *tag, *value;
> > int ret = split_tag_value(&tag, &value, line);
> >
> > - if (ret < 0)
> > + if (ret < 0 || tag == NULL || value == NULL)
> > return ret;
>
> doesnt this result in a probe score of AVPROBE_SCORE_MAX for an
> empty line, or am i misreading the code ?
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Good people do not need laws to tell them to act responsibly, while bad
> people will find a way around the laws. -- Plato
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> mpjpegdec.c | 19 ---
> 1 file changed, 16 insertions(+), 3 deletions(-)
> 7f04b810839ce200528855c2c9b50aaf45028045 patch2b.diff
> diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
> index e4d76f3..8c91bc4 100644
> --- a/libavformat/mpjpegdec.c
> +++ b/libavformat/mpjpegdec.c
> @@ -43,11 +43,20 @@ static int get_line(AVIOContext *pb, char *line, int
> line_size)
> static int split_tag_value(char **tag, char **value, char *line)
> {
> char *p = line;
> +int foundData = 0;
>
> -while (*p != '\0' && *p != ':')
> +*tag = NULL;
> +*value = NULL;
> +
> +
> +while (*p != '\0' && *p != ':') {
> +if (!av_isspace(*p)) {
> +foundData = 1;
> +}
> p++;
> +}
> if (*p != ':')
> -return AVERROR_INVALIDDATA;
> +return foundData?AVERROR_INVALIDDATA:0;
>
> *p = '\0';
> *tag = line;
> @@ -70,7 +79,9 @@ static int check_content_type(char *line)
> if (ret < 0)
> return ret;
>
> -if (av_strcasecmp(tag, "Content-type") ||
> +if ( tag == NULL ||
> +value == NULL ||
> +av_strcasecmp(tag, "Content-type") ||
> av_strcasecmp(value, "image/jpeg"))
> return AVERROR_INVALIDDATA;
>
> @@ -176,6 +187,8 @@ static int parse_multipart_header(AVFormatContext *s)
> ret = split_tag_value(&tag, &value, line);
> if (ret < 0)
> return ret;
> +if (value==NULL || tag==NULL)
> +break;
this would stop parsing on an empty line,
could there be further lines afterwards that need parsing ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpjpeg: CRLF terminating a sequence of MIME headers should not cause an error
This is as intended: stopping at the empty line is exactly what we should do in
this case, as it separates headers from the content.
If the two headers we’re looking for hadn’t been encountered prior to the empty
line, error should be returned.
This is based on http://tools.ietf.org/html/rfc2046:
body-part := MIME-part-headers [CRLF *OCTET]
; Lines in a body-part must not start
; with the specified dash-boundary and
; the delimiter must not appear anywhere
; in the body part. Note that the
; semantics of a body-part differ from
; the semantics of a message, as
; described in the text.
--
Alex Agranovsky
Sighthound, Inc
www.sighthound.com
On September 12, 2015 at 8:14:01 PM, Michael Niedermayer (michae...@gmx.at)
wrote:
On Sat, Sep 12, 2015 at 07:04:26PM -0400, Alex Agranovsky wrote:
> You’re correct, sir. New patch is attached.
>
>
> --
> Alex Agranovsky
> Sighthound, Inc
> www.sighthound.com
>
> On September 12, 2015 at 5:54:23 PM, Michael Niedermayer (michae...@gmx.at)
> wrote:
>
> On Sat, Sep 12, 2015 at 05:05:04PM -0400, Alex Agranovsky wrote:
> > Amended: one of the new blocks ended up in a wrong location.
> >
> > libavformat/mpjpegdec.c | 19 +++
> > 1 file changed, 15 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
> > index 8413ae7..1661b9d 100644
> > --- a/libavformat/mpjpegdec.c
> > +++ b/libavformat/mpjpegdec.c
> > @@ -43,11 +43,20 @@ static int get_line(AVIOContext *pb, char *line, int
> > line_size)
> > static int split_tag_value(char **tag, char **value, char *line)
> > {
> > char *p = line;
> > + int foundData = 0;
> >
> > - while (*p != '\0' && *p != ':')
> > + *tag = NULL;
> > + *value = NULL;
> > +
> > +
> > + while (*p != '\0' && *p != ':') {
> > + if (!av_isspace(*p)) {
> > + foundData = 1;
> > + }
> > p++;
> > + }
> > if (*p != ':')
> > - return AVERROR_INVALIDDATA;
> > + return foundData?AVERROR_INVALIDDATA:0;
> >
> > *p = '\0';
> > *tag = line;
> > @@ -67,7 +76,7 @@ static int check_content_type(char *line)
> > char *tag, *value;
> > int ret = split_tag_value(&tag, &value, line);
> >
> > - if (ret < 0)
> > + if (ret < 0 || tag == NULL || value == NULL)
> > return ret;
>
> doesnt this result in a probe score of AVPROBE_SCORE_MAX for an
> empty line, or am i misreading the code ?
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Good people do not need laws to tell them to act responsibly, while bad
> people will find a way around the laws. -- Plato
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> mpjpegdec.c | 19 ---
> 1 file changed, 16 insertions(+), 3 deletions(-)
> 7f04b810839ce200528855c2c9b50aaf45028045 patch2b.diff
> diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
> index e4d76f3..8c91bc4 100644
> --- a/libavformat/mpjpegdec.c
> +++ b/libavformat/mpjpegdec.c
> @@ -43,11 +43,20 @@ static int get_line(AVIOContext *pb, char *line, int
> line_size)
> static int split_tag_value(char **tag, char **value, char *line)
> {
> char *p = line;
> + int foundData = 0;
>
> - while (*p != '\0' && *p != ':')
> + *tag = NULL;
> + *value = NULL;
> +
> +
> + while (*p != '\0' && *p != ':') {
> + if (!av_isspace(*p)) {
> + foundData = 1;
> + }
> p++;
> + }
> if (*p != ':')
> - return AVERROR_INVALIDDATA;
> + return foundData?AVERROR_INVALIDDATA:0;
>
> *p = '\0';
> *tag = line;
> @@ -70,7 +79,9 @@ static int check_content_type(char *line)
> if (ret < 0)
> return ret;
>
> - if (av_strcasecmp(tag, "Content-type") ||
> + if ( tag == NULL ||
> + value == NULL ||
> + av_strcasecmp(tag, "Content-type") ||
> av_strcasecmp(value, "image/jpeg"))
> return AVERROR_INVALIDDATA;
>
> @@ -176,6 +187,8 @@ static int parse_multipart_header(AVFormatContext *s)
> ret = split_tag_value(&tag, &value, line);
> if (ret < 0)
> return ret;
> + if (value==NULL || tag==NULL)
> + break;
this would stop parsing on an empty line,
could there be further lines afterwards that need parsing ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg
Re: [FFmpeg-devel] [PATCH] Allow mpjpeg headers parsing to succeed upon EOF, if required headers are present
My bad — sorry about that.
On September 12, 2015 at 7:08:34 PM, Michael Niedermayer (michae...@gmx.at)
wrote:
On Sat, Sep 12, 2015 at 06:49:41PM -0400, Alex Agranovsky wrote:
> Modified patch is attached.
>
> --
> Alex Agranovsky
> Sighthound, Inc
> www.sighthound.com
>
> On September 12, 2015 at 5:37:51 PM, Michael Niedermayer (michae...@gmx.at)
> wrote:
>
> On Sat, Sep 12, 2015 at 04:33:17PM -0400, Alex Agranovsky wrote:
> > libavformat/mpjpegdec.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
> > index b8281fc..8413ae7 100644
> > --- a/libavformat/mpjpegdec.c
> > +++ b/libavformat/mpjpegdec.c
> > @@ -165,7 +165,7 @@ static int parse_multipart_header(AVFormatContext *s)
> >
> > ret = get_line(s->pb, line, sizeof(line));
> > if (ret < 0)
> > - return ret;
> > + break;
>
> Applying: Allow mpjpeg headers parsing to succeed upon EOF, if required
> headers are present
> fatal: corrupt patch at line 7
>
> also for strict correctness this should probably only break for AVERROR_EOF
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Dictatorship naturally arises out of democracy, and the most aggravated
> form of tyranny and slavery out of the most extreme liberty. -- Plato
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> mpjpegdec.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
> 95570908ce1b8c6a97e45954d4f5a801a525d22c patch1.diff
> diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
> index b8281fc..e4d76f3 100644
> --- a/libavformat/mpjpegdec.c
> +++ b/libavformat/mpjpegdec.c
> @@ -154,8 +154,11 @@ static int parse_multipart_header(AVFormatContext *s)
> int ret, size = -1;
>
> ret = get_line(s->pb, line, sizeof(line));
> - if (ret < 0)
> + if (ret < 0) {
> + if (ret==AVERROR_EOF)
> + break;
> return ret;
> + }
this is a different hunk and it fails to build:
ffmpeg/libavformat/mpjpegdec.c: In function ‘parse_multipart_header’:
ffmpeg/libavformat/mpjpegdec.c:159:13: error: break statement not within loop
or switch
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Observe your enemies, for they first find out your faults. -- Antisthenes
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
patch1c.diff
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Allow mpjpeg headers parsing to succeed upon EOF, if required headers are present
On Sat, Sep 12, 2015 at 08:34:14PM -0400, Alex Agranovsky wrote:
> My bad — sorry about that.
>
> On September 12, 2015 at 7:08:34 PM, Michael Niedermayer (michae...@gmx.at)
> wrote:
>
> On Sat, Sep 12, 2015 at 06:49:41PM -0400, Alex Agranovsky wrote:
> > Modified patch is attached.
> >
> > --
> > Alex Agranovsky
> > Sighthound, Inc
> > www.sighthound.com
> >
> > On September 12, 2015 at 5:37:51 PM, Michael Niedermayer (michae...@gmx.at)
> > wrote:
> >
> > On Sat, Sep 12, 2015 at 04:33:17PM -0400, Alex Agranovsky wrote:
> > > libavformat/mpjpegdec.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
> > > index b8281fc..8413ae7 100644
> > > --- a/libavformat/mpjpegdec.c
> > > +++ b/libavformat/mpjpegdec.c
> > > @@ -165,7 +165,7 @@ static int parse_multipart_header(AVFormatContext *s)
> > >
> > >
> > > ret = get_line(s->pb, line, sizeof(line));
> > > if (ret < 0)
> > > - return ret;
> > > + break;
> >
> > Applying: Allow mpjpeg headers parsing to succeed upon EOF, if required
> > headers are present
> > fatal: corrupt patch at line 7
> >
> > also for strict correctness this should probably only break for AVERROR_EOF
> >
> >
> > [...]
> >
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Dictatorship naturally arises out of democracy, and the most aggravated
> > form of tyranny and slavery out of the most extreme liberty. -- Plato
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> > mpjpegdec.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> > 95570908ce1b8c6a97e45954d4f5a801a525d22c patch1.diff
> > diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
> > index b8281fc..e4d76f3 100644
> > --- a/libavformat/mpjpegdec.c
> > +++ b/libavformat/mpjpegdec.c
> > @@ -154,8 +154,11 @@ static int parse_multipart_header(AVFormatContext *s)
> > int ret, size = -1;
> >
> > ret = get_line(s->pb, line, sizeof(line));
> > - if (ret < 0)
> > + if (ret < 0) {
> > + if (ret==AVERROR_EOF)
> > + break;
> > return ret;
> > + }
>
> this is a different hunk and it fails to build:
> ffmpeg/libavformat/mpjpegdec.c: In function ‘parse_multipart_header’:
> ffmpeg/libavformat/mpjpegdec.c:159:13: error: break statement not within loop
> or switch
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Observe your enemies, for they first find out your faults. -- Antisthenes
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> mpjpegdec.c |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
> 78ee277ff0b7d7df13eb148d601c1c8ddf4c0634 patch1c.diff
> commit 0a603cdaf5cf5d6dd722fe5556c278ce726683b9
> Author: Alex Agranovsky
> Date: Sat Sep 12 20:28:33 2015 -0400
>
> Allow mpjpeg headers parsing to succeed upon EOF, if required headers are
> present
applied
btw, "git format-patch" style patches are prefered over "git show/log"
style
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
DNS cache poisoning attacks, popular search engine, Google internet authority
dont be evil, please
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/5] avfilter/vsrc_mandelbrot: use the name 's' for the pointer to the private context
Signed-off-by: Ganesh Ajjanagadde
---
libavfilter/vsrc_mandelbrot.c | 166 +-
1 file changed, 83 insertions(+), 83 deletions(-)
diff --git a/libavfilter/vsrc_mandelbrot.c b/libavfilter/vsrc_mandelbrot.c
index e26fecd..56d0503 100644
--- a/libavfilter/vsrc_mandelbrot.c
+++ b/libavfilter/vsrc_mandelbrot.c
@@ -121,29 +121,29 @@ AVFILTER_DEFINE_CLASS(mandelbrot);
static av_cold int init(AVFilterContext *ctx)
{
-MBContext *mb = ctx->priv;
+MBContext *s = ctx->priv;
-mb->bailout *= mb->bailout;
+s->bailout *= s->bailout;
-mb->start_scale /=mb->h;
-mb->end_scale /=mb->h;
+s->start_scale /=s->h;
+s->end_scale /=s->h;
-mb->cache_allocated = mb->w * mb->h * 3;
-mb->cache_used = 0;
-mb->point_cache= av_malloc_array(mb->cache_allocated,
sizeof(*mb->point_cache));
-mb-> next_cache= av_malloc_array(mb->cache_allocated, sizeof(*mb->
next_cache));
-mb-> zyklus= av_malloc_array(mb->maxiter + 16, sizeof(*mb->zyklus));
+s->cache_allocated = s->w * s->h * 3;
+s->cache_used = 0;
+s->point_cache= av_malloc_array(s->cache_allocated,
sizeof(*s->point_cache));
+s-> next_cache= av_malloc_array(s->cache_allocated, sizeof(*s->
next_cache));
+s-> zyklus= av_malloc_array(s->maxiter + 16, sizeof(*s->zyklus));
return 0;
}
static av_cold void uninit(AVFilterContext *ctx)
{
-MBContext *mb = ctx->priv;
+MBContext *s = ctx->priv;
-av_freep(&mb->point_cache);
-av_freep(&mb-> next_cache);
-av_freep(&mb->zyklus);
+av_freep(&s->point_cache);
+av_freep(&s-> next_cache);
+av_freep(&s->zyklus);
}
static int query_formats(AVFilterContext *ctx)
@@ -162,48 +162,48 @@ static int query_formats(AVFilterContext *ctx)
static int config_props(AVFilterLink *inlink)
{
AVFilterContext *ctx = inlink->src;
-MBContext *mb = ctx->priv;
+MBContext *s = ctx->priv;
-if (av_image_check_size(mb->w, mb->h, 0, ctx) < 0)
+if (av_image_check_size(s->w, s->h, 0, ctx) < 0)
return AVERROR(EINVAL);
-inlink->w = mb->w;
-inlink->h = mb->h;
-inlink->time_base = av_inv_q(mb->frame_rate);
+inlink->w = s->w;
+inlink->h = s->h;
+inlink->time_base = av_inv_q(s->frame_rate);
return 0;
}
static void fill_from_cache(AVFilterContext *ctx, uint32_t *color, int
*in_cidx, int *out_cidx, double py, double scale){
-MBContext *mb = ctx->priv;
-if(mb->morphamp)
+MBContext *s = ctx->priv;
+if(s->morphamp)
return;
-for(; *in_cidx < mb->cache_used; (*in_cidx)++){
-Point *p= &mb->point_cache[*in_cidx];
+for(; *in_cidx < s->cache_used; (*in_cidx)++){
+Point *p= &s->point_cache[*in_cidx];
int x;
if(p->p[1] > py)
break;
-x= round((p->p[0] - mb->start_x) / scale + mb->w/2);
-if(x<0 || x >= mb->w)
+x= round((p->p[0] - s->start_x) / scale + s->w/2);
+if(x<0 || x >= s->w)
continue;
if(color) color[x] = p->val;
-if(out_cidx && *out_cidx < mb->cache_allocated)
-mb->next_cache[(*out_cidx)++]= *p;
+if(out_cidx && *out_cidx < s->cache_allocated)
+s->next_cache[(*out_cidx)++]= *p;
}
}
-static int interpol(MBContext *mb, uint32_t *color, int x, int y, int linesize)
+static int interpol(MBContext *s, uint32_t *color, int x, int y, int linesize)
{
uint32_t a,b,c,d, i;
uint32_t ipol=0xFF00;
int dist;
-if(!x || !y || x+1==mb->w || y+1==mb->h)
+if(!x || !y || x+1==s->w || y+1==s->h)
return 0;
-dist= FFMAX(FFABS(x-(mb->w>>1))*mb->h, FFABS(y-(mb->h>>1))*mb->w);
+dist= FFMAX(FFABS(x-(s->w>>1))*s->h, FFABS(y-(s->h>>1))*s->w);
-if(dist<(mb->w*mb->h>>3))
+if(dist<(s->w*s->h>>3))
return 0;
a=color[(x+1) + (y+0)*linesize];
@@ -248,50 +248,50 @@ static int interpol(MBContext *mb, uint32_t *color, int
x, int y, int linesize)
static void draw_mandelbrot(AVFilterContext *ctx, uint32_t *color, int
linesize, int64_t pts)
{
-MBContext *mb = ctx->priv;
+MBContext *s = ctx->priv;
int x,y,i, in_cidx=0, next_cidx=0, tmp_cidx;
-double scale= mb->start_scale*pow(mb->end_scale/mb->start_scale,
pts/mb->end_pts);
+double scale= s->start_scale*pow(s->end_scale/s->start_scale,
pts/s->end_pts);
int use_zyklus=0;
-fill_from_cache(ctx, NULL, &in_cidx, NULL,
mb->start_y+scale*(-mb->h/2-0.5), scale);
+fill_from_cache(ctx, NULL, &in_cidx, NULL, s->start_y+scale*(-s->h/2-0.5),
scale);
tmp_cidx= in_cidx;
-memset(color, 0, sizeof(*color)*mb->w);
-for(y=0; yh; y++){
+memset(color, 0, sizeof(*color)*s->w);
+for(y=0; yh; y++){
int y1= y+1;
-const double ci=mb->start_y+scale*(y-mb->h/2);
+const double ci=s->start_y+scale*(y-s->h/2);
fill_from_cache(ctx, NULL, &in_cidx, &next_cidx, ci, scale);
-if(y1h){
-memset(color+linesize*y1, 0, s
[FFmpeg-devel] avfilter renaming (patches 2/5-5/5)
Hi,
Apologies for not using git send-email for the remaining patches; it
seems like git send-email has been broken by gmail; or does not like
sending multiple patches in a single shot.
As these patches are trivial; I have attached the remainder instead to
this email.
Regards,
Ganesh
From d0471edddbfde1bfda5bd6fce635522a8fbbcd6f Mon Sep 17 00:00:00 2001
From: Ganesh Ajjanagadde
Date: Fri, 28 Aug 2015 01:29:07 -0400
Subject: [PATCH 2/5] avfilter/vsrc_life: use the name 's' for the pointer to
the private context
Signed-off-by: Ganesh Ajjanagadde
---
libavfilter/vsrc_life.c | 218
1 file changed, 109 insertions(+), 109 deletions(-)
diff --git a/libavfilter/vsrc_life.c b/libavfilter/vsrc_life.c
index 314746d..720953f 100644
--- a/libavfilter/vsrc_life.c
+++ b/libavfilter/vsrc_life.c
@@ -144,15 +144,15 @@ error:
#ifdef DEBUG
static void show_life_grid(AVFilterContext *ctx)
{
-LifeContext *life = ctx->priv;
+LifeContext *s = ctx->priv;
int i, j;
-char *line = av_malloc(life->w + 1);
+char *line = av_malloc(s->w + 1);
if (!line)
return;
-for (i = 0; i < life->h; i++) {
-for (j = 0; j < life->w; j++)
-line[j] = life->buf[life->buf_idx][i*life->w + j] == ALIVE_CELL ? '@' : ' ';
+for (i = 0; i < s->h; i++) {
+for (j = 0; j < s->w; j++)
+line[j] = s->buf[s->buf_idx][i*s->w + j] == ALIVE_CELL ? '@' : ' ';
line[j] = 0;
av_log(ctx, AV_LOG_DEBUG, "%3d: %s\n", i, line);
}
@@ -162,19 +162,19 @@ static void show_life_grid(AVFilterContext *ctx)
static int init_pattern_from_file(AVFilterContext *ctx)
{
-LifeContext *life = ctx->priv;
+LifeContext *s = ctx->priv;
char *p;
int ret, i, i0, j, h = 0, w, max_w = 0;
-if ((ret = av_file_map(life->filename, &life->file_buf, &life->file_bufsize,
+if ((ret = av_file_map(s->filename, &s->file_buf, &s->file_bufsize,
0, ctx)) < 0)
return ret;
-av_freep(&life->filename);
+av_freep(&s->filename);
/* prescan file to get the number of lines and the maximum width */
w = 0;
-for (i = 0; i < life->file_bufsize; i++) {
-if (life->file_buf[i] == '\n') {
+for (i = 0; i < s->file_bufsize; i++) {
+if (s->file_buf[i] == '\n') {
h++; max_w = FFMAX(w, max_w); w = 0;
} else {
w++;
@@ -182,78 +182,78 @@ static int init_pattern_from_file(AVFilterContext *ctx)
}
av_log(ctx, AV_LOG_DEBUG, "h:%d max_w:%d\n", h, max_w);
-if (life->w) {
-if (max_w > life->w || h > life->h) {
+if (s->w) {
+if (max_w > s->w || h > s->h) {
av_log(ctx, AV_LOG_ERROR,
"The specified size is %dx%d which cannot contain the provided file size of %dx%d\n",
- life->w, life->h, max_w, h);
+ s->w, s->h, max_w, h);
return AVERROR(EINVAL);
}
} else {
/* size was not specified, set it to size of the grid */
-life->w = max_w;
-life->h = h;
+s->w = max_w;
+s->h = h;
}
-if (!(life->buf[0] = av_calloc(life->h * life->w, sizeof(*life->buf[0]))) ||
-!(life->buf[1] = av_calloc(life->h * life->w, sizeof(*life->buf[1] {
-av_freep(&life->buf[0]);
-av_freep(&life->buf[1]);
+if (!(s->buf[0] = av_calloc(s->h * s->w, sizeof(*s->buf[0]))) ||
+!(s->buf[1] = av_calloc(s->h * s->w, sizeof(*s->buf[1] {
+av_freep(&s->buf[0]);
+av_freep(&s->buf[1]);
return AVERROR(ENOMEM);
}
/* fill buf[0] */
-p = life->file_buf;
-for (i0 = 0, i = (life->h - h)/2; i0 < h; i0++, i++) {
-for (j = (life->w - max_w)/2;; j++) {
+p = s->file_buf;
+for (i0 = 0, i = (s->h - h)/2; i0 < h; i0++, i++) {
+for (j = (s->w - max_w)/2;; j++) {
av_log(ctx, AV_LOG_DEBUG, "%d:%d %c\n", i, j, *p == '\n' ? 'N' : *p);
if (*p == '\n') {
p++; break;
} else
-life->buf[0][i*life->w + j] = av_isgraph(*(p++)) ? ALIVE_CELL : 0;
+s->buf[0][i*s->w + j] = av_isgraph(*(p++)) ? ALIVE_CELL : 0;
}
}
-life->buf_idx = 0;
+s->buf_idx = 0;
return 0;
}
static av_cold int init(AVFilterContext *ctx)
{
-LifeContext *life = ctx->priv;
+LifeContext *s = ctx->priv;
int ret;
-if (!life->w && !life->filename)
-av_opt_set(life, "size", "320x240", 0);
+if (!s->w && !s->filename)
+av_opt_set(s, "size", "320x240", 0);
-if ((ret = parse_rule(&life->born_rule, &life->stay_rule, life->rule_str, ctx)) < 0)
+if ((ret = parse_rule(&s->born_rule, &s->stay_rule, s->rule_str, ctx)) < 0)
return ret;
-if (!life->mold && memcmp(life->mold_color, "\x00\x00\x00", 3))
+if (!s->mold && memcmp(s->mold_color, "\x00\x00\x00", 3))
av_log(ctx, AV_LOG_WARNIN
[FFmpeg-devel] [PATCH] configure: make assignment of variable to '=' explicit
op== is confusing, as it may easily be mistook for an equality check,
while in reality it is doing an assigment to '='.
This patch has the additional benefit of cleaning up 2 warnings from
shellcheck.net.
Signed-off-by: Ganesh Ajjanagadde
---
configure | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index da18e70..2fb625b 100755
--- a/configure
+++ b/configure
@@ -622,12 +622,12 @@ enable_deep_weak(){
}
enabled(){
-test "${1#!}" = "$1" && op== || op=!=
+test "${1#!}" = "$1" && op='=' || op=!=
eval test "x\$${1#!}" $op "xyes"
}
disabled(){
-test "${1#!}" = "$1" && op== || op=!=
+test "${1#!}" = "$1" && op='=' || op=!=
eval test "x\$${1#!}" $op "xno"
}
--
2.5.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
