summaryrefslogtreecommitdiffstats
path: root/common/av_common.c
Commit message (Collapse)AuthorAgeFilesLines
* vd_lavc: request 1 more threads than CPU coreswm42015-03-051-0/+2
| | | | | | | | | | This duplicates the logic which FFmpeg's libavcodec uses. The effects are unknown, though it's somewhat clear that a single thread doesn't necessarily saturate a single CPU. (Eventually we should just let FFmpeg auto-init the thread count, but for now I prefer it this way, so e.g. verbose mode will print the thread count.)
* av_common: add comment about using now-deprecated libavcodec fieldwm42015-01-301-1/+2
| | | | | | | | | | FFmpeg and Libav have the stupid practice of replacing and deprecating API symbols on the same day. So with FFmpeg git, this is useless and will print a compile time warning, while it's required with all stable releases, and might lead to decoding errors with xvid/avi (apparently). Add a comment before someone writes a patch and I have to explain it all over again.
* player: use libavutil API to get number of CPUswm42015-01-051-3/+2
| | | | | | | | | | | Our own code was introduced when FFmpeg didn't provide this API (or maybe didn't even have a way to determine the CPU count). But now, av_cpu_count() is available for all FFmpeg/Libav versions we support, and there's no reason to have our own code. libavutil's code seems to be slightly more sophisticated than our's, and it's possible that the detected CPU count is different on some platforms after this change.
* player: print used number of threads in verbose modewm42015-01-051-3/+5
| | | | Also, don't use av_log() for mpv output.
* demux: always use AVPacketwm42014-08-251-0/+2
| | | | | | | | | | | | | | | | | | | | | This is a simplification, because it lets us use the AVPacket functions, instead of handling the details manually. It also allows the libavcodec rawvideo decoder to use reference counting, so it doesn't have to memcpy() the full image data. The change in av_common.c enables this. This change is somewhat risky, because we rely on the following AVPacket implementation details and assumptions: - av_packet_ref() doesn't access the input padding, and just copies the data. By the API, AVPacket is always padded, and we violate this. The lavc implementation would have to go out of its way to make this a real problem, though. - We hope that the way we make the AVPacket refcountable in av_common.c is actually supported API-usage. It's hard to tell whether it is. Of course we still use our own "old" demux_packet struct, just so that libav* API usage is somewhat isolated.
* Improve setting AVOptionswm42014-08-021-0/+36
| | | | | | | | Use OPT_KEYVALUELIST() for all places where AVOptions are directly set from mpv command line options. This allows escaping values, better diagnostics (also no more "pal"), and somehow reduces code size. Remove the old crappy option parser (av_opts.c).
* stream_lavf: allow setting AVOptions with --stream-lavf-owm42014-07-301-0/+9
| | | | | This commit also creates a private option struct for stream_lavf.c, but since I'm lazy, I'm not moving any existing options to it.
* av_common: remove unneeded fieldwm42014-06-291-1/+0
| | | | This is actually needed for encoding only, and not decoding. Drop it.
* Factor out setting AVCodecContext extradatawm42014-01-111-10/+14
|
* av_common: abuse av_log to print message instead of mp_msgwm42013-12-211-1/+2
| | | | Saves a little bit of pain.
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-0/+178