x264 development

[Esurnir]

i was sure you were asked this all the time so i did a search for "cuda 3.0" and "fermi" but couldn't find anything.
not too long ago the specs of fermi were released(here's a link to one review on it http://www.anandtech.com/video/showdoc.aspx?i=3651 ) and from what i understood of them it made GPGPU much simpler then it is today.
now, i remember that when cuda first came out the one of the main issues raised in regards to using it in x264 was high latencies, and difficult\inefficient coding while actually using cuda, from the review i got the impression that cuda 3\fermi made coding for it a lot more flexible and similar to coding for a normal CPU, as well a lowered price for access to it.
so i wanted to see if this is likely to change anything in regards for implementing this in future versions of x264, and generally if you guys think those changes could be useful.

The problem with CUDA is that there are some application which run well on CPUs and other which perform very well on gpus, the one that perform well on GPU tend to have task which can be paralelised extremely well and are intensive.
For instance a pixel shader program on a video game must be run on -every- pixel to determine the final rgb value of it, a 1920*1200 screen got 23,040,000 pixels, so instead of running the pixel one at a time at fast speed (what a cpu would do) you can run your program on slower but far more numerous shader units (my card a 9600M got 32 shader units so you could theoretically run 32 pixel at a time).

A few problems can use such massively parallel computing power, they tend to be the same problem for which super computer are bought. Folding@home is extract a massive amount of computing power from the gpu because the gpu is ideal for it and the whole simulation is run from the gpu (the cpu is loaded at 3-10% max)

Now the problem with that approach if that if a decision inside any of the shader has to wait for another shader before it's possible to start calculating, your toast because you'll have a lot of shader which will have to pause a moment to wait for other shader to complete.

X264 is a video encoding software, in an intra frame you must wait for each macro block that it's neighbors is done before you can start predicting and/or making choice about the type of prediction.

The more "choice" that depends on another portion of the program the encoder has to take, the more "linear" the program will be, the more unsuited it is for a GPU, reducing the number of choice the software has to make would make it faster and more paralelisable but would inherently make the software less efficient (if the software has to make a choice, I assume it got a good reason to make it).

There are a few portion of x264 that can be run in paralel, for instance Motion Estimation. However if you decide to run a -portion- of the program on the GPU and the rest on CPU, instead of going full GPU (which for the reason I listed above would be crazy), once the task the GPU has been assigned has been completed, you would have to wait for the result to be ferried back from the video card ram where cuda execute it's operation, back to the main memory ram. It's not much a question of "how much of those data can be transfered back per second" but "how long do I have to wait between the moment I instruct the card to ferry those data back and when is it usable by the cpu", the link cpu ram - video ram on a nehalem is RAM -ddr2- CPU -QPI- Northbridge -pciex16- GPU the latency is quite big in term of clock cycle wasted doing -nothing- since the cpu need to have those data in order to start crunching each frame.

x264 is basicaly slow because : the software run a lot of cpu intensive dsp function, but since those dsp function are building blocks of higher level (read : C) function which themselves are called in a fairly serial way, you can't run much of the program in paralel, each frame (save I frame) must wait for their previous neighbour to be complete, each macroblock depends on the macroblock from the previous frame or from the current frame macroblock to be dealt with (if you don't wait for them and run them all at once, you have to kiss goodbye to intra blocks...)

Bottomline : a lot of operation can't be run in paralel, and the current threading mode make the thread "wait" for relevant portion of other frame to be dealt with.

Now I'm not a programmer, and I don't play one on TV, so don't hesitate to rip me a new one if there is any bullshit in this.

Edit: Realized he just fed a 1 post cuda troller.

[bob0r]

r1373
mbtree+bpyramid -> flickerings
Only mbtree -> flickerings
Only bpyramid -> good

Same results with different patched builds

Got result file of that?

[MatLz]

Sorry...

As I've a super fast uploading (5kbytes/s :D) and as I was able to reproduce with the simple "authors" avisynth script, here is all:

http://www.sendspace.com/file/2i2xvr

[Dark Shikari]

