search

disguise-one / hap-encoder-adobe-cc

Community-supported exporter of HAP codec family for Adobe CC applications
Other
169 stars 15 forks source link

UI Chunking auto settings #26

Closed exscriber closed 5 years ago

exscriber commented 5 years ago

Idea behind chunking Auto calc: use chunk for each 2.3MPix block (1920x1200px) And there are other options: None (classic QT behavior) and Manual

TODO:

Please leave a comments: Is auto formula OK? FFMpeg reduce chunk count to land exactly on dxt macroblock border. Shoud i do same? Default setting: none or auto? (in terms of compatibility with existing software) Maybe limit max chunks a bit? For example 16 instead of 64...

chunks

https://github.com/Vidvox/hap-qt-codec/issues/31

GregBakker commented 5 years ago

[My knowledge of Hap playback implementations is limited; so I'm going to speculate here!]

To maximise parallelisation and minimise latency when skipping in playback, the number of chunks to be chosen should probably match the number of hardware threads used to decode them on the playback device.

Whether or not you get a benefit also depends whether the playback implementation multithreads the chunk decoding - if the playback engine multithreads batches at the frame decoding level [as I believe disguise does] then there's no benefit to using the chunking settings.

Can we check which playback engines multithread their chunk decoding (ffmpeg? Maybe Tom @bangnoise may know some others?) and what would make sense for them?

bangnoise commented 5 years ago

The ideal setting does depend on the playback hardware, but as long as the decoder supports multithreaded decoding it will always benefit from conservative chunking. Most engines I know of do support multithreaded decoding.

For the Auto setting definitely limit to a reasonably low number of chunks - 8 or 16? Anyone encoding enormous frames for more cores can manually select a higher number.

As there is no specced requirement to chunk on DXT boundaries that is up to you - it would be easier for decoders if all encoders did it, but it isn't in the spec.

exscriber commented 5 years ago

@bangnoise, thanks for your comment. I modify code to not exeed 16 chunks in auto mode. Realistically auto calculate 16384x1080px as 8 chunks, anyway now it hard limited to 16.

Regarding default setting: If we change default to auto - CGs start to render files with chunks. Is it safe to enable chunking by default? Did someone know software not compatible or not working well with chunked files? I mean really not working, with black instead of video and so on... I hope all software compatible.

bangnoise commented 5 years ago

@exscriber All decoders I know of correctly handle chunked frames, even if they do so on a single thread.

Perhaps the default should be off, so users are only using chunking intentionally - what do others think?

GregBakker commented 5 years ago

I'll go controversial :)

As there's a reasonable spectrum of platforms that implement multithreaded chunking, and the remainder probably use the default supplied single-threaded implementation, let's make chunking enabled by default. There's likely no harm to anyone; those that can get the multithreaded benefits do so; on average everyone gets better shows.

Of course if even one user comes back with 'this caused me pain' we disable it by default, but there's the opportunity here to make best practice be the default.

exscriber commented 5 years ago

Thanks for your comments. After looking close into pros and cons - I tend to leave default functionality as close to QT-Hap (current most used codec) as possible. Minimal user confusion vs reach features.

It mean for me - no chunking by default, and no auto chunking as it can confuse even more. Manual chunking already exist in current code. So i close this PR as not necessery.