Re: [FFmpeg-devel] [RFC] STF 2025
On 17.05.24 16:43, Ronald S. Bultje wrote: Hi, On Fri, May 17, 2024 at 9:50 AM Michael Niedermayer wrote: * Fund professional real live presence on multimedia / FOSS / buisness related events. we already refund individuals but i think we are lacking on the organizational side. We should also have on these events at least one person who can awnser developer/user questions and someone who can awnser buisness questions (on buisness related events). Maybe not 100% the same thing, but ... As you say, there's several of us (including me) that attend some of these events. In addition to sponsoring more people to go, I'd be very excited to wear FFmpeg gear and at least make the FFmpeg brand more visible. (Right now I wear videolan gear at most events.) Make some nice-looking hoodies etc. that we'd like to wear and find an efficient way to distribute them. We have FFmpeg designs for T-Shirts and Hoodies. From the last badge we ordered there are still plenty of T-Shirts. I'd sent around a large badge vial mail all over the world some years ago and if there is enough demand I could do that again. Also I could bring stuff to FOSDEM or other cons for distribution if I'd know the demand from developers. We had occasionally some stuff with us to give away to users. However this is not very practical for anything where we'd need to hop into a plane for due to weight & space restrictions. Always having some swag to give away would produce costs for us. -Thilo ___ 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] STF 2025
[...] * Fund administrative / maintainance work (one example is the mailman upgrade that is needed with the next OS upgrade on one of our servers (this is not as trivial as one might expect). Another example here may be some git related tools if we find something that theres a broad consensus about. I agree that this should be paid but I would expect that STF would not be too keen on it, not that I'd know really. We should absolutely pay for such activity and STF is very well willing to fund such things. * Fund maintaince on the bug tracker, try to reproduce bugs, ask users to provide reproduceable cases, close bugs still unreproduceable, ... ATM we have over 2000 "new" bugs that are not even marked as open This is a double-edged sword. If somebody gets paid to do that, then that is one more reason for others not to do it. And again, it is completely reasonable to be paid for that, and also for code reviews and writing test cases (if we want to complete the menial task list), but I am perplexed as to STF's stance on that. Same as above about that we should and STF would. Especially since no corporate interest usually pays anyone for these tasks (in case of reviews it might of course be considered a good thing). The one problem to solve here AFAICT is we don't know exactly what quantity of bugs, reviewable code submissions and other maintenance work will come up in the next 12 months. So it renders impossible to define in prior the workload, milestones and compensation per contributor interested as we did this year for well-defined tasks. What we should consider IMO is defining the tasks (patch review, bug review & fix, FATE extensions, checkasm extensions, etc. as well such things for the administrative tasks from above) and defining a budget for these tasks. Then, allow 'everyone interested' (aka git push access?) to claim a part of that budget every N-months, depending what the corresponding contributor actually did and can somehow be determined. Regarding STF, this could visualize as one big milestone per task with a budget of X and this group of people working on it. How exactly the money distributes from there, depends on the actual work done afterwards. However, there are many questions about the details for our side and probably on the STF side. We should however start with at least one of these tasks aiming for next year, trying to setup some process that would work for us and can then be aligned with what is possible with STF. * Fund professional real live presence on multimedia / FOSS / buisness related events. we already refund individuals but i think we are lacking on the organizational side. We should also have on these events at least one person who can awnser developer/user questions and someone who can awnser buisness questions (on buisness related events). Also we need some eye catching things there, a big screen/projector that plays some real time filtered version from a camera. Or maybe have more people remotely be available from the FFmpeg team through real time streaming (as in, if someone wants to be on some event but cant physically go there, we could put a notebook on the table facing visitors showing something like a video chat. Also we need more cute girls on these events, everything i hear its 100% male geeks/hackers. Also a "24/7" realtime stream from any booth would be nice This is not something that STF should pay for, AFAIU. This is something that professionals should pay out of their budget (or their employer's) for the business events, and SPI for cheap/community events, IMO. I think we should fund all non-b2b appearances. About b2b, I wouldn't like our donation based money to be spent. We had corporate sponsorship in the past not having to think about it and possibly will have that as well in the future. The companies are interested in seeing us there and some are willing to pay for that happening. I think we could as well get dedicated STF money to cover such costs not being dependent on supportive companies and plan ahead better. That is nothing that 'professionals' should pay out of their budget or should even be allowed to do as we talk about a presence for the open-source project, not some company's presence. -Thilo ___ 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] Samples with invalid permissions
Hi, There are a couple of files in samples.ffmpeg.org with invalid permissions, rsync is not able to read those: /V-codecs/UCOD/noextradata/CLV1_tony.mov /V-codecs/UCOD/noextradata/freddie2.mov /V-codecs/UCOD/noextradata/pittc.mov /V-codecs/UCOD/noextradata/smilla_cv.mov /ffmpeg-bugs/trac/ticket4729/hap2_fuzz.mov /ffmpeg-bugs/trac/ticket5406/crushed_1.snm /ffmpeg-bugs/trac/ticket5407/512kbps.wv /ffmpeg-bugs/trac/ticket5407/512kbps.wvc /ffmpeg-bugs/trac/ticket5410/ela2.m4b /ffmpeg-bugs/trac/ticket5410/intro_a.m4b /ffmpeg-bugs/trac/ticket6102/error_reading_header_ticket_6102_first100.mp4 > /ffmpeg-bugs/trac/ticket6102/error_reading_header_ticket_6102_last100.mp4 the above are now free to read. /ffmpeg-bugs/trac/ticket5925/non-work-spanned.zip /ffmpeg-bugs/trac/ticket6400/tooshort.avi /ffmpeg-bugs/trac/ticket6675/Cineform_Bottom_8_Pixel_Distort_1080_YUV.mov /ffmpeg-bugs/trac/ticket6765/Canon-C200-Raw.CRM These are in the size of GB's. If someone really needs them, send us a mail according to http://samples.ffmpeg.org/00-README -Thilo ___ 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 v12 0/8] [WIP] webp: add support for animated WebP decoding
Hi, [...] Tests mostly work for me. There are a few images (that I reported earlier) that give: thanks for testing! Canvas change detected. The output will be damaged. Use -threads 1 to try decoding with best effort. They don't animate without that option and with it render incorrectly. That issue yields from the canvas frame being the synchronization object (ThreadFrame) - doing so prevents the canvas size changed mid-stream. _Maybe_ this can be fixed switching the whole frame multithreading away from ThreadFrame to sth else, not sure though and no experience with the alternatives (AVExecutor?). Maybe Andreas can predict if it's worth/valid to change that whole part of it? I'm not against putting more effort into it to get it right. I could fix 488x488.webp and have an almost identical output to libwebp. 488x488.webp features an ARGB canvas and has both, ARGB & YUVA420P p-frames. Do you have more files with other variations of canvas & p-frames? If they at all exist... e.g. canvas YUV and p-frames RGB? Pinged Meta as well for real-world samples. Will take some more days until I get feedback. Will then post the next iteration... Thanks, Thilo ___ 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] STF 2025
On 20.05.24 20:51, Rémi Denis-Courmont wrote: Le sunnuntaina 19. toukokuuta 2024, 14.29.43 EEST Thilo Borgmann via ffmpeg- devel a écrit : [...] * Fund administrative / maintainance work (one example is the mailman upgrade that is needed>> with the next OS upgrade on one of our servers (this is not as trivial as one might expect). Another example here may be some git related tools if we find something that theres a broad consensus about. I agree that this should be paid but I would expect that STF would not be too keen on it, not that I'd know really. We should absolutely pay for such activity and STF is very well willing to fund such things. Again, I don't know but that seems to stray from their stated goals. Also this is most certainly not a full-time job, and it requires a very high level of trust. In practice, what this really means is paying Michael. It is more of a question whether STF is willing to pay for this, and whether a reasonable task description with a reasonable average prorated workload and a pay can be defined. Again, I do know. "...STF is very well willing to fund such things." does not sound like an assumption to me. And again, it is completely reasonable to be paid for that, and also for code reviews and writing test cases (if we want to complete the menial task list), but I am perplexed as to STF's stance on that. Same as above about that we should and STF would. Especially since no corporate interest usually pays anyone for these tasks Sadly true, but... (in case of reviews it might of course be considered a good thing). I think some review is better than none. There may be conflict of interests, but they are weighed by the risk of being caught abusing the review process. I hope you realize what you argue in favor of. Reviews need to be unbiased and independent. STF sponsoring reviews could be an excellent help towards this. Corporate influence on the review process already happened in the past and the chance of getting caught is almost zero. About the rest, I think you already said that you don't find funding non-full-time positions useful in another thread - no need to reiterate that I don't agree with that nor with your assumptions that should lead to that. -Thilo ___ 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] STF 2025
On 21.05.24 21:42, Rémi Denis-Courmont wrote: Le tiistaina 21. toukokuuta 2024, 21.43.44 EEST Thilo Borgmann via ffmpeg-devel a écrit : Same as above about that we should and STF would. Especially since no corporate interest usually pays anyone for these tasks Sadly true, but... (in case of reviews it might of course be considered a good thing). I think some review is better than none. There may be conflict of interests, but they are weighed by the risk of being caught abusing the review process. I hope you realize what you argue in favor of. Yes. It's quoted above. Are you claiming that *no* review is better than *some* review done in *public* for all to see by a paid professional just because the person is maybe biased? First, even volunteers have their own biases. Any expert should have opinions from their experience, and that by definition makes them "biased". And second, you can't have it both ways. Either we want people to be paid for review, and they will be answerable to their sponsor, or we want people to continue to work on their free time. I think that is what you don't understand. An STF sponsorship for review would not introduce any bias in favor or against some patch or sth related. A company sponsorship would as it would introduce a bias towards 'we want our stuff in'. STF has no stuff they want to be reviewed on their behalf. They are only in favor of stuff being reviewed. STF is an agency of the German government, applying German government policies. They certainly do seem to have their own biases, including on tech, e.g.: https://www.theregister.com/2024/05/20/huawei_germany_ban/ to take just the most recent example to come to mind. No. Does not apply to any funding we might get. Reviews need to be unbiased and independent. Ideally so but that's the land of utopia. Of course, we talk about what should be, don't we? STF sponsoring reviews could be an excellent help towards this. If STF is willing to sponsor reviews, that's welcome. But that would certainly not be "independent". It would. As STF would not send patches we'd be obliged to review. They'd give us money just for the sake of review 'whatever comes our way'. Corporate influence on the review process already happened in the past and the chance of getting caught is almost zero. So how do you that it happened if it does not get caught? I assume you mean how I know that and the guilty ones did not get caught? Well they did. An answer in public I will give not. And "I hope you realise that you are arguing for" Intel, Loongson, etc. employees to stop reviewing patches. Syntax error. What exactly do you mean? According to my assumptions: No, I value reviews of company employees in general which have been proven to be useful and unbiased e.g. in getting part of the community reviewing 'stuf' but not their 'own stuff'. -Thilo ___ 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] STF 2025
On 21.05.24 21:43, Rémi Denis-Courmont wrote: Le tiistaina 21. toukokuuta 2024, 22.42.00 EEST Rémi Denis-Courmont a écrit : And "I hope you realise that you are arguing for" Intel, Loongson, etc. employees to stop reviewing patches. P.S.: And FFlabs too, since it is a for-profit company. Same remark as in the previous mail. I'm not sure how you mean that whole thing. Please elaborate / put in other words. -Thilo ___ 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] STF 2025
Am 22.05.24 um 14:27 schrieb Rémi Denis-Courmont: Le 22 mai 2024 00:34:03 GMT+03:00, Thilo Borgmann via ffmpeg-devel a écrit : I hope you realize what you argue in favor of. Yes. It's quoted above. Are you claiming that *no* review is better than *some* review done in *public* for all to see by a paid professional just because the person is maybe biased? First, even volunteers have their own biases. Any expert should have opinions from their experience, and that by definition makes them "biased". And second, you can't have it both ways. Either we want people to be paid for review, and they will be answerable to their sponsor, or we want people to continue to work on their free time. I think that is what you don't understand. You're not answering the question here. The current STF funding of 153k€ for 2 years is roughly enough to pay for ONE full-time entry-level software engineer in Germany. Even if this were doubled with another similar round of funding next year, and even if that was to be reliably renewed year on year, and assuming that STF keeps an hands-off approach of not influencing the work, that will *not* be enough to pay all reviewers. So is it better to have no reviews or reviews by skilled corporate employees? Your one question above was: "Are you claiming that [...] because the person is maybe biased?" And I answered about the biasing problem. And "I hope you realise that you are arguing for" Intel, Loongson, etc. employees to stop reviewing patches. Syntax error. What exactly do you mean? I fail to see a syntax error. You're saying that corporate employees should not review because "they [will] want to get [their]" or their colleagues' "stuff in" (your words). Intel and Loongson are obvious current examples of companies whose employees are pushing and reviewing enablement patches for their commercial hardware. That is very definitely not "unbiased" nor "independent". Unfortunately true, yet you argue to pay more companies to do reviews instead having reviews funded by unbiased means. According to my assumptions: No, I value reviews of company employees in general which have been proven to be useful and unbiased e.g. in getting part of the community reviewing 'stuf' but not their 'own stuff'. I never said that I wanted biased reviews. I said some reviews were better than none, in spite of the risk of bias. So much for your grandstanding against my alleged not realising what I am advocating for, if you end up agreeing with me... I think we don't agree. You would want to pay some comapny/companies to do review work while I'd want reviewers to be paid directly without a middle man and corporate bias. -Thilo ___ 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] STF 2025
On 24.05.24 11:56, Andrew Sayers wrote: On Fri, May 17, 2024 at 03:49:58PM +0200, Michael Niedermayer wrote: Hi all Before this is forgotten again, better start some dicsussion too early than too late This comment is inspired by the other subthread, but not directly in reply to it. I'm replying to this post rather than get in the middle of all that... Thanks :) What happens if someone is hired to do a job that requires access to the ML, then gets involved in a situation where there's talk of a ban? If they're banned, does that translate to suspension without pay? With pay? Banning such a person would jeopardise future funding - if they aren't banned, will people be concerned about the apparent conflict of interest? Interesting and something we should think about. I think the project's well-being should be the priority - meaning if we vote for a ban of someone that was trusted enough to get a contact from us in the first place, the ban should be executed - or any other measure the CC or GA sees fit. Giving a work contact to someone shall not make us dependent on that person to such an extent. In a wider sense, hiring a single person to do a job we come to rely on (like code review) gives the project a bus number of 1. How would the STF react to a proposal like "we plan to do XYZ in 2025, but if we don't get funding for 2026, we'll drop Z and spend the time on a transition plan instead"? Speaking as an idealist, we should uphold our procedures independently of what another entity (except the applicable law) thinks about our decisions. Realisticly speaking, we already got some feedback from STF about such potential break aways on our end. Though these are of course never good in any such business relation, these things do happen. So up to a certain extend, it won't remove us from the program. Problems arise if such things are getting frequent. We also got another layer of protection vie the SPI linked in between. If we sanction someone severely who is in current posession of a contract to do some FFmpeg work, we might stop funding that and give another contract to someone who can take over. Not saying that this could work with any kind of work but can be an option. That brings me to the idea that we need to check the contracts for potential fail-safe clauses for such extreme cases like these. Thanks, Thnilo ___ 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] STF 2025
Am 02.06.24 um 22:14 schrieb Tomas Härdin: sön 2024-06-02 klockan 20:01 +0200 skrev Michael Niedermayer: Hi On Sat, Jun 01, 2024 at 05:19:26PM +0200, Tomas Härdin wrote: [...] * Fund professional real live presence on multimedia / FOSS / buisness related events. Also reasonable. I could help man a booth at IBC or any other event in Europe Iam strongly in favor of that! Though i have no idea about cost (for IBC) which probably requires someone to sponsor a booth if its not free. Or any details. But i think its probably best if you mail thilo as he was helping with FFmpeg presence on many european booths Attending is free, so I expect booths cost quite a bit to make up the costs. There's an inquiry form on the IBC website. Can't hurt to ask Hotels aren't cheap as Rémi points out. Last time I attended IBC we had to get a hotel in Harlem. Luckily I know some people in Amsterdam We have a booth on IBC this year which again gets sponsored so no costs for FFmpeg. Some details are still unclear which is why it's not yet announced. @Thomas: Happy you want to attend, I'll keep you updated. -Thilo ___ 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] New CC member: Steven Liu
Hi, On 05.06.24 09:34, Marton Balint wrote: On Tue, 4 Jun 2024, Ronald S. Bultje wrote: Hi all, Anton resigned from the CC [1], leaving an empty spot. The remaining members of the CC agreed it would be best to fill the spot with the next runner-up from the last CC Elections. The last CC election results [2] had Steven Liu as next runner-up, so we've asked him to fill Anton's spot for the remainder of our term, and he accepted. Thanks & welcome, Steven! I don't have a problem with this in practice, but the legitimacy of such an appointment is not rock solid. The CC itself probably should not decide on CC membership, as that comes from the GA. Agreed. Though we see this the first time and the discussion some time ago did not raise much participation / interest. Maybe we should always choose a spare member (as in the 6th winner), who can automatically jump in. And if more than 1 person resign, a new election can be held. Sounds as a good possibility to me. We should determine our procedure of choice and put it into the docs. -Thilo ___ 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] avdevice/avfoundation: add external video devices
Am 09.06.24 um 21:51 schrieb Theo Fabi: Video devices categorized by AVFoundation as 'AVCaptureDeviceTypeExternal(Unknown)' (like USB video streams) were not recognized by libavdevice. Signed-off-by: Theo Fabi --- libavdevice/avfoundation.m | 3 +++ 1 file changed, 3 insertions(+) Ok. Will push soon. Thanks, Thilo ___ 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] [PATCH v13 0/8] [WIP] webp: add support for animated WebP decoding
Marked WIP because we'd want to introduce private bsf's first; review welcome before that though v13 Switched to new ProgressFrame API Support for pixel format changes in animations Propagate MIN_DELAY in case of invalid delay in animations Added more tests for animations with pixel format changes v12 VP8 decoder decoupled again The whole animated sequence goes into one packet The (currently public) bitstream filter splits animations up into non-conformant packets Now with XMP metadata support (as string, like MOV) Patch 5/8 is still there for making changes in lavc/webp reviewable but shall be stashed when pushing. -Thilo Josef Zlomek (2): libavcodec/webp: add support for animated WebP libavformat/webp: add WebP demuxer Thilo Borgmann via ffmpeg-devel (6): avcodec/webp: remove unused definitions avcodec/webp: separate VP8 decoding avcodec/bsf: Add awebp2webp bitstream filter avcodec/webp: make init_canvas_frame static fate: add test for animated WebP avcodec/webp: export XMP metadata Changelog | 2 + configure | 1 + doc/demuxers.texi | 28 + libavcodec/bitstream_filters.c| 1 + libavcodec/bsf/Makefile | 1 + libavcodec/bsf/awebp2webp.c | 353 +++ libavcodec/codec_desc.c | 3 +- libavcodec/webp.c | 983 -- libavformat/Makefile | 1 + libavformat/allformats.c | 1 + libavformat/webpdec.c | 384 +++ tests/fate/image.mak | 9 + tests/ref/fate/exif-image-webp| 4 +- tests/ref/fate/webp-anim | 22 + tests/ref/fate/webp-chfmt1| 23 + tests/ref/fate/webp-chfmt2| 106 ++ tests/ref/fate/webp-rgb-lena-lossless | 2 +- tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +- tests/ref/fate/webp-rgb-lossless | 2 +- .../fate/webp-rgb-lossless-palette-predictor | 2 +- tests/ref/fate/webp-rgb-lossy-q80 | 2 +- tests/ref/fate/webp-rgba-lossless | 2 +- tests/ref/fate/webp-rgba-lossy-q80| 2 +- 23 files changed, 1855 insertions(+), 81 deletions(-) create mode 100644 libavcodec/bsf/awebp2webp.c create mode 100644 libavformat/webpdec.c create mode 100644 tests/ref/fate/webp-anim create mode 100644 tests/ref/fate/webp-chfmt1 create mode 100644 tests/ref/fate/webp-chfmt2 -- 2.39.3 (Apple Git-146) ___ 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] [PATCH v13 2/8] avcodec/webp: separate VP8 decoding
From: Thilo Borgmann via ffmpeg-devel
---
libavcodec/webp.c | 50 +--
1 file changed, 44 insertions(+), 6 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index af4ebcec27..c52b9732b4 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -195,6 +195,7 @@ typedef struct WebPContext {
AVFrame *alpha_frame; /* AVFrame for alpha data decompressed
from VP8L */
AVPacket *pkt; /* AVPacket to be passed to the
underlying VP8 decoder */
AVCodecContext *avctx; /* parent AVCodecContext */
+AVCodecContext *avctx_vp8; /* wrapper context for VP8 decoder */
int initialized;/* set once the VP8 context is
initialized */
int has_alpha; /* has a separate alpha chunk */
enum AlphaCompression alpha_compression; /* compression type for alpha
chunk */
@@ -1299,12 +1300,13 @@ static int vp8_lossy_decode_frame(AVCodecContext
*avctx, AVFrame *p,
int ret;
if (!s->initialized) {
-ff_vp8_decode_init(avctx);
+VP8Context *s_vp8 = s->avctx_vp8->priv_data;
+s_vp8->actually_webp = 1;
s->initialized = 1;
-s->v.actually_webp = 1;
}
avctx->pix_fmt = s->has_alpha ? AV_PIX_FMT_YUVA420P : AV_PIX_FMT_YUV420P;
s->lossless = 0;
+s->avctx_vp8->pix_fmt = avctx->pix_fmt;
if (data_size > INT_MAX) {
av_log(avctx, AV_LOG_ERROR, "unsupported chunk size\n");
@@ -1315,14 +1317,32 @@ static int vp8_lossy_decode_frame(AVCodecContext
*avctx, AVFrame *p,
s->pkt->data = data_start;
s->pkt->size = data_size;
-ret = ff_vp8_decode_frame(avctx, p, got_frame, s->pkt);
-if (ret < 0)
+ret = avcodec_send_packet(s->avctx_vp8, s->pkt);
+if (ret < 0) {
+av_log(avctx, AV_LOG_ERROR, "Error submitting a packet for
decoding\n");
return ret;
+}
-if (!*got_frame)
+ret = avcodec_receive_frame(s->avctx_vp8, p);
+if (ret < 0) {
+av_log(avctx, AV_LOG_ERROR, "VP8 decoding error: %s.\n",
av_err2str(ret));
return AVERROR_INVALIDDATA;
+}
+
+ret = ff_decode_frame_props(avctx, p);
+if (ret < 0) {
+return ret;
+}
+
+if (!p->private_ref) {
+ret = ff_attach_decode_data(p);
+if (ret < 0) {
+return ret;
+}
+}
-update_canvas_size(avctx, avctx->width, avctx->height);
+*got_frame = 1;
+update_canvas_size(avctx, s->avctx_vp8->width, s->avctx_vp8->height);
if (s->has_alpha) {
ret = vp8_lossy_decode_alpha(avctx, p, s->alpha_data,
@@ -1539,11 +1559,28 @@ exif_end:
static av_cold int webp_decode_init(AVCodecContext *avctx)
{
WebPContext *s = avctx->priv_data;
+int ret;
+const AVCodec *codec;
s->pkt = av_packet_alloc();
if (!s->pkt)
return AVERROR(ENOMEM);
+
+/* Prepare everything needed for VP8 decoding */
+codec = avcodec_find_decoder(AV_CODEC_ID_VP8);
+if (!codec)
+return AVERROR_BUG;
+s->avctx_vp8 = avcodec_alloc_context3(codec);
+if (!s->avctx_vp8)
+return AVERROR(ENOMEM);
+s->avctx_vp8->flags = avctx->flags;
+s->avctx_vp8->flags2 = avctx->flags2;
+s->avctx_vp8->pix_fmt = avctx->pix_fmt;
+ret = avcodec_open2(s->avctx_vp8, codec, NULL);
+if (ret < 0) {
+return ret;
+}
return 0;
}
@@ -1552,6 +1589,7 @@ static av_cold int webp_decode_close(AVCodecContext
*avctx)
WebPContext *s = avctx->priv_data;
av_packet_free(&s->pkt);
+avcodec_free_context(&s->avctx_vp8);
if (s->initialized)
return ff_vp8_decode_free(avctx);
--
2.39.3 (Apple Git-146)
___
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] [PATCH v13 1/8] avcodec/webp: remove unused definitions
From: Thilo Borgmann via ffmpeg-devel --- libavcodec/webp.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/libavcodec/webp.c b/libavcodec/webp.c index 7c2a5f0111..af4ebcec27 100644 --- a/libavcodec/webp.c +++ b/libavcodec/webp.c @@ -60,8 +60,6 @@ #define VP8X_FLAG_ALPHA 0x10 #define VP8X_FLAG_ICC 0x20 -#define MAX_PALETTE_SIZE256 -#define MAX_CACHE_BITS 11 #define NUM_CODE_LENGTH_CODES 19 #define HUFFMAN_CODES_PER_META_CODE 5 #define NUM_LITERAL_CODES 256 -- 2.39.3 (Apple Git-146) ___ 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] [PATCH v13 4/8] libavcodec/webp: add support for animated WebP
From: Josef Zlomek
Fixes: 4907
Adds support for decoding of animated WebP.
The WebP decoder adds the animation related features according to the specs:
https://developers.google.com/speed/webp/docs/riff_container#animation
The frames of the animation may be smaller than the image canvas.
Therefore, the frame is decoded to a temporary frame,
then it is blended into the canvas, the canvas is copied to the output frame,
and finally the frame is disposed from the canvas.
The output to AV_PIX_FMT_YUVA420P/AV_PIX_FMT_YUV420P is still supported.
The background color is specified only as BGRA in the WebP file
so it is converted to YUVA if YUV formats are output.
Signed-off-by: Josef Zlomek
---
Changelog | 1 +
libavcodec/codec_desc.c | 3 +-
libavcodec/webp.c | 897 +---
3 files changed, 840 insertions(+), 61 deletions(-)
diff --git a/Changelog b/Changelog
index 06c00e981a..de6eedfd68 100644
--- a/Changelog
+++ b/Changelog
@@ -101,6 +101,7 @@ version 6.1:
- ffprobe XML output schema changed to account for multiple
variable-fields elements within the same parent element
- ffprobe -output_format option added as an alias of -of
+- animated WebP decoder
version 6.0:
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index a28ef68061..ec1dcc327a 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1259,8 +1259,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
.type = AVMEDIA_TYPE_VIDEO,
.name = "webp",
.long_name = NULL_IF_CONFIG_SMALL("WebP"),
-.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY |
- AV_CODEC_PROP_LOSSLESS,
+.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_LOSSLESS,
.mime_types= MT("image/webp"),
},
{
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index c52b9732b4..146d5cb393 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -35,13 +35,17 @@
* Exif metadata
* ICC profile
*
+ * @author Josef Zlomek, Pexeso Inc.
+ * Animation
+ *
* Unimplemented:
- * - Animation
* - XMP metadata
*/
+#include "libavutil/common.h"
#include "libavutil/imgutils.h"
#include "libavutil/mem.h"
+#include "libavutil/colorspace.h"
#define BITSTREAM_READER_LE
#include "avcodec.h"
@@ -50,6 +54,7 @@
#include "decode.h"
#include "exif.h"
#include "get_bits.h"
+#include "progressframe.h"
#include "thread.h"
#include "tiff_common.h"
#include "vp8.h"
@@ -68,6 +73,14 @@
#define NUM_SHORT_DISTANCES 120
#define MAX_HUFFMAN_CODE_LENGTH 15
+#define ANMF_DISPOSAL_METHOD0x01
+#define ANMF_DISPOSAL_METHOD_UNCHANGED 0x00
+#define ANMF_DISPOSAL_METHOD_BACKGROUND 0x01
+
+#define ANMF_BLENDING_METHOD0x02
+#define ANMF_BLENDING_METHOD_ALPHA 0x00
+#define ANMF_BLENDING_METHOD_OVERWRITE 0x02
+
static const uint16_t alphabet_sizes[HUFFMAN_CODES_PER_META_CODE] = {
NUM_LITERAL_CODES + NUM_LENGTH_CODES,
NUM_LITERAL_CODES, NUM_LITERAL_CODES, NUM_LITERAL_CODES,
@@ -192,6 +205,8 @@ typedef struct ImageContext {
typedef struct WebPContext {
VP8Context v; /* VP8 Context used for lossy decoding
*/
GetBitContext gb; /* bitstream reader for main image
chunk */
+ProgressFrame canvas_frame; /* ThreadFrame for canvas */
+AVFrame *frame; /* AVFrame for decoded frame */
AVFrame *alpha_frame; /* AVFrame for alpha data decompressed
from VP8L */
AVPacket *pkt; /* AVPacket to be passed to the
underlying VP8 decoder */
AVCodecContext *avctx; /* parent AVCodecContext */
@@ -204,9 +219,25 @@ typedef struct WebPContext {
int alpha_data_size;/* alpha chunk data size */
int has_exif; /* set after an EXIF chunk has been
processed */
int has_iccp; /* set after an ICCP chunk has been
processed */
+int duration; /* frame duration in an animation */
int width; /* image width */
int height; /* image height */
-int lossless; /* indicates lossless or lossy */
+int vp8x_flags; /* global flags from VP8X chunk */
+int canvas_width; /* canvas width */
+int canvas_height; /* canvas height */
+int anmf_flags; /* frame flags from ANMF chunk */
+int pos_x; /* frame position X */
+int pos_y; /* frame position Y */
+int prev_anmf_flags;/* previous frame flags from ANMF
chunk */
+int prev_width; /* previous frame width */
+int prev_height;/* previous frame height */
+int prev_pos_x; /* previous frame po
[FFmpeg-devel] [PATCH v13 5/8] avcodec/webp: make init_canvas_frame static
From: Thilo Borgmann via ffmpeg-devel
---
libavcodec/webp.c | 146 +++---
1 file changed, 72 insertions(+), 74 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 146d5cb393..bacf605ff2 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -1383,7 +1383,78 @@ static int vp8_lossy_decode_frame(AVCodecContext *avctx,
AVFrame *p,
return ret;
}
-int init_canvas_frame(WebPContext *s, int format, int key_frame);
+static int init_canvas_frame(WebPContext *s, int format, int key_frame)
+{
+AVFrame *canvas = s->canvas_frame.f;
+int height;
+int ret;
+
+// canvas is needed only for animation
+if (!(s->vp8x_flags & VP8X_FLAG_ANIMATION))
+return 0;
+
+// avoid init for non-key frames whose format and size did not change
+if (!key_frame &&
+canvas &&
+canvas->width == s->canvas_width &&
+canvas->height == s->canvas_height)
+return 0;
+
+// canvas changes within IPPP sequences will lose thread sync
+// because of the ThreadFrame reallocation and will wait forever
+// so if frame-threading is used, forbid canvas changes and unlock
+// previous frames
+if (!key_frame && canvas) {
+if (s->avctx->thread_count > 1) {
+av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged. Use -threads 1 to try decoding with best effort.\n");
+// unlock previous frames that have sent an _await() call
+ff_progress_frame_report(&s->canvas_frame, INT_MAX);
+return AVERROR_PATCHWELCOME;
+} else {
+// warn for damaged frames
+av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged.\n");
+}
+}
+
+s->avctx->pix_fmt = format;
+
+// VP8 decoder changed the width and height in AVCodecContext.
+// Change it back to the canvas size.
+ret = ff_set_dimensions(s->avctx, s->canvas_width, s->canvas_height);
+if (ret < 0)
+return ret;
+
+ff_progress_frame_unref(&s->canvas_frame);
+ret = ff_progress_frame_get_buffer(s->avctx, &s->canvas_frame,
AV_GET_BUFFER_FLAG_REF);
+if (ret < 0)
+return ret;
+
+canvas = s->canvas_frame.f;
+canvas->format= format;
+canvas->duration = s->duration;
+canvas->width = s->canvas_width;
+canvas->height= s->canvas_height;
+
+if (canvas->format == AV_PIX_FMT_ARGB) {
+height = canvas->height;
+memset(canvas->data[0], 0, height * canvas->linesize[0]);
+} else /* if (canvas->format == AV_PIX_FMT_YUVA420P) */ {
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(canvas->format);
+for (int comp = 0; comp < desc->nb_components; comp++) {
+int plane = desc->comp[comp].plane;
+
+if (comp == 1 || comp == 2)
+height = AV_CEIL_RSHIFT(canvas->height, desc->log2_chroma_h);
+else
+height = FFALIGN(canvas->height, 1 << desc->log2_chroma_h);
+
+memset(canvas->data[plane], s->transparent_yuva[plane],
+ height * canvas->linesize[plane]);
+}
+}
+
+return 0;
+}
static int webp_decode_frame_common(AVCodecContext *avctx, uint8_t *data, int
size,
int *got_frame, int key_frame, AVFrame *p)
@@ -1629,79 +1700,6 @@ exif_end:
return size;
}
-int init_canvas_frame(WebPContext *s, int format, int key_frame)
-{
-AVFrame *canvas = s->canvas_frame.f;
-int height;
-int ret;
-
-// canvas is needed only for animation
-if (!(s->vp8x_flags & VP8X_FLAG_ANIMATION))
-return 0;
-
-// avoid init for non-key frames whose format and size did not change
-if (!key_frame &&
-canvas &&
-canvas->width == s->canvas_width &&
-canvas->height == s->canvas_height)
-return 0;
-
-// canvas changes within IPPP sequences will lose thread sync
-// because of the ThreadFrame reallocation and will wait forever
-// so if frame-threading is used, forbid canvas changes and unlock
-// previous frames
-if (!key_frame && canvas) {
-if (s->avctx->thread_count > 1) {
-av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged. Use -threads 1 to try decoding with best effort.\n");
-// unlock previous frames that have sent an _await() call
-ff_progress_frame_report(&s->canvas_frame, INT_MAX);
-return AVERROR_PATCHWELCOME;
-} else {
-// warn for damaged frames
-av_log(s->avctx, AV_LOG_WARNING, "Canvas chang
[FFmpeg-devel] [PATCH v13 3/8] avcodec/bsf: Add awebp2webp bitstream filter
From: Thilo Borgmann via ffmpeg-devel
Splits a packet containing a webp animations into
one non-compliant packet per frame of the animation.
Skips RIFF and WEBP chunks for those packets except
for the first. Copyies ICC, EXIF and XMP chunks first
into each of the packets except for the first.
---
configure | 1 +
libavcodec/bitstream_filters.c | 1 +
libavcodec/bsf/Makefile| 1 +
libavcodec/bsf/awebp2webp.c| 353 +
4 files changed, 356 insertions(+)
create mode 100644 libavcodec/bsf/awebp2webp.c
diff --git a/configure b/configure
index 3bca638459..1b6e56496f 100755
--- a/configure
+++ b/configure
@@ -3437,6 +3437,7 @@ aac_adtstoasc_bsf_select="adts_header mpeg4audio"
av1_frame_merge_bsf_select="cbs_av1"
av1_frame_split_bsf_select="cbs_av1"
av1_metadata_bsf_select="cbs_av1"
+awebp2webp_bsf_select=""
dts2pts_bsf_select="cbs_h264 h264parse"
eac3_core_bsf_select="ac3_parser"
evc_frame_merge_bsf_select="evcparse"
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 138246c50e..1f6471f4f3 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -28,6 +28,7 @@ extern const FFBitStreamFilter ff_aac_adtstoasc_bsf;
extern const FFBitStreamFilter ff_av1_frame_merge_bsf;
extern const FFBitStreamFilter ff_av1_frame_split_bsf;
extern const FFBitStreamFilter ff_av1_metadata_bsf;
+extern const FFBitStreamFilter ff_awebp2webp_bsf;
extern const FFBitStreamFilter ff_chomp_bsf;
extern const FFBitStreamFilter ff_dump_extradata_bsf;
extern const FFBitStreamFilter ff_dca_core_bsf;
diff --git a/libavcodec/bsf/Makefile b/libavcodec/bsf/Makefile
index fb70ad0c21..48c67dd210 100644
--- a/libavcodec/bsf/Makefile
+++ b/libavcodec/bsf/Makefile
@@ -5,6 +5,7 @@ OBJS-$(CONFIG_AAC_ADTSTOASC_BSF) += bsf/aac_adtstoasc.o
OBJS-$(CONFIG_AV1_FRAME_MERGE_BSF)+= bsf/av1_frame_merge.o
OBJS-$(CONFIG_AV1_FRAME_SPLIT_BSF)+= bsf/av1_frame_split.o
OBJS-$(CONFIG_AV1_METADATA_BSF) += bsf/av1_metadata.o
+OBJS-$(CONFIG_AWEBP2WEBP_BSF) += bsf/awebp2webp.o
OBJS-$(CONFIG_CHOMP_BSF) += bsf/chomp.o
OBJS-$(CONFIG_DCA_CORE_BSF) += bsf/dca_core.o
OBJS-$(CONFIG_DTS2PTS_BSF)+= bsf/dts2pts.o
diff --git a/libavcodec/bsf/awebp2webp.c b/libavcodec/bsf/awebp2webp.c
new file mode 100644
index 00..69a0156167
--- /dev/null
+++ b/libavcodec/bsf/awebp2webp.c
@@ -0,0 +1,353 @@
+/*
+ * Animated WebP into non-compliant WebP bitstream filter
+ * Copyright (c) 2024 Thilo Borgmann
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Animated WebP into non-compliant WebP bitstream filter
+ * Splits a packet containing a webp animations into
+ * one non-compliant packet per frame of the animation.
+ * Skips RIFF and WEBP chunks for those packets except
+ * for the first. Copyies ICC, EXIF and XMP chunks first
+ * into each of the packets except for the first.
+ * @author Thilo Borgmann
+ */
+
+#include
+#include
+
+#include "codec_id.h"
+#include "bytestream.h"
+#include "libavutil/error.h"
+#include "libavutil/mem.h"
+
+#include "bsf.h"
+#include "bsf_internal.h"
+#include "packet.h"
+
+#define VP8X_FLAG_ANIMATION 0x02
+#define VP8X_FLAG_XMP_METADATA 0x04
+#define VP8X_FLAG_EXIF_METADATA 0x08
+#define VP8X_FLAG_ALPHA 0x10
+#define VP8X_FLAG_ICC 0x20
+
+typedef struct WEBPBSFContext {
+const AVClass *class;
+GetByteContext gb;
+
+AVPacket *last_pkt;
+uint8_t *last_iccp;
+uint8_t *last_exif;
+uint8_t *last_xmp;
+
+int iccp_size;
+int exif_size;
+int xmp_size;
+
+int add_iccp;
+int add_exif;
+int add_xmp;
+
+uint64_t last_pts;
+} WEBPBSFContext;
+
+static int save_chunk(WEBPBSFContext *ctx, uint8_t **buf, int *buf_size,
uint32_t chunk_size)
+{
+if (*buf || !buf_size || !chunk_size)
+return 0;
+
+*buf = av_malloc(chunk_size + 8);
+if (!*buf)
+return AVERROR(ENOMEM);
+
+*buf_size = chunk_size + 8;
+
+byte
[FFmpeg-devel] [PATCH v13 8/8] avcodec/webp: export XMP metadata
From: Thilo Borgmann via ffmpeg-devel
---
libavcodec/webp.c | 42 --
1 file changed, 36 insertions(+), 6 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index bacf605ff2..c8be673060 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -38,8 +38,8 @@
* @author Josef Zlomek, Pexeso Inc.
* Animation
*
- * Unimplemented:
- * - XMP metadata
+ * @author Thilo Borgmann
+ * XMP metadata
*/
#include "libavutil/common.h"
@@ -220,6 +220,7 @@ typedef struct WebPContext {
int has_exif; /* set after an EXIF chunk has been
processed */
int has_iccp; /* set after an ICCP chunk has been
processed */
int duration; /* frame duration in an animation */
+int has_xmp;/* set after an XMP chunk has been
processed */
int width; /* image width */
int height; /* image height */
int vp8x_flags; /* global flags from VP8X chunk */
@@ -1469,6 +1470,7 @@ static int webp_decode_frame_common(AVCodecContext
*avctx, uint8_t *data, int si
// reset metadata bit for each packet
s->has_exif = 0;
s->has_iccp = 0;
+s->has_xmp = 0;
while (bytestream2_get_bytes_left(&gb) > 8) {
char chunk_str[5] = { 0 };
@@ -1500,6 +1502,7 @@ static int webp_decode_frame_common(AVCodecContext
*avctx, uint8_t *data, int si
s->canvas_height = 0;
s->has_exif = 0;
s->has_iccp = 0;
+s->has_xmp = 0;
ff_progress_frame_unref(&s->canvas_frame);
break;
case MKTAG('V', 'P', '8', ' '):
@@ -1682,12 +1685,39 @@ exif_end:
}
s->vp8x_flags |= VP8X_FLAG_ANIMATION;
break;
-case MKTAG('X', 'M', 'P', ' '):
-AV_WL32(chunk_str, chunk_type);
-av_log(avctx, AV_LOG_WARNING, "skipping unsupported chunk: %s\n",
- chunk_str);
+case MKTAG('X', 'M', 'P', ' '): {
+GetByteContext xmp_gb;
+AVDictionary **xmp_metadata = NULL;
+uint8_t *buffer;
+int xmp_offset = bytestream2_tell(&gb);
+
+if (s->has_xmp) {
+av_log(avctx, AV_LOG_VERBOSE, "Ignoring extra XMP chunk\n");
+goto xmp_end;
+}
+if (!(s->vp8x_flags & VP8X_FLAG_XMP_METADATA))
+av_log(avctx, AV_LOG_WARNING,
+ "XMP chunk present, but XMP bit not set in the "
+ "VP8X header\n");
+
+// there are at least chunk_size bytes left to read
+buffer = av_malloc(chunk_size + 1);
+if (!buffer) {
+return AVERROR(ENOMEM);
+}
+
+s->has_xmp = 1;
+bytestream2_init(&xmp_gb, data + xmp_offset, size - xmp_offset);
+bytestream2_get_buffer(&xmp_gb, buffer, chunk_size);
+buffer[chunk_size] = '\0';
+
+xmp_metadata = (s->vp8x_flags & VP8X_FLAG_ANIMATION) ?
&p->metadata : &s->frame->metadata;
+av_dict_set(xmp_metadata, "xmp", buffer, AV_DICT_DONT_STRDUP_VAL);
+
+xmp_end:
bytestream2_skip(&gb, chunk_size);
break;
+}
default:
AV_WL32(chunk_str, chunk_type);
av_log(avctx, AV_LOG_VERBOSE, "skipping unknown chunk: %s\n",
--
2.39.3 (Apple Git-146)
___
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] [PATCH v13 7/8] fate: add test for animated WebP
From: Thilo Borgmann via ffmpeg-devel --- tests/fate/image.mak | 9 tests/ref/fate/webp-anim | 22 tests/ref/fate/webp-chfmt1 | 23 tests/ref/fate/webp-chfmt2 | 106 + 4 files changed, 160 insertions(+) create mode 100644 tests/ref/fate/webp-anim create mode 100644 tests/ref/fate/webp-chfmt1 create mode 100644 tests/ref/fate/webp-chfmt2 diff --git a/tests/fate/image.mak b/tests/fate/image.mak index 753936ec20..37dd0b83d9 100644 --- a/tests/fate/image.mak +++ b/tests/fate/image.mak @@ -566,6 +566,15 @@ fate-webp-rgb-lossy-q80: CMD = framecrc -i $(TARGET_SAMPLES)/webp/rgb_q80.webp FATE_WEBP += fate-webp-rgba-lossy-q80 fate-webp-rgba-lossy-q80: CMD = framecrc -i $(TARGET_SAMPLES)/webp/rgba_q80.webp +FATE_WEBP += fate-webp-anim +fate-webp-anim: CMD = framecrc -i $(TARGET_SAMPLES)/webp/anim.webp + +FATE_WEBP += fate-webp-chfmt1 +fate-webp-chfmt1: CMD = framecrc -i $(TARGET_SAMPLES)/webp/anim_rgb_yuv.webp + +FATE_WEBP += fate-webp-chfmt2 +fate-webp-chfmt2: CMD = framecrc -i $(TARGET_SAMPLES)/webp/anim_yuv_rgb.webp + FATE_WEBP-$(call DEMDEC, IMAGE2, WEBP) += $(FATE_WEBP) FATE_IMAGE_FRAMECRC += $(FATE_WEBP-yes) fate-webp: $(FATE_WEBP-yes) diff --git a/tests/ref/fate/webp-anim b/tests/ref/fate/webp-anim new file mode 100644 index 00..f0d3f1a88f --- /dev/null +++ b/tests/ref/fate/webp-anim @@ -0,0 +1,22 @@ +#tb 0: 1/1000 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 100x70 +#sar 0: 0/1 +0, 0, 0, 80,28000, 0x2023ba6e +0, 80, 80, 80,28000, 0x4292b778 +0,160,160, 80,28000, 0x1c972ef1 +0,240,240, 80,28000, 0xa98d8d04 +0,320,320, 80,28000, 0xd323b6af +0,400,400, 80,28000, 0x508aba99 +0,480,480, 80,28000, 0x5c672dda +0,560,560, 80,28000, 0xc8961ebb +0,640,640, 1000,28000, 0x82460e1b +0, 1640, 1640, 80,28000, 0x3debbfc9 +0, 1720, 1720, 80,28000, 0x427ab31f +0, 1800, 1800, 80,28000, 0x6bbdec2e +0, 1880, 1880, 80,28000, 0x5690b56b +0, 1960, 1960, 80,28000, 0xb62963f3 +0, 2040, 2040, 80,28000, 0x68dd37b2 +0, 2120, 2120, 80,28000, 0x465c47d2 +0, 2200, 2200,1,28000, 0xa92033df diff --git a/tests/ref/fate/webp-chfmt1 b/tests/ref/fate/webp-chfmt1 new file mode 100644 index 00..bdb0616353 --- /dev/null +++ b/tests/ref/fate/webp-chfmt1 @@ -0,0 +1,23 @@ +#tb 0: 1/1000 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 488x488 +#sar 0: 0/1 +0, 0, 0, 80, 952576, 0x22e300c0 +0, 80, 80, 80, 952576, 0x4e7e9a01 +0,160,160, 80, 952576, 0x01b6a421 +0,240,240, 80, 952576, 0x26f09b88 +0,320,320, 80, 952576, 0xbb1404ac +0,400,400, 480, 952576, 0x14368b56 +0,880,880, 80, 952576, 0x1843fad6 +0,960,960, 80, 952576, 0xc3c4bb73 +0, 1040, 1040, 160, 952576, 0x9d662364 +0, 1200, 1200, 160, 952576, 0xf8218a9a +0, 1360, 1360, 160, 952576, 0x5828d888 +0, 1520, 1520, 560, 952576, 0x6a718e32 +0, 2080, 2080, 80, 952576, 0x95b7ff21 +0, 2160, 2160, 80, 952576, 0x84662ce1 +0, 2240, 2240, 720, 952576, 0x11974723 +0, 2960, 2960, 80, 952576, 0xd4a644ef +0, 3040, 3040, 80, 952576, 0x3d29c6a8 +0, 3120, 3120, 720, 952576, 0x3d3a2d40 diff --git a/tests/ref/fate/webp-chfmt2 b/tests/ref/fate/webp-chfmt2 new file mode 100644 index 00..3d00544390 --- /dev/null +++ b/tests/ref/fate/webp-chfmt2 @@ -0,0 +1,106 @@ +#tb 0: 1/1000 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 320x240 +#sar 0: 0/1 +0, 0, 0, 30, 192000, 0x41a50269 +0, 30, 30, 30, 192000, 0xb54a0286 +0, 60, 60, 30, 192000, 0x842c01ab +0, 90, 90, 30, 192000, 0x19b0fd8f +0,120,120, 30, 192000, 0x9eb9fb71 +0,150,150, 30, 192000, 0x1e11fb1d +0,180,180, 30, 192000, 0x4e33fe49 +0,210,210, 30, 192000, 0x2e4fffa4 +0,240,240, 30, 192000, 0xfa74ff7f +0,270,270, 30, 192000, 0x695ff5dd +0,300,300, 30, 192000, 0xd263ff87 +0,330,330, 30, 192000, 0x8eb2f958 +0,360,360, 30, 192000, 0x2630f6dd +0,390,390, 30, 192000, 0xf84af899 +0,420,420, 30
[FFmpeg-devel] [PATCH v13 6/8] libavformat/webp: add WebP demuxer
From: Josef Zlomek
Adds the demuxer of animated WebP files.
It supports non-animated, animated, truncated, and concatenated files.
Reading from a pipe (and other non-seekable inputs) is also supported.
The WebP demuxer splits the input stream into packets containing one frame.
It also marks the key frames properly.
The loop count is ignored by default (same behaviour as animated PNG and GIF),
it may be enabled by the option '-ignore_loop 0'.
The frame rate is set according to the frame delay in the ANMF chunk.
If the delay is too low, or the image is not animated, the default frame rate
is set to 10 fps, similarly to other WebP libraries and browsers.
The fate suite was updated accordingly.
Signed-off-by: Josef Zlomek
---
Changelog | 1 +
doc/demuxers.texi | 28 ++
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/webpdec.c | 384 ++
tests/ref/fate/exif-image-webp| 4 +-
tests/ref/fate/webp-rgb-lena-lossless | 2 +-
tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +-
tests/ref/fate/webp-rgb-lossless | 2 +-
.../fate/webp-rgb-lossless-palette-predictor | 2 +-
tests/ref/fate/webp-rgb-lossy-q80 | 2 +-
tests/ref/fate/webp-rgba-lossless | 2 +-
tests/ref/fate/webp-rgba-lossy-q80| 2 +-
13 files changed, 424 insertions(+), 9 deletions(-)
create mode 100644 libavformat/webpdec.c
diff --git a/Changelog b/Changelog
index de6eedfd68..22a6d16824 100644
--- a/Changelog
+++ b/Changelog
@@ -102,6 +102,7 @@ version 6.1:
variable-fields elements within the same parent element
- ffprobe -output_format option added as an alias of -of
- animated WebP decoder
+- animated WebP demuxer
version 6.0:
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 04293c4813..9c9d0fee17 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -1158,4 +1158,32 @@ this is set to 0, which means that a sensible value is
chosen based on the
input format.
@end table
+@section webp
+
+Animated WebP demuxer.
+
+It accepts the following options:
+
+@table @option
+@item -min_delay @var{int}
+Set the minimum valid delay between frames in milliseconds.
+Range is 0 to 6. Default value is 10.
+
+@item -max_webp_delay @var{int}
+Set the maximum valid delay between frames in milliseconds.
+Range is 0 to 16777215. Default value is 16777215 (over four hours),
+the maximum value allowed by the specification.
+
+@item -default_delay @var{int}
+Set the default delay between frames in milliseconds.
+Range is 0 to 6. Default value is 100.
+
+@item -ignore_loop @var{bool}
+WebP files can contain information to loop a certain number of times
+(or infinitely). If @option{ignore_loop} is set to true, then the loop
+setting from the input will be ignored and looping will not occur.
+If set to false, then looping will occur and will cycle the number
+of times according to the WebP. Default value is true.
+@end table
+
@c man end DEMUXERS
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 7ca68a7036..d86e98926d 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -628,6 +628,7 @@ OBJS-$(CONFIG_WEBM_MUXER)+= matroskaenc.o
matroska.o \
av1.o avlanguage.o
OBJS-$(CONFIG_WEBM_DASH_MANIFEST_MUXER) += webmdashenc.o
OBJS-$(CONFIG_WEBM_CHUNK_MUXER) += webm_chunk.o
+OBJS-$(CONFIG_WEBP_DEMUXER) += webpdec.o
OBJS-$(CONFIG_WEBP_MUXER)+= webpenc.o
OBJS-$(CONFIG_WEBVTT_DEMUXER)+= webvttdec.o subtitles.o
OBJS-$(CONFIG_WEBVTT_MUXER) += webvttenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 305fa46532..23f6ef7f7d 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -511,6 +511,7 @@ extern const FFInputFormat ff_webm_dash_manifest_demuxer;
extern const FFOutputFormat ff_webm_dash_manifest_muxer;
extern const FFOutputFormat ff_webm_chunk_muxer;
extern const FFOutputFormat ff_webp_muxer;
+extern const FFInputFormat ff_webp_demuxer;
extern const FFInputFormat ff_webvtt_demuxer;
extern const FFOutputFormat ff_webvtt_muxer;
extern const FFInputFormat ff_wsaud_demuxer;
diff --git a/libavformat/webpdec.c b/libavformat/webpdec.c
new file mode 100644
index 00..446e181156
--- /dev/null
+++ b/libavformat/webpdec.c
@@ -0,0 +1,384 @@
+/*
+ * WebP demuxer
+ * Copyright (c) 2020 Pexeso Inc.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; with
Re: [FFmpeg-devel] [PATCH v2 1/4] avfilter/af_volumedetect.c: Move logdb function
On 29.06.24 21:54, Yigithan Yigit wrote:
On 29 Jun 2024, at 22:22, Rémi Denis-Courmont wrote:
Le perjantaina 28. kesäkuuta 2024, 23.15.20 EEST Yigithan Yigit a écrit :
---
libavfilter/af_volumedetect.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
index 8b001d1cf2..327801a7f9 100644
--- a/libavfilter/af_volumedetect.c
+++ b/libavfilter/af_volumedetect.c
@@ -24,6 +24,8 @@
#include "avfilter.h"
#include "internal.h"
+#define MAX_DB 91
+
typedef struct VolDetectContext {
/**
* Number of samples at each PCM value.
@@ -33,6 +35,14 @@ typedef struct VolDetectContext {
uint64_t histogram[0x10001];
} VolDetectContext;
+static inline double logdb(uint64_t v)
+{
+double d = v / (double)(0x8000 * 0x8000);
ldexp(v, -30) ?
That was the original code that already written. Should I change?
Not here. Keep the move patch as-is.
You can test if ldexp() is equal and if so, add another patch to the
patchset changing the function to utilize ldexp().
-Thilo
___
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 at LinuxDays 2023 in Prague
Hi, the break after the pandemic has stopped for the LinuxDays in Prague this year as well. Thus, FFmpeg will be at the Linux Days 2023 in Prague, Czech Republic from October 7th to 8th! Find more information on their homepage. The 2023 english version linked here is still outdated but should update soon-ish (tm). https://www.linuxdays.cz/2023/en We will man a booth with our staff and are happily waiting for our users to get in touch with us! If you're a developer and want to help us or just want to visit and check in at our booth, please let us know. FFmpeg can sponsor your travels and accommodation in Prague for the duration of the conference! We would like to encourage everyone visiting the CLT to bring us sample files and/or command lines that show suspicious or buggy behavior - this will be your change to get your bug fixed right away! See you in Prague! I returned form the LDP last weekend where we had many interested users visiting. Showed a usual webcam-based demo and gave away some T-Shirts, helped out with some command lines. There have been some samples brought to us though during the second day where users experienced problems transcoding/dec. For one, that is a DVB-T2 recording, FFmpeg is actually fine with the file and it looked like a VLC regression since 3.0.18 (VLC freezes). Plays fine in my 3.0.6. and the users 3.0.9, so its all VLC's fault. Files are available 0:-) The other was a tuning issue for libsvtav1 where -profile appears broken for his FFmpeg version 6.0... though a proper -preset was sufficient to help out. -Thilo ___ 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] [REFUND-REQUEST] Travel & Accomodation for LDP 23
Hi, I went to Prag for the LinuxDays Prague 23 [1] by Bus and stayed at the university Dorm/Hotel. Bus:54,98 EUR Hotel: 154,08 EUR (converted from CZK by VISA) = Total: 209,06 EUR Thanks, Thilo [1] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-October/315777.html ___ 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] [PATCH] lavc/webp: Remove frame threading
Revealed by the patch to support animated webp, the current
frame threading implementation contains a data race.
vp8_lossy_decode_frame() calls ff_vp8_decode_frame() wich
calls ff_thread_finish_setup() to sync its internal slice threading.
The race is happens because vp8_lossy_decode_frame() has to touch
the AVCodecContext after it was passed to ff_vp8_decode_frame() and
ff_thread_finish_setup() had been called.
Therefore remove frame threading in webp and rely on slice threading
in VP8 only.
---
libavcodec/webp.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 54b3fde6dc..cde91aa7bb 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -49,7 +49,6 @@
#include "decode.h"
#include "exif.h"
#include "get_bits.h"
-#include "thread.h"
#include "tiff_common.h"
#include "vp8.h"
@@ -570,7 +569,7 @@ static int decode_entropy_coded_image(WebPContext *s, enum
ImageRole role,
img->frame->height = h;
if (role == IMAGE_ROLE_ARGB && !img->is_alpha_primary) {
-ret = ff_thread_get_buffer(s->avctx, img->frame, 0);
+ret = ff_get_buffer(s->avctx, img->frame, 0);
} else
ret = av_frame_get_buffer(img->frame, 1);
if (ret < 0)
@@ -1564,6 +1563,6 @@ const FFCodec ff_webp_decoder = {
.init = webp_decode_init,
FF_CODEC_DECODE_CB(webp_decode_frame),
.close = webp_decode_close,
-.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
+.p.capabilities = AV_CODEC_CAP_DR1,
.caps_internal = FF_CODEC_CAP_ICC_PROFILES,
};
--
2.37.1 (Apple Git-137.1)
___
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] lavc/webp: Remove frame threading
Am 22.10.23 um 16:30 schrieb Andreas Rheinhardt: Thilo Borgmann via ffmpeg-devel: Revealed by the patch to support animated webp, the current frame threading implementation contains a data race. No, it doesn't: The current implementation does not call ff_thread_finish_setup() in vp8.c for webp: if (ffcodec(avctx->codec)->update_thread_context) ff_thread_finish_setup(avctx); It seems that "the patch to support animated webp" (what patch are we talking about?) adds an update_thread_context to the webp decoder, thereby changing things and adding the data race. Oh yes that's true, no update_thread_context(), so not happening. vp8_lossy_decode_frame() calls ff_vp8_decode_frame() wich calls ff_thread_finish_setup() to sync its internal slice threading. Nonsense: ff_thread_finish_setup() is only for frame-threading. Indeed, thx. Though, even if I was too stupid to realize for what, it is called... The race is happens because vp8_lossy_decode_frame() has to touch the AVCodecContext after it was passed to ff_vp8_decode_frame() and ff_thread_finish_setup() had been called. Therefore remove frame threading in webp and rely on slice threading in VP8 only. Also nonsense: The webp decoder does not support slice threading, so the internal VP8 decoder won't ever use it (even though it supports it). Thx again, that's good to know. I am a bit confused here: On the one hand, https://developers.google.com/speed/webp/docs/riff_container says that it only uses VP8 key frame encoding; on the other hand, it has this animation feature. Does this also only use VP8-intra coding (i.e. is the non-intra part of animation just the blending of earlier frames?)? That's how it works. If it does, then the webp decoder should be separated from the VP8 decoder (i.e. it should use it according to the public API) and the sub-decoder should only be used in single-threaded mode. That would solve the issue. How do I force the VP8 decoder to be single-threaded from the API? Tried that and failed - well, you know how stupid I am... Agreed, the internal VP8 decoding for lossless images should be gone from webp.c. IMO removing frame-threading for ordinary WebP due to animated WebP is unacceptable. Once VP8 decoding happens single-threaded, this patch is void of course. Thanks, Thilo ___ 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] [ANNOUNCE] upcoming GA vote
Hi, Am 24.10.23 um 23:15 schrieb Anton Khirnov: Hi all, as discussed at the dev meeting at VDD, we need to have a series of votes, the first of which concerns defining when is the GA voter list to be updated. As the previous attempt to vote on this was hampered by email delivery issues, and also criticized due to inadequate advance announcement, the vote was closed and we are going to try again. This time, to avoid any confusion, let me clearly state that this is a declaration of intent to initiate a GA vote next Monday (2023-10-30), unless there are substantial objections. The vote question will be: How do we update the list of active members of the general assembly? Proposed possibilities so far are: * twice a year (1st Jan & 1st July) (suggested at VDD) * before each vote (suggested at VDD) * never (keep the 2020 version) (suggested at VDD) * keep everyone who had vote rights but add active developers each jan/july (suggested by Michael on the ML) Feel welcome to propose additional possibilities until Friday 2023-10-27. Other constructive comments also welcome. To test the voting beforehand this time, I created a test vote with a fake-GA member list. All of the following people should have received a corresponding mail. If you are part of this list, but did not receive an email, check your spam folder for the sender: ffmpeg.vot...@mail.de. Please comment if you didn't get the mail. The list is as follows: andreas.rheinha...@gmail.com andriy.gel...@gmail.com an...@khirnov.net barryjz...@tencent.com ceffm...@gmail.com c...@passwd.hu dcni...@gmail.com derek.buitenh...@gmail.com d...@lynne.ee devin.heitmuel...@ltnglobal.com epira...@gmail.com ffm...@gyani.pro geo...@nsup.org g...@haasn.dev haihao.xi...@intel.com jamr...@gmail.com jan.ekst...@24i.com j...@itanimul.li jianhua...@intel.com lance.lmw...@gmail.com leo.i...@gmail.com linjie.justin...@gmail.com liuq...@kuaishou.com mar...@martin.st mich...@niedermayer.cc nuomi2...@gmail.com one...@gmail.com p...@palemieux.com phil...@overt.org pr...@xvid.org rco...@rcombs.me r...@remlab.net shubhanshu@gmail.com softwo...@hotmail.com stefa...@gmail.com s...@jkqxz.net thilo.borgm...@mail.de t...@rothenpieler.org u...@pkh.me vittorio.giov...@gmail.com wenbin.c...@intel.com yejun@intel.com z...@zanevaniperen.com zhiliz...@tencent.com -Thilo ___ 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] [ANNOUNCE] upcoming GA vote
Am 25.10.23 um 16:22 schrieb Rémi Denis-Courmont: Hi, I am not on the GA, but there are probably people with my locale on the GA. And it seems that the voting system hits a Perl syntax error if your browser locale is set to French. Can you send me a screenshot? -Thilo ___ 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] [ANNOUNCE] upcoming GA vote
Am 25.10.23 um 16:23 schrieb Thilo Borgmann via ffmpeg-devel: Am 25.10.23 um 16:22 schrieb Rémi Denis-Courmont: Hi, I am not on the GA, but there are probably people with my locale on the GA. And it seems that the voting system hits a Perl syntax error if your browser locale is set to French. Can you send me a screenshot? Thanks. That appears to be a perl bug, Not going to touch that on the server atm. So sorry, switch to english or use another device for now. Thanks, Thilo ___ 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] [ANNOUNCE] upcoming GA vote
Am 25.10.23 um 19:39 schrieb Rémi Denis-Courmont: Hi, Le 25 octobre 2023 18:52:31 GMT+03:00, Thilo Borgmann via ffmpeg-devel a écrit : Am 25.10.23 um 16:23 schrieb Thilo Borgmann via ffmpeg-devel: Am 25.10.23 um 16:22 schrieb Rémi Denis-Courmont: Hi, I am not on the GA, but there are probably people with my locale on the GA. And it seems that the voting system hits a Perl syntax error if your browser locale is set to French. Can you send me a screenshot? Thanks. That appears to be a perl bug, Not going to touch that on the server atm. So sorry, switch to english or use another device for now. That seems to makes no difference (Firefox on Android). The language setting seem to only change the GUI, not whatever the Perl CGI uses (Accept-Language header?). Objectively, it really does not matter insofar as we are dealing solely with non-GA members such as I. But if I were to play devil's advocate, you may be serving on a plate a pretext for some future dissatisfied voters to call the voting process invalid later, or worse, maybe even allege xenophobic discrimination (this does *not* represent my opinion and is *not* meant to constitute an actual serious accusation). Either way it might be a problem in the particular context of this project, especially in light of the abundance of formality from Anton's original post. Not that I'd have a solution. Feel free to ignore. Not a perl "bug" but per-se but something changed about validity of my(my..., my...) constructs. There is a patch for the CIVS source which is two years old [1]. That perl "update" seems to have happened after our last vote (where this issue was non-existant afaict) and today. I'll try to find some time tomorrow to adapt the source on the server and let you know to retest your vote. Should effect french, hungarian and italian. -Thilo [1] https://github.com/andrewcmyers/civs/commit/9578227a1b37c87437bfbf545e0595aa371cf621 ___ 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] [ANNOUNCE] upcoming GA vote
Am 25.10.23 um 21:31 schrieb Thilo Borgmann via ffmpeg-devel: Am 25.10.23 um 19:39 schrieb Rémi Denis-Courmont: Hi, Le 25 octobre 2023 18:52:31 GMT+03:00, Thilo Borgmann via ffmpeg-devel a écrit : Am 25.10.23 um 16:23 schrieb Thilo Borgmann via ffmpeg-devel: Am 25.10.23 um 16:22 schrieb Rémi Denis-Courmont: Hi, I am not on the GA, but there are probably people with my locale on the GA. And it seems that the voting system hits a Perl syntax error if your browser locale is set to French. Can you send me a screenshot? Thanks. That appears to be a perl bug, Not going to touch that on the server atm. So sorry, switch to english or use another device for now. That seems to makes no difference (Firefox on Android). The language setting seem to only change the GUI, not whatever the Perl CGI uses (Accept-Language header?). Objectively, it really does not matter insofar as we are dealing solely with non-GA members such as I. But if I were to play devil's advocate, you may be serving on a plate a pretext for some future dissatisfied voters to call the voting process invalid later, or worse, maybe even allege xenophobic discrimination (this does *not* represent my opinion and is *not* meant to constitute an actual serious accusation). Either way it might be a problem in the particular context of this project, especially in light of the abundance of formality from Anton's original post. Not that I'd have a solution. Feel free to ignore. Not a perl "bug" but per-se but something changed about validity of my(my..., my...) constructs. There is a patch for the CIVS source which is two years old [1]. That perl "update" seems to have happened after our last vote (where this issue was non-existant afaict) and today. I'll try to find some time tomorrow to adapt the source on the server and let you know to retest your vote. Should effect french, hungarian and italian. Works for Remi now, shall be fixed now. Thanks, Thilo ___ 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] [ANNOUNCE] upcoming GA vote
Am 26.10.23 um 12:57 schrieb Andreas Rheinhardt: Thilo Borgmann via ffmpeg-devel: Hi, Am 24.10.23 um 23:15 schrieb Anton Khirnov: Hi all, as discussed at the dev meeting at VDD, we need to have a series of votes, the first of which concerns defining when is the GA voter list to be updated. As the previous attempt to vote on this was hampered by email delivery issues, and also criticized due to inadequate advance announcement, the vote was closed and we are going to try again. This time, to avoid any confusion, let me clearly state that this is a declaration of intent to initiate a GA vote next Monday (2023-10-30), unless there are substantial objections. The vote question will be: How do we update the list of active members of the general assembly? Proposed possibilities so far are: * twice a year (1st Jan & 1st July) (suggested at VDD) * before each vote (suggested at VDD) * never (keep the 2020 version) (suggested at VDD) * keep everyone who had vote rights but add active developers each jan/july (suggested by Michael on the ML) Feel welcome to propose additional possibilities until Friday 2023-10-27. Other constructive comments also welcome. To test the voting beforehand this time, I created a test vote with a fake-GA member list. All of the following people should have received a corresponding mail. If you are part of this list, but did not receive an email, check your spam folder for the sender: ffmpeg.vot...@mail.de. Please comment if you didn't get the mail. The list is as follows: andreas.rheinha...@gmail.com Please use my outlook mail address. I used what is given by tools/general_assembly.pl. I think you just need to patch your .mailmap entry. andriy.gel...@gmail.com an...@khirnov.net barryjz...@tencent.com ceffm...@gmail.com c...@passwd.hu dcni...@gmail.com derek.buitenh...@gmail.com d...@lynne.ee devin.heitmuel...@ltnglobal.com epira...@gmail.com ffm...@gyani.pro geo...@nsup.org g...@haasn.dev haihao.xi...@intel.com jamr...@gmail.com jan.ekst...@24i.com j...@itanimul.li jianhua...@intel.com lance.lmw...@gmail.com leo.i...@gmail.com linjie.justin...@gmail.com liuq...@kuaishou.com mar...@martin.st mich...@niedermayer.cc nuomi2...@gmail.com one...@gmail.com p...@palemieux.com phil...@overt.org pr...@xvid.org rco...@rcombs.me r...@remlab.net shubhanshu@gmail.com softwo...@hotmail.com stefa...@gmail.com s...@jkqxz.net thilo.borgm...@mail.de t...@rothenpieler.org u...@pkh.me vittorio.giov...@gmail.com wenbin.c...@intel.com yejun@intel.com z...@zanevaniperen.com zhiliz...@tencent.com ___ 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 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] financial sustainability Plan A (SPI)
Am 26.10.23 um 21:02 schrieb Kieran Kunhya: * If you have some flashy FFmpeg project you want to work on with a cost of between 5-15k $ then propose it on the mailing list, make yourself ready for some paperwork complexities and some public debate as thats the first time we try this, there will be extra issues likely. And once the community approves it and stefano with you double checks with SPI if we will be able to fund it. Then you can start working on it The mailing list is already an absolute disaster as it is and you now want to put money into the mix? Of course. FFmpeg has a donations account. So the money is already there and already used for the reimbursement requests. Whatever we spent it for needs to be decided by the community. Spending more money instead of just watch it growing is a good thing. That this will lead to more "disaster" is an assumption without basis. Even if this does happen and fails, its still better than not having even tried. Also, you just advertised FFmpeg and asked for more financial support in your talk at Demuxed [1] - so I figure your prefered way of doing that would be to channel money into some company without the community being involved? And since you also advertised explicitly for FFlabs - what is your relation to FFlabs? I own 25% of that company and I am not aware of any relationship. You just did advertise FFlabs because... FFlabs exists? FFlabs is a company co-owned by some FFmpeg developers, it's not FFmpeg nor can it represent it or act on its behalf. As soon as we pay developers via SPI it can become a good zero-trust environment for donators to offer tasks & money to FFmpeg and handle the money flow via SPI. The donators can be sure that their issues are handled properly in the project (on the ML) and do not flow away into some other sink and the developers can be sure to get their money from SPI because the offer is public and backed by the FFmpeg SPI account. Sounds like a quite trustworthy and most importantyl transparent way to handle things and build up trust in potential donators that the money they spent actually end up with FFmpeg. I don't think developers should be paid via SPI for this reason. I think supporting FFmpeg developers via SPI fits perfectly into what we have SPI for in the first place - an independant entity that handles the community funds with absolute objectivity and no intrinsic interest whatsoever. In contrast to any company, including (my own-ish) FFlabs. -Thilo [1] https://drive.google.com/file/d/1B9VoiT6sjW4vWWsp6ipudLz73QtdBbGi/view?usp=sharing ___ 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] financial sustainability Plan A (SPI)
Am 27.10.23 um 03:28 schrieb Kieran Kunhya: Hi, On Thu, 26 Oct 2023 at 12:41, Thilo Borgmann via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: Of course. FFmpeg has a donations account. So the money is already there and already used for the reimbursement requests. Whatever we spent it for needs to be decided by the community. Spending more money instead of just watch it growing is a good thing. That this will lead to more "disaster" is an assumption without basis. Even if this does happen and fails, its still better than not having even tried. Reimbursement requests for clearly defined things like travel costs with receipts, or hardware that the project owns is in no way comparable to consulting work, contracts, statements of work etc. And the current swscale proposal is far from this too. Yes, of course they are different. Most importantly sponsored development needs to be agreed upon beforehand. That does not imply sponsored work is not clearly defined. I miss your argument about why it can't be done in this. Also, you just advertised FFmpeg and asked for more financial support in your talk at Demuxed [1] - so I figure your prefered way of doing that would be to channel money into some company without the community being involved? Actually if you watched the presentation, I said big companies need to support maintenance (not the same as bounties) of FFmpeg by hiring employees to work full time as they do with Linux Kernel maintainers. Or failing that they can donate to the community - but as you know well the numbers we have are not enough to hire full time maintainers. I'm totally fine with you asking big companies to hire devs for FFmpeg maintenance. That does not relate to my question, though. Do I assume correctly that your prefered way of doing that would be to channel money into some company without the community being involved? Agreement via mailing list for money is a recipe for disaster. What we need are clear statements of work that are voted on by TC. That's not the purpose of the TC. We of course need to have a good way of approving or disapproving proposals and of course we need these to be clearly defined. I again miss to see your argument why that shall not be possible on the ML - everyone on this list knows where your suspicion comes from but again, without even having tried, it's just your assumption and should IMHO not stopping us from trying to implement such a procedure. We can't even agree on patch reviews, throwing money into the mix is throwing gasoline into the fire. Being in conflict about a patch is completely different to conflict about some feature we might want. And no, not everything is as controversial as SDR or gets controversial just because it would be sponsored. You think there would have been real and non-resolvable opposition against bringing multi-threading into ffmpeg.c? You assume a proposed sponsored AV2 decoder will raise such opposition? However, since I agree with you that there will be different oppinions, why would you think that a e.g. a vote/committee or whatever we will choose could not resolve how we deal with these cases? And since you also advertised explicitly for FFlabs - what is your relation to FFlabs? I own 25% of that company and I am not aware of any relationship. You just did advertise FFlabs because... FFlabs exists? FFlabs is a company co-owned by some FFmpeg developers, it's not FFmpeg nor can it represent it or act on its behalf. I linked to the consulting page and also to FFlabs which as far as I know is the only company offering an SLA on FFmpeg. If others existed I would have included them. Nothing wrong about bringing attention to ff.org/consulting or FFlabs. My question is what your relationship with FFlabs is? As soon as we pay developers via SPI it can become a good zero-trust environment for donators to offer tasks & money to FFmpeg and handle the money flow via SPI. The donators can be sure that their issues are handled properly in the project (on the ML) and do not flow away into some other sink and the developers can be sure to get their money from SPI because the offer is public and backed by the FFmpeg SPI account. Sounds like a quite trustworthy and most importantyl transparent way to handle things and build up trust in potential donators that the money they spent actually end up with FFmpeg. Do you really think the way SPI funding is managed currently matches your description? That's exactly the point, to find a procedure that works for sponsored work. Stefano approves by saying "Approved on my side, pending Michael's approval." That won't change because SPI demands it. Done. We can change the names Stefano and Michael into whatever, but that's it. > This is not at all a community driven process where one person can veto > everything. What needs to be setup, is a proc
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
Hi, Am 27.10.23 um 12:43 schrieb Rémi Denis-Courmont: Le 26 octobre 2023 18:45:23 GMT+03:00, Michael Niedermayer a écrit : This is financial sustainability Plan A (SPI) ATM SPI has like 150k $, we do not activly seek donations, we do not currently use SPI money to fund any development. SPI money is ultimately controlled by the FFmpeg community and everything is transparent and public. 1. We should fund some FFmpeg development with SPI-FFmpeg money Why should it be via SPI? What's the benefit of that hypothetical future additional funding going via SPI, as opposed to: obviously transparency and community control. None of which is given by the options you list. - via FFlabs or any other reputable OSS multimedia consulting company, - a consortium of large companies, or - directly to a salaried or freelance developer. Also, it is not that these shall cease to be done. Using SPI money is one more option. It seems the sole benefit is that SPI can solicit donations. So then you are putting the cart before the horses. Secure that extra funding first. To help 2. we should favor flashy, cool development that can bring in more donations That's the part that you'd need to clarify first. What relevant flashy cool development will attract those donations? Why should they be funded by donations rather than more traditional business transactions? Hen & egg. Fortunately, as Michael suggests, we have a starting budget already and 5-10 K seem totally worth exploring this possibility for us. * If you have some flashy FFmpeg project you want to work on with a cost of between 5-15k $ then propose it on the mailing list, make yourself ready for some paperwork complexities and some public debate as thats the first time we try this, there will be extra issues likely. I don't think that code bounties count toward OSS "sustainability". It's condoning the so-called jig economy, which is the opposite, IMO. Code bounties sustain a/the developer(s) working on it and that way they stay active with the project. Of course there are more reliable ways but that does not void bounties. Also, even if Michael just proposed code bounties - nothing stops us from sponsoring non-code-bounties to sustain FFmpeg. For SPI, their limitations are our limitations and they are not limited to code bounties. -Thilo ___ 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] financial sustainability Plan A (SPI)
Am 27.10.23 um 13:30 schrieb Rémi Denis-Courmont: Hi, Le 27 octobre 2023 14:10:15 GMT+03:00, Thilo Borgmann via ffmpeg-devel a écrit : Le 26 octobre 2023 18:45:23 GMT+03:00, Michael Niedermayer a écrit : This is financial sustainability Plan A (SPI) ATM SPI has like 150k $, we do not activly seek donations, we do not currently use SPI money to fund any development. SPI money is ultimately controlled by the FFmpeg community and everything is transparent and public. 1. We should fund some FFmpeg development with SPI-FFmpeg money Why should it be via SPI? What's the benefit of that hypothetical future additional funding going via SPI, as opposed to: obviously transparency and community control. None of which is given by the options you list. Do you want transparency there? This is *not* about having open source code and the public code review. Yes, absolutely. We are an *open* project. And no, we of course don't talk about the review part. This is about people's work commitments and compensation. Martin and I are about the only people here whose taxable income is public information. It doesn't seem to me that people typically want that sort of information public. If s.o. is not fine with receiving these funds in public, than this is not our public money's problem. This cuts off this individual from receiving SPI money in the first place but not cutting anyone off the other options you listed. We don't refund in private for travel & hardware, same must be true for SPI sponsored development. And then that means more non-technical work for the unpaid *other* members of the community in managing the paid developers' work. This is also unlikely to ve welcome to most. - via FFlabs or any other reputable OSS multimedia consulting company, - a consortium of large companies, or - directly to a salaried or freelance developer. Also, it is not that these shall cease to be done. Using SPI money is one more option. Using SPI money would hypothetically be an option if there was enough money. Currently there is not. There is enough budget to fund several of the smaller tasks Michael proposed. That's the part that you'd need to clarify first. What relevant flashy cool development will attract those donations? Why should they be funded by donations rather than more traditional business transactions? Hen & egg. What? Why do you need to start spending money before you can have ideas of cool projects? That makes zero sense to me. What? Michael asked specifically to propose cool projects. * If you have some flashy FFmpeg project you want to work on with a cost of between 5-15k $ then propose it on the mailing list, make yourself ready for some paperwork complexities and some public debate as thats the first time we try this, there will be extra issues likely. I don't think that code bounties count toward OSS "sustainability". It's condoning the so-called jig economy, which is the opposite, IMO. Code bounties sustain a/the developer(s) working on it and that way they stay active with the project. No they don't. They make up a precarious insecure and unstable financial situation. That's the literal opposite of sustainability. It's fine to take a bounty as a bit of extra income, or as an internship, but that is about it. That might be true for you and not for others. You deleted history here where I said there are more reliable ways but they don't void bounties and that even if this thread is about bounties, we are not limited to them. -Thilo ___ 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] [ANNOUNCE] upcoming GA vote
Am 27.10.23 um 13:24 schrieb Jan Ekström: On Wed, Oct 25, 2023 at 4:14 PM Thilo Borgmann via ffmpeg-devel wrote: Hi, Am 24.10.23 um 23:15 schrieb Anton Khirnov: Hi all, as discussed at the dev meeting at VDD, we need to have a series of votes, the first of which concerns defining when is the GA voter list to be updated. As the previous attempt to vote on this was hampered by email delivery issues, and also criticized due to inadequate advance announcement, the vote was closed and we are going to try again. This time, to avoid any confusion, let me clearly state that this is a declaration of intent to initiate a GA vote next Monday (2023-10-30), unless there are substantial objections. The vote question will be: How do we update the list of active members of the general assembly? Proposed possibilities so far are: * twice a year (1st Jan & 1st July) (suggested at VDD) * before each vote (suggested at VDD) * never (keep the 2020 version) (suggested at VDD) * keep everyone who had vote rights but add active developers each jan/july (suggested by Michael on the ML) Feel welcome to propose additional possibilities until Friday 2023-10-27. Other constructive comments also welcome. To test the voting beforehand this time, I created a test vote with a fake-GA member list. All of the following people should have received a corresponding mail. If you are part of this list, but did not receive an email, check your spam folder for the sender: ffmpeg.vot...@mail.de. Please comment if you didn't get the mail. The list is as follows: andreas.rheinha...@gmail.com andriy.gel...@gmail.com an...@khirnov.net barryjz...@tencent.com ceffm...@gmail.com c...@passwd.hu dcni...@gmail.com derek.buitenh...@gmail.com d...@lynne.ee devin.heitmuel...@ltnglobal.com epira...@gmail.com ffm...@gyani.pro geo...@nsup.org g...@haasn.dev haihao.xi...@intel.com jamr...@gmail.com jan.ekst...@24i.com I have received the e-mail this time, which is great. But it seems like my worry about the mail map being the wrong way around was not unfounded. This e-mail is not the "community member Jan" me, and should never have any committer cases as I generally attempt to air gap the two sides. I'll try to post a patch today either inverting their order (which hopefully outputs my community member e-mail), or - since this e-mail is never supposed to apply to any committer cases - removing it. Andreas might be in the same boat. If necessary, we could have a seperate .mailmap_voting file only used in the GA script. Patches welcome, I guess. -Thilo ___ 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] financial sustainability Plan A (SPI)
Am 27.10.23 um 15:38 schrieb Kieran Kunhya: On Fri, 27 Oct 2023 at 03:23, Thilo Borgmann via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: Am 27.10.23 um 03:28 schrieb Kieran Kunhya: Hi, On Thu, 26 Oct 2023 at 12:41, Thilo Borgmann via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: Of course. FFmpeg has a donations account. So the money is already there and already used for the reimbursement requests. Whatever we spent it for needs to be decided by the community. Spending more money instead of just watch it growing is a good thing. That this will lead to more "disaster" is an assumption without basis. Even if this does happen and fails, its still better than not having even tried. Reimbursement requests for clearly defined things like travel costs with receipts, or hardware that the project owns is in no way comparable to consulting work, contracts, statements of work etc. And the current swscale proposal is far from this too. Yes, of course they are different. Most importantly sponsored development needs to be agreed upon beforehand. That does not imply sponsored work is not clearly defined. I miss your argument about why it can't be done in this. Do you seriously think this project will have a sudden outbreak of professionalism and suddenly start producing detailed contracts and statements of work? The current level appear appealing enough to try and see. It'll end up being a few lines on the mailing list. Just your pessimistic assumption. Also, you just advertised FFmpeg and asked for more financial support in your talk at Demuxed [1] - so I figure your prefered way of doing that would be to channel money into some company without the community being involved? Actually if you watched the presentation, I said big companies need to support maintenance (not the same as bounties) of FFmpeg by hiring employees to work full time as they do with Linux Kernel maintainers. Or failing that they can donate to the community - but as you know well the numbers we have are not enough to hire full time maintainers. I'm totally fine with you asking big companies to hire devs for FFmpeg maintenance. That does not relate to my question, though. Do I assume correctly that your prefered way of doing that would be to channel money into some company without the community being involved? Contractually yes, this is a better solution. It allows the company to be in charge of delivery of the maintenance work with a contract behind it. Do you seriously think big companies will suddenly hand over money to the community that's got weekly drama around it? This point was raised to me by a big company that shall remain nameless at Demuxed. There is no need for a company to put money in before they are happy with the community response. If there is no history of such a procedure, uncertainty will remain. Just another reason to try implementing it. And companies not liking the procedure in general have several other options left. Agreement via mailing list for money is a recipe for disaster. What we need are clear statements of work that are voted on by TC. That's not the purpose of the TC. We of course need to have a good way of approving or disapproving proposals and of course we need these to be clearly defined. I again miss to see your argument why that shall not be possible on the ML - everyone on this list knows where your suspicion comes from but again, without even having tried, it's just your assumption and should IMHO not stopping us from trying to implement such a procedure. The mailing list isn't the be all and end all of all communications and decision making in the world. History shows it's atrocious for making decisions. Many people make valid and succinct points that are outright ignored, whoever writes the longest wall of text (often with conspiratorial ramblings that I'm sure go down well with potential donors) seems to get the most attention (i.e quantity vs quality). Don't blame mailing lists. It's just the tool we currently use, if we switch to s.th. else, than it is that. The problem will always exist no matter the tool - except you want no public access to it. The point is that it goes over FFmpeg's channel of communication where all project-wide things are discussed and eventually decided. Lots of people have left the project (e.g Derek) because of the toxicity of this mailing list. Even the Linux Kernel realised their mailing list was toxic and changed. It's again not the mailing list why they left, but the toxic behaviour from people using it. Nothing changes in that regard, no matter the tool. We can't even agree on patch reviews, throwing money into the mix is throwing gasoline into the fire. Being in conflict about a patch is completely different to conflict about some feature we might want. And no, not everything is as controversial as SDR or
[FFmpeg-devel] FFmpeg - Winner of The 2nd ZEISS FOSS Funding Award
Hi, FFmpeg is the winner of the 2nd ZEISS FOSS Funding Award [1]! We have received $1,001.40 that comes with this award in our SPI account. -Thilo [1] https://blogs.zeiss.com/digital-innovation/en/zeiss-strengthens-engagement-in-foss-community/ ___ 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] avformat/mov: Add support for demuxing still HEIC images
Thank you. I have emailed the samples to samples-requ...@ffmpeg.org. I will ping this thread once they are uploaded. Could somebody please help upload the sample files sent to samples-requ...@ffmpeg.org so that this patch can be merged? Thank you! Done, sorry for delay. Same for the avif samples. -Thilo ___ 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] financial sustainability Plan A (SPI)
Hi,
Am 28.10.23 um 16:20 schrieb Ronald S. Bultje:
Hi,
On Thu, Oct 26, 2023 at 11:45 AM Michael Niedermayer
wrote:
This is financial sustainability Plan A (SPI)
ATM SPI has like 150k $, we do not activly seek donations, we do not
currently
use SPI money to fund any development. SPI money is ultimately controlled
by
the FFmpeg community and everything is transparent and public.
1. We should fund some FFmpeg development with SPI-FFmpeg money
2. We should activly seek more donations for SPI-FFmpeg
To help 2. we should favor flashy, cool development that can bring in more
donations
Hm... There's a lot going in the above. I'd like to dissect. With 2, are
you looking for end user donations, or corporate contributions? Without
trying to be too picky, I believe they are different. Users like flashy new
features. My impression from discussions is that corporations are asking
for a lot of things, but flashy new features aren't the ones I've heard
them ask for.
With his Demuxed lightning talk, Kieran was aiming for corporate
contributions, not end user donations. I'd like to play advocate for the
devil for a second. Why would they do that? What might their desired
outcomes be?
- a more stable, polite, professional community (community sustainability)
- continued codebase maintenance, support, bugfixing (codebase
sustainability)
- so that devs who write features important to them might stay around and
maintain said features and possibly even become friendly mentors /
reviewers for future contributors - maybe even develop more features
(developer sustainability)
I also think they'd like safeguards in place. If they are willing to set
aside non-trivial amounts of *their* (not ours) money that can pay for the
annual lifelihood of a fulltime developer ("salary"), then this can no
longer be carried with community votes of an often hostile community. I
agree with Michael's point earlier that 501c3 donations are tax-deductible
for US-based corporations, which might be helpful. Maybe that can be done
with EU-based non-profits also (not an expert there). More importantly,
though, is that I doubt they would just "give" the money and sit on the
sidelines. They'd ask for a seat at the table in return - it is *their*
money, after all. In US non-profits, this is called an advisory board.
Also, these non-profits are usually run by an executive director which has
the support of that board & community. This guarantees some professional
accountability, e.g. to ensure the donations are used for useful purposes
in a somewhat-professional/accountable fashion (not just parties).
Some of this probably sounds scary to some of you. But the idea that they'd
just throw us some money and see what happens is equally scary to them. Our
community's track record (professionalism, politeness, self-sustainability)
is not good enough for that.
I don't mind where the SPI money comes from. If it does not come from scared
companies, that's fine. If they require more paperwork and won't do it via SPI,
that's fine as well. We can give them some alternatives, like Kieran did, that
fit into their world.
Right now, as we have no way accepted to spent SPI money except for travel & hw,
it is also not very appealing to donate at all - because nothing happens with
the money, either for the donors direct interests nor general interests in the
project.
What this is about, is to set up a way to properly spend the SPI money aside
from travel & hw. Why we should not do it because some companies beurocracy, I
cannot see. If we would have a proper way to spend the money, donating could
become more appealing. If we set this up and we know it could be brought to good
use, instead of sitting in the account, it could make donating more appealing
and advertising for that way easier. And if it does not, we lost exactly nothing.
-Thilo
___
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] financial sustainability Plan A (SPI)
Am 28.10.23 um 18:43 schrieb Ronald S. Bultje: Hi Thilo, On Sat, Oct 28, 2023 at 11:31 AM Thilo Borgmann via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: What this is about, is to set up a way to properly spend the SPI money aside from travel & hw. Why we should not do it because some companies beurocracy, I cannot see. I sincerely don't think the above description is what Kieran meant when he talked about sustainability at Demuxed, which this thread seems to be a response to. I am pretty sure Michael did not start this thread because of Kieran's talk, but only he can tell. His talk was just hours ago and I was not there but got that picture from his slide quickly. That I even mentioned it, was my honest interest about his connection to FFlabs - well, it just made him being angry about me now, so I don't persue that any further and for the discussion, its completely irrelevant. I should have made it more clear its more like a side note. Yes, it appears that "sustainability" used in both, the talk and the thread, has been received in a wrong way regarding to this discussion from almost anyone involved and raised the level of confusing argumentation you mention below. I'm happy to elaborate, but I think we're talking about two completely different things at this point. Spending SPI money is great. But Kieran talked about *raising* donations from the very companies you (seem to?) prefer to ignore because of their bureaucracy. If we're talking about distinct things, we'll likely end up with distinct (and multiple) solutions. I agree to the most extend of that. Maybe it could be worthwhile to split this discussion into both parts of it. I ignore, or better say don't care about, companies in regard to fund development (or whatever) over SPI in the context of this discussion _IF_ they are blocked doing that because of their bureaucracy. And if they do, I am obviously happy to deal with them in a way that suits them. -Thilo ___ 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] [ANNOUNCE] upcoming GA vote
Hi, To test the voting beforehand this time, I created a test vote with a fake-GA member list. All of the following people should have received a corresponding mail. If you are part of this list, but did not receive an email, check your spam folder for the sender: ffmpeg.vot...@mail.de. Please comment if you didn't get the mail. The list is as follows: [...] the language issue had been resolved and no further complains arrived. Thus I ended the testvote and we should be good to go. -Thilo ___ 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
Am 29.10.23 um 14:51 schrieb Jean-Baptiste Kempf: On Sun, 29 Oct 2023, at 10:30, Nicolas George wrote: Michael Niedermayer (12023-10-28): It was just that jb told me "6.1 opportunity is gone. Unsubstantiated opinion, let us ignore it. Not like your opinions that are always substantiated... Except I explain many times why the opportunity has passed for 6.1, but you, once again, don't listen, or refuse to be on the means where we discuss. Where? I don't see you saying that in this thread. If you said so at VDD, that's not many times. Not being at where you say s.th. does not imply anything and is not an argument. Again, a personal attack, from you. If you find calling your opinion unsubstantiated a personal attack, then why do you reply with the same personal attack? -Thilo ___ 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
Am 29.10.23 um 17:25 schrieb Jean-Baptiste Kempf: On Sun, 29 Oct 2023, at 16:10, Thilo Borgmann via ffmpeg-devel wrote: Where? I don't see you saying that in this thread. If you said so at VDD, that's not many times. Explained three times at VDD and several time on IRC. Very well. Assuming with "explained" you mean that you gave your reasoning as well, instead of just that statement which was quoted. Because the lack of that is what Nicolas led to refuse your opinion. Not being at where you say s.th. does not imply anything and is not an argument. Refusing to attend the developer meetups and also refusing to be on one of the major discussion media and then complaining about not receiving information is a problem in an open source community. Communication is the biggest problem indeed. In this case as well, I think you should have transported your reasoning back to this thread on the ML - you cannot blame anyone for not following live discussion like VDD or IRC. If you would have done so, your opinion could not have been waived away like Nicolas did. -Thilo p.s. sure, IRC is not really live, yet we expect to follow up on history only on the ML. Which is one reason why we say things like "as agreed on by X on IRC" in patch threads, for example. ___ 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
Am 29.10.23 um 18:56 schrieb Jean-Baptiste Kempf: On Sun, 29 Oct 2023, at 18:20, Thilo Borgmann via ffmpeg-devel wrote: In this case as well, I think you should have transported your reasoning back to this thread on the ML - It's actually in this very thread on the ML about the timing and prefering 7.0 over 6.1. I even send a longer email to explain. I wonder why you didn't say that one iteration back when I asked you where to find it. (Your answer was "at VDD & on IRC", just not to delete too much history here.) Anyway, in this very thread (and in the Release 6.1 thread started from Michael before this thread of Lynne) I can see exactly 3 prior mails from you. 06.07.23, "good idea lets do 6.1" 26.09.23, "calling people liars is bad" 21.09.23, "+1" As well as the many mails from today, of course. So is this problem on my mail client end? Can you provide links into the archives regarding the mails you are referring to? -Thilo ___ 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
Am 29.10.23 um 19:12 schrieb Nicolas George: Jean-Baptiste Kempf (12023-10-29): Sorry, I can. Being on IRC is necessary, IMHO. Completely unacceptable and fortunately not true at all. The mailing-list has always been the main channel of development, anything synchronous, that requires people to be on line at the same time, is unsuited for a project on multiple timezones where everybody is equal but nobody has an obligation. And I think it is very bad that some body with apparent authority suggests otherwise. +1 -Thilo ___ 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] [ANNOUNCE] upcoming GA vote
Am 30.10.23 um 09:18 schrieb Jean-Baptiste Kempf: Hello, On Sun, 29 Oct 2023, at 10:33, Anton Khirnov wrote: vote question (unchanged): How do we update the list of active members of the general assembly? Available answers: * twice a year (1st Jan & 1st July, 0:00 UTC); as an exception, the list will also be updated immediately after this vote (suggested at VDD, added time and the exceptional update clause) * before each vote (suggested at VDD) * never (keep the 2020 version) (suggested at VDD) * keep everyone who had vote rights but add active developers each 1st Jan and 1st July, 0:00 UTC; as an exception, the list will also be updated immediately after this vote (suggested by Michael on the ML, clarified date and time, added the exceptional update clause) If nobody has significant objections, we will go with the above for the actual vote tomorrow. This has been launched. You should be able to vote until Sunday 5th Nov, 23:59 Sure you did not just create the vote but started it already as well? I should be part of the GA but didn't get a mail... -Thilo ___ 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] [ANNOUNCE] upcoming GA vote
Am 30.10.23 um 11:50 schrieb Jean-Baptiste Kempf: On Mon, 30 Oct 2023, at 11:33, Thilo Borgmann via ffmpeg-devel wrote: Am 30.10.23 um 09:18 schrieb Jean-Baptiste Kempf: Hello, On Sun, 29 Oct 2023, at 10:33, Anton Khirnov wrote: vote question (unchanged): How do we update the list of active members of the general assembly? Available answers: * twice a year (1st Jan & 1st July, 0:00 UTC); as an exception, the list will also be updated immediately after this vote (suggested at VDD, added time and the exceptional update clause) * before each vote (suggested at VDD) * never (keep the 2020 version) (suggested at VDD) * keep everyone who had vote rights but add active developers each 1st Jan and 1st July, 0:00 UTC; as an exception, the list will also be updated immediately after this vote (suggested by Michael on the ML, clarified date and time, added the exceptional update clause) If nobody has significant objections, we will go with the above for the actual vote tomorrow. This has been launched. You should be able to vote until Sunday 5th Nov, 23:59 Sure you did not just create the vote but started it already as well? I should be part of the GA but didn't get a mail... I'm quite sure, since some people have already started voting. I received the mail now at 11:55, thx. -Thilo ___ 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] financial sustainability Plan A (SPI)
Am 31.10.23 um 18:48 schrieb Michael Niedermayer: On Tue, Oct 31, 2023 at 06:37:58PM +0100, Hendrik Leppkes wrote: On Tue, Oct 31, 2023 at 6:31 PM Michael Niedermayer wrote: On Tue, Oct 31, 2023 at 07:19:41PM +0200, Rémi Denis-Courmont wrote: Le tiistaina 31. lokakuuta 2023, 18.58.57 EET Michael Niedermayer a écrit : That's not a credible solution for a library. All reverse dependency developers would disable that before they ship affected FFmpeg versions, or worse, just stop updating their vendored FFmpeg. If its announced and we point to the commit, maybe half the minor users will remove it, maybe most of the bigger ones. If its not announced noone would remove it. companies do not audit the FFmpeg commits. They would remove it after seeing it but at that point it did what it intended to to, inform users again, like i said thats hypothetical and controversal. But basically doing the same as companies which put advertisements in without asking either creator nor viewer. How do you show ads without a GUI? Hijack the video signal from the decoder? In this very very hypothetical idea ... it would not be a add, but a simple information box shown briefly that says something like "decoded with ffmpeg.org, donate if you enjoy" / "encoded with ffmpeg.org, donate if you enjoy" If as a professional user of a decoder library, it starts putting in an ad or a watermark or whatever you want to call it, even if briefly, i'm looking for a new decoder library, or will venture to remove the message instantly. And if that wasn't enough to completely destroy the projects reputation, if you then try to hide it by randomizing or whatever, so that testing before deployment doesn't see it, that definitely will. This is not acceptable behavior for a decoder. And no "exposure" due like i said, its a hypothetical and controversal thought experiment to bad press will actually yield you a benefit. Companies won't pay you, because that doesn't get rid of the message. That misses the goal, the goal of this was to reach some of the more than 1 billion users we have and who do not know they are using FFmpeg. They'll pay an engineer to disable it. it would just show up once lets say on a specific day 1 year after the code is added. we would remove it on that day ourselfs. It would just be a simple one time shown message that says "Decoded by ffmpeg.org / Please donate, if you enjoy" Just my two cents and I admit I only flew over the last few mails. Some visual output into the decoded streams or things alike (IIUC) should be a nogo. Immediate memories about bad pirated movies comes to mind... so if this is the idea, we should really not do this, especially not (IIUC) if it would occur pseudo-randomly based on some time constraint. The one way I think this might be done, would be if we create a donations video filter to blend something like this in only if the user specifically adds this filter to their chain. In contrast, the idea of printing some "please donate" into the command line output I find quite ok. We could add one line with compressed info. The reach of that is big and should not offend any user at all (assuming it does also disappear if we set silent mode). How big this impact might be, was revealed by the deprication message libav added back in the days. Although it is of course not that news-worthy. -Thilo ___ 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
Am 29.10.23 um 20:27 schrieb Jean-Baptiste Kempf: On Sun, 29 Oct 2023, at 19:46, Thilo Borgmann via ffmpeg-devel wrote: Am 29.10.23 um 18:56 schrieb Jean-Baptiste Kempf: On Sun, 29 Oct 2023, at 18:20, Thilo Borgmann via ffmpeg-devel wrote: In this case as well, I think you should have transported your reasoning back to this thread on the ML - It's actually in this very thread on the ML about the timing and prefering 7.0 over 6.1. I even send a longer email to explain. I wonder why you didn't say that one iteration back when I asked you where to find it. (Your answer was "at VDD & on IRC", just not to delete too much history here.) Anyway, in this very thread (and in the Release 6.1 thread started from Michael before this thread of Lynne) I can see exactly 3 prior mails from you. Mail are not just from me, but about me. Quoting the mail that supposedly quotes me: "6.1 opportunity is gone. We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January" I think it's very clear about "opportunity" and "late on the schedule" and what they mean. You decided then it was not clear and "unsubstantiated", and therefore that my opinion had no value, so I had to expand on it. I did not. So, I spoke about it at VDD, several time, on IRC and it refers to me on this very mailing list. And instead of asking me to clarify, you started to say that my opinion had no value, and then attacking me. Asking for clarification is exactly what I did by asking you where to find your elaborations. You are attacking me here. -Thilo ___ 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] FFmpeg at NAB 2024
Hi, FFmpeg will have a booth at the next NAB from April 14th to 17th 2024 in Las Vegas [1]! We reiceived an anonymous corporate sponsorship for the booth, so there are no costs for the FFmpeg project to it (and no obligations, of course). Any FFmpeg developer is welcome to join in and man the booth with me, especially any developers based in the US or other american countries! Share with us your broken workflows, unfulfilled requirements, ideas for enhancements and after show drinks at W4232 [2]! -Thilo [1] https://cloud.e.nabshow.com/2024/ [2] https://nab24.mapyourshow.com/8_0/exhview/?hallID=W&selectedBooth=W4232 ___ 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] tools/general_assembly.pl - print names with emails
Hi, sorry can't comment on the ML atm as people will wonder why I respond to this but not to other "more important" mails... Set aside that I think its complete nonsense not to share the list of mail addresses directly for any legal consideration - all these mail addresses were put into a public repo and used on a public ML and there is no reason not to reshare public info. However if people (next to JB who I don't believe is actually having any legal considerations...) don't like it... The script should output two files then, so that no manual editing is required. The voting system expects a file with mail addresses one per line and the ML then shall be given the very same list but with only the names. Therefore I think the script should just output two files, ga_names.txt and ga_mails.txt. Thanks for the patch! -Thilo Am 03.11.23 um 20:18 schrieb Cosmin Stejerean via ffmpeg-devel: On Nov 3, 2023, at 11:40 AM, Nicolas George wrote: This is also changing the sort order. It might be acceptable but it might also not be. It is and I probably should have called that out in the description. If the goal is to publish mostly names and not emails in various places like this list then it seems sorting by name would be more natural. But I'm happy to to update the patch with whatever sort order we want to use. - Cosmin ___ 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 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] tools/general_assembly.pl - print names with emails
Am 05.11.23 um 14:41 schrieb Thilo Borgmann via ffmpeg-devel: Hi, sorry can't comment on the ML atm as people will wonder why I respond to this but not to other "more important" mails... Having sent this private mail to the ML anyways just proves how much I should not post to the ML in my current state :-/ -Thilo ___ 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] [ANNOUNCE] upcoming vote: extra members for GA
Am 09.11.23 um 18:50 schrieb Michael Niedermayer: On Thu, Nov 09, 2023 at 06:31:13PM +0100, Jean-Baptiste Kempf wrote: On Thu, 9 Nov 2023, at 18:24, Michael Niedermayer wrote: theres a list of voters in 2020 and 2023 The list of voters in 2020 comes from the script written by Josh (IIRC?) and run by Thilo (?) IIRC when Thilo installed CIVS. It quite matches the gitlog. The list was reused for the vote, Thats not possible multiple people on this list did not have 20 commits at the time the list must have been made Example: Gautam Ramakrishnan has 20 commits after 2020 Jul 16 but the TC/CC votes in 2020 where prior to that (and i already mentioned zane) So I do not see how the list of names you posted can be the same list as the one used in 2020 The script came in by Josh [1]. The vote was run by JB [2]. In [2] the CIVS reported 49 authorized voters as JB mentioned in the mail. Therefore, it cannot be the list of 51 voters JB provided in the corresponding thread [3]. Did the original list survive? Josh? If not, we can go back in time and run the script again. -Thilo [1] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2020-April/261323.html [2] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2020-June/265075.html [3] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316594.html ___ 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] [ANNOUNCE] upcoming vote: extra members for GA
Am 10.11.23 um 13:39 schrieb Kieran Kunhya via ffmpeg-devel: The list does not match your list, for example Gautam is on your list but not on joshs So my question is still standing, can you explain how your list was created? or where its from? How was the list of your root admins created? Who decided they would be root? Unhelpful whataboutism. -Thilo ___ 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] [ANNOUNCE] Repeat vote: GA voters list updates
Hi, in [1] JB listed his list of authorized voters for the "GA voters list updates" vote. This list does not correlate with the list Josh provided in [2]. Neither does this list of 51 people [1] correlate to the 54 authorized voters (distinct email addresses) the CIVS system actually counted, see [3]. This can mean only one of two things, either some people on the list in [1] did receive more than one ballot, or JB failed to list all the authorized voters and ballots have been given to unknown people. Both possibilities are unacceptable flaws for a democratic vote. As the admin responsible of the votes it is my duty to have supervision of all polls and thus it is my duty to declare this vote null and void for the flaws given above. This vote will be repeated from Sun 12th of November to Sunday 19th of November so we don't have to move the following votes yet another time. It will be using the list given by Josh [2] as it seems to be the closest to the truth we can get. The old extra members of the GA have become void according to [4] and will not be included. Furthermore, I patched the voting system to log all authorized voters in the future to prevent this situation in the future. The authorized voters for the repeated vote [2] reads as follows: mich...@niedermayer.cc one...@gmail.com jamr...@gmail.com andreas.rheinha...@gmail.com s...@jkqxz.net c...@passwd.hu ceffm...@gmail.com barryjz...@tencent.com liuq...@kuaishou.com lance.lmw...@gmail.com martin.vign...@gmail.com ffm...@gyani.pro a...@tmm1.net mar...@martin.st di...@biurrun.de lizhong1...@gmail.com d...@lynne.ee nfx...@googlemail.com an...@khirnov.net atomnu...@gmail.com t...@rothenpieler.org u...@pkh.me geo...@nsup.org yejun@intel.com linjie...@intel.com kaustubh.ra...@imgtec.com stebb...@jetheaddev.com phil...@overt.org andriy.gel...@gmail.com vittorio.giov...@gmail.com jerome.borsb...@carpalis.nl derek.buitenh...@gmail.com pr...@xvid.org j...@itanimul.li kjeya...@akamai.com dalecur...@chromium.org jee...@gmail.com t.r...@noa-archive.com vdi...@akamai.com zhiliz...@tencent.com matthieu.bou...@gmail.com yinshiyou...@loongson.cn z...@zanevaniperen.com ruiling.s...@intel.com kjeya...@akamai.com hwr...@126.com modma...@google.com c...@gmx.com fooba...@gmail.com baptiste.coudur...@gmail.com -Thilo [1] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316594.html [2] https://www.irccloud.com/pastebin/KNrvxILA/Votes_2020.txt [3] https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_029f7195fed7aadf [4] https://ffmpeg.org/community.html#General-Assembly-1 ___ 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] [ANNOUNCE] Repeat vote: GA voters list updates
Hi, for privacy reasons I must use JB's quote as given in the archives and need to drag this reply up one level. If the addresses in the redacted part need to be referred to, they shall be referred to as AddressA and AddressB. I will address more replies once time allows, JB's reply is actually the one mail that addresses the cause of this whole mess so I reply to it now (asap). I will also start the repeat vote now and everybody can hold their horses before going to flamewar. Depending on JB's explanations, he might still prove that the old vote is valid and this repeat vote becomes void. Anyway, if he cannot, this needs to follow the given timeframe. On we go: Am 11.11.23 um 10:54 schrieb Jean-Baptiste Kempf: On Sat, 11 Nov 2023, at 08:22, Thilo Borgmann via ffmpeg-devel wrote: Neither does this list of 51 people [1] correlate to the 54 authorized voters (distinct email addresses) the CIVS system actually counted, see [3]. And instead of you ASKING for that, you launch another vote? That's your solution? Very well, then let me ask you to share, even privately if you have privacy concerns, the following data that might help to invalidate my claims and probably shortcut the whole when what and how questions in the other half of the mail: - The file(s) you used for the first and second batch. I'd assume you did the editing you mention below in the same file, so it's of course reasonable if you therefore could only share the one file used for the second batch after editing. - The mail the poll supervisor gets with the subject like "CIVS poll created: " so that I can look at the control panel. The mail says you should keep it private so nobody can interrupt with the poll in progress. The vote is over, results known and a lockfile set so nothing can happen anymore to the vote. Just as as remark, YOU are running the voting system, and have access to infra, so YOU can check it. The answer is simple, Linjie Fu has had several emails in use, (one with and one without justin) and one of them is bouncing. I remembered that after sending the first batch, so I added it back, knowing that he/she could only vote once. Same reason for Ruiling Song who has both an Intel and a gmail email. Finally, in the emails, there was REDACTED FOR GDPR/PRIVACY. It was probably the reason. This is not completely clear to me so let me ask for clarification here as well. The logfile (attached) says: The first batch sent out were 53 mails (from 10:11:19 to 10:12:20) The second batch sent out were 53 mails (from 10:16:20 to 10:16:48) One single mail was sent (at 12:55:40) In the end, the counter is at 54. In the end, you named 51 distinct people. So the first batch must have been 53 distinct mail addresses, raising the counter from 0 to 53. The second batch must also have contained 53 distinct mail addresses because 53 mails have been sent. After the second batch, the counter must have been at 53 or 54 already, depending on wether or not the one single mail that was sent afterwards was already in one of the batches or yet another distinct mail address (counter++). What I understand from your simple answer, is you changed two mail addresses in between batch one and two (Linjie & Ruiling). That would have risen the counter from 53 to 55 after sending the second batch because the two corrected addresses are distinct and counted. Depending on wether or not the one single mail that was sent afterwards was already in one of the batches or yet another distinct mail address (counter++), the counter would have to be 55 or 56. Can you clarify what mail addresses you changed from what into what between batch one and batch two? Can you clarify if the single mail that was sent afterwards was already in one of the batches or yet another distinct mail address? And that's why you see 3 more emails than names. And that cannot change anything to the vote. jb -ThiloMon Oct 30 10:11:19 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:20 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:20 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:21 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:41 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:41 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:42 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:44 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:45 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:45 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:46 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:4
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Am 14.11.23 um 10:28 schrieb Tomas Härdin: lör 2023-11-11 klockan 10:42 +0100 skrev Jean-Baptiste Kempf: You have been told, now, several times, that a list of email is a collection of Private Information, according to a GDPR and that you are a process of this PI, and therefore liable to the law. Everyone with a copy of the git repository already has this information, and it has been willingly given by all contributors. Is further processing of already extant PI really not permissible according to the GDPR? Do we have to seek permission from all contributors to publish our git repositories containing PI that they have already given implicit permission to publish? +1 that it is no problem to reshare public information. A problem would arise if we connect this information with other information - new unknown information or an unknown link between the two. That said, this part strikes me as far more relevant wrt the GDPR: I patched the voting system to log all authorized voters in the future to prevent this situation in the future. The logfile before: Sun Nov 5 11:04:32 2023 127.0.0.1 Sending mail to a voter for poll E_af2d343f39602862 Sun Nov 5 11:04:32 2023 127.0.0.1 Sending mail to a voter for poll E_af2d343f39602862 The logfile afterwards: Sun Nov 5 11:04:32 2023 127.0.0.1 Sending mail to a voter for poll E_af2d343f39602862 someth...@somewhere.com Sun Nov 5 11:04:32 2023 127.0.0.1 Sending mail to a voter for poll E_af2d343f39602862 somethinge...@somewhereelse.com The other outputs are unchanged. This does not break any privacy about the ballots - it is still unknown what ballots voted if at all neither what that ballot eventually voted for. This only adds the information which mail addresses are connected to the poll ID E_* (in other words, who was an authorized voter). -Thilo ___ 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] [ANNOUNCE] Repeat vote: GA voters list updates
Hi, This vote will be repeated from Sun 12th of November to Sunday 19th of November so we don't have to move the following votes yet another time. It will be using the list given by Josh [2] as it seems to be the closest to the truth we can get. The old extra members of the GA have become void according to [4] and will not be included. the results are available at [1]. As they confirm the just updated GA list as well as the update procedure twice a year on Jan 1st & Jul 1st, I think the upcoming votes (extra GA members, TC/CC elections) can then proceed as announced. -Thilo [1] https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_07e9c717f7820201 ___ 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] [PATCH v5 0/7] webp: add support for animated WebP decoding
Still images fixed, includes FATE tests, VP8 decoder decoupled so there are no more data races. Patch 5/7 is still there for making changes in lavc&webp reviewable but shall be stashed when pushing. -Thilo Josef Zlomek (2): libavcodec/webp: add support for animated WebP decoding libavformat/webp: add WebP demuxer Thilo Borgmann (5): avcodec/webp: move definitions into header avcodec/webp: remove unused definitions avcodec/webp_parser: parse each frame into one packet avcodec/webp: make init_canvas_frame static fate: add test for animated WebP Changelog | 2 + doc/demuxers.texi | 28 + libavcodec/codec_desc.c | 3 +- libavcodec/version.h| 2 +- libavcodec/webp.c | 758 ++-- libavcodec/webp.h | 38 + libavcodec/webp_parser.c| 130 ++-- libavformat/Makefile| 1 + libavformat/allformats.c| 1 + libavformat/version.h | 2 +- libavformat/webpdec.c | 733 +++ tests/fate/image.mak| 3 + tests/ref/fate/exif-image-webp | 12 +- tests/ref/fate/webp-anim| 22 + tests/ref/fate/webp-rgb-lena-lossless | 2 +- tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +- tests/ref/fate/webp-rgb-lossless| 2 +- tests/ref/fate/webp-rgb-lossy-q80 | 2 +- tests/ref/fate/webp-rgba-lossless | 2 +- tests/ref/fate/webp-rgba-lossy-q80 | 2 +- 20 files changed, 1625 insertions(+), 122 deletions(-) create mode 100644 libavcodec/webp.h create mode 100644 libavformat/webpdec.c create mode 100644 tests/ref/fate/webp-anim -- 2.39.2 (Apple Git-143) ___ 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] [PATCH v5 1/7] avcodec/webp: move definitions into header
--- libavcodec/webp.c | 1 + libavcodec/webp.h | 38 ++ 2 files changed, 39 insertions(+) create mode 100644 libavcodec/webp.h diff --git a/libavcodec/webp.c b/libavcodec/webp.c index 54b3fde6dc..4994781a64 100644 --- a/libavcodec/webp.c +++ b/libavcodec/webp.c @@ -52,6 +52,7 @@ #include "thread.h" #include "tiff_common.h" #include "vp8.h" +#include "webp.h" #define VP8X_FLAG_ANIMATION 0x02 #define VP8X_FLAG_XMP_METADATA 0x04 diff --git a/libavcodec/webp.h b/libavcodec/webp.h new file mode 100644 index 00..53bf59e7cd --- /dev/null +++ b/libavcodec/webp.h @@ -0,0 +1,38 @@ +/* + * WebP image format definitions + * Copyright (c) 2020 Pexeso Inc. + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/** + * @file + * WebP image format definitions. + */ + +#ifndef AVCODEC_WEBP_H +#define AVCODEC_WEBP_H + +#define ANMF_DISPOSAL_METHOD0x01 +#define ANMF_DISPOSAL_METHOD_UNCHANGED 0x00 +#define ANMF_DISPOSAL_METHOD_BACKGROUND 0x01 + +#define ANMF_BLENDING_METHOD0x02 +#define ANMF_BLENDING_METHOD_ALPHA 0x00 +#define ANMF_BLENDING_METHOD_OVERWRITE 0x02 + +#endif /* AVCODEC_WEBP_H */ -- 2.39.2 (Apple Git-143) ___ 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] [PATCH v5 2/7] avcodec/webp: remove unused definitions
--- libavcodec/webp.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/libavcodec/webp.c b/libavcodec/webp.c index 4994781a64..286e7c8b73 100644 --- a/libavcodec/webp.c +++ b/libavcodec/webp.c @@ -60,8 +60,6 @@ #define VP8X_FLAG_ALPHA 0x10 #define VP8X_FLAG_ICC 0x20 -#define MAX_PALETTE_SIZE256 -#define MAX_CACHE_BITS 11 #define NUM_CODE_LENGTH_CODES 19 #define HUFFMAN_CODES_PER_META_CODE 5 #define NUM_LITERAL_CODES 256 -- 2.39.2 (Apple Git-143) ___ 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] [PATCH v5 6/7] libavformat/webp: add WebP demuxer
From: Josef Zlomek
Adds the demuxer of animated WebP files.
It supports non-animated, animated, truncated, and concatenated files.
Reading from a pipe (and other non-seekable inputs) is also supported.
The WebP demuxer splits the input stream into packets containing one frame.
It also marks the key frames properly.
The loop count is ignored by default (same behaviour as animated PNG and GIF),
it may be enabled by the option '-ignore_loop 0'.
The frame rate is set according to the frame delay in the ANMF chunk.
If the delay is too low, or the image is not animated, the default frame rate
is set to 10 fps, similarly to other WebP libraries and browsers.
The fate suite was updated accordingly.
Signed-off-by: Josef Zlomek
---
Changelog | 1 +
doc/demuxers.texi | 28 +
libavformat/Makefile| 1 +
libavformat/allformats.c| 1 +
libavformat/version.h | 2 +-
libavformat/webpdec.c | 733
tests/ref/fate/exif-image-webp | 12 +-
tests/ref/fate/webp-rgb-lena-lossless | 2 +-
tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +-
tests/ref/fate/webp-rgb-lossless| 2 +-
tests/ref/fate/webp-rgb-lossy-q80 | 2 +-
tests/ref/fate/webp-rgba-lossless | 2 +-
tests/ref/fate/webp-rgba-lossy-q80 | 2 +-
13 files changed, 777 insertions(+), 13 deletions(-)
create mode 100644 libavformat/webpdec.c
diff --git a/Changelog b/Changelog
index 8f34660767..fce4cda7ba 100644
--- a/Changelog
+++ b/Changelog
@@ -44,6 +44,7 @@ version 6.1:
variable-fields elements within the same parent element
- ffprobe -output_format option added as an alias of -of
- animated WebP parser/decoder
+- animated WebP demuxer
version 6.0:
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index e4c5b560a6..fcb9f9ee3c 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -943,4 +943,32 @@ which in turn, acts as a ceiling for the size of scripts
that can be read.
Default is 1 MiB.
@end table
+@section webp
+
+Animated WebP demuxer.
+
+It accepts the following options:
+
+@table @option
+@item -min_delay @var{int}
+Set the minimum valid delay between frames in milliseconds.
+Range is 0 to 6. Default value is 10.
+
+@item -max_webp_delay @var{int}
+Set the maximum valid delay between frames in milliseconds.
+Range is 0 to 16777215. Default value is 16777215 (over four hours),
+the maximum value allowed by the specification.
+
+@item -default_delay @var{int}
+Set the default delay between frames in milliseconds.
+Range is 0 to 6. Default value is 100.
+
+@item -ignore_loop @var{bool}
+WebP files can contain information to loop a certain number of times
+(or infinitely). If @option{ignore_loop} is set to true, then the loop
+setting from the input will be ignored and looping will not occur.
+If set to false, then looping will occur and will cycle the number
+of times according to the WebP. Default value is true.
+@end table
+
@c man end DEMUXERS
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 329055ccfd..4f0379f13b 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -618,6 +618,7 @@ OBJS-$(CONFIG_WEBM_MUXER)+= matroskaenc.o
matroska.o \
av1.o avlanguage.o
OBJS-$(CONFIG_WEBM_DASH_MANIFEST_MUXER) += webmdashenc.o
OBJS-$(CONFIG_WEBM_CHUNK_MUXER) += webm_chunk.o
+OBJS-$(CONFIG_WEBP_DEMUXER) += webpdec.o
OBJS-$(CONFIG_WEBP_MUXER)+= webpenc.o
OBJS-$(CONFIG_WEBVTT_DEMUXER)+= webvttdec.o subtitles.o
OBJS-$(CONFIG_WEBVTT_MUXER) += webvttenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index d4b505a5a3..d80c2f73a5 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -502,6 +502,7 @@ extern const AVInputFormat ff_webm_dash_manifest_demuxer;
extern const FFOutputFormat ff_webm_dash_manifest_muxer;
extern const FFOutputFormat ff_webm_chunk_muxer;
extern const FFOutputFormat ff_webp_muxer;
+extern const AVInputFormat ff_webp_demuxer;
extern const AVInputFormat ff_webvtt_demuxer;
extern const FFOutputFormat ff_webvtt_muxer;
extern const AVInputFormat ff_wsaud_demuxer;
diff --git a/libavformat/version.h b/libavformat/version.h
index 2a28a3bf40..3d85862bc1 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
#include "version_major.h"
#define LIBAVFORMAT_VERSION_MINOR 17
-#define LIBAVFORMAT_VERSION_MICRO 100
+#define LIBAVFORMAT_VERSION_MICRO 101
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
diff --git a/libavformat/webpdec.c b/libavformat/webpdec.c
new file mode 100644
index 00..b4024809f7
--- /dev/null
+++ b/libavformat/webpdec.c
@@ -0,0 +1,733 @@
+
[FFmpeg-devel] [PATCH v5 3/7] avcodec/webp_parser: parse each frame into one packet
---
libavcodec/webp_parser.c | 130 +++
1 file changed, 89 insertions(+), 41 deletions(-)
diff --git a/libavcodec/webp_parser.c b/libavcodec/webp_parser.c
index bd5f94dac5..da853bb1f5 100644
--- a/libavcodec/webp_parser.c
+++ b/libavcodec/webp_parser.c
@@ -25,13 +25,17 @@
#include "libavutil/bswap.h"
#include "libavutil/common.h"
+#include "libavutil/intreadwrite.h"
#include "parser.h"
typedef struct WebPParseContext {
ParseContext pc;
+int frame;
+int first_frame;
uint32_t fsize;
-uint32_t remaining_size;
+uint32_t remaining_file_size;
+uint32_t remaining_tag_size;
} WebPParseContext;
static int webp_parse(AVCodecParserContext *s, AVCodecContext *avctx,
@@ -41,62 +45,106 @@ static int webp_parse(AVCodecParserContext *s,
AVCodecContext *avctx,
WebPParseContext *ctx = s->priv_data;
uint64_t state = ctx->pc.state64;
int next = END_NOT_FOUND;
-int i = 0;
+int i, len;
-*poutbuf = NULL;
-*poutbuf_size = 0;
-
-restart:
-if (ctx->pc.frame_start_found <= 8) {
-for (; i < buf_size; i++) {
+for (i = 0; i < buf_size;) {
+if (ctx->remaining_tag_size) {
+/* consuming tag */
+len = FFMIN(ctx->remaining_tag_size, buf_size - i);
+i += len;
+ctx->remaining_tag_size -= len;
+ctx->remaining_file_size -= len;
+} else {
+/* scan for the next tag or file */
state = (state << 8) | buf[i];
-if (ctx->pc.frame_start_found == 0) {
-if ((state >> 32) == MKBETAG('R', 'I', 'F', 'F')) {
-ctx->fsize = av_bswap32(state);
-if (ctx->fsize > 15 && ctx->fsize <= UINT32_MAX - 10) {
-ctx->pc.frame_start_found = 1;
-ctx->fsize += 8;
+i++;
+
+if (!ctx->remaining_file_size) {
+/* scan for the next file */
+if (ctx->pc.frame_start_found == 4) {
+ctx->pc.frame_start_found = 0;
+if ((uint32_t) state == MKBETAG('W', 'E', 'B', 'P')) {
+if (ctx->frame || i != 12) {
+ctx->frame = 0;
+next = i - 12;
+state = 0;
+ctx->pc.frame_start_found = 0;
+break;
+}
+ctx->remaining_file_size = ctx->fsize - 4;
+ctx->first_frame = 1;
+continue;
}
}
-} else if (ctx->pc.frame_start_found == 8) {
-if ((state >> 32) != MKBETAG('W', 'E', 'B', 'P')) {
+if (ctx->pc.frame_start_found == 0) {
+if ((state >> 32) == MKBETAG('R', 'I', 'F', 'F')) {
+ctx->fsize = av_bswap32(state);
+if (ctx->fsize > 15 && ctx->fsize <= UINT32_MAX - 10) {
+ctx->fsize += (ctx->fsize & 1);
+ctx->pc.frame_start_found = 1;
+}
+}
+} else
+ctx->pc.frame_start_found++;
+} else {
+/* read the next tag */
+ctx->remaining_file_size--;
+if (ctx->remaining_file_size == 0) {
ctx->pc.frame_start_found = 0;
continue;
}
ctx->pc.frame_start_found++;
-ctx->remaining_size = ctx->fsize + i - 15;
-if (ctx->pc.index + i > 15) {
-next = i - 15;
-state = 0;
+if (ctx->pc.frame_start_found < 8)
+continue;
+
+switch (state >> 32) {
+case MKBETAG('A', 'N', 'M', 'F'):
+case MKBETAG('V', 'P', '8', ' '):
+case MKBETAG('V', 'P', '8', 'L'):
+if (ctx->frame) {
+ctx->frame = 0;
+next = i - 8;
+state = 0;
+ctx->pc.frame_start_found = 0;
+goto flush;
+}
+ctx->frame = 1;
+break;
+default:
break;
-} else {
-ctx->pc.state64 = 0;
-goto restart;
}
-} else if (ctx->pc.frame_start_found)
-ctx->pc.frame_start_found++;
-}
-ctx->pc.state64 = state;
-} else {
-if (ctx->remaining_size) {
-i = FFMIN(ctx->remaining_size, buf_size);
-ctx->remaining_size -= i;
-if (ctx->remaining_size)
-goto flush;
-ctx->pc.frame_start_found = 0;
-goto res
[FFmpeg-devel] [PATCH v5 5/7] avcodec/webp: make init_canvas_frame static
---
libavcodec/webp.c | 142 +++---
1 file changed, 70 insertions(+), 72 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 52ecdb45c5..6017631678 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -1360,7 +1360,76 @@ static int vp8_lossy_decode_frame(AVCodecContext *avctx,
AVFrame *p,
return ret;
}
-int init_canvas_frame(WebPContext *s, int format, int key_frame);
+static int init_canvas_frame(WebPContext *s, int format, int key_frame)
+{
+AVFrame *canvas = s->canvas_frame.f;
+int height;
+int ret;
+
+// canvas is needed only for animation
+if (!(s->vp8x_flags & VP8X_FLAG_ANIMATION))
+return 0;
+
+// avoid init for non-key frames whose format and size did not change
+if (!key_frame &&
+canvas->data[0] &&
+canvas->format == format &&
+canvas->width == s->canvas_width &&
+canvas->height == s->canvas_height)
+return 0;
+
+// canvas changes within IPPP sequences will lose thread sync
+// because of the ThreadFrame reallocation and will wait forever
+// so if frame-threading is used, forbid canvas changes and unlock
+// previous frames
+if (!key_frame && canvas->data[0]) {
+if (s->avctx->thread_count > 1) {
+av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged. Use -threads 1 to try decoding with best effort.\n");
+// unlock previous frames that have sent an _await() call
+ff_thread_report_progress(&s->canvas_frame, INT_MAX, 0);
+return AVERROR_PATCHWELCOME;
+} else {
+// warn for damaged frames
+av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged.\n");
+}
+}
+
+s->avctx->pix_fmt = format;
+canvas->format= format;
+canvas->width = s->canvas_width;
+canvas->height= s->canvas_height;
+
+// VP8 decoder changed the width and height in AVCodecContext.
+// Change it back to the canvas size.
+ret = ff_set_dimensions(s->avctx, s->canvas_width, s->canvas_height);
+if (ret < 0)
+return ret;
+
+ff_thread_release_ext_buffer(&s->canvas_frame);
+ret = ff_thread_get_ext_buffer(s->avctx, &s->canvas_frame,
AV_GET_BUFFER_FLAG_REF);
+if (ret < 0)
+return ret;
+
+if (canvas->format == AV_PIX_FMT_ARGB) {
+height = canvas->height;
+memset(canvas->data[0], 0, height * canvas->linesize[0]);
+} else /* if (canvas->format == AV_PIX_FMT_YUVA420P) */ {
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(canvas->format);
+for (int comp = 0; comp < desc->nb_components; comp++) {
+int plane = desc->comp[comp].plane;
+
+if (comp == 1 || comp == 2)
+height = AV_CEIL_RSHIFT(canvas->height, desc->log2_chroma_h);
+else
+height = FFALIGN(canvas->height, 1 << desc->log2_chroma_h);
+
+memset(canvas->data[plane], s->transparent_yuva[plane],
+ height * canvas->linesize[plane]);
+}
+}
+
+return 0;
+}
static int webp_decode_frame_common(AVCodecContext *avctx, uint8_t *data, int
size,
int *got_frame, int key_frame)
@@ -1599,77 +1668,6 @@ exif_end:
return size;
}
-int init_canvas_frame(WebPContext *s, int format, int key_frame)
-{
-AVFrame *canvas = s->canvas_frame.f;
-int height;
-int ret;
-
-// canvas is needed only for animation
-if (!(s->vp8x_flags & VP8X_FLAG_ANIMATION))
-return 0;
-
-// avoid init for non-key frames whose format and size did not change
-if (!key_frame &&
-canvas->data[0] &&
-canvas->format == format &&
-canvas->width == s->canvas_width &&
-canvas->height == s->canvas_height)
-return 0;
-
-// canvas changes within IPPP sequences will loose thread sync
-// because of the ThreadFrame reallocation and will wait forever
-// so if frame-threading is used, forbid canvas changes and unlock
-// previous frames
-if (!key_frame && canvas->data[0]) {
-if (s->avctx->thread_count > 1) {
-av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged. Use -threads 1 to try decoding with best effort.\n");
-// unlock previous frames that have sent an _await() call
-ff_thread_report_progress(&s->canvas_frame, INT_MAX, 0);
-return AVERROR_PATCHWELCOME;
-} else {
-// warn for damaged frames
-av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged.\n");
-}
-}
-
-s->avctx->pix_fmt = format;
-canvas->format= format;
-canvas->width = s->canvas_width;
-canvas->height= s->canvas_height;
-
-// VP8 decoder changed the width and height in AVCodecContext.
-// Change it back
[FFmpeg-devel] [PATCH v5 7/7] fate: add test for animated WebP
--- tests/fate/image.mak | 3 +++ tests/ref/fate/webp-anim | 22 ++ 2 files changed, 25 insertions(+) create mode 100644 tests/ref/fate/webp-anim diff --git a/tests/fate/image.mak b/tests/fate/image.mak index 400199c28a..2e0d1e8e3f 100644 --- a/tests/fate/image.mak +++ b/tests/fate/image.mak @@ -567,6 +567,9 @@ fate-webp-rgb-lossy-q80: CMD = framecrc -i $(TARGET_SAMPLES)/webp/rgb_q80.webp FATE_WEBP += fate-webp-rgba-lossy-q80 fate-webp-rgba-lossy-q80: CMD = framecrc -i $(TARGET_SAMPLES)/webp/rgba_q80.webp +FATE_WEBP += fate-webp-anim +fate-webp-anim: CMD = framecrc -i $(TARGET_SAMPLES)/webp/130227-100431-6817p.webp + FATE_WEBP-$(call DEMDEC, IMAGE2, WEBP) += $(FATE_WEBP) FATE_IMAGE_FRAMECRC += $(FATE_WEBP-yes) fate-webp: $(FATE_WEBP-yes) diff --git a/tests/ref/fate/webp-anim b/tests/ref/fate/webp-anim new file mode 100644 index 00..1baef9f7fb --- /dev/null +++ b/tests/ref/fate/webp-anim @@ -0,0 +1,22 @@ +#tb 0: 2/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 100x70 +#sar 0: 0/1 +0, 0, 0,1,28000, 0x2023ba6e +0, 1, 1,1,28000, 0x4292b778 +0, 2, 2,1,28000, 0x9772a187 +0, 3, 3,1,28000, 0xa98d8d04 +0, 4, 4,1,28000, 0xd323b6af +0, 5, 5,1,28000, 0x508aba99 +0, 6, 6,1,28000, 0x5c672dda +0, 7, 7,1,28000, 0xcc992d59 +0, 8, 8, 12,28000, 0x82460e1b +0, 21, 21,1,28000, 0x3debbfc9 +0, 22, 22,1,28000, 0x427ab31f +0, 23, 23,1,28000, 0x6bbdec2e +0, 24, 24,1,28000, 0x5690b56b +0, 25, 25,1,28000, 0xb62963f3 +0, 26, 26,1,28000, 0x68dd37b2 +0, 27, 27,1,28000, 0x465c47d2 +0, 28, 28, 125,28000, 0x465c47d2 -- 2.39.2 (Apple Git-143) ___ 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] [PATCH v5 4/7] libavcodec/webp: add support for animated WebP decoding
From: Josef Zlomek
Fixes: 4907
Adds support for decoding of animated WebP.
The WebP decoder adds the animation related features according to the specs:
https://developers.google.com/speed/webp/docs/riff_container#animation
The frames of the animation may be smaller than the image canvas.
Therefore, the frame is decoded to a temporary frame,
then it is blended into the canvas, the canvas is copied to the output frame,
and finally the frame is disposed from the canvas.
The output to AV_PIX_FMT_YUVA420P/AV_PIX_FMT_YUV420P is still supported.
The background color is specified only as BGRA in the WebP file
so it is converted to YUVA if YUV formats are output.
Signed-off-by: Josef Zlomek
---
Changelog | 1 +
libavcodec/codec_desc.c | 3 +-
libavcodec/version.h| 2 +-
libavcodec/webp.c | 763
4 files changed, 700 insertions(+), 69 deletions(-)
diff --git a/Changelog b/Changelog
index 7d79be1c3e..8f34660767 100644
--- a/Changelog
+++ b/Changelog
@@ -43,6 +43,7 @@ version 6.1:
- ffprobe XML output schema changed to account for multiple
variable-fields elements within the same parent element
- ffprobe -output_format option added as an alias of -of
+- animated WebP parser/decoder
version 6.0:
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 432a9c9ea6..2ab975f8d7 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1259,8 +1259,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
.type = AVMEDIA_TYPE_VIDEO,
.name = "webp",
.long_name = NULL_IF_CONFIG_SMALL("WebP"),
-.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY |
- AV_CODEC_PROP_LOSSLESS,
+.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_LOSSLESS,
.mime_types= MT("image/webp"),
},
{
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 0ef6c991f3..0a91c6b916 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -30,7 +30,7 @@
#include "version_major.h"
#define LIBAVCODEC_VERSION_MINOR 34
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 286e7c8b73..52ecdb45c5 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -35,12 +35,16 @@
* Exif metadata
* ICC profile
*
+ * @author Josef Zlomek, Pexeso Inc.
+ * Animation
+ *
* Unimplemented:
- * - Animation
* - XMP metadata
*/
+#include "libavcodec/packet.h"
#include "libavutil/imgutils.h"
+#include "libavutil/colorspace.h"
#define BITSTREAM_READER_LE
#include "avcodec.h"
@@ -192,9 +196,12 @@ typedef struct ImageContext {
typedef struct WebPContext {
VP8Context v; /* VP8 Context used for lossy decoding
*/
GetBitContext gb; /* bitstream reader for main image
chunk */
+ThreadFrame canvas_frame; /* ThreadFrame for canvas */
+AVFrame *frame; /* AVFrame for decoded frame */
AVFrame *alpha_frame; /* AVFrame for alpha data decompressed
from VP8L */
AVPacket *pkt; /* AVPacket to be passed to the
underlying VP8 decoder */
AVCodecContext *avctx; /* parent AVCodecContext */
+AVCodecContext *avctx_vp8; /* wrapper context for VP8 decoder */
int initialized;/* set once the VP8 context is
initialized */
int has_alpha; /* has a separate alpha chunk */
enum AlphaCompression alpha_compression; /* compression type for alpha
chunk */
@@ -203,9 +210,24 @@ typedef struct WebPContext {
int alpha_data_size;/* alpha chunk data size */
int has_exif; /* set after an EXIF chunk has been
processed */
int has_iccp; /* set after an ICCP chunk has been
processed */
-int width; /* image width */
-int height; /* image height */
-int lossless; /* indicates lossless or lossy */
+int vp8x_flags; /* global flags from VP8X chunk */
+int canvas_width; /* canvas width */
+int canvas_height; /* canvas height */
+int anmf_flags; /* frame flags from ANMF chunk */
+int width; /* frame width */
+int height; /* frame height */
+int pos_x; /* frame position X */
+int pos_y; /* frame position Y */
+int prev_anmf_flags;/* previous frame flags from ANMF
chunk */
+int prev_width; /* previous frame width */
+int prev_height;
Re: [FFmpeg-devel] [PATCH v5 4/7] libavcodec/webp: add support for animated WebP decoding
Am 22.11.23 um 03:54 schrieb Cosmin Stejerean via ffmpeg-devel:
On Nov 20, 2023, at 5:14 PM, James Almer wrote:
On 11/20/2023 4:22 PM, Thilo Borgmann via ffmpeg-devel wrote:
+ if (*got_frame) {
+ if (!(s->vp8x_flags & VP8X_FLAG_ANIMATION)) {
+ // no animation, output the decoded frame
+ av_frame_move_ref(p, s->frame);
+ ret = ff_attach_decode_data(p);
+ if (ret < 0)
+ return ret;
If this frame's buffers were allocated with ff_get_buffer() (or its threaded
version), then a call to ff_attach_decode_data() is not necessary.
The frame returned by avcodec_receive_frame doesn’t have private_ref set on it,
and eventually this null private_ref would get propagated to the other frame
objects (even if allocated with ff_get_buffer) by av_frame_copy_props, and
later on this would fail the assert that frames returned by codecs with
AV_CODEC_CAP_DR1 have private_ref set on them.
However this patch is dealing with it in the wrong place, moving
ff_attach_decode_data to right after avcodec_receive_frame would both make this
more clear and fix the assert issues (currently there’s an unnecessary call to
ff_attach_decode_data on an already allocated frame in a code path that doesn’t
go through vp8_lossy_decode_frame).
I verified that with that change on top of the current patch set it would run
the webp fate tests cleanly. I’m not sure if this is the best way to properly
reference a frame that came from avcodec_receive_frame inside of another codec.
But it does seem to work and a cursory search didn’t reveal a better API for
this.
Moving ff_attach_decode_data() right after avcodec_receive_frame() solved FATE
& the asserts even for --assert-level=2.
Will post a v6 according to this soon, unless there's more feedback on the
buffer creation.
Thanks,
Thilo
___
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] [PATCH v6 2/7] avcodec/webp: remove unused definitions
--- libavcodec/webp.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/libavcodec/webp.c b/libavcodec/webp.c index 4994781a64..286e7c8b73 100644 --- a/libavcodec/webp.c +++ b/libavcodec/webp.c @@ -60,8 +60,6 @@ #define VP8X_FLAG_ALPHA 0x10 #define VP8X_FLAG_ICC 0x20 -#define MAX_PALETTE_SIZE256 -#define MAX_CACHE_BITS 11 #define NUM_CODE_LENGTH_CODES 19 #define HUFFMAN_CODES_PER_META_CODE 5 #define NUM_LITERAL_CODES 256 -- 2.37.1 (Apple Git-137.1) ___ 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] [PATCH v6 3/7] avcodec/webp_parser: parse each frame into one packet
---
libavcodec/webp_parser.c | 130 +++
1 file changed, 89 insertions(+), 41 deletions(-)
diff --git a/libavcodec/webp_parser.c b/libavcodec/webp_parser.c
index bd5f94dac5..da853bb1f5 100644
--- a/libavcodec/webp_parser.c
+++ b/libavcodec/webp_parser.c
@@ -25,13 +25,17 @@
#include "libavutil/bswap.h"
#include "libavutil/common.h"
+#include "libavutil/intreadwrite.h"
#include "parser.h"
typedef struct WebPParseContext {
ParseContext pc;
+int frame;
+int first_frame;
uint32_t fsize;
-uint32_t remaining_size;
+uint32_t remaining_file_size;
+uint32_t remaining_tag_size;
} WebPParseContext;
static int webp_parse(AVCodecParserContext *s, AVCodecContext *avctx,
@@ -41,62 +45,106 @@ static int webp_parse(AVCodecParserContext *s,
AVCodecContext *avctx,
WebPParseContext *ctx = s->priv_data;
uint64_t state = ctx->pc.state64;
int next = END_NOT_FOUND;
-int i = 0;
+int i, len;
-*poutbuf = NULL;
-*poutbuf_size = 0;
-
-restart:
-if (ctx->pc.frame_start_found <= 8) {
-for (; i < buf_size; i++) {
+for (i = 0; i < buf_size;) {
+if (ctx->remaining_tag_size) {
+/* consuming tag */
+len = FFMIN(ctx->remaining_tag_size, buf_size - i);
+i += len;
+ctx->remaining_tag_size -= len;
+ctx->remaining_file_size -= len;
+} else {
+/* scan for the next tag or file */
state = (state << 8) | buf[i];
-if (ctx->pc.frame_start_found == 0) {
-if ((state >> 32) == MKBETAG('R', 'I', 'F', 'F')) {
-ctx->fsize = av_bswap32(state);
-if (ctx->fsize > 15 && ctx->fsize <= UINT32_MAX - 10) {
-ctx->pc.frame_start_found = 1;
-ctx->fsize += 8;
+i++;
+
+if (!ctx->remaining_file_size) {
+/* scan for the next file */
+if (ctx->pc.frame_start_found == 4) {
+ctx->pc.frame_start_found = 0;
+if ((uint32_t) state == MKBETAG('W', 'E', 'B', 'P')) {
+if (ctx->frame || i != 12) {
+ctx->frame = 0;
+next = i - 12;
+state = 0;
+ctx->pc.frame_start_found = 0;
+break;
+}
+ctx->remaining_file_size = ctx->fsize - 4;
+ctx->first_frame = 1;
+continue;
}
}
-} else if (ctx->pc.frame_start_found == 8) {
-if ((state >> 32) != MKBETAG('W', 'E', 'B', 'P')) {
+if (ctx->pc.frame_start_found == 0) {
+if ((state >> 32) == MKBETAG('R', 'I', 'F', 'F')) {
+ctx->fsize = av_bswap32(state);
+if (ctx->fsize > 15 && ctx->fsize <= UINT32_MAX - 10) {
+ctx->fsize += (ctx->fsize & 1);
+ctx->pc.frame_start_found = 1;
+}
+}
+} else
+ctx->pc.frame_start_found++;
+} else {
+/* read the next tag */
+ctx->remaining_file_size--;
+if (ctx->remaining_file_size == 0) {
ctx->pc.frame_start_found = 0;
continue;
}
ctx->pc.frame_start_found++;
-ctx->remaining_size = ctx->fsize + i - 15;
-if (ctx->pc.index + i > 15) {
-next = i - 15;
-state = 0;
+if (ctx->pc.frame_start_found < 8)
+continue;
+
+switch (state >> 32) {
+case MKBETAG('A', 'N', 'M', 'F'):
+case MKBETAG('V', 'P', '8', ' '):
+case MKBETAG('V', 'P', '8', 'L'):
+if (ctx->frame) {
+ctx->frame = 0;
+next = i - 8;
+state = 0;
+ctx->pc.frame_start_found = 0;
+goto flush;
+}
+ctx->frame = 1;
+break;
+default:
break;
-} else {
-ctx->pc.state64 = 0;
-goto restart;
}
-} else if (ctx->pc.frame_start_found)
-ctx->pc.frame_start_found++;
-}
-ctx->pc.state64 = state;
-} else {
-if (ctx->remaining_size) {
-i = FFMIN(ctx->remaining_size, buf_size);
-ctx->remaining_size -= i;
-if (ctx->remaining_size)
-goto flush;
-ctx->pc.frame_start_found = 0;
-goto res
[FFmpeg-devel] [PATCH v6 1/7] avcodec/webp: move definitions into header
--- libavcodec/webp.c | 1 + libavcodec/webp.h | 38 ++ 2 files changed, 39 insertions(+) create mode 100644 libavcodec/webp.h diff --git a/libavcodec/webp.c b/libavcodec/webp.c index 54b3fde6dc..4994781a64 100644 --- a/libavcodec/webp.c +++ b/libavcodec/webp.c @@ -52,6 +52,7 @@ #include "thread.h" #include "tiff_common.h" #include "vp8.h" +#include "webp.h" #define VP8X_FLAG_ANIMATION 0x02 #define VP8X_FLAG_XMP_METADATA 0x04 diff --git a/libavcodec/webp.h b/libavcodec/webp.h new file mode 100644 index 00..53bf59e7cd --- /dev/null +++ b/libavcodec/webp.h @@ -0,0 +1,38 @@ +/* + * WebP image format definitions + * Copyright (c) 2020 Pexeso Inc. + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/** + * @file + * WebP image format definitions. + */ + +#ifndef AVCODEC_WEBP_H +#define AVCODEC_WEBP_H + +#define ANMF_DISPOSAL_METHOD0x01 +#define ANMF_DISPOSAL_METHOD_UNCHANGED 0x00 +#define ANMF_DISPOSAL_METHOD_BACKGROUND 0x01 + +#define ANMF_BLENDING_METHOD0x02 +#define ANMF_BLENDING_METHOD_ALPHA 0x00 +#define ANMF_BLENDING_METHOD_OVERWRITE 0x02 + +#endif /* AVCODEC_WEBP_H */ -- 2.37.1 (Apple Git-137.1) ___ 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] [PATCH v6 0/7] webp: add support for animated WebP decoding
Still images fixed, includes FATE tests, VP8 decoder decoupled so there are no more data races, fixed more asserts. Patch 5/7 is still there for making changes in lavc/webp reviewable but shall be stashed when pushing. -Thilo Josef Zlomek (2): libavcodec/webp: add support for animated WebP decoding libavformat/webp: add WebP demuxer Thilo Borgmann (5): avcodec/webp: move definitions into header avcodec/webp: remove unused definitions avcodec/webp_parser: parse each frame into one packet avcodec/webp: make init_canvas_frame static fate: add test for animated WebP Changelog | 2 + doc/demuxers.texi | 28 + libavcodec/codec_desc.c | 3 +- libavcodec/version.h| 2 +- libavcodec/webp.c | 758 ++-- libavcodec/webp.h | 38 + libavcodec/webp_parser.c| 130 ++-- libavformat/Makefile| 1 + libavformat/allformats.c| 1 + libavformat/version.h | 2 +- libavformat/webpdec.c | 733 +++ tests/fate/image.mak| 3 + tests/ref/fate/exif-image-webp | 12 +- tests/ref/fate/webp-anim| 22 + tests/ref/fate/webp-rgb-lena-lossless | 2 +- tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +- tests/ref/fate/webp-rgb-lossless| 2 +- tests/ref/fate/webp-rgb-lossy-q80 | 2 +- tests/ref/fate/webp-rgba-lossless | 2 +- tests/ref/fate/webp-rgba-lossy-q80 | 2 +- 20 files changed, 1625 insertions(+), 122 deletions(-) create mode 100644 libavcodec/webp.h create mode 100644 libavformat/webpdec.c create mode 100644 tests/ref/fate/webp-anim -- 2.37.1 (Apple Git-137.1) ___ 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] [PATCH v6 6/7] libavformat/webp: add WebP demuxer
From: Josef Zlomek
Adds the demuxer of animated WebP files.
It supports non-animated, animated, truncated, and concatenated files.
Reading from a pipe (and other non-seekable inputs) is also supported.
The WebP demuxer splits the input stream into packets containing one frame.
It also marks the key frames properly.
The loop count is ignored by default (same behaviour as animated PNG and GIF),
it may be enabled by the option '-ignore_loop 0'.
The frame rate is set according to the frame delay in the ANMF chunk.
If the delay is too low, or the image is not animated, the default frame rate
is set to 10 fps, similarly to other WebP libraries and browsers.
The fate suite was updated accordingly.
Signed-off-by: Josef Zlomek
---
Changelog | 1 +
doc/demuxers.texi | 28 +
libavformat/Makefile| 1 +
libavformat/allformats.c| 1 +
libavformat/version.h | 2 +-
libavformat/webpdec.c | 733
tests/ref/fate/exif-image-webp | 12 +-
tests/ref/fate/webp-rgb-lena-lossless | 2 +-
tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +-
tests/ref/fate/webp-rgb-lossless| 2 +-
tests/ref/fate/webp-rgb-lossy-q80 | 2 +-
tests/ref/fate/webp-rgba-lossless | 2 +-
tests/ref/fate/webp-rgba-lossy-q80 | 2 +-
13 files changed, 777 insertions(+), 13 deletions(-)
create mode 100644 libavformat/webpdec.c
diff --git a/Changelog b/Changelog
index 8f34660767..fce4cda7ba 100644
--- a/Changelog
+++ b/Changelog
@@ -44,6 +44,7 @@ version 6.1:
variable-fields elements within the same parent element
- ffprobe -output_format option added as an alias of -of
- animated WebP parser/decoder
+- animated WebP demuxer
version 6.0:
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index e4c5b560a6..fcb9f9ee3c 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -943,4 +943,32 @@ which in turn, acts as a ceiling for the size of scripts
that can be read.
Default is 1 MiB.
@end table
+@section webp
+
+Animated WebP demuxer.
+
+It accepts the following options:
+
+@table @option
+@item -min_delay @var{int}
+Set the minimum valid delay between frames in milliseconds.
+Range is 0 to 6. Default value is 10.
+
+@item -max_webp_delay @var{int}
+Set the maximum valid delay between frames in milliseconds.
+Range is 0 to 16777215. Default value is 16777215 (over four hours),
+the maximum value allowed by the specification.
+
+@item -default_delay @var{int}
+Set the default delay between frames in milliseconds.
+Range is 0 to 6. Default value is 100.
+
+@item -ignore_loop @var{bool}
+WebP files can contain information to loop a certain number of times
+(or infinitely). If @option{ignore_loop} is set to true, then the loop
+setting from the input will be ignored and looping will not occur.
+If set to false, then looping will occur and will cycle the number
+of times according to the WebP. Default value is true.
+@end table
+
@c man end DEMUXERS
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 329055ccfd..4f0379f13b 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -618,6 +618,7 @@ OBJS-$(CONFIG_WEBM_MUXER)+= matroskaenc.o
matroska.o \
av1.o avlanguage.o
OBJS-$(CONFIG_WEBM_DASH_MANIFEST_MUXER) += webmdashenc.o
OBJS-$(CONFIG_WEBM_CHUNK_MUXER) += webm_chunk.o
+OBJS-$(CONFIG_WEBP_DEMUXER) += webpdec.o
OBJS-$(CONFIG_WEBP_MUXER)+= webpenc.o
OBJS-$(CONFIG_WEBVTT_DEMUXER)+= webvttdec.o subtitles.o
OBJS-$(CONFIG_WEBVTT_MUXER) += webvttenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index d4b505a5a3..d80c2f73a5 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -502,6 +502,7 @@ extern const AVInputFormat ff_webm_dash_manifest_demuxer;
extern const FFOutputFormat ff_webm_dash_manifest_muxer;
extern const FFOutputFormat ff_webm_chunk_muxer;
extern const FFOutputFormat ff_webp_muxer;
+extern const AVInputFormat ff_webp_demuxer;
extern const AVInputFormat ff_webvtt_demuxer;
extern const FFOutputFormat ff_webvtt_muxer;
extern const AVInputFormat ff_wsaud_demuxer;
diff --git a/libavformat/version.h b/libavformat/version.h
index 2a28a3bf40..3d85862bc1 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
#include "version_major.h"
#define LIBAVFORMAT_VERSION_MINOR 17
-#define LIBAVFORMAT_VERSION_MICRO 100
+#define LIBAVFORMAT_VERSION_MICRO 101
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
diff --git a/libavformat/webpdec.c b/libavformat/webpdec.c
new file mode 100644
index 00..b4024809f7
--- /dev/null
+++ b/libavformat/webpdec.c
@@ -0,0 +1,733 @@
+
[FFmpeg-devel] [PATCH v6 4/7] libavcodec/webp: add support for animated WebP decoding
From: Josef Zlomek
Fixes: 4907
Adds support for decoding of animated WebP.
The WebP decoder adds the animation related features according to the specs:
https://developers.google.com/speed/webp/docs/riff_container#animation
The frames of the animation may be smaller than the image canvas.
Therefore, the frame is decoded to a temporary frame,
then it is blended into the canvas, the canvas is copied to the output frame,
and finally the frame is disposed from the canvas.
The output to AV_PIX_FMT_YUVA420P/AV_PIX_FMT_YUV420P is still supported.
The background color is specified only as BGRA in the WebP file
so it is converted to YUVA if YUV formats are output.
Signed-off-by: Josef Zlomek
---
Changelog | 1 +
libavcodec/codec_desc.c | 3 +-
libavcodec/version.h| 2 +-
libavcodec/webp.c | 763
4 files changed, 700 insertions(+), 69 deletions(-)
diff --git a/Changelog b/Changelog
index 7d79be1c3e..8f34660767 100644
--- a/Changelog
+++ b/Changelog
@@ -43,6 +43,7 @@ version 6.1:
- ffprobe XML output schema changed to account for multiple
variable-fields elements within the same parent element
- ffprobe -output_format option added as an alias of -of
+- animated WebP parser/decoder
version 6.0:
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 432a9c9ea6..2ab975f8d7 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1259,8 +1259,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
.type = AVMEDIA_TYPE_VIDEO,
.name = "webp",
.long_name = NULL_IF_CONFIG_SMALL("WebP"),
-.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY |
- AV_CODEC_PROP_LOSSLESS,
+.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_LOSSLESS,
.mime_types= MT("image/webp"),
},
{
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 0ef6c991f3..0a91c6b916 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -30,7 +30,7 @@
#include "version_major.h"
#define LIBAVCODEC_VERSION_MINOR 34
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 286e7c8b73..5e77902128 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -35,12 +35,16 @@
* Exif metadata
* ICC profile
*
+ * @author Josef Zlomek, Pexeso Inc.
+ * Animation
+ *
* Unimplemented:
- * - Animation
* - XMP metadata
*/
+#include "libavcodec/packet.h"
#include "libavutil/imgutils.h"
+#include "libavutil/colorspace.h"
#define BITSTREAM_READER_LE
#include "avcodec.h"
@@ -192,9 +196,12 @@ typedef struct ImageContext {
typedef struct WebPContext {
VP8Context v; /* VP8 Context used for lossy decoding
*/
GetBitContext gb; /* bitstream reader for main image
chunk */
+ThreadFrame canvas_frame; /* ThreadFrame for canvas */
+AVFrame *frame; /* AVFrame for decoded frame */
AVFrame *alpha_frame; /* AVFrame for alpha data decompressed
from VP8L */
AVPacket *pkt; /* AVPacket to be passed to the
underlying VP8 decoder */
AVCodecContext *avctx; /* parent AVCodecContext */
+AVCodecContext *avctx_vp8; /* wrapper context for VP8 decoder */
int initialized;/* set once the VP8 context is
initialized */
int has_alpha; /* has a separate alpha chunk */
enum AlphaCompression alpha_compression; /* compression type for alpha
chunk */
@@ -203,9 +210,24 @@ typedef struct WebPContext {
int alpha_data_size;/* alpha chunk data size */
int has_exif; /* set after an EXIF chunk has been
processed */
int has_iccp; /* set after an ICCP chunk has been
processed */
-int width; /* image width */
-int height; /* image height */
-int lossless; /* indicates lossless or lossy */
+int vp8x_flags; /* global flags from VP8X chunk */
+int canvas_width; /* canvas width */
+int canvas_height; /* canvas height */
+int anmf_flags; /* frame flags from ANMF chunk */
+int width; /* frame width */
+int height; /* frame height */
+int pos_x; /* frame position X */
+int pos_y; /* frame position Y */
+int prev_anmf_flags;/* previous frame flags from ANMF
chunk */
+int prev_width; /* previous frame width */
+int prev_height;
[FFmpeg-devel] [PATCH v6 7/7] fate: add test for animated WebP
--- tests/fate/image.mak | 3 +++ tests/ref/fate/webp-anim | 22 ++ 2 files changed, 25 insertions(+) create mode 100644 tests/ref/fate/webp-anim diff --git a/tests/fate/image.mak b/tests/fate/image.mak index 400199c28a..2e0d1e8e3f 100644 --- a/tests/fate/image.mak +++ b/tests/fate/image.mak @@ -567,6 +567,9 @@ fate-webp-rgb-lossy-q80: CMD = framecrc -i $(TARGET_SAMPLES)/webp/rgb_q80.webp FATE_WEBP += fate-webp-rgba-lossy-q80 fate-webp-rgba-lossy-q80: CMD = framecrc -i $(TARGET_SAMPLES)/webp/rgba_q80.webp +FATE_WEBP += fate-webp-anim +fate-webp-anim: CMD = framecrc -i $(TARGET_SAMPLES)/webp/130227-100431-6817p.webp + FATE_WEBP-$(call DEMDEC, IMAGE2, WEBP) += $(FATE_WEBP) FATE_IMAGE_FRAMECRC += $(FATE_WEBP-yes) fate-webp: $(FATE_WEBP-yes) diff --git a/tests/ref/fate/webp-anim b/tests/ref/fate/webp-anim new file mode 100644 index 00..1baef9f7fb --- /dev/null +++ b/tests/ref/fate/webp-anim @@ -0,0 +1,22 @@ +#tb 0: 2/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 100x70 +#sar 0: 0/1 +0, 0, 0,1,28000, 0x2023ba6e +0, 1, 1,1,28000, 0x4292b778 +0, 2, 2,1,28000, 0x9772a187 +0, 3, 3,1,28000, 0xa98d8d04 +0, 4, 4,1,28000, 0xd323b6af +0, 5, 5,1,28000, 0x508aba99 +0, 6, 6,1,28000, 0x5c672dda +0, 7, 7,1,28000, 0xcc992d59 +0, 8, 8, 12,28000, 0x82460e1b +0, 21, 21,1,28000, 0x3debbfc9 +0, 22, 22,1,28000, 0x427ab31f +0, 23, 23,1,28000, 0x6bbdec2e +0, 24, 24,1,28000, 0x5690b56b +0, 25, 25,1,28000, 0xb62963f3 +0, 26, 26,1,28000, 0x68dd37b2 +0, 27, 27,1,28000, 0x465c47d2 +0, 28, 28, 125,28000, 0x465c47d2 -- 2.37.1 (Apple Git-137.1) ___ 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] [PATCH v6 5/7] avcodec/webp: make init_canvas_frame static
---
libavcodec/webp.c | 142 +++---
1 file changed, 70 insertions(+), 72 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 5e77902128..7e79bd3212 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -1367,7 +1367,76 @@ static int vp8_lossy_decode_frame(AVCodecContext *avctx,
AVFrame *p,
return ret;
}
-int init_canvas_frame(WebPContext *s, int format, int key_frame);
+static int init_canvas_frame(WebPContext *s, int format, int key_frame)
+{
+AVFrame *canvas = s->canvas_frame.f;
+int height;
+int ret;
+
+// canvas is needed only for animation
+if (!(s->vp8x_flags & VP8X_FLAG_ANIMATION))
+return 0;
+
+// avoid init for non-key frames whose format and size did not change
+if (!key_frame &&
+canvas->data[0] &&
+canvas->format == format &&
+canvas->width == s->canvas_width &&
+canvas->height == s->canvas_height)
+return 0;
+
+// canvas changes within IPPP sequences will lose thread sync
+// because of the ThreadFrame reallocation and will wait forever
+// so if frame-threading is used, forbid canvas changes and unlock
+// previous frames
+if (!key_frame && canvas->data[0]) {
+if (s->avctx->thread_count > 1) {
+av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged. Use -threads 1 to try decoding with best effort.\n");
+// unlock previous frames that have sent an _await() call
+ff_thread_report_progress(&s->canvas_frame, INT_MAX, 0);
+return AVERROR_PATCHWELCOME;
+} else {
+// warn for damaged frames
+av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged.\n");
+}
+}
+
+s->avctx->pix_fmt = format;
+canvas->format= format;
+canvas->width = s->canvas_width;
+canvas->height= s->canvas_height;
+
+// VP8 decoder changed the width and height in AVCodecContext.
+// Change it back to the canvas size.
+ret = ff_set_dimensions(s->avctx, s->canvas_width, s->canvas_height);
+if (ret < 0)
+return ret;
+
+ff_thread_release_ext_buffer(&s->canvas_frame);
+ret = ff_thread_get_ext_buffer(s->avctx, &s->canvas_frame,
AV_GET_BUFFER_FLAG_REF);
+if (ret < 0)
+return ret;
+
+if (canvas->format == AV_PIX_FMT_ARGB) {
+height = canvas->height;
+memset(canvas->data[0], 0, height * canvas->linesize[0]);
+} else /* if (canvas->format == AV_PIX_FMT_YUVA420P) */ {
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(canvas->format);
+for (int comp = 0; comp < desc->nb_components; comp++) {
+int plane = desc->comp[comp].plane;
+
+if (comp == 1 || comp == 2)
+height = AV_CEIL_RSHIFT(canvas->height, desc->log2_chroma_h);
+else
+height = FFALIGN(canvas->height, 1 << desc->log2_chroma_h);
+
+memset(canvas->data[plane], s->transparent_yuva[plane],
+ height * canvas->linesize[plane]);
+}
+}
+
+return 0;
+}
static int webp_decode_frame_common(AVCodecContext *avctx, uint8_t *data, int
size,
int *got_frame, int key_frame)
@@ -1606,77 +1675,6 @@ exif_end:
return size;
}
-int init_canvas_frame(WebPContext *s, int format, int key_frame)
-{
-AVFrame *canvas = s->canvas_frame.f;
-int height;
-int ret;
-
-// canvas is needed only for animation
-if (!(s->vp8x_flags & VP8X_FLAG_ANIMATION))
-return 0;
-
-// avoid init for non-key frames whose format and size did not change
-if (!key_frame &&
-canvas->data[0] &&
-canvas->format == format &&
-canvas->width == s->canvas_width &&
-canvas->height == s->canvas_height)
-return 0;
-
-// canvas changes within IPPP sequences will loose thread sync
-// because of the ThreadFrame reallocation and will wait forever
-// so if frame-threading is used, forbid canvas changes and unlock
-// previous frames
-if (!key_frame && canvas->data[0]) {
-if (s->avctx->thread_count > 1) {
-av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged. Use -threads 1 to try decoding with best effort.\n");
-// unlock previous frames that have sent an _await() call
-ff_thread_report_progress(&s->canvas_frame, INT_MAX, 0);
-return AVERROR_PATCHWELCOME;
-} else {
-// warn for damaged frames
-av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged.\n");
-}
-}
-
-s->avctx->pix_fmt = format;
-canvas->format= format;
-canvas->width = s->canvas_width;
-canvas->height= s->canvas_height;
-
-// VP8 decoder changed the width and height in AVCodecContext.
-// Change it back
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/jpegxl_parser: fix parsing sequences of extremely small files
> Am 26.11.2023 um 14:47 schrieb Leo Izen : > On 11/26/23 05:56, Anton Khirnov wrote: >> Would be nice to have tests for these. > > I have a sample at: https://buzo.us/l.jxl > > It would test both of these patches. I can send a fate test for these to the > ML if the sample gets uploaded. I CC'd samples-requ...@ffmpeg.org as well. Can do this in a bit. What about the file you‘d sent to samples-request in August, is there still a test to be pushed about it as well? -Thilo ___ 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] avcodec/jpegxl_parser: fix parsing sequences of extremely small files
On 27.11.23 00:33, Leo Izen wrote: On 11/26/23 13:07, Thilo Borgmann wrote: Am 26.11.2023 um 14:47 schrieb Leo Izen : On 11/26/23 05:56, Anton Khirnov wrote: Would be nice to have tests for these. I have a sample at: https://buzo.us/l.jxl It would test both of these patches. I can send a fate test for these to the ML if the sample gets uploaded. I CC'd samples-requ...@ffmpeg.org as well. Can do this in a bit. What about the file you‘d sent to samples-request in August, is there still a test to be pushed about it as well? -Thilo There is not, that sample from August was already uploaded and the fate test utilizing it has been merged. Ok, then its done: e19bb66167c096e86f8cf567a7df3528 fate-suite/jxl/l.jxl -Thilo ___ 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] [ANNOUNCE] upcoming vote: TC/CC elections
On 28.11.23 21:30, Derek Buitenhuis wrote: On 11/28/2023 3:50 PM, Anton Khirnov wrote: Calling things generically bad is the opposite of helpful. I cannot offer help on making a paragraph that I don't fully understand become more comprehensible, as that would require I understand it fully. But, I would again like to state these votes should be scrapped and redone. People literally voted the opposite of what they wanted to by accident, due to this. FWIW the type in of weights is one of the two options to do a proportional representation for the vote. The other is the one we had used so far, by ranking the candidates from 1st to n-th. Both should serve our needs for proportional representation AFAICT and I don't assume they'd give us different results of the vote. But maybe Anton had a reason to pick one over the other. If Anton decides it's worth redoing it, we maybe just do the other option and be a bit more resilient to misinterpretation. -Thilo ___ 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] fate: Add tests for QOA decoder
Am 03.12.23 um 00:43 schrieb Paul B Mahol: Files needs to be first uploaded to rsync server of FATE, and wait 24h and after that it can be pushed. Uploaded. -Thilo ___ 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] avdevice/avfoundation: replace AVCaptureDevice with new api
Am 04.12.23 um 13:47 schrieb xufuji456 via ffmpeg-devel:
Building with iOS platform, the compiler has a warning: "'devicesWithMediaType:' is
deprecated: first deprecated in iOS 10.0 - Use AVCaptureDeviceDiscoverySession
instead"
Signed-off-by: xufuji456 <839789...@qq.com>
---
libavdevice/avfoundation.m | 81 +++---
1 file changed, 76 insertions(+), 5 deletions(-)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 36ad834753..668c726eb7 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -770,8 +770,38 @@ static int avf_read_header(AVFormatContext *s)
AVCaptureDevice *video_device = nil;
AVCaptureDevice *audio_device = nil;
// Find capture device
-NSArray *devices = [AVCaptureDevice devicesWithMediaType:AVMediaTypeVideo];
-NSArray *devices_muxed = [AVCaptureDevice
devicesWithMediaType:AVMediaTypeMuxed];
+NSArray *devices = nil;
+NSArray *devices_muxed = nil;
+
+if (TARGET_OS_IPHONE) {
+if (@available(iOS 10.0, *)) {
The preprocessor directives should be more reliable especially on older
machines.
See other parts of the code which are handled that way and adopt for your case.
+AVCaptureDeviceDiscoverySession *captureDeviceDiscoverySession =
+[AVCaptureDeviceDiscoverySession
+
discoverySessionWithDeviceTypes:@[AVCaptureDeviceTypeBuiltInWideAngleCamera]
+ mediaType:AVMediaTypeVideo
+
position:AVCaptureDevicePositionUnspecified];
+devices = [captureDeviceDiscoverySession devices];
+} else {
+devices = [AVCaptureDevice devicesWithMediaType:AVMediaTypeVideo];
+}
+} else {
+devices = [AVCaptureDevice devicesWithMediaType:AVMediaTypeVideo];
+}
Here and in other chunks you can join the if() conditions into one and avoid
the duplication of the old code.
-Thilo
___
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] avdevice/avfoundation: replace AVCaptureDevice with new api
Hi,
Am 05.12.23 um 14:33 schrieb xufuji456 via ffmpeg-devel:
Building with iOS platform, the compiler has a warning: "'devicesWithMediaType:' is
deprecated: first deprecated in iOS 10.0 - Use AVCaptureDeviceDiscoverySession
instead"
Signed-off-by: xufuji456 <839789...@qq.com>
---
libavdevice/avfoundation.m | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 36ad834753..1bc99d543a 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -761,6 +761,21 @@ static int get_audio_config(AVFormatContext *s)
return 0;
}
+static NSArray* getDevicesWithMediaType(AVMediaType mediaType) {
+#if ((TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MAX_ALLOWED >= 10) || (TARGET_OS_OSX
&& __MAC_OS_X_VERSION_MAX_ALLOWED >= 101500))
+if (@available(macOS 10.15, iOS 10.0, *)) {
The preprocessor guard is meant to void the @available condition.
Also something appears not yet to achieve what you want, as on MacOS 13.4 I
still get the deprication warning:
libavdevice/avfoundation.m:776:29: warning: 'devicesWithMediaType:' is
deprecated: first deprecated in macOS 10.15 - Use
AVCaptureDeviceDiscoverySession instead. [-Wdeprecated-declarations]
return [AVCaptureDevice devicesWithMediaType:mediaType];
+AVCaptureDeviceDiscoverySession *captureDeviceDiscoverySession =
+[AVCaptureDeviceDiscoverySession
+
discoverySessionWithDeviceTypes:@[AVCaptureDeviceTypeBuiltInWideAngleCamera]
+ mediaType:mediaType
+
position:AVCaptureDevicePositionUnspecified];
+return [captureDeviceDiscoverySession devices];
+}
+#endif
why not #else... #endif ?
+// fallback
+return [AVCaptureDevice devicesWithMediaType:mediaType];
+}
+
Thanks,
Thilo
___
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] avdevice/avfoundation: replace AVCaptureDevice with new api
Am 05.12.23 um 15:16 schrieb Thilo Borgmann via ffmpeg-devel:
Hi,
Am 05.12.23 um 14:33 schrieb xufuji456 via ffmpeg-devel:
Building with iOS platform, the compiler has a warning: "'devicesWithMediaType:' is
deprecated: first deprecated in iOS 10.0 - Use AVCaptureDeviceDiscoverySession
instead"
Signed-off-by: xufuji456 <839789...@qq.com>
---
libavdevice/avfoundation.m | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 36ad834753..1bc99d543a 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -761,6 +761,21 @@ static int get_audio_config(AVFormatContext *s)
return 0;
}
+static NSArray* getDevicesWithMediaType(AVMediaType mediaType) {
+#if ((TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MAX_ALLOWED >= 10) || (TARGET_OS_OSX
&& __MAC_OS_X_VERSION_MAX_ALLOWED >= 101500))
+ if (@available(macOS 10.15, iOS 10.0, *)) {
The preprocessor guard is meant to void the @available condition.
Also something appears not yet to achieve what you want, as on MacOS 13.4 I
still get the deprication warning:
libavdevice/avfoundation.m:776:29: warning: 'devicesWithMediaType:' is
deprecated: first deprecated in macOS 10.15 - Use
AVCaptureDeviceDiscoverySession instead. [-Wdeprecated-declarations]
return [AVCaptureDevice devicesWithMediaType:mediaType];
+ AVCaptureDeviceDiscoverySession *captureDeviceDiscoverySession =
+ [AVCaptureDeviceDiscoverySession
+
discoverySessionWithDeviceTypes:@[AVCaptureDeviceTypeBuiltInWideAngleCamera]
+ mediaType:mediaType
+
position:AVCaptureDevicePositionUnspecified];
+ return [captureDeviceDiscoverySession devices];
+ }
+#endif
why not #else... #endif ?
#elif
... of course.
Also using it, would remove the deprication warning on capable systems.
Otherwise it is still in the code and warned about.
+ // fallback
+ return [AVCaptureDevice devicesWithMediaType:mediaType];
+}
+
Thanks,
Thilo
-Thilo
___
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] avdevice/avfoundation: replace AVCaptureDevice with new api
Am 05.12.23 um 15:19 schrieb Thilo Borgmann via ffmpeg-devel:
Am 05.12.23 um 15:16 schrieb Thilo Borgmann via ffmpeg-devel:
Hi,
Am 05.12.23 um 14:33 schrieb xufuji456 via ffmpeg-devel:
Building with iOS platform, the compiler has a warning: "'devicesWithMediaType:' is
deprecated: first deprecated in iOS 10.0 - Use AVCaptureDeviceDiscoverySession
instead"
Signed-off-by: xufuji456 <839789...@qq.com>
---
libavdevice/avfoundation.m | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 36ad834753..1bc99d543a 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -761,6 +761,21 @@ static int get_audio_config(AVFormatContext *s)
return 0;
}
+static NSArray* getDevicesWithMediaType(AVMediaType mediaType) {
+#if ((TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MAX_ALLOWED >= 10) || (TARGET_OS_OSX
&& __MAC_OS_X_VERSION_MAX_ALLOWED >= 101500))
+ if (@available(macOS 10.15, iOS 10.0, *)) {
The preprocessor guard is meant to void the @available condition.
Also something appears not yet to achieve what you want, as on MacOS 13.4 I
still get the deprication warning:
libavdevice/avfoundation.m:776:29: warning: 'devicesWithMediaType:' is
deprecated: first deprecated in macOS 10.15 - Use
AVCaptureDeviceDiscoverySession instead. [-Wdeprecated-declarations]
return [AVCaptureDevice devicesWithMediaType:mediaType];
+ AVCaptureDeviceDiscoverySession *captureDeviceDiscoverySession =
+ [AVCaptureDeviceDiscoverySession
+
discoverySessionWithDeviceTypes:@[AVCaptureDeviceTypeBuiltInWideAngleCamera]
+ mediaType:mediaType
+
position:AVCaptureDevicePositionUnspecified];
+ return [captureDeviceDiscoverySession devices];
+ }
+#endif
why not #else... #endif ?
#elif
... of course.
#else
... writing faster than thinking is no good...
Also using it, would remove the deprication warning on capable systems.
Otherwise it is still in the code and warned about.
+ // fallback
+ return [AVCaptureDevice devicesWithMediaType:mediaType];
+}
+
-Thilo
___
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] MAINTAINERS: add myself as vvc maintainer
Am 05.12.23 um 16:16 schrieb Nuo Mi: --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) LGTM -Thilo ___ 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] MAINTAINERS: add myself as vvc maintainer
Am 05.12.23 um 16:22 schrieb Thilo Borgmann via ffmpeg-devel: Am 05.12.23 um 16:16 schrieb Nuo Mi: --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) LGTM Pushed. Thanks, Thilo ___ 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] [PATCH v7 0/7] webp: add support for animated WebP decoding
Still images fixed, includes FATE tests, VP8 decoder decoupled so there are no more data races, fixed more asserts, fixed ffprobe regression. Patch 5/7 is still there for making changes in lavc/webp reviewable but shall be stashed when pushing. -Thilo Josef Zlomek (2): libavcodec/webp: add support for animated WebP decoding libavformat/webp: add WebP demuxer Thilo Borgmann (5): avcodec/webp: move definitions into header avcodec/webp: remove unused definitions avcodec/webp_parser: parse each frame into one packet avcodec/webp: make init_canvas_frame static fate: add test for animated WebP Changelog | 2 + doc/demuxers.texi | 28 + libavcodec/codec_desc.c | 3 +- libavcodec/version.h| 2 +- libavcodec/webp.c | 763 ++-- libavcodec/webp.h | 38 + libavcodec/webp_parser.c| 130 ++-- libavformat/Makefile| 1 + libavformat/allformats.c| 1 + libavformat/version.h | 2 +- libavformat/webpdec.c | 733 +++ tests/fate/image.mak| 3 + tests/ref/fate/exif-image-webp | 12 +- tests/ref/fate/webp-anim| 22 + tests/ref/fate/webp-rgb-lena-lossless | 2 +- tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +- tests/ref/fate/webp-rgb-lossless| 2 +- tests/ref/fate/webp-rgb-lossy-q80 | 2 +- tests/ref/fate/webp-rgba-lossless | 2 +- tests/ref/fate/webp-rgba-lossy-q80 | 2 +- 20 files changed, 1630 insertions(+), 122 deletions(-) create mode 100644 libavcodec/webp.h create mode 100644 libavformat/webpdec.c create mode 100644 tests/ref/fate/webp-anim -- 2.37.1 (Apple Git-137.1) ___ 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] [PATCH v7 1/7] avcodec/webp: move definitions into header
--- libavcodec/webp.c | 1 + libavcodec/webp.h | 38 ++ 2 files changed, 39 insertions(+) create mode 100644 libavcodec/webp.h diff --git a/libavcodec/webp.c b/libavcodec/webp.c index 54b3fde6dc..4994781a64 100644 --- a/libavcodec/webp.c +++ b/libavcodec/webp.c @@ -52,6 +52,7 @@ #include "thread.h" #include "tiff_common.h" #include "vp8.h" +#include "webp.h" #define VP8X_FLAG_ANIMATION 0x02 #define VP8X_FLAG_XMP_METADATA 0x04 diff --git a/libavcodec/webp.h b/libavcodec/webp.h new file mode 100644 index 00..53bf59e7cd --- /dev/null +++ b/libavcodec/webp.h @@ -0,0 +1,38 @@ +/* + * WebP image format definitions + * Copyright (c) 2020 Pexeso Inc. + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/** + * @file + * WebP image format definitions. + */ + +#ifndef AVCODEC_WEBP_H +#define AVCODEC_WEBP_H + +#define ANMF_DISPOSAL_METHOD0x01 +#define ANMF_DISPOSAL_METHOD_UNCHANGED 0x00 +#define ANMF_DISPOSAL_METHOD_BACKGROUND 0x01 + +#define ANMF_BLENDING_METHOD0x02 +#define ANMF_BLENDING_METHOD_ALPHA 0x00 +#define ANMF_BLENDING_METHOD_OVERWRITE 0x02 + +#endif /* AVCODEC_WEBP_H */ -- 2.37.1 (Apple Git-137.1) ___ 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] [PATCH v7 2/7] avcodec/webp: remove unused definitions
--- libavcodec/webp.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/libavcodec/webp.c b/libavcodec/webp.c index 4994781a64..286e7c8b73 100644 --- a/libavcodec/webp.c +++ b/libavcodec/webp.c @@ -60,8 +60,6 @@ #define VP8X_FLAG_ALPHA 0x10 #define VP8X_FLAG_ICC 0x20 -#define MAX_PALETTE_SIZE256 -#define MAX_CACHE_BITS 11 #define NUM_CODE_LENGTH_CODES 19 #define HUFFMAN_CODES_PER_META_CODE 5 #define NUM_LITERAL_CODES 256 -- 2.37.1 (Apple Git-137.1) ___ 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] [PATCH v7 4/7] libavcodec/webp: add support for animated WebP decoding
From: Josef Zlomek
Fixes: 4907
Adds support for decoding of animated WebP.
The WebP decoder adds the animation related features according to the specs:
https://developers.google.com/speed/webp/docs/riff_container#animation
The frames of the animation may be smaller than the image canvas.
Therefore, the frame is decoded to a temporary frame,
then it is blended into the canvas, the canvas is copied to the output frame,
and finally the frame is disposed from the canvas.
The output to AV_PIX_FMT_YUVA420P/AV_PIX_FMT_YUV420P is still supported.
The background color is specified only as BGRA in the WebP file
so it is converted to YUVA if YUV formats are output.
Signed-off-by: Josef Zlomek
---
Changelog | 1 +
libavcodec/codec_desc.c | 3 +-
libavcodec/version.h| 2 +-
libavcodec/webp.c | 768
4 files changed, 705 insertions(+), 69 deletions(-)
diff --git a/Changelog b/Changelog
index f00bc27ca4..a2cc0714b7 100644
--- a/Changelog
+++ b/Changelog
@@ -45,6 +45,7 @@ version 6.1:
- ffprobe XML output schema changed to account for multiple
variable-fields elements within the same parent element
- ffprobe -output_format option added as an alias of -of
+- animated WebP parser/decoder
version 6.0:
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 033344304c..0f72769093 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1259,8 +1259,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
.type = AVMEDIA_TYPE_VIDEO,
.name = "webp",
.long_name = NULL_IF_CONFIG_SMALL("WebP"),
-.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY |
- AV_CODEC_PROP_LOSSLESS,
+.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_LOSSLESS,
.mime_types= MT("image/webp"),
},
{
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 1008fead27..36e14e6886 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -30,7 +30,7 @@
#include "version_major.h"
#define LIBAVCODEC_VERSION_MINOR 35
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 286e7c8b73..2b9a38fdf9 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -35,12 +35,16 @@
* Exif metadata
* ICC profile
*
+ * @author Josef Zlomek, Pexeso Inc.
+ * Animation
+ *
* Unimplemented:
- * - Animation
* - XMP metadata
*/
+#include "libavcodec/packet.h"
#include "libavutil/imgutils.h"
+#include "libavutil/colorspace.h"
#define BITSTREAM_READER_LE
#include "avcodec.h"
@@ -192,9 +196,12 @@ typedef struct ImageContext {
typedef struct WebPContext {
VP8Context v; /* VP8 Context used for lossy decoding
*/
GetBitContext gb; /* bitstream reader for main image
chunk */
+ThreadFrame canvas_frame; /* ThreadFrame for canvas */
+AVFrame *frame; /* AVFrame for decoded frame */
AVFrame *alpha_frame; /* AVFrame for alpha data decompressed
from VP8L */
AVPacket *pkt; /* AVPacket to be passed to the
underlying VP8 decoder */
AVCodecContext *avctx; /* parent AVCodecContext */
+AVCodecContext *avctx_vp8; /* wrapper context for VP8 decoder */
int initialized;/* set once the VP8 context is
initialized */
int has_alpha; /* has a separate alpha chunk */
enum AlphaCompression alpha_compression; /* compression type for alpha
chunk */
@@ -203,9 +210,24 @@ typedef struct WebPContext {
int alpha_data_size;/* alpha chunk data size */
int has_exif; /* set after an EXIF chunk has been
processed */
int has_iccp; /* set after an ICCP chunk has been
processed */
-int width; /* image width */
-int height; /* image height */
-int lossless; /* indicates lossless or lossy */
+int vp8x_flags; /* global flags from VP8X chunk */
+int canvas_width; /* canvas width */
+int canvas_height; /* canvas height */
+int anmf_flags; /* frame flags from ANMF chunk */
+int width; /* frame width */
+int height; /* frame height */
+int pos_x; /* frame position X */
+int pos_y; /* frame position Y */
+int prev_anmf_flags;/* previous frame flags from ANMF
chunk */
+int prev_width; /* previous frame width */
+int prev_height;
[FFmpeg-devel] [PATCH v7 3/7] avcodec/webp_parser: parse each frame into one packet
---
libavcodec/webp_parser.c | 130 +++
1 file changed, 89 insertions(+), 41 deletions(-)
diff --git a/libavcodec/webp_parser.c b/libavcodec/webp_parser.c
index bd5f94dac5..da853bb1f5 100644
--- a/libavcodec/webp_parser.c
+++ b/libavcodec/webp_parser.c
@@ -25,13 +25,17 @@
#include "libavutil/bswap.h"
#include "libavutil/common.h"
+#include "libavutil/intreadwrite.h"
#include "parser.h"
typedef struct WebPParseContext {
ParseContext pc;
+int frame;
+int first_frame;
uint32_t fsize;
-uint32_t remaining_size;
+uint32_t remaining_file_size;
+uint32_t remaining_tag_size;
} WebPParseContext;
static int webp_parse(AVCodecParserContext *s, AVCodecContext *avctx,
@@ -41,62 +45,106 @@ static int webp_parse(AVCodecParserContext *s,
AVCodecContext *avctx,
WebPParseContext *ctx = s->priv_data;
uint64_t state = ctx->pc.state64;
int next = END_NOT_FOUND;
-int i = 0;
+int i, len;
-*poutbuf = NULL;
-*poutbuf_size = 0;
-
-restart:
-if (ctx->pc.frame_start_found <= 8) {
-for (; i < buf_size; i++) {
+for (i = 0; i < buf_size;) {
+if (ctx->remaining_tag_size) {
+/* consuming tag */
+len = FFMIN(ctx->remaining_tag_size, buf_size - i);
+i += len;
+ctx->remaining_tag_size -= len;
+ctx->remaining_file_size -= len;
+} else {
+/* scan for the next tag or file */
state = (state << 8) | buf[i];
-if (ctx->pc.frame_start_found == 0) {
-if ((state >> 32) == MKBETAG('R', 'I', 'F', 'F')) {
-ctx->fsize = av_bswap32(state);
-if (ctx->fsize > 15 && ctx->fsize <= UINT32_MAX - 10) {
-ctx->pc.frame_start_found = 1;
-ctx->fsize += 8;
+i++;
+
+if (!ctx->remaining_file_size) {
+/* scan for the next file */
+if (ctx->pc.frame_start_found == 4) {
+ctx->pc.frame_start_found = 0;
+if ((uint32_t) state == MKBETAG('W', 'E', 'B', 'P')) {
+if (ctx->frame || i != 12) {
+ctx->frame = 0;
+next = i - 12;
+state = 0;
+ctx->pc.frame_start_found = 0;
+break;
+}
+ctx->remaining_file_size = ctx->fsize - 4;
+ctx->first_frame = 1;
+continue;
}
}
-} else if (ctx->pc.frame_start_found == 8) {
-if ((state >> 32) != MKBETAG('W', 'E', 'B', 'P')) {
+if (ctx->pc.frame_start_found == 0) {
+if ((state >> 32) == MKBETAG('R', 'I', 'F', 'F')) {
+ctx->fsize = av_bswap32(state);
+if (ctx->fsize > 15 && ctx->fsize <= UINT32_MAX - 10) {
+ctx->fsize += (ctx->fsize & 1);
+ctx->pc.frame_start_found = 1;
+}
+}
+} else
+ctx->pc.frame_start_found++;
+} else {
+/* read the next tag */
+ctx->remaining_file_size--;
+if (ctx->remaining_file_size == 0) {
ctx->pc.frame_start_found = 0;
continue;
}
ctx->pc.frame_start_found++;
-ctx->remaining_size = ctx->fsize + i - 15;
-if (ctx->pc.index + i > 15) {
-next = i - 15;
-state = 0;
+if (ctx->pc.frame_start_found < 8)
+continue;
+
+switch (state >> 32) {
+case MKBETAG('A', 'N', 'M', 'F'):
+case MKBETAG('V', 'P', '8', ' '):
+case MKBETAG('V', 'P', '8', 'L'):
+if (ctx->frame) {
+ctx->frame = 0;
+next = i - 8;
+state = 0;
+ctx->pc.frame_start_found = 0;
+goto flush;
+}
+ctx->frame = 1;
+break;
+default:
break;
-} else {
-ctx->pc.state64 = 0;
-goto restart;
}
-} else if (ctx->pc.frame_start_found)
-ctx->pc.frame_start_found++;
-}
-ctx->pc.state64 = state;
-} else {
-if (ctx->remaining_size) {
-i = FFMIN(ctx->remaining_size, buf_size);
-ctx->remaining_size -= i;
-if (ctx->remaining_size)
-goto flush;
-ctx->pc.frame_start_found = 0;
-goto res
[FFmpeg-devel] [PATCH v7 5/7] avcodec/webp: make init_canvas_frame static
---
libavcodec/webp.c | 142 +++---
1 file changed, 70 insertions(+), 72 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 2b9a38fdf9..af81e2a84b 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -1372,7 +1372,76 @@ static int vp8_lossy_decode_frame(AVCodecContext *avctx,
AVFrame *p,
return ret;
}
-int init_canvas_frame(WebPContext *s, int format, int key_frame);
+static int init_canvas_frame(WebPContext *s, int format, int key_frame)
+{
+AVFrame *canvas = s->canvas_frame.f;
+int height;
+int ret;
+
+// canvas is needed only for animation
+if (!(s->vp8x_flags & VP8X_FLAG_ANIMATION))
+return 0;
+
+// avoid init for non-key frames whose format and size did not change
+if (!key_frame &&
+canvas->data[0] &&
+canvas->format == format &&
+canvas->width == s->canvas_width &&
+canvas->height == s->canvas_height)
+return 0;
+
+// canvas changes within IPPP sequences will lose thread sync
+// because of the ThreadFrame reallocation and will wait forever
+// so if frame-threading is used, forbid canvas changes and unlock
+// previous frames
+if (!key_frame && canvas->data[0]) {
+if (s->avctx->thread_count > 1) {
+av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged. Use -threads 1 to try decoding with best effort.\n");
+// unlock previous frames that have sent an _await() call
+ff_thread_report_progress(&s->canvas_frame, INT_MAX, 0);
+return AVERROR_PATCHWELCOME;
+} else {
+// warn for damaged frames
+av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged.\n");
+}
+}
+
+s->avctx->pix_fmt = format;
+canvas->format= format;
+canvas->width = s->canvas_width;
+canvas->height= s->canvas_height;
+
+// VP8 decoder changed the width and height in AVCodecContext.
+// Change it back to the canvas size.
+ret = ff_set_dimensions(s->avctx, s->canvas_width, s->canvas_height);
+if (ret < 0)
+return ret;
+
+ff_thread_release_ext_buffer(&s->canvas_frame);
+ret = ff_thread_get_ext_buffer(s->avctx, &s->canvas_frame,
AV_GET_BUFFER_FLAG_REF);
+if (ret < 0)
+return ret;
+
+if (canvas->format == AV_PIX_FMT_ARGB) {
+height = canvas->height;
+memset(canvas->data[0], 0, height * canvas->linesize[0]);
+} else /* if (canvas->format == AV_PIX_FMT_YUVA420P) */ {
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(canvas->format);
+for (int comp = 0; comp < desc->nb_components; comp++) {
+int plane = desc->comp[comp].plane;
+
+if (comp == 1 || comp == 2)
+height = AV_CEIL_RSHIFT(canvas->height, desc->log2_chroma_h);
+else
+height = FFALIGN(canvas->height, 1 << desc->log2_chroma_h);
+
+memset(canvas->data[plane], s->transparent_yuva[plane],
+ height * canvas->linesize[plane]);
+}
+}
+
+return 0;
+}
static int webp_decode_frame_common(AVCodecContext *avctx, uint8_t *data, int
size,
int *got_frame, int key_frame)
@@ -1611,77 +1680,6 @@ exif_end:
return size;
}
-int init_canvas_frame(WebPContext *s, int format, int key_frame)
-{
-AVFrame *canvas = s->canvas_frame.f;
-int height;
-int ret;
-
-// canvas is needed only for animation
-if (!(s->vp8x_flags & VP8X_FLAG_ANIMATION))
-return 0;
-
-// avoid init for non-key frames whose format and size did not change
-if (!key_frame &&
-canvas->data[0] &&
-canvas->format == format &&
-canvas->width == s->canvas_width &&
-canvas->height == s->canvas_height)
-return 0;
-
-// canvas changes within IPPP sequences will loose thread sync
-// because of the ThreadFrame reallocation and will wait forever
-// so if frame-threading is used, forbid canvas changes and unlock
-// previous frames
-if (!key_frame && canvas->data[0]) {
-if (s->avctx->thread_count > 1) {
-av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged. Use -threads 1 to try decoding with best effort.\n");
-// unlock previous frames that have sent an _await() call
-ff_thread_report_progress(&s->canvas_frame, INT_MAX, 0);
-return AVERROR_PATCHWELCOME;
-} else {
-// warn for damaged frames
-av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged.\n");
-}
-}
-
-s->avctx->pix_fmt = format;
-canvas->format= format;
-canvas->width = s->canvas_width;
-canvas->height= s->canvas_height;
-
-// VP8 decoder changed the width and height in AVCodecContext.
-// Change it back
[FFmpeg-devel] [PATCH v7 6/7] libavformat/webp: add WebP demuxer
From: Josef Zlomek
Adds the demuxer of animated WebP files.
It supports non-animated, animated, truncated, and concatenated files.
Reading from a pipe (and other non-seekable inputs) is also supported.
The WebP demuxer splits the input stream into packets containing one frame.
It also marks the key frames properly.
The loop count is ignored by default (same behaviour as animated PNG and GIF),
it may be enabled by the option '-ignore_loop 0'.
The frame rate is set according to the frame delay in the ANMF chunk.
If the delay is too low, or the image is not animated, the default frame rate
is set to 10 fps, similarly to other WebP libraries and browsers.
The fate suite was updated accordingly.
Signed-off-by: Josef Zlomek
---
Changelog | 1 +
doc/demuxers.texi | 28 +
libavformat/Makefile| 1 +
libavformat/allformats.c| 1 +
libavformat/version.h | 2 +-
libavformat/webpdec.c | 733
tests/ref/fate/exif-image-webp | 12 +-
tests/ref/fate/webp-rgb-lena-lossless | 2 +-
tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +-
tests/ref/fate/webp-rgb-lossless| 2 +-
tests/ref/fate/webp-rgb-lossy-q80 | 2 +-
tests/ref/fate/webp-rgba-lossless | 2 +-
tests/ref/fate/webp-rgba-lossy-q80 | 2 +-
13 files changed, 777 insertions(+), 13 deletions(-)
create mode 100644 libavformat/webpdec.c
diff --git a/Changelog b/Changelog
index a2cc0714b7..b9f9dceac1 100644
--- a/Changelog
+++ b/Changelog
@@ -46,6 +46,7 @@ version 6.1:
variable-fields elements within the same parent element
- ffprobe -output_format option added as an alias of -of
- animated WebP parser/decoder
+- animated WebP demuxer
version 6.0:
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index e4c5b560a6..fcb9f9ee3c 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -943,4 +943,32 @@ which in turn, acts as a ceiling for the size of scripts
that can be read.
Default is 1 MiB.
@end table
+@section webp
+
+Animated WebP demuxer.
+
+It accepts the following options:
+
+@table @option
+@item -min_delay @var{int}
+Set the minimum valid delay between frames in milliseconds.
+Range is 0 to 6. Default value is 10.
+
+@item -max_webp_delay @var{int}
+Set the maximum valid delay between frames in milliseconds.
+Range is 0 to 16777215. Default value is 16777215 (over four hours),
+the maximum value allowed by the specification.
+
+@item -default_delay @var{int}
+Set the default delay between frames in milliseconds.
+Range is 0 to 6. Default value is 100.
+
+@item -ignore_loop @var{bool}
+WebP files can contain information to loop a certain number of times
+(or infinitely). If @option{ignore_loop} is set to true, then the loop
+setting from the input will be ignored and looping will not occur.
+If set to false, then looping will occur and will cycle the number
+of times according to the WebP. Default value is true.
+@end table
+
@c man end DEMUXERS
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 2db83aff81..e8e4307fb5 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -619,6 +619,7 @@ OBJS-$(CONFIG_WEBM_MUXER)+= matroskaenc.o
matroska.o \
av1.o avlanguage.o
OBJS-$(CONFIG_WEBM_DASH_MANIFEST_MUXER) += webmdashenc.o
OBJS-$(CONFIG_WEBM_CHUNK_MUXER) += webm_chunk.o
+OBJS-$(CONFIG_WEBP_DEMUXER) += webpdec.o
OBJS-$(CONFIG_WEBP_MUXER)+= webpenc.o
OBJS-$(CONFIG_WEBVTT_DEMUXER)+= webvttdec.o subtitles.o
OBJS-$(CONFIG_WEBVTT_MUXER) += webvttenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index c8bb4e3866..51ad546361 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -503,6 +503,7 @@ extern const AVInputFormat ff_webm_dash_manifest_demuxer;
extern const FFOutputFormat ff_webm_dash_manifest_muxer;
extern const FFOutputFormat ff_webm_chunk_muxer;
extern const FFOutputFormat ff_webp_muxer;
+extern const AVInputFormat ff_webp_demuxer;
extern const AVInputFormat ff_webvtt_demuxer;
extern const FFOutputFormat ff_webvtt_muxer;
extern const AVInputFormat ff_wsaud_demuxer;
diff --git a/libavformat/version.h b/libavformat/version.h
index 6a80f3ac4e..be8ce01160 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
#include "version_major.h"
#define LIBAVFORMAT_VERSION_MINOR 18
-#define LIBAVFORMAT_VERSION_MICRO 100
+#define LIBAVFORMAT_VERSION_MICRO 101
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
diff --git a/libavformat/webpdec.c b/libavformat/webpdec.c
new file mode 100644
index 00..b4024809f7
--- /dev/null
+++ b/libavformat/webpdec.c
@@ -0,0 +1,733 @@
+
[FFmpeg-devel] [PATCH v7 7/7] fate: add test for animated WebP
--- tests/fate/image.mak | 3 +++ tests/ref/fate/webp-anim | 22 ++ 2 files changed, 25 insertions(+) create mode 100644 tests/ref/fate/webp-anim diff --git a/tests/fate/image.mak b/tests/fate/image.mak index 400199c28a..2e0d1e8e3f 100644 --- a/tests/fate/image.mak +++ b/tests/fate/image.mak @@ -567,6 +567,9 @@ fate-webp-rgb-lossy-q80: CMD = framecrc -i $(TARGET_SAMPLES)/webp/rgb_q80.webp FATE_WEBP += fate-webp-rgba-lossy-q80 fate-webp-rgba-lossy-q80: CMD = framecrc -i $(TARGET_SAMPLES)/webp/rgba_q80.webp +FATE_WEBP += fate-webp-anim +fate-webp-anim: CMD = framecrc -i $(TARGET_SAMPLES)/webp/130227-100431-6817p.webp + FATE_WEBP-$(call DEMDEC, IMAGE2, WEBP) += $(FATE_WEBP) FATE_IMAGE_FRAMECRC += $(FATE_WEBP-yes) fate-webp: $(FATE_WEBP-yes) diff --git a/tests/ref/fate/webp-anim b/tests/ref/fate/webp-anim new file mode 100644 index 00..1baef9f7fb --- /dev/null +++ b/tests/ref/fate/webp-anim @@ -0,0 +1,22 @@ +#tb 0: 2/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 100x70 +#sar 0: 0/1 +0, 0, 0,1,28000, 0x2023ba6e +0, 1, 1,1,28000, 0x4292b778 +0, 2, 2,1,28000, 0x9772a187 +0, 3, 3,1,28000, 0xa98d8d04 +0, 4, 4,1,28000, 0xd323b6af +0, 5, 5,1,28000, 0x508aba99 +0, 6, 6,1,28000, 0x5c672dda +0, 7, 7,1,28000, 0xcc992d59 +0, 8, 8, 12,28000, 0x82460e1b +0, 21, 21,1,28000, 0x3debbfc9 +0, 22, 22,1,28000, 0x427ab31f +0, 23, 23,1,28000, 0x6bbdec2e +0, 24, 24,1,28000, 0x5690b56b +0, 25, 25,1,28000, 0xb62963f3 +0, 26, 26,1,28000, 0x68dd37b2 +0, 27, 27,1,28000, 0x465c47d2 +0, 28, 28, 125,28000, 0x465c47d2 -- 2.37.1 (Apple Git-137.1) ___ 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] avdevice/avfoundation: replace deprecated AVCaptureDevice
Am 06.12.23 um 13:03 schrieb xufuji456 via ffmpeg-devel:
Building with iOS platform, the compiler has a warning: "'devicesWithMediaType:' is
deprecated: first deprecated in iOS 10.0 - Use AVCaptureDeviceDiscoverySession
instead"
Signed-off-by: xufuji456 <839789...@qq.com>
---
libavdevice/avfoundation.m | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 36ad834753..5ebfe89dca 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -761,6 +761,19 @@ static int get_audio_config(AVFormatContext *s)
return 0;
}
+static NSArray* getDevicesWithMediaType(AVMediaType mediaType) {
+#if ((TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MAX_ALLOWED >= 10) || (TARGET_OS_OSX
&& __MAC_OS_X_VERSION_MAX_ALLOWED >= 101500))
+AVCaptureDeviceDiscoverySession *captureDeviceDiscoverySession =
+[AVCaptureDeviceDiscoverySession
+
discoverySessionWithDeviceTypes:@[AVCaptureDeviceTypeBuiltInWideAngleCamera]
deviceTypes should be an array of all possible types or we risk loosing
currently detected hardware.
Otherwise, LGTM.
-Thilo
___
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 0/1] fate/jpegxl: add multiframe permuted TOC image parser
Am 09.12.23 um 20:49 schrieb Leo Izen: This patch requires a sample that hasn't been uploaded yet. It can be found at [1] and it should be placed at jxl/orange.jxl once uploaded. It's 262k, which is not very large, but large enough that I did not want to attach it to this email. [1]: https://buzo.us/O.jxl sample sha256sum: 9288337dc0d37effd1f539d4e20083a8ffed757e486f4098121520c74e8de6f6 sample signature: https://buzo.us/A.asc Uploaded. -Thilo ___ 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] avdevice/avfoundation: replace deprecated AVCaptureDevice
Am 09.12.23 um 13:09 schrieb xufuji456 via ffmpeg-devel: Building with iOS platform, the compiler has a warning: "'devicesWithMediaType:' is deprecated: first deprecated in iOS 10.0 - Use AVCaptureDeviceDiscoverySession instead" Signed-off-by: xufuji456 <839789...@qq.com> --- libavdevice/avfoundation.m | 65 +++--- 1 file changed, 60 insertions(+), 5 deletions(-) LGTM. Will apply shortly if there are no more comments. -Thilo ___ 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] avdevice/avfoundation: replace deprecated AVCaptureDevice
Am 11.12.23 um 10:32 schrieb Thilo Borgmann via ffmpeg-devel: Am 09.12.23 um 13:09 schrieb xufuji456 via ffmpeg-devel: Building with iOS platform, the compiler has a warning: "'devicesWithMediaType:' is deprecated: first deprecated in iOS 10.0 - Use AVCaptureDeviceDiscoverySession instead" Signed-off-by: xufuji456 <839789...@qq.com> --- libavdevice/avfoundation.m | 65 +++--- 1 file changed, 60 insertions(+), 5 deletions(-) LGTM. Will apply shortly if there are no more comments. Pushed. -Thilo ___ 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] [PATCH 0/5] avfilter: Add fsync filter
Synchronize video frames with an external mapping from a file. Follows up on the idea in https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-January/305986.html implemented as a filter. Not storing the frame map in a probably huge string but buffering piece-wise. Thilo Borgmann (5): fftools/ffmpeg: split loop for parsing and validation of -stats_* specifiers fftools/ffmpeg: move parsing of -stats_* specifiers to lavu/parseutils reindent after last commit avfilter: Add fsync filter fate: Add fsync filter tests Changelog| 1 + doc/filters.texi | 52 + fftools/ffmpeg.h | 33 +-- fftools/ffmpeg_enc.c | 3 +- fftools/ffmpeg_mux_init.c| 152 ++--- libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_fsync.c | 376 +++ libavformat/version.h| 2 +- libavutil/parseutils.c | 176 +++ libavutil/parseutils.h | 102 + libavutil/version.h | 2 +- tests/Makefile | 6 +- tests/fate/filter-video.mak | 8 + tests/filtergraphs/fsync-down| 2 + tests/filtergraphs/fsync-up | 2 + tests/maps/fsync-down| 7 + tests/maps/fsync-up | 57 + tests/ref/fate/filter-fsync-down | 12 + tests/ref/fate/filter-fsync-up | 62 + 20 files changed, 891 insertions(+), 166 deletions(-) create mode 100644 libavfilter/vf_fsync.c create mode 100644 tests/filtergraphs/fsync-down create mode 100644 tests/filtergraphs/fsync-up create mode 100644 tests/maps/fsync-down create mode 100644 tests/maps/fsync-up create mode 100644 tests/ref/fate/filter-fsync-down create mode 100644 tests/ref/fate/filter-fsync-up -- 2.37.1 (Apple Git-137.1) ___ 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".
