Reinhard Nissl schrieb: > Hi, > > Martin Wache wrote: > >>>> Is there a reason why the cAudioRepacker is used in transfer mode and >>>> during recordings, but not while replaying? >>> Well, when cAudioRepacker was active while recording, then there is no >>> need for it when replaying such a recording. >> Wouldn't it make more sense to use the repacker only when replaying and >> in transfer mode and not while recording? >> Like it is now, it is possible that the device gets either repacked >> audio frames (transfer mode and new recordings) or not repacked frames. >> If the device needs repacked frames the device has to find out if it is >> replaying an old recording to play and if so, split the packets. I guess >> in most cases it is a lot simpler just to repack everything. Which means >> in most cases to do the repacking twice... > > Fiddling around with repacking at that late stage is quite a mess > especially in trickspeed mode. You have to do it anyway when parsing the content of the packets to decode them. And you can do it even better, because you know what should be inside. I never had any problem implementing trickspeed modes for the softdevice, also when there was no repacker in the vdr. FFmpeg does a good job parsing those packets, and I guess ffmpeg is much better tested and faster than cAudio/VideoRepacker. > And cVideoRepacker causes "high" CPU load > because there is no length information in the video stream so the whole > stream has to be scanned for the 00 00 01 pattern. Furthermore, consider > the memcpying involved in this process. In my opinion that is a reason not to do the repacking at in the vdr. > That's why we have chosen the > earliest stage possible (cRemux) to do this complex stuff just once. > No, as I said earlier, you don't guarantee that the repacking is done, so one have to check that the packet are fine in any case. And checking them is not more work than completely parsing the packets. So in fact because the repacking is only done sometimes one hast to do the work twice. And during the decoding one has to parse the packets anyway, so it is much simpler _only_ to parse them properly in the decoder. >>> And old recordings will vanish as time passes by. >> I don't buy this argument. I know that there are VDR users with large >> archives of recordings, do you want to tell them that they can't use >> them any more? > > No, I don't, as there is no need to. VDR's device interface > specification doesn't state any relationship between PES packets and > their content, so a device implementation shouldn't rely on that. > So you are saying that we have to repack in any case... which means that the packets are completely parsed twice. Didn't you say something about "high cpu load" and "complex stuff" above? For soft devices that actually should not matter too much, because of the strong cpus, but the people who suffer are the ones which are using hardware decoders and weak cpus. And as far as I know they don't need repacking... >> But anyway, actually I think the best would be only to repack audio and >> video if the replaying device needs it. As far as I know FF cards don't >> need it, the softdevice doesn't need it (ok, it depends on the ffmpeg >> version one uses, but the patch I send fixes this). >> So why not let the device choose if repacking is needed or not? It >> should now if repacking is needed, and in most cases it should be able >> to do it by itself. > > Well, it isn't just a matter of the output device. cVideoRepacker takes > care that VDR's index file contains valid entries. Before > cVideoRepacker, the index file could address incomplete frames or even > miss some frames. > I agree that it is cleaner to have an index file which points to complete frames, but I never experienced any problems without repacking. I switched the repacking of in my vdr... I don't think that it is necessary. Bye, Martin
