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

[burek]

[00:00:09 CET] <jpabq_> RiCON: that might work...
[00:01:03 CET] <jpabq_> JEEB: does patchwork have a search feature?
[00:01:29 CET] <JEEB> jpabq_: click the "show patches with" text
[00:01:58 CET] <jpabq_> Thanks!
[04:13:24 CET] <jamrial> ubitux: "vex: the `impossible' happened: VEX temporary storage exhausted."
[04:13:39 CET] <jamrial> from your valgrind fate slot
[04:15:11 CET] <jamrial> i can reproduce it here as well
[05:14:58 CET] <cone-209> ffmpeg 03James Almer 07master:36eae4551043: fate/checkasm: use LOCAL_ALINGED_32 on hevc_add_res tests
[05:14:58 CET] <cone-209> ffmpeg 03James Almer 07master:09ce5519f3b4: fate/checkasm: fix use of uninitialized memory on hevc_add_res tests
[08:35:36 CET] <ubitux> /usr/lib/gcc/i686-pc-msdosdjgpp/6.1.0/../../../../i686-pc-msdosdjgpp/bin/as: libavcodec/vp9.o: /45: reloc overflow: 0x20b49 > 0xffff
[08:35:38 CET] <ubitux> :(((
[08:36:04 CET] <ubitux> it also refuses to compile a bunch of tables because align of 32 is too big :(
[10:44:45 CET] <j-b> JEEB: no there is no bounty for amarecco.
[10:44:53 CET] <j-b> JEEB: I have no idea what it is.
[10:52:34 CET] <wm4> ubitux: you're obviously trying to compile to 16 bit mode or something?
[11:04:17 CET] <JEEB> j-b: https://wiki.videolan.org/Bounties/#Libavcodec_features I just lulz'd at seeing "- AmaRecTV AMV2, AMV3, AMV4" there
[11:09:42 CET] <wm4> "500 ¬ To fix the issue that you cannot have MT hw decoding. "
[11:09:47 CET] <wm4> j-b: will you pay elenril?
[11:10:13 CET] <wm4> you're also free to pay me since I've ported this to ffmpeg against michaelni's resistance
[11:14:36 CET] <nevcairiel> This should've really been fixed in vlc, but what can you do,  someone badgered elenril into doing this =p
[11:15:05 CET] <wm4> it has the advantage that it works for ffmpeg.c
[11:15:11 CET] <wm4> which is why I wanted it
[11:20:33 CET] <wm4> as usual j-b never replies when it comes to bountied functionality that has been implemented by volunteers unaware of the bounty
[11:21:05 CET] <j-b> wm4: yes, we already discussed that with elenril
[11:21:13 CET] <wm4> hehe ok
[11:21:36 CET] <j-b> wm4: and as you might know, we usually pay elenril's travel&lodging to FOSDEM, at his requests.
[11:22:05 CET] <wm4> free travel for code
[11:22:30 CET] <j-b> wm4: so far, we've paid a few thousands ¬ on bounties
[11:22:37 CET] <j-b> wm4: we're not a company
[11:22:46 CET] <j-b> wm4: we don't have VC money
[11:22:54 CET] <j-b> I wish some other would do the same
[11:23:03 CET] <j-b> (and yes, I know, most of the bounties are too low)
[11:23:12 CET] <wm4> which companies
[11:24:02 CET] <j-b> do you really want names?
[11:24:37 CET] <j-b> JEEB: IIRC, those were suggested.
[11:24:46 CET] <j-b> JEEB: but if you have other suggestions, please share.
[11:24:58 CET] <wm4> j-b: I think it would be interesting
[11:25:19 CET] <j-b> wm4: ok, what about zencoder?
[11:25:53 CET] <wm4> never heard of them
[11:26:07 CET] <j-b> who explained to us (&other libavcodec devs) that one of their major codec issue was G2Mx and could not fork a couple of thousands of $ for it
[11:26:12 CET] <wm4> I mean there are going to be hundreds of companies which use ffmpeg and which won't even report simple bugs
[11:26:21 CET] <wm4> aha
[11:26:30 CET] <j-b> In the end, VideoLAN paid IIRC 2000¬ for that.
[11:26:47 CET] <wm4> why would videolan pay for something a company requested?
[11:26:53 CET] <j-b> and zencoder was ffmpeg+x264 rewrapped as SaaS
[11:27:11 CET] <wm4> time for AGPL?
[11:27:41 CET] <j-b> and they got bought by brightcove $30m
[11:27:48 CET] <j-b> and still could not make a fucking donation
[11:27:50 CET] <j-b> assholes.
[11:28:07 CET] <j-b> wm4: because VLC users were asking for this stupid codec.
[11:28:15 CET] <j-b> wm4: and because it helps everyone.
[11:28:19 CET] <thardin> agpl with an x264-style separate license is an approach I've considered proposing
[11:28:43 CET] <wm4> j-b: that's unfortunate
[11:28:57 CET] <wm4> in general ffmpeg is probably saving companies billions of dollars
[11:28:58 CET] <j-b> wm4: also, we've found money and gave money for other stuff, like some ARM asm on libavcodec and x264
[11:29:24 CET] <j-b> We're not perfect, and VLC is clearly not, but I found it's normal that we chip in too.
[11:29:36 CET] <wm4> did you pay the guy who wrote the DTS HD decoder?
[11:29:50 CET] <j-b> I don't remember what happened on that part, tbh
[11:29:57 CET] <j-b> but I can check in the archives, if you want.
[11:30:08 CET] <j-b> I think now our biggest bounty is MVC though
[11:30:10 CET] <wm4> I'd be very interested in that
[11:30:24 CET] <wm4> (what happened to the DTS guy in this respect)
[11:30:29 CET] <wm4> and people still want MVC? lol
[11:30:29 CET] <j-b> 11:20 <+wm4> as usual j-b never replies when it comes to bountied functionality that has been implemented by volunteers unaware of the bounty
[11:30:43 CET] <j-b> however, I found your quote quite disrespectful
[11:30:53 CET] <wm4> just based on past communication
[11:31:08 CET] <j-b> it's untrue
[11:31:09 CET] <wm4> it might have been an overly pessimistic assumption
[11:31:13 CET] <j-b> I usually always reply when I see it.
[11:31:31 CET] <j-b> but, yes, I'm not going to chase all developers when they implement something on this list
[11:31:38 CET] <j-b> when I don't even remember all of them
[11:31:54 CET] <j-b> However, lately, I've been pushing durandal_1707 quite a bit to send us an invoice
[11:32:03 CET] <j-b> on the last 2 codecs...
[11:32:12 CET] <j-b> let me look at it.
[11:32:13 CET] <wm4> durandal_1707: you don't like money?
[11:32:32 CET] <j-b> Was it Pixlet ?
[11:32:45 CET] <j-b> and I'm waiting for the second one, aka FMSCC
[11:33:00 CET] <j-b> wm4: some people want MVC, yes. Don't ask...
[11:33:03 CET] <wm4> anyway, I apologize for my trolling, but see, I got you to actually reply
[11:33:25 CET] <j-b> well, you know, this chan is on a non-highlight one for me
[11:33:25 CET] <wm4> j-b: I hear kodi got MVC somehow
[11:33:34 CET] <j-b> ah? ok
[11:33:37 CET] <JEEB> HW decoding?
[11:33:42 CET] <nevcairiel> they "borrowed" by code to use the intel decoding library
[11:33:48 CET] <j-b> I want SW decoding
[11:33:49 CET] <nevcairiel> s/by/my/
[11:33:50 CET] <wm4> per query I rarely get real replies either (though I didn't ask about this topic there)
[11:34:05 CET] <wm4> nevcairiel: figured it'd be something like this
[11:34:14 CET] <wm4> j-b: who still cares about sw decoding?
[11:34:17 CET] <j-b> wm4: so far, I'm on 60+ channels and have 600+ queries
[11:34:28 CET] <j-b> wm4: me.
[11:34:44 CET] <nevcairiel> the intel library has sw decoding, you just need to ship a blob =p
[11:34:48 CET] <j-b> brr
[11:34:53 CET] <wm4> didn't koda make some progress on this (this time "a" not "i")
[11:35:04 CET] <j-b> I think he did.
[11:35:17 CET] <nevcairiel> the decoding itself is probably not too hard, the real thing is frame and reference management
[11:35:31 CET] <wm4> yeah there were some API questions
[11:35:32 CET] <j-b> wm4: anyway, as once said, if you have good ideas about bounties on libavcodec/libav*, don't hesitate to suggest it.
[11:36:00 CET] <j-b> Sure, it's not perfect
[11:36:04 CET] <j-b> Sure, it's not enough
[11:36:09 CET] <j-b> but, it's something.
[11:37:19 CET] <nevcairiel> regarding MVC, you can basically just wait that out if you want to, TVs basically stopped supporting 3D, so its just a matter of time until its dead entirely :p
[11:37:31 CET] <j-b> nevcairiel: indeed :)
[11:37:36 CET] <JEEB> :D
[11:37:40 CET] <wm4> I wonder why TVs did that
[11:37:42 CET] <JEEB> yea, I noticed the trend
[11:37:46 CET] <wm4> maybe their developers went on strike
[11:37:50 CET] <j-b> IIRC, there was a bounty on DSD integration in vlc
[11:37:55 CET] <j-b> I don't see where it is now..
[11:38:11 CET] <wm4> j-b: well you were one of those who rejected a DSD samplefmt in libavutil trollol
[11:38:28 CET] <j-b> nevcairiel: yes, people just use SxS and TxB
[11:38:42 CET] <nevcairiel> j-b: that doesnt help if the tv itself is incapable of s howing 3d
[11:38:53 CET] <j-b> nevcairiel: sure, but then you can filter one side or the other
[11:39:05 CET] <j-b> wm4: sure, I believe libavutil has too many pixfmt and samplefmt
[11:39:09 CET] <j-b> wm4: does not mean I'm right.
[11:39:21 CET] <nevcairiel> samplefmts are probably fine
[11:39:24 CET] <wm4> I think koda's pixformaton was actually the right thing
[11:39:31 CET] <nevcairiel> in fact one might argue a S24 format might be useful
[11:39:34 CET] <wm4> fuck all those permutations that get added bit by bit
[11:39:37 CET] <nevcairiel> but pixfmts .. thats another mess
[11:39:54 CET] <wm4> but surely we could get rid of the obscure pixfmts
[11:40:14 CET] <wm4> e.g. remove AV_PIX_FMT_MONOBLACK or AV_PIX_FMT_MONOWHITE
[11:40:26 CET] <wm4> who the fuck uses AV_PIX_FMT_BGR4_BYTE
[11:40:28 CET] <j-b> I never understood why libavutil needs both 10L and 10B for every YUV formats
[11:40:29 CET] <wm4> etc.
[11:40:52 CET] <j-b> and never understood why it needed all bit depth and not just use 16, afte 10
[11:40:53 CET] <wm4> because it's faster to read different-endian from raw formats
[11:41:06 CET] <j-b> different-endian ?
[11:41:10 CET] <j-b> Does it still exist?
[11:41:27 CET] <wm4> I mean getting BE pixfmts on a LE machine because the actual data is BE on disk
[11:41:53 CET] <j-b> and last time I checked, there were pixfmt used only once or twice in libavcodec
[11:42:08 CET] <nevcairiel> thats definitely true
[11:42:08 CET] <j-b> but once again, that's my opinion, and I might be wrong
[11:42:24 CET] <j-b> also, I never understood the bayer ones
[11:42:48 CET] <wm4> yeah
[11:43:05 CET] <wm4> supposedly because camera hardware uses them
[11:43:28 CET] <j-b> So what?
[11:43:45 CET] <j-b> nevcairiel: do you know why there was never a S24 one?
[11:44:05 CET] <wm4> because it's 3 bytes this inefficient to process
[11:44:09 CET] <wm4> *thuas
[11:44:10 CET] <nevcairiel> because its inconvenient to process
[11:44:11 CET] <wm4> *thus
[11:44:36 CET] <j-b> wm4: as for DSD, I never really understood this format/need for this. But once again, I might be wrong.
[11:44:48 CET] <j-b> Can DSD get passthrough'd?
[11:44:58 CET] <adeel_>  /msg NickServ VERIFY REGISTER adeel_ ljlpvxxgmtzl
[11:45:26 CET] <j-b> oops :)
[11:45:46 CET] <adeel_> Yeah :D
[11:45:54 CET] <nevcairiel> j-b: yes through various USB DACs, through HDMI its rather tricky and generally unsupported
[11:45:56 CET] <adeel_> there was a trailing space
[11:46:11 CET] <wm4> nevcairiel: does that use spdif framing?
[11:46:17 CET] <nevcairiel> no
[11:46:22 CET] <wm4> makes sense
[11:46:39 CET] <wm4> j-b: as I understand, DSD must not be converted to PCM and back because that DESTROYS it
[11:46:39 CET] <nevcairiel> it has its own framing called DoP (DSD over PCM), and some a udio APIs even have a native DSD mode without framing
[11:46:41 CET] <j-b> on sdpif, only mp3/aac/dts/ac3, no?
[11:46:54 CET] <wm4> (and truehd/eac3)
[11:47:00 CET] <j-b> no
[11:47:09 CET] <j-b> truehd and eac3 only work on hdmi
[11:47:16 CET] <wm4> I'm calling both spdif
[11:47:31 CET] <wm4> (did I ever say fuck HDMI?)
[11:47:33 CET] <j-b> wm4: yeah, I read that too, but that does not compute (the destroys it part)
[11:47:42 CET] <j-b> wm4: maybe you said :)
[11:47:50 CET] <wm4> http://www.mojo-audio.com/blog/dsd-vs-pcm-myth-vs-truth/
[11:48:11 CET] <wm4> this also explains why DSD is idiotic audiophile nonsense
[11:48:28 CET] <nevcairiel> PCM cannot accurately represent DSD, and DSD cannot accurately represent PCM
[11:48:31 CET] <nevcairiel> so either conversion is lossy
[11:55:05 CET] <j-b> ok
[13:14:39 CET] <uau> michaelni: that pthread_frame failure you get seems quite weird - i tried that too and could not reproduce the problem
[13:14:59 CET] <wm4> I've sent a mail about that just now
[13:15:01 CET] <uau> the code in pthread_frame looks like it shouldn't return anything other than error or the whole avpacket size
[13:15:19 CET] <uau> and the valgrind output seems to list all uses of the "ret" variable as "uninitialized"?
[13:16:16 CET] <uau> that goto case?
[13:18:27 CET] <wm4> yes
[13:20:11 CET] <wm4> that's some pretty questionable code not in Libav, although it appeared to fix a real issue
[13:23:29 CET] <uau> wm4: the current form of that code is the result of your merge...
[13:24:47 CET] <uau> e0cd598bc4684 (merge of elenril's d4a91e65) changed it from "return err;" to "goto finish;"
[13:25:44 CET] <uau> apparently missing the case where err equals 0 but should still be returned
[13:26:16 CET] <wm4> I know
[13:45:53 CET] <ubitux> BBB: ping
[13:46:05 CET] <BBB> pong
[13:46:43 CET] <ubitux> BBB: https://github.com/ubitux/FFmpeg/compare/vp9sync opinions?
[13:47:14 CET] <BBB> did they re-split the files?
[13:47:18 CET] <BBB> or is this still the original split?
[13:47:31 CET] <BBB> I explicitly asked Anton to confirm with me before re-splitting so we can make sure its ok
[13:47:41 CET] <ubitux> we never merged the split
[13:48:12 CET] <ubitux> so i compare how it was split on libav/master/HEAD
[13:48:18 CET] <ubitux> and redid it in our tree
[13:48:32 CET] <ubitux> + a stack of random cosmetics to reduce the diff
[13:49:10 CET] <ubitux> i haven't look at the asm yet
[13:51:34 CET] <ubitux> it's still diverging quite a lot, notably because of the shared context / bitstream leading to many diff
[13:51:55 CET] <ubitux> with additionnal missing features on libav side
[13:52:06 CET] <ubitux> i spotted a few things we may want to import though
[13:52:14 CET] <ubitux> such as not using avctx in the vp9_frame* funcs
[13:52:42 CET] <ubitux> you may want to run some ${EDITOR}diff between the files to check by yourself
[13:55:47 CET] <ubitux> BBB: what's this re-split thing about?
[14:01:12 CET] <ubitux> :(
[14:07:23 CET] Action: ubitux &
[14:08:35 CET] <BBB> ubitux: sorry, disconnected
[14:09:10 CET] <BBB> ubitux: re: split
[14:09:35 CET] <BBB> ubitux: elenril told me he was aware some features in ffmpeg needed to be imported in libav (along with optimizations), and he was willing to re-import our current codebase into libav head
[14:09:47 CET] <BBB> after that he was going to re-split it but asked if I was interested in merging that on our side
[14:10:04 CET] <BBB> I said yes, if I can at least provide some input/review on the split to make sure Im OK with it
[14:10:19 CET] <BBB> ubitux: so Im basically waiting for the patch to review so we can both have the same split
[14:10:26 CET] <BBB> and then hopefully have a relatively equal codebase
[14:10:37 CET] <BBB> where whatever they apply on top can be merged trivially on our side
[14:11:15 CET] <BBB> ubitux: I Can review the smaller changes but re: split, I would say hold off until elenril sends me the patch
[14:13:06 CET] <BBB> ubitux: b5735cbb4a75fb8ec232d623061df70aabee2e08 the tree parts are fundamentally wrong, its diegoification and diego knows nothing about codecs
[14:13:56 CET] <BBB> the 32x32 zigzag scantable change is also wrong because it makes it non-32
[14:15:12 CET] <ubitux> BBB: ah... ok
[14:15:17 CET] <BBB> I would claim that b5735cbb4a75fb8ec232d623061df70aabee2e08 should have been reviewed by me
[14:15:21 CET] <BBB> I would reject most of it
[14:15:31 CET] <BBB> its all just opinion, two spaces is nicer than one
[14:15:42 CET] <BBB> that opinion should be up to the author(s), not up to some random diego
[14:15:46 CET] <ubitux> i can't apply anything without the split, i'm not willing to redo that stuff, so i'll drop that stuff
[14:15:59 CET] <ubitux> yeah, about the spaces shuffling, a lot are insane/stupid
[14:16:10 CET] <ubitux> and i didn't even merged all of them
[14:16:12 CET] <BBB> 7ee37815cd019f1ee079cce54e49107eb51d680f seems nice
[14:16:50 CET] <ubitux> it's a pita to apply those without the split so you can stop the review :p
[14:16:55 CET] <BBB> okay
[14:17:06 CET] <BBB> if youre interested in the split per se, lets discuss that with anton
[14:17:16 CET] <BBB> I really continue to think a proper split should be reviewed by me and you
[14:17:19 CET] <ubitux> i agree with the loss of information wrt the "tree indent", not sure what you're refering about the zigzag
[14:17:42 CET] <BBB> ff_vp9_default_scan_32x32
[14:17:54 CET] <BBB> its a table of 32 rows and columns, because its a 32x32 scantable
[14:18:05 CET] <BBB> he changes it into a 64 rows of 16 columns
[14:18:10 CET] <BBB> which seems very weird to me
[14:18:17 CET] <ubitux> ah, that, yeah, i assumed it was like this on purpose
[14:19:27 CET] <ubitux> but i thought it wasn't too much a problem (contrary to the loss of the "tree view indent"
[14:19:27 CET] <BBB> and patches like 77c996b62349ca928cc525be694fc2239db666d1 just make me wonder why
[14:19:29 CET] <ubitux> )
[14:19:41 CET] <ubitux> BBB: reduce diff.
[14:19:47 CET] <BBB> no, I get that
[14:19:49 CET] <ubitux> we use ret everywhere
[14:19:52 CET] <ubitux> anyway
[14:19:57 CET] <ubitux> so consistency as well if you want
[14:19:59 CET] <BBB> but lets talk to anton about the split
[14:20:27 CET] <ubitux> the split commit doesn't contain any cosmetics IIRC
[14:20:34 CET] <ubitux> i really just moved the blocks
[14:21:05 CET] <BBB> yeah, we just need to make sure this is the final version
[14:21:12 CET] <BBB> and theyre not going to re-split it again after merging it
[14:21:16 CET] <BBB> which would be strange
[14:21:21 CET] <BBB> and wasteful of our time :)
[14:21:54 CET] <ubitux> elenril may have a grudge about me, so i'll let you handle the pourparler
[14:22:35 CET] <ubitux> if he started or did a commit to be applied on ffmpeg tree to do the split we should probably take his (and i'll rebase that stuff on it)
[14:23:09 CET] <ubitux> otherwise i'll rebase when necessary
[14:23:23 CET] <ubitux> but if i could avoid reworking that branch too much that would be appreciated :p
[14:23:36 CET] <ubitux> it took me a few hours, and it's really annoying stuff to do
[14:30:30 CET] <adeel_> I have submitted my draft fro GSoC. Please review and suggest modifcaions / improvements: https://docs.google.com/document/d/1QMjzzXO6lF7Jk3KSiKWjaPQWyOYs6VZIdCKCL_Uuji0/edit?usp=sharing
[15:24:35 CET] <BBB> ubitux: Ill try to help where I can
[15:24:53 CET] <BBB> ubitux: I obviously want whatever is best for the overall vp9 decoder, and I think them being in sync is always better
[16:14:18 CET] <kierank> 10:40 AM <"j-b> and never understood why it needed all bit depth and not just use 16, afte 10
[16:14:31 CET] <kierank> because you can do arithmetic and not overflow in 16-bit
[16:48:43 CET] <ubitux> BBB: btw, it looks like valgrind doesn't like ff_vp9_idct_iadst_16x16_add_avx2 at all :p
[16:48:50 CET] <BBB> hm...
[16:48:56 CET] <BBB> overreads?
[16:48:59 CET] <BBB> link?
[16:49:08 CET] <ubitux> might be a problem with valgrind
[16:49:11 CET] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20170325102224&slot=x86_64-archlinux-gcc-valgrindundef
[16:49:29 CET] <ubitux> "VEX temporary storage exhausted.
[16:49:35 CET] <BBB> huh?
[16:49:36 CET] <BBB> :D
[16:49:36 CET] <ubitux> Increase N_{TEMPORARY,PERMANENT}_BYTES and recompile."
[16:49:38 CET] <ubitux> :D
[16:49:50 CET] <BBB> ok thats probably a valgrind issue yes
[16:51:10 CET] <ubitux> your asm is too complex for valgrind :(
[16:52:06 CET] <durandal_1707> anyone understands what needs to be done to add 444 support to our dnxhdenc?
[16:52:09 CET] <BBB> so uhm
[16:52:14 CET] <BBB> is that a compliment or a criticism?
[16:52:26 CET] <BBB> Im not quite sure what to do, basically
[16:52:42 CET] <BBB> I fully agree that the code is very, very complicated, but I dont think it does anything utterly strange
[16:52:56 CET] <BBB> shall I email the valgrind list?
[16:53:04 CET] <ubitux> it's not criticism :)
[16:53:07 CET] <BBB> I have an additional issue that valgrind doesnt work on macosx 10.12 so I cant test it :(
[16:53:08 CET] <ubitux> it's always the same function though
[16:53:40 CET] <durandal_1707> i keep getting put bits overflow
[16:53:57 CET] <BBB> durandal_1707: so if you increase the buffer, does it work? :-p
[16:54:48 CET] <BBB> ubitux: shall I just file a bug and see what happens?
[16:54:55 CET] <ubitux> would be great
[16:55:01 CET] <ubitux> :)
[16:55:12 CET] <BBB> can you reproduce locally?
[16:55:23 CET] <BBB> (just to make sure its not some weird config on the testing machine)
[16:55:40 CET] <durandal_1707> BBB: buffer size is calculated from contents iirc
[16:56:24 CET] <ubitux> BBB: yes
[16:57:12 CET] <ubitux> BBB: valgrind checkasm ’ http://sprunge.us/FBKM
[16:57:53 CET] <ubitux> BBB: want me to try to recompile valgrind with that macro increased?
[17:01:32 CET] <BBB> no
[17:01:41 CET] <BBB> lets ask them what it means
[17:02:13 CET] <BBB> thats a different function btw
[17:02:14 CET] <BBB> very strnage
[17:02:35 CET] <ubitux> http://sprunge.us/MgaI
[17:02:45 CET] <ubitux> here is what you get with valgrind svn
[17:03:19 CET] <ubitux> you may want to provide this backtrace
[17:04:05 CET] <BBB> thats very helpful, yes
[17:04:05 CET] <BBB> thanks
[17:04:20 CET] <ubitux> the ffmpeg stack is completely fucked up
[17:04:47 CET] <ubitux> at least enough to drive valgrind nuts
[17:06:17 CET] <ubitux> by 0xDEADBEEFDEADBEEE
[17:06:19 CET] <ubitux> hehehe
[17:06:54 CET] <nevcairiel> whats that, 64-bit beef?
[17:07:09 CET] <ubitux> ah that might be the checkasm clobbering thing
[17:07:29 CET] <BBB> https://bugs.kde.org/show_bug.cgi?id=378068
[17:07:42 CET] <BBB> I noticed that also
[17:07:51 CET] <BBB> its funny that its not deadbeefdeafbeef, but eee at the end
[17:08:05 CET] <BBB> but the fact that we get a backtrace out of valgrind suggests an actual bug in valgrind
[17:08:22 CET] <BBB> I dont know what it means exactly but I think asking themf or advice is probably a good idea
[17:09:21 CET] <kierank> BBB: I can test on valgrind git if you want
[17:09:35 CET] <kierank> i've had problems with simd and valgrind before and upgrading to git usually fixes it
[17:09:42 CET] <BBB> ok that would be nice, thanks
[17:09:46 CET] <ubitux> valgrind svn doesn't fix it
[17:10:07 CET] <ubitux> r16286
[17:10:10 CET] <kierank> what command do I have to run?
[17:10:27 CET] <ubitux> ~/src/valgrind/vg-in-place ./tests/checkasm/checkasm
[17:10:39 CET] <ubitux> you need an avx2 machine
[17:11:22 CET] <BBB> is valgrind in svn or in git?
[17:11:27 CET] <BBB> how strange
[17:11:45 CET] <kierank> svn
[17:12:50 CET] <ubitux> BBB: we should probably report that svq1 thing too
[17:12:54 CET] <ubitux> iirc it's a false positive :3
[17:13:37 CET] <BBB> if its a false positive, then yes
[17:13:44 CET] <BBB> I need to get a working valgrind on my machine
[17:13:56 CET] <BBB> its so irritating that every time I get a osx update, valgrind stops working :-/
[17:14:01 CET] <BBB> fortunately asan works fine
[17:14:13 CET] <BBB> brb gotta bring kids to swimming
[18:31:15 CET] <philipl> BtbN: So, I'm still looking at the nvenc bframe thing.
[18:31:41 CET] <BtbN> Yeah, looked at it myself, but couldn't find anything obvious wrong
[18:31:52 CET] <BtbN> except for it not working
[18:31:54 CET] <philipl> So, I established that the encoder works until it runs out of surfaces
[18:31:59 CET] <philipl> So it's not failing right away
[18:32:14 CET] <philipl> Surfaces are being leaked. They get locked and then never unlocked
[18:32:30 CET] <BtbN> Well, the encoder never signals that one is ready
[18:32:37 CET] <BtbN> So of course they stay locked
[18:40:56 CET] <philipl> huh.
[18:42:07 CET] <BtbN> That's what I think is happening. But I can't think of a reason why
[18:46:13 CET] <philipl> timestamps? The dts stuff is the main difference in the encoder logic
[18:46:32 CET] <philipl> And it also only started happening after the filter merge
[18:49:03 CET] <iive> i don't get it, how does it work at all if surfaces are only locked and never unlocked?
[18:50:28 CET] <philipl> If you turn off bframes, or if you don't use hwaccel, it works fine.
[18:50:35 CET] <philipl> That's the crazy part.
[18:51:14 CET] <philipl> Not using hwaccel is a very different code path, as the surface management is completely different, so the comparison there is not so immediately useful.
[18:51:36 CET] <philipl> but bframes - out of the stuff we control, there isn't much different.
[19:02:45 CET] <BtbN> philipl, adding some debug-prints reveals that the very first call to nvEncEncodePicture already fails.
[19:03:06 CET] <BtbN> [h264_nvenc @ 0x6000604a0] EncodePicture failed!: no encode device (1)
[19:03:12 CET] <BtbN> Are we even seeing the same error?
[19:03:25 CET] <philipl> Ah.
[19:03:34 CET] <philipl> So if your rc-lookahead is 0, then you get that error.
[19:04:15 CET] <philipl> (and without hwaccel, that works too)
[19:05:02 CET] <BtbN> It almost looks like a driver-side issue to me.
[19:05:13 CET] <BtbN> But hard to tell
[19:05:30 CET] <philipl> yeah, except the filter merge thing.
[19:05:34 CET] <philipl> If I revert that, then this works.
[19:05:36 CET] <philipl> same driver
[19:06:32 CET] <BtbN> Probably the same weird reason not binding the CUDA context worked before
[19:06:59 CET] <philipl> maybe we need to bind more cuda contexts :-)
[19:10:03 CET] <BtbN> It is bound while the error happens
[19:10:42 CET] <philipl> Have you ever emailed one of the nvidia guys and got a response?
[19:10:55 CET] <philipl> We could ask them to look at it. Presumably they care if this stuff works.
[19:11:21 CET] <BtbN> They responded to some issues sent on the ML
[19:14:35 CET] <BtbN> The error is also super weird: "indicates that no encode capable devices were detected"
[19:14:53 CET] <philipl> I feel like that implies the combination of options is invalid
[19:15:08 CET] <philipl> but then why does it work without hwaccel
[19:16:03 CET] <BtbN> It kind of makes sense that requesting b frames implied lookahead
[19:16:08 CET] <BtbN> *implies
[19:16:24 CET] <philipl> yeah
[19:16:42 CET] <BtbN> When doing "-bf 1 -rc-lookahead 1": [h264_nvenc @ 0x6000aa860] EncodePicture returned: need more input (17)
[19:16:49 CET] <BtbN> Until nvenc runs out of free surfaces
[19:17:45 CET] <philipl> so weird.
[19:18:06 CET] <BtbN> Maybe it just needs more...?
[19:18:35 CET] <philipl> I think I tried going all the way to hardware max surfaces and it didn't help
[19:20:22 CET] <philipl> it does not
[19:22:16 CET] <durandal_1707> BBB: it should have calculate enough bits it needs
[19:22:45 CET] <BBB> durandal_1707: its really hard to give any sort of reasonable indication of what is wrong, I dont know, sorry
[19:23:05 CET] <BBB> Im guessing theres a bug in VLC codes or buffer allocation, if you analyze it should be easy to figure out
[19:23:49 CET] <durandal_1707> no, this is dnxhd encoder for 444 profile
[19:24:11 CET] <BtbN> philipl, "-bf 1 -rc-lookahead 1 -delay 0" just makes it return the no encode device error again
[19:24:14 CET] <durandal_1707> its basically 444 yuv pix fmt instead of 422
[19:25:25 CET] <BtbN> philipl, that makes me wonder... why does the async_delay influence the returned error from EncodePicture?!
[19:25:31 CET] <BtbN> It's never passed to the encoder
[19:25:46 CET] <BBB> durandal_1707: I dont know, sorry& I think the buffer or init size for the buffer is not big enough then
[19:25:49 CET] <BBB> but Im sure you looked at that
[19:25:54 CET] <BBB> I have no other suggestions beyond that
[19:26:26 CET] <BtbN> "Lookahead not enabled. Increase buffer delay (-delay).", oh, that's why
[19:26:32 CET] <durandal_1707> take look at code
[19:27:19 CET] <philipl> BtbN: heh.
[19:39:53 CET] <BtbN> philipl, well, this is either nvEncEncodePicture returning a weird error, or it never returning anything but need_more_input
[19:50:43 CET] <BtbN> philipl, is the same happening on libav, btw.?
[19:51:57 CET] <nevcairiel> libav doesnt have cuvid hwaccel to test t hat
[19:52:20 CET] <BtbN> Oh, they never added that? Weird, as the CUDA pix_fmt comes from there
[19:52:47 CET] <nevcairiel> they are still toying with the idea of making cuvid an actual hwaccel
[19:59:46 CET] <BtbN> Well, if they feel like doing that.
[20:15:59 CET] <BtbN> philipl, cuvid->hwupload_cuda->nvenc also works fine in all circumstances.
[20:16:26 CET] <BtbN> So it's not the CUDA code in nvenc.c that's broken, but the specific combination of cuvid and nvenc sharing a cuda context, with cuvid being initialized first.
[20:21:35 CET] <philipl> that does sound like a driver bug scenario
[21:10:33 CET] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20170325195844&slot=x86_64-archlinux-gcc-random
[21:10:43 CET] <ubitux> there is a cuvid dependency problem 
[21:14:17 CET] <ubitux> all my fate instances are back btw, except icc, but fuck intel anyway
[21:38:57 CET] <durandal_1707> dnxhd is dct based codec, im working on 444 dnxhr profile
[21:42:41 CET] <philipl> ubitux: It's because the hwaccel and the decoder are declared together under the decoder #define. So if hwaccel is requested and decoder is not, then it fails like this.
[21:43:01 CET] <philipl> I'm not sure why we declare hwaccels as there is no actual hwaccel support.
[21:43:04 CET] <philipl> BtbN: ?
[21:43:46 CET] <BtbN> Because ffmpeg.c
[21:45:01 CET] <BtbN> I'm not sure if that requirement is still needed after the merges
[21:47:40 CET] <philipl> trying it out
[21:48:52 CET] <philipl> doesn't work without the hwaccels declared
[21:49:41 CET] <philipl> So have to separate out hwaccel decls to make the config robust
[21:50:28 CET] <wm4> you'Re talking about AVHWAccels for "full" hw decoders? they're needed because libavcodec/utils.c
[21:50:45 CET] <wm4> ff_get_format or whatever rejects hw pixfmts if there's no matching AVHWAccel
[21:50:57 CET] <philipl> there you go.
[21:51:42 CET] <BtbN> philipl, or just add proper dependencies to configure
[21:51:52 CET] <wm4> we could just stop this and remove the associated utils.c code
[21:52:41 CET] <philipl> BtbN: make hwaccel depend on decoder in configure?
[21:52:48 CET] <BtbN> and vice versa
[21:54:00 CET] <philipl> circular dependency?
[21:55:08 CET] <BtbN> The dependency resolver is not that smart
[21:55:24 CET] <BtbN> It will just error out if one of the two are disabled then
[21:56:06 CET] <philipl> Does that count as a fate failure?
[22:00:41 CET] <BtbN> Why does fate even get into that weird state?
[22:01:48 CET] <philipl> random configuration test
[22:06:37 CET] <ubitux> philipl: i won't fix that so sure, ok :)
[22:06:54 CET] <BtbN> It is a legitimate bug though
[22:07:08 CET] <BtbN> I guess the hwaccel should depend on the decoder
[22:08:42 CET] <wm4> hwaccel dependencies are all kind of weird
[22:09:05 CET] <BtbN> h264_cuvid_hwaccel_deps="cuda cuvid" -> h264_cuvid_hwaccel_deps="h264_cuvid_decoder cuda cuvid"
[22:09:08 CET] <BtbN> same for all the other ones
[22:09:09 CET] <wm4> e.g. auto detection (which leads to dxva2 etc. being enabled) factors into this
[22:09:41 CET] <philipl> BtbN: yeah
[22:20:20 CET] <nevcairiel> we have the "select" type for deps on internal components
[22:20:30 CET] <nevcairiel> deps should be for external things
[22:20:53 CET] <nevcairiel> so basically add h264_cuvid_hwaccel_selects=h264_cuvid_decoder
[22:22:11 CET] <BtbN> Can it be added in both directions?
[22:22:21 CET] <BtbN> Or will that cause weird cycles?
[22:22:44 CET] <nevcairiel> cant you basically have the decoder without the hwaccel
[22:22:54 CET] <nevcairiel> just not use the cuda pixfmt?
[22:22:59 CET] <philipl> Yeah, it seems valid to ahve decoder without hwaccel
[22:23:05 CET] <philipl> so circular dep is not required
[22:32:16 CET] <iive> can the cuda decoder output regular yuv image?
[22:32:36 CET] <nevcairiel> yes
[22:33:04 CET] <nevcairiel> (also, its not cuda, but cuvid/nvdec, its still dedicated video hardware, not a "cuda program")
[22:36:29 CET] <BtbN> Circular dependency for h264_cuvid_decoder.
[22:36:29 CET] <BtbN> hm
[22:36:59 CET] <BtbN> https://github.com/BtbN/FFmpeg/commit/524e0997be7e38898dc74d1b00154aff20c7f23c
[22:37:07 CET] <BtbN> aparently this is already enough to cause a circle
[22:37:47 CET] <BtbN> Oh, because h264_cuvid_decoder_select="h264_mp4toannexb_bsf h264_cuvid_hwaccel"
[22:40:06 CET] <nevcairiel> like I said, i dont think the decoder needs to depend on the hwaccel
[22:40:13 CET] <iive> nevcairiel: is it the same hardware used by vdpau?
[22:40:15 CET] <nevcairiel> it should be able to function fine without it
[22:40:17 CET] <BtbN> Yeah, it's just the wrong way around right now.
[22:40:20 CET] <nevcairiel> iive: yes
[22:40:26 CET] <BtbN> https://github.com/BtbN/FFmpeg/commit/bd717340a28ef0fdb997584623236c4428a3bdae
[22:41:02 CET] <philipl> ship it
[22:41:11 CET] <iive> nevcairiel: does the decoder output yuv automatically or it needs something extra. e.g. if you want to use software filters?
[22:41:34 CET] <nevcairiel> it gives you a memory buffer with the yuv on it, you can either copy that to normal system memory or keep it on gpu memory
[22:41:36 CET] <BtbN> it needs special treatment if you want it to NOT output YUV
[22:42:12 CET] <iive> nevcairiel: i'm asking if ffmpeg can do it?
[22:42:29 CET] <nevcairiel> it can
[22:42:37 CET] <nevcairiel> it gives you yuv by default
[22:42:49 CET] <nevcairiel> need extra options to keep it on gpu memory
[22:43:25 CET] <iive> hum..
[22:45:06 CET] <nevcairiel> you can basically just use -c:v h264_cuvid and it uses the hardware decoder and gives you normal yuv
[23:13:00 CET] <atomnuker> "ERROR SUMMARY: 1122806 errors from 311 contexts (suppressed: 0 from 0)"
[23:13:08 CET] <atomnuker> how am I meant to debug this, valgrind?
[23:13:41 CET] <atomnuker> all of them come from a single uninitialized variable somewhere which propagates and valgrind freaks out
[23:14:31 CET] <iive> nevcairiel: i ask because somebody had problem with filters when using cuvid and nvenc. I assumed the surface remained on the card.
[23:14:49 CET] <iive> i don't have nvidia hardware to test myself.
[23:32:33 CET] <cone-982> ffmpeg 03Timo Rothenpieler 07master:bd717340a28e: configure: cuvid hwaccels need the corresponding decoder, not the other way around
[23:33:48 CET] <BtbN> that should fix fate
[23:56:11 CET] <kierank> wm4: any idea what this is https://stackoverflow.com/questions/40991412/ffmpeg-producing-strange-nal-suffixes-for-mpeg-ts-with-h264?
[00:00:00 CET] --- Sun Mar 26 2017