Is there something unusual about this situation? What kind of format is the original file?
I've been testing with videos from YouTube. They're HLS files (H.264/AAC). So they are streamed from the internet, which likely slows things down. I've attached the pipeline.
Note that downloading, demuxing and decoding all take place in the media source.
[0.00.15.408422079-wg_parser_caps.dot](/uploads/4dd6e05a14964a23d2336c87a440ed9c/0.00.15.408422079-wg_parser_caps.dot)
How long are we waiting for another sample?
It's not uncommon to wait ~2 seconds. Here's an example following thread 0x072c (which has just called `wait_on_sample`):
``` 184.777:0214:072c:trace:mfplat:wait_on_sample 00000003AB0F7CB0, 0000000000000000 186.314:0214:072c:trace:mfplat:MFCreateMemoryBuffer 1382400, 00000003878CFC80. ```
The delay is from GStreamer. Here's a sample of the delays as reported by GStreamer: ``` 0:00:56.613337219 5274 0x7f5b64038a70 INFO videodecoder gstvideodecoder.c:3731:gst_video_decoder_clip_and_push_buf:<avdec_h264-1> First buffer since flush took 0:00:00.938238397 to produce 0:00:58.779292706 5274 0x7f5b64038a70 INFO videodecoder gstvideodecoder.c:3731:gst_video_decoder_clip_and_push_buf:<avdec_h264-1> First buffer since flush took 0:00:02.142121758 to produce 0:00:59.931777332 5274 0x7f5b64038a70 INFO videodecoder gstvideodecoder.c:3731:gst_video_decoder_clip_and_push_buf:<avdec_h264-1> First buffer since flush took 0:00:01.128113862 to produce 0:01:01.117394275 5274 0x7f5b64038a70 INFO videodecoder gstvideodecoder.c:3731:gst_video_decoder_clip_and_push_buf:<avdec_h264-1> First buffer since flush took 0:00:01.165114977 to produce ```
on Windows it wouldn't be a separate thread and wouldn't be interruptible
It's possible Windows solves this a different way. Maybe I can write a test to confirm.