GStreamer-devel

A tsdemuxer PIDs property

Classic

List

Threaded

16 messages Options

Eric Trousset

A tsdemuxer PIDs property

Hi all,

I am porting my application from gstreamer 0.10 to 1.0. And I used to use FluTsDemuxer witch I could give the audio and video PIDs via the es-pid property. Its seems this element hasn’t been ported to 1.0, so is there an alternative TSDemuxer I could use witch would accept PID from properties?

Best regards,

Eric

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

Nicolas Dufresne-3

Re: A tsdemuxer PIDs property

Le vendredi 15 novembre 2013 à 12:37 +0100, Eric Trousset a écrit :

> I am porting my application from gstreamer 0.10 to 1.0. And I used to
> use FluTsDemuxer witch I could give the audio and video PIDs via the
> es-pid property. Its seems this element hasn’t been ported to 1.0, so
> is there an alternative TSDemuxer I could use witch would accept PID
> from properties?

In 1.0 the TS demuxer is called tsdemux and has a 'program-number'
property. I hope this is what you are looking for.

cheers,
Nicolas

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

signature.asc (205 bytes) Download Attachment

Eric Trousset

RE: A tsdemuxer PIDs property

Actualy, I need to set the PID of the stream, the server we are working on doesn't have a PAT in the stream, we get the video PID and the audio PID via http.

Eric

> -----Original Message-----
> From: Nicolas Dufresne [mailto:[hidden email]]
> Sent: vendredi 15 novembre 2013 16:03
> To: Discussion of the development of and with GStreamer
> Subject: Re: A tsdemuxer PIDs property
>
> Le vendredi 15 novembre 2013 à 12:37 +0100, Eric Trousset a écrit :
>
> > I am porting my application from gstreamer 0.10 to 1.0. And I used to
> > use FluTsDemuxer witch I could give the audio and video PIDs via the
> > es-pid property. Its seems this element hasn’t been ported to 1.0, so
> > is there an alternative TSDemuxer I could use witch would accept PID
> > from properties?
>
> In 1.0 the TS demuxer is called tsdemux and has a 'program-number'
> property. I hope this is what you are looking for.
>
> cheers,
> Nicolas

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

Nicolas Dufresne-3

Re: A tsdemuxer PIDs property

Le vendredi 15 novembre 2013 à 16:14 +0100, Eric Trousset a écrit :
> Actualy, I need to set the PID of the stream, the server we are working on doesn't have a PAT in the stream, we get the video PID and the audio PID via http.

Not 100% sure, but normally one would watch for pad-added signal and
select the pads that match the PID you want, and finally drop the data
on the other pads. Keeping the pads around might be useful if later you
want to switch. You'll get the pid in the stream-start event which shall
be sticked to the pad before pad-added is signal. See
gst_pad_get_sticky_event() and gst_event_parse_stream_start().

cheers,
Nicolas

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

signature.asc (205 bytes) Download Attachment

Edward Hervey-4

Re: A tsdemuxer PIDs property

In reply to this post by Eric Trousset

Hi,

On Fri, 2013-11-15 at 12:37 +0100, Eric Trousset wrote:
> Hi all,
>
>
>
> I am porting my application from gstreamer 0.10 to 1.0. And I used to
> use FluTsDemuxer witch I could give the audio and video PIDs via the
> es-pid property. Its seems this element hasn’t been ported to 1.0, so
> is there an alternative TSDemuxer I could use witch would accept PID
> from properties?

tsdemux doesn't (and most likely will never) allow setting PES PID.

The rationale is that if you don't have a PMT ... you can't guess the
nature/type/caps/property of the individual PES streams.

That being said, if you *do* have PMT we could envision adding a
property to specify on which PID it is.

Edward

>
>
>
> Best regards,
>
> Eric
>
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

signature.asc (853 bytes) Download Attachment

Eric Trousset

RE: A tsdemuxer PIDs property

Hi,
I ll check what we got in the stream, but for now, we get the PIDs we need to show/play via upnp, and don't get any program information.
Also, we might need to change the played stream during playback.

Eric

