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.
_______________________________________________
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".
