Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 13th May 2011, 12:55   #1  |  Link
Cyberpro60
Registered User
 
Join Date: Dec 2006
Posts: 40
H264/MP4 Seek Problem

Over the last few weeks I have been bugged by an apparently new problem with .MP4 files which I haven't been able to resolve in spite of not inconsiderable research and effort:

Basically my problem is that some of my newer H264/.MP4 movies seem to play and seek perfectly whereas others will play perfectly but will fall over immediately upon encountering a seek request.

When I say "fall over" this could mean anything from a total player freeze/crash to several minutes of delay whilst the player moves slowly to the desired frames and starts playing again. This delay can be as long as 15 minutes for a longer, movie length, HD video file.

Note: It doesn't seem to matter what player I am using either as VLC, MPlayer, MPC all seem to have this same "seek" problem.

My research has determined the following:

1. If I mux my source .H264/AAC files into an .MKV container then all these videos will BOTH play and seek perfectly in all players - so this seems to be a "container problem"!

2. If I mux or remux into .MP4 format using either MeGui, AviDemux, Yamb etc I end up with a video that plays but which won't seek.

3. I have even re-encoded my source videos using a variety of H264 front ends but all these videos will not seek properly when played in .MP4 format but will work perfectly when muxed to .MKV format.

4. I have "remuxed" my videos with a range of muxing software but this has not resolved this issue.

5. These exact same problems arise on a range of other computers that I have tested so this is not a "machine specific" issue. Ego, this is some inherent problem with these specific MP4 files.

6. I note that I do not seem to be having any of these problems with MP4 files encoded several months ago. All the problem videos are fairly recent (ie within the last three or four months)

I would be grateful if anybody can throw any light on this issue and suggest a fix or workaround.
Cyberpro60 is offline   Reply With Quote
Old 13th May 2011, 16:33   #2  |  Link
roozhou
Registered User
 
Join Date: Apr 2008
Posts: 1,181
How did you mux to a .MP4 file? Have you tried ffmpeg?
roozhou is offline   Reply With Quote
Old 14th May 2011, 03:24   #3  |  Link
Cyberpro60
Registered User
 
Join Date: Dec 2006
Posts: 40
As indicated above I used a variety of mux programs including Yamb, MeGui/MP4Box, Avidemux etc. It made no difference to the end result. And no, I haven't tried FFMPEG but I will do so and see if that changes anything.
Cyberpro60 is offline   Reply With Quote
Old 22nd May 2011, 11:41   #4  |  Link
Cyberpro60
Registered User
 
Join Date: Dec 2006
Posts: 40
I followed your suggestion roozhou and tried to mux with FFMPEG but had no luck whatsoever.

I have to admit that I find FFMPEG almost impossible to use and I have to tell you that I spent quite a few days at it after reading through all the documentation and online help guides ... all to no avail!

I managed to get FFMPEG to encode/mux H264 video from an MPEG original but had no success at all in trying to mux existing H264 & AAC files together.

FMPEG failed every time. I got a bunch of error messages most of which were unintelligible and the muxing process crashed well before conclusion with the resulting video file not playable (gibberish?)

What I can report is that if I create an MP4 file that contains only the H264 video component (no aac) then I can seek from one end of the file to the other without any problems.

When I mux in the video and aac audio component then the original problem I reported resurfaces. I conclude therefore that this strange inability to seek is somehow caused by some inconsistency in the AAC file. What this may be I have no idea.

There has to be some reason why you can seek through some MP4 files but not others and I am surprised that there hasn't been more input on this question!
Cyberpro60 is offline   Reply With Quote
Old 22nd May 2011, 12:01   #5  |  Link
nm
Registered User
 
Join Date: Mar 2005
Location: Finland
Posts: 2,643
Quote:
Originally Posted by Cyberpro60 View Post
There has to be some reason why you can seek through some MP4 files but not others and I am surprised that there hasn't been more input on this question!
Could you provide sample streams that break seeking when muxed to MP4?
nm is offline   Reply With Quote
Old 22nd May 2011, 13:26   #6  |  Link
Cyberpro60
Registered User
 
Join Date: Dec 2006
Posts: 40
I am currently uploading a 3 x 50mb part RAR file to Mediafire. As soon as that process is complete I will post the details here.
Cyberpro60 is offline   Reply With Quote
Old 22nd May 2011, 17:53   #7  |  Link
Cyberpro60
Registered User
 
Join Date: Dec 2006
Posts: 40
Here are the download locations for the sample tracks requested:

http://www.mediafire.com/file/ckxvok...ples.part1.rar
http://www.mediafire.com/file/wm9pj4...ples.part2.rar
http://www.mediafire.com/file/3m52v7...ples.part3.rar
Cyberpro60 is offline   Reply With Quote
Old 22nd May 2011, 18:53   #8  |  Link
VFR maniac
Spinner of yarns
 
VFR maniac's Avatar
 
