x264 Encoder messes up the Framerate of a file:
Avidemux 2.6.1 SVN r8473 (32-bit)
#PY <- Needed to identify #
#--automatically built--
adm = Avidemux()
adm.loadVideo("I:/TEST/test_ORIGINAL.mp4")
adm.clearSegments()
adm.addSegment(0, 0, 147984000)
adm.markerA = 0
adm.markerB = 147984000
adm.videoCodec("x264", "general.params=2PASSBITRATE=1000", "general.threads=99", "general.fast_first_pass=True", "level=4294967295", "vui.sar_height=1", "vui.sar_width=1", "MaxRefFrames=3", "MinIdr=25", "MaxIdr=250", "i_scenecut_threshold=30"
, "intra_refresh=False", "MaxBFrame=16", "i_bframe_adaptive=2", "i_bframe_bias=0", "i_bframe_pyramid=2", "b_deblocking_filter=True", "i_deblocking_filter_alphac0=0", "i_deblocking_filter_beta=0", "cabac=True"
, "interlaced=False", "constrained_intra=False", "tff=True", "fake_interlaced=False", "analyze.b_8x8=True", "analyze.b_i4x4=True", "analyze.b_i8x8=True", "analyze.b_p8x8=False", "analyze.b_p16x16=True"
, "analyze.b_b16x16=True", "analyze.weighted_pred=2", "analyze.weighted_bipred=True", "analyze.direct_mv_pred=3", "analyze.chroma_offset=0", "analyze.me_method=2", "analyze.me_range=16", "analyze.mv_range=32"
, "analyze.mv_range_thread=-1", "analyze.subpel_refine=8", "analyze.chroma_me=True", "analyze.mixed_references=True", "analyze.trellis=2", "analyze.psy_rd=0.000000", "analyze.psy_trellis=0.000000", "analyze.fast_pskip=False"
, "analyze.dct_decimate=True", "analyze.noise_reduction=0", "analyze.psy=True", "analyze.intra_luma=21", "analyze.inter_luma=21", "ratecontrol.rc_method=0", "ratecontrol.qp_constant=0", "ratecontrol.qp_min=0"
, "ratecontrol.qp_max=69", "ratecontrol.qp_step=4", "ratecontrol.bitrate=0", "ratecontrol.rate_tolerance=1.000000", "ratecontrol.vbv_max_bitrate=0", "ratecontrol.vbv_buffer_size=0", "ratecontrol.vbv_buffer_init=0"
, "ratecontrol.ip_factor=1.400000", "ratecontrol.pb_factor=1.300000", "ratecontrol.aq_mode=2", "ratecontrol.aq_strength=1.000000", "ratecontrol.mb_tree=True", "ratecontrol.lookahead=50")
adm.audioClearTracks()
adm.audioAddTrack(0)
adm.audioCodec(0, "copy");
adm.audioSetDrc(0, 0)
adm.audioSetShift(0, 0,0)
adm.setContainer("MP4V2", "optimize=0", "add_itunes_metadata=0")
Original: http://rapidshare.com/files/3287447012/original_short.mp4
Encode: http://rapidshare.com/files/3639512902/test_x264_short.mp4
Frame rate mode : Variable
Frame rate : 13.220 fps
Original frame rate : 29.970 fps
Minimum frame rate : 9.986 fps
Maximum frame rate : 29.990 fps
FPS are not wrong, both in original and encode files.
They just describe the files situation.
( see Topic 'B-Frames dropped' )
What is wrong, the bug, is B-frame dropped, when encode the file.
Some frames have double (or more) time length to keep time stamp, and thus can have 12,5 FPS instead of 25 FPS for example when original video is Constant Frame Rate.
If the original video have Variable Frame Rate, the result is what you have.
Your mp4 is another example of what I observe, and summarise here :
'Reply 25' in : http://www.avidemux.org/smf/index.php?topic=11822
How was the file created ?
.
Try version > 8485 with preference -> trust timestamp -> dont trust
That worked!
http://rapidshare.com/files/4250121282/test_x264_notrust.mp4
Partial Trust worked as well
Well, I celebrated to early, I just tried to encode a cut version of the complete file. No luck. Encoding looks fine up until the first cut point (I think). I will do some more tests tomorror...
avoid cutting on b frame when trust = partial
only cut on intra when trust=no
Thats the problem. I want to cut advertisment out of a video and have to cut at non I-Frames.
While cuttung under "no-trust" I had some strange frame behavior:
I could not navigate to certain frames I knew that where there. Or pressing the "Frame Foreward" and "Frame Backward" button right after another wouldnt end up at the same frame you started in.
So I tried this workaround:
1. Cut the video in "Trust" mode
2. Save Project
3. Set to "Dont Trust" mode and restart
4. Load Project and encode
The first video I did this way was fine! But the second one ended premeturly at one of the cut points.
So we are getting closer to solving the problem, but are not there yet :)
BTW: Thanks for all the great work you guys do on avidemux!
The problem is that at the moment, only the decoding part is doing the trust/no trust part, but not the seeking part
I'm changing it so that it's global and automatic (i.e. no need to change settings)
8487 contains most of the code to do it properly
Does it work ok ? including editing ?
If yes, i'll finish the code
Appart from the cutting issues in "no Trust" mode mentioned above everything seemd to work fine.
8487 has trust removed, now it is done in depth and should work including cutting
great. i cant wait for the nightly build to test it :)
Should be ready in ~ 30 mn
Do I have to activate something or so? Because I encoded the sample clip with r8488 and it has the same FPS/Bitrate problem :(
Could encode a small piece and look at the log ?
Especially the stats part
ah yes, with your sample does not work
Give me 10 mn
Partially fixed, but if the file is 10 sec of big bang theory, it is really broken
You'll have seeking issue
Well, encoding the sample with r8489 worked. But like you said, I now have seeking issues with ALL files from OTR (www.onlinetvrecorder.com). I dont think this is right. Cutting them always worked before. I used copy mode, but then only rough cuts at I-Frames where possible. Thats why I started looking into Re-Encoding them with avidemux to get clean cutpoints. Is it possible to keep the way during cutting like before, and just for encoding purposes use the new method you introduced?
I'll add a popup to ask what to do
MP4 files contain extra info about timestamps
In some cases (twinsun) they are slightly incorrect
In your files, they are completely non present, so the timing infos are confusing
QuoteBut like you said, I now have seeking issues with ALL files from OTR (www.onlinetvrecorder.com). I dont think this is right. Cutting them always worked before.
What files are you talking about? OTR provides AVI and MP4 output.
Yes, OTR provides AVI. But this AVI is not seeable in Avidemux:
http://rapidshare.com/files/389249004/original.avi
So I convert the AVI to MP4 with FFMPEG (and convert the sound to AAC in the same process):
ffmpeg version: ffmpeg version N-44459-g8bdba0b (but had the same issue with older versions as well)
ffmpeg -i source.avi -map 0 -vcodec copy -acodec aac -strict experimental -sn output.mp4
http://rapidshare.com/files/741355935/convertedtomp4withaac.mp4
This new MP4 was now seekable (r8473). In the new version (r8490) it is not seekable anymore.
I made some encoding tests with this two versions and both files:
r8473 from avi -> Encoding ok (but no cutting possible due to seeking issue)
r8473 from mp4 -> Encoding FPS and Bitrate not ok
r8490 from avi -> Encoding ok (but no cutting possible due to seeking issue)
r8490 from mp4 -> Encoding ok (but no cutting possible due to seeking issue)
http://rapidshare.com/files/779518298/test_h264_r8473_frommp4.mp4
http://rapidshare.com/files/2031841724/test_h264_r8473_fromavi.mp4
http://rapidshare.com/files/2794200367/test_h264_r8490_fromavi.mp4
http://rapidshare.com/files/1155139932/test_h264_r8490_frommp4.mp4
Is there any way to make these files seekable so that you can cut them? Encoding seems to be ok now.
Thanks!
The only option would be to rederive the timestamps, which is a bit slow
That's why storing h264 in avi is not a good idea : seek & a/v sync does not work well as there is not enough timing informations
Since the infos were not there in the avi, ffmpeg could not create them for the mp4
So you end up with a MP4 including bad timing informations
If OTR directly provides mp4s, and if they contain valid timestamp informations it's probably the best to use
Unfortunately OTR provides the files this way :(
- But why was my converted MP4 seekable before and now isnt any more?
- Is there some way to "rebuild" the time index?
- You mentioned something about a popup in this case thats askes what to do (like the trust/no trust option). I did not encounter something like that with these files. Is it in?
Quote from: Spellbinder on February 25, 2013, 12:51:30 PM
ffmpeg -i source.avi -map 0 -vcodec copy -acodec aac -strict experimental -sn output.mp4
This are my settings (posted in another thread)...
Quote from: mean on February 25, 2013, 01:49:27 PM
If OTR directly provides mp4s, and if they contain valid timestamp informations it's probably the best to use
Yep, MP4 are provided, but for premium users only (and in this case the commercials are already cut out, so you don't need Avidemux anymore). But there are some OTR HQ records only provided as AVI.
Quote from: Spellbinder on February 25, 2013, 02:31:34 PM
- But why was my converted MP4 seekable before and now isnt any more?
Yep, that's the point. I will check this next time I get an AVI from OTR. I've indeed given up using Avidemux for cutting AVI files, I use MPEG Streamclip for this task. MPEG Streamclip (actually Quicktime) has no problem to read (or guess) the timestamps correctly.
I made some tests with r8492. Now I get the popup that asks if I want to keep the timing information or not. If I keep them encoding has wrong FPS/Bitrate. If not Encoding is ok but file is not seekable. Is it possible to keep the timing information for seeking/cutting and than drop it for encoding?
Quote from: mean on February 25, 2013, 01:49:27 PM
The only option would be to rederive the timestamps, which is a bit slow
Could you do that please? By adding an option to the popup (keep/discard/rederive) for example.
I have to check how long it would take
If it take 30mn to rederive it is not an option
Even if it would take 30minutes I would take it :)
Especialy if I can automate it with the CLI ;)
I would like to give you some updates on this issue:
I made some tests with other muxing/demuxing software for mp4. I used mp4box to demux these mp4 files with wrong/missing timestmaps to raw files and then muxed them again with mp4box. The result was that these files are perfectly fine in avidemux. I can cut and encode them with no problems.
In other words: I understand now, that this is more a avi or ffmpeg problem than a avidemux problem. I still would find it great if avidemux could handle such videos, but it is not the source of the problem!
So thanks again for all the great work you are doing with avidemux! It is very appriciated!
BTW: Any chance for smart-copying h264 in avidemux? ;)