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 767011 - rawparse: new rawaudioparse and rawvideoparse element which deprecate audioparse, unalignedaudioparse, and videoparse
rawparse: new rawaudioparse and rawvideoparse element which deprecate audiopa...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal enhancement
: 1.9.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-05-30 09:03 UTC by Carlos Rafael Giani
Modified: 2016-07-26 10:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
New rawaudioparse element (54.00 KB, patch)
2016-05-30 09:13 UTC, Carlos Rafael Giani
none Details | Review
New rawaudioparse element, v2 (69.62 KB, patch)
2016-06-02 09:24 UTC, Carlos Rafael Giani
none Details | Review
Patch with new audio and video parser elements (161.67 KB, patch)
2016-06-22 22:16 UTC, Carlos Rafael Giani
none Details | Review
Patch with new audio and video parser elements, v2 (158.51 KB, patch)
2016-06-27 10:52 UTC, Carlos Rafael Giani
none Details | Review
Patch with new audio and video parser elements, v3 (168.92 KB, patch)
2016-06-29 18:32 UTC, Carlos Rafael Giani
none Details | Review
330608: Patch with new audio and video parser elements, v4 (167.14 KB, patch)
2016-07-25 11:42 UTC, Carlos Rafael Giani
none Details | Review
Patch with new audio and video parser elements, v4 (167.18 KB, patch)
2016-07-25 11:46 UTC, Carlos Rafael Giani
none Details | Review
Patch with new audio and video parser elements, v5 (168.79 KB, patch)
2016-07-25 14:42 UTC, Carlos Rafael Giani
committed Details | Review
Old parser wrapper patch (76.22 KB, patch)
2016-07-25 15:59 UTC, Carlos Rafael Giani
committed Details | Review
Update rawparser documentation (12.57 KB, patch)
2016-07-25 16:00 UTC, Carlos Rafael Giani
committed Details | Review

Description Carlos Rafael Giani 2016-05-30 09:03:59 UTC
This is a new element that completely replaces audioparse and unalignedaudioparse. Its main benefits over the other two are:

* based on GstBaseParse instead of an old custom class that was based on GstElement
* retains the new audio/x-unaligned-raw sink caps media type
* works with autoplugging
* proper thread synchronization using the object lock (audioparse was lacking there)
* able to switch between properties based and sink caps based configuration (unlike with audioparse, sink caps based configuration is the default, which makes it work with autoplugging); switching can be done on the fly
* proper support for seeking (audioparse occasionally had issues, especially on embedded devices)
Comment 1 Carlos Rafael Giani 2016-05-30 09:13:03 UTC
Created attachment 328712 [details] [review]
New rawaudioparse element
Comment 2 Carlos Rafael Giani 2016-05-30 09:35:47 UTC
Forgot to add:

I opted for a rewrite instead of porting the audioparse code since baseparse makes the rawparse class almost completely redundant and the rest would be a mess. Also, this is an opportunity to introduce a more systematic naming scheme. "rawaudioparse" is much clearer than "audioparse". It also means that a future "rawvideoparse" could be introduced as well.
Comment 3 Olivier Crête 2016-05-31 15:39:50 UTC
Review of attachment 328712 [details] [review]:

Finally, someone ports our "most simple format" parser to baseparse! Thank you!

gstrawaudiocommon.h  is common with what ?

::: gst/rawparse/gstrawaudioparse.c
@@ +706,3 @@
+        );
+
+    raw_audio_parse->src_caps_set = TRUE;

Why set this outside the lock?

@@ +822,3 @@
+    GST_ERROR_OBJECT (raw_audio_parse,
+        "only %" G_GSIZE_FORMAT " bytes available, which is not enough", size);
+    flow_ret = GST_FLOW_ERROR;

This should never happen, you should just do a g_assert(). FYI, when returning GST_FLOW_ERROR, you MUST post a message on the bus using GST_ELEMENT_ERROR(), but in this case, g_assert() is enough.

@@ +923,3 @@
+       * bytes from a previous stream no longer apply.
+       * So, assume that no sink caps have ever been seen,
+       * and that the source pad caps have never been set. */

Is this true? I don't think stream start means that.

