LPCM in mpeg(ts)

[Michael Olbrich]

Hi,

I have a mpegts stream with LPCM audio that is currently not supported by
the tsdemux element. I'm looking for some advice on the best way to
implement this. The specification can be found here[1].
It's similar to the format implemented in dvdlpcmdec. Just a different
header. The stream type is 0x83.

I hacked dvdlpcmdec to support a different header. That works sometimes,
but the event handling in dvdlpcmdec is rather broken and the pipeline
fails to start occasionally.

I looked into rewriting dvdlpcmdec to use GstAudioDecoder but that's where
I got stuck:
The format currently supported by dvdlpcmdec is somewhat special: The
buffer timestamp might not refer to the first sample but somewhere in the
middle (the offset is specified in the header). I have no idea how to
handle this with GstAudioDecoder.

Any Ideas? Maybe split it into a parser and decoder and handle the header
and timestamps in the parser?

And what caps should tsdemux produce for the new format?
audio/x-private2-lpcm?

Regards,
Michael

[1] http://www.dvdforum.org/images/Guideline1394V10R0_20020911.pdf

--
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: [phone]    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   [phone]-5555 |
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Di, 2016-04-26 at 12:42 +0200, Michael Olbrich wrote:
> Hi,
>
> I have a mpegts stream with LPCM audio that is currently not supported by
> the tsdemux element. I'm looking for some advice on the best way to
> implement this. The specification can be found here[1].
> It's similar to the format implemented in dvdlpcmdec. Just a different
> header. The stream type is 0x83.

What are all the differences between this and the already supported
LPCM?

> I hacked dvdlpcmdec to support a different header. That works sometimes,
> but the event handling in dvdlpcmdec is rather broken and the pipeline
> fails to start occasionally.
>
> I looked into rewriting dvdlpcmdec to use GstAudioDecoder but that's where
> I got stuck:
> The format currently supported by dvdlpcmdec is somewhat special: The
> buffer timestamp might not refer to the first sample but somewhere in the
> middle (the offset is specified in the header). I have no idea how to
> handle this with GstAudioDecoder.

Take a look at e.g. a52dec, it is solving exactly the same problem
for audio/x-private1-ac3 caps coming from DVDs.

> Any Ideas? Maybe split it into a parser and decoder and handle the header
> and timestamps in the parser?
>
> And what caps should tsdemux produce for the new format?
> audio/x-private2-lpcm?

Seems like a good start, yes.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Michael Olbrich]

On Wed, Apr 27, 2016 at 09:12:22AM +0300, Sebastian Dröge wrote:

> On Di, 2016-04-26 at 12:42 +0200, Michael Olbrich wrote:
> > Hi,
> >
> > I have a mpegts stream with LPCM audio that is currently not supported by
> > the tsdemux element. I'm looking for some advice on the best way to
> > implement this. The specification can be found here[1].
> > It's similar to the format implemented in dvdlpcmdec. Just a different
> > header. The stream type is 0x83.
>
> What are all the differences between this and the already supported
> LPCM?

Just the header: Different size and some fields are different.

> > I hacked dvdlpcmdec to support a different header. That works sometimes,
> > but the event handling in dvdlpcmdec is rather broken and the pipeline
> > fails to start occasionally.
> >
> > I looked into rewriting dvdlpcmdec to use GstAudioDecoder but that's where
> > I got stuck:
> > The format currently supported by dvdlpcmdec is somewhat special: The
> > buffer timestamp might not refer to the first sample but somewhere in the
> > middle (the offset is specified in the header). I have no idea how to
> > handle this with GstAudioDecoder.
>
> Take a look at e.g. a52dec, it is solving exactly the same problem
> for audio/x-private1-ac3 caps coming from DVDs.
>
> > Any Ideas? Maybe split it into a parser and decoder and handle the header
> > and timestamps in the parser?
> >
> > And what caps should tsdemux produce for the new format?
> > audio/x-private2-lpcm?
>
> Seems like a good start, yes.

Thanks for the tips. I've created a new bug[1] with the initial version of
my patches.

Regards,
Michael

[1] https://bugzilla.gnome.org/show_bug.cgi?id=765807

--
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: [phone]    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   [phone]-5555 |
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel