summaryrefslogtreecommitdiffstats
path: root/sub/sd_lavc.c
Commit message (Collapse)AuthorAgeFilesLines
* sub: fix --sub-gausswm42016-06-171-4/+21
| | | | | | | | | | | | | | | | | | | | Implement it directly in sd_lavc.c as well. Blurring requires extending the size of the sub-images by the blur radius. Since we now want sub_bitmaps to be packed into a single image, and we don't want to repack for blurring, we add some extra padding to each sub-bitmap in the initial packing, and then extend their size later. This relies on the previous bitmap_packer commit, which always adds the padding in all cases. Since blurring is now done on parts of a large bitmap, the data pointers can become unaligned, depending on their position. To avoid shitty libswscale printing a dumb warning, allocate an extra image, so that the blurring pass is done on two newly allocated images. (I don't find this feature important enough to waste more time on it.) The previous refactor accidentally broke this feature due to a logic bug in osd.c. It didn't matter before it happened to break, and doesn't matter now since the code paths are different.
* sub: move paletted image handling completely to sd_lavc.cwm42016-06-171-12/+87
| | | | | | | | | | | | | | | | | | | Until now, subtitle renderers could export SUBBITMAP_INDEXED, which is a 8 bit per pixel with palette format. sd_lavc.c was the only renderer doing this, and the result was converted to RGBA in every use-case (except maybe when the subtitles were hidden.) Change it so that sd_lavc.c converts to RGBA on its own. This simplifies everything a bit, and the palette handling can be removed from the common code. This is also preparation for making subtitle images refcounted. The "caching" in img_convert.c is a PITA in this respect, and needs to be redone. So getting rid of some img_convert.c code is a positive side- effect. Also related to refcounted subtitles is packing them into a single mp_image. Fewer objects to refcount is easier, and for the libass format the same will be done. The plan is to remove manual packing from the VOs which need single images entirely.
* sd_lavc: move AVSubtitle bitmap setup code into its own functionwm42016-06-171-34/+44
| | | | No functional changes.
* sd_lavc: work around bug in older ffmpeg releaseswm42016-05-101-2/+6
| | | | | | | | | | | | | | | Older ffmpeg releases don't have ffmpeg git commit 50401f5fb7d778583b03a13bc4440f71063d319d, which fixes ffmpeg's pkt_timebase check to reject its default "unset" timebase as invalid. The consequence was that all non-PGS bitmap subtitle timestamps were forced to 0. Of course this hit _only_ shitty distros using outdated/badly maintained ffmpeg releases, so this is not worth working around. I've already wasted a lot of time on analyzing this dumb issue, and it could be useful for bisecting, so don't drop pre-3.0 ffmpeg just yet. Fixes #3109.
* sd_lavc: use decoder-reordered PTS for PGSwm42016-04-021-3/+21
| | | | | | | | | | | | | | | | There is an obscure feature which requires essentially reordering PTS from different packets. Unfortunately, libavcodec introduced a ridiculously shitty API for this, which works very much unlike the audio/video API. Instead of simply passing through the PTS, it wants to fuck with it for no reason, and even worse, fucks with other fields and changes their semantivcs (??????). This affects AVSubtitle.end_display_time. This probably will cause issues for us, and I have no desire to find out whether it will. Since only PGS requires this, and it happens not to use end_display_time, do it for PGS only. Fixes #3016.
* sd_lavc: add a comment about duration==0 handlingwm42016-04-021-1/+3
| | | | | | | | Basically, this information is useless, because some muxers (hurr libavformat) write bogus information anyway. This means if we e.g. see PGS packets in mkv with duration explicitly set to 0, we must not trust that value anyway. (The FFmpeg API problem is leaking into files, how nice.)
* sd_lavc: fix subtitle display with unknown end timestampswm42016-04-021-1/+1
| | | | | This is a theoretical issue, because subtitle end timestamps for all but the current subtitle are always known.
* sub: implement "sub-seek 0"wm42016-02-041-5/+12
| | | | | | | For bitmap subs, implement it properly. For libass, you need newest git master. Fixes #2791.
* demux: merge sh_video/sh_audio/sh_subwm42016-01-121-2/+2
| | | | | | | | | | This is mainly a refactor. I'm hoping it will make some things easier in the future due to cleanly separating codec metadata and stream metadata. Also, declare that the "codec" field can not be NULL anymore. demux.c will set it to "" if it's NULL when added. This gets rid of a corner case everything had to handle, but which rarely happened.
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-111-1/+1
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* sub: refactor initializationwm42015-12-271-17/+13
| | | | | | | | Just simplify by removing parts not needed anymore. This includes merging dec_sub allocation and initialization (since things making initialization complicated were removed), or format support queries (it simply tries to create a decoder, and if that fails, tries the next one).
* video: switch from using display aspect to sample aspectwm42015-12-191-4/+3
| | | | | | | | | | | | | | | | MPlayer traditionally always used the display aspect ratio, e.g. 16:9, while FFmpeg uses the sample (aka pixel) aspect ratio. Both have a bunch of advantages and disadvantages. Actually, it seems using sample aspect ratio is generally nicer. The main reason for the change is making mpv closer to how FFmpeg works in order to make life easier. It's also nice that everything uses integer fractions instead of floats now (except --video-aspect option/property). Note that there is at least 1 user-visible change: vf_dsize now does not set the display size, only the display aspect ratio. This is because the image_params d_w/d_h fields did not just set the display aspect, but also the size (except in encoding mode).
* sub: remove subtitle filter chain conceptwm42015-12-181-2/+3
| | | | | | | | | | | | | 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.
* sd_lavc: remove small gaps between subtitleswm42015-12-051-0/+3
| | | | | Just like with text subtitles. Move the magic constants to a common place too.
* sd_lavc: discard empty subtitles and improve sub_seek behaviorwm42015-12-051-27/+49
| | | | | | | | | | | Image subtitles often use a "signaling" packet to set the end time of the previous subtitle. As far as the libavcodec API is concerned, such packets decode to empty AVSubtitles. Discard these after the end time of the previous subtitle has been set. Keep track of the per-subtitle end time better. This is for the sake of improving sub_step/sub_seek. Without this, it would seek to the sub before the previous sub, if the current sub has ended displaying.
* sd_lavc: implement sub_step/sub_seekwm42015-12-051-0/+76
| | | | | | | | | Works roughly the same as the one in sd_ass for text subtitles. While sub_step is very uninteresting, it comes for free with the support for sub_seek. The implementation is taken from ass_step_sub() from libass, with some modifications
* sub: allow feeding bitmap subs in advancewm42015-12-051-1/+32
| | | | | | | | | | | | | | | | | | | | | | | Until now, feeding packets to the decoder in advance was done for text subtitles only. This was possible because libass buffers all subtitle data anyway (in ASS_Track). sd_lavc, responsible for bitmap subs, does not do this. But it can buffer a small number of subtitle frames ahead. Enable this. Repurpose the sub_accept_packets_in_advance(). Instead of "can take all packets" it means "can take 1 packet" now. (The old meaning is still needed locally in dec_sub.c; keep it there.) It asks the decoder whether there is place for at least 1 subtitle packet. sd_lavc implements it and returns true if its internal fixed-size subtitle queue still has a free slot. (The implementation of this in dec_sub.c isn't entirely clean. For one, decode_chain() ignores this mechanism, so it's implied that bitmap subtitles do not use the subtitle filter chain in any advanced way.) Also fix 2 bugs in the sd_lavc queue handling. Subtitles must be checked in reverse, because the first entry will often have endpts==NOPTS, which would always match. alloc_sub() must cycle the queue buffer, because it reuses memory allocations (like sub.imgs) by design.
* sd_lavc: take care of AVPicture deprecationwm42015-10-231-3/+12
|
* sd_lavc: extend subtitle resolution if images go outsidewm42015-10-211-0/+9
| | | | | | | | | | | | | | | Helps with broken vobsubs, which have an incorrect resolution header set. So we just extend the subtitle resolution to the video size, if the video size is larger. This helps somewhat with readability, or makes them visible at all. It should be a pretty safe change, because normally no sub pictures are supposed to go outside of the area. It should make a difference with broken files only. The sample in question had a video resolution of 1888x1072, and a subtitle resolution of 720x480. Note that always using video resolution as subtitle resolution would break other files.
* sub: add option for stretching image subtitles to screenwm42015-07-181-0/+2
| | | | | | | Probably makes users happy who want bitmap subtitles to show up in the screen margins, and stops them from doing idiotic crap with vf_expand. Fixes #2098.
* Update license headersMarcin Kurczewski2015-04-131-4/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* osd: simplify an aspect of change detection handlingwm42015-03-181-1/+1
| | | | | | | | | | | | | | | | | | There was a somewhat obscure optimization in the OSD and subtitle rendering path: if only the position of the sub-images changed, and not the actual image data, uploading of the image data could be skipped. In theory, this could speed up things like scrolling subtitles. But it turns out that even in the rare cases subtitles have such scrolls or axis-aligned movement, modern libass rarely signals this kind of change. Possibly this is because of sub-pixel handling and such, which break this. As such, it's a worthless optimization and just introduces additional complexity and subtle bugs (especially in cases libass does the opposite: incorrectly signaling a position change only, which happened before). Remove this optimization, and rename bitmap_pos_id to change_id.
* sd_lavc: remove mp4 vobsub extradata hackwm42015-03-031-35/+0
| | | | | The proper fix is now available in all supported FFmpeg and Libav releases.
* sd_lavc: apply fallback to video resolution only for vobsubswm42015-01-061-14/+11
| | | | | | | | | | | | | | | | | | Commit 87c13de6 added a fallback to video resolution if the subtitle resolution is unknown. Apparently this fixed some broken files with vobsubs. This broke some DVB subtitles. Apparently .ts captures with 1920x1080 video resolution and 720x576 subtitles do exist. The sample at hand had some streams with 720x576 resolution and no sub resolution set, and some streams with 1920x1080 resolution and sub resolution set (both against the same 1920x1080 video). My conclusion is that 720x576 is the only reasonable fallback for DVB (but I can't be sure). The fallback is removed for PGS too. I don't know about the PGS case; it seems the sub resolution must always be set, so it shouldn't matter. Fixes #1425.
* csputils: replace float[3][4] with a structwm42015-01-061-3/+3
| | | | | Not being able to use the 3x3 part of the matrix was annoying, so split it into a float[3][3] matrix and a separate float[3] constant vector.
* sd_lavc: ignore image subtitles with unknown duration after 1 minutewm42014-12-221-0/+3
| | | | | | | | Most image subtitle formats implicitly terminate the current subtitle event with the next event (e.g. a new packet read from the demuxer will instruct the subtitle render to stop display). If the subtitle event is just trailing, it will be displayed forever. So there's no proper way of doing this and we just apply an heuristic to avoid annoyances.
* sd_lavc: compensate for a stupid libavcodec API issuewm42014-12-211-1/+4
| | | | | | | | | The libavcodec PGS decoder sets end_display_time to UINT32_MAX, in an attempt to signal unknown end time (the API does not allow to signal this properly, and this was a backwards compatible hack). While we have no issues with the large value, our code wants to distinguish between known and unknown end time explicitly.
* sd_lavc: strictly letter-box PGS subtitleswm42014-10-211-1/+3
| | | | | | | | | | | | | | Getting subtitle scaling and positioning right even if there are video filters, which completely change the image (like cropping), doesn't seem to have a single, correct solution. To some degree, the results are arbitrary, so we may as well do what is most useful to the user. In this case, if the PGS resolution aspect ratio and the video output aspect ratio mismatch, letter-box it, instead of stretching the subs over the video frame. (This will require additional fixes, should it turn out that there are PGS subtitles which are stretched by design.) Fixes #1205.
* sd_lavc: remove ineffective codewm42014-08-241-4/+1
| | | | | | | | | It makes no sense to set the packet duration, because libavcodec doesn't know the timebase. And in fact, no subtitle decoder accesses the packet duration, except text subtitle converters, which are not relevant here. So this code did nothing - drop it. Also fix a blatantly incorrect comment.
* sub: call sub_reset() on seeks onlywm42014-08-141-9/+3
| | | | | | | | | | | | | | | | | sub_reset() was called on cycling subtitle tracks and on seeking. Since we don't want that subtitles disppear on cycling, sd_lavc.c didn't clear its internal subtitle queue on reset, which meant that seeking with PGS subtitles could leave the subtitle on screen (PGS subtitles usually don't have a duration set). Call it only on seeking, so we can also strictly clear the subtitle queue in sd_lavc. (This still can go very wrong if you disable a subtitle, seek, and enable it again - for example, if used with libavformat that uses "SSA" style demuxed ASS subtitle packets. That shouldn't happen with newer libavformat versions, and the user can "correct" it anyway by executing a seek while the subtitle is selected.)
* sd_lavc: fix stupiditywm42014-06-191-2/+5
| | | | | | Reallocating an array while you still have pointers to it -> bad idea. Recent regression.
* sd_lavc: improve bitmap subtitle timingwm42014-06-181-71/+103
| | | | | | | | | | | | | | | | | | | | | Until now, bitmap subtitles were decoded at "some" point, and then simply replaced the old subtitle. Although the subtitle is selected by time (PTS), it could happen that a subtitle was replaced too early. One consequence is that this might lead to flicker even if the subtitles are timed to follow each other without a gap (although most subtitles are explicitly timed to introduce such a gap). With this commit the past 4 subtitles are kept (instead of 1), so that the correct one can be picked by time. This should fix the aforementioned cases, but more importantly will allow demuxing/decoding and video display to be somewhat asynchronous. Still missing: somehow making sure the correct range of decoded subtitles is available, instead of just passing along whatever comes from the demuxer, and hoping that 4 queued subtitles are enough. But it should certainly be good enough for now. This removes a check that resets the subtitles if the PTS is 5 minutes before the end of the current subtitle; this is probably not needed.
* sub: remove old MPlayer DVD sub decoderwm42014-03-161-5/+0
| | | | | The DVD sub decoder in Libav 9 was broken/incomplete, so we kept the MPlayer decoder around. Now it's not needed anymore.
* sd_lavc: handle subtitles with no subtitle resolution setxylosper2014-02-141-0/+4
| | | | | | | | | | | | | | | | | | | | | | | Set subtitle resolution to video resolution when avctx->width and avctx->height are zero. This can happen with broken vobsubs that have no size set in their .idx file (or Matroska extradata). At least with the test file provided in issue #551, using the video resolution as fallback instead of what guess_resolution() does is better. Note that these files clearly are broken. It seems this particular file was created by trying to use ffmpeg to transcode DVB subtitles to vobsub, and ffmpeg "forgot" to set the subtitle resolution in the destination file. On the other hand, ffmpeg DVB and PGS decoders set the resolution on the first subtitle packet (or somewhere close), so it's not really clear what to do here. Closes #551. Signed-off-by: wm4 <wm4@nowhere> Patch by xylosper, rewritten commit message by wm4.
* sub: handle vobsub-in-mp4wm42014-02-131-0/+36
| | | | | | | | | | | The mplayer decoder (spudec.c) actually handled this. There was explicit code for binary palettes (16 32 bit values), and the subtitle resolution was handled by video resolution coincidentally matching the subtitle resolution. Whoever puts vobsub into mp4 should be punished. Fixes the sample gundam_sample.mp4, closes github issue #547.
* sd_lavc: skip 0 sized sub-bitmapswm42014-01-291-2/+4
| | | | | | | Not everything in the OSD path handles 0x0 sized sub-bitmaps well. At least the code implementing --sub-gray had severe problems with it. Fix this by skipping such bitmaps.
* sub: fix crash with certain uses of --vf=subwm42014-01-261-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If, for some reason, the subtitle renderer attempts to render a subtitle before SD_CTRL_SET_VIDEO_PARAMS was called, it passed a value calculated from invalid values. This can happen with --vf=sub and --start. The crash happens if 1. there was a subtitle packet that falls into the timestamp of the rendered video frame, 2. the playloop hasn't informed the subtitle decoder about the video resolution yet (normally unneeded, because that is used for weird corner cases only, so this code is a bit fuzzy), and 3. something actually requests a frame to be drawn from the subtitle renderer, like with vf_sub. The actual crash was due to passing NaN as pixel aspect to libass, which then created glyphs with ridiculous sizes, involving a few integer overflows and unchecked mallocs. The sd_lavc.c and sd_spu.c cases probably don't crash, but I'm not sure, and it's better fix them anyway. Not bothering with sd_spu.c, this crap is for compatibility and will be removed soon. Note that this would have been no problem, had the code checked whether SD_CTRL_SET_VIDEO_PARAMS was actually called. This commit adds such a check (although it basically checks after using the parameters). Regression since 49caa0a7 and 633fde4a.
* sd_lavc: use mp_lavc_set_extradata()wm42014-01-111-2/+2
| | | | | This includes the magical input padding required by libavcodec, which we possibly didn't do before this commit.
* sub/osd: mp_msg conversionswm42013-12-211-4/+2
|
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-2/+2
|
* Move options/config related files from mpvcore/ to options/wm42013-12-171-1/+1
| | | | | | | | | Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
* Add prelimimary (basic, possibly broken) dvdnav supportwm42013-12-121-4/+15
| | | | | | | | | | | | | | | | | | | | | | | | | This readds a more or less completely new dvdnav implementation, though it's based on the code from before commit 41fbcee. Note that this is rather basic, and might be broken or not quite usable in many cases. Most importantly, navigation highlights are not correctly implemented. This would require changes in the FFmpeg dvdsub decoder (to apply a different internal CLUT), so supporting it is not really possible right now. And in fact, I don't think I ever want to support it, because it's a very small gain for a lot of work. Instead, mpv will display fake highlights, which are an approximate bounding box around the real highlights. Some things like mouse input or switching audio/subtitles stream using the dvdnav VM are not supported. Might be quite fragile on transitions: if dvdnav initiates a transition, and doesn't give us enough mpeg data to initialize video playback, the player will just quit. This is added only because some users seem to want it. I don't intend to make mpv a good DVD player, so the very basic minimum will have to do. How about you just convert your DVD to proper video files?
* sd_lavc: factor out bitmap positioning codewm42013-12-121-30/+14
|
* Rename sub.c/.h to osd.c/.hwm42013-11-241-1/+0
| | | | | This was way too misleading. osd.c merely calls the subtitle renderers, instead of actually dealing with subtitles.
* Reduce stheader.h includes, move stream types to mp_common.hwm42013-11-231-1/+0
|
* sd_lavc, sd_spu: make dvdsub stretching conditional on --stretch-dvd-subs.Rudolf Polzer2013-11-071-1/+3
| | | | | | | | | | | | We found that the stretching - although it usually improves the looks of the fonts - is incorrect. On DVD, subtitles can cover the full area of the picture, and they have the same pixel aspect as the movie itself. Too bad many commercially released DVDs use bitmap fonts made with the wrong pixel aspect (i.e. assuming 1:1) - --stretch-dvd-subs will make these more pretty then.
* sd_ass, sd_lavc: use the input video's pixel aspect for scaling subtitles.Rudolf Polzer2013-11-071-3/+21
| | | | | | | The previous code used the output video's pixel aspect for stretching purposes, breaking rendering with e.g. -vf scale in the chain. Now subtitles are stretched using the input video's pixel aspect only, matching the intentions of the original subtitle author.
* sd_lavc: display DVD subs with unknown durationwm42013-10-311-0/+6
| | | | | | | | | | | | | | | | | | DVD subs (rarely) have subtitle events without end timestamp. The duration is unknown, and they should be displayed until they're replaced by the next event. FFmpeg fails hard to make us aware whether duration is unknown or actually 0, so we can't distinguish between these two cases. It fails at this twice: AVPacket.duration is set to 0 if duration is unknown, and AVSubtitle.end_display_time has the same issue. Add a hack that considers all bitmap subtitles with duration==0 as events with uknown length. I'd rather accidentally display a hidden subtitle (if they exist at all), instead of not displaying random subtitles at all. See github issue #325.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-3/+3
| | | | Followup commit. Fixes all the files references.
* sd_lavc: don't stretch DVD subtitles to video aspectwm42013-07-161-4/+16
| | | | | | | | | | | | | | | | | | | | | | I'm not sure what's correct: stretching the DVD subtitles from storage aspect ratio to video display aspect ratio, or displaying subtitles u