Florian Schirmer wrote:
Hi,Yes, this should be the responsibility of the demux. Just add capability ioctls there. The frontend could be rather dumb. Syncing to TS boundaries, etc. can also be handled by the demux. It will have to do that anyway for budget cards which deliver unaligned data (e.g. Bt878/fusion cards). Demux hardware usually does it by itself.
In the latest Fusion code i've pushed all the sync handling down to the
(soft) demux. It needs some tweaks here and there but it basically works.
I.e. open("/dev/.../dvrN"), then DMX_DVR_SET_PIDS(int num, int16_tpids[])?softwareYes. This should make recording all PIDs of one service very easy. A
seemsfilter implementation should also be simple. Now this kind of filter even
to fit perfectly to some hardware as Rob McConnell described in his mail.
IMHO the dvr is comletely useless. Instead of adding more and more features
to it we should remove it. At the same time we have to change the demux API
to allow more than one pid filter per fd. If it is possible to route more
than one pid into the same buffer you will basically get the functions the
dvr device provides. If we do it carefully we're able to extend the API
without loosing compatibility.
Could you please propose a rough API? A quick'n'dirty outline of the ioctls would be perfectly sufficient...
I don't like the dvr device either, I'd like much more a DMX_SET_STREAMTYPE ioctl, which could be used to specify if the stream you pass to the demux device is TS, PS, whatever...I dont know alot about hw that provides dvr units. But the hw/driver should be able to deal with that internally without forcing the user to know about wether it has dvr support or not. If there is any reason why the hw or sw requires a dvr device please elaborate why. Thx!