Re: [FFmpeg-devel] [RFC] Release 6.1
Rémi Denis-Courmont (12023-09-28): > Thanks for making my point. Stealing the other person rhetoric device does not make you right. > That does not change the fact that it won't make it any popular, and thus > your > postulate is wrong. It reach more popular included in FFmpeg than if users have to download it separately. Nobody honest would seriously try to argue the opposite. > It should be blatantly obvious to anybody with a modicum of modesty that "fit > nicely together" is intrinsically a very subjective value judgement, not a > technical argument in favor or disfavor of anything. What you are describing here is your “does not belong”. “Fit nicely together” means it allows to do things that were not possible previously or required more work and were more fragile (pipelines and shell scripts). It is a technical argument. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Rémi Denis-Courmont (12023-09-28): > Strange, I thought FFmpeg really became popular as a back-end library for > mplayer, before it was picked up by all other OSS multimedia at the time > (gstreamer, VLC, Xine, etc.). Fortunately, I know the history of our projects better than you: First, FFmpeg was already a feature-rich self-contained program when MPlayer started using it. Second, MPlayer did not start using it FFmpeg as a library, it started — and still does in part — using it as embedded code. Too bad your attempt at disproving my point just proves it. > Force-feeding the SDR code to all FFmpeg packagers is not going to make it > popular. Most of them will just disable it, especially if it brings new > dependencies and/or doesn't work on the popular proprietary platforms. So, they can “just disable it” and ignore it. They have no ground to oppose, and neither do you. > FWIW, Fabrice Bellard didn't bundle all his initially hobby projects > together. > Several of them became popular. He bundled together the things that fit nicely together. Once again an argument in favor of SDR integration. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Rémi Denis-Courmont (12023-09-28): > You can repeat the contrary as much as you want, we do not believe that your > SDR code fits in FFmpeg. Why do you not understand this? We understand that very well. Once again, it is you who do not understand something: your BELIEF that SDR does not belong in ffmpeg is nothing more than that, a belief, an opinion, and it weighs nothing in front of the argument that some users want it. > Like no, seriously. If you really want to generic support for AM and FM RX in > FFmpeg, then you should use implement frontends for the already *existing* > HAL > (that would be V4L radio and ALSA on Linux), or perhaps, write a new user- > space HAL library that would accomodate both hardware radio RX devices and > SDR. Did you miss the part where he explained he was not interesting in doing it like that? > In fact, the SDR code has quite a number of impediments that all but > guarantee > that it will not "catch on" in FFmpeg: > - it requires niche hardware, Like a few components of libavdevice, that is not an issue. > - it only works on some limited set of OSes (if not only Linux), Like a few components of libavdevice, that is not an issue. > - it will be subject to all the FFmpeg processes and drama, This problem does not come from SDR, it comes from you. > - it will be obscured by FFmpeg's existing own fame, remaining an obscure > feature set that hardly anybody outside FFmpeg-devel knows about. Like a lot of features. Scrapping the bottom of drawers for arguments are you? -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Anual Committee Report
Michael Niedermayer (12023-09-28): > I think the 2 commmittteees we have We do not have two committees, their mandate expired more than a year ago. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] framequeue: Remove redundant logic code
杨亚磊 via ffmpeg-devel (12023-09-14): > Hello everyone. > I submitted a patch, the details are as follows: > > framequeue: Remove redundant logic code > > In this logical branch, fq->queued and fq->allocated must be equal. > Deleting this code will make it easier to understand the logic ( > copy the data before tail to the newly requested space) > > >Please review as soon as possible, thank you very much！ Hi. Thanks for the patch. Good catch. Applied. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Michael Niedermayer (12023-09-27): > With SDR they do ask for a seperate library. And they are being dishonest in that. Nothing successful starts as a library, they start small and grow, and get turned into libraries once multiple projects can use them. Demanding you make a separate library and a separate project is a hypocritical ploy to have you spend your time on boring things like build system and packaging, so that you lose interest in SDR and go back to doing useful things for them, like fixing fuzzing bugs and backporting the fixes. > maybe we can organize the > existing code to make everyone happy. You will NOT make everyone happy. Some people here have made absolutely clear they will never be happy with your SDR code and will not rest until they have killed it. Acknowledge it: if you cannot make them happy, do not waste effort trying, just accept you will be making them unhappy as unavoidable, and make the rest of us — developers who would like to have fun with FFmpeg again and users who would like to use the code — very happy. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] QOA decoding support
Andreas Rheinhardt (12023-09-27): > Then you could simply reuse the code inside libavformat. Do you finally support merging the libraries then? Because otherwise, using from libavformat code for an individual component of libavcodec requires adding a new avpriv function. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] QOA decoding support
Paul B Mahol (12023-09-27): > I think that having parser is much more useful. Having a parser when it can be done without is a waste of code and resources. Do not push like that. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Vittorio Giovara (12023-09-26): > This is not true. If you say so. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Anton Khirnov (12023-09-26): > It is not. From my perspective, the objections to SDR have been largely > technical We have not read the same discussion. The objections to SDR start and end at “it does not belong in FFmpeg”, which is not a technical objection but an aesthetic one. Furthermore, the way these objections were stated made it quite obvious the motivation behind them was that they wanted Michael to spend his time on more useful tasks. More useful for them, implicitly. Again, that is not technical, that is egoistical. Last, there have been some suggestions or demands, technical indeed, that looked like openings for compromise. But the same people who made them made it clear in other parts of the discussion they had no intention of meeting anybody on any kind of middle ground. Given the disingenuousness of these demands, I think Michael is entitled to feel a little paranoid. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)
Paul B Mahol (12023-09-21): > If this SDR troll code ever get committed in FFmpeg libraries I will > immediately leave project. That would be sad for the project. But I am sorry, I sincerely believe that if you were to follow through with it, it would be a price worth paying to have Michael working on code that gives him fun again. Anyway, I suppose you have no difficulty seeing how this kind of blackmail cannot be taken into consideration for the decision of the future of the project. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] libavdevice (was: FFmpeg release 6.1 (SDR Plans))
Paul B Mahol (12023-09-25): > [computer@archlinux ffmpeg]$ git sn libavdevice/|grep Paul\ B\ Mahol ~/prog/ffmpeg $ git sn libavformat/|grep Paul\ B\ Mahol git: 'sn' is not a git command. See 'git --help'. > I had great plans for libavdevice, but as my proposal to change API was > rejected I'm no longer contributing to libavdevice. I do not remember your proposal and it rejection, nor do I manage to find it in my archives, but I will assume you remember correctly having sent it. If your great plans involved breaking the ability to use most device transparently in place of a muxer or demuxer, then of course they were rejected. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
James Almer (12023-09-26): > We don't want you to resign anything. We want a proper discussion in how to > handle SDR, if at all. Pushing it in a form that everyone agrees is not > ready for upstream is not a good idea. We can agree on this, if we consider that the opinion on whether it is ready of people who have made it clear they will never consider it “ready” is to be disregarded, just as much as somebody who says “nak” to a patch without reasons. > SDR is big, so its API needs to be designed carefully and in an extensible > way. > libavradio must absolutely not be libavdevice redux, and it must have its > own, versatile and extensible API that a lavd device can then work with, > even if not using its full potential, because libavradio can have other > users that will not be constrained to what lavf/lavd can do. SDR **will be** big. SDR **will need** to have its own versatile and extensible API. But the way to get there is to start small. First make it a module, with a very simple API to the rest. Then, as it grows, it acquires utility functions: an internal API that we can change as we discover what it needs. And progressively the API stabilizes and becomes good. Nothing successful starts as a library. Suggesting that a project starts as a library is either an expression of incompetence or a dishonest attempt at killing it. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] libavdevice (was: FFmpeg release 6.1 (SDR Plans))
Paul B Mahol (12023-09-24): > libavdevice is using libavformat API that is unacceptable maintenance burden. This is a lie. You would not even know if libavdevice is a maintenance burden, you never touch it. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] libavdevice (was: FFmpeg release 6.1 (SDR Plans))
Paul B Mahol (12023-09-24): > Citations needed. > libavdevice have no API. Yes, that was my point. If you do not understand why it is an essential part of libavdevice, I suggest you take the time to learn what libavdevice is all about and refrain from commenting on it before you have gotten a clue. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] libavdevice (was: FFmpeg release 6.1 (SDR Plans))
Paul B Mahol (12023-09-24): > Define 'works'. > > It is clearly sub-optimal. Many users use it for many different tasks and it serves them efficiently. There are probably ways to enhance the API of libavdevice. If you have suggestions, then please share them. But when you say that libavdevices is “abusing libavformat”, it seems to indicate you completely missed the fact that being able to use devices in places that were not designed is an essential part of the service libavdevice gives to users, and if your suggestions involve breaking it you can keep them to yourself, they are useless. As for people who criticize libavdevice without even a hint of a reflection on how to make make it better, they are just hypocrites who disguise their hate into technical opinion. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)
Michael Niedermayer (12023-09-24): > Also SW must be easy maintainable, everything i hear of gitlab is saying > the opposit. I have not read the rest of the message yet, for now I just want to mention that a non-negligible part of my job in the last year involved upgrading GitLab after emergency security releases. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)
Paul B Mahol (12023-09-24): > libavdevice is abusing libavformat. > > It should have own API or be removed. libavdevice works. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)
Neal Gompa (12023-09-23): > If it's just taking SDR devices as inputs and allowing you to encode > audio and video streams, I'm not sure why you *wouldn't* have this as > something in libavdevice or extended from it as a separate library. The people who oppose Michael's SDR also have been trying to kill libavdevice for years. At least some of them. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Michael Niedermayer (12023-09-22): > Now the SDR + blockings is solved by not including any SDR that the > community doesnt like in 6.1 but instead me simply making a seperate > release with SDR, or so i thought. I strongly suggest you just refuse to make any release that do not include SDR. If somebody wants it, let them do the work. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 02/42] avcodec/refstruct: Add simple API for refcounted objects
Andreas Rheinhardt (12023-09-19): > For now, this API is supposed to replace all the internal uses > of reference counted objects in libavcodec; "internal" here > means that the object is created in libavcodec and is never > put directly in the hands of anyone outside of it. > > It is intended to be made public eventually, but for now > I enjoy the ability to modify it freely. > > Several shortcomings of the AVBuffer API motivated this API: Thanks for stating qualms that I have had for a long time about this API. An API like this one would have been really useful when the new channel layout structure was integrated. On a brighter note, it will be really useful if we finally turn the library's global state into a structure that can exist in multiple instances. > This brings with it > one further downside: It is not apparent from the pointer itself > whether the underlying object is managed by the refstruct API > or whether this pointer is a reference to it (or merely a pointer > to it). I do not count it as a downside: it is just how the C language is supposed to work. When we get a pointer, there is nothing written on it that says whether we are supposed to free(), av_free(), g_object_unref() it or just do nothing. People who cannot track static pointer ownership in their sleep should do Java. Also, you probably do not remember, three years ago I started proposing a similar idea, and it got bikeshedded to death: http://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/265227.html The difference is: You make this API universal using void pointers and callbacks, and you make it convenient by hiding the internals using pointer arithmetic. I achieve more or less the same using a template to generate code, with the extra benefit that it is type-safe. I see a few places in the code below where you pay the price for your design choice. I think you should consider taking a few ideas from my version. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)
Vittorio Giovara (12023-09-21): > So this is an example of accusatory tone - discrediting the previous author > in order to make your arguments have more weight. It's a bad move and > easily spottable, you should argue with better elements at your disposal, > not by claiming that I don't package software or don't contribute to > libavfilter. You are misunderstanding my point completely, I am not accusing you of anything, I am merely using you as an example to show how your argument is flawed. I can take myself as an example instead, if you like it better: How much did *I* contribute to hardware acceleration? Zero! How much did *I* contribute to assembly optimization? Zero! How much do *I* intend to contribute to hardware acceleration? Zero! But now, however much I would like to, especially in libavfilter, I refrain from objecting to new features of hardware acceleration. Because I can make the difference between the things that benefit me and the things that are useful to many users and therefore good for the project. FFmpeg is made a of a lot of parts that are often very independent. That is on purpose: that way, if somebody is not interested in a part, they can just ignore it and let others work on it. And that is exactly what I am asking you to do: Just ignore SDR and let Michael work on it. SDR costs NOTHING except Michael's time, and Michael's time is his own to spend. For the rest of us, the grounds for objecting are the same NOTHING. > opinion on this release still stands: either a release with everything or a > release without the contentious piece of code, but not both. It's confusing > to the end users, and shows lack of direction of the project. On this we agree, making a second release without the feature just some people object to it would be a waste of Michael's time. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)
Vittorio Giovara (12023-09-21): > What about other developers' time for maintenance? Yes, what about it? How much time did YOU spend maintaining libavfilter or libavdevice? Zero. How much time will you spend maintaining SDR? Zero. What does it change for you and everybody who thinks like you? NOTHING. Michael wants to invest his time in a features that integrates beautifully in FFmpeg and that some users are glad to expect. That is a good thing. People who are not interested in it but have no practical arguments against it have absolutely no right to oppose or put so much roadblock it becomes discouraging just because they would like it better if Michael spent his time on things that they find useful rather than things that he finds fun. > And for users installing a library nowadays is a one liner, not really a > big deal Only if it is packaged by a distribution. I am guessing you are not volunteering to package it yourself, so you are again proposing to waste somebody else's time. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)
Vittorio Giovara (12023-09-21): > Good, if it's so isolated it can be moved to a separate library and we're > arguing over nothing. Wasting Michael's time for the maintenance and users' time for installing it in the process. That is a completely stupid idea. > Will you stop with this accusatory tone in _every_ _single_ _email_ you > send? > Meeting a threshold of emails is not a good measure of the validity of any > claim. What? > Yes, and it agrees with its removal. Not if you count correctly. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)
Vittorio Giovara (12023-09-21): > Because it adds maintenance burden and it's out of scope with the proejct The feature is isolated, so that is a lie. > No thanks, feature creep is a bad mojo. “Creep” is your opinion, the opinion of somebody who we never see on users mailing lists by the way. > At any rate for the topic at hand, in my opinion there shouldn't be two > separate releases, either there is one with SDR or there is one without, > not both. > I actually thought the majority of the developer community was against > including this feature and I thought it was already removed. There is a clear majority of the developer community who do the work. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)
Kieran Kunhya via ffmpeg-devel (12023-09-21): > How on earth is it acceptable that you can publish your hobby project > under the FFmpeg project name? How on earth is it acceptable that you continue bikeshedding a feature that some users have been enthusiastically waiting for? > I have been working on BIOS code recently If it brings useful features in a way that integrate gracefully in FFmpeg, then great! Send the patches then. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 26/26] avfilter/buffersrc: Use av_frame_clone() where appropriate
Andreas Rheinhardt (12023-09-07): > Signed-off-by: Andreas Rheinhardt > --- > libavfilter/buffersrc.c | 13 + > 1 file changed, 5 insertions(+), 8 deletions(-) No objection. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] doc/developer: Code pushed without patches on ffmpeg-devel must be announced on the ML
James Almer (12023-08-25): > As i said on IRC, A medium that can only be accessed by a small fraction of the contributors due to timeliness constraints. > there's a difference between "Unless justified, please > send things to the ML before pushing" and "Everything must have at least two > reviews from long standing developers". > > This is not requiring everything to have been reviewed before being pushed, > it's asking for non trivial things to hit the ML so people have at least a > chance at finding problems. Faire enough. Just let us make it very clear it is the former and not the latter. The I-don't-know-the-code-“LGTM” mandatory review were a disgrace. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] doc/developer: Reviews must be constructive
Leo Izen (12023-08-25): > FWIW I read it the same way Anton did but if it's unclear then perhaps it > could be modified. Essentially, I think what's going on is we don't want > "NAK" without a reason. If you want to say a patch shouldn't make it in, > there should at least be a reason. I agree on this too. > Even if the reason is "this API/module has no place in FFmpeg." But not on this example: what has place in FFmpeg or not is anybody's arbitrary opinion, saying “no place in FFmpeg” alone is just a fancy way of saying “NAK” with no reason. It must be substantiated too, for example “the same feature is already possible [like that]”. And if the same feature is *not* already possible, then it surely means the code *does* belong in FFmpeg. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] doc/developer: Code pushed without patches on ffmpeg-devel must be announced on the ML
Jean-Baptiste Kempf (12023-08-25): > >> So that means mandatory sending to the mailing list :) > Trolling is not going to get you anywhere. What trolling? You mean the suggestion to enforce a rule that is known to have caused a fork to wither and die? That was not from me. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] doc/developer: Code pushed without patches on ffmpeg-devel must be announced on the ML
Jean-Baptiste Kempf (12023-08-25): > So that means mandatory sending to the mailing list :) And change the name to libav? -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] doc/developer: Reviews must be constructive
Vittorio Giovara (12023-08-25): > NAK > we shouldn't put extra burden on reviewers, nor guilt trap them into > suggesting an alternative approach It is hilarious, in a very sad way, that you prefer put extra burden on people who do things than on people who block them. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
Rémi Denis-Courmont (12023-08-08): > I have made some preposterous statements in my dark past, but I am pretty > sure > that I didn't make any statement to that effect, no. > > I did assert that there "are dozens of people, ostensibly including [you], > that depend on FFmpeg being ""Serious OpenSource TM"" in some way, for their > livelihood, and millions for their computer use" in response to NG's argument > that FFmpeg should be turned into a fun experimental research project, and > that people who wanted to keep FFmpeg what he calls a "serious open-source > trademark" should just fork. Not “turned into”, but restored. FFmpeg *was* a fun experimental research project, and it was the reason it became so great: developers then could try things that were not tried elsewhere, they were free to take risks, to make mistakes and fix them. And the, during the second half of 2000s decade, people like you took more and more place, people who demanded absolute stability and rejected all risks whatsoever. They started giving shit to Michael, then project leader, trying to force him and everybody else to behave, according to their own standards. They wasted the time of one of the most skilled hackers in the field of multimedia having him perform tasks a few baseline technicians could do. And when it did not go as fast as they wanted, they staged a coup, with all the terrible consequences we know. Let me state it plain and clear: The fact that people and companies choose to depend on FFmpeg for their livelihood is their own problem, and their own only, it does not create ANY OBLIGATION WHATSOEVER for FFmpeg. It is even true for sponsors. They can gift FFmpeg hardware or money or hosting, they can hope that FFmpeg will progress to be even more useful to them, but FFmpeg has NO OBLIGATION WHATSOEVER to honor that hope. (Except for tit-for-tat programs with contractual rules, like GSoC.) If a sponsor tried to leverage their sponsoring to dictate the direction of the project, threatening to withhold it unless they get their way, then we should realize that sponsor is a dangerous asshole and sever all ties with them immediately. > No. You are taking for granted that SDR belongs in FFmpeg in the first place, > and that's exactly what people disagree with. And you are taking for granted that it does not belongs in FFmpeg. But what you refuse to realize is that it is only an opinion, shared by you and a few “people”, backed by zero actual arguments. As such, your opinion is worthy of very little consideration, a lot much less than the opposition opinion that is actually backed by the enthusiasm of users. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/7] avutil/bprint: Allow size == 0 in av_bprint_init_for_buffer()
Andreas Rheinhardt (12023-08-06): > The AVBPrint API guarantees that the string buffer is always > zero-terminated; in order to honour this guarantee, there > obviously must be a string buffer at all and it must have > a size >= 1. Therefore av_bprint_init_for_buffer() treats > passing a NULL buffer or size == 0 as invalid data that > leads to undefined behaviour, namely NPD in case NULL is provided > or a write to a buffer of size 0 in case size == 0. > > But it would be easy to support this, namely by using the internal > buffer with AV_BPRINT_SIZE_COUNT_ONLY in case size == 0. > > There is a reason to allow this: Several functions like > av_channel_(description|name) are actually wrappers > around corresponding AVBPrint functions. They accept user > provided buffers and are supposed to return the required > size of the buffer, which would allow the user to call > it once to get the required buffer size and call it once > more after having allocated the buffer. > If av_bprint_init_for_buffer() treats size == 0 as invalid, > all these users would need to check for this themselves > and basically add the same codeblock that this patch > adds to av_bprint_init_for_buffer(). > > This change is in line with e.g. snprintf() which also allows > the pointer to be NULL in case size is zero. > > This fixes Coverity issues #1503074, #1503076 and #1503082; > all of these issues are about providing NULL to the channel-layout > functions that are wrappers around AVBPrint versions. > > Signed-off-by: Andreas Rheinhardt > --- > Missing lavu minor version bump. Looks good to me. The other patches in the series too, but I do not maintain the channel layouts. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avformat/sbgdec: Use avio_read_to_bprint() where appropriate
Andreas Rheinhardt (12023-08-08): > Note: There is a slight difference in the handling of > the max_file_size option: The earlier code used it to mean > to limit the size of the buffer to allocate; the new code > treats it more literally as maximum size to read from > the input. > > Signed-off-by: Andreas Rheinhardt > --- > libavformat/sbgdec.c | 63 ++-- > 1 file changed, 25 insertions(+), 38 deletions(-) Both patches ok by me. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
Michael Niedermayer (12023-08-04): > Everything is there for a reason. > Every part of mp4 has a use, still we extract the data and setup various > structs like AVStream, AVPacket, AVProgram and so on. > We do not return raw mp4/mov atoms > the seperation between programs in a stream of bits/bytes looses meaning > once the frames are in AVPackets with AVStream/AVProgram. > If there is more data in any framing that people want, theres a wide range > of ways to preserve and export that data. > OTOH outputting AAC in TS or AAC is other framing is painfull to handle > especially when it is muxed into something again. because it then needs > the right framing and even if it comes in as DAB framing and the output > wants DAB framing, it is unlikely everything in the framing will be correct > for the output. > The same is true for TS. I surely can take raw TS from 3 programs but if > i just take these and concatenate them into something that suppports TS > thats quite likely going to blow up somehow. > All this framing stuff should IMHO be "removed" on the demuxer side > usefull data be extracted and properly exported. And if anything > on the muxing side needs something similar it needed to rebuild it all. > > I may be missing something but i dont think the raw framing is too usefull > to the user. I recommend you do what feels most simple, or most elegant, or most logical, whichever feels right. If somebody else, or you later, find a use for the framing, the code that removes it can be turned into code that extract information from it or reshape it. If and when that happens is the good time to figure out how to bring that information to the user, because that will be when what is necessary will be known. This is why the demands that you design a clean API first are absurd: at this point, you do not know exactly where this code is going, what kind of information or control you will need to expose. All this depends on which direction the codes takes, which in turns depends on you inspiration. And as the code progresses, the necessary API will emerge, and at one point it will be just a matter of thinking on it carefully to cut it cleanly. I suppose this is what the buzzword-living industry calls “agile programming”. But the industry cannot do it right because it needs return on investment quick. Only a real Libre Software project like FFmpeg can do that. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
Tomas Härdin (12023-08-03): > I thought of another thing that bears mentioning: Michael has expressed > interest in implementing DAB. This carries with it two problems: > > * Each DAB ensemble is an MPEG-TS stream > * There can be more than one ensemble on air > > The first means mere demodulation is not enough - MPEG-TS must also be > implemented somehow. This likely means a dependency on lavf, assuming > we are not so insane as to have two independent MPEG-TS > implementations. There might also be an impedance mismatch due to lavf > pulling bytes from avio. There's no way to "push" bytes to a demuxer. > Synchronization may be an issue, though I admit I'm not 100% sure here. > Perhaps the device can pretend to be a protocol, entailing even tighter > coupling with lavf? Also I don't think registering protocols from > outside is allowed. > > The second means that if such a DAB device is to work similar to the FM > demodulator handling multiple stations, then somehow multiple MPEG-TS > streams have to be dealt with. AFAIK lavd cannot do this. Merging MPEG- > TS streams might be tempting, but is not guaranteed to work I think. Or maybe Michael, being a very skilled hacker, will find a smart solution that will make it work without code duplication. You do not know what code he will submit. Why waste time speculating and discussing nightmare scenarios that will probably not happen on this mailing-list? > I still don't understand why this must live in lavd rather than having > a separate program that does this and does it well. There is useful DSP > code in libav* that can then be motivated breaking out into a separate > library. Oh, yes, great idea! More administrative bloat. You were complaining about wasting precious developer time on useless tasks, you should start by yourself: wasting precious developer time on maintaining extra build systems and packaging. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
Tomas Härdin (12023-07-31): > As far as I recall libxml2 does not enable the fancier features of XML > unless told to do so. And if it can't disable things like DTD then a > ticket should be opened with them to make that possible. You are missing the point: even if all these features are entirely disabled (which we cannot be really sure), the code and data structure have to be designed to make them possible. That means significantly more complex code, much more prone to bugs, including security-relevant. > It is foolish to spread scarce developer time more thinly. For that, see below. > It almost certainly means worse security, not better. I am quite sure your estimation in this is wrong. > The same goes for all things that FFmpeg reimplements. HTTP has already > been mentioned. How many developer hours have been wasted on it when > libcurl could be used instead, and a fraction of those hours going to > improving it rather than a duplicate implementation? > > I have been accused of being a "bean counter". But what are these beans > that I count? They are developer time, the sole source of value of the > free software movement as a whole. When I see things like HTTP or MXF > being reimplemented I don't see features. I see liabilities. You are neglecting a very important point here: The time of other people is not yours to count. You are not a boss directing the time of your employees towards the task most profitable for you. Michael is not hacking software defined radio to be profitable for somebody, he is having fun with it (probably because he recently got his hands on the hardware). And I want to write a parser because it is an interesting challenge. But since Michael is a very talented hacker, the result of he having fun ends up being code that is in some way already better than existing alternatives. As a member of a community project, you do not have the authority to choose what other developers work on. The only authority you have is to decide whether you will welcome the fruit of their work as an useful new feature (while being vigilant about code quality) or whether you will be so annoying about it that they give up trying to contribute to FFmpeg. As of now, you seem to be making the wrong choice. And I can tell you about my own situation: for several months now, the attitude of some developers here, including you very strongly, has mostly disgusted me from contributing to FFmpeg. The stupid farmer kills the goose with the golden eggs by opening up her belly. The smart farmer kills the goose with the golden eggs by trying to force her to lay on a schedule. > Layering is not an end in itself as you rightfully point out. It is a > tool. To what end? > In the free software world we don't layer and segregate things for no > reason. We do it so that programs can interact with each other through > standardized interfaces. The effect is a comedy of the commons. More > can be done with less labour. For an FM receiver program the > appropriate interfaces are ALSA, PulseAudio and/or JACK. That way its > audio can be piped to many programs. As you point: layering is not an end. “The scope” is not the reason, it is only a quick summary of the reasons when they are obvious and we all agree. So please stop invoking “the scope” as a reason. Second, layering is indeed something to wish for in a complex project, but it has to come organically, it has to appear progressively as the code becomes more complex and the useful boundaries and interfaces appear. When people start with layering, the result looks like the OSI model for network stacks: it makes a few nice paragraphs in textbooks and is completely worthless in practice. > It is true that we can add more features, and it is also certainly true > that these are useful for a non-empty set of users. But is it a good > use of scarce developer time? Were SDR limited to only Michael's time > then there would be no problem. But it isn't. It unavoidably touches > many other parts of the code, as we are already seeing. It is the second time you say this, and it is the second time I have to tell you: no, it is not true at all. We are seeing exactly the opposite: Michael's code is big, but it is self-contained and completely optional. Furthermore, it is not wasting any developer time. Only these sterile objections are wasting precious time. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/img2dec: added option -strftime_mkdir to allow directory creation if the strftime pattern include non-existing directories, similarly to how hls muxer does.
},
> +{ "strftime", "use strftime for filename", OFFSET(use_strftime),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
> +{ "strftime_mkdir", "create directory structure for filename, if
> needed", OFFSET(use_strftime_mkdir), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1,
> ENC },
> +{ "frame_pts", "use current frame pts for filename",
> OFFSET(frame_pts), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
> { "atomic_writing", "write files atomically (using temporary files and
> renames)", OFFSET(use_rename), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
> -{ "protocol_opts", "specify protocol options for the opened files",
> OFFSET(protocol_opts), AV_OPT_TYPE_DICT, {0}, 0, 0, ENC },
> +{ "protocol_opts", "specify protocol options for the opened files",
> OFFSET(protocol_opts), AV_OPT_TYPE_DICT, {0}, 0, 0, ENC },
> { NULL },
> };
>
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
Michael Niedermayer (12023-08-02): > The libraries should be split into runtime loadable plugins > Not only would that make tools alot smaller it also would allow > development of code available in ffmpeg that is maintained outside > FFmpeg. > > I suggested this previosuly, it is of course not a "simple" thing > to do. No, it would be a terrible mistake. And mostly, people who suggest or demand that do it based on misconceptions about how linking works and/or have no actual scenario where that would help. But this is another discussion entirely. For this discussion, it is enough that the libavradio device is just another device with one or a few source files enabled by the build system, and that disabling it is just a “--disable-” away. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
Brad Isbell (12023-08-02): > As a frequent FFmpeg user, and an occasional RTL-SDR user, the major > tradeoff for me is in the size of FFmpeg binaries vs. features. I > agree with Jean-Baptiste that if this were an optional library to be > added to the build, then that resolves any issues I might have as a > user. > > Then I have the choice to opt for the big honkin' beast build that > includes all-the-things on my daily dev machine, but can still build > targeted builds for deployment to production servers, oddball > platforms like WASM, etc. What you describe is already the case, for the avradio device just the same as for any other component. > On Wed, Aug 2, 2023 at 7:59 AM Jean-Baptiste Kempf wrote: Please do not top-post. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] What is FFmpeg and what should it be
Kieran Kunhya (12023-07-30): > I plan to write a more detailed response to Nicolas' email. However, > this response is superb because it immediately points out the flaw in > the arguments. Users will not tolerate "incomplete" features, they > will always want their edge case (packet capture replay) to work. This > is Open Source, there are no product managers and roadmaps to > constrain user requests so we have to decide as a community what is in > scope and what is not. “Patch welcome.” And IF it becomes too big, we can discuss splitting it into a separate library. But as long as a new feature doesn't metastasize into the common code, as long as it stays optional, there is no ground to oppose it, imaginary “scope” or not. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] What is FFmpeg and what should it be
Kieran Kunhya (12023-07-28): > FFmpeg doesn't implement TCP in userspace, it doesn't implement the > WiFi protocol etc etc. Different layers are delegated to different > programs. Hi. You seem to be discussing this in more good faith than I previously imagined, so I will try to tone done the irritation in my mails. I am also changing the subject of the mail, so that more people will have a look at it. I have already posted about my conception of what FFmpeg is and should be in the previous mail: http://ffmpeg.org/pipermail/ffmpeg-devel/2023-July/312735.html There are at least two necessary conditions for something to go into FFmpeg: that it is useful to users, at least a few of them, and that somebody bothered to write the code. FFmpeg is designed to run under an operating system, where a network stack is usually available whenever network hardware exists, so there is absolutely no need for that in FFmpeg. But if people started to routinely use FFmpeg on some kind of bare-metal microcontroller where network hardware exists but the official network stack is too big to share the space with FFmpeg, and if somebody were to propose a limited network stack based on lavu's cryptographic primitives, then it would totally make sense to accept it. Yes, this example is far-fetched, because you chose a case where only a far-fetched example works. You insist on having different layers, and I agree it is somewhat relevant. But remember: the Internet is not built on the nice theoretical layers of the OSI model. The protocols of Internet are much more messy, because they insist more on pragmatism than aesthetics, and that is what made their success. If there are well-defined layers, then probably the others layers are already implemented, the “different programs” exist, are very satisfactory and very widely available. Then FFmpeg does not need to have them natively. But if these “different programs” for different layers do not exist, or are not satisfactory, or are not widely available, then we have to develop them. And if that happens, it would be idiot to force them to be separate projects. Maybe later, when they have become stable, and other programs use them, it will make sense to split them into their own separate project. But in the beginning, it is a waste of effort. > Is FFmpeg going to implement HTTP3 (QUIC) in full? QUIC is a layered protocol. I do not know. I have followed things from afar, does HTTP3 brings benefits from users, apart from more efficient tracking and faster delivery of ads? Anyway, your sentence brigs a point that is very important: *** IT DOES NOT HAVE TO BE COMPLETE TO BE USEFUL. *** See below for more about it. > All of your examples are small and self-contained. SDR is definitely > not small and self-contained. It's a field bigger than multimedia and > there are many layers of framing inside. Michael's code seems pretty self-contained to me. And once again: *** IT DOES NOT HAVE TO BE COMPLETE TO BE USEFUL. *** As far as I understand it, if I bought the hardware tomorrow, the code that Michael already wrote, and that is a tiny little bit of the whole field of SDR, would already bring me features that are not available in any other piece of Libre Software, or possibly at the cost of fragile plumbing. This is enough of an argument to warrant inclusion. And it does not make sense to insist that one of our most talented developers waste his time with the trouble of maintaining a separate project just to satisfy aesthetic considerations of “proper layering”. I have another example of “it does not have to be complete to be useful”: XML. The whole XML standard is quite complex, it involves DVD and schema validation, loading external entities, etc. But the use of XML in multimedia is much more limited, it only involves parsing “”-style text. Now, “proper layering” dictates using a real XML library. But real XML libraries are designed to support most of the standard, and that affects their design as a whole. That means every time we use a real XML library to parse “”, we pay the price for the complexity of the whole language, in terms of efficiency, reliability, security exposure. If we had our own parser for “”, we would have to pay a price only once. “Proper layering” has benefits, but it also has costs. Therefore it is a bad idea to adhere to it dogmatically. FFmpeg has been successful because it relied on pragmatism rather than dogmatic adherence to principles. Let us continue that way. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 0/4] Fix MSVC build without optimizations
Reimar Döffinger (12023-07-28): > I assume the issue is missing symbols during linking? > If you really want this, why not create a file that provides dummy > symbols for all that are missing, concentrating the #if mess in > a single place and avoiding affecting any of the regular code, and thus > having no impact at all when compiling with optimizations. > Yes, it's likely to be a good bit of maintenance effort for those who > want to use it, but at least anyone not caring about this feature can > ignore it, so at least I would not have a reason to be against it. This is an interesting idea. It would even be possible to include a tool that generate these stubs directly from the linker's errors, reducing the maintenance. Maybe even make the stubs static inline functions rather than actual linking symbols. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
Michael Niedermayer (12023-07-27): > Now gqrx needs me to manually enter the frequency, the modulation the > device, then it still doesnt work (first one has to know why from multiple > rtlsdr lines some dont work) and once one is through this it still > doesnt work, all AGC methods dont work, i have to set the gain manually > for the station i want to listen to to have acceptable quality. I do know > but at this point we lost likely 90% of users already who dont realize that > the AGC sets a too high gain Also, can gqrx (or other tools based on the same backends) record from a V4L device at the same time, process the video to add text or overlay a logo or decrease the noise, process the audio to normalize the volume or mix it with background music, encode it into a variety of codecs and save the result into a file while at the same time publishing it as a Youtube Live stream? Because if something is integrated, then ffmpeg can do all that. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
Kieran Kunhya (12023-07-25): > You can have satisified users without having to implement SDR in a > multimedia library, nor xml parsing, nor a web server, nor anything > else that sits at a higher or lower level than FFmpeg. Satisfied users is not a yes/no thing. There was a branch of the fork with more features and more satisfied users, and a branch of the fork with less features and less satisfied users. The second one died, and good riddance. We are on the branch of the fork that wants more features even if it means a few hacks. Accept it or work on the other branch. > It's not just multimedia that goes over radio, it's not just > multimedia that goes over TCP, it's not just multimedia that needs > XML, that's why there are separate libraries for these kind of things. It is not just multimedia that can be encrypted, yet FFmpeg has cryptographic primitives. It is not just multimedia that can go over HTTP, yet FFmpeg has support for HTTP — limited to its needs. It is not just multimedia that requires Fourier transforms and similar mathematical operations, yet FFmpeg has them too. > FFmpeg is not the kitchen sink of miscellaneous wheel reinvention. I reject the disparaging “kitchen sink”, but apart from it, YES, FFmpeg is exactly that, or at least it was some time before the fork. Then some people pushed for more seriousness, more stability, which meant less creativity. And seeing their efforts to make the project more serious, more stable and more sterile were not succeeding enough, they tried to take over, that resulted in a fork that almost killed the project. And we, on the FFmpeg side, made the mistake to try to entice them back. We changed for that, we made the project more serious, more stable, more sterile, to try and convince them to come back. We should not have done so. Instead, we should have reaffirmed what makes FFmpeg not libav, and demanded THEY change to be welcomed back. And so the trend towards more seriousness, more stability, more sterility, continued. Amplified by people who started business to exploit FFmpeg, and have a personal interest in the project being more serious, more stable, and don't care it's more sterile. But before that evolution, what FFmpeg success in the first place, was precisely that it was a welcoming place for development in the multimedia field. Not just a narrow version of “the scope”, but anything related to multimedia, or useful for it. Not just things that do not exist elsewhere but also projects to invent new and creative ways of doing it. And since that ambiance attracted very talented hackers (including you personally, as far as I could see), it frequently gave impressive results. So yes, being able to use SDR devices to record AM/FM on the fly from ffmpeg or any FFmpeg-based application is worth a few hacks here and there. And yes, being able to read network streams defined by XML manifests without linking to the big stinking pile of shite that is libxml2 is worth having our own XML parser, limited to exactly what we need instead of supporting the whole complex format. And so on and so on. FFmpeg is a place for creativity. If you do not agree, try to remember why you came here in the first place. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libaformat: fix incorrect handling of incomplete AVBPrint.
Reimar Döffinger (12023-07-27): > Thanks, sent a new version with that updated, plus a fix for a typo > in the commit message. If it is all you have changed, then I do not think I need to look at it again. I do not maintain most of the files you have changed, but I think you can go ahead. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libaformat: fix incorrect handling of incomplete AVBPrint.
reimar.doeffin...@gmx.de (12023-07-23): > From: Reimar Döffinger > > Change some internal APIs a bit to make it harder to make > such mistakes. > In particular, have the read chunk functions return an error > when the result is incomplete. > This might be less flexible, but since there has been no > use-case for that so far, avoiding coding mistakes seems better. > Add a function to queue a AVBPrint directly > (ff_subtitles_queue_insert_bprint). > Also fixes a leak in lrcdec when ff_subtitles_queue_insert fails. > --- > libavformat/assdec.c | 4 +++- > libavformat/lrcdec.c | 7 ++- > libavformat/mpsubdec.c | 5 +++-- > libavformat/realtextdec.c| 6 +- > libavformat/samidec.c| 6 +- > libavformat/srtdec.c | 4 +++- > libavformat/subtitles.c | 17 + > libavformat/subtitles.h | 14 -- > libavformat/tedcaptionsdec.c | 2 +- > libavformat/webvttdec.c | 4 +++- > 10 files changed, 54 insertions(+), 15 deletions(-) Sorry I forgot I meant to review. These changes look for the best, except > +if (!av_bprint_is_complete(event)) return NULL; > +if (i == INT_MAX) return AVERROR_INVALIDDATA; … which do not follow the coding style. (The dynamic buffer writer of the AVWriter API makes it much harder to forget checking. But AVWriter is currently in limbo waiting for this project to reaffirm its orientation.) Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
Kieran Kunhya (12023-07-25): > As we have seen in FFmpeg, APIs are "designed" around basic things > like AVI and hacks upon hacks are needed to support anything more > complex. The API being written around AM/FM is history clearly > repeating itself. > > Unlike you, quite a lot of people are able to comprehend this now and > don't want history repeating itself. I know all that, I was here as well as you. But there are two things that you refuse to acknowledge (because I will not stoop to the discourteous suggestion that you are not intelligent enough to comprehend it): One, most of these “hacks” are in limited and optional parts of the code. I you do not like them, you just have to not look at them and they are not your problem. And if at some point they become nobody's problem, then removing them is very easy. Two, a lot of our users are very happy of the consequences of these hacks. They like that their favorites applications have gained new features transparently. Even if it is limited and awkward, because limited and awkward is better than nothing, and using other, specialized applications for these features would bring a different brand of limited of awkward. If you would rather FFmpeg be a perfect pearl of beautiful design developed in an ivory tower with no regards for the satisfaction of users… there is a project for that, it is called libav. And guess what? It died because of that attitude. In the meantime, the patches we are discussing for now are not even hacks. So if you and Thomas only have a slippery slope fallacy against them, we will give you exactly as much consideration as fallacies deserve. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
Kieran Kunhya (12023-07-25): > This is a completely incorrect and poorly thought through statement. > AM/FM are a microscopically small subset of SDR. > SDR is a massively complex field, bigger than multimedia itself. There > are permutations and complexity in things like DAB/DVB etc much more > complex than anything the FFmpeg API can handle (e.g physical layer > pipes). > > To draw the conclusion that all SDR is now fine in FFmpeg beacause in > your mind AM/FM did not require a large number of changes to FFmpeg is > incorrect to say the least. Applying support for AM/FM now does not force us to accept support for more complex parts later, and support for what is now there is already an interesting feature. In other words, please all stop engaging in the slippery slope fallacy: reject objectionable patches if they ever come but stop blocking reasonable features. Also, trust Michael to be able to realize when to stop. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
Tomas Härdin (12023-07-24): > Such libraries already exist. Libraries that need talented developers > working on them. Something that I have already suggested, but it > appears to be falling on deaf ears. Which is a shame. > > GNU Radio Companion can be used to generate Python code that does > everything that avradio tries to do, including GUI code. This code can > then be further massaged to one's individual needs, the heavy lifting > already being handled by gnuradio's DSP stuff. If Michael wants to write everything from scratch to learn and discover rather than just adding tidbits here and there to an existing project, that is entirely understandable. FFmpeg was made by somebody who wanted to write everything from scratch to learn and discover, after all, and at no point was it decided “no more, now we serve the interests of our sponsors and everything else is ‘out of scope’”. If Michael wants to work within the framework of FFmpeg and its signal processing features rather than within the framework of Python, that is entirely understandable too. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
Tomas Härdin (12023-07-24): > Features either are or aren't in scope. I don't see how you can > compromise on that. The scope is what we decide it is, collectively, based on arguments. Your conception of the scope is only a small part of that, and even smaller if you cannot sustain it with arguments. “I don't see how you can compromise on that” is called dogmatism and has no place in this project. The way I see it, avradio has about as much or as little its place in a project that historically contained software implementations of the major and minor multimedia codecs as hardware acceleration. Yet support for hardware acceleration has been added, to the convenience and satisfaction of everybody. > The Linux kernel also has separation of concerns. It has a concept of > userland for example, unlike say TempleOS. Not everything is in scope > for the Linux project. Yet features have repeatedly made back and forth between kernel and userland and mixed implementations, searching for the sweet spot of compromise between performance, security and convenience. Proof that “the scope”, even when there is a much more clearly delineated frontier, is fluid and a matter of compromise. If you cannot accept compromise, then your opinion should not be taken into consideration in a functioning collective project. > I have 63 forks of ffmpeg alone. I don't see the problem. I am doubtful whether this is to be considered a good thing or a bad thing, but I am rather leaning towards bad. > As for me being loudest, someone has to be. As a licensed amateur radio > operator I also happen to have domain knowledge, which is why I know > radio stuff will affect the code in profound ways, as we are already > seeing evidence of. These are hard-gotten learns. Well, if you are right, then we will see patches on the mailing list that will affect the code in profound ways, and you will be able to object to them then. But far from “already seeing evidence” of the apocalypse you predict, we see that the avradio code already delivers features while being self-contained and only required extending the signal processing abilities of our libraries a little, and in ways that are useful to other developers. So I guess it proves being licensed to operate something does not make you qualified to evaluate the difficulty in implementing the software of that thing. What a surprise. I will add that “affect the code in profound ways” was actually true for hardware acceleration, requiring a big mess in the code and significant to the internal API and even public API and user interface. Yet nobody is objecting to them. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [TC] checkasm: use pointers for start/stop functions
Martin Storsjo (12023-07-25): > The TC has discussed the matter at hand. The TC (and CC) has been elected for a year in July of 2020. That means your mandate is two years expired. This decision is therefore not binding. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/1] avfilter/buffersink: Add video frame allocation callback
Paul B Mahol (12023-07-23): > Your comment is extremely rude and unhelpful. I am sorry for any perceived rudeness. Shall I point each time I find your comments to me extremely rude and/or unhelpful too? > The patch at best only replaces last get_buffer call of buffersink. Yes, indeed, that is exactly what this patch does, and that is exactly why it is useful, anybody involved in the library as you are should be able to spot it in an instant. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
Michael Niedermayer (12023-07-24): > There are other pathes forward but thats the current plan _IF_ this > isnt killed off by the community and _IF_ others join and enjoy > working on this. Also nothing is cast in stone, this plan is intended > to be adapted as needed on the way. I would love to play with this, but apart from the lack of time, I suspect using these patches requires some hardware I do not have. Can you tell a little about it? Also, is it only for receiving? It is there, at least as a potential, the possibility of sending, maybe in the Citizen Band? > Theres a point where > i will move on and switch the bulk of my time to "not FFmpeg" and just do > payed work here. That would be very sad — but having myself set all FFmpeg development on back-burner until the project becomes welcoming again, I fully understand the feeling. I hope before coming to that you will consider taking part in an effort to take back the project from the bean counters. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
Tomas Härdin (12023-07-23): > No to this entire patchset. 404 argument not found. > Users can test libavradio's master if they wish. Do not assume merging > this fork will happen, especially not without TC approval, nor that > trying to sneak it in won't be noticed and opposed. A striving Libre Software project works by compromise. I see no intent of compromise at all in your position. > Why would they package it when there already are mature programs like > gqrx, dablin etc? Programs that feature separation of concerns. See for > example hacktv which uses ffmpeg, libhackrf and libsoapysdr without > insisting on being part of either Oh, yes. And these idiots working on the Linux kernel, why do they waste their time when Windows and MacOS are excellent for everybody? And the Vim team, do they not know that LibreOffice can do everything better? Why bother maintaining i3 and Fvwm when Gnome is so much better? Why develop Perl modules? Python for everybody! Seriously, if you have to ask, you are at the wrong place. >I know this because it's going to cause headaches for this > project to care about maintaining compatibility with a fork that > doesn't want to pretend it's a fork. This is very dishonest. Maintaining a fork only causes headaches to the people who do it, and you have made amply clear that would not be you. In fact, quite the opposite, you were one the loudest demanding that one of our most talented hacker waste his time on maintaining a separate build system instead of doing creative and useful work. I say: let us merge this fork that should never have been separate, for the convenience of Michael and of potential users. Then let us reaffirm that FFmpeg is a place for hackers to be creative in the general field of multimedia, the place to foster new ideas, new solutions, new ways of writing efficient code, rather than a wrapper around other libraries and obsolescent native code for the convenience of other projects and commercial companies. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/1] avfilter/buffersink: Add video frame allocation callback
Paul B Mahol (12023-07-23): > - missing audio support You realize that direct rendering is order of magnitude more useful for video frames than for audio, right? > - missing full internal buffers allocation replacement support Nonsense. > - missing/untested hardware acceleration support Direct rendering is especially useful for software, that is the point. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/1] avfilter/buffersink: Add video frame allocation callback
James Almer (12023-07-23): > What about when FF_FILTER_FLAG_HWFRAME_AWARE filters are present in the > graph? hw_frames_ctx from AVFilterLink can't be accessed from outside lavfi. > Is vf_hwdownload meant to be added to the graph before buffersink? I do not know how hardware acceleration works at all. (The tidbits of discussion I catch left me the impression all of it is very badly designed, but I have low confidence in that impression.) If this API only works with filters that output software frames, it is already very useful. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/1] avfilter/buffersink: Add video frame allocation callback
James Almer (12023-07-23): > Does the AVBuffersinkAllocVideoFrameFunc function have access to the > AVFilterLink ff_default_get_video_buffer() gets? I assume it'd be needed to > get values like pixel format. If so, it should be documented how, but maybe > it's easier to just pass link here instead of the AVFilterContext, and let > the caller access link->dst if needed. The API of buffersink already exposes all the necessary format information. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/1] avfilter/buffersink: Add video frame allocation callback
John Cox (12023-07-22): > Finger trouble - repost of previous patch - please ignore No problem, I was about to make the remark. But please do not Cc people who have not asked for it. Especially when the mail says "Reply-To: ffmpeg-devel@ffmpeg.org". Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/1] avfilter/buffersink: Add video frame allocation callback
Paul B Mahol (12023-07-22): > What about an audio? Are we in the business of refusing a patch adding an interesting feature because we want two interesting features instead? > This works only for sinks mostly, what about filters inside graph? It is already in place, it has been for years. This patch only adds the API to expose it publicly. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/1] avfilter/buffersink: Add video frame allocation callback
John Cox (12023-07-20):
> Add a callback to enable user allocation of video frames on the final
> stage of a filter chain.
>
> Signed-off-by: John Cox
> ---
> libavfilter/buffersink.c | 21 +
> libavfilter/buffersink.h | 27 +++
> libavfilter/version.h| 2 +-
> 3 files changed, 49 insertions(+), 1 deletion(-)
Hi.
Thanks for the patch.
>
> diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
> index 306c283f77..070b743186 100644
> --- a/libavfilter/buffersink.c
> +++ b/libavfilter/buffersink.c
> @@ -62,6 +62,11 @@ typedef struct BufferSinkContext {
> int sample_rates_size;
>
> AVFrame *peeked_frame;
> +
> +union {
> +av_buffersink_alloc_video_frame * video;
> +} alloc_cb;
> +void * alloc_v;
Here and everywhere: our coding style puts a space before the * but not
after.
> } BufferSinkContext;
>
> #define NB_ITEMS(list) (list ## _size / sizeof(*list))
> @@ -154,6 +159,21 @@ int attribute_align_arg
> av_buffersink_get_samples(AVFilterContext *ctx,
> return get_frame_internal(ctx, frame, 0, nb_samples);
> }
>
> +static AVFrame * alloc_video_buffer(AVFilterLink *link, int w, int h)
> +{
> +AVFilterContext * const ctx = link->dst;
> +BufferSinkContext * const bs = ctx->priv;
Nit: it is called buf in the rest of this file.
> +return bs->alloc_cb.video ? bs->alloc_cb.video(ctx, bs->alloc_v, w, h) :
> +ff_default_get_video_buffer(link, w, h);
Nit: align ff_ with bs->.
> +}
> +
> +void av_buffersink_set_alloc_video_frame(AVFilterContext *ctx,
> av_buffersink_alloc_video_frame * cb, void * v)
> +{
> +BufferSinkContext * const bs = ctx->priv;
> +bs->alloc_cb.video = cb;
> +bs->alloc_v = v;
> +}
> +
> static av_cold int common_init(AVFilterContext *ctx)
> {
> BufferSinkContext *buf = ctx->priv;
> @@ -381,6 +401,7 @@ static const AVFilterPad avfilter_vsink_buffer_inputs[] =
> {
> {
> .name = "default",
> .type = AVMEDIA_TYPE_VIDEO,
> +.get_buffer = {.video = alloc_video_buffer},
> },
> };
>
> diff --git a/libavfilter/buffersink.h b/libavfilter/buffersink.h
> index 64e08de53e..73f0ddc476 100644
> --- a/libavfilter/buffersink.h
> +++ b/libavfilter/buffersink.h
> @@ -166,6 +166,33 @@ int av_buffersink_get_frame(AVFilterContext *ctx,
> AVFrame *frame);
> */
> int av_buffersink_get_samples(AVFilterContext *ctx, AVFrame *frame, int
> nb_samples);
>
> +/**
> + * Callback from av_buffersink_set_alloc_video_frame to allocate
> + * a frame
> + *
> + * @param ctx pointer to a context of the abuffersink AVFilter.
> + * @param v opaque pointer passed to
> + * av_buffersink_set_alloc_video_frame
> + * @param w width of frame to allocate
> + * @param height of frame to allocate
> + *
> + * @return
> + * - The newly allocated frame
> + * - NULL if error
> + */
> +typedef AVFrame * av_buffersink_alloc_video_frame(AVFilterContext * ctx,
> void * v, int w, int h);
In the rest of the API, function typedefs are always pointer-to-function
typedefs.
Also, I find this typedef looks too much like actually a function, maybe
use CamelCase.
> +
> +/**
> + * Set a video frame allocation method for buffersink
> + *
> + * @param ctx pointer to a context of the abuffersink AVFilter.
> + * @param cb Callback to the allocation function. If set to NULL
> + * then the default avfilter allocation function will
> + * be used.
> + * @param v Opaque to pass to the allocation function
> + */
> +void av_buffersink_set_alloc_video_frame(AVFilterContext *ctx,
> av_buffersink_alloc_video_frame * cb, void * v);
> +
> /**
> * @}
> */
> diff --git a/libavfilter/version.h b/libavfilter/version.h
> index c001693e3c..54950497be 100644
> --- a/libavfilter/version.h
> +++ b/libavfilter/version.h
> @@ -31,7 +31,7 @@
>
> #include "version_major.h"
>
> -#define LIBAVFILTER_VERSION_MINOR 8
> +#define LIBAVFILTER_VERSION_MINOR 9
> #define LIBAVFILTER_VERSION_MICRO 102
A test program would be nice too. I assume you have something to test
your code: would it be a lot of work to make it public?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] git email hook
Michael Niedermayer (12023-07-15): > COMBINED_REFCHANGE_REVISION_SUBJECT_TEMPLATE = ( > '%(emailprefix)s%(refname_type)s %(short_refname)s updated: %(oneline)s' > ) Setting this to: '%(emailprefix)s %(oneline)s (%(refname_type)s %(short_refname))' would yield: [ffmpeg-radio] avradio/sdrdemux: Some corrections to the FM stereo side channel (branch master) instead of: [ffmpeg-radio] branch master updated: avradio/sdrdemux: Some corrections to the FM stereo side channel and is much closer to what we have now. Maybe also get rid of %(emailprefix)s, since the mailing-list will add its own. Thanks. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/x86/mathops: use constrained immediate operands
James Almer (12023-07-15): > Should fix assembling with binutil as >= 2.41 > > Signed-off-by: James Almer > --- > This is IMO a big breakage. binutil's as has until now clipped these values on > its own, and never required the compiler to do it. I confirm it fixes the build failures on up-to-date Debian testing. OTOH, I ran a benchmark (decoding some x264): 474134 mod 488751 orig 494359 mod 498554 orig 508958 orig 514246 orig 518160 mod 528427 orig 530223 mod 534762 mod 536415 orig 548434 orig 550789 orig 551716 mod 553951 orig 561754 orig 572688 mod 580254 mod 581205 orig 583856 mod 583939 orig 584748 orig 594143 orig 600681 mod 607596 mod 612757 mod 621033 orig 624567 orig 626346 mod 627309 mod 628242 mod 638344 mod The numbers are the sum of the “user” column of the -benchmark_all output, on an AMD Ryzen 3 3200U and Debaian stable. The mod lines are when I disabled the two faulty functions. They are all over the place, it is hard to be sure, but it seems to indicate that, as you suspected, the benefit is not that big. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] git email hook
Michael Niedermayer (12023-07-14): > I today added and tested git-multimail to git.ffmpeg.org as our git mail > sending script is old and unmaintained > > I intend to use libavradio for testing it, this will result in > different looking mails for avradio. (probably on the next push in a day or 2) > If that goes well i intend to switch ffmpeg-web and all repositories > that are on git.ffmpeg.org over to it too. But its easy to leave some > on the old script if people prefer. > I hope though the new will produce nicer mails. > (this is unrelated to git master for which videolan is doing the git mail) > > No ill sideeffects are expected but unexpected things are always possible. Hi. Can the "branch master updated:" be removed? We only work on master anyway, it takes up space and the interesting part of the commit subject gets truncated. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Build failure un Debian Testing
James Almer (12023-07-13): > Curious that they pull git snapshots of this package for Debian testing. For > others they seem to stick to tagged releases. I do not understand what you mean. *I* pulled my work tree to the head to fix a bug in the OpenGL device, it was the first time since Testing was unfrozen, and I noticed it fails to build. > This definitely sounds like a regression in binutils, so other than > reporting it upstream, i don't see much more we can do. It could also be a case where we have been using a slightly invalid and unsupported construct. My knowledge of assembly stopped at the 386, so I cannot tell which one it is, but I think the likeliness are balanced. Somebody more skilled will look at it, hopefully. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Build failure un Debian Testing
Hi. We currently have a build failure on Debian Testing (and certainly Unstable): CC libavformat/adtsenc.o src/libavcodec/x86/mathops.h: Assembler messages: ×19 src/libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr' make: *** [src/ffbuild/common.mak:81: libavformat/adtsenc.o] Error 1 CC libavformat/av1.o src/libavcodec/x86/mathops.h: Assembler messages: ×47 src/libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr' It can be worked around by commenting: #define NEG_SSR32 NEG_SSR32 #define NEG_USR32 NEG_USR32 near the end of libavcodec/x86/mathops.h. According to comments on bug trackers, it might be related to binutils 2.40.90 (versus 2.40 from stable). I do not know how to fix this kind of error, but I can help if a change needs testing and somebody does not have a Debian Testing with enough libraries installed. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavu/avassert: include config.h
Anton Khirnov (12023-07-12): > I do not see this patch on the mailing list. You need to look better, just like for the benefits of good infrastructure APIs. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] lavu/avassert: include config.h
Nicolas George (12023-04-26): > Updated version attached, similar to what exists in common.h. Pushed. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [FFmpeg-cvslog] fftools/ffmpeg: move each muxer to a separate thread
Anton Khirnov (12022-07-23): > ffmpeg | branch: master | Anton Khirnov | Thu Mar 31 > 17:33:48 2022 +0200| [2d924b3a630869c65fe0c76568910500f54ed057] | committer: > Anton Khirnov > > fftools/ffmpeg: move each muxer to a separate thread > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=2d924b3a630869c65fe0c76568910500f54ed057 This broke: “ffmpeg -i whatever -f opengl -” that can be used to preview the result in real time. I will be looking how to fix it. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/developer: Make tests a requirement
Paul B Mahol (12023-07-04): > Tyrants and dictators. I would not have said it that way, but you are not wrong. While in theory it would be nice to have tests for all new code, the entitlement of the members of this project who contribute little code or none at all who demand ever more and more from those who do is sincerely disgusting. They think they can get away with it because they believe they control access to the project and the prestige of being published in FFmpeg will push anybody to jump through hoops. Well, they are wrong on the second point, nothing new happened in FFmpeg except interfacing with other code, the prestige is melting like a glacier in the XXIst century. So let us make sure they are wrong on the first point. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 0/1] avformat: add Software Defined Radio support
Lynne (12023-07-02): > git master is not a playground, but it is certainly a place for developers > to experiment with ideas they're *seriously* exploring. > > Sonic and Snow were experiments. They didn't work out, but nevertheless, > they made their mark on the status quo of compression research at the time. > > FFV1 was an experiment. It worked out, being an IETF standard. > The native mpeg encoders were experiments. They worked out, and their > rate control system largely inspired x264's rate control systems. > The DNN filtering stuff was an experiment. It didn't work out.The native Opus > encoder was an experiment, and it holds up well against > libopus, if a bit slow and misguided. > The AAC encoder was always an experiment. Did it work out? Let's > find out after the third rewrite :) Thanks for the history. This is what I called a playground for hackers; a rose by any other name. > As for libavsdr? Time will tell. But it's certainly got a niche to fill, > as currently, you have to setup large and complex gnuradio filterchains. > But, I would prefer for it to be in a separate repository. I have a hard time understanding this preference, for both avradio and avstream. Moving to a separate repository requires you to maintain a separate build system, separate tests, etc. It also means only enthusiast users will download and install the library, thus greatly reducing both its usefulness and its changes of getting off the ground. It seems to me like a lose-lose situation. I can understand why people only interested in their short-term revenue stream would object, but people who work on them I do not understand. Can you explain? Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 0/1] avformat: add Software Defined Radio support
Jean-Baptiste Kempf (12023-07-02): > Unfortunately, for both questions, I think you are in the minority. > But if you want, we can call an AG vote. You can do so, but be sure to write the question in the way things will happen: “Do you want to continue making FFmpeg a hostile place for hackers who want to have fun, driving them away and sterilizing the process, in the vague hope to gain some more revenue for jb and his friends?” Because you cannot force talented people to work on your schedule. It is sad to see you trying to use the very rules that were put in place to prevent the likes of libav from stealing the project's infrastructure and name recognition in order to steal the project from the people who made it great. It would be 100% legal and within the rules, but stealing nonetheless. Michael is a thousand times more FFmpeg than you. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 0/1] avformat: add Software Defined Radio support
Michael Niedermayer (12023-07-02): > as libavradio so far has been the only actionable suggestion. > ill move the code to that and next revission or the one after that > will be in libavradio. Please only do that if it makes working on the code easier for you. These people will not take concessions and accept your code. They will take every conception you make and demand more, the only thing they will accept is if you stop “wasting” your time on it and go back to work that can increase their revenue stream. Ignore them. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 0/1] avformat: add Software Defined Radio support
Jean-Baptiste Kempf (12023-07-02): > Absolutely not. > You are the only one who believes that. Except for the person who created FFmpeg in the first place. And probably other people too. Most great Libre Software projects are hackers playgrounds first. They become immensely useful as a byproduct. There is a classical fable to illustrate the shortsightedness of people who want FFmpeg to be a Serious OpenSource Project TM, it's called The Goose that Laid the Golden Eggs, I assume everybody knows how it ends. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 0/1] avformat: add Software Defined Radio support
Rémi Denis-Courmont (12023-07-02): > Otherwise it's not offensive and inflammatory. Rather it's insulting and > defamatory. “Bean counter” was derogatory, but against an attitude like yours, not against a matter of lower of higher. This kind of strategy to assassinate my character is not very honorable, but not very surprising either. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 0/1] avformat: add Software Defined Radio support
Martin Storsjo (12023-07-01): > As numerous others have said already, this is at the wrong level of > abstraction, even if it happens to work for you for the current use case. Then say what yopu think is the right level. > Even if it is disabled by default, git master isn't a playground for > personal projects. Yes it is. We are not libav. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
Tomas Härdin (12023-07-02): > On Debian these are provided by apt same as all other libraries > including libc, so yes. By this reasoning, xbill would be considered a system library. Try again. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 0/1] avformat: add Software Defined Radio support
Michael Niedermayer (12023-06-30): > And if we could put it in git master then people could work together to > build the libavradio out of it as we all want. > > Such collaboration is kind of one of the reasons of having a "git master" I want you to continue writing your great code where it is the easiest to install and enjoy for users and to contribute for others. Right now, at the very beginning of the project, and since you are very familiar with FFmpeg, a part of FFmpeg is the right place. The bean counters who tell you otherwise are actually not very good at counting beans, when it is not their own. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
Tomas Härdin (12023-06-30): > Factually incorrect. libxml2 provides what we need. libexpat would also > be acceptable. In fact providing that option may be useful to > packagers. Do you consider these to be system libraries? > ABI and API stability are Pretty Fucking Important. This attitude alone > is reason to withdraw push access. Good thing you do not have this kind of authority. It could be argued that this kind of authoritarian attitude should be a reason to kick *you* out. > What do you think the point of this project is? The point of FFmpeg is for hackers to have fun and produce great code. Little hands can come later and polish the result so that is can be used even by lusers. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 0/1] avformat: add Software Defined Radio support
Tomas Härdin (12023-07-01): > Just start a separate project or contribute to GNU Radio or osmocom or > whatever. How is this so difficult to grasp? Yeah, handling a separate project and maintaining a separate built system is the best use of the limited time of one of the best hackers in the FFmpeg project. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
Tomas Härdin (12023-06-29): > This is very revealing. Indeed. > The reason why XML parsing shouldn't be > implemented in FFmpeg isn't just because it is difficult but because: > > * it is out of scope It is necessary. > * it is technical debt > * shitty parsing is the cause of the vast majority of CVEs > > It speaks of an inability to make sane architectural decisions, of not > seperating concerns and of preferring cowboy coding over sane decisions > with respect to the entire free software ecosystem. Thank you for illustrating my words with your inability to consider that (1) we do not need a complete parser (2) the things that make parsing XML hard are precisely the things we do not need and (3) if you consider writing such a XML parser is way too hard, it speaks more of your skills in that area than anything else. > Are you implying that API and ABI stability are not important? Precisely. Nothing is “important” in absolute?. Things are only important with regard to a goal. My goal is to have fun, and for that goal, API and ABI stability are not important. To have fun, I still need the project to exist, so I will spend time on these issues, that is all. API and ABI stability are important if you want to be of service. I do not want to be of service. Maybe you want FFmpeg to be of service, you seem to. Well, let me tell you this: if you want to force me to not have fun and spend effort on things you think are important instead, go fork yourself. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
Tomas Härdin (12023-06-27): > I propose we add the ability for ffmpeg to send email. After all some > users might find that useful. And because many users use webmail we > should also implement HTML parsing. If you like to work on it and manage to produce something that integrates elegantly in the framework, then by all means, go ahead. Please, do it. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
Tomas Härdin (12023-06-27): > Yes those are all fine use cases. But that doesn't explain why they > belong in FFmpeg rather than say a driver that turns generic SDRs into > V4L FM devices, or a dedicated GUI application. They can be implemented in any of these pieces of software, including FFmpeg, and each solution will have its own set of benefits and drawbacks in terms of performance, features, user interaction, etc. In other words, a simple point of logic: X can Y does not imply X cannot Z for all Z not equal to Y. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [WIP] [PATCH 1/2] lavfi/framesync: support filters with multiple outputs
The filters will have to provide the logic to set the status
and check for a wanted frame.
Signed-off-by: Nicolas George
---
libavfilter/framesync.c | 46 ++---
libavfilter/framesync.h | 28 +
2 files changed, 62 insertions(+), 12 deletions(-)
Untested yet.
diff --git a/libavfilter/framesync.c b/libavfilter/framesync.c
index c748262ba6..0923e8c22b 100644
--- a/libavfilter/framesync.c
+++ b/libavfilter/framesync.c
@@ -75,6 +75,10 @@ enum {
static int consume_from_fifos(FFFrameSync *fs);
+static void default_on_eof(FFFrameSync *fs);
+
+static int default_on_miss(FFFrameSync *fs);
+
void ff_framesync_preinit(FFFrameSync *fs)
{
if (fs->class)
@@ -83,28 +87,36 @@ void ff_framesync_preinit(FFFrameSync *fs)
av_opt_set_defaults(fs);
}
-int ff_framesync_init(FFFrameSync *fs, AVFilterContext *parent, unsigned nb_in)
+int ff_framesync_postinit(FFFrameSync *fs)
{
-/* For filters with several outputs, we will not be able to assume which
- output is relevant for ff_outlink_frame_wanted() and
- ff_outlink_set_status(). To be designed when needed. */
-av_assert0(parent->nb_outputs == 1);
-
-ff_framesync_preinit(fs);
-fs->parent = parent;
-fs->nb_in = nb_in;
+if (fs->parent->nb_outputs == 1) {
+if (!fs->on_eof)
+fs->on_eof = default_on_eof;
+if (!fs->on_miss)
+fs->on_miss = default_on_miss;
+}
+av_assert0(fs->on_eof);
+av_assert0(fs->on_miss);
-fs->in = av_calloc(nb_in, sizeof(*fs->in));
+fs->in = av_calloc(fs->nb_in, sizeof(*fs->in));
if (!fs->in)
return AVERROR(ENOMEM);
return 0;
}
+int ff_framesync_init(FFFrameSync *fs, AVFilterContext *parent, unsigned nb_in)
+{
+ff_framesync_preinit(fs);
+fs->parent = parent;
+fs->nb_in = nb_in;
+return ff_framesync_postinit(fs);
+}
+
static void framesync_eof(FFFrameSync *fs)
{
fs->eof = 1;
fs->frame_ready = 0;
-ff_outlink_set_status(fs->parent->outputs[0], AVERROR_EOF, AV_NOPTS_VALUE);
+fs->on_eof(fs);
}
static void framesync_sync_level_update(FFFrameSync *fs)
@@ -342,7 +354,7 @@ static int consume_from_fifos(FFFrameSync *fs)
}
}
if (nb_miss) {
-if (nb_miss == nb_active && !ff_outlink_frame_wanted(ctx->outputs[0]))
+if (nb_miss == nb_active && !fs->on_miss(fs))
return FFERROR_NOT_READY;
for (i = 0; i < fs->nb_in; i++)
if (!fs->in[i].have_next && fs->in[i].state != STATE_EOF)
@@ -422,3 +434,13 @@ int ff_framesync_dualinput_get_writable(FFFrameSync *fs,
AVFrame **f0, AVFrame *
}
return 0;
}
+
+static void default_on_eof(FFFrameSync *fs)
+{
+ff_outlink_set_status(fs->parent->outputs[0], AVERROR_EOF, AV_NOPTS_VALUE);
+}
+
+static int default_on_miss(FFFrameSync *fs)
+{
+return ff_outlink_frame_wanted(fs->parent->outputs[0]);
+}
diff --git a/libavfilter/framesync.h b/libavfilter/framesync.h
index 233f50a0eb..1957396c7f 100644
--- a/libavfilter/framesync.h
+++ b/libavfilter/framesync.h
@@ -193,6 +193,19 @@ typedef struct FFFrameSync {
*/
int (*on_event)(struct FFFrameSync *fs);
+/**
+ * Callback called when EOF is reached; can be NULL
+ * The default is to ff_outlink_set_status() on the single output.
+ */
+void (*on_eof)(struct FFFrameSync *fs);
+
+/**
+ * Callback called when no input can be produced to decide if input must
+ * be requested
+ * The default is ff_outlink_frame_wanted() on the singe output.
+ */
+int (*on_miss)(struct FFFrameSync *fs);
+
/**
* Opaque pointer, not used by the API
*/
@@ -240,6 +253,21 @@ typedef struct FFFrameSync {
*/
void ff_framesync_preinit(FFFrameSync *fs);
+/**
+ * Finish the initialization of a frame sync structure
+ *
+ * Use it in combination with ff_framesync_preinit() and set fields and
+ * options in between.
+ *
+ * ff_framesync_preinit(fs);
+ * fs->parent = parent;
+ * fs->nb_in = nb_in;
+ * fs->field = value;
+ * ret = ff_framesync_postinit(fs);
+ * if (ret < 0) ...
+ */
+int ff_framesync_postinit(FFFrameSync *fs);
+
/**
* Initialize a frame sync structure.
*
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [WIP] [PATCH 2/2] lavfi/vf_framematch: add filter to output matching synchronized frames
Signed-off-by: Nicolas George
---
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vf_framematch.c | 82 +
3 files changed, 84 insertions(+)
create mode 100644 libavfilter/vf_framematch.c
Unfinished yet, but should be rather straightforward. I think I can
squeeze some work on this the day after tomorrow.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 9b7813575a..290a473b63 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -313,6 +313,7 @@ OBJS-$(CONFIG_FIND_RECT_FILTER) +=
vf_find_rect.o lavfutils.o
OBJS-$(CONFIG_FLOODFILL_FILTER) += vf_floodfill.o
OBJS-$(CONFIG_FORMAT_FILTER) += vf_format.o
OBJS-$(CONFIG_FPS_FILTER)+= vf_fps.o
+OBJS-$(CONFIG_FRAMEMATCH_FILTER) += vf_framematch.o
OBJS-$(CONFIG_FRAMEPACK_FILTER) += vf_framepack.o
OBJS-$(CONFIG_FRAMERATE_FILTER) += vf_framerate.o
OBJS-$(CONFIG_FRAMESTEP_FILTER) += vf_framestep.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 9a7fadc58d..aa42b353c1 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -289,6 +289,7 @@ extern const AVFilter ff_vf_flip_vulkan;
extern const AVFilter ff_vf_floodfill;
extern const AVFilter ff_vf_format;
extern const AVFilter ff_vf_fps;
+extern const AVFilter ff_vf_framematch;
extern const AVFilter ff_vf_framepack;
extern const AVFilter ff_vf_framerate;
extern const AVFilter ff_vf_framestep;
diff --git a/libavfilter/vf_framematch.c b/libavfilter/vf_framematch.c
new file mode 100644
index 00..703b5ad93b
--- /dev/null
+++ b/libavfilter/vf_framematch.c
@@ -0,0 +1,82 @@
+
+#include "libavutil/avstring.h"
+#include "libavutil/opt.h"
+
+#include "avfilter.h"
+#include "framesync.h"
+#include "internal.h"
+
+typedef struct MatchContext {
+const AVClass *class;
+int nb;
+FFFrameSync fs;
+} MatchContext;
+
+static av_cold int init(AVFilterContext *ctx)
+{
+int i, ret;
+MatchContext *s = ctx->priv;
+
+for (i = 0; i < s->nb; i++) {
+AVFilterPad pad = { 0 };
+pad.type = AVMEDIA_TYPE_VIDEO;
+pad.name = av_asprintf("input%d", i);
+if (!pad.name)
+return AVERROR(ENOMEM);
+if ((ret = ff_append_inpad_free_name(ctx, )) < 0)
+return ret;
+pad.name = av_asprintf("output%d", i);
+if (!pad.name)
+return AVERROR(ENOMEM);
+if ((ret = ff_append_outpad_free_name(ctx, )) < 0)
+return ret;
+}
+return 0;
+}
+
+static int query_formats(AVFilterContext *ctx)
+{
+MatchContext *s = ctx->priv;
+int i, ret;
+
+for (i = 0; i < s->nb; i++) {
+AVFilterFormats *f = ff_all_formats(AVMEDIA_TYPE_AUDIO);
+if ((ret = ff_formats_ref(f, >inputs [i]-> incfg.formats)) < 0 ||
+(ret = ff_formats_ref(f, >outputs[i]->outcfg.formats)) < 0)
+return ret;
+}
+return 0;
+}
+
+static av_cold void uninit(AVFilterContext *ctx)
+{
+MatchContext *s = ctx->priv;
+//ff_framesync_uninit(>fs);
+}
+
+static int activate(AVFilterContext *ctx)
+{
+MatchContext *s = ctx->priv;
+return ff_framesync_activate(>fs);
+}
+
+#define FLAGS AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM
+#define OFFSET(x) offsetof(MatchContext, x)
+static const AVOption framematch_options[] = {
+{ "s", "set number of streams", OFFSET(nb), AV_OPT_TYPE_INT, {.i64=2}, 2,
INT_MAX, .flags = FLAGS },
+{ NULL },
+};
+
+AVFILTER_DEFINE_CLASS(framematch);
+
+const AVFilter ff_vf_framematch = {
+.name = "framematch",
+.description = NULL_IF_CONFIG_SMALL("Match frames from multiple inputs"),
+.priv_size = sizeof(MatchContext),
+.priv_class= _class,
+FILTER_QUERY_FUNC(query_formats),
+.init = init,
+.uninit= uninit,
+.activate = activate,
+.flags = AVFILTER_FLAG_DYNAMIC_INPUTS |
AVFILTER_FLAG_DYNAMIC_OUTPUTS,
+};
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
Michael Niedermayer (12023-06-23): > * What iam interrested in was working with the signals at a low level, why > because i find it interresting and fun. Then this is what you should be spending your time on, and to hell with anybody who says otherwise. Unless you have commitments that we are not privy of, nobody can tell you how you are supposed to be spending your time and skills. Nobody can force you to manage releases and fix fuzzing bugs and do all the things you do that are necessary to the project. Necessary to a conception of the good of the project that is not even your own I think. Nobody can prevent you from hacking the things that motivate you. At worst, they can prevent you from committing the resulting code into official FFmpeg. That would be the project's loss, and you can still publish it on a private branch. But they do not have the power to block you from pushing. It is not even clear they have the authority do block you, more so if the code is really good and fits FFmpeg well. The only thing that can block you is your desire to play nice and not harm the project. I would like to emphasize that some of the frequent naysayers do not have an excellent track record when it comes to playing nice and especially not harming the project. I am especially annoyed by the “it's too hard” naysayers — the same I have been getting when I say that I want to write a XML suited to our needs to replace our use of libxml. They do not realize they reveal more about their own skills than anybody else. You know if you can write a radio, so ignore them and go ahead. And if they were right, if it is too hard and you fail… well, you would just have wasted your own time; and you would have had fun and learned things on the occasion, which means the time was not even wasted. But the whole attitude who wants FFmpeg to be a Serious OpenSource TM Project, who needs to make releases and worry above all about ABI stability, is really the attitude who is killing all the fun in working on FFmpeg. Hey, people, realize FFmpeg does not exist to be a Serious OpenSource TM Project, FFmpeg does not exist to serve other projects, to serve companies who benefit from it give the bare minimum back. FFmpeg exists because some day a dude thought it would be fun to write a MPEG decoder. And everybody else told him it would be too hard, everybody else told him to use an existing library and to leave it to the professionals. He did not believe them and proved them utterly wrong, and the rest, as the saying goes, is history. So I will say it explicitly. We — me, and everybody who agrees with me — do not want to just maintain a bunch of wrappers for the convenience of others, we want to have fun writing interesting code, trying new ways of doing things, inventing original optimizations. We can find a balance and work on useful things too. But if you want us to work only on the boring useful things, if you want to bar us from working on fun things, then just fork you. P.S.: I do not think I am skilled enough in that area to review your code. But if you think I am, maybe on some parts, then I will happily. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] overlay_vulkan: remove in favor of libplacebo
Lynne (12023-06-20): > Patch attached. > > >From 453c513bb4960dee72228a8713375fce75a40482 Mon Sep 17 00:00:00 2001 > From: Lynne > Date: Tue, 20 Jun 2023 18:59:03 +0200 > Subject: [PATCH 2/2] lavfi: remove overlay_vulkan in favor of libplacebo Similar questions than for the other patch: Is libplacebo considered a system library? Is overlaying not considered an integral part of FFmpeg's task? Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] lavfi: remove scale_vulkan filter
Lynne (12023-06-20): > libplacebo is better in every way for anything involving scaling or format > conversions Is libplacebo considered a system library? Are scaling and format conversions not considered essential parts of FFmpeg's task? Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] [PATCH] avfilter/avfilter: add flag to signal filters that support w/h change
Paul B Mahol (12023-06-14): > To flag filters that can work with variable frame size changes > all the time in graph. So no rescalers are need to be inserted or > filtergraph reset. > > Once all such filters are flaged with such capability then code will be > added so auto inserted rescale filter is inserted where neccesarry to > filters in > filtergraph that do not support dynamic width/height changes. If you have a proof-of-concept patch series where this flag is actually useful, I will review it. As it is, it is dead code and not for commit. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] [PATCH] avfilter/avfilter: add flag to signal filters that support w/h change
Paul B Mahol (12023-06-14): > Will apply soon. A flag connected with no code at all? What is it supposed to do? -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Embedded documentation?
Stefano Sabatini (12023-05-08): > Can you share more details about the plan? In particular, is the doc > going to be embedded in the code itself (e.g. in the C > implementation)? Or should we have some dedicated headers containing > the docs? > > We should also avoid to duplicate the same information between docs > and code, so there should be some way to autogenerate the docs from > the corresponding entries in the code. This is far from settled, but I imagine something like that: - Short doc paragraphs go directly in the C source code as comments with a specific markup, like doxygen but distinct from it. - Longer doc texts go in a file with the same name as the C source code but a different extension, probably .md. - The build system parses all this to generate source files with the structured documentation to be compiled into the library. - The build system can also parse parts of the C source code to extract the structure information, for example AVOption initializers. - The build system also parses the current texinfo documentation so that we do not have to rewrite it all at once. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Embedded documentation?
Zhanbang He (12023-05-08): > Can it supports chatGPT? Of course not. Only ChatGnuTP, for obvious reasons of freedom. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Embedded documentation?
Stefano Sabatini (12023-05-08): > I cannot parse this, where is the threshold value defined? The threshold is the enum constant that was being described. > Maybe an example would clarify this, since there is ambiguity about > what default and explanations are. Let us think how this is meant to be used. For example, the user of a GUI clicks on a filter, the application asks the library “give me the documentation for this” and displays it somewhere. Imagine the whole FFmpeg documentation as a gigantic hypertext document, like <https://ffmpeg.org/ffmpeg-all.html>. Imagine we want the documentation for the scale filter. So we start at <https://ffmpeg.org/ffmpeg-all.html#scale-1>, and we take: - the introduction of the scale filter, - the width option, - the height option, - the flags option, - the size option, - etc., - the examples, - the commands, But the width and height options are expressions, therefore we will need also <https://ffmpeg.org/ffmpeg-all.html#Expression-Evaluation>. And the size option is a video size, so we take <https://ffmpeg.org/ffmpeg-all.html#Video-size> too. And the flags option requires <https://ffmpeg.org/ffmpeg-all.html#Scaler-Options>. And maybe the various scaler flags link to explanations about their pros and cons, and we want these explanations too. In general, to get the documentation for a component, avdoc starts at the doc node of this component, and it follows all the links from there, and then all the links from the nodes reached, etc., recursively, until avdoc has all the documentation that might be useful to understand that component. Then it returns to the application. But that means we will get 50 pages of documentation for most components. It is fine to display in a full-fledged help browser, but a 50 pages tooltip is not very convenient. This is where the thresholds come into play: - if you want a tooltip, av_documentation_get_excerpt(obj, 0); - if you want a help dialog where scrolling is possible, av_documentation_get_excerpt(obj, AVDOC_LINK_SELF_CONTAINED); - if you want a help browser where hyperlinks are possible, av_documentation_get_excerpt(obj, AVDOC_LINK_SELF_CONTAINED_FULL). Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Embedded documentation?
Stefano Sabatini (12023-05-08): > I think the problem with HTML is that then you need to parse it if you > want to display it, so I'd tend to rather go with markdown: > 1. it provides readable raw output > 2. there are plenty of libraries which can render it to various > formats (including HTML) I will reply to this separately. A lot of your comments are a little premature: I am not ready to start working on this just now. For starters, it is out of question without AVWriter being committed, and I am still waiting for somebody who is not a-priori hostile and who understand strings to look at the code. But this issue can be discussed now. I think using Markdown internally would be a huge mistake. You say “it provides readable raw format”: you seem to be assuming ffmpeg/ffplay/ffprobe will dump the documentation to the terminal as is and be done with it, and all other kinds of applications will have to manage the rest themselves. Well, this is not the kind of API I want to design. I want an API where we provide to the applications all its needs to prepare the documentation for the user, with the data in the most convenient format. And for that, the internal format needs to be convenient to manage with a program. A C program specifically. Markdown is designed to be easy to type and easy to look at by humans. But that makes it terrible to manage with a program. For starters, its syntax is highly ambiguous, already with “*” and “**”. HTML is a much better choice. Note: I am not suggesting the full complex beast of HTML found on the world-wide-web, with CSS and javascript and bad syntax and all the crap. I am suggesting a very well-defined subset of clean HTML. That is much easier to parse than Markdown, with only < and & acting as special characters. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Embedded documentation?
Timo Rothenpieler (12023-05-01): > Somewhat loosely related to this: > > A frequent issue is that it's entirely non-obvious which global libavcodec > options a codec might make use of. > Having a way to self-document that would be amazing, so those options show > up in the --help output, ideally with their codec-specific default. Interesting remark. I also thought in the past that knowing if a certain component uses or ignore a particular common option would be useful, but I had not pushed the reflexion to that point. > The obvious idea I had for this was to utilize the FFCodecDefault struct > which already exists, maybe expanding it a tiny bit to allow the second > value to be NULL, indicating "This codec uses that option, but does not > change the default". > > Main issue with this is that FFCodecDefault is a private struct. > It could just be made public and user-queryable, while making every current > user of it aware of possible NULL-values, which they can then just ignore. I can imagine a few other solutions. Note that the way we store the information in the library does not have to be the same as the way we give that information to the user. For example, internally we could store an array of used or unused options and to the user we can include only the used options in AVDocExcerpt. The most annoying task for this will be to look at the code component by component. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Embedded documentation?
Diederick C. Niehorster (12023-05-01): > +1. Thanks. > I assume a lot of the AVDocNode can be automatically populated from its > corresponding option? We'd not want to maintain, e.g. option names and > aliases in more than one place. I cannot promise there will be no duplication at all, and AVOption is very limited and needs to be replaced anyway. But I can promise it will not have to be written as a C structure with all its fields initialized. I have not discussed it nor finalized any of the details, but I am thinking the build system will parse either doxy-style comments in the C source code or in a separate .md file with the same name to generate the structures for the built-in documentation. If the system parses comments in the C source, it can also parse the AVOption initializers, at least in the simple cases. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/8] lavu: new AVWriter API
Rémi Denis-Courmont (12023-05-02): > I think that that is pretty rich coming from you, just judging by your > earlier > responses to other people. Pointers? -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/8] lavu: add macros to help making future-proof structures
Rémi Denis-Courmont (12023-05-02): > So it must be very poorly written because C union are supposed to avoid this > cleanly. > If you need padding where any sane implementation does not, then it is > clearly > poorly written. I must say, I am impressed by the rudeness and arrogance of such a comment without even looking at the code itself. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/8] lavu: new AVWriter API
Rémi Denis-Courmont (12023-05-02): > Please re-read the comments. You are totally misses the point. I confess so, indeed, I completely failed to understand your point after reading your comment multiple times. > Well, I'll add myself to the already long list of people publicly objecting > to > your patchset then. I will read your technical comments then. > > There is nothing about heap allocation in this code. And if code can be > > in the framework common to all backends, then it is where it belongs, > > not duplicated in each backend. > This makes zero sense. Why the hell would you want to have more than one heap- > allocation backend. FFmpeg only provides one. Applications can decide to provide their own if they want. That is the point. > Well duh, I wrote the VLC equivalent years ago. And glibc or FreeBSD libc did > them more than a decade before I did. Pointer? > And I decided to object to that on the basis that it's dumb and confusing. The only thing dumb and confusing I see here is the mail I am answering to. > I think I was pretty damn clear and you are just deliberately making up > reason > to ignore other people's comments (not just mine). Think what you will about me. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
