splitmuxsink -- get timestamp of the keyframe as file name, make it accurate.

Антон Шаров sharov_am at mail.ru
Fri Jul 21 13:11:59 UTC 2023


Hi.
 
Given following code snippet for pipeline —  https://gist.github.com/sharov-am/3cf9c650be409c3b1ae4d5c6900973bb
I want to understand if my approach of naming newly created files with it’s keyframe (or first frame) timestamp is proper.
 
But first one simple question:
 
given code above, am I right that the probe callback  for splitmuxsink sink pad just triggered on every frame ? It looks like so, because looking add debug messages I have following:
 
new file counter: 10, probes since last file:55
new file counter: 11, probes since last file:70
new file counter: 12, probes since last file:57
new file counter: 13, probes since last file:69
new file counter: 14, probes since last file:56
new file counter: 15, probes since last file:70
new file counter: 16, probes since last file:56
new file counter: 17, probes since last file:70
new file counter: 18, probes since last file:70
new file counter: 19, probes since last file:56
new file counter: 20, probes since last file:56
new file counter: 21, probes since last file:56
new file counter: 22, probes since last file:70
new file counter: 23, probes since last file:56
new file counter: 24, probes since last file:56
new file counter: 25, probes since last file:56
 
It just counts number of times callback was raised between files (new file, start count from 0) which suspicially reminds me of  duration(max-time-size) * FPS, which in my case either 3.9* or 4.9* (duration) and 15.244 FPS. Not exact but close, which make sense. Could be?
 
So, back to main question, for now I just take gstTs (it’s latest value) which is either ts for last frame of previous file or ts of the first frame of current file. I need to name current with it’s first frame timestamp so last case seems proper to me but I want to understand sequance of events which fires callback. If splitmuxsink buffers data and then raise format-location event(signal) than my current approach is wrong, if it fires this event right after it closes previous file and before or near after it starts receiving  frames for new file than it would be more or less accurate. As I understood, splitmuxsink starts writing with I-frame, so is there any option to differentiate frames (I-frame vs not I-frame) because in this case the obvious choise is to select ts of latest I-frame as correct name.
 
Thanks in advance.
 
--
С Уважением,
Шаров Антон
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20230721/2402a017/attachment.htm>


More information about the gstreamer-devel mailing list