Hi, I have noticed that with the new version 2.6.19 of Avidemux for Windows 64 bit using XVID video files so generated have some microlag/stuttering. With the old 2.6.18 all is ok. After several tests I have noticed that the problem exists only with files with certain framerates, 23.x or 24.x. With 25 or 60 fps no problems, at least from what I could see.
I'm surprised, nothing has changed about this
Are you generating mkv or avi ?
AVI
If you copy the content to a mkv, does the stutter disappear ?
If I use MKV Muxer instead of AVI Muxer videos generated are smooth. But if I load a previously encoded avi and then I copy the video part in mkv file then this video remain with lag. Also I saw a strange thing: videos with 23,976 or 24 fps are changed in 24,390 fps, so Mediainfo says. Maybe is this the problem? But mkv are smooth even with 24,390 fps issue...
I have just done the same tests using the 2.6.18 version and all is fine, no lag/stutter and the framerate remain the same of original videos.
I can't reproduce the fps change, don't see any stuttering.
For example:
video encoded with 2.6.18:
Video
ID : 0
Formato : MPEG-4 Visual
Profilo formato : Advanced Simple@L4
Impostazioni formato, BVOP : Si
Impostazioni formato, QPel : No
Impostazioni formato, GMC : No warppoints
Impostazioni formato, Matrix : Default (H.263)
ID codec : DIVX
ID codec/Informazioni : Project Mayo
ID codec/Suggerimento : DivX 4
Durata : 43s 333 ms
Bitrate : 18,9 Mb/s
Larghezza : 1.920 pixel
Altezza : 1.080 pixel
Rapporto aspetto visualizzazione : 16:9
Frame rate : 24,000 FPS
Spazio colore : YUV
Croma subsampling : 4:2:0
Profonditàbit : 8 bit
Tipo scansione : Progressivo
Modo compressione : Con perdita
Bit/(pixel*frame) : 0.380
Dimensione della traccia : 97,6MiB (97%)
Compressore : XviD 64
video encoded with 2.6.19:
Video
ID : 0
Formato : MPEG-4 Visual
Profilo formato : Advanced Simple@L4
Impostazioni formato, BVOP : Si
Impostazioni formato, QPel : No
Impostazioni formato, GMC : No warppoints
Impostazioni formato, Matrix : Default (H.263)
ID codec : DIVX
ID codec/Informazioni : Project Mayo
ID codec/Suggerimento : DivX 4
Durata : 43s 255 ms
Bitrate : 18,9 Mb/s
Larghezza : 1.920 pixel
Altezza : 1.080 pixel
Rapporto aspetto visualizzazione : 16:9
Frame rate : 24,390 FPS
Spazio colore : YUV
Croma subsampling : 4:2:0
Profonditàbit : 8 bit
Tipo scansione : Progressivo
Modo compressione : Con perdita
Bit/(pixel*frame) : 0.374
Dimensione della traccia : 97,6MiB (97%)
Compressore : XviD 64
The microlags can be seen especially during horizontal or vertical panning, every few seconds there is a little interruption of the movement. It is clearly visible both on the pc (I use MPC-BE as video player) and especially on my tv.
Well, I couldn't find any 24 fps videos in my archive yet. You mentioned 23.976 fps changed into 24.390 fps, and this is exactly what is not happening according to my testing. Obviously, fps may not be modified in copy mode, and if this value is changed, the problems you describe would arise.
I have made some test files so if you want you can donwload them:
original video:
https://app.box.com/s/elhyvn0tvlxepoe9sbk6rcumy1b1ltfh
video encoded using 2.6.18:
https://app.box.com/s/9opszt7cdko385u6lqnh3vfpusp44o3x
video encoded using 2.6.19:
https://app.box.com/s/tni98lz1osbzy1nswbm7tw1fyqkbsuf6
If you compare the two videos you can see that they aren't exactly the same, some stutter appears every few seconds in 2.6.19, it is not very noticeable but it's quite annoying.
It's not obvious what change triggered that
This has nothing to do with xvid as Avidemux misdetects the fps as 24.390 already when loading the video. When saving "Original.mkv" in copy mode, Avidemux sets fps to 1000 (really, 1k), when reencoding with AVI as target container, the fps is set to the wrong value, is respected by players and causes stuttering no matter which codec. When reencoding with MKV as target container, the fps is set to 1k, gets ignored by players I tried and plays fine.
This is a demuxer bug. Partially reverting [mkv/demux] slightly better recomputation of delay and frame duration, still not perfect (https://github.com/mean00/avidemux2/commit/960e9ecb49664b516ea91c3e7bb6848f44549b57)
git diff avidemux_plugins/ADM_demuxers/Matroska/ADM_mkv.cpp
diff --git a/avidemux_plugins/ADM_demuxers/Matroska/ADM_mkv.cpp b/avidemux_plugins/ADM_demuxers/Matroska/ADM_mkv.cpp
index 540558f..14f802e 100644
--- a/avidemux_plugins/ADM_demuxers/Matroska/ADM_mkv.cpp
+++ b/avidemux_plugins/ADM_demuxers/Matroska/ADM_mkv.cpp
@@ -307,7 +307,7 @@ bool mkvHeader::ComputeDeltaAndCheckBFrames(uint32_t *minDeltaX, uint32_t *maxDe
ADM_info("Default duration %" PRId64" us\n",track->_defaultFrameDuration);
if(minDelta)
{
- if(minDelta<track->_defaultFrameDuration && labs((long int)minDelta-(long int)track->_defaultFrameDuration)>100)
+ if(minDelta<track->_defaultFrameDuration && labs((long int)minDelta-(long int)track->_defaultFrameDuration)>1000)
{
ADM_info("Changing default frame duration from %" PRIu64" to %" PRIu64" us\n",
track->_defaultFrameDuration,minDelta);
would fix this for the MKV demuxer. When remuxed as MP4, the wrong value originated from the MP4Header::refineFps function.
That would re-enable the other bug
In a nutshell :
* Avidemux needs to have the minimum period between two frames, does not have to be perfect, but <= the real value
* AVI only have that period as timing information, if it is wrong, you'll get stuttering etc...
* MKV has that info optionally, but does not really needs it, so if it is slightly wrong, the players wont care much
Thanks, I meant that it was the fix for that bug (http://avidemux.org/smif/index.php/topic,17616.0.html) that influenced how Avidemux behaves here (i.e. arriving at a fps value which disagrees with ffmpeg). Would it work be better to assume fps = average fps and treat max fps separately, e.g. for aviInfo? Finally, setting fps in copy mode to 1k doesn't look right (I'll return to GUI and console output polish in a few days :-)).
The new fps determining logic works great for many files, thank you, but disagrees with ffprobe about the sample in http://avidemux.org/smif/index.php/topic,17616.0.html (http://avidemux.org/smif/index.php/topic,17616.0.html):
[ComputeDeltaAndCheckBFrames] 01:06:28-948 PTS is not monotonous, there are bframe
[ComputeDeltaAndCheckBFrames] 01:06:28-948 Duplicate PTS...(0 and 1,size=1014 41)
[getStdFrameRate] 01:06:28-948 Best match is -1
[checkDeviation] 01:06:28-948 Num=1000 Den=23810 half=20998 zero=0 first=0
[checkDeviation] 01:06:28-950 Den=23810 Num=1000 Good = 18009, bad=16373
[checkDeviation] 01:06:28-950 Num=41000 Den=1000000 half=20499 zero=0 first=0
[checkDeviation] 01:06:28-953 Den=1000000 Num=41000 Good = 18450, bad=15932
[ComputeDeltaAndCheckBFrames] 01:06:28-953 Deviation = 16373
[ComputeDeltaAndCheckBFrames] 01:06:28-953 DeviationMinDelta = 15932
[ComputeDeltaAndCheckBFrames] 01:06:28-953 Min delta is better
[ComputeDeltaAndCheckBFrames] 01:06:28-953 Old default duration 41999 us
[ComputeDeltaAndCheckBFrames] 01:06:28-953 New default duration 41000 us
[ComputeDeltaAndCheckBFrames] 01:06:28-953 First frame pts 0 us
[ComputeDeltaAndCheckBFrames] 01:06:28-953 Not enough valid DTS
[open] 01:06:28-953 Have to delay by 208000 us so that PTS>DTS
ffprobe identifies fps*1000 as 23810.
The issue with fps in copy mode set to 1000 fps could be related to the new ffmpeg (unsure).
Mkv fps import should be much better now
The heuristic should correctly derive the actual fps and update the timestamps accordingly
Normally no
Mkv has a built-in accuracy of 1ms
MP4 is using rational, so if the file has been properly created, it is exact
I've split the topic