Created attachment 336421 [details] [review]
fdkaacenc: set framed=true on src caps

Comment on attachment 336421 [details] [review]
fdkaacenc: set framed=true on src caps

How is this fixing muxing in MPEG-TS? You mean it does not work if you insert aacparse? That seems problematic and should be fixed then.

This patch seems good to go though.

It worked with an extra aacparse. I was just comparing pipelines using another aac element to see where the fdk one failed and the other one worked.

Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk>
Date:   Wed Sep 28 09:44:58 2016 +0100

    fdkaacenc: set framed=true on src caps
    
    This fixes muxing in MPEG TS.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=772108

I assume you checked to make sure it really does output framed data? :)

AFAICT, it's one frame in, one frame out. And it plays fine :)

Sorry for banging on about it, but that doesn't necessarily mean it's framed :)

And with MPEG-TS "it plays fine" isn't really meaningful because the format itself doesn't require framing and the framing can be re-instated from the ADTS headers.

Could you check for ADTS frame headers in the output of each buffer and also confirm that "raw" mode works with mp4? (I don't have a build with it at hand right now).

ADTS, as in ADIF and raw can't be framed ? I thought framed meant split at "frame boundaries for that format" to gst buffers. I've just looked in the docs and there isn't any mention of whether the output will always be one frame, so  I guess I'll revert that.

This creates a file which gst-play-1.0 can play (not using fdk):

gst-launch-1.0 audiotestsrc num-buffers=40 ! fdkaacenc ! mp4mux ! filesink location=foo.mp4

Not super sure how to tell whether the headers are what you intend though, sorry.

They can all be framed. With ADTS you can just easily check. If it looks fine for a few buffers it probably is framed.

If the mp4 plays fine it likely is framed, so all good from the sound of it, thanks for checking!