[dvblast-devel] 6 patches for DVBlast

[Christophe Massiot]

Hello,

> On 27 Mar 2015, at 22:52, Contact (COEXSI) <contact at coexsi.fr> wrote:
> 
> 1: Prevent a warning from compiler for unknown delivery type with DVB API
> version 5 (case not handled)

Applied.

> 2: Add a timeout for sending and receiving to prevent dvblastctl to be
> blocked in case of communication error

I am not sure why you need that, can you provide a scenario ?

> 3: This one is really strange, as the RTP timestamp originally calculated
> may perturb some receivers RTP input buffer management as the counter can be
> too volatile for some highly variable bandwidth streams. So, it's better to
> use a local timestamp.

Although I am personally in favour of using a local timestamp for RTP timestamp (and I have done so in Upipe), this is in contradiction with RFC 2250, section 2, "Each RTP packet will contain a timestamp derived from the sender's 90KHz clock reference.  This clock is synchronized to the system stream Program Clock Reference (PCR) or System Clock Reference (SCR) and represents the target transmission time of the first byte of the packet payload."

However DVB-IPI states that it is not mandatory but "recommended". So does anyone object to changing the behaviour of DVBlast ?

> 4: On high bandwidth transponder, this is useful to slightly decrease the
> number of main loop to be executed per second.

... but on low bandwidth transponder, this greatly raises the time before which you get the first DMA packet containing PAT. Please make it configurable, or auto-adjusted.

> 5: There were some case when the poll timeout calculated was negative, the
> case is now handled with a minimum poll timeout value.

Applied.

> 6: Add a limit for CAM reset initiated by an output unscrambling issue.
> Also, increase the interval between the CAM reset. Sometimes, an output may
> have some unscrambling issue (wrong rights) and doing periodic CAM reset
> perturb all the other outputs.

I agree that an output should not continuously reset the CAM, and thus having a per-output counter is good. However, there should be a way for the counter to reset to 0 after a certain period without error. Otherwise a transient error will mean that this service can no longer reset the CAM until DVBlast is restarted.

Also, why did you remove i_last_reset ? If there are 5 scrambled services in the mux, you may end up resetting the CAM 5 times in a very short period of time, without letting enough time for the CAM to initialise.

Please note also that the "always on" parameter for each output (2nd parameter, usually "1") can be set to 0. If this is the case, this output will never trigger a reset of the CAM. This is useful for adult channels that are only open at night in some countries.

Regards,