Andreas Rheinhardt (12021-08-14): > I do not really get that: The option passing syntax is restricted to the > subfile protocol, so I don't know why we allow it for the file protocol > in dashdec and hls. Unless I am missing something, this could (and > should) be removed at once.
It must be leftover code from when it was supported for all protocols. Not requiring this kind of convoluted tests in new code is also a motivation for just removing the last trace of this feature. > I use it to concatenate parts of files: When a DVR of mine has to split > files due to the 4GB FAT-32 boundary, it does not do so cleanly; for > some reason the first 96256B of the second file are duplicated, i.e. > they coincide with bytes 96256-192511. For the third file, about a MB > starting from offset 96256 is duplicated. Makes sense. I think we should decide that protocols like concat and subfile, protocols where part(s) of the pseudo-URI are themselves pseudo-URI with other protocols (let us call them metaprotocols) should always involve a solution to pass options to the sub-protocols. Possibly, let us make this a common helper API. concat:file01.bin|[start=96256]subfile:file02.bin Anyway, I think I can push the series except for the last patch now. Any objection? Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
