GNOME Bugzilla – Bug 735627
wavenc/wavparse: should support RF64 files
Last modified: 2014-10-14 08:26:11 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 http://tech.ebu.ch/docs/tech/tech3306-2009.pdf. To use gstreamer in professional environments where audio files exceed 4 GB this file format has to be supported.
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 on attachment 284740 [details] [review] wavparse: support rf64 format commit f5df8af59e73c44d732b1f0bee6f78836e4cd321 Author: Sebastian Dröge <sebastian@centricular.com> 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 <sebastian@centricular.com> 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 <peter@dr-baum.net> Date: Wed Aug 27 18:55:18 2014 +0200 wavparse: support rf64 format https://bugzilla.gnome.org/show_bug.cgi?id=735627
Not closing this bug yet as the title talks about wavenc but the patches so far were only for wavparse.
Created attachment 284819 [details] [review] wavenc: support RF64 format Patch for encoder part of RF64 support.
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
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.
video/quicktime has this, there the variants are based on the ftyp. Could be quicktime, 3gpp, mp4, etc.
Sorry, I don't see it. Do you have a pointer to the source code of the plugin?
Check > gst-inspect-1.0 mp4mux > gst-inspect-1.0 qtmux and compare the src pad template caps
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.
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).
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.
Could you please give me a hint how to get the negotiated src caps?
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.
Created attachment 287711 [details] [review] gstwavenc: support RF64 format
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); gst_caps_unref(caps)
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".
Any comments to the patch?
commit b5e46c05d79ad88089db3d88bcd6c9cb9db8626c Author: Peter G. Baum <peter@dr-baum.net> Date: Sun Oct 5 21:24:27 2014 +0200 wavenc: Support RF64 format https://bugzilla.gnome.org/show_bug.cgi?id=725145