@@ +941,3 @@
+      GST_OBJECT_LOCK (raw_audio_parse);
+      gst_adapter_clear (raw_audio_parse->adapter);
+      raw_audio_parse->src_caps_set = FALSE;

flushes don't change the caps.

::: gst/rawparse/gstrawaudioparse.h
@@ +125,3 @@
+   * samples inside.
+   * The adapter is cleared during FLUSH_STOP and STREAM_START events. */
+  GstAdapter *adapter;

Why not use the adapter that's already in BaseParse? Setting the min_frame_size means you should only get whole "frames".
Comment 4 Carlos Rafael Giani 2016-05-31 16:06:45 UTC
> Is this true? I don't think stream start means that.

Then what does stream start mean, if not a start of a completely new stream?
Comment 5 Carlos Rafael Giani 2016-05-31 16:12:20 UTC
And:

> Why not use the adapter that's already in BaseParse? Setting the min_frame_size means you should only get whole "frames".

Is this true? I understood min_frame_size as the minimum size of a buffer, as indicated by this part of the docs: "A buffer of (at least) min_frame_size bytes is passed to subclass with handle_frame." On the other hand, the docs also mention: "Inform base class how big data chunks should be retrieved. This is done with gst_base_parse_set_min_frame_size() function." I suppose "how big data chunks" refers to multiples of min_frame_size?
Comment 6 Olivier Crête 2016-05-31 18:13:01 UTC
Review of attachment 328712 [details] [review]:

::: gst/rawparse/gstrawaudioparse.c
@@ +746,3 @@
+      GST_ERROR_OBJECT (parse,
+          "trying to push data even though current config is not ready");
+      flow_ret = GST_FLOW_ERROR;

In which case could this happen? If the src caps were rejected? Then it's GST_FLOW_NOT_NEGOTIATED? Otherwise, do GST_ELEMENT_ERROR() before returning GST_FLOW_ERROR.

