>Wouldn't it make more sense to set it in decoder init? >Anton Khirnov
Yes, you're right, in the actual code, this would seem the best place. But, I have in mind to add support for s337m in wav (I am just getting back on this work I started some months ago). Take a 48k wav with dolby_e in it which rate is 44800 for example (this is my test case actually). Here is the diff (+frame_size set on init / -frame_size set on decode frame) -0, 0, 0, 1920, 11496, 0x05a9c147 -0, 1920, 1920, 1920, 11496, 0x1d44d2b4 -0, 3840, 3840, 1920, 11496, 0x4e078953 -0, 5760, 5760, 1920, 11496, 0x1c73b1a1 -0, 7680, 7680, 1920, 11262, 0xfa179fc8 +0, 0, 0, 1792, 11496, 0x05a9c147 +0, 1792, 1792, 1920, 11496, 0x1d44d2b4 +0, 3712, 3712, 1920, 11496, 0x4e078953 +0, 5632, 5632, 1920, 11496, 0x1c73b1a1 +0, 7552, 7552, 1920, 11262, 0xfa179fc8 The problem is the duration of the first audio frame. The mismatch is because of the difference of sample_rate between the mux/wav and the stream/dolby_e. Anyway, my proposal is that I will send my complete patchset including this patch, so you can review the global project and continue the discussion. I think the way I have integrated s377m in wav is ok, but the lack of a parser for dolby_e (and thus early sample rate detection) makes things a little bit tricky. Nicolas _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
