x264 and MP4 compatibility

[dumbuser]

For some time when I was beginning to use x264 I could not get Quicktime compatibility. I went through a testing period to see the range of options I could and couldn't use and am now making very reasonable QT files that are fully compatible to every decoder I have tested. The key is, what I have now read here and that is, don't go into High Profile or over 2 B frames.

During this process I also realized what I have heard many say or imply here in the pages of the doom9 forum. QT is just not a good player and or representation of h.264

Recently I tried frame serving from avs to Avidemux in mean's latest preview 3, muxed the resulting x264 using his MP4 container and then muxed the audio and video with MP4Box as Avidemux is still not finished. The resulting file is the best h264 QT compatible file I have seen to date. Even when you pull down the Movie Info.. it's correct. Something I have never been able to do using x264's .mp4 also some of the artifacts I have been blaming on QT seem to have vanished.

It seems at one time it was possible to take raw .264 or .h264 mux it through MP4Box and end up with compatibility. This will not happen today with all the latest versions (builds). However, using x264's internal muxer you do get kinda sorta some compatibility. The same end result is present with MP4Creator and these 2 muxers do not seem to be the source of the problem. The source of the problem seems to be x264's output selection IE (raw) .264 and or .mp4

Now, by comparison to others here I'm relatively new and most certainly do not have the experience or expertise. But I do know I have reasonable well exhausted the possibilities of combinations in tests and I keep coming back to the same issues.

If I were a programmer and had those resources within my grasp I would:

1. Start up a dialog with mean regarding his mp4 muxer to see how he got full compatibility. It goes a little further than what I described here as the resulting files were also a bit smoother using other players like MPlayer and VLC beside using Dshow's CoreAVC or Nero which also showed improvement.

2. Look at the source code to see if these modifications and or changes could easily be implemented into x264

3. Try to fined out why raw is problematic using another MP4 muxer when it comes to compatibility.

I hope I'm not being to forward here and most certainly have respect for all the people who have and are contributing to making x264 better. So any or all comments are welcomed along with your experiences on this topic and or suggestions.

[GodofaGap]

I'm sorry, but I don't think anyone can be of much help to you if you don't report version/revision numbers of the tools used (and where you got them), commandlines used to produce the files and players that showed the problem. A sample file never hurts either. The way you have written your post no one can exclude human error on your side, because no one really knows what you did in the first place.

[dumbuser]

Well, Part of this seem to be an error in thinking by a dumbuser :)

After writing the original post it seemed reasonable that if mean's mp4 muxer was truly better then doing a complete encode using avidemux without avsproxy should yield the same results and it didn't. Won't say that it was better or worse than the same settings in Staxrip or MeGUI. Just that it was not the improvement I originally saw. So I went back to the frame service. But when I finished the mux, it too was about the same and I became real confused for several hours while I ran more tests. I figured this couldn't be a one time mistake as I still had the sample I liked and it is better.

Most of us think about sound for picture and all of the programs we use do work in this manor. IE the sound is added to the picture. In the traditional sense for film sound locked to picture. But in computers and all digital media, picture locks to audio. So I decided to mux the audio first and add picture to it and it worked. I must have been tired when I did that sample. But this mistake has allowed the answer I was looking for. As I'm writing this a sample is running to try the same thing with x264 raw. When it finishes I will try the same kind of finishing technique.

It will be interesting to see the finished product on a few other machines to see if this is just a bit of improved jitter on my machine or if it holds up. The jitter is very low on this machine by comparison to others I have seen. But there is always the possibility of error in equipment that does NOT employ PLLs. :P

[dumbuser]

The end of this story is not going to come easily! The raw output of x264 build 590 is NOT working correctly. So I would need to sort back through the builds to see where it stopped working. VLC will not play the raw file and it always has in the past. QT believes the file is 25fps after muxing and it's not, even when I tell the muxer what it really is. I'm not sure I can go back 3 builds and most of the devs don't keep them. So it is going to require a developer to sort this one out. :(

BTW I did confirm with a hex editor the order of the mux should anyone care at this point.

[foxyshadis]

Previous builds:
http://x264.nl/x264/

[GodofaGap]

@dumbuser: You still don't provide any info to recreate the behaviour.

[dumbuser]

I'm running the x264 cli build 590 from a batch file. The source is an animation done at 29.9 and a had a real 2-3 puldown applied (23.976). The sample was built from the original m2v and built up as a vob so I wouldn't need to think about sound sync or lengths or FPS. The sound track is from the original DTS 5.1 track done as aac using ND as 128 cbr LC stereo. The avs was used to make (what I consider to be) simple corrections only. The command line for x264 is:

x264.exe --progress --no-psnr --thread-input --scenecut 40 -I 240 -i 24 --threads 1 --me umh --merange 16 --sar 1:1 -r 5 --nr 0 -f 1:1 -b 2 --direct "spatial" --b-bias 0 --ipratio 1.400000 --pbratio 1.300000 -A p8x8,p4x4,b8x8,i4x4 -B 700 --qpmin 10 --qpmax 51 --qpstep 4 --qcomp 0.600000 -m 6 --b-rdo -o "D:\test\LS2 raw.264" "D:\test\LS2.avs"

As you should see the commands will yield a QT compatible file.
I can post the avs file if anyone is interested as the source is a compressed m2v HD at a real resolution of 854x480 and I'm making it 480p (848x480) 1:1.78 while maintaining the original aspect ratio. But this really shouldn't make a difference if you want to reproduce the things I am seeing.

The second time the batch file was run (no changes) the resulting raw file worked and was playable in VLC. MP4box needed to be told the frame rate as players believed the file was 25fps. The raw 264 file was muxed into a mp4 first then for the final mux the sound was muxed first and then the video in MP4Box. The resulting MP4 was not playable in QT but did yield the results that I originally saw in other players. I'm now running a x264 MP4 version and will try that in muxing the final version. Sound first of coarse. Hope this gives everyone reading this enough detail. If not please ask. :)