> -----Original Message-----
> From: Edward Hervey [mailto:[hidden email]]
> Sent: vendredi 15 novembre 2013 16:43
> To: Discussion of the development of and with GStreamer
> Subject: Re: A tsdemuxer PIDs property
>
> Hi,
>
> On Fri, 2013-11-15 at 12:37 +0100, Eric Trousset wrote:
> > Hi all,
> >
> >
> >
> > I am porting my application from gstreamer 0.10 to 1.0. And I used to
> > use FluTsDemuxer witch I could give the audio and video PIDs via the
> > es-pid property. Its seems this element hasn’t been ported to 1.0, so
> > is there an alternative TSDemuxer I could use witch would accept PID
> > from properties?
>
> tsdemux doesn't (and most likely will never) allow setting PES PID.
>
> The rationale is that if you don't have a PMT ... you can't guess the
> nature/type/caps/property of the individual PES streams.
>
> That being said, if you *do* have PMT we could envision adding a property
> to specify on which PID it is.
>
> Edward
>
> >
> >
> >
> > Best regards,
> >
> > Eric
> >
> >
> > _______________________________________________
> > gstreamer-devel mailing list
> > [hidden email]
> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

Eric Trousset

RE: A tsdemuxer PIDs property

Using MediaInfo, I can confirm I have no PAT/PMT in the stream, so I can only rely on the PID I receive via upnp to select the streams I render in the player.

Regards,
Eric

> -----Original Message-----
> From: Eric Trousset [mailto:[hidden email]]
> Sent: vendredi 15 novembre 2013 17:13
> To: Discussion of the development of and with GStreamer
> Subject: RE: A tsdemuxer PIDs property
>
> Hi,
> I ll check what we got in the stream, but for now, we get the PIDs we need to
> show/play via upnp, and don't get any program information.
> Also, we might need to change the played stream during playback.
>
> Eric
>
> > -----Original Message-----
> > From: Edward Hervey [mailto:[hidden email]]
> > Sent: vendredi 15 novembre 2013 16:43
> > To: Discussion of the development of and with GStreamer
> > Subject: Re: A tsdemuxer PIDs property
> >
> > Hi,
> >
> > On Fri, 2013-11-15 at 12:37 +0100, Eric Trousset wrote:
> > > Hi all,
> > >
> > >
> > >
> > > I am porting my application from gstreamer 0.10 to 1.0. And I used
> > > to use FluTsDemuxer witch I could give the audio and video PIDs via
> > > the es-pid property. Its seems this element hasn’t been ported to
> > > 1.0, so is there an alternative TSDemuxer I could use witch would
> > > accept PID from properties?
> >
> > tsdemux doesn't (and most likely will never) allow setting PES PID.
> >
> > The rationale is that if you don't have a PMT ... you can't guess
> > the nature/type/caps/property of the individual PES streams.
> >
> > That being said, if you *do* have PMT we could envision adding a
> > property to specify on which PID it is.
> >
> > Edward
> >
> > >
> > >
> > >
> > > Best regards,
> > >
> > > Eric
> > >
> > >
> > > _______________________________________________
> > > gstreamer-devel mailing list
> > > [hidden email]
> > > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

Edward Hervey-4

Re: A tsdemuxer PIDs property

On Fri, 2013-11-15 at 17:37 +0100, Eric Trousset wrote:
> Using MediaInfo, I can confirm I have no PAT/PMT in the stream, so I can only rely on the PID I receive via upnp to select the streams I render in the player.

So I assume UPNP has an out-of-bound mechanism to tell you what media
type each PID is ? In the HTTP headers maybe ? Also, is this a
"standard" UPNP/DLNA behaviour (to not put PAT/PMT in stream and
indicate streams in a different fashion) ?

BTW, track selection has nothing to do with this problem (demuxer just
exposes pads for all available streams and you switch accordingly).

Regards,

Edward

