GUI and x264: reuse logfile

[flapane]

On Avidemux 2.5 I used to split long x264 encodings by doing the first pass on a day and the second pass on the next day.
On Avidemux 2.6 (svn) this doesn't seem to be possible, nor I couldn't find any option to enable this feature.

Any hints?
Thanks

[flapane]

Nobody ever used that function, back on v2.5? 

[poutnik]

As a work around, what about suspend / resume of machine, if the case is not to run the machine overnight ?

I use MeGUI on Windows for time demanding Avisynth encodings for archive purposes,

It may be OS specific, but I can deliberately suspend machine when encoding is in progress.
When resumed, encoding continues where it was stopped.

Edit: I suppose even hibernation is an option, but this I cannot test,
as Vista64 ( I know, I know, Vista... ) does not support hibernation with more than 4 GB RAM.

[flapane]

Hi,
unfortunately I have to switch off the machine. Hibernation could be an option but, still, maybe the devs could explain us why such a feature has been removed in v2.6.

[poutnik]

ADM 2.6 is rather rewritten than improved ADM 2.6, I would say the feature was rather not re-implemented yet, than removed.
There are more such features in ADM 2.5 that were missing initially, and were implemented during the time, are pending implementation or will not be implemented.

E.g. ADM2.6 cannot read MPEG 2 elementary stream, and support for XviD was added on user request only.

[Jan Gruuthuse]

Perhaps this has to do with 2.6 is not a framed based, but a time based editor? 2.6 is a mostly rewritten core that deals with time, not frames That (c/w)ould make it hard (impossible) to implement 2.5 stuff in 2.6?

[flapane]

That makes sense, thanks.

[poutnik]

Perhaps this has to do with 2.6 is not a framed based, but a time based editor? 2.6 is a mostly rewritten core that deals with time, not frames That (c/w)ould make it hard (impossible) to implement 2.5 stuff in 2.6?

I have meant my post as explanation , rather than complains, I see the reasons.

OTOH, scheduling the passes have very little to do with being frame or time based.
But I suppose it has to be reimplemented to have it in ADM2.6 as well, as my idea is that even frame/time irrelevant code cannot be directly overtaken.

[Jan Gruuthuse]

I have meant my post as explanation , rather than complains,

I did not see complaint(s) Just shared my careful user thoughts/questions. Perhaps you overlooked the ? in every sentence?
Big difference between 2.5 and 2.6 has always been frame versus time based

[poutnik]

I did not see complaint(s) Just shared my careful user thoughts/questions. Perhaps you overlooked the ? in every sentence?
Big difference between 2.5 and 2.6 has always been frame versus time based

Hm,  question marks can be easily misinterpreted, as may have many different meaning, depending on context and user customs.

No doubts about that difference,
but difficulties to implement the discussed idea from ADM2.5  has no direct relation to frame vs time approach.
rather to very different code structure of ADM, as way to implement this approach switch.

[AQUAR]

I believe ADM 2.5 had much more of a controlling interaction with encoders of the time.
That was given up in ADM 2.6 due to the complexity of X264 hence (from frame base to time base).

At the moment is seems ADM 2.6 has no lasting awareness of X264 2 pass encode parameters that associate with a specific video file.
Everything is handed over to X264.
It would, I think, need to store the X264 encoding parameters and point to the relevant stat file name in order to setup a resume from 1 pass.

Its probably more complicated than just saving parameters (else it seems quite possible to implement!).

[poutnik]

I believe ADM 2.5 had much more of a controlling interaction with encoders of the time.
That was given up in ADM 2.6 due to the complexity of X264 hence (from frame base to time base).

At the moment is seems ADM 2.6 has no lasting awareness of X264 2 pass encode parameters that associate with a specific video file.
Everything is handed over to X264.
It would, I think, need to store the X264 encoding parameters and point to the relevant stat file name in order to setup a resume from 1 pass.

Its probably more complicated than just saving parameters (else it seems quite possible to implement!).

Hmm, but time base is ADM internal thing, as X264 encoders, like e.g. AVS2X264 are frame based, AFAIK.
Also, 2pass X264 encoding means IMHO 2 calls of the encoder and it is on ADM, when it calls it.

But I do not say it is easy, as I suppose ADM 2.6 is internally very different application than ADM 2.6, just GUI remains near the same.

[Jan Gruuthuse]

I'm afraid it is more complex then that. 2.5 and below work with real (existing) frames. 2.6 works with pseudo frames (there not really there, the ones in between the key-frames). Hence the term time based. And probably the speed advantage 2.6 has over 2.5. As I understand it.

[AQUAR]

@ poutnik
Of course the encoder get's called twice.
If these calls are made from a contiguous ADM process then the needed parameters are known.
Otherwise, ADM 2.6 is 'stateless' so that a 2 pass encode has to start from scratch, even with the same video file name.

I agree with Jan:
ADM 2.5 has control of the frame ordering process needed to assemble pseudo frames.
ADM 2.6 can only look ahead and relies on the codec to do the frame ordering.

Anyway, its just my opinion of why I think this feature hasn't been made available so far for ADM 2.6.
If it is only an issue of storing parameters for 2nd X264 pass, then maybe this feature will be implemented in due course.

Another possible reason might be that there isn't much call for doing 2 pass X264 encodes, as 1 pass CRF encodes are pretty close in subjective quality for a given average bit rate.