Timestamp files v3
it seems that timestamp files v3 don't work at all; by this I mean that no files are muxed (sometimes the EBML-Head, Segment (with size field 0x0100000000000000), segment information, tracks and EBML void are present in the output file, but nothing more). Looking in the code and using
--debug timestamp_factory I found one issue: If a line contains a valid duration,fps entry, then the duration isn't parsed at all. See lines 345-352. But this can't explain why it fails to mux at all. There must be something else.
PS: Looking at timestamp_factory_v3_c::get_next I see that e.g. for
# timestamp format v3 assume 20.0 0.21,10.0 10.0
the output timestamps are supposed to be 0, 100ms, 200ms, 210ms, 260ms, 310ms... where the packet at 200ms has a duration of 100ms, but is followed by a packet at 210ms. Is this really intended? I would opt for 0, 100ms, 200ms, 300ms, 350ms, but in a manner so that the errors (in this case: the 90ms) don't accumulate. One could do so by setting m_current_timestamp to m_current_timestamp-m_durations[m_current_duration].duration when resetting/switching to the next entry in the timestamp files. Also at line 386 one would have to set m_current_timestamp to max(m_current_timestamp-m_durations[duration_index].duration,0) (so that if there were a gap between the first two lines in the above examples, the gap would be shorter (by a maximum of 90ms), compensating for the first entry being 90ms too long and so that the third entry would start at the right time).