GNOME Bugzilla – Bug 774850
decklinksrc: Stop using the "hardware" timestamps and directly use the pipeline clock
Last modified: 2017-08-02 08:10:17 UTC
See commit message
Created attachment 340541 [details] [review] decklinksrc: Stop using the "hardware" timestamps and directly use the pipeline clock The hardware timestamps have no relation to when frames were produced, only when frames arrived somewhere in the hardware. Especially there is no guarantee that audio and video will have the same hardware timestamps although they belong together, and even more important: the rate with which the hardware timestamps increase is completely unrelated to the rate with which the frames are captured! As such we can as well use the pipeline clock directly and stop doing complicated calculations. Also as a side effect this allows now running without any pipeline clock, by directly making use of the stream times as reported by the driver.
There will be more patches on top of this, not mergeable as is. We can do better
Created attachment 340614 [details] [review] decklinksrc: Stop using the "hardware" timestamps and directly use the pipeline clock The hardware timestamps have no relation to when frames were produced, only when frames arrived somewhere in the hardware. Especially there is no guarantee that audio and video will have the same hardware timestamps although they belong together, and even more important: the rate with which the hardware timestamps increase is completely unrelated to the rate with which the frames are captured! As such we can as well use the pipeline clock directly and stop doing complicated calculations. Also as a side effect this allows now running without any pipeline clock, by directly making use of the stream times as reported by the driver.
Created attachment 340615 [details] [review] decklinksrc: Keep track of a window of capture/stream time mappings and calculate relationship Based on this we calculate the actual capture time, which should get us rid of any capturing jitter by averaging it out. Also add a output-stream-time property which forces the elements to output the stream time directly instead of doing any conversion to the pipeline clock. Use with care.
Created attachment 340647 [details] [review] decklinksrc: Keep track of a window of capture/stream time mappings and calculate relationship Based on this we calculate the actual capture time, which should get us rid of any capturing jitter by averaging it out. Also add a output-stream-time property which forces the elements to output the stream time directly instead of doing any conversion to the pipeline clock. Use with care.
Created attachment 340680 [details] [review] decklinksrc: Stop using the "hardware" timestamps and directly use the pipeline clock The hardware timestamps have no relation to when frames were produced, only when frames arrived somewhere in the hardware. Especially there is no guarantee that audio and video will have the same hardware timestamps although they belong together, and even more important: the rate with which the hardware timestamps increase is completely unrelated to the rate with which the frames are captured! As such we can as well use the pipeline clock directly and stop doing complicated calculations. Also as a side effect this allows now running without any pipeline clock, by directly making use of the stream times as reported by the driver.
Created attachment 340681 [details] [review] decklinksrc: Keep track of a window of capture/stream time mappings and calculate relationship Based on this we calculate the actual capture time, which should get us rid of any capturing jitter by averaging it out. Also add a output-stream-time property which forces the elements to output the stream time directly instead of doing any conversion to the pipeline clock. Use with care.
Created attachment 340701 [details] [review] decklinksrc: Keep track of a window of capture/stream time mappings and calculate relationship Based on this we calculate the actual capture time, which should get us rid of any capturing jitter by averaging it out. Also add a output-stream-time property which forces the elements to output the stream time directly instead of doing any conversion to the pipeline clock. Use with care.
Created attachment 340753 [details] [review] decklinksrc: Keep track of a window of capture/stream time mappings and calculate relationship Based on this we calculate the actual capture time, which should get us rid of any capturing jitter by averaging it out. Also add a output-stream-time property which forces the elements to output the stream time directly instead of doing any conversion to the pipeline clock. Use with care.
Created attachment 340754 [details] [review] decklinksrc: Set GAP flag on buffers that are captured without signal
Created attachment 340755 [details] [review] decklinksrc: Add property to skip the first N seconds of capture On some hardware the first few frames are bogus and not very useful. Their timestamps are off, they have no timecodes, or there are spurious black frames / no-signal frames. After a few frames this stabilizes though.
Created attachment 340756 [details] [review] decklinksrc: Add property to drop frames that are marked as having no input signal
Attachment 340680 [details] pushed as 881a086 - decklinksrc: Stop using the "hardware" timestamps and directly use the pipeline clock Attachment 340753 [details] pushed as 09dd64b - decklinksrc: Keep track of a window of capture/stream time mappings and calculate relationship Attachment 340754 [details] pushed as cf224a9 - decklinksrc: Set GAP flag on buffers that are captured without signal Attachment 340755 [details] pushed as 331b2af - decklinksrc: Add property to skip the first N seconds of capture Attachment 340756 [details] pushed as aec4614 - decklinksrc: Add property to drop frames that are marked as having no input signal
Could this have been configurable through a property, just like 'provide-clock' in alsasrc?
Yes but it would not make any sense. The timestamps have no real meaning.