Looks perfectly normal to me. Without weighted prediction, there's a certain quantizer threshold beyond which you'll get false skips in that clip. MB-tree just happens to go above that threshold at that bitrate. That's how it's supposed to work.

[LoRd_MuldeR]

Fix two bugs in 2-pass ratecontrol
last_qscale_for wasn't set during the 2pass init code.
abr_buffer was way too small in the case of multiple threads, so accordingly increase its buffer size based on the number of threads.
May significantly increase quality with many threads in 2-pass mode, especially in cases with extremely large I-frames, such as anime.

Was that a regression with one of the recent changes/improvements or a longstanding bug?

[Dark Shikari]

Fix two bugs in 2-pass ratecontrol
last_qscale_for wasn't set during the 2pass init code.
abr_buffer was way too small in the case of multiple threads, so accordingly increase its buffer size based on the number of threads.
May significantly increase quality with many threads in 2-pass mode, especially in cases with extremely large I-frames, such as anime.

Was that a regression with one of the recent changes/improvements or a longstanding bug?The first part was a regression, but probably didn't actually affect much. The second is a longstanding bug, as old as 2-pass itself, AFAIK.

[LoRd_MuldeR]

Thx for clarification :)

[chipzoller]

In the current build (1376), is the frame look-ahead type still unthreaded? Are there plans to also make this threaded?

[Dark Shikari]

In the current build (1376), is the frame look-ahead type still unthreaded? Are there plans to also make this threaded?It's been threaded for a couple hundred revisions now. It's not multithreaded, but it is in a separate thread at least.

Multithreading it might be tricky, as the results of the b-pyramid changes proved that a large speedup is gained in the lookahead by not doing motion searches that aren't necessary. However, if the lookahead was split up and all the searches done separately, there would be no real way to take that shortcut.

Of course, in some cases, it may be worthwhile to do redundant work if it means better parallelism.

[kemuri-_9]

In the current build (1376), is the frame look-ahead type still unthreaded? Are there plans to also make this threaded?

lookahead can have its own thread,
but as for multi-threading within it, no.

I've had ambitions of doing this for b-adapt 2, but the current framework is not very permitting for this kind of change.
I'd rather have threadpool get committed so i can utilize it here before attempting this again.

[chipzoller]

Sorry, I misspoke, I meant multithreaded, but DS answered my question. I suppose it isn't a huge loss not having it multithreaded, just that with more B-brames it becomes a significant bottleneck. If lookahead were multithreaded, what benefit, if any, would there be and at what cost?

[dwrbudr]

I was using very old x264 (r12xx) and before a couple of days I downloaded the latest r1376 from x264.nl and suddenly my encodes looks like this:

http://i.imagehost.org/0079/snapshot20091218131708.jpg (http://i.imagehost.org/view/0079/snapshot20091218131708)

x264.exe --pass 1 --bitrate 2368 --preset slow --threads auto --thread-input --tune film --sar 1:1 --output "C:\vts_11_1.h264" "C:\vts_11_1.avs"
x264.exe --pass 2 --bitrate 2368 --preset slow --threads auto --thread-input --tune film --sar 1:1 --output "C:\vts_11_1.h264" "C:\vts_11_1.avs"

The AVS is simple:

Mpeg2Source("c:\vts_11_1.d2v")
LanczosResize(720,400,0,0,-0,-0)

This happens to ALL encodes using different sources and resolutions.

I've tried to play it using CoreAVC 1.9.5 and KMPlayer's internal H264 decoder.

Since I don't use any fancy settings why is this garbled output from x264? Which older and stable version do you recommend?

[wyti]

you only need a updated decoder, try one of the latest ffdshow build, or wait for coreAVC 2.0

[Fr4nz]

[...]

Since I don't use any fancy settings why is this garbled output from x264? Which older and stable version do you recommend?

New x264 revisions work correctly, culprit are your old decoders that don't support correctly new x264 weight-p functionality.

Use an updated h264 decoder (for example, latest ffmpeg-tryouts works flawlessly).

[aegisofrime]

Dark Shikari et al of the x264 development team:

