| Message ID | 20200903170323.23006-1-onemda@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [FFmpeg-devel] avcodec/dxtory: unbreak decoding after 6e1a167c556 | expand |
| Context | Check | Description |
|---|---|---|
| andriy/default | pending | |
| andriy/make | success | Make finished |
| andriy/make_fate | success | Make fate finished |
Paul B Mahol (12020-09-03): > get_unary() takes at minimum only 1 bit. > > Signed-off-by: Paul B Mahol <onemda@gmail.com> > --- > > As this is important fix, will apply in next 5 minutes. Five minutes, for an important fix of a commit that was there for eighteen months? Please. Like any other fix, wait for review.
On 9/3/2020 2:03 PM, Paul B Mahol wrote: > get_unary() takes at minimum only 1 bit. > > Signed-off-by: Paul B Mahol <onemda@gmail.com> > --- > > As this is important fix, will apply in next 5 minutes. > I kindly ask authors of various timeouts changes to kindly > test their changes more carefully. That change is two years and a half old by now. Maybe the decoder needs a fate test, seeing how it's barely used so we can't rely on users finding such regressions in a timely manner. > > --- > libavcodec/dxtory.c | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/libavcodec/dxtory.c b/libavcodec/dxtory.c > index bc19f27951..3cd95afe80 100644 > --- a/libavcodec/dxtory.c > +++ b/libavcodec/dxtory.c > @@ -395,7 +395,7 @@ static int dx2_decode_slice_5x5(GetBitContext *gb, AVFrame *frame, > int stride = frame->linesize[0]; > uint8_t *dst = frame->data[0] + stride * line; > > - for (y = 0; y < left && get_bits_left(gb) > 6 * width; y++) { > + for (y = 0; y < left && get_bits_left(gb) >= 3 * width; y++) { > for (x = 0; x < width; x++) { > b = decode_sym_565(gb, lru[0], 5); > g = decode_sym_565(gb, lru[1], is_565 ? 6 : 5); > @@ -462,7 +462,7 @@ static int dx2_decode_slice_rgb(GetBitContext *gb, AVFrame *frame, > int stride = frame->linesize[0]; > uint8_t *dst = frame->data[0] + stride * line; > > - for (y = 0; y < left && get_bits_left(gb) > 6 * width; y++) { > + for (y = 0; y < left && get_bits_left(gb) >= 3 * width; y++) { > for (x = 0; x < width; x++) { > dst[x * 3 + 0] = decode_sym(gb, lru[0]); > dst[x * 3 + 1] = decode_sym(gb, lru[1]); > @@ -508,7 +508,7 @@ static int dx2_decode_slice_410(GetBitContext *gb, AVFrame *frame, > uint8_t *U = frame->data[1] + (ustride >> 2) * line; > uint8_t *V = frame->data[2] + (vstride >> 2) * line; > > - for (y = 0; y < left - 3 && get_bits_left(gb) > 9 * width; y += 4) { > + for (y = 0; y < left - 3 && get_bits_left(gb) >= 4 * width; y += 4) { > for (x = 0; x < width; x += 4) { > for (j = 0; j < 4; j++) > for (i = 0; i < 4; i++) > @@ -553,7 +553,7 @@ static int dx2_decode_slice_420(GetBitContext *gb, AVFrame *frame, > uint8_t *V = frame->data[2] + (vstride >> 1) * line; > > > - for (y = 0; y < left - 1 && get_bits_left(gb) > 6 * width; y += 2) { > + for (y = 0; y < left - 1 && get_bits_left(gb) >= 3 * width; y += 2) { > for (x = 0; x < width; x += 2) { > Y[x + 0 + 0 * ystride] = decode_sym(gb, lru[0]); > Y[x + 1 + 0 * ystride] = decode_sym(gb, lru[0]); > @@ -597,7 +597,7 @@ static int dx2_decode_slice_444(GetBitContext *gb, AVFrame *frame, > uint8_t *U = frame->data[1] + ustride * line; > uint8_t *V = frame->data[2] + vstride * line; > > - for (y = 0; y < left && get_bits_left(gb) > 6 * width; y++) { > + for (y = 0; y < left && get_bits_left(gb) >= 3 * width; y++) { > for (x = 0; x < width; x++) { > Y[x] = decode_sym(gb, lru[0]); > U[x] = decode_sym(gb, lru[1]) ^ 0x80; >
On 9/3/20, Nicolas George <george@nsup.org> wrote: > Paul B Mahol (12020-09-03): >> get_unary() takes at minimum only 1 bit. >> >> Signed-off-by: Paul B Mahol <onemda@gmail.com> >> --- >> >> As this is important fix, will apply in next 5 minutes. > > Five minutes, for an important fix of a commit that was there for > eighteen months? Please. > > Like any other fix, wait for review. Ah, you still here ! I wondered will you get bait....
Paul B Mahol (12020-09-03):
> I wondered will you get bait....
Was this the only reason you threatened to commit without review?
On 9/3/20, Michael Niedermayer <michael@niedermayer.cc> wrote: > On Thu, Sep 03, 2020 at 07:03:23PM +0200, Paul B Mahol wrote: >> get_unary() takes at minimum only 1 bit. >> >> Signed-off-by: Paul B Mahol <onemda@gmail.com> >> --- >> >> As this is important fix, will apply in next 5 minutes. >> I kindly ask authors of various timeouts changes to kindly >> test their changes more carefully. > > Can you provide test samples and a fate test ? Why should I? Nobody uploads my request to wav CUE thing. Test samples can be generated by installing trial dxtory capture and recording mainly black frames from some simple game. On windows, or under virtualbox. I can upload files, but I value my time and will not do it for nothing in return. The ones who are actually paid to the actual work should make sure they do not break decoders. > > >> >> --- >> libavcodec/dxtory.c | 10 +++++----- >> 1 file changed, 5 insertions(+), 5 deletions(-) >> >> diff --git a/libavcodec/dxtory.c b/libavcodec/dxtory.c >> index bc19f27951..3cd95afe80 100644 >> --- a/libavcodec/dxtory.c >> +++ b/libavcodec/dxtory.c >> @@ -395,7 +395,7 @@ static int dx2_decode_slice_5x5(GetBitContext *gb, >> AVFrame *frame, >> int stride = frame->linesize[0]; >> uint8_t *dst = frame->data[0] + stride * line; >> >> - for (y = 0; y < left && get_bits_left(gb) > 6 * width; y++) { >> + for (y = 0; y < left && get_bits_left(gb) >= 3 * width; y++) { >> for (x = 0; x < width; x++) { >> b = decode_sym_565(gb, lru[0], 5); >> g = decode_sym_565(gb, lru[1], is_565 ? 6 : 5); >> @@ -462,7 +462,7 @@ static int dx2_decode_slice_rgb(GetBitContext *gb, >> AVFrame *frame, >> int stride = frame->linesize[0]; >> uint8_t *dst = frame->data[0] + stride * line; >> >> - for (y = 0; y < left && get_bits_left(gb) > 6 * width; y++) { >> + for (y = 0; y < left && get_bits_left(gb) >= 3 * width; y++) { >> for (x = 0; x < width; x++) { >> dst[x * 3 + 0] = decode_sym(gb, lru[0]); >> dst[x * 3 + 1] = decode_sym(gb, lru[1]); > >> @@ -508,7 +508,7 @@ static int dx2_decode_slice_410(GetBitContext *gb, >> AVFrame *frame, >> uint8_t *U = frame->data[1] + (ustride >> 2) * line; >> uint8_t *V = frame->data[2] + (vstride >> 2) * line; >> >> - for (y = 0; y < left - 3 && get_bits_left(gb) > 9 * width; y += 4) { >> + for (y = 0; y < left - 3 && get_bits_left(gb) >= 4 * width; y += 4) >> { >> for (x = 0; x < width; x += 4) { >> for (j = 0; j < 4; j++) >> for (i = 0; i < 4; i++) > > iam not sure this is correct > let us consider the equal case occurs get_bits_left(gb) == 4 * width; > now this is read as 4x4 blocks, each will read a minimum of 18 bits 16 luma > and 2 chroma. 18*(width/4) == 4 * width doesnt look right This is correct and it is for support odd dimensions (not supported at all from beginning) in next patch, the ones non-aligned to subsampled constraints.
On Fri, Sep 04, 2020 at 12:27:11AM +0200, Paul B Mahol wrote: > On 9/3/20, Michael Niedermayer <michael@niedermayer.cc> wrote: > > On Thu, Sep 03, 2020 at 07:03:23PM +0200, Paul B Mahol wrote: > >> get_unary() takes at minimum only 1 bit. > >> > >> Signed-off-by: Paul B Mahol <onemda@gmail.com> > >> --- > >> > >> As this is important fix, will apply in next 5 minutes. > >> I kindly ask authors of various timeouts changes to kindly > >> test their changes more carefully. > > > > Can you provide test samples and a fate test ? > > Why should I? Nobody uploads my request to wav CUE thing. You have access to upload yourself and post the request to the wrong address, it is FFmpeg sample uploads <samples-request@ffmpeg.org> > > Test samples can be generated by installing trial dxtory capture and recording > mainly black frames from some simple game. On windows, or under virtualbox. > > I can upload files, but I value my time and will not do it for nothing > in return. The time someone else needs to setup a windows machiene, trial dxtory capture, some game and so forth is several times that of just providing existing files. So by providing existing files you give others more time to work on other things like reviewing your patches, or uploading your files to fate, or working on anything else, which can then also benefit you ... Is that enough in return ? Thanks [...]
On 9/4/20, Michael Niedermayer <michael@niedermayer.cc> wrote: > On Fri, Sep 04, 2020 at 12:27:11AM +0200, Paul B Mahol wrote: >> On 9/3/20, Michael Niedermayer <michael@niedermayer.cc> wrote: >> > On Thu, Sep 03, 2020 at 07:03:23PM +0200, Paul B Mahol wrote: >> >> get_unary() takes at minimum only 1 bit. >> >> >> >> Signed-off-by: Paul B Mahol <onemda@gmail.com> >> >> --- >> >> >> >> As this is important fix, will apply in next 5 minutes. >> >> I kindly ask authors of various timeouts changes to kindly >> >> test their changes more carefully. >> > >> > Can you provide test samples and a fate test ? >> >> Why should I? Nobody uploads my request to wav CUE thing. > > You have access to upload yourself and > post the request to the wrong address, it is > FFmpeg sample uploads <samples-request@ffmpeg.org> > I never received anything of sort of access to something. > >> >> Test samples can be generated by installing trial dxtory capture and >> recording >> mainly black frames from some simple game. On windows, or under >> virtualbox. >> >> I can upload files, but I value my time and will not do it for nothing >> in return. > > The time someone else needs to setup a windows machiene, trial dxtory > capture, > some game and so forth is several times that of just providing existing > files. > > So by providing existing files you give others more time to work on > other things like reviewing your patches, or uploading your files to > fate, or working on anything else, which can then also benefit you ... > Is that enough in return ? No, I will leave this decoder broken. So be it. And I wish you happy breaking of every single other decoder, you have enormous potential. I'm completely unpaid in this what I do.
On 9/4/20, Michael Niedermayer <michael@niedermayer.cc> wrote: > On Fri, Sep 04, 2020 at 12:27:11AM +0200, Paul B Mahol wrote: >> On 9/3/20, Michael Niedermayer <michael@niedermayer.cc> wrote: >> > On Thu, Sep 03, 2020 at 07:03:23PM +0200, Paul B Mahol wrote: >> >> get_unary() takes at minimum only 1 bit. >> >> >> >> Signed-off-by: Paul B Mahol <onemda@gmail.com> >> >> --- >> >> >> >> As this is important fix, will apply in next 5 minutes. >> >> I kindly ask authors of various timeouts changes to kindly >> >> test their changes more carefully. >> > >> > Can you provide test samples and a fate test ? >> >> Why should I? Nobody uploads my request to wav CUE thing. > > You have access to upload yourself and > post the request to the wrong address, it is > FFmpeg sample uploads <samples-request@ffmpeg.org> > > >> >> Test samples can be generated by installing trial dxtory capture and >> recording >> mainly black frames from some simple game. On windows, or under >> virtualbox. >> >> I can upload files, but I value my time and will not do it for nothing >> in return. > > The time someone else needs to setup a windows machiene, trial dxtory > capture, > some game and so forth is several times that of just providing existing > files. > > So by providing existing files you give others more time to work on > other things like reviewing your patches, or uploading your files to > fate, or working on anything else, which can then also benefit you ... > Is that enough in return ? https://drive.google.com/drive/folders/1RV0NSfkAvNA8Ju59SBuzKg7pWosIVLQd?usp=sharing > > Thanks > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Republics decline into democracies and democracies degenerate into > despotisms. -- Aristotle >
On 9/4/2020 6:29 AM, Paul B Mahol wrote: > On 9/4/20, Michael Niedermayer <michael@niedermayer.cc> wrote: >> On Fri, Sep 04, 2020 at 12:27:11AM +0200, Paul B Mahol wrote: >>> On 9/3/20, Michael Niedermayer <michael@niedermayer.cc> wrote: >>>> On Thu, Sep 03, 2020 at 07:03:23PM +0200, Paul B Mahol wrote: >>>>> get_unary() takes at minimum only 1 bit. >>>>> >>>>> Signed-off-by: Paul B Mahol <onemda@gmail.com> >>>>> --- >>>>> >>>>> As this is important fix, will apply in next 5 minutes. >>>>> I kindly ask authors of various timeouts changes to kindly >>>>> test their changes more carefully. >>>> >>>> Can you provide test samples and a fate test ? >>> >>> Why should I? Nobody uploads my request to wav CUE thing. >> >> You have access to upload yourself and >> post the request to the wrong address, it is >> FFmpeg sample uploads <samples-request@ffmpeg.org> >> > > I never received anything of sort of access to something. Your ssh pub key is in the server, which means you can connect to it and upload samples using rsync. See https://ffmpeg.org/fate.html#Uploading-new-samples-to-the-fate-suite > >> >>> >>> Test samples can be generated by installing trial dxtory capture and >>> recording >>> mainly black frames from some simple game. On windows, or under >>> virtualbox. >>> >>> I can upload files, but I value my time and will not do it for nothing >>> in return. >> >> The time someone else needs to setup a windows machiene, trial dxtory >> capture, >> some game and so forth is several times that of just providing existing >> files. >> >> So by providing existing files you give others more time to work on >> other things like reviewing your patches, or uploading your files to >> fate, or working on anything else, which can then also benefit you ... >> Is that enough in return ? > > No, I will leave this decoder broken. So be it. > And I wish you happy breaking of every single other decoder, > you have enormous potential. > > I'm completely unpaid in this what I do. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >
On 9/4/20, James Almer <jamrial@gmail.com> wrote: > On 9/4/2020 6:29 AM, Paul B Mahol wrote: >> On 9/4/20, Michael Niedermayer <michael@niedermayer.cc> wrote: >>> On Fri, Sep 04, 2020 at 12:27:11AM +0200, Paul B Mahol wrote: >>>> On 9/3/20, Michael Niedermayer <michael@niedermayer.cc> wrote: >>>>> On Thu, Sep 03, 2020 at 07:03:23PM +0200, Paul B Mahol wrote: >>>>>> get_unary() takes at minimum only 1 bit. >>>>>> >>>>>> Signed-off-by: Paul B Mahol <onemda@gmail.com> >>>>>> --- >>>>>> >>>>>> As this is important fix, will apply in next 5 minutes. >>>>>> I kindly ask authors of various timeouts changes to kindly >>>>>> test their changes more carefully. >>>>> >>>>> Can you provide test samples and a fate test ? >>>> >>>> Why should I? Nobody uploads my request to wav CUE thing. >>> >>> You have access to upload yourself and >>> post the request to the wrong address, it is >>> FFmpeg sample uploads <samples-request@ffmpeg.org> >>> >> >> I never received anything of sort of access to something. > > Your ssh pub key is in the server, which means you can connect to it and > upload samples using rsync. > > See https://ffmpeg.org/fate.html#Uploading-new-samples-to-the-fate-suite So I connect via ssh program?
On 9/4/2020 11:44 AM, Paul B Mahol wrote: > On 9/4/20, James Almer <jamrial@gmail.com> wrote: >> On 9/4/2020 6:29 AM, Paul B Mahol wrote: >>> On 9/4/20, Michael Niedermayer <michael@niedermayer.cc> wrote: >>>> On Fri, Sep 04, 2020 at 12:27:11AM +0200, Paul B Mahol wrote: >>>>> On 9/3/20, Michael Niedermayer <michael@niedermayer.cc> wrote: >>>>>> On Thu, Sep 03, 2020 at 07:03:23PM +0200, Paul B Mahol wrote: >>>>>>> get_unary() takes at minimum only 1 bit. >>>>>>> >>>>>>> Signed-off-by: Paul B Mahol <onemda@gmail.com> >>>>>>> --- >>>>>>> >>>>>>> As this is important fix, will apply in next 5 minutes. >>>>>>> I kindly ask authors of various timeouts changes to kindly >>>>>>> test their changes more carefully. >>>>>> >>>>>> Can you provide test samples and a fate test ? >>>>> >>>>> Why should I? Nobody uploads my request to wav CUE thing. >>>> >>>> You have access to upload yourself and >>>> post the request to the wrong address, it is >>>> FFmpeg sample uploads <samples-request@ffmpeg.org> >>>> >>> >>> I never received anything of sort of access to something. >> >> Your ssh pub key is in the server, which means you can connect to it and >> upload samples using rsync. >> >> See https://ffmpeg.org/fate.html#Uploading-new-samples-to-the-fate-suite > > So I connect via ssh program? rsync will connect through ssh if you use the commands listed there. Just replace the path to wherever you have the samples suite locally. And please don't skip the dry-run, to ensure you don't make unwanted changes to the remote repository.
On 9/4/20, James Almer <jamrial@gmail.com> wrote: > On 9/4/2020 11:44 AM, Paul B Mahol wrote: >> On 9/4/20, James Almer <jamrial@gmail.com> wrote: >>> On 9/4/2020 6:29 AM, Paul B Mahol wrote: >>>> On 9/4/20, Michael Niedermayer <michael@niedermayer.cc> wrote: >>>>> On Fri, Sep 04, 2020 at 12:27:11AM +0200, Paul B Mahol wrote: >>>>>> On 9/3/20, Michael Niedermayer <michael@niedermayer.cc> wrote: >>>>>>> On Thu, Sep 03, 2020 at 07:03:23PM +0200, Paul B Mahol wrote: >>>>>>>> get_unary() takes at minimum only 1 bit. >>>>>>>> >>>>>>>> Signed-off-by: Paul B Mahol <onemda@gmail.com> >>>>>>>> --- >>>>>>>> >>>>>>>> As this is important fix, will apply in next 5 minutes. >>>>>>>> I kindly ask authors of various timeouts changes to kindly >>>>>>>> test their changes more carefully. >>>>>>> >>>>>>> Can you provide test samples and a fate test ? >>>>>> >>>>>> Why should I? Nobody uploads my request to wav CUE thing. >>>>> >>>>> You have access to upload yourself and >>>>> post the request to the wrong address, it is >>>>> FFmpeg sample uploads <samples-request@ffmpeg.org> >>>>> >>>> >>>> I never received anything of sort of access to something. >>> >>> Your ssh pub key is in the server, which means you can connect to it and >>> upload samples using rsync. >>> >>> See https://ffmpeg.org/fate.html#Uploading-new-samples-to-the-fate-suite >> >> So I connect via ssh program? > > rsync will connect through ssh if you use the commands listed there. > Just replace the path to wherever you have the samples suite locally. > And please don't skip the dry-run, to ensure you don't make unwanted > changes to the remote repository. If I use first command listed there i get: computer@localhost:~/git/ffmpeg$ rsync -vauL --chmod=Dg+s,Duo+x,ug+rw,o+r,o-w,+X fate-suite.ffmpeg.org:/home/samples/fate-suite/ ../fate-suite/ computer@fate-suite.ffmpeg.org: Permission denied (publickey). rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: unexplained error (code 255) at io.c(235) [Receiver=3.1.2]
On 9/4/2020 11:53 AM, Paul B Mahol wrote: > On 9/4/20, James Almer <jamrial@gmail.com> wrote: >> On 9/4/2020 11:44 AM, Paul B Mahol wrote: >>> On 9/4/20, James Almer <jamrial@gmail.com> wrote: >>>> On 9/4/2020 6:29 AM, Paul B Mahol wrote: >>>>> On 9/4/20, Michael Niedermayer <michael@niedermayer.cc> wrote: >>>>>> On Fri, Sep 04, 2020 at 12:27:11AM +0200, Paul B Mahol wrote: >>>>>>> On 9/3/20, Michael Niedermayer <michael@niedermayer.cc> wrote: >>>>>>>> On Thu, Sep 03, 2020 at 07:03:23PM +0200, Paul B Mahol wrote: >>>>>>>>> get_unary() takes at minimum only 1 bit. >>>>>>>>> >>>>>>>>> Signed-off-by: Paul B Mahol <onemda@gmail.com> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> As this is important fix, will apply in next 5 minutes. >>>>>>>>> I kindly ask authors of various timeouts changes to kindly >>>>>>>>> test their changes more carefully. >>>>>>>> >>>>>>>> Can you provide test samples and a fate test ? >>>>>>> >>>>>>> Why should I? Nobody uploads my request to wav CUE thing. >>>>>> >>>>>> You have access to upload yourself and >>>>>> post the request to the wrong address, it is >>>>>> FFmpeg sample uploads <samples-request@ffmpeg.org> >>>>>> >>>>> >>>>> I never received anything of sort of access to something. >>>> >>>> Your ssh pub key is in the server, which means you can connect to it and >>>> upload samples using rsync. >>>> >>>> See https://ffmpeg.org/fate.html#Uploading-new-samples-to-the-fate-suite >>> >>> So I connect via ssh program? >> >> rsync will connect through ssh if you use the commands listed there. >> Just replace the path to wherever you have the samples suite locally. >> And please don't skip the dry-run, to ensure you don't make unwanted >> changes to the remote repository. > > If I use first command listed there i get: > > computer@localhost:~/git/ffmpeg$ rsync -vauL > --chmod=Dg+s,Duo+x,ug+rw,o+r,o-w,+X > fate-suite.ffmpeg.org:/home/samples/fate-suite/ ../fate-suite/ > computer@fate-suite.ffmpeg.org: Permission denied (publickey). > rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] > rsync error: unexplained error (code 255) at io.c(235) [Receiver=3.1.2] Guess you're not using the key Michael saw was uploaded in the server. Do you have more than one for different purposes? Maybe Michael can chime in.
On 9/4/20, James Almer <jamrial@gmail.com> wrote: > On 9/4/2020 11:53 AM, Paul B Mahol wrote: >> On 9/4/20, James Almer <jamrial@gmail.com> wrote: >>> On 9/4/2020 11:44 AM, Paul B Mahol wrote: >>>> On 9/4/20, James Almer <jamrial@gmail.com> wrote: >>>>> On 9/4/2020 6:29 AM, Paul B Mahol wrote: >>>>>> On 9/4/20, Michael Niedermayer <michael@niedermayer.cc> wrote: >>>>>>> On Fri, Sep 04, 2020 at 12:27:11AM +0200, Paul B Mahol wrote: >>>>>>>> On 9/3/20, Michael Niedermayer <michael@niedermayer.cc> wrote: >>>>>>>>> On Thu, Sep 03, 2020 at 07:03:23PM +0200, Paul B Mahol wrote: >>>>>>>>>> get_unary() takes at minimum only 1 bit. >>>>>>>>>> >>>>>>>>>> Signed-off-by: Paul B Mahol <onemda@gmail.com> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> As this is important fix, will apply in next 5 minutes. >>>>>>>>>> I kindly ask authors of various timeouts changes to kindly >>>>>>>>>> test their changes more carefully. >>>>>>>>> >>>>>>>>> Can you provide test samples and a fate test ? >>>>>>>> >>>>>>>> Why should I? Nobody uploads my request to wav CUE thing. >>>>>>> >>>>>>> You have access to upload yourself and >>>>>>> post the request to the wrong address, it is >>>>>>> FFmpeg sample uploads <samples-request@ffmpeg.org> >>>>>>> >>>>>> >>>>>> I never received anything of sort of access to something. >>>>> >>>>> Your ssh pub key is in the server, which means you can connect to it >>>>> and >>>>> upload samples using rsync. >>>>> >>>>> See >>>>> https://ffmpeg.org/fate.html#Uploading-new-samples-to-the-fate-suite >>>> >>>> So I connect via ssh program? >>> >>> rsync will connect through ssh if you use the commands listed there. >>> Just replace the path to wherever you have the samples suite locally. >>> And please don't skip the dry-run, to ensure you don't make unwanted >>> changes to the remote repository. >> >> If I use first command listed there i get: >> >> computer@localhost:~/git/ffmpeg$ rsync -vauL >> --chmod=Dg+s,Duo+x,ug+rw,o+r,o-w,+X >> fate-suite.ffmpeg.org:/home/samples/fate-suite/ ../fate-suite/ >> computer@fate-suite.ffmpeg.org: Permission denied (publickey). >> rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] >> rsync error: unexplained error (code 255) at io.c(235) [Receiver=3.1.2] > > Guess you're not using the key Michael saw was uploaded in the server. > Do you have more than one for different purposes? Maybe Michael can > chime in. I use only one key, another one was made long time ago and never used again. Perhaps that is source of confusion?
On Fri, Sep 04, 2020 at 05:28:06PM +0200, Paul B Mahol wrote: > On 9/4/20, James Almer <jamrial@gmail.com> wrote: > > On 9/4/2020 11:53 AM, Paul B Mahol wrote: > >> On 9/4/20, James Almer <jamrial@gmail.com> wrote: > >>> On 9/4/2020 11:44 AM, Paul B Mahol wrote: > >>>> On 9/4/20, James Almer <jamrial@gmail.com> wrote: > >>>>> On 9/4/2020 6:29 AM, Paul B Mahol wrote: > >>>>>> On 9/4/20, Michael Niedermayer <michael@niedermayer.cc> wrote: > >>>>>>> On Fri, Sep 04, 2020 at 12:27:11AM +0200, Paul B Mahol wrote: > >>>>>>>> On 9/3/20, Michael Niedermayer <michael@niedermayer.cc> wrote: > >>>>>>>>> On Thu, Sep 03, 2020 at 07:03:23PM +0200, Paul B Mahol wrote: > >>>>>>>>>> get_unary() takes at minimum only 1 bit. > >>>>>>>>>> > >>>>>>>>>> Signed-off-by: Paul B Mahol <onemda@gmail.com> > >>>>>>>>>> --- > >>>>>>>>>> > >>>>>>>>>> As this is important fix, will apply in next 5 minutes. > >>>>>>>>>> I kindly ask authors of various timeouts changes to kindly > >>>>>>>>>> test their changes more carefully. > >>>>>>>>> > >>>>>>>>> Can you provide test samples and a fate test ? > >>>>>>>> > >>>>>>>> Why should I? Nobody uploads my request to wav CUE thing. > >>>>>>> > >>>>>>> You have access to upload yourself and > >>>>>>> post the request to the wrong address, it is > >>>>>>> FFmpeg sample uploads <samples-request@ffmpeg.org> > >>>>>>> > >>>>>> > >>>>>> I never received anything of sort of access to something. > >>>>> > >>>>> Your ssh pub key is in the server, which means you can connect to it > >>>>> and > >>>>> upload samples using rsync. > >>>>> > >>>>> See > >>>>> https://ffmpeg.org/fate.html#Uploading-new-samples-to-the-fate-suite > >>>> > >>>> So I connect via ssh program? > >>> > >>> rsync will connect through ssh if you use the commands listed there. > >>> Just replace the path to wherever you have the samples suite locally. > >>> And please don't skip the dry-run, to ensure you don't make unwanted > >>> changes to the remote repository. > >> > >> If I use first command listed there i get: > >> > >> computer@localhost:~/git/ffmpeg$ rsync -vauL > >> --chmod=Dg+s,Duo+x,ug+rw,o+r,o-w,+X > >> fate-suite.ffmpeg.org:/home/samples/fate-suite/ ../fate-suite/ > >> computer@fate-suite.ffmpeg.org: Permission denied (publickey). > >> rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] > >> rsync error: unexplained error (code 255) at io.c(235) [Receiver=3.1.2] > > > > Guess you're not using the key Michael saw was uploaded in the server. > > Do you have more than one for different purposes? Maybe Michael can > > chime in. > > I use only one key, another one was made long time ago and never used again. > Perhaps that is source of confusion? your key on the git and fate samples servers is the same but your user name is durandal on both not computer thx [...]
On Fri, Sep 04, 2020 at 12:13:53PM +0200, Paul B Mahol wrote: > On 9/4/20, Michael Niedermayer <michael@niedermayer.cc> wrote: > > On Fri, Sep 04, 2020 at 12:27:11AM +0200, Paul B Mahol wrote: > >> On 9/3/20, Michael Niedermayer <michael@niedermayer.cc> wrote: > >> > On Thu, Sep 03, 2020 at 07:03:23PM +0200, Paul B Mahol wrote: > >> >> get_unary() takes at minimum only 1 bit. > >> >> > >> >> Signed-off-by: Paul B Mahol <onemda@gmail.com> > >> >> --- > >> >> > >> >> As this is important fix, will apply in next 5 minutes. > >> >> I kindly ask authors of various timeouts changes to kindly > >> >> test their changes more carefully. > >> > > >> > Can you provide test samples and a fate test ? > >> > >> Why should I? Nobody uploads my request to wav CUE thing. > > > > You have access to upload yourself and > > post the request to the wrong address, it is > > FFmpeg sample uploads <samples-request@ffmpeg.org> > > > > > >> > >> Test samples can be generated by installing trial dxtory capture and > >> recording > >> mainly black frames from some simple game. On windows, or under > >> virtualbox. > >> > >> I can upload files, but I value my time and will not do it for nothing > >> in return. > > > > The time someone else needs to setup a windows machiene, trial dxtory > > capture, > > some game and so forth is several times that of just providing existing > > files. > > > > So by providing existing files you give others more time to work on > > other things like reviewing your patches, or uploading your files to > > fate, or working on anything else, which can then also benefit you ... > > Is that enough in return ? > > https://drive.google.com/drive/folders/1RV0NSfkAvNA8Ju59SBuzKg7pWosIVLQd?usp=sharing Thanks [...]
diff --git a/libavcodec/dxtory.c b/libavcodec/dxtory.c index bc19f27951..3cd95afe80 100644 --- a/libavcodec/dxtory.c +++ b/libavcodec/dxtory.c @@ -395,7 +395,7 @@ static int dx2_decode_slice_5x5(GetBitContext *gb, AVFrame *frame, int stride = frame->linesize[0]; uint8_t *dst = frame->data[0] + stride * line; - for (y = 0; y < left && get_bits_left(gb) > 6 * width; y++) { + for (y = 0; y < left && get_bits_left(gb) >= 3 * width; y++) { for (x = 0; x < width; x++) { b = decode_sym_565(gb, lru[0], 5); g = decode_sym_565(gb, lru[1], is_565 ? 6 : 5); @@ -462,7 +462,7 @@ static int dx2_decode_slice_rgb(GetBitContext *gb, AVFrame *frame, int stride = frame->linesize[0]; uint8_t *dst = frame->data[0] + stride * line; - for (y = 0; y < left && get_bits_left(gb) > 6 * width; y++) { + for (y = 0; y < left && get_bits_left(gb) >= 3 * width; y++) { for (x = 0; x < width; x++) { dst[x * 3 + 0] = decode_sym(gb, lru[0]); dst[x * 3 + 1] = decode_sym(gb, lru[1]); @@ -508,7 +508,7 @@ static int dx2_decode_slice_410(GetBitContext *gb, AVFrame *frame, uint8_t *U = frame->data[1] + (ustride >> 2) * line; uint8_t *V = frame->data[2] + (vstride >> 2) * line; - for (y = 0; y < left - 3 && get_bits_left(gb) > 9 * width; y += 4) { + for (y = 0; y < left - 3 && get_bits_left(gb) >= 4 * width; y += 4) { for (x = 0; x < width; x += 4) { for (j = 0; j < 4; j++) for (i = 0; i < 4; i++) @@ -553,7 +553,7 @@ static int dx2_decode_slice_420(GetBitContext *gb, AVFrame *frame, uint8_t *V = frame->data[2] + (vstride >> 1) * line; - for (y = 0; y < left - 1 && get_bits_left(gb) > 6 * width; y += 2) { + for (y = 0; y < left - 1 && get_bits_left(gb) >= 3 * width; y += 2) { for (x = 0; x < width; x += 2) { Y[x + 0 + 0 * ystride] = decode_sym(gb, lru[0]); Y[x + 1 + 0 * ystride] = decode_sym(gb, lru[0]); @@ -597,7 +597,7 @@ static int dx2_decode_slice_444(GetBitContext *gb, AVFrame *frame, uint8_t *U = frame->data[1] + ustride * line; uint8_t *V = frame->data[2] + vstride * line; - for (y = 0; y < left && get_bits_left(gb) > 6 * width; y++) { + for (y = 0; y < left && get_bits_left(gb) >= 3 * width; y++) { for (x = 0; x < width; x++) { Y[x] = decode_sym(gb, lru[0]); U[x] = decode_sym(gb, lru[1]) ^ 0x80;
get_unary() takes at minimum only 1 bit. Signed-off-by: Paul B Mahol <onemda@gmail.com> --- As this is important fix, will apply in next 5 minutes. I kindly ask authors of various timeouts changes to kindly test their changes more carefully. --- libavcodec/dxtory.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)