Le quartidi 14 germinal, an CCXXV, Timothy Lee a écrit : > Thanks for your quick reply. Regarding the almost direct copy of code from > cache.c, I previously submitted a patch on 31 March that adds a "cache_file" > option to the cache protocol. It was intended to allow a specifically named > cache file to serve as a dump of the input stream. > > Michael Niedermayer explained that his intention was to maintain a caching > system that was more consistent with how a browser's cache works, and my > changes to the cache protocol was not appropriate. > > Hence my attempt to duplicate the code from cache.c and use it for the > capture protocol.
I see. IMHO, there are two options here: either implement the feature you want within cache.c while respecting Michael's intents or implement a protocol that does only capture, no caching at all. If you go the first way, then you need to discuss the solution with Michael (but on the mailing-list) to find a way that suits you both. It is probably the best option. If you go the second way, then I think you must remove from your patch all that is related to caching, i.e. re-reading from the capture file. The capture file becomes just a copy of the octets read from the underlying protocol. In particular, if you do not need seeking, I strongly suggest to remove it; otherwise, you would need an auxiliary map file to report valid ranges. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
