On 3/13/23 20:44, Andreas Rheinhardt wrote: > Looking at the calculation in av_dynamic_hdr_plus_to_t35(), it seems > that the maximum bitlength of a valid ITU-T T.35 payload is > 48+2×937+27+1+10+25×25×4+3×82+(3×15×24)+(1+10+25×25×4+3×1)+(3×(28+15×10))+3+3×6 > = 8855 bits (please double-check this). This means we can just copy that > much into a padded buffer on the stack and ignore the padding. We may > then remove the padding from the serialization function, too.
I went over the calculations again and found a couple of places where size was overestimated due to fields that can fit larger values than their specified maximum. 937 also seems like a typo on my part (unsure how that happened, maybe multiplied instead of added some number), it should be 153. I re-ran the numbers for everything and rewrote/expanded the size calculation code somewhat to make reading alongside the spec or block comment easier. I also removed another 40 bits from the header to match the parsing function, which begins parsing at the application mode, rather than at the terminal provider code. That means we exclude 48 bits in total from the header, and the calculation should be as follows: 8 + 2 + 2 * 153 + 27 + 1 + 10 + 25 * 25 * 4 + 3 * (72 + 15 * 24 + 10) + 1 + 10 + 25 * 25 * 4 + 3 * (1 + 28 + 15 * 10) + 3 * (1 + 6) = 7249 bits maximum (907 bytes rounded up). Can we correct the padding amount along with get_bits.h in a separate patch? I would like to avoid scope creep. Will send a new version with the changes mentioned above. I've tested the round trip (HEVC decode -> parse -> serialize -> HEVC encode). RZ _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
