Opened 13 years ago
Closed 13 years ago
#552 closed enhancement (fixed)
warning flags needed for av_open_input_file
Reported by: | DonMoir | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avformat |
Version: | git-master | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | yes | |
Analyzed by developer: | no |
Description
When you open a video, warnings are sent to stdout. This does you no good if you need to check these warnings. This needs to be tied into AVFormatContext so it is instance driven and not some global setting.
The main case I am looking at now is in asfdec.c and asf_read_header. There are test for DRM Protected etc and message 'decoding will likely fail'. I would like to know about these warnings after I do an open. I have multiples instances of code that can call av_open_input_file from various threads.
Looks like the only thing I can do now is trap log messages which are global which would mean I have to block on av_open_input_file so that I know I am dealing with the right instance. Then do something silly like look at strings from the log callback. If you have another work around let me know.
There are probably other cases where other warnings might be useful as well. Not sure where you would fit these flags in, but ideally as part of the AVFormatContext structure.
Change History (5)
comment:1 by , 13 years ago
Reproduced by developer: | set |
---|---|
Status: | new → open |
Version: | unspecified → git-master |
comment:2 by , 13 years ago
Not sure if it's a matter of a simple flag. It's seems to be more of a matter where to put it. I did take a quick look at things. Is there a place for such flags in AVFormatContext without changing structure ? Or is a slight structure change appropriate ?
Also could be there are additional cases that would be good that I am just not aware of. Getting basic structure is place would be a start though.
comment:3 by , 13 years ago
Is adding an AVFMT_FLAG not enough?
#define AVFMT_FLAG_ENCRYPTED 0x80000 ///<Stream is likely encrypted, decoding will probably fail if no key is provided.
(I don't know if they are meant "user-supplied only", but the documentation doesn't mention it.)
comment:4 by , 13 years ago
Yeah wasn't sure about the flags on who sets what, but that seems perfect.
I suppose I use this email ffmpeg-devel@ffmpeg.org and will send.
comment:5 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | open → closed |
This has apparently been implemented differently.
I suggest you add such a flag and send it to ffmpeg-devel.