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

[Nihil]

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

When it comes to h.264 (x264) GOP is what I was thinking of. Since my 
own video codec coding experience is over decade old and at that time 
and with the codec I was playing with IPB set was independent structure 
which could be encoded independently without problems since there wasn't 
outside references to B-frames. I know this from the fact because I 
implemented multi-threading to that codec while it was single thread 
encoder at the beginning. Goal of that implementation was to utilize all 
CPU power on dual CPU systems. It's kind of sad that there isn't dual 
CPU MoBo's in consumer space anymore. Most people can't buy Xeon etc 
dual CPU systems but dual CPU Haswell could be nice for some consumers.

Well personally I haven't looked into how to split video stream and 
direct it to two encoding application where one uses CPU and other uses 
GPU and after that combines output from those two application into one 
video stream. Frankly speaking that's not my cup of tea. When there is 
at least 3 or 4 different application doing just video stream encoding 
and adding multiplexing and synching to that, whole system gets way too 
complex for my taste. When system gets more complex risk of something 
going wrong gets higher.

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

If you say so. That nVidia CUDA encoder was just an example. As I said 
earlier there are reasons which limit time I can use for things like 
this. From where we get to "asking personal starship" and me asking 
generic things like "adding OpenCL/GPU support to -p 2 and -p 3". 
Personally I don't have time to start to implement this kind of 
functionality and I don't even have enough time to make some decent 
research which could have pointed out that NVCUVENC performance isn't 
that great and it doesn't meet x264 requirements.

So best I could do was to ask if x264 developers have ideas, time, 
interest, something to expand OpenCL/GPU usage in x264 and improve 
encoding speed.

Should we stop here since I don't have code etc to contribute and my 
spare time is barely enough for sending few e-mails.

Thank you from answers and your time, sorry about inconvenience.

 >Jason