x264 patch: gpac 0.4.x compatibility

[superdump]

I have written a patch to convert x264's gpac support to 0.4.x. From 0.3.x to 0.4.x the API changed and as such some functions, variables, etc needed renaming in x264. This patch should work but before it is committed we will need to have thorough testing of both gpac 0.4.x and this patch, so please test them and give feedback if you have any problems.

You can download the patch here. (http://www.swains.plus.com/x264/patches/x264_mp4_output_gpac_04x_update.0.diff)

I would also like to know if you can compile gpac under MinGW, preferably not just the lib but the whole thing.

[celtic_druid]

http://mirror05.x264.nl/celtic_druid/force.php?file=./x264.revision291.gpac0.4.7z

Worked fine in my limited testing.

About compiling gpac, I usually just run make lib, which works fine. I just tried then and had some issues with some of the plugins. Nothing that couldn't be fixed though I don't think.

[leowai]

I would also like to know if you can compile gpac under MinGW, preferably not just the lib but the whole thing.
Thanks. Great Work!

Well, compilation works ok for me under MinGW, gcc-4.0.1, gpac v0.4.1 Dev.

A quick test works fine.

Wondering if this patch would eliminate the suspected "bug" in gpac v0.3.x for fps at 23.976 . (http://forum.doom9.org/showthread.php?t=98680)

Besides, I observed a smaller x264.exe with gpac v0.4.1.Dev (617KB) than v0.3.1.Dev (~646KB). :)

[Sirber]

Wondering if this patch would eliminate the suspected "bug" in gpac v0.3.x for fps at 23.976 . (http://forum.doom9.org/showthread.php?t=98680)Same wonders here... :)

[superdump]

I haven't done anything to approach that issue as it was not my goal. If it's a problem in gpac and not x264 and 0.4.x fixes it then whoopee, but otherwise... sorry. :)

Thanks for the feedback thus far. Please keep testing! :D

[Sharktooth]

My new builds (from 291A on) include your patch.

[bond]

ok, i made some quick tests with a 25fps source and the new .mp4 output and it seems to work great outputting perfect files :)

[Sharktooth]

bond, the gpac0.4.x support patch has been submitted to the SVN some days ago.

[bond]

yep, i tested r305, just wanted to be sure myself everything works fine

[bob0r]

Now all we need is 29.97 fps fix :D

@doom9 below:
Roger that

[Doom9]

it has nothing to do with 29.97 fps.. it has something to do with insane dwscale and dwrate values that x264.exe cannot handle. A proper 29.97fps source is no problem, neither is a proper 23.976 source..

[eMotionEstimation]

static int set_eop_mp4(hnd_t handle, x264_picture_t *p_picture)
{
mp4_t *p_mp4 = (mp4_t *)handle;
uint32_t dts = p_mp4->i_numframe * p_mp4->i_time_inc;
uint32_t pts = p_picture->i_pts;
int offset = p_mp4->i_init_delay + pts - dts;
...


The problem is that "dts" and "pts" are soo short (only 32 bits) - if "i_time_inc" (==scale) is very big 32 bits are not enough to hold the information. This could be easily fixed, but...

...
p_mp4->p_sample->IsRAP = p_picture->i_type == X264_TYPE_IDR ? 1 : 0;
p_mp4->p_sample->DTS = dts;
p_mp4->p_sample->CTS_Offset = offset;
gf_isom_add_sample(p_mp4->p_file, p_mp4->i_track, p_mp4->i_descidx, p_mp4->p_sample);
...


"dts" is written into "*p_sample" which is of type "GF_ISOSample". And here really is the problem. "p_sample->DTS" is 32 bit, too. This can't be "fixed" without breaking mp4-specs (I think). So the only way around this is not to have such a big rate and scale. use nicefps or some other workaround.

wishes, Chris

[Doom9]

hehe, that's a pickle, isn't it?

[bond]

This can't be "fixed" without breaking mp4-specs (I think).why do you think so? :eek:

[eMotionEstimation]

"GF_ISOSample.DTS" is defined as int32 and I think that this (DTS only being 32 bits) is related to the MP4-Spec - and with that what's later written into the bitstream. But I might be wrong. I don't have enough time at hands to look into all this. But there are many ways around the problem.

chris

[bond]

i dunno what GF_ISOSample does, but i cant find it in the iso, mp4 and avc file format specs

[eMotionEstimation]

As I said, I'm not sure, too. Perhaps someone with more insight in the inner workings of GPAC and MP4-bitstream could help out here.

wishes, Chris