Traced down problem acquiring channels on AMC3-87W, 12180 V 30000 mpx

[Corey Ashford-2]

Hi Folks,

This is my first time posting here.

I'm using Kaffeine 0.8.6 to view a dvb-s source, and ran across a
problem with the first mpx I tried to channel scan - 12180 V 30000 on
AMC3-87W.

At first it was telling me that there was an invalid section header for
0x11 or there was a timeout.  I reported this on the linux-dvb site and
Cristophe Thommeret kindly suggested a change to make the code ignore
the fact that Kaffeine couldn't find an SDT.  

Well, after that, it was still not getting any channels from the scan
(though I could get them on other mpx's on the same satellite).  I
started adding a bunch of fprintf instrumentation in the code and
discovered that the channels were actually being acquired, but were
being rejected in the ScanDialog::checkNewChannel() because the
channel's napid field was set to zero.  This tells me that the scan was
unable to acquire any audio pids for the channel (I think).  However,
if I do a 'scandvb' (from dvb-apps) on the same multiplex, it does pick
up the audio pids.  Some something is amiss with picking up the audio
pids in kaffeine on this particular multiplex.

I will spend some more time tracking this down, but I thought I'd throw
that out there in case it rings some bells.

As an experiment, I modified checkNewChannel so that it wouldn't reject
a channel with an napid of 0, and lo and behold, I got a channel list
from the scan.  The video pids are correct, but no audio pids are set,
so as you might guess, I get video but no sound.  I edited a few of the
channels, and added the audio pids I got from the scandvb, and they
worked.. video and audio.

Thanks for reading this.  I'd be glad to try any suggested experiments.

- Corey



      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Kaffeine-devel mailing list
Kaffeine-devel@...
https://lists.sourceforge.net/lists/listinfo/kaffeine-devel

Le vendredi 01 février 2008 07:34, Corey Ashford a écrit :
> Hi Folks,

Hi again, Corey :) (i'm the Kaffeine dvb author)

> This is my first time posting here.
>
> I'm using Kaffeine 0.8.6 to view a dvb-s source, and ran across a
> problem with the first mpx I tried to channel scan - 12180 V 30000 on
> AMC3-87W.
>
> At first it was telling me that there was an invalid section header for
> 0x11 or there was a timeout.  I reported this on the linux-dvb site and
> Cristophe Thommeret kindly suggested a change to make the code ignore
> the fact that Kaffeine couldn't find an SDT.
>
> Well, after that, it was still not getting any channels from the scan
> (though I could get them on other mpx's on the same satellite).  I
> started adding a bunch of fprintf instrumentation in the code and
> discovered that the channels were actually being acquired, but were
> being rejected in the ScanDialog::checkNewChannel() because the
> channel's napid field was set to zero.  This tells me that the scan was
> unable to acquire any audio pids for the channel (I think).  However,
> if I do a 'scandvb' (from dvb-apps) on the same multiplex, it does pick
> up the audio pids.  Some something is amiss with picking up the audio
> pids in kaffeine on this particular multiplex.
>
> I will spend some more time tracking this down, but I thought I'd throw
> that out there in case it rings some bells.
>
> As an experiment, I modified checkNewChannel so that it wouldn't reject
> a channel with an napid of 0, and lo and behold, I got a channel list
> from the scan.  The video pids are correct, but no audio pids are set,
> so as you might guess, I get video but no sound.  I edited a few of the
> channels, and added the audio pids I got from the scandvb, and they
> worked.. video and audio.
>
> Thanks for reading this.  I'd be glad to try any suggested experiments.

Good catch. So there is a bug in SI parser, that we have to fix.
And since you offer to help, i would suggest to get "dvbsnoop"
(dvbsnoop.sf.net), a cli SI parser. When you get it, we will try to meat on
either #kaffeine or #linuxtv.

--
Christophe Thommeret


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Kaffeine-devel mailing list
Kaffeine-devel@...
https://lists.sourceforge.net/lists/listinfo/kaffeine-devel

[Corey Ashford-2]

Hi Cristophe,

I might be able to work on this tonight.  I live in Oregon which is
GMT-8.

I did dig a little deeper last night and found that some of the pid
types were not being recognized, in particular the codes 5,6, and 129.
I found that 129 is for ATSC AC3, so I added that to the ac3 case
that's already there, and I was able to pick up two audio pids (one for
English, and one for Spanish) for the one channel in the multiplex that
uses it.

Looking at the 5 & 6 codes, a document I found on the web describes
them as private or something.

Anyway, yeah, I will download dvbsnoop and start playing with that.
I'll need to set up an IRC client on that machine.

Thanks :)