Join Date: May 2009
Posts: 164
MP4Box doesn't mark non-IDR I-frames as random access points because 14496-15 doesn't allow marking them as sync samples.
Seeking of H.264/AVC stream with Open-GOP in MP4 is incomplete on its spec currently.
The solution of this will be defined in 14496-12:2008/Amd.3 (under 'iso6' brand).
So I recommend you should avoid AVC-in-MP4 with Open-GOP at present.
__________________
僕と契約して、L-SMASH developerになってよ!
L-SMASH | L-SMASH Works | Opus-in-ISOBMFF specification and reference software

Last edited by VFR maniac; 22nd May 2011 at 19:28.
VFR maniac is offline   Reply With Quote
Old 23rd May 2011, 03:26   #9  |  Link
Cyberpro60
Registered User
 
Join Date: Dec 2006
Posts: 40
Er, I guess I should thank VFR maniac for his response and I would do so except that I haven't the faintest clue what he was actually saying.

I guess you could say that I am somewhat technically ignorant but could you please explain what are "non-IDR I-frames"? Also, am I right in assuming that "14496-15" is part of the current technical spec for .MP4 files?

VFR Maniac also suggests: "So I recommend you should avoid AVC-in-MP4 with Open-GOP at present" but what does that mean in practical terms and how does this explain why some MP4 files seek perfectly and others do not?

Also, if you could tell me what am I doing wrong and what do I have to do to do it correctly I would be eternally grateful. Note that I have trouble with these few files using not only MP4Box but a whole raft of other muxing programs.
Cyberpro60 is offline   Reply With Quote
Old 23rd May 2011, 05:27   #10  |  Link
RunningSkittle
Skittle
 
RunningSkittle's Avatar
 
Join Date: Mar 2008
Posts: 539
solution: Dont use open gop in mp4
RunningSkittle is offline   Reply With Quote
Old 23rd May 2011, 08:43   #11  |  Link
Cyberpro60
Registered User
 
Join Date: Dec 2006
Posts: 40
Haha .... the only open GOP's that I am familiar with are on the kid's faces at dinner time

