After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 735627 - wavenc/wavparse: should support RF64 files
wavenc/wavparse: should support RF64 files
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
Other Linux
: Normal enhancement
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 737735
Reported: 2014-08-28 18:46 UTC by Peter G. Baum
Modified: 2014-10-14 08:26 UTC
See Also:
GNOME target: ---
GNOME version: ---

A small RF64 file generated with libsndfile. (172.37 KB, application/octet-stream)
2014-08-28 18:46 UTC, Peter G. Baum
wavparse: support rf64 format (3.95 KB, patch)
2014-08-28 19:09 UTC, Peter G. Baum
committed Details | Review
wavenc: support RF64 format (8.88 KB, patch)
2014-08-29 14:33 UTC, Peter G. Baum
reviewed Details | Review
gstwavenc: support RF64 format (6.86 KB, patch)
2014-10-04 12:47 UTC, Peter G. Baum
needs-work Details | Review
Patch integrating Sebastian's comments (6.89 KB, patch)
2014-10-05 19:31 UTC, Peter G. Baum
committed Details | Review

Description Peter G. Baum 2014-08-28 18:46:56 UTC
Created attachment 284733 [details]
A small RF64 file generated with libsndfile.

MBWF / RF64 is an extended File Format for enabling file sizes to exceed 4 Gbyte defined by the EBU (European Broadcast Union) see

To use gstreamer in professional environments where audio files exceed 4 GB this file format has to be supported.
Comment 1 Peter G. Baum 2014-08-28 19:09:44 UTC
Created attachment 284740 [details] [review]
wavparse: support rf64 format

To make this work a patch to gst-plugins-base is necessary, which is handled in bug #735631.
Comment 2 Sebastian Dröge (slomo) 2014-08-29 08:56:36 UTC
Comment on attachment 284740 [details] [review]
wavparse: support rf64 format

commit f5df8af59e73c44d732b1f0bee6f78836e4cd321
Author: Sebastian Dröge <>
Date:   Fri Aug 29 11:55:26 2014 +0300

    wavparse: Store size of data tag in a 64 bit integer locally too
    Otherwise we will clip the DS64 value of RF64 files to 32 bits again.

commit d924f8a9556056f21b6d024d3ee4178178b8c20e
Author: Sebastian Dröge <>
Date:   Fri Aug 29 11:53:23 2014 +0300

    wavparse: Use 64 bit scaling functions now that fact is a 64 bit integer

commit 5c838af3003e4724e1e3192bd721f62cd81d7d77
Author: Peter G. Baum <>
Date:   Wed Aug 27 18:55:18 2014 +0200

    wavparse: support rf64 format
Comment 3 Sebastian Dröge (slomo) 2014-08-29 08:57:13 UTC
Not closing this bug yet as the title talks about wavenc but the patches so far were only for wavparse.
Comment 4 Peter G. Baum 2014-08-29 14:33:05 UTC
Created attachment 284819 [details] [review]
wavenc: support RF64 format

Patch for encoder part of RF64 support.
Comment 5 Sebastian Dröge (slomo) 2014-09-01 07:35:53 UTC
Review of attachment 284819 [details] [review]:

This should probably be negotiated via caps, maybe a new variant field for the WAV caps.