- Corey

--- Christophe Thommeret <hftom@...> wrote:

> Le vendredi 01 février 2008 07:34, Corey Ashford a écrit :
> > Hi Folks,
>
> Hi again, Corey :) (i'm the Kaffeine dvb author)
>
> > This is my first time posting here.
> >
> > I'm using Kaffeine 0.8.6 to view a dvb-s source, and ran across a
> > problem with the first mpx I tried to channel scan - 12180 V 30000
> on
> > AMC3-87W.
> >
> > At first it was telling me that there was an invalid section header
> for
> > 0x11 or there was a timeout.  I reported this on the linux-dvb site
> and
> > Cristophe Thommeret kindly suggested a change to make the code
> ignore
> > the fact that Kaffeine couldn't find an SDT.
> >
> > Well, after that, it was still not getting any channels from the
> scan
> > (though I could get them on other mpx's on the same satellite).  I
> > started adding a bunch of fprintf instrumentation in the code and
> > discovered that the channels were actually being acquired, but were
> > being rejected in the ScanDialog::checkNewChannel() because the
> > channel's napid field was set to zero.  This tells me that the scan
> was
> > unable to acquire any audio pids for the channel (I think).
> However,
> > if I do a 'scandvb' (from dvb-apps) on the same multiplex, it does
> pick
> > up the audio pids.  Some something is amiss with picking up the
> audio
> > pids in kaffeine on this particular multiplex.
> >
> > I will spend some more time tracking this down, but I thought I'd
> throw
> > that out there in case it rings some bells.
> >
> > As an experiment, I modified checkNewChannel so that it wouldn't
> reject
> > a channel with an napid of 0, and lo and behold, I got a channel
> list
> > from the scan.  The video pids are correct, but no audio pids are
> set,
> > so as you might guess, I get video but no sound.  I edited a few of
> the
> > channels, and added the audio pids I got from the scandvb, and they
> > worked.. video and audio.
> >
> > Thanks for reading this.  I'd be glad to try any suggested
> experiments.
>
> Good catch. So there is a bug in SI parser, that we have to fix.
> And since you offer to help, i would suggest to get "dvbsnoop"
> (dvbsnoop.sf.net), a cli SI parser. When you get it, we will try to
> meat on
> either #kaffeine or #linuxtv.
>
> --
> Christophe Thommeret
>
>

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Kaffeine-devel mailing list
Kaffeine-devel@...
https://lists.sourceforge.net/lists/listinfo/kaffeine-devel

[Corey Ashford-2]

Quick follow up on this:

I haven't fixed Kaffeine yet, but I did run dvbsnoop on the multiplex,
and saw similar things as what I saw with my extra fprintfs, that there
are some private data pids, types 5 & 6, that go with each channel.

I plan, sometime soon, to look at the source to scandvb to see if I can
figure out why it is treating those as audio channels.  scandvb is
right that those pids are actually audio, but I'm wondering how it
knows that.  Maybe it looks deeper into the individual pid stream and
figures it out by looking at the headers?  Or maybe it just guesses
based on the fact that there aren't any other pids for audio, and
therefore these two must be it?

Anyway, more study is needed.

- Corey

--- Corey Ashford <yeroca@...> wrote:

> Hi Cristophe,
>
> I might be able to work on this tonight.  I live in Oregon which is
> GMT-8.
>
> I did dig a little deeper last night and found that some of the pid
> types were not being recognized, in particular the codes 5,6, and
> 129.
> I found that 129 is for ATSC AC3, so I added that to the ac3 case
> that's already there, and I was able to pick up two audio pids (one
> for
> English, and one for Spanish) for the one channel in the multiplex
> that
> uses it.
>
> Looking at the 5 & 6 codes, a document I found on the web describes
> them as private or something.
>
> Anyway, yeah, I will download dvbsnoop and start playing with that.
> I'll need to set up an IRC client on that machine.
>
> Thanks :)
>
> - Corey
>
> --- Christophe Thommeret <hftom@...> wrote:
>
> > Le vendredi 01 février 2008 07:34, Corey Ashford a écrit :
> > > Hi Folks,
> >
> > Hi again, Corey :) (i'm the Kaffeine dvb author)
> >
> > > This is my first time posting here.
> > >
> > > I'm using Kaffeine 0.8.6 to view a dvb-s source, and ran across a
> > > problem with the first mpx I tried to channel scan - 12180 V
> 30000
> > on
> > > AMC3-87W.
> > >
> > > At first it was telling me that there was an invalid section
> header
> > for
> > > 0x11 or there was a timeout.  I reported this on the linux-dvb
> site
> > and
> > > Cristophe Thommeret kindly suggested a change to make the code
> > ignore
> > > the fact that Kaffeine couldn't find an SDT.
> > >
> > > Well, after that, it was still not getting any channels from the
> > scan
> > > (though I could get them on other mpx's on the same satellite).
> I
> > > started adding a bunch of fprintf instrumentation in the code and
> > > discovered that the channels were actually being acquired, but
> were
> > > being rejected in the ScanDialog::checkNewChannel() because the
> > > channel's napid field was set to zero.  This tells me that the
> scan
> > was
> > > unable to acquire any audio pids for the channel (I think).
> > However,
> > > if I do a 'scandvb' (from dvb-apps) on the same multiplex, it
> does
> > pick
> > > up the audio pids.  Some something is amiss with picking up the
> > audio
> > > pids in kaffeine on this particular multiplex.
> > >
> > > I will spend some more time tracking this down, but I thought I'd
> > throw
> > > that out there in case it rings some bells.
> > >
> > > As an experiment, I modified checkNewChannel so that it wouldn't
> > reject
> > > a channel with an napid of 0, and lo and behold, I got a channel
> > list
> > > from the scan.  The video pids are correct, but no audio pids are
> > set,
> > > so as you might guess, I get video but no sound.  I edited a few
> of
> > the
> > > channels, and added the audio pids I got from the scandvb, and
> they
> > > worked.. video and audio.
> > >
> > > Thanks for reading this.  I'd be glad to try any suggested
> > experiments.
> >
> > Good catch. So there is a bug in SI parser, that we have to fix.
> > And since you offer to help, i would suggest to get "dvbsnoop"
> > (dvbsnoop.sf.net), a cli SI parser. When you get it, we will try to
> > meat on
> > either #kaffeine or #linuxtv.
> >
> > --
> > Christophe Thommeret
> >
> >
>
>
>
>      
>

____________________________________________________________________________________
> Be a better friend, newshound, and
> know-it-all with Yahoo! Mobile.  Try it now.
> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 
>
>



      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Kaffeine-devel mailing list
Kaffeine-devel@...
https://lists.sourceforge.net/lists/listinfo/kaffeine-devel

Le mardi 05 février 2008 03:44, Corey Ashford a écrit :
> Quick follow up on this:
>
> I haven't fixed Kaffeine yet, but I did run dvbsnoop on the multiplex,
> and saw similar things as what I saw with my extra fprintfs, that there
> are some private data pids, types 5 & 6, that go with each channel.

Could you post dvbsnoop output for such a PMT ?

> I plan, sometime soon, to look at the source to scandvb to see if I can
> figure out why it is treating those as audio channels.  scandvb is
> right that those pids are actually audio, but I'm wondering how it
> knows that.  Maybe it looks deeper into the individual pid stream and
> figures it out by looking at the headers?  Or maybe it just guesses
> based on the fact that there aren't any other pids for audio, and
> therefore these two must be it?


--
Christophe Thommeret


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Kaffeine-devel mailing list
Kaffeine-devel@...
https://lists.sourceforge.net/lists/listinfo/kaffeine-devel

[Corey Ashford-2]

Sorry for the delay in posting this.  Been busy the last few days.

Here's a dvbsnoop of a couole of the PMTs in the multiplex:

dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/ 

------------------------------------------------------------
SECT-Packet: 00000001   PID: 176 (0x00b0), Length: 90 (0x005a)
Time received: Sat 2008-02-09  22:15:49.342
------------------------------------------------------------
  0000:  02 b0 57 00 0b c5 00 00  e0 b1 f0 0e 05 04 47 41  
..W...........GA
  0010:  39 34 10 06 c0 bd 61 c0  08 00 02 e0 b1 f0 03 06  
94....a.........
  0020:  01 02 81 e0 b4 f0 15 81  07 00 00 00 00 00 1f 00  
................
  0030:  0a 04 65 6e 67 00 05 04  41 43 2d 33 81 e0 b5 f0  
..eng...AC-3....
  0040:  15 81 07 00 00 00 00 00  1f 00 0a 04 73 70 61 00  
............spa.
  0050:  05 04 41 43 2d 33 cd 15  b4 12                     ..AC-3....

PID:  176 (0x00b0)

Guess table from table id...
PMT-decoding....
Table_ID: 2 (0x02)  [= Program Map Table (PMT)]
section_syntax_indicator: 1 (0x01)
(fixed '0'): 0 (0x00)
reserved_1: 3 (0x03)
Section_length: 87 (0x0057)
Program_number: 11 (0x000b)
reserved_2: 3 (0x03)
Version_number: 2 (0x02)
current_next_indicator: 1 (0x01)  [= valid now]
Section_number: 0 (0x00)
Last_Section_number: 0 (0x00)
reserved_3: 7 (0x07)
PCR PID: 177 (0x00b1)
reserved_4: 15 (0x0f)
Program_info_length: 14 (0x000e)

        MPEG-DescriptorTag: 5 (0x05)  [= registration_descriptor]
        descriptor_length: 4 (0x04)
        format_identifier: 1195456820 (0x47413934)  [= see: SC29]
            GA94

        MPEG-DescriptorTag: 16 (0x10)  [= smoothing_buffer_descriptor]
        descriptor_length: 6 (0x06)
        reserved_1: 3 (0x03)
        sb_leak_rate: 48481  (= 121 bits/sec)
        reserved_2: 3 (0x03)
        sb_size: 2048  bytes

Stream_type loop:

    Stream_type: 2 (0x02)  [= ITU-T Rec. H.262 | ISO/IEC 13818-2 Video
| ISO/IEC 11172-2 constr. parameter video stream]
    reserved_1: 7 (0x07)
    Elementary_PID: 177 (0x00b1)
    reserved_2: 15 (0x0f)
    ES_info_length: 3 (0x0003)

            MPEG-DescriptorTag: 6 (0x06)  [=
data_stream_alignment_descriptor]
            descriptor_length: 1 (0x01)
            alignment_type: 2 (0x02)
               as VideoStream:  (= video access unit)   as AudioStream:
 (= reserved)


    Stream_type: 129 (0x81)  [= User private]
    reserved_1: 7 (0x07)
    Elementary_PID: 180 (0x00b4)
    reserved_2: 15 (0x0f)
    ES_info_length: 21 (0x0015)

            DVB-DescriptorTag: 129 (0x81)  [= User defined/ATSC
reserved]
            descriptor_length: 7 (0x07)
            Descriptor-data:
                 0000:  00 00 00 00 00 1f 00                          
   .......

            MPEG-DescriptorTag: 10 (0x0a)  [=
ISO_639_language_descriptor]
            descriptor_length: 4 (0x04)
               ISO639_language_code:  eng
               Audio_type: 0 (0x00)  [= undefined]


            MPEG-DescriptorTag: 5 (0x05)  [= registration_descriptor]
            descriptor_length: 4 (0x04)
            format_identifier: 1094921523 (0x41432d33)  [= see: SC29]
               AC-3


    Stream_type: 129 (0x81)  [= User private]
    reserved_1: 7 (0x07)
    Elementary_PID: 181 (0x00b5)
    reserved_2: 15 (0x0f)
    ES_info_length: 21 (0x0015)

            DVB-DescriptorTag: 129 (0x81)  [= User defined/ATSC
reserved]
            descriptor_length: 7 (0x07)
            Descriptor-data:
                 0000:  00 00 00 00 00 1f 00                          
   .......

            MPEG-DescriptorTag: 10 (0x0a)  [=
ISO_639_language_descriptor]
            descriptor_length: 4 (0x04)
               ISO639_language_code:  spa
               Audio_type: 0 (0x00)  [= undefined]


            MPEG-DescriptorTag: 5 (0x05)  [= registration_descriptor]
            descriptor_length: 4 (0x04)
            format_identifier: 1094921523 (0x41432d33)  [= see: SC29]
               AC-3

CRC: 3440751634 (0xcd15b412)
==========================================================
dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/ 

------------------------------------------------------------
SECT-Packet: 00000001   PID: 256 (0x0100), Length: 72 (0x0048)
Time received: Sat 2008-02-09  22:45:58.146
------------------------------------------------------------
  0000:  02 b0 45 00 10 c1 00 00  e1 01 f0 0e 05 04 47 41  
..E...........GA
  0010:  39 34 10 06 c0 bd 61 c0  08 00 02 e1 01 f0 03 06  
94....a.........
  0020:  01 02 81 e1 04 f0 0c 0a  04 65 6e 67 00 05 04 41  
.........eng...A
  0030:  43 2d 33 81 e1 05 f0 0c  0a 04 73 70 61 00 05 04  
C-3.......spa...
  0040:  41 43 2d 33 c0 89 45 b3                            AC-3..E.

PID:  256 (0x0100)

Guess table from table id...
PMT-decoding....
Table_ID: 2 (0x02)  [= Program Map Table (PMT)]
section_syntax_indicator: 1 (0x01)
(fixed '0'): 0 (0x00)
reserved_1: 3 (0x03)
Section_length: 69 (0x0045)
Program_number: 16 (0x0010)
reserved_2: 3 (0x03)
Version_number: 0 (0x00)
current_next_indicator: 1 (0x01)  [= valid now]
Section_number: 0 (0x00)
Last_Section_number: 0 (0x00)
reserved_3: 7 (0x07)
PCR PID: 257 (0x0101)
reserved_4: 15 (0x0f)
Program_info_length: 14 (0x000e)

        MPEG-DescriptorTag: 5 (0x05)  [= registration_descriptor]
        descriptor_length: 4 (0x04)
        format_identifier: 1195456820 (0x47413934)  [= see: SC29]
            GA94

        MPEG-DescriptorTag: 16 (0x10)  [= smoothing_buffer_descriptor]
        descriptor_length: 6 (0x06)
        reserved_1: 3 (0x03)
        sb_leak_rate: 48481  (= 121 bits/sec)
        reserved_2: 3 (0x03)
        sb_size: 2048  bytes

Stream_type loop:

    Stream_type: 2 (0x02)  [= ITU-T Rec. H.262 | ISO/IEC 13818-2 Video
| ISO/IEC 11172-2 constr. parameter video stream]
    reserved_1: 7 (0x07)
    Elementary_PID: 257 (0x0101)
    reserved_2: 15 (0x0f)
    ES_info_length: 3 (0x0003)

            MPEG-DescriptorTag: 6 (0x06)  [=
data_stream_alignment_descriptor]
            descriptor_length: 1 (0x01)
            alignment_type: 2 (0x02)
               as VideoStream:  (= video access unit)   as AudioStream:
 (= reserved)


    Stream_type: 129 (0x81)  [= User private]
    reserved_1: 7 (0x07)
    Elementary_PID: 260 (0x0104)
    reserved_2: 15 (0x0f)
    ES_info_length: 12 (0x000c)

            MPEG-DescriptorTag: 10 (0x0a)  [=
ISO_639_language_descriptor]
            descriptor_length: 4 (0x04)
               ISO639_language_code:  eng
               Audio_type: 0 (0x00)  [= undefined]


            MPEG-DescriptorTag: 5 (0x05)  [= registration_descriptor]
            descriptor_length: 4 (0x04)
            format_identifier: 1094921523 (0x41432d33)  [= see: SC29]
               AC-3


    Stream_type: 129 (0x81)  [= User private]
    reserved_1: 7 (0x07)
    Elementary_PID: 261 (0x0105)
    reserved_2: 15 (0x0f)
    ES_info_length: 12 (0x000c)

            MPEG-DescriptorTag: 10 (0x0a)  [=
ISO_639_language_descriptor]
            descriptor_length: 4 (0x04)
               ISO639_language_code:  spa
               Audio_type: 0 (0x00)  [= undefined]


            MPEG-DescriptorTag: 5 (0x05)  [= registration_descriptor]
            descriptor_length: 4 (0x04)
            format_identifier: 1094921523 (0x41432d33)  [= see: SC29]
               AC-3

CRC: 3230221747 (0xc08945b3)
==========================================================


--- Christophe Thommeret <hftom@...> wrote:

> Le mardi 05 février 2008 03:44, Corey Ashford a écrit :
> > Quick follow up on this:
> >
> > I haven't fixed Kaffeine yet, but I did run dvbsnoop on the
> multiplex,
> > and saw similar things as what I saw with my extra fprintfs, that
> there
> > are some private data pids, types 5 & 6, that go with each channel.
>
> Could you post dvbsnoop output for such a PMT ?
>
> > I plan, sometime soon, to look at the source to scandvb to see if I
> can
> > figure out why it is treating those as audio channels.  scandvb is
> > right that those pids are actually audio, but I'm wondering how it
> > knows that.  Maybe it looks deeper into the individual pid stream
> and
> > figures it out by looking at the headers?  Or maybe it just guesses
> > based on the fact that there aren't any other pids for audio, and
> > therefore these two must be it?
>
>
> --
> Christophe Thommeret
>
>

      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page.
http://www.yahoo.com/r/hs

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Kaffeine-devel mailing list
Kaffeine-devel@...
https://lists.sourceforge.net/lists/listinfo/kaffeine-devel

Hi,

I have a fix for this - so the next release (which is quite far away) will not
suffer from this problem anymore ...

Meanwhile you can apply the attached patch (to src/input/dvb/dvbsi.cpp).

@hftom: the issue here is that ATSC (and not DVB) stream types are used for
audio - it's the first time i see that on a sat :)

Christoph


Am Sonntag 10 Februar 2008 schrieb Corey Ashford:

> Sorry for the delay in posting this.  Been busy the last few days.
>
> Here's a dvbsnoop of a couole of the PMTs in the multiplex:
>
> dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/
>
> ------------------------------------------------------------
> SECT-Packet: 00000001   PID: 176 (0x00b0), Length: 90 (0x005a)
> Time received: Sat 2008-02-09  22:15:49.342
> ------------------------------------------------------------
>   0000:  02 b0 57 00 0b c5 00 00  e0 b1 f0 0e 05 04 47 41
> ..W...........GA
>   0010:  39 34 10 06 c0 bd 61 c0  08 00 02 e0 b1 f0 03 06
> 94....a.........
>   0020:  01 02 81 e0 b4 f0 15 81  07 00 00 00 00 00 1f 00
> ................
>   0030:  0a 04 65 6e 67 00 05 04  41 43 2d 33 81 e0 b5 f0
> ..eng...AC-3....
>   0040:  15 81 07 00 00 00 00 00  1f 00 0a 04 73 70 61 00
> ............spa.
>   0050:  05 04 41 43 2d 33 cd 15  b4 12                     ..AC-3....
>
> PID:  176 (0x00b0)
>
> Guess table from table id...
> PMT-decoding....
> Table_ID: 2 (0x02)  [= Program Map Table (PMT)]
> section_syntax_indicator: 1 (0x01)
> (fixed '0'): 0 (0x00)
> reserved_1: 3 (0x03)
> Section_length: 87 (0x0057)
> Program_number: 11 (0x000b)
> reserved_2: 3 (0x03)
> Version_number: 2 (0x02)
> current_next_indicator: 1 (0x01)  [= valid now]
> Section_number: 0 (0x00)
> Last_Section_number: 0 (0x00)
> reserved_3: 7 (0x07)
> PCR PID: 177 (0x00b1)
> reserved_4: 15 (0x0f)
> Program_info_length: 14 (0x000e)
>
>         MPEG-DescriptorTag: 5 (0x05)  [= registration_descriptor]
>         descriptor_length: 4 (0x04)
>         format_identifier: 1195456820 (0x47413934)  [= see: SC29]
>             GA94
>
>         MPEG-DescriptorTag: 16 (0x10)  [= smoothing_buffer_descriptor]
>         descriptor_length: 6 (0x06)
>         reserved_1: 3 (0x03)
>         sb_leak_rate: 48481  (= 121 bits/sec)
>         reserved_2: 3 (0x03)
>         sb_size: 2048  bytes
>
> Stream_type loop:
>
>     Stream_type: 2 (0x02)  [= ITU-T Rec. H.262 | ISO/IEC 13818-2 Video
>
> | ISO/IEC 11172-2 constr. parameter video stream]
>
>     reserved_1: 7 (0x07)
>     Elementary_PID: 177 (0x00b1)
>     reserved_2: 15 (0x0f)
>     ES_info_length: 3 (0x0003)
>
>             MPEG-DescriptorTag: 6 (0x06)  [=
> data_stream_alignment_descriptor]
>             descriptor_length: 1 (0x01)
>             alignment_type: 2 (0x02)
>                as VideoStream:  (= video access unit)   as AudioStream:
>  (= reserved)
>
>
>     Stream_type: 129 (0x81)  [= User private]
>     reserved_1: 7 (0x07)
>     Elementary_PID: 180 (0x00b4)
>     reserved_2: 15 (0x0f)
>     ES_info_length: 21 (0x0015)
>
>             DVB-DescriptorTag: 129 (0x81)  [= User defined/ATSC
> reserved]
>             descriptor_length: 7 (0x07)
>             Descriptor-data:
>                  0000:  00 00 00 00 00 1f 00
>    .......
>
>             MPEG-DescriptorTag: 10 (0x0a)  [=
> ISO_639_language_descriptor]
>             descriptor_length: 4 (0x04)
>                ISO639_language_code:  eng
>                Audio_type: 0 (0x00)  [= undefined]
>
>
>             MPEG-DescriptorTag: 5 (0x05)  [= registration_descriptor]
>             descriptor_length: 4 (0x04)
>             format_identifier: 1094921523 (0x41432d33)  [= see: SC29]
>                AC-3
>
>
>     Stream_type: 129 (0x81)  [= User private]
>     reserved_1: 7 (0x07)
>     Elementary_PID: 181 (0x00b5)
>     reserved_2: 15 (0x0f)
>     ES_info_length: 21 (0x0015)
>
>             DVB-DescriptorTag: 129 (0x81)  [= User defined/ATSC
> reserved]
>             descriptor_length: 7 (0x07)
>             Descriptor-data:
>                  0000:  00 00 00 00 00 1f 00
>    .......
>
>             MPEG-DescriptorTag: 10 (0x0a)  [=
> ISO_639_language_descriptor]
>             descriptor_length: 4 (0x04)
>                ISO639_language_code:  spa
>                Audio_type: 0 (0x00)  [= undefined]
>
>
>             MPEG-DescriptorTag: 5 (0x05)  [= registration_descriptor]
>             descriptor_length: 4 (0x04)
>             format_identifier: 1094921523 (0x41432d33)  [= see: SC29]
>                AC-3
>
> CRC: 3440751634 (0xcd15b412)
> ==========================================================
> dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/
>
> ------------------------------------------------------------
> SECT-Packet: 00000001   PID: 256 (0x0100), Length: 72 (0x0048)
> Time received: Sat 2008-02-09  22:45:58.146
> ------------------------------------------------------------
>   0000:  02 b0 45 00 10 c1 00 00  e1 01 f0 0e 05 04 47 41
> ..E...........GA
>   0010:  39 34 10 06 c0 bd 61 c0  08 00 02 e1 01 f0 03 06
> 94....a.........
>   0020:  01 02 81 e1 04 f0 0c 0a  04 65 6e 67 00 05 04 41
> .........eng...A
>   0030:  43 2d 33 81 e1 05 f0 0c  0a 04 73 70 61 00 05 04
> C-3.......spa...
>   0040:  41 43 2d 33 c0 89 45 b3                            AC-3..E.
>
> PID:  256 (0x0100)
>
> Guess table from table id...
> PMT-decoding....
> Table_ID: 2 (0x02)  [= Program Map Table (PMT)]
> section_syntax_indicator: 1 (0x01)
> (fixed '0'): 0 (0x00)
> reserved_1: 3 (0x03)
> Section_length: 69 (0x0045)
> Program_number: 16 (0x0010)
> reserved_2: 3 (0x03)
> Version_number: 0 (0x00)
> current_next_indicator: 1 (0x01)  [= valid now]
> Section_number: 0 (0x00)
> Last_Section_number: 0 (0x00)
> reserved_3: 7 (0x07)
> PCR PID: 257 (0x0101)
> reserved_4: 15 (0x0f)
> Program_info_length: 14 (0x000e)
>
>         MPEG-DescriptorTag: 5 (0x05)  [= registration_descriptor]
>         descriptor_length: 4 (0x04)
>         format_identifier: 1195456820 (0x47413934)  [= see: SC29]
>             GA94
>
>         MPEG-DescriptorTag: 16 (0x10)  [= smoothing_buffer_descriptor]
>         descriptor_length: 6 (0x06)
>         reserved_1: 3 (0x03)
>         sb_leak_rate: 48481  (= 121 bits/sec)
>         reserved_2: 3 (0x03)
>         sb_size: 2048  bytes
>
> Stream_type loop:
>
>     Stream_type: 2 (0x02)  [= ITU-T Rec. H.262 | ISO/IEC 13818-2 Video
>
> | ISO/IEC 11172-2 constr. parameter video stream]
>
>     reserved_1: 7 (0x07)
>     Elementary_PID: 257 (0x0101)
>     reserved_2: 15 (0x0f)
>     ES_info_length: 3 (0x0003)
>
>             MPEG-DescriptorTag: 6 (0x06)  [=
> data_stream_alignment_descriptor]
>             descriptor_length: 1 (0x01)
>             alignment_type: 2 (0x02)
>                as VideoStream:  (= video access unit)   as AudioStream:
>  (= reserved)
>
>
>     Stream_type: 129 (0x81)  [= User private]
>     reserved_1: 7 (0x07)
>     Elementary_PID: 260 (0x0104)
>     reserved_2: 15 (0x0f)
>     ES_info_length: 12 (0x000c)
>
>             MPEG-DescriptorTag: 10 (0x0a)  [=
> ISO_639_language_descriptor]
>             descriptor_length: 4 (0x04)
>                ISO639_language_code:  eng
>                Audio_type: 0 (0x00)  [= undefined]
>
>
>             MPEG-DescriptorTag: 5 (0x05)  [= registration_descriptor]
>             descriptor_length: 4 (0x04)
>             format_identifier: 1094921523 (0x41432d33)  [= see: SC29]
>                AC-3
>
>
>     Stream_type: 129 (0x81)  [= User private]
>     reserved_1: 7 (0x07)
>     Elementary_PID: 261 (0x0105)
>     reserved_2: 15 (0x0f)
>     ES_info_length: 12 (0x000c)
>
>             MPEG-DescriptorTag: 10 (0x0a)  [=
> ISO_639_language_descriptor]
>             descriptor_length: 4 (0x04)
>                ISO639_language_code:  spa
>                Audio_type: 0 (0x00)  [= undefined]
>
>
>             MPEG-DescriptorTag: 5 (0x05)  [= registration_descriptor]
>             descriptor_length: 4 (0x04)
>             format_identifier: 1094921523 (0x41432d33)  [= see: SC29]
>                AC-3
>
> CRC: 3230221747 (0xc08945b3)
> ==========================================================
>
> --- Christophe Thommeret <hftom@...> wrote:
> > Le mardi 05 février 2008 03:44, Corey Ashford a écrit :
> > > Quick follow up on this:
> > >
> > > I haven't fixed Kaffeine yet, but I did run dvbsnoop on the
> >
> > multiplex,
> >
> > > and saw similar things as what I saw with my extra fprintfs, that
> >
> > there
> >
> > > are some private data pids, types 5 & 6, that go with each channel.
> >
> > Could you post dvbsnoop output for such a PMT ?
> >
> > > I plan, sometime soon, to look at the source to scandvb to see if I
> >
> > can
> >
> > > figure out why it is treating those as audio channels.  scandvb is
> > > right that those pids are actually audio, but I'm wondering how it
> > > knows that.  Maybe it looks deeper into the individual pid stream
> >
> > and
> >
> > > figures it out by looking at the headers?  Or maybe it just guesses
> > > based on the fact that there aren't any other pids for audio, and
> > > therefore these two must be it?
> >
> > --
> > Christophe Thommeret

[patch.diff]

---

--- dvbsi.cpp_orig 2008-03-24 12:03:10.000000000 +0100
+++ dvbsi.cpp 2008-03-24 12:03:42.000000000 +0100
@@ -466,6 +466,10 @@ bool DVBsi::tablePMT( unsigned char* buf
  if ( type==3 || type==4 ) {
  audio = true;
  }
+ if (type == 0x81) {
+ audio = true;
+ ac3 = true;
+ }
  loop = getBits(buf,28,12);
  buf +=5;
  length -=(5+loop);

---

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Kaffeine-devel mailing list
Kaffeine-devel@...
https://lists.sourceforge.net/lists/listinfo/kaffeine-devel