mpeg-ts playback

[Dave Walker]

Doesn't look like it was supported in 1.2 - that was one of my experiments.
But I'll go take a look. That approach makes sense.

In general does the active master branch stay pretty stable? For a project
that's pushing into new-ish territory (HLS and Android support) would you
recommend using 1.2 or 1.3?

Dave


On Thu, Mar 6, 2014 at 7:43 AM, Sebastian Dröge
<sebastian at centricular.com>wrote:

> On Di, 2014-03-04 at 01:05 -0800, Dave Walker wrote:
> > I've been attempting to get MPEG-TS content to play back using the
> Android
> > mediacodec decoders. I finally got it working and wanted to report my
> > findings and ask a couple questions about how to proceed. My device is a
> > Samsung Galaxy S4, and I'm not sure how commonplace this behavior is.
> >
> > When I started the audio decoder failed to start. When buffering the
> first
> > frame I got the following from the OMX codec:
> >
> > E/SEC_AAC_DEC(  208):  This is unsupported profile in SAACD. Profile 31
> is
> > not supported
> > E/SEC_AAC_DEC(  208):  SAACD only supports AAC-LC Profile
> >
> > So, the decoder's confused about profile. Often this data is passed in
> via
> > a 'csd-0' element in the MediaFormat, and sure enough it looks like this
> > has helped people in the past. The link below also points out an
> "is-adts"
> > flag in MediaFormat that should be sent to decode ADTS content, which is
> > what I have.
> >
> >
> http://stackoverflow.com/questions/18784781/how-to-initialize-mediaformat-to-configure-a-mediacodec-to-decode-raw-aac-data
> >
> > I added both csd-0 and is-adts to my MediaFormat, and this shifted around
> > the error a bit but ultimately didn't get rid of it. However, if I strip
> > out the 7 byte ADTS headers but leave the csd-0 buffer in place to
> include
> > the format parameters, then the content plays fine.
> >
> > My question is - how should I best implement this for real? The ADTS
> format
> > is slightly more complicated than a simple 7 byte header, and I'm not
> sure
> > converting from adts->raw is really the business of the amc component. It
> > appears that this may be a device-specific foible, and that in general
> > devices should support this as long as is-adts is in the format. But my
> > device is a super common one - adding a workaround seems reasonable and
> par
> > for the course for the MediaCodec support. In any case the csd-0 element
> > will be needed to properly decode ADTS content, and the tsdemux component
> > isn't producing the codec data. I assume the correct fix here is to have
> > the demuxer create this data as part of its caps.
> >
> > Thanks, and apologies in advance for any misunderstandings or mistaken
> > terminology. This is my first project in gstreamer.
> >
> > Thanks for any advice you can provide.
>
> You could put stream-format=raw on the sinkpad caps of the amc audio
> decoder for AAC. Then aacparse could do the conversion to the raw stream
> format from ADTS.
>
> I'm not entirely sure if this was already supported in 1.2 or if those
> changes to aacparse were added later.
>
> --
> Sebastian Dröge, Centricular Ltd - http://www.centricular.com
> Expertise, Straight from the Source
>
> _______________________________________________
> gstreamer-android mailing list
> gstreamer-android at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-android
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-android/attachments/20140306/be249b84/attachment.html>