Log in

View Full Version : First impressions, first questions


darkyp
16th June 2008, 18:35
Hello everyone,

I've just recently started using x264 for a non-stop realtime recording system. I'm using it currently through the x264vfw (tried ffdshow as well) as the system's working under MS Win XP OS. So far I've used XviD mostly because of x264 higher cpu usage and realtime requirements. Now I have a better cpu and modified the my software a bit so that it uses x264 as well. Have to say that I was greatly impressed bye the quality / bitrate (file size) ratio.

To everyone of the developers - thanks for making this available as an open source project!

Now, some questions from me. Basically I have a MS DShow graph with capture - my filter - x264 - avi mux - filewriter. If I try to deliver samples to x264 from a different thread an exception is thrown from the x264 address space. This occurs both using x264vfw and ffdshow vfw. When using XviD this will not occur.

My second question, that I found out has been asked a couple of times here though with no definite answer is: is it possible to force a given frame to be an IDR (real Keyframe) when being sent to the encoder? With XviD I found out my own way of doing it and it is working properly. The necessity of having this functionality for me is that at every half an hour or one hour (precisely +/- 2 or 3 frames) I have to start creating a new AVI file - thus it should start with a key frame; morover I do not stop the capture (encoding) graph - I simply change to which file writer graph the frames should go - thus no missing frames between consecutive AVI files.

So far I've tried changing the i_keyint_min before sending a sample hoping to fall into this part of the encoder.c code:

else if( i_gop_size >= h->param.i_keyint_min )

Well it is a working solution but not quite stable as my changes are not synchronized in any way with x264 code and sometime exceptions occur (I suppose due to multithreading and unsychronized access).

Something interesting as well for those still fighting VFW and directshow - it is not possible (at least I think so) to use IAMVideoCompressDialogs.SetState to apply vfw codec settings. In order to do it I did quite a research and found no answers. Finally reversed (disasm) a bit qcap.dll just to find that every time one calls SetState, MS opens the driver, sends the message and then closes the driver!? What do we set these settings using SetState then? If anyone's interested, I'll post my solution to this problem.

Hope I will find a solution to my keyframe problem here as well.

Thanks!

Dark Shikari
16th June 2008, 18:41
It sounds like you might be better off tossing Video for Windows here, especially given that x264 VfW is not maintained officially anymore. Either way, make sure you're using a recent version; the versions of VfW floating around (since they're not officially maintained) are often absolutely ancient.

You might be better off making an application that calls the libx264 library directly rather than using such an outdated (and often hackneyed) interface.

darkyp
16th June 2008, 18:49
OK, what about the one integrated in ffdshow?

darkyp
16th June 2008, 18:50
I got this one from sourceforge project x264vfw: 13_870bm_13659_fixed from June 5, 2008 .

LoRd_MuldeR
16th June 2008, 19:05
I got this one from sourceforge project x264vfw: 13_870bm_13659_fixed from June 5, 2008 .

This is the latest VfW build of x264 available and it's pretty much up-to-date. It's not maintained officially though...

OK, what about the one integrated in ffdshow?

ffdshow uses the VfW interface too, at least for encoding. So there's not much difference to x264 VfW.

The only alternatives to VfW are: Run x264.exe from the commandline (like MeGUI) or call the libx264.dll directly (like Avidemux).

darkyp
16th June 2008, 19:10
No problem if it is not supported as long as it works :) I do not think I have any alternatives to using x264 in directshow, or am I wrong? I mean a ready filter not having to write a wrapper for the library.

Anyway forget about VFW. What if I write my own wrapper filter to using the library. For example I can compile x264vfw with having more functions exported from the dll and use them instead of the VFW interface. How can I force a frame to be encoded as an IDR one?

sorry, did not know about libx264.dll

LoRd_MuldeR
16th June 2008, 19:18
I think you could create a DirectShow encoder based on libx264.dll (VfW won't be needed), but you'd have to code it yourself.
Calling the libx264.dll directly from your app (without using DirectShow) might be the easier way and avoids dependency on DirectShow...

darkyp
16th June 2008, 19:26
I think you could create a DirectShow encoder based on libx264.dll (VfW won't be needed), but you'd have to code it yourself.
Calling the libx264.dll directly from your app (without using DirectShow) might be the easier way and avoids dependency on DirectShow...

Yes, already agreed on this one.

And about IDRs? :) What should I do?

Dark Shikari
16th June 2008, 19:50
Yes, already agreed on this one.

And about IDRs? :) What should I do?I'm pretty sure that when you pass in frames to libx264 you can choose the frametype; I think the default is FRAME_TYPE_AUTO or something like that, but you could also theoretically declare a frame to be IDR.

I don't have much experience using the library externally though, so I might be wrong.

Sagittaire
16th June 2008, 21:56
Yes, already agreed on this one.

And about IDRs? :) What should I do?

I think that Iframe are IDR by default with x264.exe ...

darkyp
17th June 2008, 07:12
I think that Iframe are IDR by default with x264.exe ...

I'll be using it from my program streaming from a capture device to libx264.dll. So no x264.exe here.

Dark Shikari
17th June 2008, 07:27
It appears that currently x264 does not obey input frametypes unless you use no scenecut and no b-adapt.

Fortunately, this patch (http://trac.handbrake.fr/browser/trunk/contrib/patch-x264-idr.patch) apparently fixes the problems for IDR frames.

darkyp
17th June 2008, 15:12
It appears that currently x264 does not obey input frametypes unless you use no scenecut and no b-adapt.

Fortunately, this patch (http://trac.handbrake.fr/browser/trunk/contrib/patch-x264-idr.patch) apparently fixes the problems for IDR frames.

Thanks for pointing this out to me. As I have no experience compiling x264, moreover under windows, moreover with the vfw interface, I decided to load the x264vfw.dll dynamically and to patch it in the memory space of my software. So far it is working as expected.

Thanks again!