summaryrefslogtreecommitdiffstats
path: root/sub/sd_lavc_conv.c
Commit message (Collapse)AuthorAgeFilesLines
* sub: rename sd_lavc_conv.c to lavc_conv.cwm42015-12-181-280/+0
| | | | | | | | The previous commit turned sd_lavc_conv from a sd_driver to free-standing functions. Do the rename to reflect this change separately to avoid confusing git's content tracking. (Or did git solve this, making separating renames and content changes unnecessary?)
* sub: remove subtitle filter chain conceptwm42015-12-181-54/+47
| | | | | | | | | | | | | It was stupid. The only thing that still effectively used it was sd_lavc_conv - all other "filters" were the subtitle decoder/renderers for text (sd_ass) and bitmap (sd_lavc) subtitles. While having a subtitle filter chain was interesting (and actually worked in almost the same way as the audio/video ones), I didn't manage to use it in a meaningful way, and I couldn't e.g. factor secondary features like fixing subtitle timing into filters. Refactor the shit and drop unneeded things as it goes.
* sub: do not clear subtitle list on seekingwm42015-12-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This affects non-ASS text subtitles (those which go through libavcodec's subtitle converter), which are muxed with video/audio. (Typically srt subs in mkv.) The problem is that seeking in the file can send a subtitle packet to the decoder multiple times. These packets are interlaved with video, and thus can't be all read when opening the file. Rather, subtitle packets can essentially be randomly skipped or repeated (by seeking). Until recently, this was solved by scanning the libass event list for duplicates. Then our builtin srt-to-ass converter was removed, and the problem was handled by fully clearing the subtitle list on each seek. This resulted in sub-seek not working properly for this type of file. Since the subtitle list was cleared on seek, it was not possible to do e.g. sub-seeks to subtitles before the current playback position. Fix this by not clearing the list, and intead explicitly rejecting duplicate packets. We use the packet file position was unique ID for subtitles; this is confirmed working for most file formats (although it is slightly risky - new demuxers may not necessarily set the file position to something unique, or at all). The list of seen packets is sorted, and the lookup uses binary search. This is to avoid quadratic complexity when subtitles are added in bulks, such as when opening a text subtitle file. In some places, the code has to be adjusted to pass through the packet file position correctly.
* Replace deprecated av_free_packet() callswm42015-10-281-3/+3
| | | | | | av_free_packet() got finally deprecated. Use av_packet_unref() instead, which has almost the same semantics, has existed for a while, and is available in all FFmpeg and Libav versions we support.
* Take care of libavcodec convergence_duration deprecationwm42015-09-291-0/+2
| | | | | | This AVPacket field was a hack against the fact that the duration field was merely an int (too small for things like subtitle durations). Newer libavcodec drops this field and makes duration 64 bit.
* sub: always try to use libavcodec text subtitle converterwm42015-09-011-12/+4
| | | | | | | | | | | | Drop the whitelist. It's annoying to maintain. Instead, accept any subtitle decoder. Since this code path will now also be taken by bitmap subtitle decoders not whitelisted by sd_lavc.c, add a warning when bitmap subtitles are decoded. (To reduce or increase potential user confusion.) To some degree, a whitelist is needed to distinguish text and bitmap subtitles. FFmpeg has an API to distinguish them in a generic way to some degree, but Libav doesn't. So we just stick with this for now.
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-291-1/+1
| | | | | | | | | bstr.c doesn't really deserve its own directory, and compat had just a few files, most of which may as well be in osdep. There isn't really any justification for these extra directories, so get rid of them. The compat/libav.h was empty - just delete it. We changed our approach to API compatibility, and will likely not need it anymore.
* Remove some more unneeded version checkswm42014-03-161-5/+1
| | | | | All of these check against things that happened before the latest supported FFmpeg/Libav release.
* sub/osd: mp_msg conversionswm42013-12-211-4/+3
|
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-3/+3
|
* av_common: add timebase parameter to mp_set_av_packet()wm42013-12-041-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | If the timebase is set, it's used for converting the packet timestamps. Otherwise, the previous method of reinterpret-casting the mpv style double timestamps to libavcodec style int64_t timestamps is used. Also replace the kind of awkward mp_get_av_frame_pkt_ts() function by mp_pts_from_av(), which simply converts timestamps in a way the old function did. (Plus it takes a timebase parameter, similar to the addition to mp_set_av_packet().) Note that this should not change anything yet. The code in ad_lavc.c and vd_lavc.c passes NULL for the timebase parameters. We could set AVCodecContext.pkt_timebase and use that if we want to give libavcodec "proper" timestamps. This could be important for ad_lavc.c: some codecs (opus, probably mp3 and aac too) have weird requirements about doing decoding preroll on the container level, and thus require adjusting the audio start timestamps in some cases. libavcodec doesn't tell us how much was skipped, so we either get shifted timestamps (by the length of the skipped data), or we give it proper timestamps. (Note: libavcodec interprets or changes timestamps only if pkt_timebase is set, which by default it is not.) This would require selecting a timebase though, so I feel uncomfortable with the idea. At least this change paves the way, and will allow some testing.
* sd_lavc_conv: fix build with older ffmpeg/libavwm42013-08-241-0/+17
| | | | Sigh...
* sub: add webvtt-in-webm supportwm42013-08-241-1/+124
| | | | | | | | | | | | | | The way this was added to FFmpeg is less than ideal, because it requires text parsing in the Matroska demuxer. But in order to use the FFmpeg webvtt-to-ass converter, we still have to mimic this in some way. We do this by putting the parsing into sd_lavc_conv.c, before the subtitle packet is passed to libavcodec. At least this keeps the ugliness out of unrelated code. There is some change that FFmpeg will fix their design eventually. Instead of rewriting the parsing code, we simply borrow it from FFmpeg's Matroska demuxer.
* sd_lavc_conv: don't check AV_CODEC_PROP_TEXT_SUB flagwm42013-08-151-7/+3
| | | | | | | | Not actually useful. This would break whenever a new text subtitle format would be added, which requires a binary->text transformation. (mov_text is one such format; disable it.) In general, we would have to know which packet formats are binary, which we don't, so the only reasonable way to handle this is a white list.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-3/+3
| | | | Followup commit. Fixes all the files references.
* sd_ass: handle libavformat ASS comment packets as wellwm42013-06-231-1/+1
| | | | | | | | | | | | Currently, we are filtering libavformat style ASS packets by checking whether they are prefixed "Dialogue: ". Unfortunately, comment packets are demuxed too. These start with "Comment: ", so they are not caught. Change the filtering, and use the codec ID instead. libavformat uses "ssa" as codec ID for ASS subtitles, while mpv uses "ass". Also, at least FFmpeg will change the ASS packet format to the same format mpv and Matroska use, and identify these with "ass" as codec ID, so this is works out nicely.
* sub: add name field to all sub decoderswm42013-06-031-0/+1
| | | | Might help with debugging.
* core: add common function to initialize AVPacketwm42013-06-031-4/+1
| | | | | | | | | | Audio and video had their own (very similar) functions to initialize an AVPacket (ffmpeg's packet struct) from a demux_packet (mplayer's packet struct). Add a common function for these. Also use this function for sd_lavc_conv. This is actually a functional change, as some libavfilter subtitle demuxers add weird out-of-band stuff as side-data.
* sd_lavc_conv: strip style headerwm42013-06-031-0/+19
| | | | | | | | | Normally, libavcodec subtitle converters will output a style header like this as part of the extradata: Style: Default,Arial,16,&Hffffff,&Hffffff,&H0,&H0,0,0,0,1,1,0,2,10,10,10,0,0 We don't want that, so use some bruteforce to get rid of them.
* sd_lavc_conv: add hack if AV_CODEC_PROP_TEXT_SUB is not availablewm42013-06-031-1/+17
| | | | | | | Otherwise this could happily open decoders for image subtitles or even audio/video decoders. AV_CODEC_PROP_TEXT_SUB is a preprocessor symbol, but it's still better to detect this properly instead of using #ifdef, because these flags might as well be changed into enums sooner or later.
* sub: make use of libavcodec subtitle converterswm42013-06-031-0/+132
This allows using some formats that were not supported until now, like WebVTT. We still prefer the internal subtitle reader (subreader.c), because 1. Libav, and 2. random things which we probably want to keep, such as control over formatting, codepage stuff, or various mysterious postprecessing done in that code.