On 19.07.2017, at 12:03, Nicolas George <geo...@nsup.org> wrote: > What I do insist on, is this: > > Look at the find_size() function in this patch: > https://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213076.html > > Then look at the fits_read_header() in this patch: > https://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213061.html > > They are the same. One works on an AVIOContext using read operations, > the other works on a buffer using pointer arithmetic, but the logic is > the same. And it is not a trivial logic, here, we are talking about > dozens of lines of code.
Ok, I think it is possible to use the same code for those, for example by doing this: - in the demuxer (or parser, but that is harder because you cannot just read what you need but have to deal with the data as it is provided), get data until the end of the header. The end of the header detection would be somewhat duplicated, but should be fairly trivial. - Then use a function that takes such a buffer and returns a AVDictionary with name/value pairs. The decoder and demuxer can then each decide what they want to do with them. There is one issue at least though: for files with very large meta-data/header this would almost double memory usage in the demuxer due to having copies in the dictionary. There is also to me the issue, while both parse the same things, what these functions do is not at all the same semantically, at least currently. The demuxer only parses a select few keywords with well-known format and as a result can e.g, use sscanf directly (not that I like using sscanf personally). The decoder one builts a metadata dictionary and thus needs a lot of special-case handling like proper parsing, handling possibly new keywords, deciding what to do with garbage (instead of just skipping), handling escaping for the values, ... Personally if it was my job to get this in, I would start by simplifying at least one of those functions while making sure to have proper bounds checking and error handling to see where the complexity really lies and how complex the problem actually is compared to how the first try solution looks. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
