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

[GStreamer (GNOME Bugzilla)]

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

Seungha Yang <sh.yang at lge.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sh.yang at lge.com

--- Comment #5 from Seungha Yang <sh.yang at lge.com> ---
To simplify, let's focus on pull mode for this discussion. (push mode is being
discussed in bug #760779)
There are 2 questions
- What if fragmented & duration and/or n_samples are unknown?
- Need update caps for every new moof? If so, where should be done?

Q: What if fragmented & duration and/or n_samples are unknown?
A: In my opinion, unknown duration and/or n_samples will not happen if the mp4
file is not broken.
And unknown duration and/or n_samples case is already covered by this codes
6917       if (stream->duration == 0 || stream->n_samples < 2) {
6918         stream->fps_n = stream->timescale;       
6919         stream->fps_d = 1;
6920       } else {
6921         /* Calculate a framerate, ignoring the first sample which is  

Let's assume that two fragmented case, And this patch is just for Case 2.
Case 1. moov + mdat_1 + moof_1 + mdat_2 + moof_2 + mdat_3 + ...
Case 2. moov + moof + mdat + moof + mdat + ....

For the Case 1, moov has n_sample data of mdat_1. So, sample data of moof_1
will not parsed 
in qtdemux_prepare_stream (In GST_STATE_HEADER/INITIAL), because n_samples is
non-ZERO.
@qtdemux_prepare_streams (GstQTDemux * qtdemux)
..
10455     if (qtdemux->fragmented) {
10456       /* need all moov samples first */
10457       GST_OBJECT_LOCK (qtdemux);  
10458       while (stream->n_samples == 0)
10459         if ((ret = qtdemux_add_fragmented_samples (qtdemux)) !=
GST_FLOW_OK)  

Then, in this case, n_samples_moof and duration_moof has inital value (zero), 
so qtdemux will calculate framerate based on only available data in moov.
I think this is what qtdemux did without this proposed patch.

Let's take a look at Case 2. qtdemux try to parse moof's until find sample data
(in the trun box), 
then frame rate will be calculated by the first valid moof.
So, it will also work properly.

Please note that, proposed patch will work by following condition
+        if (qtdemux->fragmented && stream->n_samples_moof > 0
+            && stream->duration_moof > 0) 

In summary, unknown duration and/or n_samples will not happen for case 2.


Q: Need update caps for every new moof? If so, where should be done?
A: I do not think that calcuates frame rate and update for every moof is very
meaningful.
It imply that whenever jump from on moof to another, qtdemux need configure
stream again (call gst_qtdemux_configure_stream() function).
Also, this patch did not consider this case. Note that, qtdemux configure
stream again if it get new caps from sink pad.

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