View Full Version : Can a MP4 AVC H.264 greater than 4GB ?
jusko
6th November 2008, 14:24
Hi, just want to know whether a MP4 AVC H.264 video file can be greater than 4GB in size. I asked because I had encoded a video file 4.4 GB, but the player crashed when playing near the end of the file. I guessed it was near the 4GB limit mark.
I am using Windows Vista x64 NTFS system, so file size should have no problem greater than 4GB.
Thanks in advance for your advice.
crypto
6th November 2008, 17:51
Yes, that's definitely possible. What player crashed at > 4GB?
Sagekilla
6th November 2008, 18:01
Thats odd because I had a 10 GB mp4 once (transcode of a Blu-ray popped into mp4 for testing) and it played back perfectly fine from start to finish under mpc. Also, I don't understand -why- mp4s have to be at most 4 GB big. I don't think mp4 is based off AVI, so it doesn't have the problem that avi does, which leads me to wonder what is causing this 4 gb limit.
In all honesty, having file size limits in this day and age is plain idiocy.
crypto
6th November 2008, 20:12
There is no 4 GB limit for MP4. To build MP4s larger than 4GB the muxer must use 64bit addressing. Some players also need 64bit time stamps. That's why I asked about the player.
jusko
7th November 2008, 02:43
Thanks crypto and Sagekilla for your replies.
The players that crashed includes Windows Media Player (with CoreAVC decoder), MPC v1.1, PowerDVD 8.0, Nero ShowTime. All crashed at near the same location.
My video consists of 4 clips originally, I used Adobe Media Encoder to combine them into one single file about 4.4GB.
I have tried some testings to see whether it was the problem of my clips.
First, encoded only the last clip that caused the problem. That made a final video file of only a few hunderd MB. The resulting video played with no problem.
Second, I rearranged the last clip to be the first one. So, the same clips and same file size 4.4GB. Players crashed while playing near the end of the 4.4GB file.
Thats why I suspect the culprit is the 4GB limit.
Any idea please ?
Regards
jusko
squid_80
7th November 2008, 03:28
I don't think mp4 is based off AVI, so it doesn't have the problem that avi does, which leads me to wonder what is causing this 4 gb limit.
In all honesty, having file size limits in this day and age is plain idiocy.
Good thing AVI doesn't have any such restrictions then.
setarip_old
7th November 2008, 03:33
@jusko
Hi!
What is the format of the audio?
jusko
7th November 2008, 06:17
@setarip
Hi !
The audio codec used is mp4a: MPEG-4 AAC LC, 48000Hz 157 kb/s tot , stereo (2/0)
The video codec used is avc1 H.264/MPEG-4 AVC
Regards
jusko
7th November 2008, 06:23
Hi, all, I just finished another testing. Everything being the same, except a bit lower in quality from 9mbps to 8.2mbps. The final video file is just below 4GB. All players play the video fine down to the end, no crash.
So, I suspect there is really something to do with the 4GB limit.
Any ideas please ?
burfadel
7th November 2008, 07:22
All those players are probably using an external codec, such as the Coreavc you mentioned. The bundled versions of CoreAVC that are floating around still are very old, and weren't as far as I know, meant to be free! Try a more up to date decoder such as FFdshow (build 2300 or above), and see if it still works. Make sure you get a very recent ffdshow, as there new builds that come out almost every day. Definitely don't use the original ffdshow series from years ago, it won't work either! (these were before the current branch, which I believe started at 1!) - I'm sure someone can clear that up!
If you are using a proper version of CoreAVC, and its recent, then try ffdshow anyways just in case there's an erroneous bug that affects your installation. Just make sure ffdshow is used in this case instead of Coreavc.
squid_80
7th November 2008, 11:02
The problem will be in the splitter, not the codec.
jusko
7th November 2008, 15:47
To: burfadel
I just installed the latest ffdshow v.2301 of Nov 5, 2008. And played with mpc homecinema v.1.1.0.0. But the video was all pixelated. What settings should I make in ffdshow please? I guess PowerDVD doesn't use ffdshow for decoding, but Its strange that it also crashes at near the same location of about 4GB.
To: squid_80
If the problem lies in the splitter, then how do I set the splitter in ffdshow please ?
Best Regards
squid_80
7th November 2008, 16:41
Just make sure you have the latest version of Haali's splitter (http://www.haali.net/mkv/MatroskaSplitter.exe) installed.
burfadel
7th November 2008, 17:28
I've just checked some encodings, it does seem the last few revisions of ffdshow lead to blocking, something in the last month!... hopefully its a bug that can be found an fixed. It only applies to seeking, and for the current I-frame interval. Once the new i-frame comes up, its fine. More precisely, blocking occurs when you seek to a position between I-frames.
jusko
8th November 2008, 10:35
Thank you squid_80 and burfadel.
Just installed Haali's splitter v.1.8.122.18. But no improvement of any kind. Besides blockings all over the video, all the players still crash or stop at the suspected 4GB limit.
Am I missing something in the ffdshow video/audio decoder configuration ? I just left all the settings in default. The default for H.264/AVC is libavcodec while the default for AAC is libfaad2.
Further help is appreciated.
Best Regards
crypto
8th November 2008, 11:06
@jusko
I suspect the muxing has not been done in 64bit mode. Try extracting the audio and video elementary streams and remux with mp4muxer. I hope there is no problem to extract the streams from the faulty mux. I have several files >4GB and much larger and they are all ok. You can also use the analyzer in mp4muxer to see, if your stream has 64-bit chunk offsets (co64 atom).
8.19 Chunk Offset Box
8.19.1 Definition
Box Type: ‘stco’, ‘co64’
Container: Sample Table Box (‘stbl’)
Mandatory: Yes
Quantity: Exactly one variant must be present
The chunk offset table gives the index of each chunk into the containing file. There are two variants, permitting
the use of 32-bit or 64-bit offsets. The latter is useful when managing very large presentations. At most one of
these variants will occur in any single instance of a sample table.
Offsets are file offsets, not the offset into any box within the file (e.g. Media Data Box). This permits referring
to media data in files without any box structure. It does also mean that care must be taken when constructing
a self-contained ISO file with its metadata (Movie Box) at the front, as the size of the Movie Box will affect the
chunk offsets to the media data.
jusko
8th November 2008, 12:07
Thanks crypto for your advice. I did what you said, i.e. extracting the audio and video elementary streams and remux with mp4muxer. Its strange that the resulting video played just like in slow motion and chopped off at exactly the suspected 4GB limit. That is the remaining part after the suspected 4GB limit is lost.
I also used the mp4muxer to analyze the video. But the result was totally incomprehensible to me. I must admit that I am a total newbie as far as video codec is concerned.
Best Regards
crypto
8th November 2008, 13:33
..Its strange that the resulting video played just like in slow motion
You need to specify the correct fps rate. It defaults to 25fps, which is probably not correct for your stream.
... and chopped off at exactly the suspected 4GB limit. That is the remaining part after the suspected 4GB limit is lost.
Check 64-bit addressing and 64-bit times before starting to mux.
...
I also used the mp4muxer to analyze the video. But the result was totally incomprehensible to me. I must admit that I am a total newbie as far as video codec is concerned.
Click thru the tree:
+moov
+trak (video)
+mdia
+minf
+stbl
+co64 <-- do you see this?
jusko
8th November 2008, 14:57
Thank you crypto. Its very kind of you taking so much time to help me.
1. Yes, its 25 fps for my video.
2. Checked both 64-bit addressing and 64-bit times , but the result is the same, ---slow motion, 2nd half of the video is without audio, end being chopped off near the 4GB limit.
3. can't see the co64 in the moov tree.
Looking forward to your further advice please.
Best Regards
jusko
9th November 2008, 11:40
Hi, all. I have just made another testing. A completely new project. The duration of the video was even longer and about 5GB in size. All players either crashed or stopped at about 2mins before the end. But I guess the crash point has passed the 4GB limit. So the conclusion is that the crash has nothing to do with the 4GB limit
I am now suspecting its a bug of the CS4 Adobe Media Encoder. No matter the video is 4.4GB or 5GB, the crash point is also about 2mins before the end of the video.
crypto
9th November 2008, 11:46
I am now suspecting its a bug of the CS4 Adobe Media Encoder. No matter the video is 4.4GB or 5GB, the crash point is also about 2mins before the end of the video.
Unlikely but not impossible. Use x264 to encode then. This encoder is known for its superior results and its free.
jusko
9th November 2008, 16:04
But I am using Premiere Pro for editing and I have to export the project to Adobe Media Encoder.
Is there anything to do with the H.264 profile ? I chose Main Profile for encoding. Any advantage for High Profile or Baseline Profile ?
Best Regards
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.