Comments on: Pipe RGB data to ffmpeg

by: Kyle Cordes

Thu, 22 May 2008 20:24:09 +0000

As I described in the post I solved the challenges here, with some IPP stuff and some code from before I found IPP. Sorry, but I’m not at liberty to publish any more details.

by: Connie

Thu, 22 May 2008 01:29:54 +0000

Kyle,

thanks for the post. I’ve also been looking for a way to pipe rgb data into ffmpeg. Do you know if there’s been any new developments since the time of your post? Or if there’s another format (other than y’cbcr) that can be piped into ffmpeg?

You mentioned that:

“By using a multicore CPU and threads, this whole process can be made to happen in real time or better (i.e., one second of “wall clock” processing time, for one second of finished MPEG2 video). ”

Are you speaking from personal experience? If so, was it using IPP’s function or your own solution?

thanks in advance

by: Horse

Thu, 18 Oct 2007 01:34:56 +0000

Boris, in a single thread converting a 720×576 frame may be reasonably fast. Multicore machines are not going to nett you much gain unless you understand the limitations of threaded programming and how to avoid them. Remember that synchronization will lose you as much as you gain from parallelising your code if you do it badly.

by: Boris

Fri, 21 Sep 2007 22:03:40 +0000

What do you mean ‘quite slow’. For instance, on a single thread i can convert 720×576 in 3.8ms on a Pentium4, on todays cheap dual core machines it would be 1/2 that. I dont do ‘theory’ i always speak from practice.

by: Kyle Cordes

Tue, 04 Sep 2007 13:27:49 +0000

Boris’s comment is a great example of the difference between theory and practice. It turns out that in practice, a trivial implementation of the trivial RGB/YUV conversion is quite slow. That code, and many other parts, need to be well tested and optimized to process video in real time.

by: Boris

Tue, 04 Sep 2007 12:50:33 +0000

RGB to YUV conversion, including sample C code is on wikipedia. Its a fairly trivial conversion.
the conversion code is not your biggest concern when implementing on x86, streaming/cache issues will be.

by: Alex

Mon, 06 Aug 2007 18:03:04 +0000

I’m interested in doing something similar. After some research, I wonder why you
weren’t able, or chose not to, use libavcodecs own img_convert() method to go from RGB to YUV420.

by: Maurice

Thu, 12 Jul 2007 09:58:40 +0000

I also encountered the problem of piping Y Cb Cr Data into ffmpeg. I found a solution and maybe it is useful to anybody out there in the WWW
An application, let’s call it “a.out”, extracts YCbCr Data (4:2:2) with 10 bit resolution from a video stream. The order ist [Cb] [Y] [Cr] [Y] ….
I created a named_pipe called “output_pipe” which is constantly filled with the RGB Data. A.out constantly is filling up the “output_pipe” with YCbCr data.
Now, I can use ffmpeg like the following:
ffmpeg -pix_fmt uyvy422 -s 720×576 -f rawvideo -i output_pipe -target pal-dvd -aspect 4:3 -y myDVD.mpg

Notice, that the codec is “rawvideo” and the “pix_fmt” is chosen corresponsing to the input stream. You can get a list of all pix_formats of ffmpeg by typing “ffmpeg -pix_fmt list”.

I hope this is helpful!

Currently, I’m trying to pipe video and audio to ffmpeg within 1 step. I use the command:
ffmpeg -pix_fmt uyvy422 -s 720×576 -f rawvideo -i output_pipe -target pal-dvd -aspect 4:3 -y myDVD.mpg -f s16le -ar 48000 -ac 2 -i pcm0_pipe -acodec mp2 -ab 224k -newaudio

I’m having 48kHz / 16bit stereo audio raw PCM data which I want to directly add to the video file (muxing). The audio data is piped into the pcm0_pipe.
I ran into the problem that, of course, there is more audio than video data and so, if the video pipe is full, ffmpeg waits for the audio data and the whole process is blocked….

If anybody knows a solution, it would be nice to share it

Maurice