Edit:

The resulting file (x264 MP4) after muxing the sound first using MP4Box and then the video was playable in QT and every other player I tried (Mplayer, VLC, MPC etc. and did yield the results I first saw. Complete compatibility! :) The question that remains is why am I having problems with the RAW output of x264???

[Sharktooth]

Craptime is a POS and doesnt support a LOT of stuff. (for example, in your command line, -b 2 is incompatible). Please use QuickTime profiles included in MeGUI, StaxRip and other softwares.
Also QuickTime doesnt support 64bit timestamps in MP4 files...
Get rid of that POS and use a serious player.

[dumbuser]

Craptime is a POS and doesn't support a LOT of stuff. (for example, in your command line, -b 2 is incompatible). Please use QuickTime profiles included in MeGUI, StaxRip and other softwares.
Also QuickTime doesnt support 64bit timestamps in MP4 files...
Get rid of that POS and use a serious player.

I realize that many people have their favorite players. But personally I don't believe that's a reason to make incompatible files. People should have confidence when opening a player that when it supports a standard the file will play, rather than search the Internet for hours trying to find out why it doesn't. Believe me when I say QT is NOT my favored player. However, I think you should look at the latest revision as everything in the batch file is compatible including -b 2 however setting -b 1 will not make a difference when it comes to the raw output problem. Also the issue of mux order making a difference is still not addressed and this is not QT specific, but does make a major difference here.

I do use MeGUI as well as Staxrip and others. I have the greatest respect for the people that make and contribute to these. So thanks for the input. :)

The final question(s) remains and that is why is x264's raw output problematic? Why does the mux order make a difference in smoothness in all players and full compatibility including proper reporting specially in QuickTime?

Please see prior posts for explanation!

[GodofaGap]