What plans do you have for x264 for 2010? 2009 has been an amazing year of development and I'm eager to hear what's in store for us! :thanks:

[LoRd_MuldeR]

Dark Shikari et al of the x264 development team:

What plans do you have for x264 for 2010? 2009 has been an amazing year of development and I'm eager to hear what's in store for us! :thanks:

It seems you totally missed those posts :p

http://forum.doom9.org/showpost.php?p=1356595&postcount=2833

http://forum.doom9.org/showpost.php?p=1358877&postcount=1

[aegisofrime]

It seems you totally missed those posts :p

http://forum.doom9.org/showpost.php?p=1356595&postcount=2833

http://forum.doom9.org/showpost.php?p=1358877&postcount=1

Actually I did see them :p Just wondering if there's anything else on the cards ;)

[Chengbin]

Actually I did see them :p Just wondering if there's anything else on the cards ;)

DS won't budge, as it would cause problems like "OMG, it's 2011 and xxx things are still not done". We've seen that with the weighted P frame project.

By not telling us the schedule allows them to be flexable. For example, if somebody paid them to do x project now, they can delay whatever it is they're working without "consequences". Or they feel that another project is more important, etc,etc.

Also, there is always a surprise factor!

[Dark Shikari]

Dark Shikari et al of the x264 development team:

What plans do you have for x264 for 2010? 2009 has been an amazing year of development and I'm eager to hear what's in store for us! :thanks:The biggest goal we have is to create a general-purpose ffmpeg replacement.

The goal is to make x264cli into a Just Works program that can take any input, deinterlace/ivtc it as necessary, resize it, and re-encode the audio and video. The plan is not to create something with the flexibility of ffmpeg, but rather something that Just Works as much of the time as possible. It will not be intended for the most advanced users.

The primary intended users here are threefold:

1. With an x264 that Just Works, making a good GUI becomes trivial.
2. With an x264 that Just Works, running massive batch encodes becomes far easier: Youtube-alike websites will love it.
3. With an x264 that Just Works, most "normal" users will be able to simply use "x264 inputfile -o outputfile" and get the results they want, even if the input file is interlaced or hybrid or whatnot.

[nakTT]

The biggest goal we have is to create a general-purpose ffmpeg replacement.

The goal is to make x264cli into a Just Works program that can take any input, deinterlace/ivtc it as necessary, resize it, and re-encode the audio and video. The plan is not to create something with the flexibility of ffmpeg, but rather something that Just Works as much of the time as possible. It will not be intended for the most advanced users.

The primary intended users here are threefold:

1. With an x264 that Just Works, making a good GUI becomes trivial.
2. With an x264 that Just Works, running massive batch encodes becomes far easier: Youtube-alike websites will love it.
3. With an x264 that Just Works, most "normal" users will be able to simply use "x264 inputfile -o outputfile" and get the results they want, even if the input file is interlaced or hybrid or whatnot.
That sounds like a very, very good new year resolution. Keep up the good work.

By not needing avisynth or whatever, is that means in time we will be able to run x264 64bit natively (without pipe or the like)?

[LoRd_MuldeR]

By not needing avisynth or whatever, is that means in time we will be able to run x264 64bit natively?

You can do that already with current x264! Either by using 64-Bit Avisynth or by using raw YUV files as input.

Also when piping the input data into 64-Bit x264 from a separate 32-Bit process, the 64-Bit x264 process still runs natively!

Anyway, with the upcoming changes you won't depend Avisynth anymore, so you can open the source file (e.g. MPEG or MKV files) with x264 (32-Bit or 64-Bit) directly.

Still you will need to use Avisynth for more advanced filtering/processing. So you cannot always get rid of Avisynth!

[Dark Shikari]

That sounds like a very, very good new year resolution. Keep up the good work.

By not needing avisynth or whatever, is that means in time we will be able to run x264 64bit natively (without pipe or the like)?Correct.

[nakTT]

You can do that already with current x264! Either by using 64-Bit Avisynth or by using raw YUV files as input.

