On Sun, Feb 11, 2018 at 08:31:40PM +0200, Jan Ekström wrote:
> On Sun, Feb 11, 2018 at 7:52 PM, Michael Niedermayer
> <mich...@niedermayer.cc> wrote:
> >
> > should be ok unless its intended to also restore the MSB
> >
> The value seemed to be 10bit and if the pointer is at the position
> right after the picture_start_code, then `buf[0] << 2` would move the
> 8 bits left of data two bits leftwards, and `buf[1] >> 6` would then
> move the topmost bits of the following byte to be the bottom-most
> bits.
> Unless you mean that there's a forgotten `(uint16_t)` there as the end
> value has 10 bits of effective data, making the correct way of doing
> it something a la `(((uint16_t)buf[0]) << 2) | (((uint16_t)buf[1]) >>
> 6)`?

it was more a question about our API 

if output_picture_number is intended to be what it is called in english then
this patch is wrong as the number will frequently go back to 0 and
as more than 1024 pictures are output.
so taken as its english meaning, there would be code needed to 
the MSB occasionally
OTOH if the field is intended to store a unspecified number of LSB only
i wonder what it could be used for

> > Theres no code using output_picture_number currently
> >
> Seems like some API users utilize this value.

What do they do with it ?


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.

Attachment: signature.asc
Description: PGP signature

ffmpeg-devel mailing list

Reply via email to