`People should have confidence when opening a player that when it supports a standard the file will play, rather than search the Internet for hours trying to find out why it doesn't.
Then go bug Apple. :) x264 doesn't say 'QT compatible' anywhere AFAIK.

Personally, I don't see any problem with muxing order (I do see problems with QT caused by QT). Can you provide sample files where the the same audio and video will behave very differently when muxed differently?

[Sharktooth]

it's QT that's non-standard, incomplatible and have bugs everywhere. blame apple for that... not x264.

[dumbuser]

To me it seems fairly obvious that Apple Computer is quite satisfied with where they are at for the moment and have based most all their programs (like final cut pro) around this engine. This was developed for and excepted by professionals around the world and I can only assume it works better on a Mac. :p I know many people that are using it and are happy with it and I have seen and used on a Mac. So there may be no accounting for taste here. Or perhaps we have become spoiled by what we know could be better. Non the less compatibility should be considered supreme when making product for general distribution so that consumer confidence is not dissuaded. However, when AVC becomes more main stream there is a proven upgrade path that will raise the bar for Apple $$

As for a sample! Sure, but I think The forum would be a bit upset if I posted copyrighted material in an attachment (35.6 meg > 5.35 min long) and I rather not make it public. So if you have a suggestion in this regard or give me an address...
But really I would think it best to experiment with this yourself as then you have the original and various methods to compare against. On the other hand packing all this up in a zip file and making it a torrent I will not do, even though it may be the best way to prove my point. :p

There are a few artifacts left in two segments of the clip
one of which is original and the other I'm still working on as the clip represents the most difficult portions of the feature length animation and thus far looks better than the original in general as I have tried to correct a number of problem areas and the encoding has reflected the improvement. This is something I was not sure could be done, considering many of the comments in the pages of this forum.

BTW I'm not defending Apple Computer and on my machine is worse than say CoreAVC with everything else kinda in between. But this isn't about what looks or works the best, it's about compatibility and consumer confidence!!!

Streaming and DAR should be the next issues for me as I believe this is also important to the future of H.264. Apple Computer has the best streaming to date and has made this equally difficult to grasp with their implementation. I don't believe anyone has approached DAR. Hmm! Well, maybe MeGUI kinda sorta or maybe it's me not spending enough time with it! :)

Please understand my reason for this post was and is for information regarding problem areas within (what I believe is) x264 and have hoped for some answers to my 2 remaining questions!

If I have not provided enough information for you to duplicate this please tell me what more you would need or how I may be of help. :)

[Sharktooth]

Read my previous post. x264 follows the standards... quicktime doesnt...

[dumbuser]

it's QT that's non-standard, incomplatible and have bugs everywhere. blame apple for that... not x264.

You don't have to defend x264 because I'm NOT attacking it and I agree that Apple Computer seems to have gone out of there way to make this more difficult than it should be. I don't believe for a moment it was accidental or bad implementation as I believe it was and or is on purpose! :p

But really this has little to do with my remaining two questions other than it is most noticeable in QT but does seem to effect any decoder to some degree. As far as the raw question goes the query is why should it have any effect at all? Why does it totally stop compatibility? I guess that makes 3 questions now! :)

Thanks for continuing to follow this thread!

[Sharktooth]

You cant pretend compatibility with a software does not follow the standards (im talking about quicktime).
I dont understand what you want from x264. It produces standard compliant streams that any standard compliant decoder can decode.
i have no problems with raw streams and muxed streams too... are you sure you are using an up to date version of MP4Box?

[dumbuser]

MP4Box is version 0.4.3 dated 10/5/06 and is the second update with the same version number. Please remember MP4Creator will yield the same result (version 1.5.5 dated 8/29/06) I did however need to change the sound track to one created by CT but still was the same spec as it was for ND (IE. 128 CBR LC Stereo @ orginal sampel rate of 48k)

Perhaps I can put this in a different light. Any Designer, Programmer or Consultant will never go against the specifications for a standard nor will they ever knowingly go against the math that built the standard as this leaves them open to attack from their peers. But they will interpret the gray areas or areas that were loosely defined so as to produce an end result under the guide lines of the company for which they are employed. To do anything else would hurt there reputation and or make it difficult to get referrals for more work or change jobs for perhaps more money. With this in mind, it is very doubtful that QuickTime is filled with obvious bugs as you seem to suggest, but is likely the team of programmers did exactly what management wanted under the loosely defined areas of the specification for H.264

I hope this is helpful and makes you understand that I'm NOT attacking x264 nor am I defending QT. I'm here just trying to find some answers. At the moment (because of the nature of the tests and the results) it appears that the problem is x264's raw output as everything else appears to have some logical explanation. If you remember the raw output did not pass the FPS and when externally muxed before the final mux where sound was added first and then the video. This broke compatibility. However when x264 did the mp4 mux and the same finishing was used there was complete compatibility. Now, even with the compatibility broken, the improvement in life like movement for this animation was improved through the finishing technique (IE smoothness) But it would be nice to have someone else confirm this and answer the questions directly if possible. Rather than continue to defend x264, which I like. So there is no argument here. :)

[check]

The problem is more likely with QTs mp4 parser than with mp4box. Apply enjoy proprietary formats, so even when they pick up MPEG forumats to use, they will only partially implement them or outright fudge with the specs.
For example, unless mp4 files are created with QT, they will not play on new iPods. They do this by checking a custom atom in the MP4 file which has no reason for being there other to force people to use QT for video transcoding. Obviously this has been easily circumvented, but the fact remains apple played fast & loose with both the mp4 muxer and parser.

[dumbuser]

The problem is more likely with QTs mp4 parser than with mp4box. Apply enjoy proprietary formats, so even when they pick up MPEG forumats to use, they will only partially implement them or outright fudge with the specs.
For example, unless mp4 files are created with QT, they will not play on new iPods. They do this by checking a custom atom in the MP4 file which has no reason for being there other to force people to use QT for video transcoding. Obviously this has been easily circumvented, but the fact remains apple played fast & loose with both the mp4 muxer and parser.

I have heard this said about mp4tags, but was unaware they may be playing games to outright deceive the consumer. Sad :( Is there no integrity left in the world?

[check]

don't expect apple to ever provide a 'good' multimedia solution, they have historically settled for 'good enough'.
With current tech, they have only implemented baseline h264 encoding and AAC-LC, when they had the option of high profile h264 and AAC-HE for lower audio bitrates.
The same happened last generation. Apple decided MPEG4-SP was 'good enough', and Sorenson was born, the ugly duckling of divx, xvid, et al. I can't even remember the audio format they used with those files, but it probably wasn't anything good either.

Part of the reason apple is so popular is simply because people don't know how much better they could be. Each upgrade is incrementally better than the previous generation of QT content, but never close to what other compeditors, such as vc-1 or high profile h264 provide. Simply because they have been around for so long (and were better in the good ol' days) and they provide a reasonably 'turn key' solution are reasons for the still reasonable support they enjoy.

[dumbuser]

I realize what your trying to say and once again I won't disagree. But in order not to confuse a non technical populace the files we make for distribution should be compatible. If for no other reason than to show that it can be better. I believe in the long hall this alone will force Apple's hand. For example down load the sample and put it up in QT, I believe you will find it is as good as any animation you have seen on their website, Look at media info while your there. Then put it up in MPC using CoreAVC if you have it.

I tried a few min ago to upload a sample to you but realized that it's a 8 meg limit. So I'm using RapidShare and will try to pull it in a few days. The name of the file is "LS2_mux_ sample.mp4" and should have a link in a few min.

http://rapidshare.de/files/36681139/LS2_mux_sample.mp4.html

The sample isn't going to show the differences, but it will show it is completely compatible and more so than any method described in pages here. If you want to see how close I am to the source go rent the DVD, but this is a bit better than the DVD. Except for may be the under water scene if you do a series of stills. In the opening the clouds fade in and there is a slight blockeyness at the top of the screen and this is in the master. Then tell me what you think as we will have a basis for discussion. This includes anyone else that wants to join in. :)

[emmel]

I realize what your trying to say and once again I won't disagree. But in order not to confuse a non technical populace the files we make for distribution should be compatible.

In other words, the output range of all encoders should be a subset of the input domain af all decoders? That would mean level 1?

[dumbuser]

In other words, the output range of all encoders should be a subset of the input domain af all decoders? That would mean level 1?

Do you really believe it will stay there long at present pace? Or are you thinking in the short term! :p Look at how far it has come in the past 24 months. The attention it has gained and the shier number of people and corporations on board indicates lots of growth in coming months. Probably sooner than we imagine!

But if you want to guarantee success on an investment don't confuse the general public. We should have learned a lesson with the VHS Beta wars. And now we have the HD DVD versus BlueRay do we need to confuse it even more with incompatible h.264 standards? This kind of thinking will only prove to slow the pace of public acceptance, specially in the face of a declining world economy! Or are you just being selfish and want to keep this to yourself? :p

Fortunately both the content owners and content providers have a better view of this. :)

Edit:

Sorry! Really should not have responded to this one as it is really off topic and everyone is entitled to their opinions. I came here asking some questions, looking for some answers and not to try to change the way people use or want to use x264. At this point I have provided a sample that shows what is possible in the realm of compatibility. I continue to search for real answers to my questions and not conjecture. Thanks for understanding! :)

[dumbuser]

I can only assume, considering it has been a few days now, that it was to much to ask that some one else try this and see if it responds the same for them.

I will also assume that the anomaly with x264's raw output is unfix-able. There have been two revisions since the original post that display the same end result. I'm about to test a couple of other builds but considering the lack of response here I really don't expect much. Tomorrow morning I will pull the sample and stop following this post. :(

I'm also very sad that for all the seemingly bright people here not one of them had a reasonable answer or would take the time to try what I had suggested. :( :(

I'm also sad because some seemed to think I'm trying to push QT or some how hold back x264 development which couldn't be further from the truth. I do realize that I did ask a few hard questions that perhaps only a developer could answer. I guess they don't ever come here. :)

[Sharktooth]

There is nothing wrong with x264 raw stream output...

[akupenguin]

The developers had no need to answer since GodofaGap, Sharktooth, and Check said everything that needed to be said.

[dumbuser]

The developers had no need to answer since GodofaGap, Sharktooth, and Check said everything that needed to be said.

Thanks for stopping by! I have spent about 11 hrs. today running more samples trying different approaches and pouring through change logs. What I discovered was, appears to have started in the early part of 05. If I had a guess it was within a revision of r195. If I could gain any of these I would try to prove it. But the result of how it acts today is that the raw output does not pass frame rate even when you explicitly tell it the frame rate via the --fps <framerate> option it is always locked at 25 fps. Further when the MP4 output was added FPS appears to be written in two places for compatibility one seems to be the GPAC standard and the other is where QT is looking for it. Therefore the problem is that you can NOT make a compatible QT file using the raw or .264 output of x264. It is (in my opinion) a bug in x264.

Now you might say, how did he arrive at that conclusion. VLC will play the raw file and shows it at 25FPS. When muxed with either MP4Box or MP4Creator if you do not explicitly tell the muxer what the FPS is you end up with 25FPS which is not what the video is. Further when you change the FPS via the muxer QT doesn't know what the FPS is. Now the only possible explanation I can think of for this is the FPS must be written in two places which was accounted for in x264's MP4 output. But isn't or can't be accounted for in the raw output.

I also find it interesting that when I put the video into a AVI container I end up with the same problem IE. if I do not tell the muxer the FPS it ends up being 25FPS. Why is it that the players always know what the frame rate is in any format if it is not consistent in the header? I'm assuming from this that the place QT looks for it is normally unused space no matter what the finished product is. So also assuming this is correct, what would it hurt to allow x264 either to pass the frame rate or allow the option (--fps <framerate>) to be active in the raw state? Further, Why couldn't the frame rate be written in the two most common places within any format?

Now there is another area that x264 could not possibly account for and one the Ateme is probably aware of and that it in order to have a completely compatible QT file the sound must be muxed first within the container. This is not a x264 issue. But wouldn't be quite so confusing if the frame rate issue were to be resolved for the raw output. :)

Originally all I asked is that someone take a look at this and try it. Unfortunately I keep getting the gut feeling from the responses in defense when there was no attack that no one ever tried. But wrote answers based on belief. IE their feelings rather than reality.

Thanks for reading this! At present all my original questions have been answered and now that I know the apparent reality, I will deal with it. If you change this or not is of coarse your decision. The sample will be pulled as it is not necessary anymore and the moderator can erase this post if so desired.

:thanks:

[imcold]

The default fps value for raw h264 streams in mp4box is 25 (MP4Box.exe -h import), that's why you're getting 25fps when not explicitly defining one - and I bet it's the default value in other sw too (for example avc2avi). Mp4creator from mpeg4iptools-1.4.18 does explicitly ask for the fps of .264 files.

[foxyshadis]

Raw frame timestamps are completely ignored by current mp4 muxers, which will all write their own instead. Always have. (That's why you have to specify a framerate when muxing, not any nefariousness on x264's part.) You really need to file a bug report with gpac and mp4box, not x264, as I assume you're using up-to-date versions of each.

[GodofaGap]

Now you might say, how did he arrive at that conclusion. VLC will play the raw file and shows it at 25FPS. When muxed with either MP4Box or MP4Creator if you do not explicitly tell the muxer what the FPS is you end up with 25FPS which is not what the video is. Further when you change the FPS via the muxer QT doesn't know what the FPS is. Now the only possible explanation I can think of for this is the FPS must be written in two places which was accounted for in x264's MP4 output. But isn't or can't be accounted for in the raw output.

You haven't considered that VLC and mp4box might actually be ignoring the fps written in raw streams (which is true for mp4box, I don't know about VLC). But mplayer plays raw files at the correct frame rate. So your assumption that the problem must be with x264 is just plain false.

`Originally all I asked is that someone take a look at this and try it. Unfortunately I keep getting the gut feeling from the responses in defense when there was no attack that no one ever tried. But wrote answers based on belief. IE their feelings rather than reality.
No, you write very longwinded posts and without giving any info on recreating the problems you encounter (I had to ask two times before you even gave that). When I try to recreate it and don't encounter the problem, in all my goodness in believing you have a problem that is not caused by yourself, I ask you to upload a sample that shows it, but instead you upload a sample that does works. Well duh, I can make working samples myself. All day long.