Also when piping the input data into 64-Bit x264 from a separate 32-Bit process, the 64-Bit x264 process still runs natively!

Anyway, with the upcoming changes you won't depend Avisynth anymore, so you can open the source file (e.g. MPEG or MKV files) with x264 (32-Bit or 64-Bit) directly.

Still you will need to use Avisynth for more advanced filtering/processing. So you cannot always get rid of Avisynth!
Thanks Lord, for a very helpful explaination.

1) For me I just using resize function to downsize from 1080p to 720p and in rare cases I will use crop function. That is what I normally do.

2) As for 64bit thingy, actually I'm hoping to be able to enjoy full benefit (whatever it is) of x264 64bit over 32bit version.

3) Does Avisynth 64bit has what it takes (64bit filters and all) for me to accomplish (1) task?

4) It is my intention to get rid of my Vista Business 64bit (no offense to MS lover) from my main encoding PC and replace it with Linux Mint 64bit. Will this new changes planned for x264 would eventually make it possible for me to finally switch to Linux?

Thank you in advance, Lord.

:thanks:

[nakTT]

Correct.
Thanks for the confirmation.

Looking at x264 git, we haven't seen any update for a while now. I just somehow knew that you are up to something special for the new year. Damn glad I was right. :D

:thanks:

[LoRd_MuldeR]

1) For me I just using resize function to downsize from 1080p to 720p and in rare cases I will use crop function. That is what I normally do.

2) As for 64bit thingy, actually I'm hoping to be able to enjoy full benefit (whatever it is) of x264 64bit over 32bit version.

3) Does Avisynth 64bit has what it takes (64bit filters and all) for me to accomplish (1) task?

4) It is my intention to get rid of my Vista Business 64bit (no offense to MS lover) from my main encoding PC and replace it with Linux Mint 64bit. Will this new changes planned for x264 would eventually make it possible for me to finally switch to Linux?

1) It seems x264 will be able to accomplish those tasks without Avisynth in the near future (not at the moment).

3) Yes. But some more "exotic" plugins may not be available as 64-Bit versions, so you cannot use all plugins with 64-Bit Avisynth. All the basic stuff works, of course.

4) Yes. There's no "native" Avisynth on Linux yet, but because of (1) it will be more easy/convenient to use x264 on Linux (without Avisynth), I think.

[nakTT]

1) It seems x264 will be able to accomplish those tasks without Avisynth in the near future (not at the moment).

3) Yes. But some more "exotic" plugins may not be available as 64-Bit versions, so you cannot use all plugins with 64-Bit Avisynth. All the basic stuff works, of course.

4) Yes. There's no "native" Avisynth on Linux yet, but because of (1) it will be more easy/convenient to use x264 on Linux (without Avisynth), I think.
Thanks again for your (trademark) very informative explanation.

:thanks:

[nm]

4) It is my intention to get rid of my Vista Business 64bit (no offense to MS lover) from my main encoding PC and replace it with Linux Mint 64bit. Will this new changes planned for x264 would eventually make it possible for me to finally switch to Linux?

What's stopping you now? I don't think that using x264 on Linux is particularly difficult if you only need simple resizing and cropping. Both ffmpeg and MPlayer/MEncoder do that and piping the video to x264 is pretty simple, if you don't want to use libx264 through ffmpeg or MEncoder. If you need AviSynth for some more complex processing, there's Wine and avs2yuv.

[nakTT]

What's stopping you now? I don't think that using x264 on Linux is particularly difficult if you only need simple resizing and cropping. Both ffmpeg and MPlayer/MEncoder do that and piping the video to x264 is pretty simple, if you don't want to use libx264 through the encoder frontend. If you need AviSynth for some more complex processing, there's Wine and avs2yuv.
Many thanks for the reply, nm.

I have heard about people using x264 on Linux but for me, I don't think I have technical prowess up to that level (it sounds a bit too challenging for me). Please note that I'm just a GUI user (MeGUI for my serious encoding and ASXGui for testing).

[aegisofrime]

