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

MovieWriter fps changes to fix issue #15 #16

Closed exscriber closed 5 years ago

exscriber commented 5 years ago

I revert f8187d0, because i was wrong with it. Current solution for issue #15 was tested on 1m15s files with different fps settings: https://www.dropbox.com/sh/4xki0t9vdsxjp46/AACGFpwL_0KXZoVd4Eoz3fkba?dl=0

Timebase of output files differ from Hap-QT, for example: Hap-CC 25fps: codec_time_base = 1/25, time_base=1/12800 Hap-QT 25fps: codec_time_base = 1/25, timebase=1/25

But muxer seems to calculate parameters right way: d3 and AE now read Hap-CC files without frame loss, show right fps and right duration.

twhittock commented 5 years ago

Hi, thanks for the patch. Couple of questions:

  1. Is the truncating cast to integer what is wanted, or should it round to closest?
  2. Has this been tried on NTSC frame rates (i.e. 1000/1001 denominator pattern)

Thanks.

exscriber commented 5 years ago
  1. Cast is here to convert int64_t (already divided by GCD) to int, no truncating as result already small enough.
  2. Yes, now timebase for NTSC is correct 1001/30000 as in Hap-QT files: frameRateNumerator = 254016000000, frameRateDenominator = 8475667200 GCD = 8467200, streamTimebase.num = 1001, streamTimebase.den = 30000
twhittock commented 5 years ago

Ah yes I understand - didn't grok GCD at first, sorry.

Assume you mean num = 30000, den = 1001.

LGTM - @GregBakker ?

exscriber commented 5 years ago

@GregBakker it’s about AVCodecContext deprecated. But without assigning timebase to both: codec and stream - av_write_header calculate messy codec_timebase on it’s own.

GregBakker commented 5 years ago

I like the std::gcd usage, new one to me :)

twhittock commented 5 years ago

Thank you @exscriber for this contribution! :)