Microlag with XVID codec in 2.6.19 version.

[Steve23]

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.

[mean]

I'm surprised, nothing has changed about this
Are you generating mkv or avi ?

[Steve23]

AVI

[mean]

If you copy the content to a mkv, does the stutter disappear ?

[Steve23]

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.

[eumagga0x2a]

I can't reproduce the fps change, don't see any stuttering.

[Steve23]

For example:

video encoded with 2.6.18:

Code Select Expand

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:

Code Select Expand

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.

[eumagga0x2a]

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.

[Steve23]

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.

[mean]

It's not obvious what change triggered that

[eumagga0x2a]

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.

[eumagga0x2a]

This is a demuxer bug. Partially reverting [mkv/demux] slightly better recomputation of delay and frame duration, still not perfect

Code Select Expand

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.

[mean]

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

[eumagga0x2a]

Thanks, I meant that it was the fix for that bug 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 :-)).

[eumagga0x2a]

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:

Code Select Expand

[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).