Quoting Timo Rothenpieler (2022-12-06 16:08:49) > On 06/12/2022 15:43, Anton Khirnov wrote: > > Quoting Timo Rothenpieler (2022-12-06 15:39:50) > >> On 06/12/2022 15:37, Anton Khirnov wrote: > >>> Quoting Timo Rothenpieler (2022-12-05 14:39:37) > >>>> This is fairly basic and makes a lot of assumptions, but it works > >>>> for the most simple cases. > >>>> > >>>> For one, it only ever fetches exactly one packet per call to > >>>> receive_frame. > >>>> Right now it's impossible for there to ever be more than one, but the API > >>>> allows for more, which might need handled in the future. > >>>> > >>>> It also basically translates the new API back to the old, since that's > >>>> how > >>>> the frame threading code operates. Which feels backwards in regards to > >>>> the new API, but it was the path with least resistance in implementing > >>>> this. > >>> > >>> If it only supports one packet to one frame, then it goes against the > >>> whole point of using the receive_frame API. > >> > >> Otherwise the entirety of pthread_frame.c would need rewritten from > >> scratch. It has that assumption coded into it. > > > > I told you on IRC I already have a mostly-finished branch that > > implements threading with receive_frame(), so I don't really understand > > what's the point of your writing this patch. > > > > You said it wasn't even in a state to be tested. > Do you have a link to it? Happy to help finishing it up.
Sure, see branch 'thread_receive' in git://git.khirnov.net/libav IIRC it was only missing some allocations for frames or packets in AVCodecInternal. -- Anton Khirnov _______________________________________________ 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".
