On 8/6/2024 2:54 PM, Andreas Rheinhardt wrote:
Michael Niedermayer:
On Tue, Aug 06, 2024 at 07:05:38PM +0200, Michael Niedermayer wrote:
Hi
Did CBS win the obfuscated C contest yet?
I was just looking at a msan issue and then looked at this:
CHECK(FUNC_SEI(message_list)(ctx, rw, ¤t->message_list, 1));
#define CHECK(call) do { \
err = (call); \
if (err < 0) \
return err; \
} while (0)
#define FUNC_NAME2(rw, codec, name) cbs_ ## codec ## _ ## rw ## _ ## name
#define FUNC_NAME1(rw, codec, name) FUNC_NAME2(rw, codec, name)
#define FUNC_H264(name) FUNC_NAME1(READWRITE, h264, name)
#define FUNC_H265(name) FUNC_NAME1(READWRITE, h265, name)
#define FUNC_H266(name) FUNC_NAME1(READWRITE, h266, name)
#define FUNC_SEI(name) FUNC_NAME1(READWRITE, sei, name)
#define SEI_FUNC(name, args) \
static int FUNC(name) args; \
static int FUNC(name ## _internal)(CodedBitstreamContext *ctx, \
RWContext *rw, void *cur, \
SEIMessageState *state) \
{ \
return FUNC(name)(ctx, rw, cur, state); \
} \
static int FUNC(name) args
anyway, can we remove all preprocessor use from cbs ?
I don't think that this is really obfuscated.
the issue iam looking at is due to
SEI_FUNC(sei_pic_timing, (CodedBitstreamContext *ctx, RWContext *rw,
H264RawSEIPicTiming *current, SEIMessageState *sei))
having different active SPS on writing than reading, so the write code
has nal_hrd_parameters_present_flag set while the read had that 0
so uninitialized data is written
I cannot find any match for "cbs" in MAINTAINERS, also there are no copyright
with names in the cbs code.
1. I just sent a patch that "fixes" this.
2. But actually, there is a deeper bug here: We would need to defer
parsing certain SEI message units to a second pass when the currently
active SPS is known. This can happen with spec-compliant input (and even
Is this a scenario where a slice that referenced an SPS was parsed, then
a SEI message, then another slice that references another SPS, and the
SEI expects the latter to be active despite it being coded before the slice?
more so with spec-incompliant input, which is presumably what the fuzzer
produced).
- Andreas
_______________________________________________
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".
_______________________________________________
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".
