Why do consecutive encodes, using the same settings, result in different output?

[therube]

Why do consecutive encodes - without restarting Avidemux, using the same settings, result in different outputs?

"Different".
Different in the "body" of the output (as opposed to, aside from, differences in the file header/tag, like MKV's guid).

"Without restarting Avidemux".
In other words, run an encode, & once that is done, do nothing more, except run the very same thing again - no changes.


If you run an encode, Quit Avidemux & restart, then run that very same encode again, output will be the same (aside from possible file header/tag diffs).


Why if you don't quit, but just run a consecutive encode, do you get "different output"?


"Different output".
I take it that even though the files are physically different, these differences do not affect anything - other then the physical layout of the bytes making up the file?


Does the order in which filters are enabled affect output?
Best I can tell, yes.

As in, if you enable in order; Crop, Asharp, Contrast,
you'll get different output, including file size,
had you enabled; Contrast, Asharp, Crop.


Use of certain codecs are far more apt to cause output differences.
Like AAC (FDK) almost assuredly, where AAC (Lav), not necessarily.

Along the same lines, disabling audio, so video only out, does not do this.


I take it some of this is due to Demuxers & Muxers & how they interact & what happens if or if you do not quit between runs?


Win7 x64, 2.8.2, 221127

[therube]

(And now, a ramble of above...)

why, if i do the same encode, do i get different size output files?
run 1, 93.4 MB, run 2, 95.7 MB
mediainfo show all the same (except size & overall bitrate)

does the order of filters make a difference?
as in, i'm using crop & asharp & contrast
so if on the second run i "set them up" in order; crop contrast asharp
- all with the same filter settings (& same encode settings), would
that cause a size diff?

- ah, if i run an encode, even if using AAC FDK,
& if i Quit, & Restart,
& Restore Previous Session
i get identical output... ?

if you encode
quit
Restore Previous & encode
- get identical output

if you then do nothing more but encode a 3rd time
- you get different output

lastEdit.py between the 1st encode & the 3rd encode are exactly the same
the only difference is whether you quit between encodes
or whether you ran consecutive encodes

so... quit again...

Recent -> File - same source
x264, fdk, crop 18 all sides, sharp Asharp, contrast MPEG2->PC
all selections done - in that order

the first 3 encodes were 27,008,755
the first 2 of those encodes were identical
the 3rd encode was different, that was the consecutive encode

now, the 4th encode, selecting the same source file
& re-applying the exact same filters, in the same order...
- AH! .py is different - WHY ? - oh, OK, that was me - forgot to tic MPEG2->PC

so... (now that i've quit, restarted, & fixed that)...

ok, so now 1 & 2 & 5 are exactly alike
3 was the consecutive run, that ended up different, 4 was the one i made the error on

& if i now run another consecutive run... ?
so that is the 6th, & that is exactly the same as the 3rd run (which was also consecutive)

& a 7th, run consecutively (i.e. without restarting Avidemux), is unique against all the others
& if i run an 8th, this consecutively also - it too should be unique - Yes.

and quit
& .py is identical to my 1st encode, so .py is the same

which means, if i now start again, load that .py
& run a number of consecutive encodes - no changes in settings
each of those should be unique to this group
but also each of these should also be identical to some earlier runs... ?

1 2, 11 22, ... are identical - except for the guid that mkv throws in there
111 222, i don't recall what i did there, but they are different

restart111 restart222 restart333 are identical - except for mkv's guid
restart444, don't recall what i did there either ?

then i switched to mp4 & with that, i made no changes except for adding the filters in.
& except for the 1 time i missed a change to the filter, all of those runs had exactly
the same settings.  only difference is whether i restarted between runs, or ran them
consecutively.

the 49# series were all run consecutively.  & oddly ?, both 491 (which was the first
in that series after a restart) & 496 are identical (& identical to 111 & 222).

111 & 222 & 491 were all done after a restart, so that it is expected that they would
be identical.  but 496 was run consecutively (after 491..492..496) & that run also
ended up identical (to 111 222 & 491) - so like maybe things are going in a loop, at
some point?

likewise, there are other series of runs, where 1 consecutive matched another consecutive,
which seems to be "expected".

that said, i didn't expect any of this ;-).

& that is not the end of my un-expectedness <sp ?> (but it's enough for the moment).

so... just why is this happening ?

OK, so yes, the ordering of the filters does make a difference - even though the settings
for those same filters are unchanged.

all earlier runs, the filters were ordered; crop asharp contrast
& this last run, i changed it to;           contrast asharp crop
& that ordering difference resulted in a larger (unique) file compared to all of the rest.


lastedit.py:

Code Select Expand

#PY  <- Needed to identify #
#--automatically built--

adm = Avidemux()
if not adm.loadVideo("C:/COLD/TMP/SEA/video.test.file/mp4BigBuckBunny_115k.mov.mp4"):
    raise("Cannot load C:/COLD/TMP/SEA/video.test.file/mp4BigBuckBunny_115k.mov.mp4")
adm.clearSegments()
adm.addSegment(0, 0, 596375000)
adm.markerA = 0
adm.markerB = 596375000
adm.setHDRConfig(1, 1, 1, 1, 0)
adm.videoCodec("x264", "useAdvancedConfiguration=False", "general.params=AQ=20", "general.threads=99", "general.preset=medium", "general.tuning=", "general.profile=high", "general.fast_decode=False", "general.zero_latency=False"
, "general.fast_first_pass=True", "general.blueray_compatibility=False", "general.fake_interlaced=False", "level=-1", "vui.sar_height=1", "vui.sar_width=1", "vui.overscan=0", "vui.vidformat=5", "vui.fullrange=False"
, "vui.colorprim=2", "vui.transfer=2", "vui.colmatrix=2", "vui.chroma_loc=0", "MaxRefFrames=3", "MinIdr=25", "MaxIdr=250", "i_scenecut_threshold=40", "intra_refresh=False", "MaxBFrame=3", "i_bframe_adaptive=1"
, "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=True", "analyze.b_p16x16=False", "analyze.b_b16x16=False", "analyze.weighted_pred=2", "analyze.weighted_bipred=True"
, "analyze.direct_mv_pred=1", "analyze.chroma_offset=0", "analyze.me_method=1", "analyze.me_range=16", "analyze.mv_range=-1", "analyze.mv_range_thread=-1", "analyze.subpel_refine=7", "analyze.chroma_me=True"
, "analyze.mixed_references=True", "analyze.trellis=1", "analyze.psy_rd=1.000000", "analyze.psy_trellis=0.000000", "analyze.fast_pskip=True", "analyze.dct_decimate=True", "analyze.noise_reduction=0", "analyze.psy=True"
, "analyze.intra_luma=11", "analyze.inter_luma=21", "ratecontrol.rc_method=0", "ratecontrol.qp_constant=0", "ratecontrol.qp_min=10", "ratecontrol.qp_max=51", "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=1", "ratecontrol.ip_factor=1.400000", "ratecontrol.pb_factor=1.300000"
, "ratecontrol.aq_mode=1", "ratecontrol.aq_strength=1.000000", "ratecontrol.mb_tree=True", "ratecontrol.lookahead=40")
adm.addVideoFilter("crop", "top=18", "bottom=18", "left=18", "right=18", "ar_select=0")
adm.addVideoFilter("asharp", "t=2.000000", "d=4.000000", "b=0.000000", "bf=False", "d_enabled=True", "b_enabled=False")
adm.addVideoFilter("contrast", "coef=1.160000", "offset=-16", "doLuma=True", "doChromaU=True", "doChromaV=True")
adm.audioClearTracks()
adm.setSourceTrackLanguage(0,"eng")
if adm.audioTotalTracksCount() <= 0:
    raise("Cannot add audio track 0, total tracks: " + str(adm.audioTotalTracksCount()))
adm.audioAddTrack(0)
adm.audioCodec(0, "FDK_AAC")
adm.audioSetDrc2(0, 0, 1, 0.001, 0.2, 1, 2, -12)
adm.audioSetEq(0, 0, 0, 0, 0, 880, 5000)
adm.audioSetChannelGains(0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
adm.audioSetChannelDelays(0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
adm.audioSetChannelRemap(0, 0, 0, 1, 2, 3, 4, 5, 6, 7, 8)
adm.audioSetShift(0, 0, 0)
adm.setContainer("MP4", "muxerType=0", "optimize=1", "forceAspectRatio=False", "aspectRatio=1", "displayWidth=1280", "rotation=0", "clockfreq=0")





https://i.postimg.cc/371nRJC1/Avidemux-gives-different-results-on-consecutive-runs-same-settings.png

[eumagga0x2a]

I apologize for having mostly skipped the long posts, but it is expected for re-encoding of audio tracks in Avidemux to produce different bitstreams as Avidemux converts internally from 32-bit floating point to signed 16-bit integer format and thus has to apply dithering.

In my testing, performed on Linux, all runs encoding 2 minutes worth of stereo AC-3 audio track to a variety of codecs produces different bitstreams, no matter whether Avidemux was open all the time or closed between runs. If the results on Windows are identical after restarting Avidemux, this indicates that the random number generator doesn't generate random values. I'll recheck this.

Audio in copy mode and mere re-encoding of video tracks with x264 should produce consistently identical results (except of the cases where the muxer generates and writes a UUID to the container like in case of MKV as you mentioned).

Video filters (or rather basic routines they are using) may or may not involve random data / noise, this needs to be analysed for each filter individually.