So before shouting that x264 is doing things wrong, and that we are "stuck in our beliefs" I really should advice to take a big look at yourself in the mirror and perhaps consider that you are not perfect and might make mistakes and perhaps do not have a thorough understanding of how things work. That is ok, we all have to learn these things.

[Mug Funky]

this works. i've tried it on many a quicktime, mac and PC (btw there's no difference in compatibility between the 2, only speed):

"C:\Program Files\x264\x264.exe" --pass 1 --stats "%~dpn1_stats.log" --bitrate 256 --thread-input --qpmin=4 --bframes 2 --subme 6 --weightb --analyse p8x8,b8x8,i4x4,p4x4 --me umh --progress --output "%~dpn1_x264.264" "%~dpn1.avs"

"C:\Program Files\x264\x264.exe" --pass 2 --stats "%~dpn1_stats.log" --bitrate 256 --thread-input --qpmin=4 --bframes 2 --subme 6 --weightb --analyse p8x8,b8x8,i4x4,p4x4 --me umh --progress --output "%~dpn1_x264.264" "%~dpn1.avs"
"C:\Program Files\AviSynth 2.5\plugins\avs2wav.exe" "%~dpn1.avs" - | "C:\Program Files\x264\neroAacEnc_sse2.exe" -br 96000 -lc -if - -of "%~dpn1_audio.m4a"

