30.01.19 21:02 - James Almer: > On 1/30/2019 4:19 PM, jannis_wth wrote: >> 30.01.19 19:51 James Almer: >>> On 1/30/2019 3:43 PM, jannis_wth wrote: >>>> Okay, so how about this one? >>>> This functionality is important if you don't know the packet size you >>>> are feeding. It allows you to reconstruct the size. >>> >>> In what scenario you can't know the size of the AVPacket you're feeding >>> to avcodec_send_packet(). >>> >> For example when a mp4 container lost its moov atom. > > What value is stored in pkt->size in this scenario at the time you feed > it to libavcodec? This function will return that value after all, > provided it's valid data. > > Also, AVCodecParsers are the usual way to reconstruct/assemble broken or > incomplete packets.
pkt->size and its offset can be used to rebuild the moov atom. I tried av_parser_parse2() but it I think it's not what I need. Its return value does not match the true packet size, not even close. >>> This is only used by decoders implementing the AVCodec.decode() >>> callback. It will always be zero for any decoder using >>> AVCodec.receive_frame(), like Bink Audio, libdav1d, etc. >> >> Well, what would be the correct way then? >> Or is there no good way and thus you won't accept such interface? > > Accepting it or not depends on what other developers think about such a > function. Unlike the old API, the new one always fully consumes all > packets you feed to it, so there's no real need to check how many bytes > were consumed. > Trying to expose the internals for this purpose is not really feasible, > as you could see with all the different layers of internal buffering. > > I guess avctx->internal->last_pkt_props could work for this, but it may > not be consistent across decoders. avctx->internal->last_pkt_props stores the properties of the last passed packet, and does not get updated on decoding frames. Since I set the input-packets size to a constant (size is unknown) this is not very helpfull.. One could add a warning to avcodec_get_remaining_size() saying it only works for some codecs. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
