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

[burek]

[04:35:01 CEST] <cone-095> ffmpeg 03Michael Niedermayer 07master:b24fffeb9476: avcodec/utils: Move avctx->codec check before its use
[09:45:50 CEST] <alexyecu> Well, looks like my question should be asked at libav-user, but that channel is empty atm. Sorry for possible off-topic. The question:
[09:45:55 CEST] <alexyecu> Is there any possibility now to create mpegts receiver with dynamic port and get it's port from it after?
[09:46:01 CEST] <alexyecu> avformat_open_input waits until some data will be readed from it, but I need to get opened port and send it to sender side, without it no input will be available.
[09:46:07 CEST] <alexyecu> So I need to open input before any reading, get dynamically allocated port from it, send it to output site, and, after all of that, read input and other usual stuff
[09:53:22 CEST] <cone-239> ffmpeg 03Paul B Mahol 07master:8b5941ce5954: doc/filters: fix order of tinterlace filter drop modes
[09:55:01 CEST] <JEEB> alexyecu: libav-user(s?) is a mailing list, the non internal development discussion is on #ffmpeg on IRC
[09:56:09 CEST] <alexyecu> JEEB, thanx
[16:59:38 CEST] <durandal_1707> pfelt: Did you bumped thread 3 times?
[17:14:57 CEST] <pfelt> i saw that i bumped the same one twice
[17:15:05 CEST] <pfelt> did i screw up and bump it again
[17:15:23 CEST] <pfelt> yeah.  so two bumps were the same patch (because i'm an idiot)
[17:15:28 CEST] <pfelt> the other bump should be a different patch
[17:22:25 CEST] <pfelt> (they have similar titles in the subject)
[17:22:55 CEST] Action: pfelt steps away for a bit.  bbl
[17:24:56 CEST] <michaelni> BBB, coverity found some issues in colorspacedsp_template.c, i think tehy are false positive but didnt look closely
[17:25:04 CEST] <BBB> link?
[17:27:10 CEST] <michaelni> not sure this works: https://scan5.coverity.com/reports.htm#v13076/p10109/fileInstanceId=93212030&defectInstanceId=27068970&mergedDefectId=1361941
[17:27:30 CEST] <michaelni> CIDs are 1361941 2 3
[17:30:41 CEST] <BBB> they are all intentional
[17:30:42 CEST] <michaelni> atomnuker, coverty found something in  aacpsy.c CID 1361962 https://scan5.coverity.com/reports.htm#v13076/p10109/fileInstanceId=93212446&defectInstanceId=27069330&mergedDefectId=1361962
[17:30:56 CEST] <michaelni> BBB thoght so, please close them
[17:30:58 CEST] <BBB> the code may be a little bit icky for newcomers, but its behaviour is intentional
[17:31:02 CEST] <BBB> how?
[17:31:10 CEST] <BBB> just false positive?
[17:31:18 CEST] <BBB> or intentional?
[17:31:19 CEST] <michaelni> yes or intentional
[17:31:34 CEST] <michaelni> that should get rid of them ni the next run
[17:31:43 CEST] <BBB> action: ignore?
[17:31:56 CEST] <BBB> or keep unspecified?
[17:32:50 CEST] <atomnuker> michaelni: I know, I'll try to fix them tommorrow but if I can't I'll have time after next wednesday
[17:33:04 CEST] <michaelni> BBB i think classifiation is enough  to make them disappear, other fields can eb anything
[17:33:16 CEST] <michaelni> atomnuker, ok thanks
[17:33:21 CEST] <BBB> ok should all be gone
[17:33:27 CEST] <michaelni> thx
[17:33:58 CEST] <BBB> it still says 50 outstanding in the user interface
[17:34:06 CEST] <BBB> I hope I didnt screw up
[17:34:59 CEST] <michaelni> i dont know what it updates (maybe once a day or only when coverity is rerun on new source)
[17:35:07 CEST] <michaelni> s/what/when/
[18:46:39 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vrzly
[18:46:39 CEST] <KGB> 13FFV1/06master 140dbf0e7 15Jérôme Martinez: Slice header members restrictions...
[19:13:00 CEST] <cone-404> ffmpeg 03foo86 07master:e0706e9cc8f3: avcodec/dca: remove Rice code length limit
[19:24:23 CEST] <pfelt> greatest of mornings everyone! :)
[19:34:07 CEST] <cone-404> ffmpeg 03Michael Niedermayer 07master:b50bd6951689: avutil/eval-test: Check av_expr_parse_and_eval() for failure and also check it in the fate test
[19:40:24 CEST] <kurosu> is there a documentation on the steps for performing a merge from libav? (the merge commit+actual commit thing) 
[19:42:17 CEST] <jamrial> kurosu: nevcairiel and michaelni know how
[19:42:29 CEST] <jamrial> it's handled with a script afaik
[19:59:58 CEST] <cone-404> ffmpeg 03foo86 07master:b5cda2303911: avcodec/dca: remove useless debug message
[20:13:44 CEST] <cone-404> ffmpeg 03foo86 07master:39f7620d76c7: avcodec/dca: don't set initial sample_fmt
[20:18:20 CEST] <kurosu> I'm not volunteering at all, but while I still can (which may not last), I want to make my bitstream work useful for merge
[20:21:06 CEST] <BtbN> I think stuff has to be merged in order, otherwise everything explodes.
[20:21:30 CEST] <BtbN> So merging only a few selected commits isn't easily possible. Cherry-Pick them instead.
[20:23:22 CEST] <wbs> just fwiw, the openh264 patch that somebody just sent, for fixing compilation with 1.6 (which is not released) is just awful. it changes defaults for lots of options, it changes names for options, etc, all in one single patch (which breaks compilation with any earlier version)
[20:23:47 CEST] <wbs> if one wants to add support for 1.6, it shouldn't break support for earlier versions. and 1.6 isn't released, so the actual api for that version may still change
[20:24:06 CEST] <wbs> so I would just tell people to stick it and not try to "support" an unreleased version which is still open for changes
[20:28:04 CEST] <kurosu> BtbN, ok, cherry-pick is what I've down, but that includes resolving the conflicts & actually doing the porting for code not from libav
[20:28:41 CEST] <BtbN> So you think the merged do that automatically?
[20:28:44 CEST] <BtbN> *merges
[20:29:26 CEST] <BtbN> I'm not sure what you're up to, but merging/picking code from libav allways involves quite a bit of manual fixing.
[20:30:39 CEST] <kurosu> BtbN, no I don't think it does this automatically, just that it is non-trivial merges, but that already happens
[20:31:34 CEST] <kurosu> sometimes, the authorship on those merges is somewhat a grey area, because of the new code being ported
[20:32:06 CEST] <kurosu> as for the context, when the new bitstream api was being discussed, I cherry-picked it to validate it outside of libav on decoders I had worked on
[20:32:23 CEST] <kurosu> trying to validate the api performance-wise, and getting used to it
[20:33:03 CEST] <kurosu> as I did it for a few decoders, it would be useful to reuse that work for an actual merge
[21:00:58 CEST] <durandal_1707> the new bitstream api can live with old one
[21:01:36 CEST] <iive> kurosu: have you benchmarked the new bitstream on 32 bit system?
[21:06:29 CEST] <durandal_1707> iive: 32 is dead
[21:15:33 CEST] <nevcairiel> kurosu: when that is pushed and we get to the point merging that, i'll try to remember
[21:15:49 CEST] <nevcairiel> but as durandal_1707 said, its certainly possibly to just delay deletion of the old one until all our components can be updated
[21:16:00 CEST] <nevcairiel> for once its a thing that may not need a big monolithic merge
[21:16:13 CEST] <nevcairiel> (although i'm sure they'll s till push it as such for reasons)
[21:27:54 CEST] <kurosu> nevcairiel, in my branch, I've did what I said they should do, ie have 2 independant implementations
[21:28:15 CEST] <kurosu> in case the new bitstream reader would have been slower
[21:28:26 CEST] <kurosu> its only drawback is generated code size
[21:28:54 CEST] <kurosu> iive, not on many codecs, but for the most sensitive ones it was still a win
[21:29:52 CEST] <kurosu> and the large win on 64b system should not preclude 32b systems from making the majority loose
[21:30:07 CEST] <kurosu> *should preclude
[21:33:37 CEST] <kurosu> durandal_1707, not completely, the golomb part (and I suppose derivative like unary etc) is made to be committed in one go, replacing immediately the old one
[21:34:13 CEST] <kurosu> I move the new golomb code to a new file so that it lives independently
[21:34:18 CEST] <kurosu> but not unary & co
[21:36:54 CEST] <BBB> so the 64bit reader is largely faster because the default state buffer is 64bit instead of current 32bit right?
[21:37:11 CEST] <BBB> if we move our current bitstream reader to have a 64bit state, do we get all the gains without the rewrite?
[21:40:47 CEST] Action: michaelni wonders why 2 out of 3 bitreader implementations where droped years ago and now the one choosen is replaced instead of having just added it into the system existing long ago
[21:41:52 CEST] <michaelni> would seem more flexible, one could choose whatever is best for a hw and decoder
[21:42:07 CEST] <BBB> we shouldnt have N implementations
[21:42:13 CEST] <BBB> we should have 1, which is always best
[21:42:18 CEST] <michaelni> yes
[21:42:38 CEST] <michaelni> is the new one always best ? 
[21:45:43 CEST] <durandal_1707> michaelni: what was different?
[21:45:47 CEST] <cone-404> ffmpeg 03foo86 07master:a0349ae27c12: avcodec/dca_parser: improve frame end search
[21:46:32 CEST] <iive> i think one of the old implementations was with static buffer, like the new bitstream one.
[21:52:38 CEST] <kurosu> those all were comments I made, but they went up being "forgotten" - I guess nobody want to invest the time checking it
[21:54:15 CEST] <kurosu> https://lists.libav.org/pipermail/libav-devel/2016-May/076532.html
[21:54:47 CEST] <kurosu> (first quote)
[21:56:34 CEST] <kurosu> michaelni, the numbers show it is faster for x86_32, x86_64 and a particular arm system
[21:56:54 CEST] <kurosu> but there must be a point where it isn't, because of the increased code size
[21:59:54 CEST] <kurosu> https://lists.libav.org/pipermail/libav-devel/2016-April/076455.html <- total is around 5% size increase for the final binary
[22:00:19 CEST] <iive> kurosu: i'd like to see some numbers, if you have any. (and no, it is not urgent).
[22:01:11 CEST] <kurosu> iive, frankly I have spent a lot of time, go check my posts on libav archives, or better, spend the time yourself and thus provide another operating point
[22:01:48 CEST] <kurosu> my own conclusion is the implementation is worth investigating
[22:01:52 CEST] <iive> kurosu: i haven't found any benchmark numbers for 32bit or arm systems on the list.
[22:02:19 CEST] <kurosu> now, maybe something less painful would be what BBB suggests, but who is going to do it?
[22:02:57 CEST] <kurosu> iive, I do remember arm numbers
[22:02:59 CEST] <kurosu> for h264, for sure, and maybe dnxhd, I don't remember
[22:03:49 CEST] <iive> i thought that h264 uses mostly cabac/cavlc that is ... separate than this bitstream reader.
[22:03:52 CEST] <michaelni> btw was h264 cabac or cavlc ?
[22:03:55 CEST] <kurosu> for 32b systems, I did, I just haven't published the number
[22:04:13 CEST] <nevcairiel> michaelni: we intentionally asked them to test cavlc because cabac uses its own bitreader
[22:04:23 CEST] <kurosu> I suspect indeed it's a case where bitstream reader outside of cabac doesn't mater
[22:04:24 CEST] <nevcairiel> i dont remember if they did
[22:04:29 CEST] <kurosu> they didn't
[22:04:30 CEST] <michaelni> nevcairiel, ok then,
[22:04:38 CEST] <kurosu> they ran dnxhd and another high bitrate codec
[22:04:47 CEST] <kurosu> I ran huffyuv, dnxhd, prores, vc2
[22:04:55 CEST] <kurosu> around 5% gain on x86_64
[22:05:07 CEST] <kurosu> iirc, dnxhd was 2% gain on x86_32
[22:05:25 CEST] <michaelni> nevcairiel, actually not ok if they didnt, my reply was lagging a moment
[22:05:27 CEST] <BBB> if 32bit wins also, I think its all fine
[22:06:33 CEST] <iive> that's exactly why I want some 32bit benchmark numbers.
[22:06:45 CEST] <kurosu> frankly, I'm a single operating point, if people care, I'd very much welcome they provide other operating points
[22:07:30 CEST] <kurosu> https://github.com/kurosu/ffmpeg/tree/gb <- fresh from maybe 1h ago
[22:08:47 CEST] <kurosu> older patches though, the names of the new API functions have changed since then, but that's just s/old/new
[22:41:15 CEST] <durandal_1707> nobody left to do merges? What should be done now?
[22:54:03 CEST] <BBB> you could beg michaelni or nevcariel to do it again
[22:56:45 CEST] <durandal_1707> and you are perfect candidate?
[22:57:39 CEST] <pfelt> out of curiosity, how many merges are we looking at?  (1000s or 10s)
[22:58:34 CEST] <durandal_1707> Less than 100 I guess
[22:59:15 CEST] <durandal_1707> I can do cheery picks
[22:59:38 CEST] <durandal_1707> but those hw stuff I can't test
[23:03:30 CEST] <ubitux> 124
[23:19:15 CEST] <BBB> is alexandra (author of that bitstream reader patch) on irc?
[23:19:25 CEST] <JEEB> yeah
[23:19:35 CEST] <JEEB> sasshka
[23:19:43 CEST] <BBB> not in this channel I suppose
[23:20:07 CEST] <JEEB> seems so
[00:00:00 CEST] --- Sat May 21 2016