>
> Regards,
> Eric
>
> > -----Original Message-----
> > From: Eric Trousset [mailto:[hidden email]]
> > Sent: vendredi 15 novembre 2013 17:13
> > To: Discussion of the development of and with GStreamer
> > Subject: RE: A tsdemuxer PIDs property
> >
> > Hi,
> > I ll check what we got in the stream, but for now, we get the PIDs we need to
> > show/play via upnp, and don't get any program information.
> > Also, we might need to change the played stream during playback.
> >
> > Eric
> >
> > > -----Original Message-----
> > > From: Edward Hervey [mailto:[hidden email]]
> > > Sent: vendredi 15 novembre 2013 16:43
> > > To: Discussion of the development of and with GStreamer
> > > Subject: Re: A tsdemuxer PIDs property
> > >
> > > Hi,
> > >
> > > On Fri, 2013-11-15 at 12:37 +0100, Eric Trousset wrote:
> > > > Hi all,
> > > >
> > > >
> > > >
> > > > I am porting my application from gstreamer 0.10 to 1.0. And I used
> > > > to use FluTsDemuxer witch I could give the audio and video PIDs via
> > > > the es-pid property. Its seems this element hasn’t been ported to
> > > > 1.0, so is there an alternative TSDemuxer I could use witch would
> > > > accept PID from properties?
> > >
> > > tsdemux doesn't (and most likely will never) allow setting PES PID.
> > >
> > > The rationale is that if you don't have a PMT ... you can't guess
> > > the nature/type/caps/property of the individual PES streams.
> > >
> > > That being said, if you *do* have PMT we could envision adding a
> > > property to specify on which PID it is.
> > >
> > > Edward
> > >
> > > >
> > > >
> > > >
> > > > Best regards,
> > > >
> > > > Eric
> > > >
> > > >
> > > > _______________________________________________
> > > > gstreamer-devel mailing list
> > > > [hidden email]
> > > > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> > _______________________________________________
> > gstreamer-devel mailing list
> > [hidden email]
> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

signature.asc (853 bytes) Download Attachment

Eric Trousset

RE: A tsdemuxer PIDs property

Hi,
Actually we get the PIDs from the via au nonstandard field in the media protocol info.
Btw, if I dump the pipeline, it does seem the demuxer exposes any output.

Mediainfo returns the following info for the stream :

General
Complete name : stream_playspeed_1.000000_seek_0s.bin
Format : BDAV
Format/Info : Blu-ray Video
Format profile : No PAT/PMT
File size : 1.12 MiB
Duration : 3s 86ms
Overall bit rate : 3 047 Kbps

Video
ID : 4112 (0x1010)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Duration : 3s 86ms
Bit rate : 2 534 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 59.940 fps
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.046
Stream size : 955 KiB (83%)
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio
ID : 4114 (0x1012)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Duration : 3s 72ms
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Delay relative to video : -1s 20ms
Stream size : 144 KiB (13%)

Any clue why I don't get any source (output) pads then?

Regards,
Eric

> -----Original Message-----
> From: Edward Hervey [mailto:[hidden email]]
> Sent: dimanche 17 novembre 2013 21:34
> To: Discussion of the development of and with GStreamer
> Subject: Re: A tsdemuxer PIDs property
>
> On Fri, 2013-11-15 at 17:37 +0100, Eric Trousset wrote:
> > Using MediaInfo, I can confirm I have no PAT/PMT in the stream, so I can
> only rely on the PID I receive via upnp to select the streams I render in the
> player.
>
> So I assume UPNP has an out-of-bound mechanism to tell you what media
> type each PID is ? In the HTTP headers maybe ? Also, is this a "standard"
> UPNP/DLNA behaviour (to not put PAT/PMT in stream and indicate streams
> in a different fashion) ?
>
> BTW, track selection has nothing to do with this problem (demuxer just
> exposes pads for all available streams and you switch accordingly).
>
> Regards,
>
> Edward
>
>
> >
> > Regards,
> > Eric
> >
> > > -----Original Message-----
> > > From: Eric Trousset [mailto:[hidden email]]
> > > Sent: vendredi 15 novembre 2013 17:13
> > > To: Discussion of the development of and with GStreamer
> > > Subject: RE: A tsdemuxer PIDs property
> > >
> > > Hi,
> > > I ll check what we got in the stream, but for now, we get the PIDs
> > > we need to show/play via upnp, and don't get any program information.
> > > Also, we might need to change the played stream during playback.
> > >
> > > Eric
> > >
> > > > -----Original Message-----
> > > > From: Edward Hervey [mailto:[hidden email]]
> > > > Sent: vendredi 15 novembre 2013 16:43
> > > > To: Discussion of the development of and with GStreamer
> > > > Subject: Re: A tsdemuxer PIDs property
> > > >
> > > > Hi,
> > > >
> > > > On Fri, 2013-11-15 at 12:37 +0100, Eric Trousset wrote:
> > > > > Hi all,
> > > > >
> > > > >
> > > > >
> > > > > I am porting my application from gstreamer 0.10 to 1.0. And I
> > > > > used to use FluTsDemuxer witch I could give the audio and video
> > > > > PIDs via the es-pid property. Its seems this element hasn’t been
> > > > > ported to 1.0, so is there an alternative TSDemuxer I could use
> > > > > witch would accept PID from properties?
> > > >
> > > > tsdemux doesn't (and most likely will never) allow setting PES PID.
> > > >
> > > > The rationale is that if you don't have a PMT ... you can't
> > > > guess the nature/type/caps/property of the individual PES streams.
> > > >
> > > > That being said, if you *do* have PMT we could envision adding a
> > > > property to specify on which PID it is.
> > > >
> > > > Edward
> > > >
> > > > >
> > > > >
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Eric
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > gstreamer-devel mailing list
> > > > > [hidden email]
> > > > > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> > >
> > > _______________________________________________
> > > gstreamer-devel mailing list
> > > [hidden email]
> > > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> > _______________________________________________
> > gstreamer-devel mailing list
> > [hidden email]
> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

