Marcus Metzler wrote: > Johannes Stezenbach writes: > > > Currently the API makes no guarantee on data alignment when you read() > > PES data from the demux. For sections, it is guaranteed that each read() > > wil get exactly one section with the start of the section at the start > > of the buffer, provided the buffer is large enough. If the buffer is too > > small, consecutive read()s will get the remainder of the section. > > > > We could try to do the same for PES filters, or shouldn't we? > > > > There are various problems with that. > > 1) You don't know how long a video PES will be when it starts. > 2) There is no maximum size for video PES.
I don't know if that is a problem. I just want the API to guarantee that a single read() won't get the end of one PES packet and the start of the next. That way userspace won't have to scan through the whole buffer to find the start of a PES packet, it would be sufficient to check at the start of the buffer. OTOH, I'm not sure what would be required to implement this. As Andreas wrote, the payload_unit_start_indicator would be one part of the puzzle. But the driver can buffer more than one PES packet before userspace calls read(), so the driver has to remember all PES packet start positions in the buffer. > 3) The TS is usually not muxed on the PES level, at least from my > experience. I don't know what you mean by that. If we would allow a filter to output two PES streams (e.g. audio and video -> AVPES) to a common file descriptor for read(), we need separate buffers to assemble full PES packets before they can be joined in the filters output buffer. If the hardware directly supports PES filters, fine, it will then already have sperate PES buffers for each filter. Otherwise it's the driver's job. Regards, Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
