[Ffmpeg-devel-irc] ffmpeg-devel.log.20140922

[burek]

[00:20] <jamrial> BBB: https://github.com/jamrial/FFmpeg/commit/1d408433e2d3fc951d26d688d15c4fe08c0eed6a
[00:24] <cone-560> ffmpeg.git 03Nicolas George 07fatal: ambiguous argument 'refs/tags/n2.4.1': unknown revision or path not in the working tree.
[00:24] <cone-560> Use '--' to separate paths from revisions
[00:24] <cone-560> refs/tags/n2.4.1:HEAD: lavu/bprint: add const to av_bprint_is_complete() argument.
[00:53] <cone-560> ffmpeg.git 03Jörg Krause 07master:56b8d106769c: configure: Refactor setting of feature test macro _XOPEN_SOURCE
[01:26] <pross> 'what to pull from ffmpeg' makes up third of libav vdd report. good job guys.
[01:28] <jamrial> we can't really make fun of them for that tbh, because we literally pull *everything* from libav
[02:40] <iive> well, they are not going to literally pull stuff from ffmpeg. Its history is way too ... non-linear, bumpy, hairy 
[03:08] <cone-560> ffmpeg.git 03Deti Fliegl 07master:a5e040ee3c75: avdevice/decklink: move general code of decklink encoder to common file
[03:08] <cone-560> ffmpeg.git 03Deti Fliegl 07master:bac6cfcb3a1d: avdevice: add decklink input support
[03:10] <pross> iive: "smelly"
[03:18] <jamrial> michaelni: should the decklink indev addition bump minor for lavd?
[03:45] <cone-560> ffmpeg.git 03Michael Niedermayer 07master:f3aaec781a9e: avdevice/version: bump minor for the decklink input
[04:26] <cone-560> ffmpeg.git 03Thomas Volkert 07master:e1cddd1a0c21: rtpenc_h263_rfc2190: avoid misleading error output
[06:25] <rcombs> I was under the impression that the only thing people ever did with AVIs was remux them to something else
[10:32] <ubitux> mmh is there a record of the ebu-tt talk @ vdd?
[10:34] <cone-636> ffmpeg.git 03Benoit Fouet 07master:591e06b0e24f: avformat/img2: remove useless 'pix' duplicated entry.
[11:02] <cone-636> ffmpeg.git 03Benoit Fouet 07master:9c843fb1d081: avformat/avidec: ensure that palette does not contain the BottomUp info.
[11:56] <kierank> ubitux: I think yes
[11:57] <ubitux> does it look sane?
[13:53] <ubitux> > I would like to see avpicture_deinterlace improved, renamed, but retained as
[13:53] <ubitux> > part of the main ffmpeg libraries.
[13:53] <ubitux> seriously..
[14:10] <J_Darnley> renamed to what?
[14:11] <ubitux> avpicture_deinterlace_broken() is the only suggestion that comes to my mind
[14:12] <ubitux> they guy is like "please i know it's broken, but please keep it, and improve it so it's not broken"
[14:15] <wm4> he just dislikes the terrible lavfi API
[14:15] <wm4> seems justified
[14:15] <ubitux> that's right, but the correct thing to do is improve the interface with it
[14:15] <ubitux> not keep and "improve" this hack
[14:17] <wm4> sure
[14:47] <Daemon404> wow avpicture_deinterlace still exists?
[14:47] <Daemon404> that makes me a sad panda
[14:48] <wm4> ffmpeg never removes things
[14:48] <Daemon404> is it at least deprecated
[14:48] <Daemon404> even people in ffmpeg hate it
[14:48] <Daemon404> afaict
[14:49] <wm4> yes
[14:49] <ubitux> libav also has it
[14:49] <wm4> and it's in one of those major-bump-removal-guards
[14:49] <Daemon404> ubitux, doesnt mean its not terrible
[14:49] <Daemon404> wm4, i see
[14:49] <Daemon404> so 'soon'
[14:49] <ubitux> sure, just saying it's not that we are eagerly keeping it
[14:49] <wm4> 2 years, give or take
[14:50] <Daemon404> ubitux, sure
[14:50] <Daemon404> i dont think anyone is encouraging its use
[14:50] <Daemon404> ;)
[14:51] <wm4> I think all of avpicture should die
[14:52] <Daemon404> there was a single function i used from it iirc...
[14:52] <Daemon404> avpicture_layout or something
[14:52] <Daemon404> to make a contiguous buffer
[14:52] <wm4> yeah
[14:53] <wm4> rawdec or so uses that too
[14:53] <Daemon404> i mean
[14:53] <wm4> or was it rawvideo
[14:53] <Daemon404> it's useful, but it should be in avutil
[14:53] <Daemon404> or smth
[14:53] <Daemon404> i mean a proper util func
[14:53] <Daemon404> not avpict
[15:38] <cone-636> ffmpeg.git 03Thomas Volkert 07master:5820358bbc4a: Add missing entry for maintainer of rtpenc_hevc.*
[17:01] <wm4> ubitux: "We at XBMC got the first complaints about broken subtitles. Why was this removed?"
[17:01] <wm4> hahahaha
[17:01] <ubitux> i'm replying
[17:01] <ubitux> that was expected
[17:01] <ubitux> vlc might break too
[17:02] <wm4> I just replied too
[17:02] <nevcairiel> that reminds me that I wanted to check if i need to adapt anything to that
[17:03] <nevcairiel> did you change the ass output of avi by any chance
[17:03] <nevcairiel> (i know, ass in avi, big hack, etc)
[17:04] <wm4> I don't think we ever supported that?
[17:04] <nevcairiel> well it works somehow, i use avformat afterall
[17:04] <wm4> got a sample file?
[17:04] <nevcairiel> i was hoping to avoid that part
[17:05] <nevcairiel> my archives of that age arent well sorted
[17:06] <ubitux> it's not supported in avi afaik
[17:07] <nevcairiel> found it!
[17:08] <nevcairiel> http://files.1f0.de/samples/mewmew-ssa.avi
[17:08] <nevcairiel> still works for me  at least
[17:09] <wm4> doesn't work here
[17:09] <wm4> no subtitle stream
[17:10] <nevcairiel> wonder if i hacked the detection in
[17:10] Action: nevcairiel checks hack backlog
[17:10] <wm4> [avi @ 0x68d920] Could not find codec parameters for stream 17 (Unknown: none): unknown codec
[17:10] <wm4> Consider increasing the value for the 'analyzeduration' and 'probesize' options
[17:10] <wm4> and I get streams like:
[17:10] <wm4>     Stream #0:4: Unknown: none
[17:10] <wm4>     Metadata:
[17:10] <wm4>       title           : English
[17:10] <nevcairiel> http://git.1f0.de/gitweb?p=ffmpeg.git;a=commitdiff;h=603d3c063787895bbf10ec18b3557a3602103a12;js=1
[17:10] <wm4> (ffprobe)
[17:10] <nevcairiel> this maybe did it
[17:11] <nevcairiel> only one remotely related
[17:11] <wm4> could be
[17:11] <nevcairiel> but of course its in the old format
[17:11] <nevcairiel> but i have codez that convert it!
[17:12] <ubitux> if the avi didn't hack the packet, nothing might actually change
[17:12] <ubitux> also is see no mapping to the codec itself
[17:12] <ubitux> (and never saw any)
[17:12] <nevcairiel> i guess there is a probe function somewhere
[17:12] <wm4>    Stream #0:4: Subtitle: ssa
[17:12] <wm4>     Metadata:
[17:12] <wm4>       title           : English
[17:13] <wm4> black magic?
[17:13] <wm4> which that patch above applied
[17:13] <ubitux> O_O
[17:13] <cone-636> ffmpeg.git 03Michael Niedermayer 07master:fe5093aafc8f: Revert "configure: Refactor setting of feature test macro _XOPEN_SOURCE"
[17:13] <nevcairiel> it can use the probe function of the ass demuxer to set the codec
[17:13] <nevcairiel> its one of the neat tricks in avformat
[17:13] <wm4> it even works in my player
[17:13] <wm4> oh, my ffmpeg copy isn't up to date
[17:13] <wm4> might be before ubitux's changes
[17:14] Action: ubitux is extremely confused at what's going on 
[17:14] <nevcairiel> hah
[17:15] <nevcairiel> which is supposed to be the short mkv format, SSA or ASS?
[17:15] <wm4> how do you make ffprobe to show packet contents?
[17:15] <wm4> mkv supports both
[17:15] <Daemon404> *contents*? i'd be surprised if it had such a feature.
[17:15] <wm4> the mangling should be the same
[17:15] <nevcairiel> ASS is the short one, i looked it up
[17:16] <nevcairiel> wm4: i was talking av codecs
[17:16] <wm4> ah
[17:16] <nevcairiel>  AV_CODEC_ID_SSA is with Dialogue: and timestamp and whatnot
[17:16] <wm4> yeah
[17:16] <nevcairiel> _ASS is without
[17:16] <wm4> ok so avi uses the old format?
[17:16] <nevcairiel> yes
[17:16] <wm4> awesome
[17:17] <nevcairiel> whatever tool muxed this, it just copied the line 1:1 from a .ass file
[17:17] <nevcairiel> maybe even ffmpeg muxed this, and just copied the stuff in there
[17:18] <nevcairiel> what other containers could ass/ssa possibly be in?
[17:18] <nevcairiel> pretty much just mkv?
[17:19] <wm4> ogm?
[17:19] <wm4> (maybe)
[17:19] <nevcairiel> mkv is the only place it seems mentioned in avformat
[17:20] <nevcairiel> short of the raw demuxers
[17:20] <wm4> hm seems like ogm just has plain text subs
[17:22] <ubitux> wm4, Daemon404 -show_packets -show_data
[17:22] <ubitux> and -select_streams s:0 might help
[17:22] <nevcairiel> that avi has a lot of subtitle streams otherwise
[17:23] <wm4> thanks
[17:23] <nevcairiel> the first stream is kinda funky tho, i think it has only one packet
[17:23] <wm4> Dialogue: Marked=0,0:00:00.77,0:....
[17:23] <ubitux> oh. my. god.
[17:23] <nevcairiel> i told you
[17:24] <nevcairiel> Writing application            : AVI-Mux GUI 1.17.8
[17:24] <nevcairiel> fwiw
[17:24] <JEEBsv> oh yes
[17:24] <ubitux> current ffmpeg doesn't demux them anyway
[17:24] <JEEBsv> from the "yes avi can do this" guy
[17:25] <nevcairiel> i think a user complained about lack of support to me one day, and it was like a 2 line fix, so...
[17:26] <ubitux> i'll keep that sample for when i get a hand on a death note
[17:27] <Daemon404> lol
[17:27] <Daemon404> didnt look but i bet it was from circa 2005 gg
[17:32] <ubitux> ooh that request_probe is so evil
[17:32] <ubitux> actually that's awesome
[17:32] <ubitux> but still..
[17:33] <Daemon404> the best probe is no probe
[17:33] <Daemon404> everything is mp3
[17:33] <alpa_astero> I agree with the first half of that
[17:33] <Daemon404> the latter is true in lavf though
[17:34] <nevcairiel> i think even avformat would  be hardpressed to identify a text subtitle as mp3
[17:34] <Daemon404> you may regret those words one dya
[17:34] <Daemon404> day
[17:34] <wm4> lol
[17:35] <ubitux> try starting the subtitles "\x7ELF" or something like that
[17:35] <ubitux> might trigger the mp3 probing
[17:35] <Daemon404> ubitux, as a bonus it could actually work with some ass parsers
[17:35] <nevcairiel> i suppose some chinese unicode subs could easily identify as binary something
[17:35] <Daemon404> because some will skip any leadign two bytes
[17:35] <wm4> yeah, lavf still thinks ELF binaries are mp3
[17:35] <Daemon404> because some files have a BOM
[17:36] <nevcairiel> wm4: probe score 2?
[17:36] <nevcairiel> :D
[17:36] <ubitux> Daemon404: wm4 fixed that ;)
[17:36] <nevcairiel> luckily lavf exposes the probe score now, so you can say like, probe score < 10, i dont want to open you
[17:36] <wm4> nevcairiel: no, 50
[17:37] <nevcairiel> i dunno what value is required for realisticly  opening most valid files
[17:37] <Daemon404> nevcairiel, but some demuxers use a low probe score
[17:37] <Daemon404> and only such a probe score
[17:37] <Daemon404> it's entirely arbitrary
[17:37] <nevcairiel> Daemon404: but not as low as 10
[17:37] <nevcairiel> its usually 25 or so
[17:37] <ubitux> nevcairiel: anyway, i guess we'll probably need to keep the SSA decoder...
[17:37] <ubitux> so& thanks for the sample :)
[17:38] <wm4> you could make the avi demuxer depend on the ass demuxer, and share the header parser
[17:38] <wm4> the novelty of "avi demuxer depends on ass demuxer" would be amusing
[17:38] <Daemon404> just add it to dsputils
[17:38] <ubitux> :D
[17:38] <nevcairiel> i thought diego killed dsputils now
[17:39] <Daemon404> true
[17:39] <Daemon404> The Context was cleaned up to
[17:39] <Daemon404> i dont have a whipping boy anymore
[17:39] <ubitux> yes it's called videodsp now
[17:39] <nevcairiel> there is still mpegvideoencctx or how its called, and its still evil
[17:39] <Daemon404> i thought elenril broke it up
[17:40] <nevcairiel> its not used in  h264 anymore at least, but i think the evil remains in the true mpeg decoders
[17:40] <Daemon404> o ok
[17:40] <nevcairiel> i may have missed something tho
[17:40] <nevcairiel> never know
[17:44] <ubitux> btw, i wonder how we're going to be able to decode properly these subtitles
[17:44] <ubitux> typically, on seek
[17:44] <wm4> ubitux: because of the ReadOrder?
[17:44] <ubitux> yes
[17:44] <wm4> set ReadOrder to timestamp
[17:44] <wm4> not very nice but works
[17:44] <ubitux> ooh
[17:45] <wm4> the ass muxer will buffer them, but who cares
[17:45] <nevcairiel> if this is the same format as .ass files, how do .ass files work :d
[17:45] <ubitux> libass won't shit bricks with the readorder gaps?
[17:45] <wm4> ubitux: no
[17:45] <ubitux> yeah right
[17:45] <ubitux> interesting
[17:46] <ubitux> nevcairiel: ass demuxer increment the readorder at each line
[17:46] <ubitux> also it's not incremental since it needs to read the whole file (to stort by ts etc)
[17:47] <ubitux> wm4: anyway, thanks for the trick, that sounds pretty good
[17:47] <ubitux> i hope libass read the readorder as int64 ;)
[17:50] <wm4> no
[17:50] <wm4> just int
[17:55] <nevcairiel> just use ass timebase, there is still plenty of room in 32-bit then
[17:56] <nevcairiel> or 31 if its signed
[17:56] <cone-636> ffmpeg.git 03Michael Niedermayer 07master:bd6890975303: postprocess: prefetch* dont change anything, thus their arguments should be const
[17:56] <cone-636> ffmpeg.git 03Michael Niedermayer 07master:3c4fc6a78251: postproc/postprocess_template: mark unchanged function arguments const
[17:58] <ubitux> note that pts are not unique
[17:58] <ubitux> and typically in your sample
[17:58] <ubitux> the first 2 have the same pts
[17:59] <ubitux> i should probably use pos
[18:16] <cone-636> ffmpeg.git 03Michael Niedermayer 07master:3a7f9db180d9: avcodec/snow: Make block argumrnt of ff_snow_pred_block() const
[18:16] <cone-636> ffmpeg.git 03Michael Niedermayer 07master:544380aaf0da: avcodec/4xm: Make src of decode_p_block() const
[18:59] <cone-636> ffmpeg.git 03Michael Niedermayer 07master:d902a3f4cb97: avformat/adtsenc: buf isnt changed in adts_decode_extradata(), make it const
[18:59] <cone-636> ffmpeg.git 03Michael Niedermayer 07master:1cf28fd5f3f6: avformat/asfenc: Make asf_write_indexs index argument const
[19:10] <wm4> how do I enable debugging for a certain source file? I keep forgetting this
[19:10] <nevcairiel> i know how to do it for msvc
[19:11] <nevcairiel> #pragma GCC optimize ("O0") i guess?
[19:11] <wm4> oh, it'd be awesome if that works, I'll try
[19:12] <nevcairiel> thats what i do in msvc, and it works perfectly
[19:12] <nevcairiel> different pragma of course
[19:13] <wm4> this probably worked
[19:13] <wm4> thanks a lot
[19:21] <ubitux> hey saste 
[19:21] <saste> ubitux, hey
[19:22] <ubitux> saste: are you going to write a summary?
[19:22] <saste> ubitux, a summary about VDD2014?
[19:22] <ubitux> yes
[19:22] <saste> ubitux, we had a meeting with Libav, I'm going to write a summary about that, yes
[19:23] <saste> let's say before the end of the week
[19:23] <saste> then I missed the ffmpeg whining session, because I already left the venue when the session begun
[19:36] <rcombs> can the ASS muxer be made to not buffer output? I might need that for a thing.
[19:37] <ubitux> buffer output?
[19:37] <ubitux> like, not flushing after every packet?
[19:38] <rcombs> like, not waiting until the end if it doesn't get ReadOrder 1
[19:38] <ubitux> aah, not buffer output, no
[19:38] <ubitux> why do you need that?
[19:38] <rcombs> might need to stream subtitles to a client live
[19:38] <ubitux> how evil
[19:38] <ubitux> and you pick ass for that?
[19:39] <ubitux> well, i guess we could add an option
[19:39] <rcombs> libjass is a thing that works pretty well
[19:39] <wm4> libjass wat
[19:39] <ubitux> like, "max buffer count size" or something
[19:39] <rcombs> I've been poking at it for in-browser streamed subtitle rendering
[19:39] <ubitux> libjackass
[19:40] <rcombs> ubitux: and I suppose I'd set that to 0 if I wanted subs output RIGHT NOW, then?
[19:40] <ubitux> 1 actually i'd say
[19:40] <ubitux> but yeah
[19:40] <wm4> rcombs: why would you mux anyway?
[19:40] <rcombs> sane values are 0, 1, and infinity, I suppose
[19:40] <ubitux> you're aware that will break the readorder right?
[19:40] <wm4> you'd just transfer the ass packet over http or so
[19:41] <rcombs> wm4: still gotta output in some sort of format
[19:41] <rcombs> ubitux: yeah, but if I'm rendering in-browser it probably doesn't matter
[19:41] <ubitux> why not use webvtt? oO
[19:42] <ubitux> (you need advanced markup?)
[19:42] <rcombs> ubitux: because a lot of implementations suck, and a lot of browsers don't have implementations
[19:42] <ubitux> ok
[19:42] <rcombs> and you can't even do color properly with webvtt
[19:43] <rcombs> libjass is great for dialogue with basic styling, and can even handle simple kara and TS
[19:43] <wm4> hehe webvtt
[19:43] <rcombs> but if you're anywhere near the point where ReadOrder matters, then you're probably beyond its limitations
[19:43] <wm4> <rcombs> wm4: still gotta output in some sort of format <- well, you need some framing
[19:43] <wm4> maybe wrap the ass text in json
[19:43] <wm4> oh god what am I suggestion... but should work
[19:43] <wm4> *suggesting
[19:44] <ubitux> o_o
[19:44] <rcombs> wm4: that'd require a custom ASS-in-JSON muxer and would be altogether more complex than just streaming .ass and chucking lines at libjass's parser
[19:44] <rcombs> also, it'd make me feel like Crunchyroll (which does something like that)
[19:45] <wm4> oh so I guess your issue is that even the code for it is trivial, you have to have it in ffmpeg?
[19:45] <ubitux> maybe we can make a jass muxer
[19:45] <rcombs> more that I have absolutely no reason to do it that way
[19:45] <ubitux> actually, you can do that with ffprobe
[19:46] <ubitux> ah mmh, not for the payload
[19:47] <wm4> so, what is libjass? a new impl, or emscripted libass?
[19:48] <rcombs> Arnavion's basic ASS implementation in JS using HTML nodes and CSS
[19:49] <rcombs> it's limited to what you can do with, well, HTML nodes and CSS, but that encompasses pretty much everything you can rationally call "subtitles"
[19:51] <wm4> that's... not what ASS is
[19:52] <wm4> ASS what you irrationally call "subtitles"
[19:53] <kepstin-laptop> you see the lightning bolts in https://www.kepstin.ca/dump/railgunsop.jpg ? those are done in ASS subtitles.
[19:53] <ubitux> yeah that stuff is "common"
[19:57] <rcombs> kepstin-laptop: that's not that complex
[19:57] <rcombs> libjass couldn't handle it (it doesn't have drawing support), but there's _way_ more complex stuff done regularly in ASS than that
[19:57] <wm4> oh I've seen this thing before
[19:57] <wm4> someone complained that it wasn't correctly clipped
[19:57] <wm4> but I forgot about it
[19:57] <kepstin-laptop> yeah, that's just the example I happened to have handy
[19:57] <kepstin-laptop> wm4: that image was done with mplayer's libass rendering on the opengl video output.
[19:58] <wm4> same issue
[19:58] <wm4> I _think_ libass should be clipping the drawing to the margins
[19:59] <Guest50004> pross: did you see "the code"? a tv series in your area (I think). apparently ffmpeg makes an appearance (or maybe it's not our ffmpeg?)
[20:05] <ubitux> so, fieldmatch doesn't seem to like progressive content at all
[20:05] <ubitux> or, i mean, switch between the two
[20:36] <llogan> is anyone getting autoresponder messages from a ffmpeg-user ML subscriber as very recently complained by Reindl H. in same ML?
[20:40] <ubitux> nope
[20:41] <llogan> i guess i'd have to reply to something to test
[21:00] <wm4> michaelni: dalias (from musl, you might also know him from mplayer times) has said you can ask him anything about feature test macros and what exactly to do, in order to resolve the confusion
[21:01] <nevcairiel> the musl people are idealists though, the real world doesnt function like that
[21:02] <wm4> they also know how the real world works, though
[21:02] <michaelni> wm4, i know dalias but this is really not my patch
[21:03] <michaelni> Jörg Krause is the author of that (and other musl) patches
[21:04] <michaelni> i just reverted it after it broke almost all bsds
[21:04] <wm4> oh well I guess that guy will try ask on the musl ML again if he needs more advice
[21:04] <wm4> +to
[21:05] <michaelni> yes, hopefully
[21:05] <michaelni> also ive no musl setup here so iam really not the right one to work on this
[21:14] <cone-636> ffmpeg.git 03Nicholas Robbins 07master:c7d21dee2856: libavcodec/dvdsubdec: Add option forced_subs_only to only decode forced subtitle frames.
[21:48] <mjuszczak> Are there ffmpeg 2.x packages for Ubuntu 14.04?  The PPA only goes up to 1.2.x.  Looking to find something that has this bug resolved: https://trac.ffmpeg.org/ticket/1918
[21:48] <JEEBcz> no packages most probably since most packages are just trying to be a replacement for the libav installed, including the libraries
[21:48] <JEEBcz> and 1.2.x is IIRC the last thing with a similar API to libav 9
[21:53] <mjuszczak> I know we talked about this earlier.  So is it better to just move to libav at this point...? 
[21:53] <BtbN> no?
[21:53] <BtbN> You just can't libav with a binary incompatible ffmpeg, that would break half the system
[21:53] <BtbN> so it's a compatible ffmpeg version, which turns out to be 1.2
[21:54] <BtbN> just be happy you're not on 13.10 or earlier, it's ffmpeg 0.10 there.
[21:54] <wm4> I've came across this PPA: https://launchpad.net/~mc3man/+archive/ubuntu/trusty-media
[21:55] <mjuszczak> My issue is: right now we're running ffmpeg 1.2 on Ubuntu 14.04 using the ffmpeg PPA (jon-severinnson). Because of that bug above (we think), we need to move to 2.x - local tests of 2.x fix the bug.  Either that or libav but even then we aren't sure if libav 9.x has the bug fixed.
[21:55] <ubitux> debian has packaged 2.4 in experimental, i suppose it won't take long before ubuntu follows
[21:55] <BtbN> Yeah, just a few more years
[21:55] <nevcairiel> ubuntu would inherit it if it moves into sid in debian
[21:55] <nevcairiel> if we're extremely lucky, maybe for 15.04, but probably not
[21:57] <ubitux> sid ` experimental?
[21:57] <ubitux> never remember.
[21:57] <wm4> sid is unstable
[21:58] <mjuszczak> I did find 2.3.x packaged here for trusty: https://launchpad.net/~archivematica/+archive/ubuntu/externals
[21:58] <wm4> 2.3 is now unmaintained
[21:58] <wm4> because no distro used it
[22:04] <mjuszczak> wm4: So the mc3man PPA might be a better bet?
[22:04] <wm4> possibly
[22:04] <wm4> 2.3 was dropped because no distro uses it
[22:05] <jamrial> 2.3 is api compatible with 2.2 (which is api compatible with libav 10), so distros using any of the latter two should be able to use 2.3 without any issue
[22:05] <jamrial> maybe we shouldn't be so hasty with calling it unmaintained
[22:05] <wm4> michaelni: 2.3 is discontinued, right?
[22:05] <wm4> jamrial: 2.4 should be API compatible with 2.3 (mostly)
[22:06] <wm4> just like libav 11 is mostly API compatible with libav 10
[22:06] <jamrial> quite a few things were dropped, so not really
[22:06] <jamrial> that didn't happen with 2.2 -> 2.3
[22:06] <jamrial> http://upstream-tracker.org/compat_reports/ffmpeg/2.2.8_to_2.3/src_compat_report.html
[22:06] <michaelni> 2.3 doesnt have a volunteer to maintain it, but ill very likely backport stuff anyway for a while when its easy or critical 
[22:09] <wm4> jamrial: no removed symbols?
[22:10] <jamrial> no. just a bunch added as you can see in that link
[22:10] <nevcairiel> his complaing was about the red in this one: http://upstream-tracker.org/compat_reports/ffmpeg/2.3.3_to_2.4/src_compat_report.html
[22:10] <wm4> ah I didn't read the link
[22:10] <jamrial> whereas 2.3 -> 2.4 removed quite a few
[22:11] <wm4> not that bad
[22:11] <wm4> mostly things that were deprecated ages ago
[22:12] <wm4> but yeah might break some things
[22:13] <mjuszczak> Is there an easy way to figure out what version of ffmpeg has this fix? https://trac.ffmpeg.org/ticket/1918  -- the earliest version?
[22:13] <nevcairiel> it doesnt even mention in w hich change it was fixed, so .. no
[22:13] <michaelni> wm4,  posted a slightly changed fix for musl support
[22:14] <mjuszczak> nevcairiel: okay, thanks.
[22:16] <jamrial> mjuszczak: earliest version with that fix seems to be ffmpeg 1.0
[22:16] <mjuszczak> jamrial: thank you!
[22:17] <mjuszczak> weird then that we're running 1.2 and encountering a bug but 2.x fixes it - perhaps I'm looking at the wrong one.
[22:17] <mjuszczak> I'll keep researching
[22:17] <jamrial> commit 6f77122bf5712da1d860a0ad7174181fd0bcffd9 mentions that ticket
[22:17] <mjuszczak> Awesome - thank you
[22:17] <wm4> sigh, mp3 seeking is so broken
[22:18] <wm4> adding some sort of full scanning/indexing pass to utils.c would probably easier than trying to fix it
[23:45] <cone-636> ffmpeg.git 03Nicholas Robbins 07master:bdb7f0866683: doc/decoders: adding documentation for lavc/dvdsubdec.c option "forced_subs_only"
[00:00] --- Tue Sep 23 2014