When fed a raw h264 file, it seems mp4box does not support opengop fully. The code does parse recovery point seis but does not flag as a key frame. If i remove the line that stops i-frames with RPs from being flagged as keyframes, the resulting output jumps (pauses 1/2 a second and then plays on) at keyframes. when .mp4 output is used with x264 instead of raw, (x264 uses libgpac) x264 flags isRAP==true for open gop frames that have recovery points and the output plays with no problems and seeks fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also wanted to mention an unmodified mp4box will error out if the file is long enough. I presume it has difficulty dealing with what it perceives as no keyframes for the entire duration of the file. (some variable(s) get overloaded?)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The default behavior (UNMODIFIED mp4box) is the inability to seek to recovery points, and on very long files (movie duration files around 3 gigabyte or greater) mp4box will not even complete mux.
The stuttering only occured when i attempted to fix it by commenting out line 3880 (approximately) in media_import.c "//avc.sei.recovery_point.valid = 0;" The mux no longer crashes but then I get the stuttering. It was a guess at a way to fix the crash and seeking issue but apparently not the right way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) I could seek to recovery points with VLC. That's why I'm asking for the possibility for you to upload a .264 file.
2) I'll try to mux a big big file.
3) I saw the stuttering a few weeks ago. It happens when MP4Box looks endlessly for a RAP. I'll have a look to make it clearer.
4) It's the good function but unfortunately your fix only impacts the first NAL unit. Nice try anyway, thank you :-)
Romain
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. The ultimate fix needs to work on platforms i cant alter like my xbox 360 which doesnt allow for settings to change. x264s libGPAC mp4s play and seek fine on the xbox..mp4box' open gop mp4s wont seek on anything i have software or hardware.
2. Thanks
3. hmmm
4. Hehe. An attempt at fixing it without having to learn the code. Unfortunately crossing my fingers didnt help any. ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) I tried your mp4 + muxing with both a 6 months-old MP4Box and a recent one the raw 264. The 3 resulting MP4 files work and seek with VLC 1.1.0 and Osmo4 (GPAC windows player).
The time you wait when seeking depends on the implementation of the player (sometimes you seek to a frame that is in the middle of the GOP and need to decode several frames before reaching the one you asked for), it is around half a second for each one, which is acceptable to me.
At the moment I still can't reproduce your bug.
2) a 6GB file works. I need a file that would show the bad behaviour if you see it again.
3) The stuttering appeared when cutting files with MP4Box. I am told this bug was closed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My seek time on the mp4 (3/4 in for example) is 11 seconds, but I have an old AMD x2. On a closed gop seek my seek time is 1/2 second. How long does a seek to the middle of the 6gb open gop mp4box muxed .mp4 file you made in step 2 take? If it is properly seeking it should also be roughly 1/2 a second as well. If it is, I'll consider the issue something on my end and closed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a question. I couldnt tell by quickly looking at the code and I know of nothing that parses .mp4 files with enough detail to check the stream itself. From what you told me the spec says that marking recovery points as keyframes is not the right thing to do. That they should be marked as something else.. Does mp4box actually mark the frames as such? Im trying to figure out if my playback devices (xbox 360 and mpchc) are just not acknowledging this or is mp4box not writing these sync points to the stream. do you have a url that shows the 2010 discussion of open-gop you mentioned on d9?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There have been proposals at MPEG in 2010, for instance a solution including the number of frames you need to decode before being able to display all content (this also causes complexity when the mux is not the encoder). See proposal as an example M17844 if you have access to MPEG working files.
When you use mp4box through x264, x264 marks all open/closed gops as sync points. This is stricto sensus incorrect, but practically produces the behaviour you expect. That's why I advised to add audio on an existing mp4 file (using 'mp4box -add') produced via x264. I have an early patch somewhere to have the same behaviour directly with mp4box, but as the x264 solution exists, I'd rather prefer mp4box to remain fully compliant with the MPEG specs.
I hope it's clearer for you,
Romain
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank goodness I found this thread. Well that explains a lot. Question about this issue though. Since the recovery point SEIs are not flagged as seekable in MP4Box, is the player suppose to automatically use these recovery points?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There's news on this topic: add ":forcesync" to your import to mark all possible sync points:
"forces non IDR samples with I slices to be marked as sync points (AVC GDR)"
"!! RESULTING FILE IS NOT COMPLIANT WITH THE SPEC but will fix seeking in most players"
Hi, i tried the :forcesync option on one file that would not seek when muxed to mp4. The result was, that seeking was now possible, but the playback was "rocky", stopping from time to time and heavy blocking was visible.
The command looks OK, but it's hard to say what the pb could be. Which player(s) have you been testing the file with ? Could you post the file somewhere ?
One way of detecting OpenGOPs is to extract/import the h264 track with MP4Box and check the result … but it's not very elegant I admit.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is what Mediainfo says about the original mkv:
General
Unique ID : 20…
Complete name : INFO\test.mkv
Format : Matroska
Format version : Version 2
File size : 1.37 GiB
Duration : 1h 1mn
Overall bit rate : 3 193 Kbps
Encoded date : UTC 2011-11-02 19:24:17
Writing application : mkvmerge v3.1.0 ('HELLO KITTY') gebaut am Feb 16 2010 03:12:16
Writing library : libebml v0.7.9 + libmatroska v0.8.1
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 1mn
Bit rate : 2 994 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.135
Stream size : 1.26 GiB (92%)
Writing library : x264 core 85 r1442tw
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=6 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 /
When fed a raw h264 file, it seems mp4box does not support opengop fully. The code does parse recovery point seis but does not flag as a key frame. If i remove the line that stops i-frames with RPs from being flagged as keyframes, the resulting output jumps (pauses 1/2 a second and then plays on) at keyframes. when .mp4 output is used with x264 instead of raw, (x264 uses libgpac) x264 flags isRAP==true for open gop frames that have recovery points and the output plays with no problems and seeks fine.
I also wanted to mention an unmodified mp4box will error out if the file is long enough. I presume it has difficulty dealing with what it perceives as no keyframes for the entire duration of the file. (some variable(s) get overloaded?)
Hi,
I tried to encode foreman with x264 rev 1683 from http://x264.nl/.
x264.exe -keyint 24 -bframes 2 -B 500 -open-gop normal -o foreman_normal.h264 foreman.yuv -input-res 352x288
then
MP4Box -add foreman_normal.h264 foreman_normal.mp4
VLC (1.1.0) plays it smoothly.
Could you please provide us a sample file/command-line so that we can reproduce the problem.
Thanks.
Romain
The default behavior (UNMODIFIED mp4box) is the inability to seek to recovery points, and on very long files (movie duration files around 3 gigabyte or greater) mp4box will not even complete mux.
The stuttering only occured when i attempted to fix it by commenting out line 3880 (approximately) in media_import.c "//avc.sei.recovery_point.valid = 0;" The mux no longer crashes but then I get the stuttering. It was a guess at a way to fix the crash and seeking issue but apparently not the right way.
1) I could seek to recovery points with VLC. That's why I'm asking for the possibility for you to upload a .264 file.
2) I'll try to mux a big big file.
3) I saw the stuttering a few weeks ago. It happens when MP4Box looks endlessly for a RAP. I'll have a look to make it clearer.
4) It's the good function but unfortunately your fix only impacts the first NAL unit. Nice try anyway, thank you :-)
Romain
http://www.mediafire.com/?iuafrotdk64huf5 raw
http://www.mediafire.com/?ka6l91mrc9w8726 mp4
is an example of a short stream. if you are able to make a bigger stream for yourself that would be great. This issue has been present since i started open gop and was still present as of the last beta build.
1. The ultimate fix needs to work on platforms i cant alter like my xbox 360 which doesnt allow for settings to change. x264s libGPAC mp4s play and seek fine on the xbox..mp4box' open gop mp4s wont seek on anything i have software or hardware.
2. Thanks
3. hmmm
4. Hehe. An attempt at fixing it without having to learn the code. Unfortunately crossing my fingers didnt help any. ;)
Ok thanks!
1) I tried your mp4 + muxing with both a 6 months-old MP4Box and a recent one the raw 264. The 3 resulting MP4 files work and seek with VLC 1.1.0 and Osmo4 (GPAC windows player).
The time you wait when seeking depends on the implementation of the player (sometimes you seek to a frame that is in the middle of the GOP and need to decode several frames before reaching the one you asked for), it is around half a second for each one, which is acceptable to me.
At the moment I still can't reproduce your bug.
2) a 6GB file works. I need a file that would show the bad behaviour if you see it again.
3) The stuttering appeared when cutting files with MP4Box. I am told this bug was closed.
My seek time on the mp4 (3/4 in for example) is 11 seconds, but I have an old AMD x2. On a closed gop seek my seek time is 1/2 second. How long does a seek to the middle of the 6gb open gop mp4box muxed .mp4 file you made in step 2 take? If it is properly seeking it should also be roughly 1/2 a second as well. If it is, I'll consider the issue something on my end and closed.
I re-tried with the big file as you suggested and I have finally understood ;-)
I'll have a look and provide updates via this thread.
Romain
I have a question. I couldnt tell by quickly looking at the code and I know of nothing that parses .mp4 files with enough detail to check the stream itself. From what you told me the spec says that marking recovery points as keyframes is not the right thing to do. That they should be marked as something else.. Does mp4box actually mark the frames as such? Im trying to figure out if my playback devices (xbox 360 and mpchc) are just not acknowledging this or is mp4box not writing these sync points to the stream. do you have a url that shows the 2010 discussion of open-gop you mentioned on d9?
mp4box doesn't mark what you call "open-GOP" in any way. In h264 this is a non-sense, as there is no I-picture, only I-slices (see this feature of x264 for an advanced example: http://git.videolan.org/?p=x264.git;a=commit;h=52a4fbe142926435571fbf2fb3d535e8873627d3).
There have been proposals at MPEG in 2010, for instance a solution including the number of frames you need to decode before being able to display all content (this also causes complexity when the mux is not the encoder). See proposal as an example M17844 if you have access to MPEG working files.
When you use mp4box through x264, x264 marks all open/closed gops as sync points. This is stricto sensus incorrect, but practically produces the behaviour you expect. That's why I advised to add audio on an existing mp4 file (using 'mp4box -add') produced via x264. I have an early patch somewhere to have the same behaviour directly with mp4box, but as the x264 solution exists, I'd rather prefer mp4box to remain fully compliant with the MPEG specs.
I hope it's clearer for you,
Romain
Thank goodness I found this thread. Well that explains a lot. Question about this issue though. Since the recovery point SEIs are not flagged as seekable in MP4Box, is the player suppose to automatically use these recovery points?
There's news on this topic: add ":forcesync" to your import to mark all possible sync points:
"forces non IDR samples with I slices to be marked as sync points (AVC GDR)"
"!! RESULTING FILE IS NOT COMPLIANT WITH THE SPEC but will fix seeking in most players"
Commit 3835: https://sourceforge.net/apps/trac/gpac/changeset/3835/
Romain
Hi, i tried the :forcesync option on one file that would not seek when muxed to mp4. The result was, that seeking was now possible, but the playback was "rocky", stopping from time to time and heavy blocking was visible.
This was the command that i used:
mp4box.exe -add "TEMP\test_0.h264:fps=23.976:forcesync" -add "TEMP\test_1.ac3" -add "TEMP\test_2.aac" "TEMP\test.mp4"
Did I do something wrong?
Is there some good way to check if a file "suffers" from open GOP?
Thanks!
The command looks OK, but it's hard to say what the pb could be. Which player(s) have you been testing the file with ? Could you post the file somewhere ?
One way of detecting OpenGOPs is to extract/import the h264 track with MP4Box and check the result … but it's not very elegant I admit.
This is what Mediainfo says about the original mkv:
General
Unique ID : 20…
Complete name : INFO\test.mkv
Format : Matroska
Format version : Version 2
File size : 1.37 GiB
Duration : 1h 1mn
Overall bit rate : 3 193 Kbps
Encoded date : UTC 2011-11-02 19:24:17
Writing application : mkvmerge v3.1.0 ('HELLO KITTY') gebaut am Feb 16 2010 03:12:16
Writing library : libebml v0.7.9 + libmatroska v0.8.1
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 1mn
Bit rate : 2 994 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.135
Stream size : 1.26 GiB (92%)
Writing library : x264 core 85 r1442tw
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=6 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 /
me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=30 / sliced_threads=0 / nr=0 /
decimate=1 / mbaff=0 / constrained_intra=0 / bframes=6 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=1 / wpredb=1 / wpredp=0 / keyint=240 / keyint_min=24 /
scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=2994 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 /
cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No
Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : A_AC3
Duration : 1h 1mn
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 84.6 MiB (6%)
Default : Yes
Forced : No
From the information, it seems you are using an older version of MKVMerge and x264. Maybe updating either or both would help.
Scratch that, forgot you were just changing containers.