GNOME Bugzilla – Bug 783038
timecodestamper: Always increment internal counter
Last modified: 2017-07-20 11:33:36 UTC
Created attachment 352486 [details] [review] [PATCH] timecodestamper: Always increment internal counter The internal timecode counter also needs to be incremented if exisiting timecode is not overwritten.
Review of attachment 352486 [details] [review]: ::: gst/timecode/gsttimecodestamper.c @@ +425,3 @@ GST_OBJECT_UNLOCK (timecodestamper); tc = gst_video_time_code_copy (&tc_meta->tc); + gst_video_time_code_increment_frame (timecodestamper->current_tc); Wouldn't it be better to update current_tc with the one from the meta, instead of blindly incrementing?
No, at least not in the use case I'm targeting: What I want is a completely independant counter which always keeps incrementing from first-timecode, even it is not actually forwarded downstream.
But that would mean that there are two timecode "timelines", and you would jump between one and the other whenever there happens to be a frame without a timecode. Or not?
It means there are two timecode "timelines", and the user can jump between them with override-existing property. If override-existing is false and there is a frame without timecode, there is still no timecode. I see that the name "override-existing" is a bit misleading in that case. But this property will change anyways with the LTC patches I'll submit soon.
Maybe there should be 3 modes then: 1) Count and ignore whatever meta is on buffers 2) Initialize counter from the meta, and put that on buffers in between that don't have metas 3) Count and use the counter for buffers without meta (the 2 timelines you mention) All 3 seem useful (I don't see why 3 is useful, but you say so :) ). What do you think? And the "override-existing" property should probably be renamed and reused for this then.
It's not about existing meta, it's only about what the user sets for override-existing. Imagine, during run time, someone switches from counting timecode to existing meta and back. Then, he would expect the same timecode as if he hadn't switched.
OK, let's get that done as part of the LTC changes which add a new mode anyway then?
Ok, this is now part of: https://bugzilla.gnome.org/show_bug.cgi?id=784295
*** This bug has been marked as a duplicate of bug 784295 ***