MP4Box.exe -fps 25 -add "%~dpn1_x264.264" -add "%~dpn1_audio.m4a" "%~dpn1.mp4"

mp4box version 30/09/2005
x264 = latest or thereabouts (last week)
neroaacenc version - i can't remeber. probably one of the first releases.

all versions should work fine though, provided syntax stays the same.

[edit]

and yes, it's a sorry state of affairs, because i can only guarantee a client (read: non-video geeq) can watch it if i tell them to play it in quicktime 7.

it absolutely sucks that quicktime should be so awful but be what i have to encode for in the end. maybe if VLC was pretty like quicktime it'd be an ideal solution, as that's on PC and Crapple (and is actually the weapon of choice for watching DVDs on a lot of macs, because the stock player is so terrible).

and people talk about MS being anti-competitive! apple have been getting away with it for far too long, and it's about time someone came along and made a decent multimedia platform for the mac so mac users can get a taste of what their stupidly expensive hardware is actually capable of. i dream of seeing avisynth 3.0 on the mac, so i can turn the whole office into a renderfarm after hours :)

[dumbuser]

this works. i've tried it on many a quicktime, mac and PC (btw there's no difference in compatibility between the 2, only speed):

"C:\Program Files\x264\x264.exe" --pass 1 --stats "%~dpn1_stats.log" --bitrate 256 --thread-input --qpmin=4 --bframes 2 --subme 6 --weightb --analyse p8x8,b8x8,i4x4,p4x4 --me umh --progress --output "%~dpn1_x264.264" "%~dpn1.avs"

"C:\Program Files\x264\x264.exe" --pass 2 --stats "%~dpn1_stats.log" --bitrate 256 --thread-input --qpmin=4 --bframes 2 --subme 6 --weightb --analyse p8x8,b8x8,i4x4,p4x4 --me umh --progress --output "%~dpn1_x264.264" "%~dpn1.avs"
"C:\Program Files\AviSynth 2.5\plugins\avs2wav.exe" "%~dpn1.avs" - | "C:\Program Files\x264\neroAacEnc_sse2.exe" -br 96000 -lc -if - -of "%~dpn1_audio.m4a"

MP4Box.exe -fps 25 -add "%~dpn1_x264.264" -add "%~dpn1_audio.m4a" "%~dpn1.mp4"

mp4box version 30/09/2005
x264 = latest or thereabouts (last week)
neroaacenc version - i can't remeber. probably one of the first releases.

all versions should work fine though, provided syntax stays the same.

[edit]

and yes, it's a sorry state of affairs, because i can only guarantee a client (read: non-video geeq) can watch it if i tell them to play it in quicktime 7.

it absolutely sucks that quicktime should be so awful but be what i have to encode for in the end. maybe if VLC was pretty like quicktime it'd be an ideal solution, as that's on PC and Crapple (and is actually the weapon of choice for watching DVDs on a lot of macs, because the stock player is so terrible).

and people talk about MS being anti-competitive! apple have been getting away with it for far too long, and it's about time someone came along and made a decent multimedia platform for the mac so mac users can get a taste of what their stupidly expensive hardware is actually capable of. i dream of seeing avisynth 3.0 on the mac, so i can turn the whole office into a renderfarm after hours :)

OH! That's a nice response! I agree whole heartedly. :) I have a friend in Seattle who is an old film maker / writer, he has a son who today lives and works in LA providing shoot sites and film crews for the majors. We have had many discussions about h.264 and final cut pro. He feels like we do that it is not what it could or should be. I turned him on to x264 but the original problem was that he is a Mac person. So recently I introduced him to VLC. :) Still, this is kind of a geeky program but it is slowly improving with each revision.

I will look more closely at your command line when I have had a chance to respond to everyone else. But on the surface, Ya! It should make a compatible QT file. If you have the opportunity, try muxing the audio first and tell me if you think the end result is a bit smoother. Please also note QT's reporting of the file. It should show correctly. While we normally mux the video first the reporting is gibberish.

Considering the recent response I have received here. I'm running some more tests :( in sequence and may post some of them. But I need to respond to everyone that was kind enough to respond to me.

:goodpost: :thanks: You touched my heart. It's where I live. :)

[dumbuser]

Raw frame timestamps are completely ignored by current mp4 muxers, which will all write their own instead. Always have. (That's why you have to specify a framerate when muxing, not any nefariousness on x264's part.) You really need to file a bug report with gpac and mp4box, not x264, as I assume you're using up-to-date versions of each.

Really! Being honest I did not consider this. Will run some more tests. Be aware that both the muxers are current and do recognize x264's MP4 output without user intervention.

BTW I didn't mean to ignore you earlier and did look for prior versions, just couldn't find them compiled.

:thanks: For showing interest and offering a response.

[Sharktooth]

OMG... i already told you to use the MeGUI, StaxRIP, AutoMKV etc... profiles for quicktime... THEY WORK.

[dumbuser]

There is nothing wrong with x264 raw stream output...

You are a legend in your own time and I have a great deal of respect for you! But You need to be more human! :) I did hear you the first time. But again, I'm not attacking x264. I'm just a dumbuser trying to understand.

While many people do not understand the technical ins and outs and actually believe the old wives tail that states "Any technology so significantly advanced is indistinguishable from magic" I do not! :)

