mplayer only plays one audio track
vlc only plays one audio track

Also : did you miss the discussions on the ml about stream without PAT/PMT ???

Hi Ed,
with mplayer I am able to choose witch audio stream I want to play.

Can you point me to discussion?

Regards,
Eric

VLC doesn't play the file. GOM player plays the video. Mediainfo shows the container type as BDAV(No PAT/PMT)

But honestly what should be the behaviour of tsdemuxer if it doesn't find any PAT and PMT? How will it know what is the PID of each ES in such a case?

Regards,
Jagadish

Giving the demux, programs and pmts via object properties would be nice.

I began writing a patch to the tsdemuxer to allow this behaviour.
For now I am able to have the pipeline build correctly, but unfortunately, the streams don't want to play. I still don't know why. I'll have to investigate this after new year.

Cheers, 
Eric T

I can see one way to implement this, but *only* once bug #703884 has been implemented.

Once the logic in that bug has been handled, you would then only have to:
1) if more than 100ms (or more) has gone by without a PAT, assume that the PAT is indeed missing
2) For each of the pending PSI/SI streams, check which ones are potential PMT (table_id:0x02). If you have one use that PMT to initialize the program (and carry on as normal)
3) If you haven't found a PMT... you'll have to expose all PES streams
4) For each pending PES, you'll need to pass the data through the typefind functions to figure out what the nature of the stream is. If you have a very high probability match, use those caps and expose the stream
5) If you don't get a very high probability, it might be because we don't have a typefinder for that (might want to create one) or that we don't have enough data yet to typefind it.

Hi Ed,

that sounds good.

Also I tried another approach.

I added two properties to the mpegtsdemux, 
one to add a PAT, and one for a PMT in this way: 

 GstStructure *thePAT = gst_structure_new("pat",
                                          "program-number", G_TYPE_UINT, 1,
                                          "pmt-id", G_TYPE_UINT, 480,
                                          NULL);

 GstStructure *thePMT = gst_structure_new("pmt",
                                          "pmt-pid", G_TYPE_UINT, 480,
                                          "video-pid", G_TYPE_UINT, theVideoPid,
                                          "audio-pid", G_TYPE_UINT, theAudioPid,
                                          "program-number", G_TYPE_UINT, 1,
                                          NULL);
 g_object_set(G_OBJECT(GST_MESSAGE_SRC(aMessage)),
                "add-pat", thePAT,
                "add-pmt", thePMT,
                NULL); 

In the demux I created the a GstMpegTsSection for the PAT and one for the PMT.
Then I call mpegts_base_handle_psi with those struct as argument.

This way I am able to build the whole pipeline, but then I can't manage to actually have the media rendered.

The code is not the nicest as I had to duplicate some function from the mpegts lib, but I can provide it if you want/need.

Regards, 
Eric

Kindly share the patch

Regards,
Jagadish

Created attachment 265208 [details] [review]
Patch to add 'add-pat' and 'add-pmt' properties to the mpegtsdemux

This is a attempt in experimental stage.
I successed in getting the pipeline build for my media, but then it didn't render any output.

Created attachment 265209 [details] [review]
Added a function to create an empty section

(In reply to comment #6)
> Hi Ed,
> 
> that sounds good.
> 
> Also I tried another approach.
> 

  As is that approach is not acceptable

> The code is not the nicest as I had to duplicate some function from the mpegts
> lib, but I can provide it if you want/need.

  Why not just ... use that library instead of duplicating code from it ?

  An acceptable change would be to have tsdemux/tsparse accept PAT/PMT as downstream events (i.e. coming from upstream). This would also be the longer-term way of handling fast-dvb-startup also (dvbsrc/dvbbasebin could cache the PAT/PMT for various channels and push-them asap as in-band events to notify tsparse/tsemux of upcoming streams).

  In your case it would then end up being:
  1) Create PAT/PMT sections with the mpeg-ts lib
  2) Wrap them as GstEvent
  3) Set/Send those events on tsdemux/tsparse

  There is another bug report regarding adding support for MpegTSSsection as GstEvent, you could re-use/extend that (and I should review it :()

The bug about sections : https://bugzilla.gnome.org/show_bug.cgi?id=671136

Hi, 
thx for the info.
Sorry for the code duplication, I knew it was ugly, but it was quick :)

The GstEvent approach seems actually better. I'll have a look at it!

Cheers,
Eric

Shall I :

- Move the code I wrote in the SetPropertie to the mpegtslib and create to function to create the the Sections in the lib.

-Create a custom event to send PMT/PAT downstream.

-Add code to handle those events in the demux

Am I correct with this?

Actually I see the Jesper has writen code to create the sections allready...

Created attachment 265822 [details] [review]
Patch to handle Mpeg ts section event.

Need mpegts lib form head with patch from https://bugzilla.gnome.org/show_bug.cgi?id=671136 to build.

Known bugs :
- the media doesn't seem to be seekable, and the seek is doesn't exit...
- The audio and the video are not sync, 1 or 2 second latency...

First bug should linked to (In reply to comment #16)
> Known bugs :
> - the media doesn't seem to be seekable, and the seek is doesn't exit...
must be linked to https://bugzilla.gnome.org/show_bug.cgi?id=721835

> - The audio and the video are not sync, 1 or 2 second latency...

Eric, those various bugs you mention have been updated. Might want to rebase your patch.

Furthermore, I've had yet-another-idea to speed up stream type detection (i.e. steps 4/5 from Comment #5).

Instead of passing the data through typefind, we can also analyze the various PES start codes and data to identify the stream type.

vlc does that and has covered a good amount of solutions : http://git.videolan.org/?p=vlc.git;a=blob;f=modules/demux/ps.h;h=c36bdcdb0b585418628b1e27968ccc1d60cc7ade;hb=HEAD#l81

Hi, thx fir the update, I'll have a look to the updated code in the next week(s).

(In reply to comment #18)
> Eric, those various bugs you mention have been updated. Might want to rebase
> your patch.
> 
> Furthermore, I've had yet-another-idea to speed up stream type detection (i.e.
> steps 4/5 from Comment #5).
> 
> Instead of passing the data through typefind, we can also analyze the various
> PES start codes and data to identify the stream type.
> 
> vlc does that and has covered a good amount of solutions :
> http://git.videolan.org/?p=vlc.git;a=blob;f=modules/demux/ps.h;h=c36bdcdb0b585418628b1e27968ccc1d60cc7ade;hb=HEAD#l81

This is definitely still valid, but renaming the title accordingly.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/117.