Re: [FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule
On Tue, Mar 05, 2024 at 11:27:22AM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-03-05 03:50:01) > > The STF opertunity had a deadline. > > Also we can already start discussing what shall be done when the next grant > > opertunity comes. > > How about some actual transparency Theres a wiki: https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024 that contains an application only 2 people filled out the application also Pierre collected the SoWs, only 2 people submitted any SoWs I do remember asking you to submit something and IIRC you said that you are waiting for the vote outcome. But you never submitted anything I also tried to contact everyone else, who at the time had something incomplete on the wiki and their name. This (and other people also not submitting any SoWs) caused us to fall below teh 150k€ minimum so i tried to fill the missing space with added work so we reach the minimum. at night on the 12th/morning 13th february i was CC-ed on the application submission to STF " a draft corresponding to the community-driven proposals found in [wiki]." Tara from STF then reworked this and asked us various additional information: (estimated effort (people hours) per milestone, and the fully loaded hourly rate (the price rate, so the cost divided by total number of hours).) "If you want to invoice after each sub milestone, then you need to break down the total cost per milestone into each sub milestone (and by extension also the estimated effort)." Others, I and niklas then helped fill the missing things in quickly before the deadline Someone along the line added more incomplete proposals to the wiki after the deadline But same as with others, no SoWs where submitted, and none of the details needed in the application where filled out. > instead of backroom deals, for a > change. iam sorry, but these accusations are not acceptable The application was and is on a public wiki the SoWs where collected by pierre and it was publically announced before. I tried to contact all people before the deadline who had incomplete submissions. I think for a change you should say thanks to tara, pierre, SPI, STF and others doing all the work. Instead of accusations. And you should submit a proposal with SoW and all needed information next time. Similarly others should too. The idea of this was never to have just 2 people submit SoWs > > The application has apparently been submitted, with no public > announcement that it even happened, much less what was in it. whats in it, should simlpy be what was on the wiki application plus the fixes and cleanups mentioned above thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2
Hi aybe On Sat, Jan 13, 2024 at 02:28:52AM +, aybe aybe wrote: > Here are the two STR files I have used when writing this patch: > https://github.com/aybe/FFmpeg-PSX-STR-tests ok, i can confirm the version patch fixes these, i will apply it > Fanatics would probably say that 30 FPS for NTSC is wrong (i.e. should be > 29.97)... > However, as the reversed-engineered docs in jpsxdec mentions, it is sort of > impossible to figure out which value to snap to from how frames spans across > CD-ROM sectors. > The sector count per video frame always seem to juggle between two values, > e.g. 6 sectors, then 7 sectors, rinse/repeat. i.e. it's never constant. > > Also, as one can see in the various code samples online on writing a PSX > program that plays MDEC videos, it is the responsibility of the coder to > present the frames on screen. > i.e. there is not definitive way on how to do so, and even if there was, you > can be sure some folks did not play by the rules back then. > The only way to figure out how a movie was intended to be played is to > reverse engineer a game to see what values they did cram in. > In short, the computed frame rate is 99% good, not 100%. But for mere > mortals, they are unlikely to notice it at all. Well, with the subset of samples i have, i dont feel confident that i could write and test timestamping/fps. The docuemnt you linked says "Data is read from the disc one sector at a time at either 75 sectors per second (single speed) or 150 sectors per second (double speed). The video and audio are spaced out over these sectors so they can be delivered at the appropriate times." what i would suggest to try is: avpriv_set_pts_info(st, 64, 1, 150); (or 75 for single speed) and then set AVPacket->pts to the sector number you never set fps, leave it to libavformat to figure it out. can you try that ? (i assume you have many samples to easily check) > > As for the movies in the samples repository, they are corrupt and FFmpeg > fails at them, obviously. > I figured these ones were by checking them in a hex-editor but also by > loading them in https://github.com/m35/jpsxdec which has great > logging. > Not sure why these samples were corrupt in first instance, maybe it was > intentional for testing? I can't tell. Thats very strange, anyone remembers where these samples are from originally ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/av1dec: Fix resolving zero divisor
Fixes: Out of array read Fixes: global-buffer-overflow-AV1 Found-by: "Leonelli, Matteo" Tested-by: "Wang, Fei W" Reviewed-by: "Wang, Fei W" Signed-off-by: Michael Niedermayer --- libavcodec/av1dec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c index 6114cb78e65..4dcde234c6c 100644 --- a/libavcodec/av1dec.c +++ b/libavcodec/av1dec.c @@ -177,7 +177,7 @@ static uint8_t get_shear_params_valid(AV1DecContext *s, int idx) int16_t alpha, beta, gamma, delta, divf, divs; int64_t v, w; int32_t *param = >cur_frame.gm_params[idx][0]; -if (param[2] < 0) +if (param[2] <= 0) return 0; alpha = av_clip_int16(param[2] - (1 << AV1_WARPEDMODEL_PREC_BITS)); -- 2.17.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".
