GNOME Bugzilla – Bug 639710
matroskamux: seeking messed up when remuxing H.264
Last modified: 2018-11-03 14:43:07 UTC
Remuxing H.264 from matroska to matroska like: ... demuxer.video_00 ! queue ! muxer.video_0 ... creates a file with a broken index. When seeking, we don't seem to land on a keyframe, but any frame. After a few seconds, at the next keyframe, the garbage clears up again.
That is likely because (version 1) matroska files do not contain any keyframe information in the block data, so outgoing buffers cannot be marked properly that way, and the muxing matroskamux does not stand much of a chance then. Seeking works in the original matroska because the index contains "seek points" (which presumably then point to keyframes, though not necessarily all of them, and these are likely to be found at cluster starts, but that is not certain either ...).
There's not much we can do about this if it's really caused by a Matroska v1 file. You can only add h264parse between the demuxer and muxer to correctly mark buffers as keyframe or not. Is this a Matroska v1 file?
fwiw putting h264parse between demuxer and muxer won't fix the issue because ... it will work in passthrough. We should have a way to force-disable passthrough in parsers for these use-cases.
Ideally we should try to do something better by default. If we require a property to be enabled, it means we fail most people most of the time, because most app writers don't know that's needed etc. Should matroskademux maybe set keyframe flags based on the index as well, if it doesn't do that yet? Maybe h264parse should never operate in passthrough mode until it has gotten a buffer marked as keyframe?
I've bitten by H.264 parse being in passthrough as well. Don't like that behavior much. I think when parser sets parsed=true it should parse the file, even if the input is packetized.
(In reply to comment #4) > Ideally we should try to do something better by default. If we require a > property to be enabled, it means we fail most people most of the time, because > most app writers don't know that's needed etc. > > Should matroskademux maybe set keyframe flags based on the index as well, if it > doesn't do that yet? No, because the index could point to arbitrary frames too. > Maybe h264parse should never operate in passthrough mode until it has gotten a > buffer marked as keyframe? Yes, and until it saw any other signs of upstream providing a parsed stream.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/38.