On Sun, Jun 6, 2021 at 6:15 AM Andreas Rheinhardt <andreas.rheinha...@outlook.com> wrote: > Diederick C. Niehorster: > > See other mails: the bit of documentation in avdevice.h (lines > > 334--402) suggest the capabilities API is supposed to be used on an > > unopened device. It would make sense: probe the device for what it can > > do, decide what settings you want to use, then open device). In case > > of the dshow device, I think i cannot avoid potential false positives > > (entries in the query output that shouldn't be there) if the device is > > already opened. I'll experiment, perhaps this is only a theoretical > > worry. > > > And is the AVFormatContext that has been used for probing then supposed > to be reused for actually using the device? (You are calling > dshow_read_close() manually, but our cleanup functions typically only > clean up things that need to be freed; they e.g. don't reset (say) > ordinary ints to zero, although the code may rely upon this.)
It is not supposed to, but does work. However, as user you still need to set the device options in the opts dict passed to avformat_open_input() even after narrowing down the format you want to use through the capabilities API. I'll document this. NB: reusing the AVFormatContext currently leaks a little bit of memory as, e.g., avformat_open_input() set url without checking and freeing if its already set. And maybe more. I'll just add a patch with my proposed API extension avformat_alloc_input_context() and needed extra checks to avformat_open_input(), so we can discuss it. All the best, Dee _______________________________________________ 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".
