[multicat-devel] Issues with recording and playback

[Christophe Massiot]

Le 5 janv. 2012 à 22:12, Eduardo Vieira a écrit :

> First of all, I've made some optimizations in the disk access part.
> Now I'm using XFS file system with 4k block size, and these fstab
> options:
> 
> defaults,noatime,nodiratime,nosuid,nodev,allocsize=64m

I do not use XFS so I can't comment on this.

> I've also added this to my sysctl.conf:
> net.core.rmem_max = 16777216
> net.core.wmem_max = 16777216
> net.core.wmem_default = 16777216

That would certainly help.

> Yet the behavior I've described to you earlier continues..
> After a few days of testing I think I figured out what is happening here.
> It seems that in intervals of 30 seconds the kernel blocks on the
> write() call on the main loop while some packets arrive in the receive
> socket buffer. When this occurs, multicat is taking longer to pull out
> the packets from the socket buffer and saving the wrong timestamps in
> the aux file.
> The proof is when a remove the aux created by multicat and generate a
> new one with ingests the video plays smoothly.
> I can provide you links to download sample aux and ts files from my
> server if you want (contact me privately if so).

Is it better if you use -i 10 (as root) ?

> To work around this problem I had 2 ideias: one is to give multicat
> the possibility to stream a ts file based on the PCR present in it.

It already exists, it's called ingests and you found out already :).

> The other idea is to get the packet's timestamps based on this:
> http://lwn.net/Articles/325929/
> 
> What do you think ?

I'd love to see that because timestamping must happen as early as possible. BTW that's what we do for the ASI input of DVBlast also. However I do not know if the API you mention is stable enough, and whether it needs to be supported by the Ethernet driver. Also I do not know if it has consequences for the other processes of the same machine. Did you investigate this ?