::: gst/wavenc/gstwavenc.c
@@ +186,3 @@
+  /* we could also automatically switch between WAV and RF64
+   * if the size grows beyond 4 GB, but then we would always
+   * have a JUNK chunk in WAV files, which is different from

There are also other WAV variants for support >4GB IIRC
Comment 6 Peter G. Baum 2014-09-07 14:16:41 UTC
1) caps should define a property of the stream, right? That means the same stream must have different properties depending on the destination file type. I find this a bit awkward. Is something like this already used in other plug-ins?

2) Yes, there are several other WAV variants for support of >4GB. The advantage of RF64 is that it is a company independent standard (EBU has quite a good name in Europe). It has also the advantage that it could automatically switch between "normal" wav and RF64 as described above, which is not the case with all others.
Comment 7 Sebastian Dröge (slomo) 2014-09-07 14:24:19 UTC
video/quicktime has this, there the variants are based on the ftyp. Could be quicktime, 3gpp, mp4, etc.
Comment 8 Peter G. Baum 2014-09-07 14:41:25 UTC
Sorry, I don't see it. Do you have a pointer to the source code of the plugin?
Comment 9 Sebastian Dröge (slomo) 2014-09-07 14:46:08 UTC
> gst-inspect-1.0 mp4mux
> gst-inspect-1.0 qtmux
and compare the src pad template caps
Comment 10 Peter G. Baum 2014-09-07 15:52:32 UTC
That means we would have rf64enc and wavenc, which map to the same source code and which can either be selected via name (rf64enc or wavenc) or caps (audio/x-raw variant=wav or audio/x-raw variant=rf64)?

This solution could be extend to more wav variants and is in line with quicktime.

I agree, this is the way to go.

If nobody disagrees, I'll rework the patch.
Comment 11 Tim-Philipp Müller 2014-09-07 17:19:47 UTC
For what it's worth, you can also let wavenc output one variant or the other based on downstream caps (that's how many encoders negotiate which profile to use or parsers which stream-format to use).
Comment 12 Sebastian Dröge (slomo) 2014-09-07 17:36:21 UTC
Yeah, just wavenc which negotiates the variant with downstream via caps seems enough (and default to normal WAV). We can add more factories later if needed.
Comment 13 Peter G. Baum 2014-09-22 19:07:54 UTC
Could you please give me a hint how to get the negotiated src caps?
Comment 14 Sebastian Dröge (slomo) 2014-09-24 07:44:47 UTC
Before setting the caps on the srcpad of wavenc, and before deciding on a format, you would e.g. call gst_pad_get_allowed_caps() on the srcpad and then check what downstream wants. Then decide on a format based on that.
Comment 15 Peter G. Baum 2014-10-04 12:47:57 UTC
Created attachment 287711 [details] [review]
gstwavenc: support RF64 format
Comment 16 Sebastian Dröge (slomo) 2014-10-05 18:56:20 UTC
Review of attachment 287711 [details] [review]:

::: gst/wavenc/gstwavenc.c
@@ +99,3 @@
+#define SRC_CAPS \
+    "audio/x-wav; " \
+    "audio/x-rf64"

Is audio/x-rf64 used by anything else already? As a mimetype maybe? Otherwise an option would also be to use audio/x-wav,format=rf64

@@ +1033,3 @@
+      caps = gst_caps_truncate (caps);
+    }
+    str = gst_caps_to_string (caps);

GstStructure *s = gst_caps_get_structure (caps, 0);
wavenc->use_rf64 = gst_structure_has_name (s, "audio/x-rf64");

@@ +1037,3 @@
+    g_free (str);
+    gst_pad_set_caps (wavenc->srcpad, caps);

Comment 17 Peter G. Baum 2014-10-05 19:31:56 UTC
Created attachment 287775 [details] [review]
Patch integrating Sebastian's comments

I'm not quite sure about the "audio/x-wav,format=rf64".
Since it is not strictly a wav-version since it does not use a RIFF-chunk but a RF64, I think an own type is more appropriate than a version of x-wav.
Even though I never saw audio/x-rf64 before. "file" reports it as "MBWF/RF64 audio".
Comment 18 Peter G. Baum 2014-10-13 19:32:37 UTC
Any comments to the patch?
Comment 19 Sebastian Dröge (slomo) 2014-10-14 08:26:09 UTC
commit b5e46c05d79ad88089db3d88bcd6c9cb9db8626c
Author: Peter G. Baum <>
Date:   Sun Oct 5 21:24:27 2014 +0200

    wavenc: Support RF64 format