[Bug 755543] New: wavparse: plain PCM wav wrongly treated as DTS

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=755543

            Bug ID: 755543
           Summary: wavparse: plain PCM wav wrongly treated as DTS
    Classification: Platform
           Product: GStreamer
           Version: 1.x
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: douglas.bagnall at catalyst.net.nz
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 312059
  --> https://bugzilla.gnome.org/attachment.cgi?id=312059&action=edit
A 5 second wav that won't play properly in Gstreamer

I have an 8kHz mono wav (relevant section attached) that happens to contain the
magic bytes 'fe 7f 01 80' near the start:

000008d0  ab fb 10 fb 43 fc 30 fe  c2 fd 60 fc f2 fe 7f 01  |....C.0...`.....|
000008e0  80 02 c3 02 c7 03 23 02  dd 00 29 02 a0 01 fe fe  |......#...).....|


This causes wavparse to treat it as DTS, and use the next few bytes as some
kind of accursed header. In turn it happens to survive this check:

  num_blocks = (hdr[2] >> 2) & 0x7F;
  *frame_size = (((hdr[2] & 0x03) << 12) | (hdr[3] >> 4)) + 1;
  chans = ((hdr[3] & 0x0F) << 2) | (hdr[4] >> 14);
  *sample_rate = sample_rates[(hdr[4] >> 10) & 0x0F];
  lfe = (hdr[5] >> 9) & 0x03;

  if (num_blocks < 5 || *frame_size < 96 || *sample_rate == 0)
    return FALSE;

That's all in -base/gst/typefind, and in wavparse plugin itself there is this:

  /* for maybe, check for at least a valid-looking rate and channels */
  if (!gst_structure_has_field (s, "channels"))
    return FALSE;
  /* and for extra assurance we could also check the rate from the DTS frame
   * against the one in the wav header, but for now let's not do that */
  return gst_structure_has_field (s, "rate");


I'm guessing I want to do that last bit, right?


As GST_DEBUG puts it:

LOG        typefindfunctions
gsttypefindfunctions.c:1733:dts_parse_frame_header: dts sync marker 0xfe7f0180
at offset 2225
LOG        typefindfunctions
gsttypefindfunctions.c:1754:dts_parse_frame_header: frame header:
c302c7022303dd02
...
LOG        wavparse gstwavparse.c:1835:gst_wavparse_add_src_pad: typefind caps
= audio/x-dts, rate=(int)44100, channels=(int)5, depth=(int)16,
endianness=(int)1234, framed=(boolean)false, P=50
...

and that doesn't want to link. The caps ought to be something like
"audio/x-raw,
format=(string)S16LE, layout=(string)interleaved, channels=(int)1,
rate=(int)8000".


Nobody else seems to get this wrong. gst123 plays a short little squirting
sound and
offers a few of these:

ERROR: block code look-up failed
Didn't get subframe DSYNC


I believe this is the opposite of
https://bugzilla.gnome.org/show_bug.cgi?id=636234,
whose incomplete fix caused this.

It might be useful to have a wavparse flag property that meant "trust me,
believe
the RIFF header", which would avoid this always and save all that time spent
looking for
magic brokenness.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.