On Sat, Sep 16, 2017 at 04:41:00PM +0200, Reimar Döffinger wrote: > On Fri, Sep 15, 2017 at 02:16:58AM +0200, Michael Niedermayer wrote: > > On Wed, Sep 13, 2017 at 08:11:38PM +0200, Reimar Döffinger wrote: > > > On Wed, Sep 13, 2017 at 07:12:48PM +0200, Reimar Döffinger wrote: > > > > This is the equivalent to what 7d317d4706b49d572a1eb5269438753be18362c7 > > > > did for the codec-specific options. > > > > av_opt_copy has specific handling so it's fine that we already copied > > > > the whole context before. > > > > the change looks reasonable > > Thanks! > > > > Btw, if someone can make time for reviewing it that would likely > > > be time well spent. > > > > you mean reviewing the whole frame_thread_encoder code searching > > for issues unrelated to tickets or patches ? > > ATM i think i have too much i should have done "yesterday" to add that > > Sure, I understand. Though just some comments around the thinking or > such (e.g. if it's intentional or just outdated API that it is not using > av_packet_alloc, or what exactly is the av_dup_packet there for).
IIRC av_dup_packet() is there so cases of packets that have their memory reused in the next call work. av_dup_packet() properly allocates a packet or if its already properly allocated it does nothing its possibly av_dup_packet() is not needed anymore thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
