GNOME Bugzilla – Bug 658931
Decoders: More generic sanity checks (based on monitoring in a buffer probe)
Last modified: 2012-06-21 18:17:14 UTC
Mart is currently working on this (estimate 5 days) Copy-pasted from internal notes (feel free to close this bug and re-open, or add comments if plans change): * Pure default playback to a fake video/audio sink for some amount of frames * Pure default playback to a real video/audio sink for some amount of frames * Seeking back to the beginning while in playing state * Playing only a given segment, less than the whole media regarding both the start and stop times, EOS vs SEGMENT_DONE correctness * Playing at faster and slower rate than normal * Accurate seeking to a non-keyframe position, making sure buffers from keyframe up to the desired position are dropped * Seek scrubbing simulation * Reverse playback with different rates
#21 Test video decoder passing through timing information correctly Decoder should pass through newsegment event, should remember segment configuration, should handle and pass through segment updates. Decoder should do correct clipping of output at segment boundaries (if timestamp+duration > segment.end either drop buffer, or if timestamp < segment.end clip duration so that timestamp+duration = segment.end). Decoder should pass timestamps through correctly (ie. output timestamps should match input timestamps if adjusted for display/coding order re-ordering that may happen), even if there are jumps or there is jitter. #22 Test video decoder timestamp interpolation Decoder should interpolate output timestamps if input isn't consistently timestamped (which is perfectly acceptable and common with some containers). #23 Test video decoder flush handling Make sure the video decoder handles flushes properly (flushes decoder, internal queues etc.), even if in rapid succession from multiple threads (e.g. app seek-scrubbing). Easiest to test with input files. Possibly also make sure memory/resource usage stays steady, ie. there are no accidental leaks.
You don't need to file bug reports about everything you're doing or planning to do. gst-qa-system is not active enough to need lots of discussion about what you are doing. A simple mail to gst-devel (or the maintainer) would suffice. If you want to use bugzilla as a TODO list, that's cool (I do it too), please put the bugs in the NEW state and assign them to yourself (or whomever is going to do the work). That way, they don't show up on the triage or needs-work lists. Please go ahead and fix all the bug reports that you filed.
This bug is not relevent anymore as most of insanity as been rewritten. Closing the bug and if something similare should be done, we should reopen a new bug.