On Wed, Apr 10, 2019 at 3:28 AM James Almer <jamr...@gmail.com> wrote: > > > >> Two thirds of SPS is not hard to implement, so i really don't understand > >> why you're so adamantly against it. > > > > I’m adamant about re-using code between libavcodec and libavformat. > > Re-using code is _good_ > > So lets do what i suggested in a previous email if re-implementing sps > in libavformat is not ok in your opinion: Add an > avpriv_h264_decode_seq_parameter_set() function that internally calls > ff_h264_decode_seq_parameter_set(), including proper AVBufferRef > cleaning at the end with a call to ff_h264_ps_uninit(), and that either > returns the six values using pointers parameters, or takes a pointer to > a new, small struct as parameter which will be allocated at runtime > (thus avoiding storing it on stack within libavformat, and tying to the > ABI) which contains at least those six values in question. > The reason i suggest a new small struct is to avoid using H264ParamSets > for this, which would imply direct access to ps->sps fields within > libavformat, and thus locking everything in its current offset. > > See how avpriv_ac3_parse_header() and av_ac3_parse_header() wrap > ff_ac3_parse_header() and each do either of the two options above.
As mentioned in another thread on this topic already, I agree with this. If you insist on re-use so strongly, then lets not cement more internal structs into the ABI, especially some that we worked on to get out of the ABI recently in the first place, and define a clean wrapper API that takes simple byte pointers as input and gives you a simplified public struct back. - Hendrik _______________________________________________ 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".
