| Message ID | a9b7b394-3d2e-bd2a-e3ae-039a0cccf03b@mediaarea.net |
|---|---|
| State | Accepted |
| Commit | b5788e70255a8dbbd4a816f06a39a81dca4b2fd1 |
| Headers | show |
On Tue, Apr 10, 2018 at 09:41:05PM +0200, Jerome Martinez wrote: > On 10/04/2018 12:34, Carl Eugen Hoyos wrote: > >2018-04-10 12:28 GMT+02:00, Kieran O Leary <kieran.o.leary@gmail.com>: > >>I just tested this patch non packed to 16-bit gbrp12le DPX from DaVinci > >>Resolve. > >Testing is good, apart > > I thought the patch was "technically" OK, as I answered to all change > requests and there was no additional feedback IIRC. > > > from more brackets > > Not sure I understand, as the only "missing" brackets I see are for the 1 > line code after a "if", and I see that 1 line code has no brackets in other > parts of the file. > Anyway, I added more brackets, except for "if (*n_datum) (*n_datum)--;" as I > copied/pasted it from another part of the file. > Did I miss something else? > > > (and less comments) > > I thought it would be better for someone willing to add alpha support in the > future, as the alpha support was tested and "just" rejected for the moment. > Anyway, I removed the commented code. > > Modified patch attached. > Note that I personally prefer to use the previous patch (or this patch > without the additional brackets). > > > it would > >be better if Jerome sends his public keys to Michael and pushes the patch. > > If it is the only solution for having the patch pushed, I'll do that, even > if I am not convinced that I deserve for the moment write rights on FFmpeg > repository (especially because Git and me are not good friends :) ). what do you mean by "Git and me are not good friends" ? If git hates you and sometimes does things that you didnt intend at all then that would be a problem with direct pushes as theres no way to undo. But maybe i misunderstand. Also to get git write access, post a patch that adds yourself to the MAINTAINERs file. When noone objects then ill add your key and apply the MAINTAINER patch. thanks [...]
On Tue, Apr 10, 2018, at 2:05 PM, Michael Niedermayer wrote: > > what do you mean by "Git and me are not good friends" ? > If git hates you and sometimes does things that you didnt intend at all then > that would be a problem with direct pushes as theres no way to undo. > But maybe i misunderstand. > > Also to get git write access, post a patch that adds yourself to the > MAINTAINERs file. When noone objects then ill add your key and apply > the MAINTAINER patch. Also, if you're uncomfortable pushing to the repository that's fine too. It is not a problem, but you may have to prod and remind us, perhaps a few times (or more), to push stuff.
On 11/04/2018 00:16, Lou Logan wrote: > On Tue, Apr 10, 2018, at 2:05 PM, Michael Niedermayer wrote: >> what do you mean by "Git and me are not good friends" ? >> If git hates you and sometimes does things that you didnt intend at all then >> that would be a problem with direct pushes as theres no way to undo. >> But maybe i misunderstand. Yes, that's right :), I think you also remarked that I am an expert of careless mistakes :(. I am still at the bottom of the Git learning curve, being more used to the GitHub PR things (which IMO avoids well to do a mess with upstream repo). Additionally, I think that it does not worth it to take risks (including the risk of compromised machine) about giving me write rights with the only few patches I send. It would be another story if I become more active on FFmpeg code in the future. >> >> Also to get git write access, post a patch that adds yourself to the >> MAINTAINERs file. When noone objects then ill add your key and apply >> the MAINTAINER patch. > Also, if you're uncomfortable pushing to the repository that's fine too. It is not a problem, but you may have to prod and remind us, perhaps a few times (or more), to push stuff. I kindly request a maintainer to push one (the latest one?) of the DPX patches in this thread (i.e. right I am uncomfortable pushing to FFmpeg repo directly, I would do it only if it is the only method for having my patches pushed upstream after review due to no current maintainer willing to push them), as well as reviewing then push (if they are fine) the ones related to FFV1 [1] Jérôme [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/226192.html
On Wed, Apr 11, 2018 at 11:44:47AM +0200, Jerome Martinez wrote: > On 11/04/2018 00:16, Lou Logan wrote: > >On Tue, Apr 10, 2018, at 2:05 PM, Michael Niedermayer wrote: > >>what do you mean by "Git and me are not good friends" ? > >>If git hates you and sometimes does things that you didnt intend at all then > >>that would be a problem with direct pushes as theres no way to undo. > >>But maybe i misunderstand. > > > Yes, that's right :), I think you also remarked that I am an expert of > careless mistakes :(. > I am still at the bottom of the Git learning curve, being more used to the > GitHub PR things (which IMO avoids well to do a mess with upstream repo). > Additionally, I think that it does not worth it to take risks (including the > risk of compromised machine) about giving me write rights with the only few > patches I send. It would be another story if I become more active on FFmpeg > code in the future. > > >> > >>Also to get git write access, post a patch that adds yourself to the > >>MAINTAINERs file. When noone objects then ill add your key and apply > >>the MAINTAINER patch. > >Also, if you're uncomfortable pushing to the repository that's fine too. It is not a problem, but you may have to prod and remind us, perhaps a few times (or more), to push stuff. > > I kindly request a maintainer to push one (the latest one?) of the DPX will apply thx [...]
diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c index 1aa2cbd1c8..026fb10e90 100644 --- a/libavcodec/dpx.c +++ b/libavcodec/dpx.c @@ -65,6 +65,38 @@ static uint16_t read10in32(const uint8_t **ptr, uint32_t * lbuf, return *lbuf & 0x3FF; } +static uint16_t read12in32(const uint8_t **ptr, uint32_t * lbuf, + int * n_datum, int is_big) +{ + if (*n_datum) + (*n_datum)--; + else { + *lbuf = read32(ptr, is_big); + *n_datum = 7; + } + + switch (*n_datum){ + case 7: return *lbuf & 0xFFF; + case 6: return (*lbuf >> 12) & 0xFFF; + case 5: { + uint32_t c = *lbuf >> 24; + *lbuf = read32(ptr, is_big); + c |= *lbuf << 8; + return c & 0xFFF; + } + case 4: return (*lbuf >> 4) & 0xFFF; + case 3: return (*lbuf >> 16) & 0xFFF; + case 2: { + uint32_t c = *lbuf >> 28; + *lbuf = read32(ptr, is_big); + c |= *lbuf << 4; + return c & 0xFFF; + } + case 1: return (*lbuf >> 8) & 0xFFF; + default: return *lbuf >> 20; + } +} + static int decode_frame(AVCodecContext *avctx, void *data, int *got_frame, @@ -201,10 +233,27 @@ static int decode_frame(AVCodecContext *avctx, break; case 12: if (!packing) { - av_log(avctx, AV_LOG_ERROR, "Packing to 16bit required\n"); - return -1; + int tested = 0; + if (descriptor == 50 && endian && (avctx->width%8) == 0) { // Little endian and widths not a multiple of 8 need tests + tested = 1; + } + if (!tested) { + av_log(avctx, AV_LOG_ERROR, "Packing to 16bit required\n"); + return -1; + } + } + stride = avctx->width * elements; + if (packing) { + stride *= 2; + } else { + stride *= 3; + if (stride % 8) { + stride /= 8; + stride++; + stride *= 8; + } + stride /= 2; } - stride = 2 * avctx->width * elements; break; case 16: stride = 2 * avctx->width * elements; @@ -349,6 +398,7 @@ static int decode_frame(AVCodecContext *avctx, (uint16_t*)ptr[2], (uint16_t*)ptr[3]}; for (y = 0; y < avctx->width; y++) { + if (packing) { if (elements >= 3) *dst[2]++ = read16(&buf, endian) >> 4; *dst[0] = read16(&buf, endian) >> 4; @@ -357,6 +407,17 @@ static int decode_frame(AVCodecContext *avctx, *dst[1]++ = read16(&buf, endian) >> 4; if (elements == 4) *dst[3]++ = read16(&buf, endian) >> 4; + } else { + *dst[2]++ = read12in32(&buf, &rgbBuffer, + &n_datum, endian); + *dst[0]++ = read12in32(&buf, &rgbBuffer, + &n_datum, endian); + *dst[1]++ = read12in32(&buf, &rgbBuffer, + &n_datum, endian); + if (elements == 4) + *dst[3]++ = read12in32(&buf, &rgbBuffer, + &n_datum, endian); + } } for (i = 0; i < elements; i++) ptr[i] += p->linesize[i];