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 increase(/decrease) 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.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