Thanks for the reply Dark Shikari. What about improvements to speed and compressibility? I'm under the impression that the improvements you have started are on the usability front. Has x264 reached the boundaries of the H.264 specification?

[nm]

I have heard about people using x264 on Linux but for me, I don't think I have technical prowess up to that level (it sounds a bit too challenging for me). Please note that I'm just a GUI user (MeGUI for my serious encoding and ASXGui for testing).
How about HandBrake (http://handbrake.fr/) then?

[nakTT]

How about HandBrake (http://handbrake.fr/) then?
Thanks for the reply,

The main turn off for me to use Handbrake is because I can't use external audio encoder (in my case, nero AAC) for my video. Any idea on how to overcome this drawback? Thank you in advance.

:thanks:

P/S: Mod, please move my discussion (this one) to a new thread so that I won't disturb others in this thread.

[rallymax]

Hi All,
I hope this is the correct place to post.
Over in VideoHelp.com (Adobe Premiere - MainConcept's H.264 vs x264 open source encoder (http://forum.videohelp.com/topic372349.html#2000141)) I've been posting about how I'm making an Exporter for Adobe Premiere (since the bundled Main Concept (consumer level) H.264 encoder is AWEFUL - see example here - http://forum.videohelp.com/topic371339-120.html#1999573). Anyhow I'm using x264 and am very excited that you've added slice support since I started. - yippee legal AVCHD and Bluray!

I was planning on simply taking my gui settings of the "preset", "tuning", "profile", "datarate" etc etc etc and pushing them to a slightly modified x264.c's Parse( ) function and then implement the required inbound file functions...
/* input file operation function pointers */
int (*p_open_infile)( char *psz_filename, hnd_t *p_handle, x264_param_t *p_param );
int (*p_get_frame_total)( hnd_t handle );
int (*p_read_frame)( x264_picture_t *p_pic, hnd_t handle, int i_frame );
int (*p_close_infile)( hnd_t handle );
...to get the frames from Adobe but..... it seems easier for me to do the for(frame x to y) loop in Adobe and call the x264 encoder_encode function instead of being lazy with the use of Parse() and Encode(). But.... I don't know what "nal"s are or any of the other elements in Encode()'s for loop. I was hoping that someone could post a brief description of how to interface to the libx264 directly or Private Message me instead.

..or am I better off staying on the path I'm on and forcing a lot of colorspace conversion (RGBA4444 @ BT.601 -> BT.709 -> YUV12 MPG Planar) inside each p_read_frame( ) call?

Much appreciated.

I guess I'm asking how do I use the library directly instead of leaning on Encode() and Encode_frame()...


static int Encode( x264_param_t *param, cli_opt_t *opt )
{
...snip...
/* Encode frames */
for( i_frame = 0, i_file = 0; b_ctrl_c == 0 && (i_frame < i_frame_total || i_frame_total == 0); )
{
if( p_read_frame( &pic, opt->hin, i_frame + opt->i_seek ) )
break;

pic.i_pts = (int64_t)i_frame * param->i_fps_den;

if( opt->qpfile )
parse_qpfile( opt, &pic, i_frame + opt->i_seek );
else
{
/* Do not force any parameters */
pic.i_type = X264_TYPE_AUTO;
pic.i_qpplus1 = 0;
}

i_frame_size = Encode_frame( h, opt->hout, &pic );
if( i_frame_size < 0 )
return -1;
i_file += i_frame_size;

i_frame++;

/* update status line (up to 1000 times per input file) */
if( opt->b_progress && i_frame % i_update_interval == 0 )
{
int64_t i_elapsed = x264_mdate() - i_start;
double fps = i_elapsed > 0 ? i_frame * 1000000. / i_elapsed : 0;
double bitrate = (double) i_file * 8 * param->i_fps_num / ( (double) param->i_fps_den * i_frame * 1000 );
if( i_frame_total )
{
int eta = i_elapsed * (i_frame_total - i_frame) / ((int64_t)i_frame * 1000000);
sprintf( buf, "x264 [%.1f%%] %d/%d frames, %.2f fps, %.2f kb/s, eta %d:%02d:%02d",
100. * i_frame / i_frame_total, i_frame, i_frame_total, fps, bitrate,
eta/3600, (eta/60)%60, eta%60 );
}
else
{
sprintf( buf, "x264 %d frames: %.2f fps, %.2f kb/s", i_frame, fps, bitrate );
}
fprintf( stderr, "%s \r", buf+5 );
SetConsoleTitle( buf );
fflush( stderr ); // needed in windows
}
}

[Dark Shikari]

If you're looking to write a demuxer/input module for x264, you should drop by #x264dev on Freenode; we've basically rewritten the entire input framework so it would be a bit silly to try to write one for the old framework now.

Also, in the meantime, you could just export to a HuffYUV AVI file and then encode with x264 after that.

[creamyhorror]

Good to see you here, rallymax. Hope you don't have to discard too much of your work :S

[Dark Shikari]

OK, this will be more complicated. To make a plugin, you can't extend the CLI, you have to write your own code.

If you want to be able to export both video and audio muxed to a file, you'll need:

libswscale (RGB->YUV conversion)
libx264 (h264 encoding)
libavcodec, libvorbis, libmp3lame, or some other audio encoder
libavformat, gpac, or some other muxer

It wouldn't be too hard--just a game of tying together a bunch of existing libraries--and would probably be a good introduction to them in general.

[rallymax]

Thanks Dark'.
I didn't know about libswscale so that will help a lot.
I'm going to skip audio for now. Muxing it doesn't really help the workflow because you can export audio only from Premiere already. The DVD/BluRay authoring tool "Encore" supports dropping separate audio and video files together so I'll leave it to handle the muxing.

My challenge now is to understand what is required to take the H.264 stream and put it into the most basic of containers.

From what you wrote it looks like I should use libavformat to make it into an AVI etc.

thanks for the help over on the IRC and here.

[Dark Shikari]

Thanks Dark'.
I didn't know about libswscale so that will help a lot.
I'm going to skip audio for now. Muxing it doesn't really help the workflow because you can export audio only from Premiere already. The DVD/BluRay authoring tool "Encore" supports dropping separate audio and video files together so I'll leave it to handle the muxing.Wait, if you don't intend to include audio, why do you need to mux the H.264 at all?My challenge now is to understand what is required to take the H.264 stream and put it into the most basic of containers.

From what you wrote it looks like I should use libavformat to make it into an AVI etc.H.264 doesn't go in AVI. I'd use one of the following:

libavformat for mkv or mp4s
gpac for mp4 (see x264's mp4 output module for an example)
x264's matroska.c for mkv (see x264's mkv output module)
libmp4v2 for mp4

[rallymax]

I guess I'm confused then - re no need to mux.
I was of the understanding that if I take the output stream of libx264 and dump it into a file that it would not be openable by most programs. It would need to be containered in something like mp4 first.

[Dark Shikari]

I guess I'm confused then - re no need to mux.
I was of the understanding that if I take the output stream of libx264 and dump it into a file that it would not be openable by most programs. It would need to be containered in something like mp4 first.This is true, it would be a nice convenience to mux it first, even though the user will have to remux it with the audio himself later.

[kieranrk]

The DVD/BluRay authoring tool "Encore" supports dropping separate audio and video files together so I'll leave it to handle the muxing.


Couldn't you do the audio first then let your plugin read that in for muxing? (I assume you can't access the audio exporting from the plugin API?) Also the ts muxer I'm writing could easily write the AVCHD structure (not sure about Blu-ray though) whereas the one in libavformat is very broken.

[rallymax]

kieranrk, thanks for the offer (ie AVCHD file structure).
I know that I'm going to use Encore to make my menus etc so I'm happy to have the plugin only output H.264 for now.

The Adobe API does provide audio as well, I was simply ignoring it because the provided MP3 or Dolby Digital exporters work fine. It's the Main Concept H.264 encoder that is so horrible that I've decided to put the time in to make a new Export plugin using x264. As many have said, I could simply export to an intermediate like HuffyYUV but I'd like to make the workflow for myself (and the less-technical friends that I'll give the plugin to), as simple as possible.

If I can add a plugin that has a dialog box with basic buttons for AVCHD or BluRay legal output as well as a file size estimate as a % of the disc space then it's basically idiot proof. I'm not going to take care of things like resize since you should do that in the project itself.

Unfortunately having just looked at the libswscale libarary it doesn't look like there is a RGB->YUYV->YUV12planar conversion path. I'll keep looking.

I also just looked at the libavformat and it doesn't seem very easy to understand how you take the output of the encode and stuff it into that library to get a mux'ed mp4 file. I'll keep looking though.

Sure is a shame that the x264VfW project died - they have done this all already and more generically. I'm only doing it a dedicated plugin because I know the Adobe API quite well (vs VfW or DirectShow or Media Foundation).

[Dark Shikari]

Unfortunately having just looked at the libswscale libarary it doesn't look like there is a RGB->YUYV->YUV12planar conversion path. I'll keep looking.There's an RGB->YV12 planar conversion path, unless you meant "RGB is planar too".

[rallymax]

can you point me to it. I found the declaration

rgb2rgb.c # 74
void (*rgb24toyv12)(const uint8_t *src, uint8_t *ydst, uint8_t *udst, uint8_t *vdst,
long width, long height,
long lumStride, long chromStride, long srcStride);
but couldn't find the implementation anywhere. Is it created as a part of the template magic that's happening in rgb2tgb_template.c (I haven't got my head around all that name casting yet).

[rallymax]

never mind. grep'ed and found all the references. I'll try to get my head around all that renaming stuff

[Dark Shikari]

can you point me to it. I found the declaration

rgb2rgb.c # 74
void (*rgb24toyv12)(const uint8_t *src, uint8_t *ydst, uint8_t *udst, uint8_t *vdst,
long width, long height,
long lumStride, long chromStride, long srcStride);
but couldn't find the implementation anywhere. Is it created as a part of the template magic that's happening in rgb2tgb_template.c (I haven't got my head around all that name casting yet).Again, like with x264, you don't seem to understand the concept of an external API.

You only call swscale though the swscale functions in swscale.h. You should never look at any code inside swscale for any reason.

The functions you need are:

sws_getContext
sws_scale
sws_freeContext

Nothing else.

[rallymax]

Thanks Dark. wise words.
You just saved me A LOT of time :)
you wouldn't happen to know which of the many functions you need to use in avformat.h would you?
It seems that it's similar needing
avformat_alloc_context
but then it gets a little blurry about what you would do next. - And I can't seem to find an example.

[rallymax]

I found a swscale and avformat example. I should be good to go now.
ffmpeg\output_example.c

[rallymax]

Hi all,
if I'm supposed to use encoder_encode() and the x264 example shows in Encode() and Encode_frame() that after the encoder_encoder() it then calls the encoder_nal_encode()..... then..... can someone explain to me what a "nal" is? It's a little hard to get over the learning curve/hump when you suggest I don't look at the src doing the actual work and only use/look at the external api. It's really hard coz there are no docs or newbie-level commented examples on what required to use the library. x264 isn't the only culpret. the libavformat is equally as confusing. 'fortunately the output example using swscale and avformat gives up most of the secrets.
sorry if it sounds like I'm complaining. I'm just frustrated.

[LoRd_MuldeR]

I don't think you are supposed to call encoder_nal_encode() from "outside" when using the libx264 library.

At least not in up-to-date x264. It used to be a "public" function, but it is no longer after this API change was applied:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff;h=031e25d8cc909af2d138f9fedc8252961f34a6ac

"NAL" refers to "Network Abstraction Layer". The H.264 specs say:
NAL unit: A syntax structure containing an indication of the type of data to follow and bytes containing that data in the form of an RBSP interspersed as necessary with emulation prevention bytes.

[rallymax]

I'm getting the feeling that I should "borrow" from the Encode() / Encode_frame() example since it shows how to open the encoder then process pictures and then dump the *pic to whatever you want. I want mp4 container so I'm going to use the implementation that's already there.