[x264-devel] Bug (or bugs) in x264 rev 2334 OpenCL and one improvement proposal.

[Jason Garrett-Glaser]

> What I was thinking was that on -p 2 and -p 3 videos frame structure is
> already known. So for example dividing encoding between CPU and GPU could be
> done taking frames from one I frame to next. CPU encodes one IPB set while
> GPU encodes another IPB set.

You can't do that in an inter-frame video format; each frame depends
on the encoded versions of previous frames. If you want to do that,
you need to thread on a per-GOP level, which is basically equivalent
to splitting up the video and sending it to two entirely different
encoding apps -- which you can already do.

> and if or when this isn't valid idea / process
> other ideas and maybe even some implementation can be looked from (in this
> case nVidia code, AMD might have something similar but since I haven't used
> ATI after early 2000 I don't know what they have to offer).
>
> https://developer.nvidia.com/nvidia-video-codec-sdk
> NVCUVENC - CUDA-Based Video Encoding
> NVCUVENC is a hybrid CPU/GPU accelerated library with related code samples
> that creates video streams compliant with AVC/H.264.

nVidia's CUDA encoder is at best mediocre, in terms of speed,
compression and features. They added a hardware encoder because the
CUDA encoder wasn't able to provide good enough results to be useful.

It is not something we could possibly call "x264-grade" with a straight face.

Jason