But :thanks: again for trying to be helpful and being here.

[dumbuser]

You haven't considered that VLC and mp4box might actually be ignoring the fps written in raw streams (which is true for mp4box, I don't know about VLC). But mplayer plays raw files at the correct frame rate. So your assumption that the problem must be with x264 is just plain false.


No, you write very longwinded posts and without giving any info on recreating the problems you encounter (I had to ask two times before you even gave that). When I try to recreate it and don't encounter the problem, in all my goodness in believing you have a problem that is not caused by yourself, I ask you to upload a sample that shows it, but instead you upload a sample that does works. Well duh, I can make working samples myself. All day long.

So before shouting that x264 is doing things wrong, and that we are "stuck in our beliefs" I really should advice to take a big look at yourself in the mirror and perhaps consider that you are not perfect and might make mistakes and perhaps do not have a thorough understanding of how things work. That is ok, we all have to learn these things.

I'm sorry we crossed paths earlier as it seems I was posting a response and didn't see yours until the next time I signed in. I am considering your response and running some more tests now. I will post the results later in the day as I have the opportunity to compile them.

BTW I'm human like most people and as such am subject to error, IE imperfect. But on the other hand I have never met any on who could walk on water or put on their pants more than one leg at a time. :) Sorry for the long winded just try to be complete but sometimes this is equally misunderstood.

From now on when you ask I will only post a sample of the file that is screwed up so you can accurately evaluate it. :)

:thanks: for taking the time to respond to me.

[dumbuser]

OMG... i already told you to use the MeGUI, StaxRIP, AutoMKV etc... profiles for quicktime... THEY WORK.

Yes! They do, without them it would have taken me a great deal longer. Thanks for providing them as I know you HATE QT! :) But, QT as we all know, is screwed up. In my opinion, on purpose. I have been looking for a way to make this better as most of the trailers on QT's own website are better than anything I have done here using current tools. I had this weird notion there was a better way with out buying a Mac and installing Final Cut Pro that uses QT's engine.

:thanks: again for the reply.

[dumbuser]

The default fps value for raw h264 streams in mp4box is 25 (MP4Box.exe -h import), that's why you're getting 25fps when not explicitly defining one - and I bet it's the default value in other sw too (for example avc2avi). Mp4creator from mpeg4iptools-1.4.18 does explicitly ask for the fps of .264 files.

As I told foxyshadis, I am considering this now and running some more tests. But please be aware that both muxers do recognize FPS in x264's MP4 output. How many places can you write it and still have it not be recognized? Well, that may not be a well formed question. :)

Thanks for the response!

[foxyshadis]

As I told foxyshadis, I am considering this now and running some more tests. But please be aware that both muxers do recognize FPS in x264's MP4 output. How many places can you write it and still have it not be recognized? Well, that may not be a well formed question. :)

Thanks for the response!

Well, they're mp4 tools, of course they recognize mp4 timestamps while importing. I know there have been several requests to implement raw avc timestamps in mp4box over the years, but it was never implemented. Neither the standard nor the quicktime framerate location are related to the raw bitstream location, so yes, three incompatible places. (afaik per-frame timestamps are the same between qt and standard, though, just stream default framerate is in different atoms.) Raw avc doesn't have any kind of framerate, it only has timestamps, I believe.

(This forum could really use the double-post combining hack.)

[dumbuser]

Well, they're mp4 tools, of course they recognize mp4 timestamps while importing. I know there have been several requests to implement raw avc timestamps in mp4box over the years, but it was never implemented. Neither the standard nor the quicktime framerate location are related to the raw bitstream location, so yes, three incompatible places. (afaik per-frame timestamps are the same between qt and standard, though, just stream default framerate is in different atoms.) Raw avc doesn't have any kind of framerate, it only has timestamps, I believe.

(This forum could really use the double-post combining hack.)

Hmm! This could be very true but in the following tests it seems any of the players that can play raw files, don't recognize framerate even when it is specified on the x264 command line. Please see the following post for more info and draw your own conclusions, please!

[dumbuser]

I ran the following group of tests today for all of you. Please draw your own conclusions.

1. LS2 raw.264 (no fps specified in command line)

Command line: x264.exe --progress --no-psnr --thread-input --scenecut 40 -I 240 -i 24 --threads 1 --me umh --merange 16 --sar 1:1 -r 5 --nr 0 -f 1:1 -b 2 --direct "spatial" --b-bias 0 --ipratio 1.400000 --pbratio 1.300000 -A p8x8,p4x4,b8x8,i4x4 -B 700 --qpmin 10 --qpmax 51 --qpstep 4 --qcomp 0.600000 -m 6 --b-rdo -o "D:\vStrip test\LS2 raw.264" "D:\vStrip test\LS2.avs"

MPC does not recognize the raw file
VLC doesn't report frame rate for the raw file
MPlayer does report frame rate (23.976) same as avs

------

2. LS2 raw fps.264 (fps is specified in the command line)

Command line: x264.exe --progress --no-psnr --thread-input --scenecut 40 -I 240 -i 24 --threads 1 --me umh --merange 16 --sar 1:1 -r 5 --nr 0 -f 1:1 -b 2 --direct "spatial" --b-bias 0 --ipratio 1.400000 --pbratio 1.300000 -A p8x8,p4x4,b8x8,i4x4 -B 700 --qpmin 10 --qpmax 51 --qpstep 4 --qcomp 0.600000 -m 6 --b-rdo --fps 23.976 -o "D:\vStrip test\LS2 raw fps.264" "D:\vStrip test\LS2.avs"

