[gstreamer-bugs] [Bug 624173] New: [qtdemux] qt file with dimension data in tkhd does not get pixel-aspect-ratio in caps

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=624173
  GStreamer | gst-plugins-good | git

           Summary: [qtdemux] qt file with dimension data in tkhd does not
                    get pixel-aspect-ratio in caps
    Classification: Desktop
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: wulczer at wulczer.org
         QAContact: gstreamer-bugs at lists.sourceforge.net
      GNOME target: ---
     GNOME version: ---


I have a file that has the dimension set to 1024x576 in the tkhd atom, pixel
dimensions set to 720x576 in the stds atom and the pasp atom is not present.

The major brand of the file is 'qt  '.

Some discussion on #gstreamer revealed, that QT files should have PAR data in
the pasp atom, but in the case of this particular file (which I sadly cannot
share) the correct PAR is 64/45 and it's exactly what 1024/720 is.

Since apparently such files are appearing in the wild it would make sense to
use the info from tkhd and stds to determine PAR in case there is no pasp atom.
The only problem is that according to the spec the PAR data should be in the
pasp atom only (for QT files), and so a compliant demuxer should not signal PAR
if there is no pasp atom. I tend to think that in this case it's better to
accept a common misinterpretation of the spec instead of standing strictly by
it.

Does anyone know a QT file that has no pasp and that would cause wrong PAR to
be set, if it were done according to tkhd and stds?

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.