Sebastian Dröge-3

Re: A tsdemuxer PIDs property

On Mo, 2013-11-18 at 10:12 +0100, Eric Trousset wrote:
> Hi,
> Actually we get the PIDs from the via au nonstandard field in the media protocol info.
> Btw, if I dump the pipeline, it does seem the demuxer exposes any output.

I think tsdemux currently requires a PAT/PMT to expose any streams at
all, and proper MPEGTS streams should have this.

If you file a bug with a sample file, we could look into adding support
for your files if it can be done without risk of breaking anything or
making the code much more complicated.

--
Sebastian Dröge <[hidden email]>
Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source

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

signature.asc (985 bytes) Download Attachment

Eric Trousset

RE: A tsdemuxer PIDs property

Hi Seb,
I just filed a bug with a link to a mpegts file with no PAT/PMT
It's filed under Bug 715147

Cheers,
Eric T.

> -----Original Message-----
> From: Sebastian Dröge [mailto:[hidden email]]
> Sent: vendredi 22 novembre 2013 20:32
> To: Discussion of the development of and with GStreamer
> Subject: Re: A tsdemuxer PIDs property
>
> On Mo, 2013-11-18 at 10:12 +0100, Eric Trousset wrote:
> > Hi,
> > Actually we get the PIDs from the via au nonstandard field in the media
> protocol info.
> > Btw, if I dump the pipeline, it does seem the demuxer exposes any
> output.
>
> I think tsdemux currently requires a PAT/PMT to expose any streams at all,
> and proper MPEGTS streams should have this.
>
> If you file a bug with a sample file, we could look into adding support for your
> files if it can be done without risk of breaking anything or making the code
> much more complicated.
>
> --
> Sebastian Dröge <[hidden email]> Centricular Ltd -
> http://www.centricular.com Expertise, Straight from the Source

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

Duncan Palmer

Re: A tsdemuxer PIDs property

A useful use-case for having a tsdemux which doesn't first parse the PAT/PMT from the stream, is to reduce channel zap time on a DVB network. The PAT & PMT contents are stored somewhere else (e.g. a database), and you can save yourself a few hundred milliseconds by pulling pids and other information from the database rather than waiting for the tables to arrive at the demux. As Edward mentioned tho, there would need to be some generic mechanism to allow the tsdemux to determine caps etc. for the source pads.

On 25 November 2013 09:36, Eric Trousset <[hidden email]> wrote:

Hi Seb,
I just filed a bug with a link to a mpegts file with no PAT/PMT
It's filed under Bug 715147

Cheers,
Eric T.

> -----Original Message-----
> From: Sebastian Dröge [mailto:[hidden email]]
> Sent: vendredi 22 novembre 2013 20:32
> To: Discussion of the development of and with GStreamer
> Subject: Re: A tsdemuxer PIDs property
>

