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

RE: PIDs vs flow IDs

Hi Marie-Jose
 
A few quickies...
 
On the INT:
 
INT does not announce the PID, but a set of identifiers which then may be used to find the PID.
INT announces network_id, original_network_id, transport_stream_id, service_id and component_tag.
  • Network_id identifies the DVB network.
  • Original_network_id and transport_stream_id together identify the transport stream (globally, not only within the network. i.e. the network_id is not actually needed, but it's there anyway).
  • service_id identifies the PMT sub-table within the transport stream.
  • component_tag identifies the component within the PMT sub-table. PMT announces PID for each component.
On the Table/PID Change requirements:
 
When a MUX changes (re-marks) PIDs, it only has to update the PMT (where PIDs are announced).
MUX does not need to (and it does not) update the INT, as INT does not announce PID.
MUX only changes (re-marks) PIDs, and updates the PMT accordingly.
If INT table is properly used (i.e. PIDs are not fixed, but announced using INT and PMT), MUX may change (re-mark) PIDs at will, and it causes no problems for data-transmission.
 
On the need:
 
For mostly IP backbone (e.g. IP encapsulated close to transmission) it's unlikely that PID change would be necessary. However, many DVB deployments do have multiple MUXes, especially in the satellite case so I guess this design constraint is totally unavoidable. INT took account of the need for remux PID change and for this reason it uses component_tag which is persistent even with PID change - so it should work pretty smoothly.
 
Cheers, Rod.
 
 
-----Original Message-----
From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On Behalf Of ext Marie-Jose Montpetit
Sent: Friday, November 21, 2003 12:47 PM
To: ip-dvb@erg.abdn.ac.uk
Subject: PIDs vs flow IDs

I'm working on a new version of the AR draft and something has come up: how PIDs are not really flow IDs and can change. As far as I know in broadcast TV networks when you use INT with PID, a (re)MUX may re-mark the PID, and then could remark the
INT. This is a standard MUX function. However in a data network I think it is assumed that PIDs are to be used end-to-end (as unidirectional flows), and Muxes should not re-mark. If that is the case it's ok. If it's not the case then we may have to find a way to easily identify flows and map them appropriately.
 
Marie-Jose