GitLab

Between versions 1.14 and 1.16, there has been a change either in gst-discoverer itself or in some underlying part of gstreamer, which causes gst-discoverer to now leak title tags from subtitle tracks into "main" title track, which in turn causes problems in applications that rely on gst-discoverer.

Consider a test .mkv file with subtitle tracks that have title tags, whereas the main file/container itself does not have a title.

On Fedora 29 (gstreamer 1.14.4), running gst-discoverer-1.0 against the file will produce: (full --verbose output)

[rok@vm-fedora29 ~]$ gst-discoverer-1.0 test.mkv
Analyzing file:///home/rok/test.mkv
Done discovering file:///home/rok/test.mkv

Topology:
  container: Matroska
    subtitles: Timed Text
    subtitles: Timed Text
    audio: E-AC-3 (ATSC A/52B)
    video: H.264 (High Profile)

Properties:
  Duration: 0:42:15.840000000
  Seekable: yes
  Live: no
  Tags:
      container format: Matroska
      language code: en
      video codec: H264
      audio codec: E-AC-3 audio

On Fedora 30 (gstreamer 1.16.0), the output is: (full --verbose output)

[rok@vm-fedora30 ~]$ gst-discoverer-1.0 ./test.mkv
Analyzing file:///home/rok/./test.mkv
Done discovering file:///home/rok/./test.mkv

Topology:
  container: Matroska
    subtitles: Timed Text
    subtitles: Timed Text
    audio: E-AC-3 (ATSC A/52B)
    video: H.264 (High Profile)

Properties:
  Duration: 0:42:15.840000000
  Seekable: yes
  Live: no
  Tags:
      container format: Matroska
      language code: en
      title: English, English SDH
      audio codec: E-AC-3 audio
      video codec: H264

The old version does not return a title, whereas the new version does, and this title is a combination of subtitle tracks' titles - "English, English SDH" (and on differents runs, the order may change to "English SDH, English", or even contain only one of the titles - presumably because they are obtained asynchronously).

Consequently, programs that rely on gst-discoverer (e.g., totem, or rygel when exporting shared DLNA library) used to list such video files by their filenames, but now list them by this bogus "title". Which means that one may end up with a whole list of "English, English SDH" videos to choose from.

The attached proof-of-concept patch works around this issue by discarding all tags received from subtitle streams in handle_message() so that they are not added to main tags. But they are still (correctly) added to a stream's list of tags, as shown by full --verbose output after applying patch

While it fixes my issue with files listed by Rygel, I am not sure if this is the best place to fix it? Or if the fix should perhaps be even more generic - for example, a video file may also contain (multiple) audio and video tracks with title tags, and those should not be propagated into main title, either.