> On Mo, 2013-11-18 at 10:12 +0100, Eric Trousset wrote:
> > Hi,
> > Actually we get the PIDs from the via au nonstandard field in the media
> protocol info.
> > Btw, if I dump the pipeline, it does seem the demuxer exposes any
> output.
>
> I think tsdemux currently requires a PAT/PMT to expose any streams at all,
> and proper MPEGTS streams should have this.
>
> If you file a bug with a sample file, we could look into adding support for your
> files if it can be done without risk of breaking anything or making the code
> much more complicated.
>
> --
> Sebastian Dröge <[hidden email]> Centricular Ltd -
> http://www.centricular.com Expertise, Straight from the Source

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

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

Edward Hervey-4

Re: A tsdemuxer PIDs property

Hi,

On Wed, 2013-11-27 at 09:11 +0000, Duncan Palmer wrote:
> A useful use-case for having a tsdemux which doesn't first parse the
> PAT/PMT from the stream, is to reduce channel zap time on a DVB
> network. The PAT & PMT contents are stored somewhere else (e.g. a
> database), and you can save yourself a few hundred milliseconds by
> pulling pids and other information from the database rather than
> waiting for the tables to arrive at the demux. As Edward mentioned
> tho, there would need to be some generic mechanism to allow the
> tsdemux to determine caps etc. for the source pads.

That's indeed a perfectly valid use-case, and dvbbasebin could be made
to store and re-inject cached PAT/PMT to speed up zap time.
The end-result would be that tsdemux first receives the PAT/PMT for
the new channel before any data from that new channel.

Edward

>
>
>
> On 25 November 2013 09:36, Eric Trousset <[hidden email]> wrote:
> Hi Seb,
> I just filed a bug with a link to a mpegts file with no
> PAT/PMT
> It's filed under Bug 715147
>
> Cheers,
> Eric T.
>
> > -----Original Message-----
> > From: Sebastian Dröge [mailto:[hidden email]]
> > Sent: vendredi 22 novembre 2013 20:32
> > To: Discussion of the development of and with GStreamer
> > Subject: Re: A tsdemuxer PIDs property
> >
>
> > On Mo, 2013-11-18 at 10:12 +0100, Eric Trousset wrote:
> > > Hi,
> > > Actually we get the PIDs from the via au nonstandard field
> in the media
> > protocol info.
> > > Btw, if I dump the pipeline, it does seem the demuxer
> exposes any
> > output.
> >
> > I think tsdemux currently requires a PAT/PMT to expose any
> streams at all,
> > and proper MPEGTS streams should have this.
> >
> > If you file a bug with a sample file, we could look into
> adding support for your
> > files if it can be done without risk of breaking anything or
> making the code
> > much more complicated.
> >
> > --
> > Sebastian Dröge <[hidden email]> Centricular Ltd
> -
> > http://www.centricular.com Expertise, Straight from the
> Source
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

signature.asc (853 bytes) Download Attachment

Nicolas Dufresne-3

Re: A tsdemuxer PIDs property

Le mercredi 27 novembre 2013 à 10:54 +0100, Edward Hervey a écrit :

That's indeed a perfectly valid use-case, and dvbbasebin could be made
to store and re-inject cached PAT/PMT to speed up zap time.
The end-result would be that tsdemux first receives the PAT/PMT for
the new channel before any data from that new channel.

We could probably pass that into caps, it's very similar to codec_data in some sense, it's a blob of data specific to the stream the let it starts sooner or at all in some cases. (though codec_data would probably be a bad name).

just an idea,
Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

jopado

Re: A tsdemuxer PIDs property

Just a ping to see if this issue has been patched/resolved/worked-around. I see the referenced bug 715417 is still open. I have similar need to access data for a PID that is not listed in the PMT. Thank you.

Gst-Geek

Re: A tsdemuxer PIDs property

In reply to this post by Eric Trousset

Hi Eric Trousset,

In mpegtsmux you can set PID number through sink pad name. To set PES PID to 100, While requesting sink_%d of mpegtsmux pad request with pad name sink_100.

Hope this is what you are looking for.