No point in looking at MPC
VLC still does not report the frame rate for the raw file (must have been mistaken on this one)
MPlayer does report frame rate (23.976) same as avs (I love Mplayers comment "FPS seems to be: 23.976025") Is it possible that Mplayer is seeing the pull down flag and interpreting the FPS?? The flag in this video is there and correct it is 29.9 with a real 2-3 pull down and thus is 23.976. Notice that it says "23.976025" which is rather unusual to see the whole thing as most programs round the numbers and even when you do see it the "025" is some variant of the real number.

As of this point there is nothing conclusive to indicate x264 is actually writing FPS to a raw output or not. However, there is good indication that it isn't.

-------

3. LS2 raw fps muxed.mp4

Next is to mux the raw output into a MP4 container. I will use the file that the FPS was specified and for the sake of convenience MP4Box will be used. We will not mux audio at this point as this mux should compare to what x264 would do if asked to produce a MP4 output.

In The first mux we will NOT change or add the FPS within the muxer.

MPC recognizes the file as 25FPS
VLC recognizes the file as 25FPS
MPlayer recognizes the file as 25FPS
QT does not recognize the file and the reporting is unreadable.

No reason to present a command line in these as I think we all know how to mux a file.

-------

4. LS2 raw fps muxed2.mp4

Next is to mux the raw output into a MP4 container using the command for FPS within the muxer. Again I will use MP4Box and the raw file where FPS was specified. I hope no one objects to this But I can't see how it could possibly make a difference as FPS didn't appear to be recognized and I have tried it the other way. In other words I have been here before and the muxer doesn't care. :)

MPC recognizes the file as 23.98FPS
VLC recognizes the file as 23.976023FPS
MPlayer recognizes the file as 23.976FPS (Note the difference in reporting here as there was no speculation and no 025)
QT still does not recognize the file and the reporting is unreadable.

-------

5. LS2 raw fps muxed3.mp4

Next I will take the last muxed file and add audio to it muxing the audio first in the command structure.The audio is a prepared track using 5.1 48k DTS as the source and transcoding it to AAC using ND @ 128 CBR LC Stereo. The resulting file is an MP4 type file. However it has made no difference in the past if I use CT with same spec to produce an .aac file.

MPC reports the video the same as before, first in the reporting structure with audio being second.
VLC reports the video the same as before with audio (MP4a) being first in the reporting structure and video second
MPlayer reports the video same as before with video being first in the reporting structure and then audio (MP4a) being second.
QT will not play the file (audio no video) but it's reporting is readable. It shows Movie FPS as 23.98 and Playing FPS as 0.00 (given this is not how it was reported last night I may need to back up here). (Last night it was reported as 0 in both movie and playing sections) For the moment we will move on. But QT was both slow and rather unresponsive which has been the case in the past when it doesn't like something, but it didn't crash.

I did verify with a hex editor that audio in the header information was first.

-------

6. LS2 raw fps muxed4.mp4

Next I will take the last muxed file (LS2 raw fps muxed2.mp4) and mux the video first. What we all consider normal.

MPC showed no difference in reporting
VLC showed the video first and then the audio (opposite of the last time)
MPlayer showed no difference in reporting
QT does not play the video and the reporting is unreadable (audio plays normally)

Again I did verify with a hex editor that video was first.

--------

The following two may not be necessary but were done to be complete in concepts.

6. LS2 raw muxed5.mp4

Given that there has been no evidence that the x264 option --fps <framrate> command was ever recognized and I saw a difference in one of the tests above I decided to use (LS2 raw.264) for the following tests. The concept for these tests are for people that might say: Why do we need an extra step of muxing the video before we do the final mux. Give the question has validity we will try it both ways IE. audio first and video first and see how the players respond. Of coarse we must specify FPS in the muxer just like we need to, using LS2 raw fps.264 to create the muxed version (LS2 raw fps muxed2.mp4) for the last set of tests. The audio file will be the same as before.

LS2 raw muxed5.mp4 will be audio first

MPC showed the same reporting as before and the file played normally
VLC showed the same reporting as before and the file played normally IE audio first.
MPlayer showed the same reporting as before and the file played normally
QT will not play the file (audio no video) but it's reporting is readable. It shows Movie FPS as 23.98 and Playing FPS as 0.00 (I have no idea what was different last night).

Again this was checked with a hex editor and the audio handler was first.

--------

7. LS2 raw muxed6.mp4

This one will be Video first

MPC showed the same reporting as before and the file played normally
VLC showed the same reporting as before (IE video first) and the file played normally.
MPlayer showed the same reporting as before and the file played normally
QT does not play the video and the reporting is unreadable (audio plays normally)

Again this was checked with a hex editor and the video handler was first.

--------

8. LS2 MP4 x264muxed7.mp4

The last set of 3 tests is to create a QT compatible file using the same commands for x264 as used for the rest of these tests.

Command line: x264.exe --progress --no-psnr --thread-input --scenecut 40 -I 240 -i 24 --threads 1 --me umh --merange 16 --sar 1:1 -r 5 --nr 0 -f 1:1 -b 2 --direct "spatial" --b-bias 0 --ipratio 1.400000 --pbratio 1.300000 -A p8x8,p4x4,b8x8,i4x4 -B 700 --qpmin 10 --qpmax 51 --qpstep 4 --qcomp 0.600000 -m 6 --b-rdo -o "D:\vStrip test\LS2 mp4 x264muxed7.mp4" "D:\vStrip test\LS2.avs"

MPC showed the same reporting as before and the file played normally (23.98fps)
VLC showed the same reporting as before and the file played normally (23.976023fps)
MPlayer showed the same reporting as before and the file played normally (23.976fps)
QT played the file normally but the file information was unreadable.

-------

9. LS2 MP4 x264muxed8.mp4

For this test MP4Box will be used to add audio and muxed first. No statement of framrate will be disclosed or entered into the muxer.

