Question about outcome and total-frames?

[MaistroX]

I´ve finnished a encode of a clip and after checked it via MediaInfo and I noticed this in the "encoding settings: total-frames=0" and also checked other ppl´s handbrake results, but in every one I´ve checked the managed to get the "total-frames" saved as one ex: "total-frames=189144"!

WHY does it show on other ppl´s HandBrake outcome ín MediaInfo and NOT in mine, ONLY "0" as stated above?

What am I missing or should I add anything into the "Extra Options" for that to be registrated and saved in the encode?

Regards MaistroX

[rollin_eng]

Could you please post your logs, instructions can be found here:

https://handbrake.fr/docs/en/latest/hel ... y-log.html

[MaistroX]

Sorry, maby should have linked to my older post that has all the info there, did´nt save the loggs more than on that post!

-> viewtopic.php?f=11&t=37161&p=175310#p175310

[rollin_eng]

Your video has 2877 frames.

[MaistroX]

Thx, BUT that was not my Question, the frames is not shown at all in MediaInfo, in there it says "total-frames=0", so something is missing in the encode settings and/or in the "Extra Options" field, but what?

[rollin_eng]

Have you asked mediainfo?

[MaistroX]

I don´t belive it´s a MediaINfo case since other ppl´s encodes show up correct in same version of MediaInfo showing total-frames with the numbers, so thats why I belive I´m missing something when I encode or something I need to add in Extra Options to get that info tagged/added, any idéas?

[rollin_eng]

Can you post a log from an encode that does display the correct info?

[MaistroX]

Since I have´nt been able to get that info myself inside a encode done by HandBrake, that´s mainly why I asked for help here, since other ppl seems to get that info inside, I have to be missing so additional parameters to fetch and store the info inside a complete encode, but what?

[rollin_eng]

How do you know other people have?

[MaistroX]

Ex of what info SHOULD look like after a encode with "total-frames" writen into encoded file ->



And this is when I encoded my own test file with with HandBrake nightly, shows "0" in total-frames ->



So ANY idea why HandBrake in MY CASE don´t save/store/writes the total-frames to encoded file???

[rollin_eng]

Your first example is not created by HB.

It may just be some metadata HB does not write.

[s55]

It's not set by HandBrake as it's not required.

[MaistroX]

Your first example is not created by HB.

It may just be some metadata HB does not write.

OK, I´ll go with this, BUT HOW do I get it written with HB, maby as some Extra Option or ?

[rollin_eng]

See s55’s response.

[MaistroX]

But IF I wanted to have it added as the encode goes, WHAT whould I have to ADD to get that???

[rollin_eng]

Edit HB code to include the metadata, it is open source.

[MaistroX]

No other way to do it?

Say add some command to the extra options so it gets included?

[rollin_eng]

Not with HB.

[s55]

Why do you want this? It’s not required

[Woodstock]

Probably wants MediaInfo to work.

[WhatZit]

BUT HOW do I get it written with HB, maby as some Extra Option or ?

I reckon we're only wasting our time discussing this because of these vague and ambiguous allusions in the x265 documentation:

--frames <integer>
The number of frames intended to be encoded. It may be left unspecified, but when it is specified rate control can make use of this information. It is also used to determine if an encode is actually a stillpicture profile encode (single frame)

(then, later)

--frames, -f <integer>
Number of frames of input sequence to be encoded. Default 0 (all)
CLI ONLY

(later still)

If --total-frames is 1, then a stillpicture variant will be signaled, but this parameter is not always set by applications, particularly not when the CLI uses stdin streaming or when libx265 is used by third-party applications.

Maybe a year ago, I read something in the x265 issue list about the lack of frames being recorded, which stopped CLI encoder "random access" into the input and borked progress % displays. It was also asked what the documentation meant when it stated that rate control could use it. I think it was Pradeep (a lead developer) who replied back "Dunno". Great stuff!

What WAS indicated was how the encoder always considers whether the input is a file or from stdin/pipe. In the documentation above, the first version of --frames which "may be left unspecified" is the API version intended to be passed within an x265_param structure. The second version is the CLI version (hence the big "CLI ONLY" tag) intended for stdin. Indeed, the CLI --frames & --seek options are how you make short encode samples without an API.

I don't really want to rehash all of the seek/progress frame-count CLI malarky because it's annoying, geeky and unimportant in this circumstance.

HandBrake is a frame-piping, API-based application, so it is entirely appropriate for it to not specify the total number of frames in x265's header, because that information is only used by the HandBrake application itself.

Having said that, the HandBrake team could probably set this useless information as a trivial addition to the x265_param list, since the framecount is already known before invoking the encoder. For example:

[08:35:22] sync: expecting 174717 video frames
x265 [info]: HEVC encoder version 2.6+12-7bd8751a8183
x265 [info]: build info [Windows][GCC 7.1.0][64 bit] 10bit

Now, whether you can convince them that this is even remotely important enough to do is another matter.

Assuming that you can't, there's nothing stopping you from adding the total number of frames yourself, either by calculating (runtime in seconds) multiplied by (Constant FPS), or by cancelling an encode immediately once the log spills the beans for you. Then, all you need to do is put this into Extra Opts:

Code: Select all

total-frames=NUMBER

Behold, your frame count will be there for all to see... for "reasons".

[BradleyS]

The estimation as logged by sync isn’t always accurate, especially in the case of over-the-air type broadcasts.

Anyway, this is a non-issue.