Seriously though .... I assume having open or closed "GOPs" is one of the many setting that can be made when an H264 file is first created (although I don't remember having seen any direct reference to them).

Unfortunately the files that I am having difficulties with were not created by me in the first instance but came already encoded in .MKV format. Presumably these H264 tracks come with these dreaded open GOPs referred to above.

I am curious though why you can seek in the MKV format whilst you can't do that when the very same video track is encoded into .MP4? It also doesn't explain why I can seek when the MP4 file contains only a video track but falls over when an AAC audio track is muxed in as well.

Also, short of re-encoding all these files shutting all these open GOPs is there any other way of fixing this problem?
Cyberpro60 is offline   Reply With Quote
Old 23rd May 2011, 09:40   #12  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 5,814
Here are my two cents:

Have you read: http://forum.doom9.org/showthread.php?t=146492 ? (if not do)

Quote:
is there any other way of fixing this problem?
VFR maniac stated: 'MP4Box doesn't mark non-IDR I-frames as random access points'
Manao stated (in the thread linked above): 'Seeking : you can still seek on open GOP (provided the encoder inserted a random access point indicator, or a recovery point SEI)'
so combining these two statements your problem should be fixed if you find a muxer that contrary to the MP4 file format standard sets 'random access point indicator, or a recovery point SEI' for NON-IDR I-Frames,.. (+ the splitter/decoder combination also needs to accept these non standard files)
mkv works because it doesn't have to obey 14496-15 aka. the MP4 file format standard since it's not a mp4 file,..

Quote:
It also doesn't explain why I can seek when the MP4 file contains only a video track but falls over when an AAC audio track is muxed in as well.
Got no clue about that one.

So if you have/need to use .mp4 as container re-encoding and not using 'open gop' is probably the safest way.

Cu Selur
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 23rd May 2011, 10:41   #13  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,340
In mediainfo you can see whether open-gop was used or not if the file was encoded with x264. But x264cli and most GUIs have open-gop disabled by default, so chances are this might not be the problem after all. (But look for yourself)
sneaker_ger is offline   Reply With Quote
Old 23rd May 2011, 11:13   #14  |  Link
Cyberpro60
Registered User
 
Join Date: Dec 2006
Posts: 40
Many thanks Selur for your insightful comments.

I read the article you referred to at http://forum.doom9.org/showthread.php?t=146492 and it really did throw a little light on the problem so, thanks for that. I now have a much clearer picture of the sorts of issues that might be in operation here.

The reference in the posting from LoRd_MuldeR (http://forum.doom9.org/showthread.php?t=146269) was quite useful to me as well.

@sneaker_ger. Given the experiences I have had with this problem so far I have a gut feeling that you may be absolutely spot on. Accordingly I will follow up your suggestion and use MediaInfo to examine these files and see what I can discover.

Stay tuned as I will post the results of these investigations shortly.
Cyberpro60 is offline   Reply With Quote
Old 23rd May 2011, 11:27   #15  |  Link
nm
Registered User
 
Join Date: Mar 2005
Location: Finland
Posts: 2,643
Quote:
Originally Posted by sneaker_ger View Post
In mediainfo you can see whether open-gop was used or not if the file was encoded with x264. But x264cli and most GUIs have open-gop disabled by default, so chances are this might not be the problem after all. (But look for yourself)
Cyberpro's sample stream was encoded with open-gop enabled.
nm is offline   Reply With Quote
Old 23rd May 2011, 12:17   #16  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,340
Quote:
Originally Posted by nm View Post
Cyberpro's sample stream was encoded with open-gop enabled.
You're correct. But that doesn't explain why seeking works in video-only files. I'm not denying open-gop being a possible culprit, only saying that he should check with mediainfo on all his files whether it really is or is not.
sneaker_ger is offline   Reply With Quote
Old 23rd May 2011, 13:12   #17  |  Link
nm
Registered User
 
Join Date: Mar 2005
Location: Finland
Posts: 2,643
Quote:
Originally Posted by sneaker_ger View Post
You're correct. But that doesn't explain why seeking works in video-only files.
Actually seeking doesn't work for me if I mux the open-gop H.264 stream alone with MP4Box.


But ffmpeg seems to mark non-IDR I-frames as random access points and seeking works with VLC at least -- MPlayer shows one or two blocky frames after a seek. Command-line:
Code:
ffmpeg -i Sample_Track1.h264 -i Sample_Track3.aac -acodec copy -vcodec copy out.mp4
Dunno if there are other problems in the output or if it fails on some inputs.
nm is offline   Reply With Quote
Old 23rd May 2011, 13:40   #18  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,340
Quote:
Originally Posted by nm View Post
Actually seeking doesn't work for me if I mux the open-gop H.264 stream alone with MP4Box.
You're correct again, I hadn't tested it myself - only trusted the thread starters word.
sneaker_ger is offline   Reply With Quote
Old 23rd May 2011, 14:24   #19  |  Link
VFR maniac
Spinner of yarns
 
VFR maniac's Avatar
 
Join Date: May 2009
Posts: 164
x264cli marks 'key-frames' as sync points even if they are not IDR-frames.
('key-frame' is a random accessible frame in x264's term.)
This will work but, of course, this is spec violation.


It can say there are two types of random access.
1) IDR (Instantaneous Decoding Refresh)
2) GDR (Gradual Decoding Refresh)

Open-GOP is the special case of GDR, where recovery_frame_cnt (the number of frames necessary to be correct in output order from the SEI) is 0.

It is discussed and declared on 93rd meeting that we prefer a new sample group (‘rap ‘?), which documents random access points which might not be sync points.

Each of them is signaled as random accessible point by different ways in MP4/ISO Base Media file format.
IDR: sync sample table ('stss')
GDR: roll recovery grouping ('roll')
IDR and Open-GOP: random access point grouping ('rap ')

'stss' and 'roll' are already defined publicly in ISO/IEC 14496-12.
However, amendment for 'rap ' is still on a draft.
So the implementation of random access for Open-GOP in MP4 is dangerous in the present stage.
__________________
僕と契約して、L-SMASH developerになってよ!
L-SMASH | L-SMASH Works | Opus-in-ISOBMFF specification and reference software

Last edited by VFR maniac; 23rd May 2011 at 16:09.
VFR maniac is offline   Reply With Quote
Old 25th May 2011, 03:25   #20  |  Link
Cyberpro60
Registered User
 
Join Date: Dec 2006
Posts: 40
I have completed my investigations of my suspect mp4 files and wish to report that VFR maniac was absolutely correct in identifying that the problem was caused by "Open GOP's". This proved to be the case in all but one of my suspect files. MediaInfo for these files followed the following basic pattern:

Encoding settings : cabac=1 / ref=5 / deblock=1:-3:-3 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=64 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=9 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=2 / weightp=2 / keyint=360 / keyint_min=2 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=17930 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=50000 / vbv_bufsize=50000 / nal_hrd=none / ip_ratio=1.40 / aq=1:1.00

On this basis I re-compiled each of these files using FFMPEG and produced a final output file that both plays and seeks normally so I think was can safely say that my problem has been resolved satisfactorily. My thanks go to all who participated in this discussion.

I have two small niggling questions though: When I recompile using FFMPEG and run the final output through MediaInfo there is no listing for "encoder settings" and therefore no way to determine if this file has open or closed GOPs. Can anybody explain this please?

Also, I do know that during my experimental/testing phase I was able to get at least one suspect file to play and seek if the video included only video and no audio track. I have yet to replicate that result but will try and do so shortly and report back on my investigations.

Last edited by Cyberpro60; 25th May 2011 at 03:28.
Cyberpro60 is offline   Reply With Quote
Reply

Tags
mp4, seek problem

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 16:27.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.