@@ +866,3 @@
+
+  if (config->bpf == 0) {
+    GST_ERROR_OBJECT (parse, "trying to convert even though config->bpf is 0");

In which case can the ->bpf be 0? Shouldn't it always be valid either from the sink caps or from the properties?
Comment 7 Olivier Crête 2016-05-31 18:13:15 UTC
(In reply to Carlos Rafael Giani from comment #4)
> Then what does stream start mean, if not a start of a completely new stream?

It means a new "logical" stream, I don't think it requires the caps to change or be re-sent.

(In reply to Carlos Rafael Giani from comment #5)
> Is this true? I understood min_frame_size as the minimum size of a buffer,
> as indicated by this part of the docs: "A buffer of (at least)
> min_frame_size bytes is passed to subclass with handle_frame." On the other
> hand, the docs also mention: "Inform base class how big data chunks should
> be retrieved. This is done with gst_base_parse_set_min_frame_size()
> function." I suppose "how big data chunks" refers to multiples of
> min_frame_size?


Min size is indeed just a minimum, but if the base class gives you something that is more than the multiple of the "bpf, you can call _finish_frame() with a multiple of bpf and the following bytes will be given to you again in the next ->handle_frame(), the adapter in the base class is there exactly for the kind of stuff your doing, because almost all parsers have something like that.
Comment 8 Carlos Rafael Giani 2016-06-02 09:24:32 UTC
Created attachment 328929 [details] [review]
New rawaudioparse element, v2

Updated patch which addresses the aforementioned issues, adds new checks for corner cases (such as when upstream pushes a TIME segment and properties config is active), and adds unit tests.
Comment 9 Carlos Rafael Giani 2016-06-02 09:27:34 UTC
There is one corner case that I haven't been able to figure out yet. Take this pipeline:

  gst-launch-1.0 fakesrc filltype=5 sizetype=fixed sizemax=4096 ! "audio/x-raw,rate=44100,channels=2,format=S16LE,layout=interleaved" ! rawaudioparse ! fakesink sync=true

In this case, rawaudioparse receives stream-start , and then immediately afterwards data. This is because fakesrc is operating in pull mode. If can-activate-pull=false is added to fakesrc, it works. The question is how to catch this properly, or if it even makes sense to do so.

Also, if I replace rawaudioparse with audioconvert for example, it works. I guess this is because audioconvert operates in push mode.
Comment 10 Olivier Crête 2016-06-02 19:50:03 UTC
That case seems to also fail with the old "audioparse". The way I understand pull mode, the parser has to be able to just pull data without receiving segment or caps. I expected BaseSrc to push a segment event, but it seems to not do that in pull mode.
Comment 11 Sebastian Dröge (slomo) 2016-06-02 19:56:55 UTC
In pull mode (if you pull from upstream) you never get (and if you do it's a bug) events or anything pushed from upstream.
Comment 12 Carlos Rafael Giani 2016-06-08 07:18:23 UTC
Alright, then I'll not consider it a bug, and document it instead.

However, please hold back on committing this for now. I was able to begin the rawvideoparse development sooner than anticipated, and I'm extracting common rawaudio/rawvideo functionality to a rawbaseparse base class (which unlike the old rawparse base class is written on top of baseparse and has the config switching functionality that rawaudioparse already has). I'll update this in a few days.
Comment 13 Carlos Rafael Giani 2016-06-22 22:16:10 UTC
Created attachment 330221 [details] [review]
Patch with new audio and video parser elements

Thanks to many interferences, it took a little more than a few days :) This adds the rawaudioparse and rawvideoparse elements. They are both based on the new GstRawBaseParse class, which in turn is based on GstBaseParse. Tests for rawaudioparse and rawvideoparse are also added.

The old videoparse and audioparse elements are not needed anymore, and can be removed in a followup commit.
Comment 14 Sebastian Dröge (slomo) 2016-06-23 06:46:40 UTC
(In reply to Carlos Rafael Giani from comment #13)

> The old videoparse and audioparse elements are not needed anymore, and can
> be removed in a followup commit.

Would be good to register additional element factories for them though, for backwards compatibility for a while (and let them print deprecation warnings when used).
Comment 15 Carlos Rafael Giani 2016-06-23 07:05:09 UTC
(In reply to Sebastian Dröge (slomo) from comment #14)

> Would be good to register additional element factories for them though, for
> backwards compatibility for a while (and let them print deprecation warnings
> when used).

Alternatively, we could keep the old elements in 1.10, with deprecation warnings, and remove them in 1.12.
Comment 16 Sebastian Dröge (slomo) 2016-06-23 07:06:07 UTC
Review of attachment 330221 [details] [review]:

Unit tests \o/ I only shortly looked over it now and wrote down everything that I noticed

::: gst/rawparse/gstrawaudioparse.c
@@ +864,3 @@
+        channel_mask, config->channel_positions);
+  } else
+    return TRUE;

Curly braces

@@ +1039,3 @@
+  gst_caps_unref (caps);
+  if (ret)
+    config->ready = TRUE;

You only set this to ready here, nowhere else? What if we don't get config from caps? :)

::: gst/rawparse/gstrawbaseparse.c
@@ +126,3 @@
+
+
+#define DEFAULT_USE_SINK_CAPS  TRUE     /* default is TRUE to facilitate autoplugging */

Subclasses should maybe set it automatically to FALSE if any of the other properties is set?

@@ +382,3 @@
+    /* Push caps outside of the lock */
+    gst_pad_push_event (GST_BASE_PARSE_SRC_PAD (raw_base_parse),
+        gst_event_new_caps (new_src_caps)

The caps should probably be unreffed?

@@ +460,3 @@
+    }
+
+    new_caps_event = gst_event_new_caps (new_src_caps);

And unref the caps here?

@@ +527,3 @@
+    frame->out_buffer = processed_data;
+  } else
+    frame->out_buffer = NULL;

Curly braces please

@@ +548,3 @@
+  if (G_UNLIKELY (new_caps_event != NULL))
+    gst_pad_push_event (GST_BASE_PARSE_SRC_PAD (raw_base_parse),
+        new_caps_event);

There are various return-paths between this and creating the caps event, where the event is not unreffed

@@ +672,3 @@
+       * assume the buffers are timestamped properly and
+       * this rawbaseparse element does not actually have
+       * to do anything, so put it in passthrough mode.

It has to make sure the data is correctly chunked at least, or not? Upstream could know timestamps but not frame sizes

@@ +728,3 @@
+      if (new_src_caps)
+        gst_pad_push_event (GST_BASE_PARSE_SRC_PAD (parse),
+            gst_event_new_caps (new_src_caps));

Also caps leaked

@@ +784,3 @@
+  /* must be called with lock */
+  g_assert (raw_base_parse != NULL);
+  raw_base_parse->src_caps_set = FALSE;

This, and probably also some other things, should probably be reset in GstBaseParse::stop()

::: gst/rawparse/gstrawbaseparse.h
@@ +23,3 @@
+#include <gst/gst.h>
+#include <gst/base/gstadapter.h>
+#include <gst/base/gstbaseparse.h>

#include <gst/base/base.h>

@@ +43,3 @@
+
+#define GST_RAW_BASE_PARSE_CONFIG_MUTEX_LOCK(obj)   g_mutex_lock(&(((GstRawBaseParse *)(obj))->config_mutex))
+#define GST_RAW_BASE_PARSE_CONFIG_MUTEX_UNLOCK(obj) g_mutex_unlock(&(((GstRawBaseParse *)(obj))->config_mutex))

Why not the object lock?

::: gst/rawparse/gstrawvideoparse.c
@@ +1,2 @@
+/* GStreamer
+ * Copyright (C) <2016> Carlos Rafael Giani <dv at pseudoterminal dot org>

In general, you probably want to copy over the old copyrights of the files. I think you based some code on the old one, right?

@@ +232,3 @@
+          "Width",
+          "Width of frames in raw stream",
+          0, INT_MAX, DEFAULT_WIDTH, G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS)

G_MAXINT, etc

@@ +346,3 @@
+gst_raw_video_parse_dispose (GObject * object)
+{
+  //GstRawVideoParse *raw_video_parse = GST_RAW_VIDEO_PARSE(object);

No // comments

@@ +796,3 @@
+        GST_VIDEO_INFO_PAR_D (&(config_ptr->info));
+    config_ptr->framerate[0] = GST_VIDEO_INFO_FPS_N (&(config_ptr->info));
+    config_ptr->framerate[1] = GST_VIDEO_INFO_FPS_D (&(config_ptr->info));

Why an array? We everywhere else use _n and _d :) Seems inconsistent
Comment 17 Carlos Rafael Giani 2016-06-23 11:58:28 UTC
> @@ +1039,3 @@
> +  gst_caps_unref (caps);
> +  if (ret)
> +    config->ready = TRUE;
>
> You only set this to ready here, nowhere else? What if we don't get config from caps? :)

Hm I think it should be reset in the stop() vfunc. However, "if we don't get config from caps" refers to the properties config, and its ready parameter is set to TRUE in the _init function. (Same applies to rawvideoparse.)


> ::: gst/rawparse/gstrawbaseparse.c
> @@ +126,3 @@
> +
> +
> +#define DEFAULT_USE_SINK_CAPS  TRUE     /* default is TRUE to facilitate autoplugging */
>
> Subclasses should maybe set it automatically to FALSE if any of the other properties is set?

Is this really a good idea? This sounds to me like the type of "intelligent" behavior that can negatively surprise people. I'm not totally against it, just concerned that this would make the usage more confusing.


> @@ +382,3 @@
> +    /* Push caps outside of the lock */
> +    gst_pad_push_event (GST_BASE_PARSE_SRC_PAD (raw_base_parse),
> +        gst_event_new_caps (new_src_caps)
>
> The caps should probably be unreffed?

Oh. I remembered the new_caps behavior incorrectly then - I thought it takes ownership over the caps.


> @@ +672,3 @@
> +       * assume the buffers are timestamped properly and
> +       * this rawbaseparse element does not actually have
> +       * to do anything, so put it in passthrough mode.
>
> It has to make sure the data is correctly chunked at least, or not? Upstream could know timestamps but not frame sizes

This I do not understand. This is the _passthrough_ mode. The element is not supposed to touch the data at all in this mode. The role of the raw parsers is to parse _raw_ data. TIMES segments with timestamps is not raw data.


> Why not the object lock?

Because from discussions in #gstreamer I got the impression that the object lock is supposed to be used by actual elements, not by base classes. Also, I do call some base class functions within locked regions.


> In general, you probably want to copy over the old copyrights of the files. I think you based some code on the old one, right?

No. This is completely new code.
Comment 18 Sebastian Dröge (slomo) 2016-06-23 12:13:11 UTC
(In reply to Carlos Rafael Giani from comment #17)

> This I do not understand. This is the _passthrough_ mode. The element is not
> supposed to touch the data at all in this mode. The role of the raw parsers
> is to parse _raw_ data. TIMES segments with timestamps is not raw data.

Upstream could for example be adaptivedemux, which sends a TIME segment and the initial PTS for each fragment. However the data that comes is not chunked (it's just souphttpsrc in the end).
Comment 19 Carlos Rafael Giani 2016-06-23 12:20:00 UTC
Then perhaps we could introduce video/x-unaligned-raw , just like with audio. The passthrough mode is useful if for some reason a raw parser is autoplugged even though the incoming data is already timestamped and chunked. This can happen for example with rawaudioparse and mulaw content.
Comment 20 Sebastian Dröge (slomo) 2016-06-23 12:25:44 UTC
It should never be autoplugged for audio/x-raw
Comment 21 Carlos Rafael Giani 2016-06-23 12:28:23 UTC
"The initial PTS for each fragment" meaning ... what? Several buffers will have the same PTS from the corresponding fragment? And this means that the raw parsers should (re)timestamp and set durations even with TIME segments? That is, never enter passthrough mode?
Comment 22 Sebastian Dröge (slomo) 2016-06-23 12:35:38 UTC
The first one will have a PTS, the others will have NONE. The parser (and/or other elements) are supposed to take the timestamps they get and interpolate any missing timestamps.
Comment 23 Carlos Rafael Giani 2016-06-23 18:17:29 UTC
So this essentially means that I just have to dismantle the passthrough code, since this is what baseparse does anyway. The rawparsers already set the duration, and this is all that's needed. I can add an extra check to see if the duration is already set, and only if it isn't, I set my own.
Comment 24 Sebastian Dröge (slomo) 2016-06-24 08:17:21 UTC
Sounds good :)
Comment 25 Carlos Rafael Giani 2016-06-27 10:52:39 UTC
Created attachment 330426 [details] [review]
Patch with new audio and video parser elements, v2

Updated patch with the aforementioned issues fixed. Passthrough mode was removed. No special handling added, since there was little gain in it, and just complicated the code.
Comment 26 Sebastian Dröge (slomo) 2016-06-28 07:24:10 UTC
I think my main concern here is now that we would always "autoplug" these elements for audio/x-raw and video/x-raw, which might not be ideal. Maybe there should be one variant that only registers {audio,video}/x-raw-unaligned and has PRIMARY rank, and the other variant has all caps and NONE rank.
Comment 27 Carlos Rafael Giani 2016-06-29 14:44:06 UTC
I thought these caps won't have any autoplugging?

But we could keep the unalignedaudioparse element and set the default use-sink-caps property values to FALSE. Also what about the idea of a video/x-unaligned-raw caps and a new unalignedvideoparse element?
Comment 28 Sebastian Dröge (slomo) 2016-06-29 15:58:04 UTC
That seems useful, yes. Having unaligned elements around the new parsers that take the x-unaligned caps, are autoplugged and use the caps by default. And having the normal ones with NONE rank.
Comment 29 Carlos Rafael Giani 2016-06-29 18:32:48 UTC
Created attachment 330608 [details] [review]
Patch with new audio and video parser elements, v3

Set rawaudioparse & rawvideoparse ranks to NONE, and added an unalignedvideoparse element. unalignedaudioparse now uses rawaudioparse instead of audioparse.
Comment 30 Carlos Rafael Giani 2016-07-11 11:41:24 UTC
I'd like to propose this patch for the 1.9.2 release.
Comment 31 Sebastian Dröge (slomo) 2016-07-22 12:15:48 UTC
We should get this in for 1.10, yes
Comment 32 Sebastian Dröge (slomo) 2016-07-25 08:14:00 UTC
Review of attachment 330608 [details] [review]:

rawvideoparse is still missing the frame-size property (there could be more padding at the very end of a frame), otherwise this looks good to go to me.

Main reason why we can't remove the old parsers at this point is the property name changes, right? Apart from that it should be compatible?

::: gst/rawparse/gstrawaudioparse.h
@@ +89,3 @@
+   * for reordering channel data in outgoing buffers if necessary.
+   */
+  GstAudioChannelPosition *valid_channel_positions;

The two arrays here can just be statically allocated [64] arrays. Less memory to keep track of

::: gst/rawparse/gstrawvideoparse.c
@@ +940,3 @@
+   * from here */
+  while (TRUE) {
+    GstVideoMeta *videometa = gst_buffer_get_video_meta (out_data);

while ((videometa = gst_buffer_get_video_meta (out_data)) { ... }

might be more beautiful... but not so important :)
Comment 33 Carlos Rafael Giani 2016-07-25 09:03:26 UTC
frame-stride is the replacement for frame-size. It accomplishes exactly what you described (handling padding at the end of a frame).
Comment 34 Carlos Rafael Giani 2016-07-25 09:04:10 UTC
Oh, and forgot to add: I thought since the old parsers are in -bad , API changes are OK? Including the removal of plugins? So why do we have to keep the old ones now?
Comment 35 Sebastian Dröge (slomo) 2016-07-25 09:17:56 UTC
We should mark the existing elements as deprecated and let them print warnings and everything, and *ideally* make them just wrappers with the same interface around the new elements for a release or two. Otherwise code out there is just falling apart without warning.
Comment 36 Carlos Rafael Giani 2016-07-25 10:26:17 UTC
Okay. So should this deprecation / wrapping be done in a separate followup commit, or in this same one? What would be preferred?
Comment 37 Sebastian Dröge (slomo) 2016-07-25 10:28:05 UTC
Make it another commit
Comment 38 Carlos Rafael Giani 2016-07-25 11:42:41 UTC
Created attachment 332096 [details] [review]
330608: Patch with new audio and video parser elements, v4
Comment 39 Carlos Rafael Giani 2016-07-25 11:46:20 UTC
Created attachment 332098 [details] [review]
Patch with new audio and video parser elements, v4

Typo
Comment 40 Carlos Rafael Giani 2016-07-25 14:42:39 UTC
Created attachment 332106 [details] [review]
Patch with new audio and video parser elements, v5

Plane offset / stride values were not being tested for, and in fact were swapped internally (planet-offset property returned stride values and vice versa). Fixed & added test for these values.
Comment 41 Carlos Rafael Giani 2016-07-25 15:59:50 UTC
Created attachment 332110 [details] [review]
Old parser wrapper patch

Here is a patch to wrap the new parsers in the old parser interfaces, together with deprecation notes.
Comment 42 Carlos Rafael Giani 2016-07-25 16:00:56 UTC
Created attachment 332111 [details] [review]
Update rawparser documentation

And here are documentation updates
Comment 43 Sebastian Dröge (slomo) 2016-07-26 10:48:31 UTC
commit efa5b219e65ab3614270630eaf1163b3dc6f2dad
Author: Carlos Rafael Giani <dv@pseudoterminal.org>
Date:   Mon Jul 25 17:55:24 2016 +0200

    docs: Update rawparser documentation
    
    Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
    
    https://bugzilla.gnome.org/show_bug.cgi?id=767011

commit 403499a0c015920d367ba62531d515cfced1c3f3
Author: Carlos Rafael Giani <dv@pseudoterminal.org>
Date:   Mon Jul 25 17:54:09 2016 +0200

    rawparse: Remove old parser code and wrap new parsers in old elements
    
    https://bugzilla.gnome.org/show_bug.cgi?id=767011

commit d555f34562d8e477383df4d9f2b851db7de2af51
Author: Carlos Rafael Giani <dv@pseudoterminal.org>
Date:   Mon Jul 25 13:45:40 2016 +0200

    rawparse: Add new raw audio and video parser elements
    
    The new rawaudioparse and rawvideoparse elements are based on GstBaseParse
    and completely replace audioparse and videoparse
    
    https://bugzilla.gnome.org/show_bug.cgi?id=767011