I'm taking the Chapter Data from my MKV's and using the time-codes directly to make chapter files for my iPhone MP4 conversions and to make qpfiles to feed into X264 to ensure there are I-frames at the Chapter Markers. However, I just played one MP4 using VLC and upon skipping chapters, one of the chapters begins one frame before where it ought to be. I've looked at the file using AVIDemux and it says there is an I-frame at the right spot, however the time-code is wrong, but AVIDemux seems to be skipping quite a few frames at the beginning that are in the UT Video Codec source and it says the time-code of the first frame is 120ms, I'm not sure what to make of that... The MKV version works perfectly. I'm having trouble examining the various versions and looking for differences as AVIDemux seems to be doing really weird things (wrong time-codes, missing frames, reporting EVERY frame as an I-frame, *sigh*) is there a better program for doing this? Does anyone have any insight on this? Are MKV time-codes and MP4 time-codes the same? (There are no container level delays in any of the files, but the original MakeMKV file begins with 2 b-frames, which I extract with MKVEXtract and which I believe MPEG2Source converts to actual frames. There's no frame-rate conversion and the video is 25fps PAL so I don't see how there could be any rounding issues.) I'm a little confused at the moment, why is VLC beginning that chapter 1 frame early? Any ideas...
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 1 to 16 of 16
Thread
-
-
Are you certain sure they are IDR frames "I" at the markers, not "i" frames ? AVIDemux won't distinguish between the two
Explain in more detail your exact steps. Is it something like
DVD => MakeMKV => MKVExtract => MPEG2Source => UT video => Something else ? => x264 ?
I've seen MakeMKV sometime make errors from MPEG2 sources -
DVD->MakeMKV->(Correct Chapters with mmg chapter editor)->MKVMerge->MKVExtract->MPEG2Source->Double Rate TFM + QTGMC {50.000FPS}->VirtualDub->UT Video AVI->TDecimate {25.000FPS}->VirtualDub->UT Video->Chapters Extracted From Source MKV and converted directly to MP4 Chapters (ttxt and txt(Nero)) and a QPFile->avs2pipemod->X264->MP4Box
qpfile:
Code:1538 I 14050 I 21217 I 30988 I 31738 I
Code:00:00:00.000 : "Beast Wars" 00:01:01.520 : Part 1 00:09:22.000 : Part 2 00:14:08.680 : Part 3 00:20:39.520 : Next Time... 00:21:09.520 : Credits
-
OK, if I pause VLC and use the Next/Prev Chapter buttons I can see that the 'Part 1', 'Next Time...' and 'Credits' chapters all start too early, in fact 'Next Time...' starts at least 7 frames too early. Whereas 'Part 3' starts at exactly the right time - which I can verify by pressing the VLC's 'Next Frame' button.
I'm going to pause my batches and check the variables, I may have done something stupid with the qpfiles, but AVIDemux is being a pain.Last edited by ndjamena; 24th Apr 2014 at 16:44.
-
Instead of checking with avidemux , you can check with ffms2 / avisynth to see if an I frame was placed where you specified
FFInfo() will give you the frame type and running timecode , but won't distinguish between IDR/ non keyframe "i" frames
If you want to be super duper accurate (if you're going to be seeking fwd/backwd) , you can set FFVideoSource's seekmode=0, but it will be very slooooow
e.g
FFVideoSource("file.ext")
FFInfo()
Just curious - Why are you splitting out the TDecimate() as a separate step? -
OK, FFVideoSource reports that the frame 'Part 2' is supposed to begin at has a time-code of 'CRF Time: 0:09:22.000' 'VFR Time: 0:09:22.120' and has a Picture Type of I. Whereas if I play that same MP4 in VLC, pause it, then press 'next chapter' until I get to the 'Part 2' marker, I then have to press 'Next Frame' five times to get to the correct frame...
I know what I'm thinking... does anyone see any alternative explanations?
-edit- VFR is 3 frames later than the chapter time-code, which means 'VFR 0:09:22.000' would be three frames earlier, which is in the middle of a gop and VLC is terribly inaccurate when seeking into the middle of GOPs, generally starting a few frames early... WTF is VFR in this context??? How do I fix this???? And why does 'Part 3' start at the right frame when it's VFR is 120 ms ahead too...Last edited by ndjamena; 24th Apr 2014 at 16:45.
-
VFR is variable frame rate. It means it thinks that the time codes aren't constant 25 FPS
-
-
VFR and CFR are exactly the same in the MKV, and MPC-HC seeks to the correct frame in the MP4.
The Command Line looks like this:
"C:\Program Files (x86)\GPAC\MP4Box.exe" -ipod -add "D:\Videos2\Beast Wars - 01x08 - Double Jeopardy\iPhone\Video 1.h264:fps=25.000:delay=0:lang=en:name=AVC/H.264/MPEG4 Part 10 (25.000 fps):enable:group=1" -add "D:\Videos2\Beast Wars - 01x08 - Double Jeopardy\iPhone\Audio 1.m4a:delay=0:lang=eng:group=2:enable:name=English AAC(2.0)" -add "D:\Videos2\Beast Wars - 01x08 - Double Jeopardy\Chapters.ttxt:chap" -chap "D:\Videos2\Beast Wars - 01x08 - Double Jeopardy\Chapters.txt" -itags tool="NDJMux" -new "F:\iPhone\Beast Wars\Season 01\Beast Wars - 01x08 - Double Jeopardy.mp4"
So, what am I dealing with?
-Edit- hmmm, should I be adding FPS with a decimal point, that's how MediaInfo outputs it... -
How was MPCHC configured? eg. using lav splitter / decoder ?
What way does the MP4 behave on the iphone ?
It's probably something about the way mp4box is muxing that ffmpeg based programs don't like
To be clear, when you are using FFInfo() , when VFR time = CFR time the whole way through, that means it's CFR for the file . When there are sections/frames that VFR time doesn't equal CFR time, then that section is variable (at least when read by ffmpeg) -
It doesn't make sense to me why you are getting those results with mp4box, but you can try a different mp4box build (maybe something wrong with your binary), you can try a different muxer (e.g. lsmash) , you can try muxing in CFR timecodes from the mkv (maybe using mp4fpsmod - normally it's used for making VFR MP4's but if the timecodes are CFR, it will force CFR), you can try remuxing with ffmpeg with -video_track_timescale 25
-
-
It turns out it's the 64-bit version of AVIDemux that's the problem, I downloaded the 32-bit version and it seems to be working fine. Does AVIDemux depend on system codecs/demuxes? Should I be rethinking Shark007? Anyway, AVIDemux uses the 'VFR' time-codes as well, according to it the first frame is at 120ms. I've posted on the GPAC forums asking if there's anything I can do about that in MP4Box. I don't understand where this extra 120ms is coming from.