[FFmpeg-devel] [PATCH] mjpegdec: Support 4x1, 2x1, 2x1 notation for 4:2:2 chroma subsampling

[Michael Niedermayer]

On Tue, Jun 19, 2018 at 01:46:27PM +0100, Derek Buitenhuis wrote:
> On 19/06/2018 12:31, Michael Niedermayer wrote:
> > On Mon, Jun 18, 2018 at 09:19:30PM +0100, Derek Buitenhuis wrote:
> >> Just one of the many, many ways to store this stuff in the header.
> >>
> >> Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
> >> ---
> >> Related reading, but not exactly the same type:
> >>      * https://github.com/libjpeg-turbo/libjpeg-turbo/issues/92
> >>      * https://github.com/libjpeg-turbo/libjpeg-turbo/commit/8ce2c9119a995ef6280f8bba375aac7effb9b571
> >> ---
> >>   libavcodec/mjpegdec.c | 1 +
> >>   1 file changed, 1 insertion(+)
> >>
> >> diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
> >> index d1dca84d36..e5888ed548 100644
> >> --- a/libavcodec/mjpegdec.c
> >> +++ b/libavcodec/mjpegdec.c
> >> @@ -568,6 +568,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
> >>           }
> >>           break;
> >>       case 0x21111100:
> >> +    case 0x41212100:
> >>           if (s->component_id[0] == 'Q' && s->component_id[1] == 'F' && s->component_id[2] == 'A') {
> >>               if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_GBRP;
> >>               else
> > 
> > either this is wrong or
> > "
> >   -    /* NOTE we do not allocate pictures large enough for the possible
> >   -     * padding of h/v_count being 4 */
> >   "
> > this is outdated in some way.
> 
> I don't think this was ever a valid comment, since h_coutn and v_count are
> not supposed to be interpreted as absolute values to be applied? That is,
> you need to look at the ratio.

The absolute values define the bitstream and have to be used


> 
> Further, I am not quite sure what 'padding' refers to in this specific instance,
> since this has to do with subsampling? I'm maybe missing something JPEG-specific?

with a count of 4, mjpeg is coded in MCUs of 4 8x8 blocks in that direction
all buffers must be sized accordingly so that these blocks fit in.
I suspect that is already done but i could be wrong

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180620/193683de/attachment.sig>