MPC showed the same reporting as before and the file played normally
VLC showed the same reporting as before (IE audio first) and the file played normally
MPlayer showed the same reporting as before and the file played normally
QT played the file normally and its reporting was also normal (Movie fps: 23.98 Playing fps: 24)

Again this was checked with a hex editor and the audio handler was first.

-------

10. LS2 MP4 x264muxed9.mp4

For this test MP4Box will be used to mux the video first. No statement of framrate will be disclosed or entered into the muxer.

MPC showed the same reporting as before and the file played normally
VLC showed the same reporting as before (IE video first) and the file played normally
MPlayer showed the same reporting as before and the file played normally
QT played the file normally but its reporting was unreadable

Again this was checked with a hex editor and the video handler was first.

-------

Note: While I haven't mentioned this, search functions have also been checked along the way and no seeking problems have been encountered. Also MPC uses CoreAVC 1.1 along with CoreAAC for decoding. I never experienced any kind of sync problem in any of the tests that sync would be applicable.

I'm not going to do a summery as I believe the tests speak for them self. If you want any of the files please request them by name or number and I will try to get it posted somewhere. The notes within the tests were merely to keep my place or sanity. :) If you feel that somehow the test criteria is in error or you feel I have neglected to provide some important aspect please state in what group and try correcting the error for me and I will try running that test or group again if possible.

[akupenguin]

Raw avc doesn't have any kind of framerate, it only has timestamps, I believe.
Raw h264 allows both framerate and per-frame timestamps. x264cli always writes the framerate, and doesn't support per-frame timestamps. MP4Box ignores both.

[dumbuser]

I can't help myself from asking the stupid question! If x264 always writes the framerate why is it that nothing reads it? Or perhaps better said: If x264 always writes the framerate why can't it write it where something can read it?

Plus! Why have a command (--fps <framerate>)? If it's written where nothing ever reads it, how could changing the framerate via the command ever make a difference? Right? :confused:

BTW You can add MP4Creator to your list too! Along with any player I have found that plays raw h.264 files.

[imcold]

Standart defines, where should the fps be written. --fps makes perfect sense, for example when you're feeding x264 with raw yuv input, since you need to define output's fps somehow.

[foxyshadis]

I can't help myself from asking the stupid question! If x264 always writes the framerate why is it that nothing reads it? Or perhaps better said: If x264 always writes the framerate why can't it write it where something can read it?
It does, other tools just don't bother to read it. Because the functionality was never written; they won't read mainconcept's or ateme's any better than x264's. Apparently there just hasn't been a developer of GPAC or mp4box interested in writing the code (which is what it all comes down to in open source); if you can get a developer interested, I'm sure you wouldn't be the only one to benefit... ;p

Thanks for the clarification, akupenguin.

[GodofaGap]

Again, mplayer reads the framerate.

[bond]

not all raw streams have a fps signalled

edit: btw jeanlf implements as good as all feature requests for mp4box, there simply has to be one to start with tough (he doesnt read doom9), so someone needs to make one:
http://sourceforge.net/tracker/?atid=571741&group_id=84101&func=browse

[dumbuser]

Personally I think this whole situation is rather Bazaar!

1. akupenguin says that the framerate is always written and apparently (according to him) this is true if it is specified on the command line or not. But it doesn't appear there is a designated place within the specification as to where it is written and perhaps even required to be written in the raw form.

2. GodofaGap says MPlayer can read it. But I'm not quite sure this is true. Specially considering how MPlayer is reporting it. As though it isn't really sure. Plus the fact that the last three digits of a frame rate would only be assumed from the pull down flags and MPlayer could be doing this also. Yes! it plays but so does VLC that doesn't claim to know the frame rate and doesn't speculate. It would be nice to be able to shut of the framerate to know for sure! :)

3. foxyshadis and bond seem to agree in that, if the framerate is written then GPAC needs to support this. But it also seems logical that this could be said for any container. Haven't looked at Matroska. Does it recognize framerate in the raw state? I will look today! Never mind I just remembered Matroska doesn't accept .264 files. :( Also foxyshadis mentions that Ateme and Mainconcepts framerates are also not being recognized. This is of coarse assuming they are writing it, I suppose.

From a pure logic standpoint it seem that if framerate was to be written in a place where everything could find it, would be the real answer here or am I missing something? IE make the bold move to make this part of the specification and have a resolve for every container. If there is conjecture among peers then let the --fps <framerate> switch be an option for the end user to decide. If no framerate is written without the use of the switch the default would be 25fps.

[bond]

dumbuser, can you plz summarize your problem in one or two sentences (not more)?

[foxyshadis]

mkvmerge won't import raw avc, it has to be muxed from mp4. Haali's works through directshow, which places its own timestamps on it, and mencoder and avidemux don't have functional mkv muxers yet.

Anyway, I filed the RFE at gpac: http://sourceforge.net/tracker/index.php?func=detail&aid=1579222&group_id=84101&atid=571741

[GodofaGap]

`2. GodofaGap says MPlayer can read it. But I'm not quite sure this is true. Specially considering how MPlayer is reporting it. As though it isn't really sure. Plus the fact that the last three digits of a frame rate would only be assumed from the pull down flags and MPlayer could be doing this also. Yes! it plays but so does VLC that doesn't claim to know the frame rate and doesn't speculate. It would be nice to be able to shut of the framerate to know for sure!
There are no pulldown flags in the raw AVC stream... your assumptions are nonsense. NTSC FILM fps is 24000/1001 and mplayer reports this correctly as a float.

Furthermore, if you wish ignore a dev saying his tool is writing the framerate to the raw avc stream and wish to ignore everybody else saying mp4box does not read the framerate from a raw AVC stream then what more do you expect to hear? Go read the source code and find out for yourself.

`From a pure logic standpoint it seem that if framerate was to be written in a place where everything could find it, would be the real answer here or am I missing something?
Yes, you are.