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

[burek]

[00:12:50 CEST] <michaelni> durandal_1707, theres nothing in GSoCs web interface to pass students ATM that i know of, theres only a "ignore" and a "star" thing, neither is documented AFAIK
[00:27:40 CEST] <michaelni> iam just assuming that "star" means something like accept and "ignore" clearly means what it says and we use "ignore" for "spam"
[00:33:29 CEST] <durandal_1707> I can't add star
[02:34:25 CEST] <kierank> how do I mark someone as accept
[02:34:50 CEST] <kierank> star thing doesn't work
[13:34:16 CEST] <cone-314> ffmpeg 03Michael Niedermayer 07master:ee7a642b0e5d: avformat/mpegts: Check adaption field control in analyze() more instead of transport_error_indicator
[13:34:16 CEST] <cone-314> ffmpeg 03Michael Niedermayer 07master:38a6242b271f: avformat/mpegts: Remove unused argument from analyze()
[14:54:57 CEST] <gerion> hi, can somebody say what error number -541478725 mean?
[14:55:16 CEST] <gerion> if get this as return value of ff_request_frame in a filter
[14:56:04 CEST] <gerion> doc says only something about AVERROR(EOF) and AVERROR(EAGAIN) but none of this has the high number
[14:57:40 CEST] <gerion> btw the number seems to be unique to ffmpeg (the results from google are always ffmpeg related) :)
[14:59:08 CEST] <nevcairiel> that is AVERROR_EOF
[14:59:15 CEST] <nevcairiel> note that EOF uses AVERROR_EOF, not AVERROR(EOF)
[14:59:18 CEST] <nevcairiel> important difference
[14:59:45 CEST] <gerion> oh ok
[14:59:50 CEST] <gerion> i see, thx
[15:00:14 CEST] <jkqxz> Look at libavutil/error.h - the numbers are kinda hard to search.
[15:01:00 CEST] <kierank> I'm sorry that you are using lavfi from the api
[15:01:46 CEST] <gerion> jkqxz: the problem is the output with %d, but the doc says also AVERROR_EOF have not see it correctly
[15:02:44 CEST] <nevcairiel> dont we have a function to print you an error string
[15:07:07 CEST] <gerion> hmm now I undertand the error, problem is: my signature filter is multiinput, but input can have different length, the relevant function is request frame
[15:07:58 CEST] <gerion> for now i had:
[15:07:58 CEST] <gerion> iterate over all inputs {
[15:07:58 CEST] <gerion>     ret = ff_request_frame(ctx->inputs[i]);
[15:07:58 CEST] <gerion> }
[15:07:59 CEST] <gerion> return ret;
[15:08:08 CEST] <gerion> this only returns the last error code
[15:08:37 CEST] <gerion> but if I add "if (ret < 0) return ret;" in the for loop
[15:09:19 CEST] <gerion> the filter fails in calling filter_frame given you have a short input[0] video and a longer input[1] video
[15:09:56 CEST] <gerion> do you know a way to honor the return values without making the filter useless?
[15:10:55 CEST] <gerion> the reason the filter fails is that it return EOF for the first input and then return immediately
[15:12:29 CEST] <gerion> my solution would be something like recording the returnvalue for each input, if all inputs are EOF return EOF, if all inputs are 0 return 0, what should I do with AVERROR(EAGAIN)?
[15:23:54 CEST] <Daemon404> energized
[15:24:00 CEST] <Daemon404> see if i can fix that weird mkv thing
[15:24:15 CEST] <Daemon404> other than plan, i plan to merge today, i think
[15:24:31 CEST] <Daemon404> michaelni wm4 nevcairiel ubitux ^
[15:26:20 CEST] <wm4> sure
[15:28:38 CEST] <Daemon404> 11 hrs of sleep and 2 espresso later im pretty sure i can fix mkv
[15:29:08 CEST] Action: Daemon404 adds roughly 50 printfs to ffmpeg.c
[15:40:01 CEST] <cone-314> ffmpeg 03Carl Eugen Hoyos 07master:7e1e25c2dced: lavf/avio: Remove linebreak from https warning.
[15:46:45 CEST] <Daemon404> encoder <- type:video frame_pts:21 frame_pts_time:0.84 time_base:1/25 pkt_duration:3600
[15:46:48 CEST] <Daemon404> encoder -> type:video pkt_pts:21 pkt_pts_time:0.84 pkt_dts:21 pkt_dts_time:0.84 pkt_duration:0
[15:46:53 CEST] <Daemon404> so the encoder is nulling the pkt duration
[15:47:06 CEST] <Daemon404> O_o
[15:50:58 CEST] <rcombs> which encoder
[15:51:47 CEST] <Daemon404> mpeg4
[15:51:50 CEST] <Daemon404> and h264
[15:52:45 CEST] <Daemon404> apparently...
[15:52:45 CEST] <rcombs> not particularly surprising
[15:53:02 CEST] <rcombs> since they delay+reorder
[15:53:44 CEST] <Daemon404> it didnt happen pre-codecpar
[15:55:28 CEST] <rcombs> libx264.c doesn't appear to touch pkt_duration directly, so I'd imagine the value was automatically filled by lavc with the duration of the packet being passed in (i.e. not necessarily correct due to delay)?
[15:55:50 CEST] <rcombs> or was there some magic to find the right packet params out of a queue by pts?
[15:56:07 CEST] <Daemon404> i have no idea, looking into it further atm
[15:57:15 CEST] <Daemon404> hmm looks like it happens with old ffmpeg master too??
[15:57:28 CEST] <Daemon404> maybe ffmpeg.c re-sets it somewhere if (magic)
[15:57:55 CEST] <JEEB> wee
[15:58:32 CEST] <Daemon404> let's see what master has
[15:59:15 CEST] <Daemon404> hmmm so ffmpeg.c passes muxer 0 duration too!
[15:59:17 CEST] <Daemon404> in master
[15:59:26 CEST] <Daemon404> so wtf, the muxer used to make up some duration but no longer does?
[16:02:28 CEST] <Daemon404> also we have so many debug flags...
[16:02:42 CEST] <JEEB> like debugts?
[16:02:44 CEST] <Daemon404> -loglevel debug, -debugts, -debug (which does everything but ts) and -fdebug ts
[16:02:54 CEST] <Daemon404> they all do slightly different things
[16:02:56 CEST] <JEEB> yeah
[16:04:26 CEST] <rcombs> https://xkcd.com/927/ we need to develop one universal debug flag that covers everyone's use cases
[16:11:31 CEST] <Daemon404> while that xkcd is usually relevant, not in this case imo
[16:19:16 CEST] Action: rcombs shrugs
[16:19:41 CEST] <Daemon404> ok i figured it out... eugh
[16:27:39 CEST] <Daemon404> woo ... fixed it.
[16:27:43 CEST] <JEEB> \o/
[16:28:49 CEST] <Daemon404> just gotta run fate
[16:34:54 CEST] <nevcairiel> um Daemon404, are you sure about this
[16:34:56 CEST] <nevcairiel> if (!st->codec->time_base.num && st->codec->time_base.num) {
[16:35:00 CEST] <nevcairiel> this looks mighty wrong =p
[16:35:35 CEST] <nevcairiel> might as well delete the entire block
[16:36:41 CEST] <rcombs> kek
[16:36:49 CEST] <rcombs> nice unreachable
[16:39:25 CEST] <Daemon404> nevcairiel, revert it then
[16:39:30 CEST] <Daemon404> that wasnt my fix (which is unpushed)
[16:39:33 CEST] <Daemon404> i just happened to notice that
[16:39:41 CEST] <Daemon404> ill push a revetr
[16:39:57 CEST] <nevcairiel> oh well, i thought this was supposed to fix this
[16:40:06 CEST] <nevcairiel> which would've been some mad side effect
[16:40:06 CEST] <nevcairiel> :;D
[16:40:23 CEST] <Daemon404> lol
[16:40:40 CEST] <Daemon404> ill show my fix for the mkv thing once i pass fate
[16:40:42 CEST] <Daemon404> which i need to rerun
[16:40:54 CEST] <nevcairiel> wonder when this compat block can go though, should check dates when it was deprecated
[16:40:55 CEST] <Daemon404> because i bet teh new failrues were from the change i just revert
[16:41:16 CEST] <Daemon404> which would indicate that compat used still affects fate
[16:41:17 CEST] <nevcairiel> ffmpeg.c probably still uses it in some situations though
[16:41:19 CEST] <Daemon404> yeah
[16:41:38 CEST] <nevcairiel> i tried to read some of its processing flow earlier, but its just so confusing
[16:41:47 CEST] <nevcairiel> mixing AVStreams with its own stream objects and all sorts of weird properties
[16:42:33 CEST] <Daemon404> i spent over a week in this code, man
[16:42:37 CEST] <Daemon404> youre preaching to the choir
[16:42:44 CEST] <kierank> are there any ffv1 samples anywhere
[16:42:55 CEST] <Daemon404> kierank, ask dave rice? :P
[16:43:01 CEST] <kierank> small ones
[16:43:05 CEST] <kierank> for fuzzing
[16:44:26 CEST] <kierank> found one i think
[16:47:06 CEST] <Daemon404> i wish fate didnt have so many vsynth
[16:47:11 CEST] <Daemon404> takes forever to run
[16:47:14 CEST] <Daemon404> with each change
[16:47:23 CEST] <nevcairiel> i never thought vsynth was a slow part for me
[16:47:58 CEST] <Daemon404> looks like this fix also makes some of the old flv hashes match
[16:48:06 CEST] <nevcairiel> i wonder if i could make a sort of breakdown of how long the tests take individually and make some sort of stats
[16:48:07 CEST] <Daemon404> (they were different, but not wrong.)
[16:48:14 CEST] <Daemon404> (since the code i just fixed was for fixing wrong crap)
[16:49:06 CEST] <nevcairiel> matching old hashes is always nice
[16:50:02 CEST] <Daemon404> it still bothers me that we call teh compute pkt duration function in mux.c, but thats unrelated to this merge
[16:51:49 CEST] <nevcairiel> i wish we could reliably lock down git for a couple hours to get a final squashed and rebased version, give it a final read through for an hour without having to worry about rebasing it again later
[16:53:29 CEST] <Daemon404> its not much a problem if the changes are all unrelated
[16:53:42 CEST] <Daemon404> but i dunno how one would manage that with ffmpeg
[16:53:45 CEST] <nevcairiel> i dont even know how you rebase the merge, that was something i always had trouble with
[16:53:46 CEST] <Daemon404> locking, that is
[16:53:56 CEST] <Daemon404> i do it in an old-school way
[16:54:09 CEST] <Daemon404> git diff HEAD^..HEAD > merge.diff
[16:54:12 CEST] <nevcairiel> lol
[16:54:13 CEST] <Daemon404> git reset --hard HEAD^
[16:54:14 CEST] <Daemon404> git pull
[16:54:19 CEST] <Daemon404> git merge -s ours --log <hash>
[16:54:22 CEST] <nevcairiel> guess that works
[16:54:23 CEST] <Daemon404> patch -p1 < merge.diff
[16:54:28 CEST] <Daemon404> fix by hand
[16:54:29 CEST] <Daemon404> and amend
[16:54:36 CEST] <Daemon404> it made rebase this SO much easier
[16:54:40 CEST] <Daemon404> git itself does it so terribly
[16:54:40 CEST] <nevcairiel> there was like one new demuxer a day or so ago
[16:54:52 CEST] <nevcairiel> i still dont know why it cant just rebase the merge like any other commit
[16:54:53 CEST] <Daemon404> right
[16:54:55 CEST] <nevcairiel> why is that so hard
[16:55:05 CEST] <Daemon404> yeah i dunno
[16:56:26 CEST] <Daemon404> but yeah, i often find diff/patch easier to use taht git itself
[16:56:28 CEST] <Daemon404> i use them a *lot*
[16:56:31 CEST] <Daemon404> than*
[16:56:42 CEST] <nevcairiel> the only part i had such troubles with is merging for ffmpeg
[16:56:48 CEST] <nevcairiel> everything else i can do with git
[16:56:59 CEST] <Daemon404> merging in general, is like that
[16:57:04 CEST] <nevcairiel> and for the simple merges I just used git rerere
[16:57:14 CEST] <nevcairiel> but that doesnt work in such a huge merge
[16:57:15 CEST] <Daemon404> git rerere works... very weirdly
[16:57:23 CEST] <Daemon404> and cant handle ammends to a merge
[16:57:33 CEST] <Daemon404> itll use the old conflic resolutions
[16:57:39 CEST] <Daemon404> pre-amend
[16:57:43 CEST] <Daemon404> which sucks when fixign stuff
[16:57:50 CEST] <nevcairiel> hence simple merges
[16:58:06 CEST] <nevcairiel> it helps somewhat, but isnt the universal answer
[16:58:16 CEST] <Daemon404> it's also SLOW
[16:58:17 CEST] <Daemon404> for me anyway
[16:58:29 CEST] <nevcairiel> merging and rebasing got super fast in some recent git update
[16:58:37 CEST] <Daemon404> interesting
[16:58:41 CEST] <nevcairiel> was it 2.7
[16:58:43 CEST] <nevcairiel> maybe
[17:01:31 CEST] <Daemon404> ok pushed fix
[17:01:45 CEST] <Daemon404> only fate chanegs were making some old flv hashes match
[17:02:18 CEST] <Daemon404> shall i rebase on master now?
[17:02:24 CEST] <Daemon404> and push to a branch for final inspection?
[17:02:29 CEST] <nevcairiel> sure
[17:03:00 CEST] <nevcairiel> like i said a few demuxer changes in the last week that need adapting, but nothing too big
[17:03:26 CEST] <nevcairiel> also two new demuxers
[17:03:32 CEST] <nevcairiel> but trivial ones
[17:06:32 CEST] <Daemon404> yes
[17:06:36 CEST] <Daemon404> ill squash those in too
[17:06:38 CEST] <Daemon404> should be easy
[17:07:35 CEST] <nevcairiel> did someone ever update the lib* based demuxers, i dont think i checked
[17:08:00 CEST] <nevcairiel> looks like they are
[17:10:16 CEST] <Daemon404> nevcairiel, yes i did them
[17:10:41 CEST] <Daemon404> nevcairiel, yes fixing all the new changes was easy
[17:10:55 CEST] <Daemon404> make libavformat/libavformat.a and watch for new warnigns -> fix
[17:11:21 CEST] <nevcairiel> thats how i originally went through the files
[17:11:28 CEST] <nevcairiel> also why lib* stuff didnt get any love from me =p
[17:20:01 CEST] <Daemon404> good news: no fate failures after rebase
[17:20:40 CEST] <wm4> don't think, push
[17:20:57 CEST] <nevcairiel> did you push it to github=
[17:21:53 CEST] <Daemon404> i am doing this now
[17:24:19 CEST] <Daemon404> https://github.com/dwbuiten/FFmpeg/tree/codecpar_rebase_part_two
[17:27:40 CEST] <nevcairiel> do you want to push tonight then?
[17:27:48 CEST] <Daemon404> i would like to, yes.
[17:27:57 CEST] <nevcairiel> ok
[17:28:10 CEST] <nevcairiel> i'll scroll through the diff and see if i find something obvious left
[17:28:13 CEST] <Daemon404> ok
[17:28:19 CEST] <Daemon404> you cant on teh githbu ui though
[17:28:21 CEST] <Daemon404> it's too long 
[17:28:24 CEST] <Daemon404> A+ web ui
[17:28:48 CEST] <nevcairiel> yeah
[17:29:00 CEST] <nevcairiel> and if you try to use the .patch url, you get the original commit from anton for some reason
[17:29:06 CEST] <Daemon404> wtf?
[17:29:15 CEST] <nevcairiel> i used the .diff url now to download a full diff
[17:29:24 CEST] <Daemon404> that's just so odd
[17:29:46 CEST] <Daemon404> ive always used .diff and .patch interchangeably
[17:29:48 CEST] <Daemon404> since everyone used both before git
[17:29:51 CEST] <Daemon404> for diff/patch
[17:30:07 CEST] <nevcairiel> diff is just an ordinary diff -u
[17:30:10 CEST] <nevcairiel> patch is weird
[17:30:17 CEST] <nevcairiel> it gives you a git-format-patch thing usually
[17:30:29 CEST] <kierank> ok, so what libs need removal?
[17:30:35 CEST] <Daemon404> yeah but thats a github-only distinction
[17:30:37 CEST] <nevcairiel> but if you try to use it say on a range of commits, it just concats the format-patches one after another
[17:30:44 CEST] <Daemon404> yes
[17:30:53 CEST] <nevcairiel> while diff gives you an overall diff
[17:30:53 CEST] <kierank> faac?
[17:31:10 CEST] <Daemon404> faac has no uses afaict
[17:31:54 CEST] <nevcairiel> AV_RB32(par->extradata+0); .. who writes stuff like that =p
[17:32:18 CEST] <Daemon404> thats not from us though
[17:32:22 CEST] <Daemon404> that was there pre-merge
[17:32:25 CEST] <nevcairiel> i know
[17:32:28 CEST] <nevcairiel> but still +0
[17:32:30 CEST] <Daemon404> yeah
[17:32:31 CEST] <Daemon404> i dunno
[17:34:05 CEST] <wm4> why not
[17:34:21 CEST] <wm4> might look nicer if there are other offsets
[17:34:46 CEST] <Daemon404> 'if'
[17:47:07 CEST] <wm4>    --enable-libflite        enable flite (voice synthesis) support via libflite [no]
[17:47:11 CEST] <wm4> we have such a thing?
[17:47:29 CEST] <wm4> lol it's a libavfilter source
[17:47:57 CEST] <JEEB> wow
[17:51:35 CEST] <JEEB> btw, was aacplus already removed?
[17:51:50 CEST] <JEEB> so that we would only have fdk-aac and the internal one
[17:53:02 CEST] <wm4> yes aacplus is removed
[17:54:26 CEST] <Daemon404> btw i cant wait for half of lavf to show my name in git blame after this merge
[17:54:50 CEST] Action: Daemon404 suspects a lot of blame will be aimed at him
[17:56:14 CEST] <JEEB> :D
[18:01:13 CEST] <wm4> git should totally have support for N author fields
[18:01:52 CEST] <Daemon404> iirc svn did
[18:01:53 CEST] <Daemon404> kinda
[18:25:57 CEST] <nevcairiel> anyone wanna place bets how long after push carl asks for revert?
[18:27:04 CEST] <Daemon404> 16:14 < Daemon404> wm4, do you want to start a pot on how long it takes for carl to demand a revert?
[18:27:07 CEST] <Daemon404> fro m2 or so days ago
[18:27:12 CEST] <Daemon404> ;)
[18:27:16 CEST] <nevcairiel> ahah
[18:27:20 CEST] <Daemon404> \
[18:29:07 CEST] <nevcairiel> there is q uite certainly still some hidden problems left somewhere, but thats expected of such a huge change
[18:30:08 CEST] <Daemon404> well yes
[18:30:22 CEST] <Daemon404> but what do you expect?
[18:30:22 CEST] <Daemon404> "write bug free code every time"?
[18:30:22 CEST] <wm4> of course
[18:30:38 CEST] <wm4> without doubt there will be some fallout
[18:30:59 CEST] <Daemon404> all directly aimed at me no doubt
[18:31:29 CEST] <nevcairiel> i never got angry mails for merged breakage, you must somehow attract that more
[18:31:57 CEST] <nevcairiel> btw there is still usage of st->codec in sdp speex code
[18:32:05 CEST] <nevcairiel> unfixable, too, no clue what to make of that
[18:32:28 CEST] <nevcairiel> it needs to know rather codec specific information
[18:33:17 CEST] <nevcairiel> anyway carl will be most upset about information loss in ffmpeg.c stream listings, like ref frame count, closed caption presence, etc
[18:33:30 CEST] <nevcairiel> because the auto-probing no longer exports that
[18:33:43 CEST] <wm4> yeah, we discussed the speex/sdp thing away
[18:34:02 CEST] <wm4> and the stream listings come from libavformat/dump.c
[18:34:14 CEST] <wm4> IMO it's a given that these can't be as detailed anymore
[18:34:25 CEST] <nevcairiel> did we ever do something about the flac bitdepth loss?
[18:34:30 CEST] <Daemon404> [17:31] <@nevcairiel> i never got angry mails for merged breakage, you must somehow attract that more <-- he doesnt like me, is why
[18:34:31 CEST] <wm4> what ffmpeg.c really should do is decode a frame for each stream
[18:34:41 CEST] <nevcairiel> i personally would miss that as well, really
[18:34:57 CEST] <Daemon404> nevcairiel, i changed it to use coded rather than raw
[18:35:01 CEST] <Daemon404> for flac it should still work
[18:35:11 CEST] <nevcairiel> changed where
[18:35:17 CEST] <nevcairiel> in the printout?
[18:35:21 CEST] <Daemon404> the bit tou added in matroska*c
[18:35:25 CEST] <nevcairiel> oh that
[18:35:34 CEST] <wm4> that one wasn't entirely clear
[18:35:35 CEST] <Daemon404> oh the dump.
[18:35:48 CEST] <Daemon404> we can probably add codedd depth printout in dump
[18:36:06 CEST] <Daemon404> i personally blame the lack of a 24bit format
[18:36:22 CEST] <nevcairiel> yeah well that is to blame
[18:37:03 CEST] <Daemon404> i more or less never use dump.c stuff
[18:37:03 CEST] <Daemon404> i use ffprobe like a sane person to get info
[18:37:06 CEST] <nevcairiel> i used that info myself in the demuxer to export that part of the stream information
[18:37:29 CEST] <nevcairiel> guess i'll see how to poke that when i update to codecpar
[19:25:44 CEST] <cone-277> ffmpeg 03Martin Vignali 07master:2dd7b46132e2: avcodec/exr: fix channel detection
[19:53:05 CEST] <cone-277> ffmpeg 03Martin Vignali 07master:b45d542ea625: fate/exr : add test for PXR24 Float and tile uncompress
[19:55:07 CEST] <cone-277> ffmpeg 03Paul B Mahol 07master:571aa7d25edc: avcodec/shorten: mark as AV_CODEC_CAP_SUBFRAMES
[19:56:46 CEST] <Daemon404> atomnuker, any way to make the native encoder faster/worse?
[19:56:56 CEST] <Daemon404> seems like the reason we cant remove faac is due to speed
[19:56:58 CEST] <nevcairiel> use the fast coder
[19:57:05 CEST] <nevcairiel> its absolutely terrible
[19:57:12 CEST] <Daemon404> worse or better than faac though
[19:57:16 CEST] <atomnuker> well the fast coder doesn't do rate control
[19:57:32 CEST] <Daemon404> lol ic
[19:57:46 CEST] <atomnuker> so the bitrate's going to be stuck at 400kbps ish
[19:58:00 CEST] <atomnuker> also it's not particularly faster than twoloop
[19:58:06 CEST] <Daemon404> i mean
[19:58:08 CEST] <Daemon404> the example he gave
[19:58:14 CEST] <Daemon404> the internal aac encoder is still 25-30x realtime
[19:58:21 CEST] <Daemon404> so personally i wouldnt even give a shit
[19:58:24 CEST] <JEEB> lol
[19:58:24 CEST] <atomnuker> I thought we got rid of faac a long time ago
[19:58:28 CEST] <JEEB> nah
[19:58:38 CEST] <JEEB> aacplus was the one that was dropped first
[19:59:55 CEST] <wm4> Daemon404: but what about all those people who use an i386 as streaming server?
[20:00:43 CEST] <Daemon404> it still proabbly faster than realtime
[20:00:52 CEST] <Daemon404> my phone can probably do faster than real time N times over
[20:01:41 CEST] <atomnuker> faac is unstable, hasn't had any work done on it at all in who knows how many years, misses a ton of features, IIRC some decoder complain about its bitstream, etc
[20:02:03 CEST] <Daemon404> reply as such
[20:02:10 CEST] <Daemon404> nothing happens if you omly say it on irc
[20:02:18 CEST] <atomnuker> was
[20:02:19 CEST] <JEEB> yeah
[20:02:31 CEST] <Daemon404> "it's fast because it's bad" afaict
[20:02:32 CEST] <Daemon404> ;)
[20:02:53 CEST] <Daemon404> our internal aac encoder about matches fdk's speed fwiw
[20:27:14 CEST] <Daemon404> lol that wma 'support'
[20:27:27 CEST] <Daemon404> ive had to add hacks at work so ffmpeg doesnt try and use the 'decoder'
[20:27:42 CEST] <Daemon404> (failing is better than weirdly silent audio)
[21:01:58 CEST] <Daemon404> nevcairiel, how goes merge reading
[21:02:38 CEST] <nevcairiel> nothing crazy so far
[21:02:55 CEST] <Daemon404> \o/
[21:37:57 CEST] <cone-277> ffmpeg 03Jakub Stachowski 07master:60b75186b2c8: avcodec/wmalosslessdec: do not discard last frame
[21:51:03 CEST] <durandal_1707> if codecpar doesn't happen I will start cherry picking interesting commits from libav
[21:52:34 CEST] <JEEB> it's pretty much happening
[21:52:49 CEST] <JEEB> it was just rebased and should be merged soon unless nev finds some extra issues
[21:53:52 CEST] <nevcairiel> its probably fine as it is now if Daemon404 wants to merge, always things we have to fix over the next week
[21:56:35 CEST] <Daemon404> \o/
[21:56:54 CEST] <Daemon404> shall i?
[21:57:01 CEST] <Daemon404> after a fate run 
[21:57:33 CEST] <durandal_1707> after Carl goes to sleep :p
[21:58:06 CEST] <Daemon404> heh
[22:00:06 CEST] <durandal_1707> oh he is here
[22:01:28 CEST] <Daemon404> dont deliberately goad someone, only bad things happen
[22:06:03 CEST] <JEEB> oh kierank finally brought up the fact that faac is nonfree
[22:06:53 CEST] Action: Daemon404 is keeping distance from aac stuff 
[22:06:59 CEST] <Daemon404> 10-foot pole for me right now
[22:07:51 CEST] <JEEB> yeah, you have your own iä iä monster right now
[22:08:18 CEST] <atomnuker> I am hyping up for codecpar
[22:08:40 CEST] <JEEB> codecpar is mai waifu
[22:09:27 CEST] <durandal_1707> codecpar is cosmetics, sorry
[22:10:20 CEST] <JEEB> durandal_1707: cosmetics that found quite a few WTFs inside the libraries as far as I can tell
[22:10:22 CEST] <Daemon404> it really isnt
[22:10:37 CEST] <Daemon404> fate passes, as expected
[22:10:42 CEST] <Daemon404> nevcairiel, thundbirds are ago?
[22:10:43 CEST] <Daemon404> a go*
[22:11:54 CEST] <durandal_1707> but we want to unite all libs, not to split them properly
[22:12:09 CEST] <Daemon404> "we" = you and nicholas
[22:12:23 CEST] <durandal_1707> Lol
[22:20:38 CEST] <JEEB> durandal_1707: also people are already uniting them anyways if they really want to. just look at those tutorials creating libffmpeg.so|a!
[22:21:21 CEST] <wm4> even merging all libs would be better than the current situation
[22:21:32 CEST] <nevcairiel> Daemon404: fine with me
[22:22:47 CEST] <cone-277> ffmpeg 03Anton Khirnov 07master:9200514ad871: lavf: replace AVStream.codec with AVStream.codecpar
[22:22:48 CEST] <cone-277> ffmpeg 03Derek Buitenhuis 07master:6f69f7a8bf6a: Merge commit '9200514ad8717c63f82101dc394f4378854325bf'
[22:23:00 CEST] Action: Daemon404 ducks for cover
[22:23:23 CEST] <wm4> the evil has infected ffmpeg!
[22:25:22 CEST] <Daemon404> harr ahrr funny
[22:25:46 CEST] <JEEB> wohoo!
[22:26:30 CEST] <durandal_1707> src_movie and vf_subtitles are not ported?
[22:27:06 CEST] <Daemon404> only lavf has at the moment, otehr bits get ported in further merges
[22:27:08 CEST] <Daemon404> or by you
[22:27:18 CEST] <Daemon404> the lavf part was by far the hard part
[22:28:48 CEST] <atomnuker>  362 files changed, 6555 insertions(+), 6079 deletions(-)
[22:29:08 CEST] <Daemon404> ... and the next commit to merge is a no-op.
[22:30:46 CEST] <cone-277> ffmpeg 03Anton Khirnov 07master:5b9cdf8cba11: avconv: switch opening decoders and encoders
[22:30:47 CEST] <cone-277> ffmpeg 03Derek Buitenhuis 07master:6372c9dc9972: Merge commit '5b9cdf8cba114c41239bf0f9f5e0ccb6977d1c8d'
[22:31:29 CEST] <Daemon404> durandal_1707, 1138eb5509d3db7f6d565cb45f137a786d22beb9
[22:31:37 CEST] <Daemon404> a few merges away, converts vsrc_movie
[22:31:44 CEST] <Daemon404> theirs is probably different than ours though
[22:32:04 CEST] <Daemon404> but im not going to merge more today.
[22:32:48 CEST] <Daemon404> wm4, nevcairiel btw we want to no-op the avconv change to codecpar right? so we can do it ourselves.
[22:32:59 CEST] <nevcairiel> didnt you just do that :D
[22:33:04 CEST] <Daemon404> no
[22:33:12 CEST] <Daemon404> that was a different commit that was actually a no-op
[22:33:24 CEST] <Daemon404> i explained in the merge commit msg
[22:34:05 CEST] <Daemon404> nevcairiel, same for avplay right?
[22:34:24 CEST] <nevcairiel> probably
[22:36:11 CEST] <nevcairiel> merging changes in either of those is rather painful since git has is sues with the rename
[22:36:24 CEST] <Daemon404> you can force git to pick up the rename manually
[22:37:33 CEST] <Daemon404> regardless i think it is better to do it manually
[22:37:44 CEST] <Daemon404> with guidance from the original commit where necessary
[22:38:07 CEST] <wm4> indeed probably better
[22:38:39 CEST] <nevcairiel> both also diverged quite a bit
[22:50:10 CEST] <cone-277> ffmpeg 03Anton Khirnov 07master:15e84ed3f141: avconv: convert to codecpar
[22:50:11 CEST] <cone-277> ffmpeg 03Anton Khirnov 07master:0705f5960c9d: avplay: do not use AVStream.codec for decoding
[22:50:12 CEST] <cone-277> ffmpeg 03Anton Khirnov 07master:c23152a90371: avplay: convert do codecpar
[22:50:13 CEST] <cone-277> ffmpeg 03Derek Buitenhuis 07master:bbf5ef9dac94: Merge commit '15e84ed3f141c586e8cb78ed58365cf5a511108a'
[22:50:14 CEST] <cone-277> ffmpeg 03Derek Buitenhuis 07master:bc91bc1d8b2b: Merge commit '0705f5960c9d272cef1309c090000865b991c9c7'
[22:50:15 CEST] <cone-277> ffmpeg 03Derek Buitenhuis 07master:972df59f4f4d: Merge commit 'c23152a90371bfe971b063781ef4e7d9d5ef9d70'
[22:50:34 CEST] <Daemon404> interestingly, ffplay already was converted not to use st->codec.
[22:50:35 CEST] <Daemon404> in 2013.
[22:50:50 CEST] <wm4> eh
[22:50:59 CEST] <nevcairiel> half the work!
[22:51:17 CEST] <Daemon404> wm4, for decodingh
[22:51:25 CEST] <jamrial> ffplay also has a maintainer, unlike ffserver
[22:51:31 CEST] <Daemon404> yea
[22:54:13 CEST] <Daemon404> ok all the no-ops are done
[22:54:22 CEST] <Daemon404> yoru regularily scheduled merging will resume tomorrow.
[22:59:58 CEST] <Daemon404> jamrial, i sent an email to ffplay's maintainer to see if he wants to work on it, or not
[23:00:12 CEST] <nevcairiel> ffplay should be relatively simple i would think
[23:00:23 CEST] <Daemon404> he already did the hard work
[23:00:30 CEST] <Daemon404> by converting it to use a generic decoder
[23:00:41 CEST] <Daemon404> the hard part for me is testing since there are no unit tests
[23:00:47 CEST] <Daemon404> and SDL is a PITA
[23:00:47 CEST] <Daemon404> :P
[23:00:59 CEST] <nevcairiel> SDL parts shouldnt need touching
[23:01:12 CEST] <Daemon404> no i mean installing it on windows and trying there
[23:01:15 CEST] <nevcairiel> oh
[23:01:15 CEST] <atomnuker> wasn't there an SDL2 patch on the ML?
[23:01:17 CEST] <Daemon404> i usually do my ffmpeg dev work over ssh 
[23:01:19 CEST] <Daemon404> on linux
[23:01:45 CEST] <Daemon404> michaelni, i CC'd you on the mail
[23:32:38 CEST] <cone-277> ffmpeg 03James Almer 07master:5501f58e5278: fate: fix sample dependencies for fate-{a,v}filter tests
[00:00:00 CEST] --- Mon Apr 11 2016