Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] ARM or what ?



=?iso-8859-1?Q?Jean=2DFran=E7ois?= GOBBERS writes:
 > I would like to get some explanations about the code loaded into the ARM
 > on Siemens-Fujitsu DVB-S cards.
 > 
 > Basically, while experimenting with such a card, I observed the
 > following results : when feeding the card with a TS containing only 1
 > ES, which is of stream_id 0xBF (private_stream_2), the demultiplexer
 > seems to get confused when the payload of this ES is another TS (i.e.
 > when I encapsulate a TS into an ES in another TS using the Asynchronous
 > Data Stream profile). Graphically, what I'm doing is :
 > 
 > --------------------------         --------------------------
 > |Audio stream |          |         |             |          |
 > |   PID 17    |          | payload |             |          |
 > |-------------|          |   of    | Async Data  |          |
 > |Video stream | inner-TS |  ---->  |   Stream    |          |
 > |   PID 18    |          |         |   PID 33    | outer-TS |
 > |-------------|          |         |             |          |
 > |PAT, PMT, ...|          |         |             |          |
 > --------------------------         |-------------|          |
 >                                    |PAT, PMT, ...|          |
 >                                    --------------------------
 > 
 > When setting up a PES filter on PID 33 and feeding the `outer-TS' into
 > the card, I get a mix-up of TS packets, some of them are the ones
 > corresponding to the data stream, but others appear magically, whose
 > payload is coming from the video stream in the inner-TS; additionally,
 > adaptation fields (containing only stuffing bytes) appear on PID 33 (in
 > the async data stream), altough none were inserted when generating this
 > outer-TS...
 > 
 > JF
 > 
 > 
 > PS : driver version is 0.8 & 0.8.1 (same results), and the `dvb' module
 > is insmoded with `outstream=3 napi=1 init_chan=1' ().
 > PS2 : I suspect a problem during synchronization on 0x47 chars... (lots
 > of them in the __payload__ of the outer-TS, all coming from the
 > inner-TS!)
 > 

Well, I explained many times before what the Siemens card can and
cannot do and what we had to do in software, etc.
The card cannot deliver transport streams. Any TS the drivers delivers
is simulated/recontructed from the PES filters provided in the ARM
firmware. I guess you can get the converters to brake with the kind of
exotic data you are sending.

If complete documentation of the hardware were available one could
probably get the card to do some more things (not to mention a Linux
port). A disassembly of the firmware ROM (not the "firmware"=ARM 
application which gets loaded on the card) is very revealing and 
interesting in this regard but hard to understand without complete 
register description.


Ralph


--- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.



Home | Main Index | Thread Index