VP9 seeking broken in GStreamer 1.26

Hi. I have a video engine that uses GStreamer to decode videos to an AppSink, which accepts the video frames and composites them with other stuff in the video engine. Pipeline definition is simple:

std::string pipeline_definition = "\
  filesrc location=" + pathname + " ! decodebin ! videoconvert ! \
  video/x-raw,format=" + this->pixelFormat() + "  ! appsink name=sink";

When accepting frames, the app tests for an end of stream condition, and loops back to the beginning of the video:

gst_element_seek_simple(this->pipeline_, GST_FORMAT_TIME, static_cast<GstSeekFlags>(GST_SEEK_FLAG_FLUSH), 0);

This code has been working fine for years. However, upon recently updating to GST 1.26.1, seeking to the start of file is broken when the source video is a VP9 (WebM with alpha) file. The seek returns status indicating that is was successful, but then the pipeline is immediately back in EOS state again, and the code can no longer fetch any frames. The same code continues to work properly for MP4 videos.

I saw in the release notes that there were changes in Matroska support in 1.26, specifically talking about seeks, so I figure it’s possible that this is either a GST bug, or that I need to change my code in some way. Would appreciate advice on how to get this working again.

BTW, I’m testing on Mac OS X Sequoia on an x86 machine.

Thanks very much!

Quick update: I verified the same problem exists on Linux with latest components across the board. Everything was working fine on GStreamer 1.24, but now I can’t seek in VP9 videos in GStreamer 1.26.

OK, the culprit appears to be this:

(<unknown>:62478): GStreamer-WARNING **: 21:03:20.166: Trying to set string on taglist field 'extended-comment', but string is not valid UTF-8. Please file a bug.

I used ffmpeg to remove metadata from the WebM video asset (with no code changes) and now seeking back to the start of the file is working as expected. Consider a bug filed. :smiley: (Actually, I’m happy to formally do so, I just need to research how that’s done for this project.)

Sorry for talking to myself in this thread, but hopefully this will help someone else who encounters this problem, and/or nudge the appropriate GST developer to fix the underlying problem.

Thanks!

The final final resolution to this question: this was a regression bug in GStreamer 1.26.1 that specifically related to seeking in a VP8/VP9 with transparency after the input reached EOS. Fixed in 1.26.2 and all is well again. Apologies again for my ramblings!