GNOME Bugzilla – Bug 790334
avwait: Deserialised timecodes set after caps event now get correct framerate
Last modified: 2017-11-14 16:45:02 UTC
See commit message
Created attachment 363611 [details] [review] avwait: Deserialised timecodes set after caps event now get correct framerate A deserialised timecode has a framerate of 0/1 by default. That breaks it when comparing the frames field with another timecode (incoming from the frame). We were setting the framerate when receiving the caps event, but not when setting the timecode in set_property, so it was broken for timecodes set after the caps event.
Comment on attachment 363611 [details] [review] avwait: Deserialised timecodes set after caps event now get correct framerate Should also check for fps_n != 0 I guess, otherwise ok
Created attachment 363613 [details] [review] avwait: Deserialised timecodes set after caps event now get correct framerate A deserialised timecode has a framerate of 0/1 by default. That breaks it when comparing the frames field with another timecode (incoming from the frame). We were setting the framerate when receiving the caps event, but not when setting the timecode in set_property, so it was broken for timecodes set after the caps event. Also checking if the fps_n we got from the caps event is != 0 before setting it - also at the caps event.
Review of attachment 363613 [details] [review]: ::: gst/timecode/gstavwait.c @@ +595,3 @@ self->tc->config.fps_d = self->vinfo.fps_d; } + if (self->end_tc && self->end_tc->config.fps_n == 0 && self->vinfo.fps_n) { Make this also != 0, then push
Created attachment 363614 [details] [review] avwait: Deserialised timecodes set after caps event now get correct framerate A deserialised timecode has a framerate of 0/1 by default. That breaks it when comparing the frames field with another timecode (incoming from the frame). We were setting the framerate when receiving the caps event, but not when setting the timecode in set_property, so it was broken for timecodes set after the caps event. Also checking if the fps_n we got from the caps event is != 0 before setting it - also at the caps event.
Created attachment 363615 [details] [review] avwait: Deserialised timecodes set after caps event now get correct framerate A deserialised timecode has a framerate of 0/1 by default. That breaks it when comparing the frames field with another timecode (incoming from the frame). We were setting the framerate when receiving the caps event, but not when setting the timecode in set_property, so it was broken for timecodes set after the caps event. Also checking if the fps_n we got from the caps event is != 0 before setting it - also at the caps event.