On 3/8/2021 5:48 PM, Lynne wrote:
Mar 8, 2021, 21:31 by jamr...@gmail.com:
On 2/22/2021 7:27 PM, James Almer wrote:
Looked at bit into this. AVCodec->encode2() based encoders don't support
returning EAGAIN at all, as it completely breaks the frame threading logic. It
would require a considerable rewrite in order to re-add a task that didn't fail
but also didn't succeed.
Non frame threading encoders could probably support it with some minimal
changes, but i don't think suddenly letting an scenario that was until now
guaranteed to never happen start happening (avcodec_send_frame() and
avcodec_receive_packet() both returning EAGAIN) is a good idea. It's an API
break.
Letting the user's custom get_encode_buffer() callback suspend the thread is
IMO acceptable. In frame threading scenarios, the other threads are still
working on their own packets (afaics none depends on the others, since it's
intra only encoders only).
Ping. I'd like to get this in.
https://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/276679.html
You agreed with me, so i didn't think i needed to reply to that email.
It's Mark who hasn't yet said if he's ok with it.
And regarding to the AVPacket data alignment, that's a separate
discussion for an API change unrelated to this.
_______________________________________________
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".
