On Tue, Jun 13, 2023 at 7:43 PM Roy Funderburk <royffm...@funderburk.us> wrote:
> > > On 6/13/23 7:26 AM, Paul B Mahol wrote: > > Why we need new av_* calls, can you elaborate logic behind such approach > to > > implement parser? > > > There is common code for dtsuhd audio frame parsing (dtsuhd_common.c) used > by the libavcodec and libavformat DTS-UHD modules. It is complex enough > that we do not want to duplicate it. > Parser just splits bitstream into packets and packets are then passed to decoders. Demuxer in such case pass fixed packet sizes to parser minus optional header/trailer bytes. There should be no reason for such complexity in parser and/or demuxer if there are in bitstream valid markers for start/end of packet that is given to decoder. Unless this format uses packets that may be not byte aligned than and/or markers are useless and/or there are no size info of each packet feed to decoder in such case and only in such case current complexity is valid. > > If you refer to the naming of av_*, would changing the names to > ff_dtsuhd_* as in libavcodec/aac_ac3_parser.c be more appropriate? > That is purely for visuals, and not relevant in discussing issues. > > Thanks, > -Roy > > _______________________________________________ > 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".
