Esxi running macos For selur

[Selur]

The 'experimental'-option combines some otherwise disabled options.
There are a bunch of undocumented (and a bunch of undocumented and not working) misc.ini options, but I'm not planning to change anything about those options.
Since I do not plan to support custom window sizing, I do not plan to add anything in that regard.
I was once planning to add a fullscreen-option, but dropped it for the time being.
-> I know that you want to freely resize the window size, but like I wrote before that is probably not happening.

Cu Selur

[shijan]

But why? Current "experimental" window resize works very well. It is even better than window resize in legacy Hybrid versions because it don't change window size to default when i switch to upper row of tabs.
Fullscreen also subjectively works very well. Very useful when used on secondary display.

By the way, do you think Hybrid_2021.03.30 stable enough? Is is worth to update installer package with it? Or don't hurry and wait for future releases?

[Selur]

a. There are still quite a few things broken with resizing and fullscreen, especially since quite a bit of it uses legacy code which, from what I read will not be usable in the next MacOS.
b. There are tons of problems with different themes under Linux, Windows and Mac.
-> not changing the default behavior any time soon.

By the way, do you think Hybrid_2021.03.30 stable enough? Is is worth to update installer package with it? Or don't hurry and wait for future releases?

short: wait
longer: There are still a bunch of bugs in it which I haven't had time to fix or look deeper into.
Also I haven't looked into updating all the tools. (especially the encoders)
Currently I plan to get a new public release ready end of this week.

Cu Selur

[shijan]

Ok, got it.

Back to bug (or not a bug) with incorrect duration.
I done some tests with file "Test Patterns Resolve 422 HQ.mov" (original duration 600ms):

Rendered to ProRes mov - Incorrect duration.
Rendered to Cineform mov - Incorrect duration.

Rendered to x264 mov - no problem.
Rendered to x264 mp4 - no problem.
Rendered to ProRes mkv - no problem.
Rendered to Cineform avi - no problem.


So i guess there is a problem somewhere in FFmpeg or in Hybrid.

[Selur]

Can't reproduce this here.
None of the files from https://www.dropbox.com/sh/bak63hnr7mnpg...aaxFa?dl=0 are reported by mediainfo with Duration_Lastframe-info.
You didn't share any debug output so I don't even know what command lines are used.
No clue what's happening.
-> You are on your own on that one.

"Test Patterns Resolve 422 HQ.mov"

I don't have that file. Only similar named file would be 'Test Patterns Resolve 422 HQ 10-bit.mov'

So i guess there is a problem somewhere in FFmpeg or in Hybrid.

or your file is simply flagged in a wrong way

Cu Selur

[Selur]

Ahhh,... okay, reencoding 'Test Patterns Resolve 422 HQ 10-bit.mov' with ProRes created a file with the 'Druation_LastFrame' info.
The whole time I understood it that the input had this info not the output,...

ffmpeg -y -noautorotate -nostdin -threads 8 -ignore_editlist true -i "C:\Users\Selur\Desktop\ProRes Examples 10 12 bit\Test Patterns Resolve 422 HQ 10-bit.mov" -map 0:0 -an -sn -pix_fmt yuv422p10le -strict -1 -vsync 0  -vcodec prores_ks -profile:v 3 -vtag apch -metadata encoding_tool="Hybrid 2021.03.30.1" -f mov "E:\Output\Test Patterns Resolve 422 HQ 10-bit_2021-03-30@16_23_34_1710_01.mov"

is the call used.

During the reencoding ffmpeg reports:

[mov @ 00000108f32800c0] Application provided duration: -9223372036854775808 / timestamp: -9223372036854775808 is out of range for mov/mp4 format
[mov @ 00000108f32800c0] pts has no value

-> the input is problem and ffmpeg makes something funny with the time codes.
(when reencoding to a non ffmpeg based encoder, only the frames are used not the time codes)
There is probably an additional ffmpeg-option to fix this,..

Cu Selur

[shijan]

It is same as "Test Patterns Resolve 422 HQ 10-bit.mov" i just renamed it on computer.
It was no problem with old version of FFmpeg and Hybrid.
I will test different combinations of FFmpeg and Hybrid
Here is debug. Hybrid_dev_2021.03.30 + ffmpeg-101748-g797c2ecc8f 2021-03-28

[Selur]

Read my last post again.
Problem might be that ffmpeg keeps some sort of time code track.

Cu Selur

[shijan]

Ok, hope it will be some fix for this. I don't like when ffmpeg changes file duration like this under the hood

[Selur]

Problem seems to be the '-vsync 0' option:

-vsync parameter

Video sync method. For compatibility reasons old values can be specified as numbers. Newly added values will have to be specified as strings always.

0, passthrough

Each frame is passed with its timestamp from the demuxer to the muxer.
1, cfr

Frames will be duplicated and dropped to achieve exactly the requested constant frame rate.
2, vfr

Frames are passed through with their timestamp or dropped so as to prevent 2 frames from having the same timestamp.
drop

As passthrough but destroys all timestamps, making the muxer generate fresh timestamps based on frame-rate.
-1, auto

Chooses between 1 and 2 depending on muxer capabilities. This is the default method.

Note that the timestamps may be further modified by the muxer, after this. For example, in the case that the format option avoid_negative_ts is enabled.

With -map you can select from which stream the timestamps should be taken. You can leave either video or audio unchanged and sync the remaining stream(s) to the unchanged one.

source: https://www.ffmpeg.org/ffmpeg-all.html
When removing the option (which then uses '-vsync -1') everything seems fine.

-> Seems like the way how ffmpeg reacts to broken time codes in the input has changed.

Cu Selur