x264 ios settings?

[akropp]

I've been trying to generate a ios streamable file using the x264 library programmatically and not using ffmpeg or the x264 executable (I am on windows). I have an x264 dll compiled with the disable-gpl flag set. In general, video records and streams fine for me, but now I am trying to generate ios playable files.

The settings I am using when initializating the x264_param_t pointer are:


param->i_threads = X264_THREADS_AUTO;
param->b_deterministic = 1;

param->i_csp = X264_CSP_I420;

param->i_width = 640;
param->i_height = 480;

param->i_frame_reference = 1;

param->i_fps_num = 30;

param->i_level_idc = 30;

param->rc.i_rc_method = X264_RC_ABR;
param->rc.i_bitrate = 300;

param->rc.i_lookahead = 0;

param->b_repeat_headers = 1;
param->b_aud = 0;

applyProfile(param, "baseline");


There are no other settings after I apply the baseline profile. I wanted to mention that the "applyProfile" function does return 0. This is just a function pointer to x264_param_apply_profile by doing


applyProfile = (APPLY_PROFILE_PTR)GetProcAddress(dllModule, "x264_param_apply_profile");


When doing dynamic loading of the x264.dll that I built. I have it set up this way so I can drop in new dll's without having to recompile the solution.

My goal is to generate the most basic h.264 ios streamable file.

Using the settings above, the files I generate play just fine in VLC, and QuickTime player. The files are also valid in atombox studio, AtomicParsley and other applications (as far as I can tell). I've made sure the file sizes are small, the bitrate is small, and I've tried most of the suggestions I've heard about h.264 files not playing, but nothing works. I keep getting a play button with a line through it. I also have no idea if there is a way to get any debug information as to why the file wont' play.

I can tell that the sps/pps values between my files and ffmpeg generated files are not the same though, but I don't know how to map this to the internal x264 parameters. Short of those differences, for a while I thought that maybe it was header differences between how ffmpeg writes mp4 file formats vs how my own file saver formats the mp4 headers, but to remove any chances that invalid header atoms were causing problems I ran it through AtomicParsely. The ffmpeg file still works, and my file still does not work. This made me think that it was some sort of encoder setting?

Here are two files that I've generated:

http://thesummerwentwest.com/video/ (http://thesummerwentwest.com/video)

One (customVideo.mp4), is created by me.

The second video (ffmpegVideo.mp4) I created with the baseline profile, -refs 1 and -weightp 0.

I've been banging my head against this for a few days and figured I'd come to the experts to ask. If anyone has any clue or can maybe guide me in the right direction of where to look that would be amazing.

Thanks!

[xooyoozoo]

I'm not sure if you're using Baseline for just compatibility with very old iOS hardware, but the newer Apple SoCs can handle fairly excessive encodes. On my iPad, I regularly stream preset-veryslow ~20+ megabits high profile MP4s. If it ever comes with a Bluray drive, we'd be golden.

I doubt this will contribute much to the solution. Just thought this might help for other things. :)

[Guest]

Your ffmpeg file appears corrupted. It is only 50KB and won't open in anything.

Your custom file crashes DGIndexNV, which reports it has multiple atoms in stsd, when there should only be one.

I wanted to compare the two, but with the ffmpeg one being messed up I am unable to go any further.

[akropp]

Neuron2, I am a fool and didn't set the ftp upload to 8-bit binary hence the busted videos. I've reuploaded them (and downloaded them to test again). Thanks for helping, I appreciate it.

Edit:

While the file was legit corrupt (since it didn't upload properly), the 50kb file size is actually right. The video is just a rendering of one png image with no movement for 30 seconds. The other video is from a webcam of my living room wall. I know the frame content isn't the same, but I was going more for encoding settings than content. I figured the content was irrelevant? If it isn't, I can probably generate something from the same sequence

[akropp]

xooyoozoo, I'm using baseline right now just to eliminate any difficulties. Once I get this to work I'll try better profiles. Thanks!

[Guest]

Your custom file includes free space atoms in ...stbl:stsd, which you should not do. Check your MP4 muxing code.

[akropp]

Ok cool, thanks. Are there any other restrictions to free atoms I should be aware of or is it just stsd? The custom file has free atoms kind of all over the place, I want to make sure I remove all of the ones that would interfere with ios playback

Short of the free space atoms is there anything else that could cause it to not play? I just want to make sure I have as much info as possible so I can tackle the problem tomorrow

[Guest]

I can only tell you why my tools and parsers have trouble with your file. In general, for better playability across devices, you should closely adhere to specifications. Let's begin by adhering to the spec regarding free atoms in stsd and see what happens.

[akropp]

Sounds like a plan. Do you happen to know where I can find the spec on where free atoms are valid or not? I was under the impression that they were valid everywhere and would be ignored, but I guess that's not the case.

Edit:

Found the spec, it says:


8.1.2.1 Definition
Box Types: ‘free’, ‘skip’
Container: File or other box
Mandatory: No
Quantity: Any number
The contents of a free-space box are irrelevant and may be ignored, or the object deleted, without affecting
the presentation. (Care should be exercised when deleting the object, as this may invalidate the offsets used
in the sample table, unless this object is after all the media data).


I didn't see in the spec for stsd any exclusion of free atoms? I don't doubt that its irregular, but I'm just trying to figure out where it would have problems so I can change the muxing code to work better.

The file I have has free atoms in all the stbl atoms because the header is pre-allocated for a max recording time. Then, every time an stco chunk is written, the mux code updates the stbl atoms with the latest information (unlike other muxers that write everything at the end). This way if the machine crashes or the process dies in the middle of recording you still have a playable file even if the file wasn't closed properly.

If the stsd is the only atom that is going to cause problems with a free atom that's an easy fix. I'm hoping that free atom's in the other atoms aren't also causing issues though.

[Guest]

After reviewing the spec, I agree that free atoms are legal everywhere according to the spec.

On the other hand my parser complains about it, and it's a difference versus your ffmpeg file. So it's worth trying to remove it. All these free space boxes waste space anyway; why are they there?

If that does not improve things then we can look at other things.

[akropp]

Neuron2, the free atoms are there to preserve header space for dynamically writing the header as the file is being written to. This way as the file grows we can rewrite the headers in the pre-allocated space. If the process dies or the machine is turned off in the middle of encoding then the file is still valid. For example, with ffmpeg if you are encoding and you kill the process (without giving it a signal interrupt) the file is totally hosed. With my muxer the file would still be ok.

Part of me had hoped that it wouldn't be these free atoms since having this reliability for my application is pretty integral, but I can try removing them as a test to see if that does let the file play.

Tomorrow I'll try writing a tool to strip out the free atoms and see what happens. If that does work then that'll be an OK solution for me, to post process the files after the fact to remove the free atoms to make them mobile friendly.

Thanks for the help, and I'll report back with results!

[akropp]

Neuron2, I wrote a tool to extract out the free atoms from my header file and now the file plays on my iphone! Thank you for helping I really appreciate it!

[Guest]

Glad to hear that it is working for you and happy to be of assistance! And thanks for updating us on your status.