matroskamux: file not seekable maybe due to timecode rounding problem
Describe your issue
I am using an app that uses gstreamer to export application internal video streams to stand alone MKV files. Unfortunately, the files generated can be played by e.g. VLC but are not seekable (i.e. I cannot jump to specific positions in the video).
Expected Behavior
The videos should be seekable.
Observed Behavior
The video is not seekable.
Setup
- Operating System: Windows 10
- Device: Computer
- GStreamer Version: 1.22.2
- Command line: "jpegdec ! videoconvert ! nvh264enc ! h264parse" (source and sink part of the pipeline are controlled by the app, only the pipeline between can be adapted by the user)
Steps to reproduce the bug
How reproducible is the bug?
Every time exporting/generating a MKV using the app.
Screenshots if relevant
Solutions you have tried
- Using different input files
- Using different pipelines
- Adapting matroskamux properties (not possible due to limitations in app)
Related non-duplicate issues
Additional Information
mkvalidator-0.6 gives the following results:
230331_091006.adtfdat_export_Video.mkv
ERR201: Invalid 'Colour' for profile 'matroska v2' in Video at 371
ERR201: Invalid 'Range' for profile 'matroska v2' in Colour at 391
ERR201: Invalid 'MatrixCoefficients' for profile 'matroska v2' in Colour at 391
ERR201: Invalid 'TransferCharacteristics' for profile 'matroska v2' in Colour at 391
ERR201: Invalid 'Primaries' for profile 'matroska v2' in Colour at 391
ERR312: CueEntry Track #1 and timecode g80249104967 ms not found
ERR312: CueEntry Track #1 and timecode g80249119965 ms not found
ERR312: CueEntry Track #1 and timecode g80249164966 ms not found
ERR312: CueEntry Track #1 and timecode g80249194964 ms not found
ERR312: CueEntry Track #1 and timecode g80249209963 ms not found
file "D:\20230331_091006.adtfdat_export_Video.mkv"
created with GStreamer matroskamux version 1.22.2 / GStreamer Matroska muxer
mkvtoolnix shows, that the cues and the referenced clusters have the same timecode, but the first SimpleBlock of the Cluster has sometimes a timecode that differs by 1*timecodescale from the timecode of the cluster (see e.g. timestamps in lines 43 vs. 44 or 195 vs 197 in mkvinfo below)
I am totally new to gstreamer and video processing, and may be wrong in my conclusion, but dig down the code a little and I suppose the core issues is matroskamux does a rounding of the time codes for the Blocks, that in some cases (maybe related with inappropriate timecodescale), leads to +-1 values. Whereas the timecode in the Clusters is taken (quite) straight from the buffer_timestamp
Unfortunately, the app does not allow me to configure the properties of matroskamux and try another timecodescale, so my conclusion is until now mainly based on "theoretical analysis".