[Bug 760774] qtdemux: fix framerate calculation for fragmented format

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=760774

--- Comment #8 from Seungha Yang <sh.yang at lge.com> ---
Differences between patch set #1 and #2 are that,

- Modification 1: Initialization point of "n_samples_moof" and "duration_moof"
is changed from "per trun box" to "traf box", because multiple trun can exist
in a moof. This modification is to accumulate samples in one moof.

- Modification 2: Frame rate will be re-calculated using new moof and caps also
be updated by patch set #2.

Dear Sebastian Dröge,
I have two questions.
- Q1: Could you please clarify your comment "But best to do that as a new patch
on top"? Does it means report new Bug? or implement it on this patch set?

- Q2: I had a rethink about the second issue, and I agree with your comment
that short first fragment might cause incorrect frame rate calculation.
So, I modified frame rate to be updated per moof. However, based on your
comment, you prefer averaging frame rate values over multiple fragments.

I think it is not difficult to accumulate n_samples and duration data over
multiple moof. But I need your opinion on my following question.

- mp4 supports variable frame rate. That means, frame rate can be varied as
time goes on. In this context, we need to choose "piecewise calculated frame
rate" or "keep averaging frame rate". My choice is that "piecewise calculated
frame rate" is better than the other (that's the reason why I implement
"Modification 2"). Could you give me feedback?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.