[Bug 767950] qtmux: Add support for writing timecode track

[GStreamer (GNOME Bugzilla)]

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

Thiago Sousa Santos <thiagossantos at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #331194|none                        |reviewed
             status|                            |

--- Comment #6 from Thiago Sousa Santos <thiagossantos at gmail.com> ---
Review of attachment 331194:
 --> (https://bugzilla.gnome.org/review?bug=767950&attachment=331194)

::: gst/isomp4/atoms.c
@@ +1296,3 @@
+{
+  atom_tref_clear (tref);
+

atom_tref_clear already calls atom_clear.

@@ +2595,3 @@
+
+  if (atom_array_get_len (&tref->entries) == 0) {
+    /* FIXME not needing this atom might be confused with error while copying
*/

Maybe it should be checked before called. We could also rework these copy_data
to have different return but let's keep that to later.

@@ +2605,3 @@
+  /* FIXME where does 8 + 4 * length come from? */
+  prop_copy_uint32 (8 + 4 * atom_array_get_len (&tref->entries), buffer, size,
+    return 0;

8 is from the fourcc + size  (this size that is written here and the next foucc
copy) and 4 is the size of the array entry.

::: gst/isomp4/atoms.h
@@ +533,3 @@
+
+  guint32 reftype;
+  //guint32 tref_index;

Replace with /* comment */

::: gst/isomp4/gstqtmux.c
@@ +634,3 @@
       DEFAULT_RESERVED_BYTES_PER_SEC_PER_TRAK;
+  qtmux->first_pts = GST_CLOCK_TIME_NONE;
+  qtmux->tc_pos = -1;

Maybe move this to _reset()

@@ +3125,3 @@
+           * we've already received the first frame to be presented. Otherwise
+           * the decoder would need to go back in time */
+          frames_since_daily_jam = GUINT32_TO_BE (frames_since_daily_jam);

When this happens, what brings back the writing position to the latest one to
continue writing data correctly?

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