On Sun, Dec 27, 2015 at 4:42 AM, Mats Peterson <matsp888-at-yahoo....@ffmpeg.org> wrote: > On 12/27/2015 03:57 AM, Mats Peterson wrote: >> >> On 12/27/2015 03:03 AM, Michael Niedermayer wrote: >>>> >>>> + >>>> + if (!(stsd = av_malloc(70))) >>>> + return AVERROR(ENOMEM); >>> >>> >>> the malloc is unneeded, an array on the stack could be used (its just >>> a fixed 70 bytes) >>> this would also simplify the error handling >> >> >> Yes, I thought so. I tried to be "a good boy", but that was obviously to >> no avail ;) >> >>>> +int ff_get_qtpalette(int codec_id, uint8_t *stsd, AVIOContext *pb, >>>> + uint32_t *palette); >>>> + >>> >>> >>> missing doxy documentation, missing "const" for unchanged arrays >>> also why does this need a "byte" array and a AVIOContext as input >>> arguments ? >>> iam asking as this looks a bit confusing with 2 inputs ... >> >> >> Regarding doxy documentation, I notice several files in libavformat are >> lacking doxy documentation (if what you mean by "doxy documentation" is >> a comment beginning with /**). I don't know what to put it in either, at >> that. Please help me out. >> >> And regarding two inputs, well, the problem is that matroskadec.c has >> the video sample description stored in its in-memory private data, while >> mov.c reads the video sample description from the file. I don't want to >> mess too much with the logic in mov.c, that's why I provide both a >> "memory" and a "file" input. Confusing, yes, slightly, but necessary as >> long as you want a common function to be called from both sources. If >> anyone else manages to come up with something better WITHOUT BREAKING >> IT, no problem. It does take some knowledge about the structure of a >> QuickTime video sample description. >> >> Mats >> >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > Actually I would prefer that nobody touches what I've been doing, since it > works just fine right now, and it can be easily broken if you start trying > to "improve it". Belive me, I've tried. >
And we would prefer if code is actually clean and not a convoluted mess, and if you don't want us improving it, and you don't want to do it yourself, then thats too bad. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel