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

[burek]

[01:33:16 CEST] <cone-729> ffmpeg 03Steven Liu 07master:0d2dd5d96d0d: avformat/hlsenc: support mkdir_p for use_localtime_mkdir
[01:41:07 CEST] <jamrial> uh, was that patch really reviewed as the commit implies?
[01:45:11 CEST] <Chloe> jamrial: not by anyone else
[01:46:36 CEST] <iive> have the patch been sent 2-3 days ago?
[01:47:37 CEST] <Chloe> 26th
[01:47:43 CEST] <Chloe> (originally)
[01:48:03 CEST] <iive> well, he's waited planty of time then.
[01:48:58 CEST] <wm4> why can't it show who pushed a commit
[01:49:00 CEST] <Chloe> err, it was reviewed, just not explicitly approved. 
[01:49:12 CEST] <wm4> also does this guy have push access?
[01:49:34 CEST] <Chloe> how many people have push access anyway?
[01:49:55 CEST] <Chloe> wm4: I would say he does, he's in MAINTAINERS
[01:50:16 CEST] <Chloe> I guess I can answer my own question here :)
[01:50:25 CEST] <wm4> why do we hand put push access like cookies
[01:50:36 CEST] <wm4> "we"
[01:51:52 CEST] <Chloe> good question
[01:52:20 CEST] <iive> how else do you solve lack of man power problem?
[01:52:52 CEST] <jamrial> well, if he's maintaining something, it makes sense
[01:53:04 CEST] <Chloe> yeah hlsenc or soemthing
[01:53:39 CEST] <jamrial> which is what he just modified
[01:53:42 CEST] <jamrial> still, he should have pinged the patch because it was never really approved or reviewed
[01:54:15 CEST] <Chloe> jamrial: the issue is that these practises arent really documented very well
[01:54:39 CEST] <wm4> more importantly, there are no practices
[01:55:05 CEST] <wm4> some devs just push what they want (I'll try that too)
[01:55:15 CEST] <jamrial> he mentioned michaelni as reviewer when he never did. he pointed some faults in the first version of the patch, but never said anything else
[01:55:42 CEST] <iive> well, it used to be a rule, that you have to wait 2 days before committing something yourself, if nobody reviews it.
[01:56:08 CEST] <rcombs> maybe mailing lists suck
[01:56:15 CEST] <iive> so if he had addressed michael points...
[01:56:26 CEST] <rcombs> patchwork is slightly less bad than just the list
[01:56:27 CEST] <iive> maybe everybody should relax
[01:56:38 CEST] <Chloe> I think it would be a good idea to define these rules somewhere
[01:56:51 CEST] <Chloe> or guidelines at least
[01:56:57 CEST] <rcombs> but people will need to actually use it, and it doesn't provide a good way to ping on something
[01:57:21 CEST] <Chloe> I use patchwork to get patches, because I still dont know how to do it from my mail client
[01:57:36 CEST] <Chloe> that's pretty much it though
[01:57:42 CEST] <iive> i think ffmpeg got patchwork
[01:57:50 CEST] <rcombs> yes
[01:57:56 CEST] <Chloe> iive: https://patchwork.ffmpeg.org/project/ffmpeg/list/
[01:58:43 CEST] <iive> anyway, don't drink too much member berry wine.
[01:59:07 CEST] <Chloe> .-.
[02:04:32 CEST] <Chloe> oh, we do have guidelines
[02:04:53 CEST] <Chloe> https://www.ffmpeg.org/developer.html#Development-Policy see 12
[02:05:46 CEST] <wm4> fascinating
[02:05:57 CEST] <Chloe> too bad probably no one reads them
[02:06:16 CEST] <Chloe> they're also not very legible
[02:09:03 CEST] <BtbN> Does setting _GNU_SOURCE have any bad side effects?
[02:13:46 CEST] <Chloe> I assume it might break some posix functions
[02:20:57 CEST] <michaelni> GNU_SOURCE can hide non posix code use
[02:22:36 CEST] <michaelni> i have 2 new fate tests locally (ticket186 and a svq3 watermark one, they break with the pending ffmpeg patches), should i push them or should i post them to the ML ?
[02:23:06 CEST] <michaelni> i think they break similarly as the cavs one
[02:23:36 CEST] <Chloe> post them to the ML
[02:24:07 CEST] <Chloe> why do they break with the new ffmpeg patches?
[02:24:31 CEST] <michaelni> i didnt really investigate 
[02:26:12 CEST] <wm4> wait until the new patches are in
[02:28:34 CEST] <michaelni> i would have liked to document the changes the patches cause to the tests in git history
[02:30:08 CEST] <wm4> well if you're fine with me changing them just to newly generated refs...
[02:31:02 CEST] <michaelni> i definitly prefer to push them before and have the refs changed shortly after than pushing them after the patches
[02:31:21 CEST] <Chloe> As long as they don't block wm4's patches, I dont see an issue with this
[02:36:08 CEST] <michaelni> ok, ill wait a bit and then push them before going to bed unless people want me to wait longer
[02:38:59 CEST] <wm4> I just don't want to rewrite this patch again
[02:44:19 CEST] <michaelni> the effect your patches have on the tests is the disappearance of the last frame. 
[03:10:21 CEST] <cone-729> ffmpeg 03Michael Niedermayer 07release/3.1:c8c5f66b42ed: avformat/avidec: Remove ancient assert
[03:10:22 CEST] <cone-729> ffmpeg 03Michael Niedermayer 07release/3.1:622ccbd8ab89: avformat/avidec: Check nb_streams in read_gab2_sub()
[03:10:23 CEST] <cone-729> ffmpeg 03Michael Niedermayer 07release/3.1:c2ea70628215: Changelog: update
[03:37:47 CEST] <cone-729> ffmpeg 03Steven Liu 07n3.1.4:HEAD: avformat/hlsenc: support mkdir_p for use_localtime_mkdir
[03:56:32 CEST] <cone-729> ffmpeg 03Michael Niedermayer 07master:588c2355a6f5: fate: Add fate-svq3-watermark
[03:56:33 CEST] <cone-729> ffmpeg 03Michael Niedermayer 07master:68d619a31cd7: fate: Add regression test for Ticket 186
[03:59:25 CEST] <Chloe> michaelni: while it wasn't as explicit as it could have been, I added a note in-case people question you pushing the tests so soon seemingly without a review/approval.
[10:20:13 CEST] <ubitux> this hls patch is really horrible
[10:21:12 CEST] <ubitux> strncmp for comparing 1 char? really?
[10:22:49 CEST] <nevcairiel> just because someone claims to be a maintainer doesnt mean they are good at their job =p
[10:42:11 CEST] <cone-096> ffmpeg 03Clément BSsch 07master:0fbd42390532: doc/libav-merge: complete TODO section
[12:29:30 CEST] <BtbN> michaelni, so defining _XOPEN_SOURCE would be preferred?
[12:29:49 CEST] <michaelni> BtbN, IMHO yes
[12:30:02 CEST] <BtbN> it's just about one missing function on cygwin
[12:30:11 CEST] <BtbN> sigaction is missing without XOPEN_SOURCE or GNU_SOURCE
[12:39:50 CEST] <michaelni> nevcairiel, if you see a problem with someones commit, best to talk to him, if you want to volunteer to take over any maintaince or know of someone who wants to iam very interrested, we always need more volunteers and manpower. Do we have anything were there are 2 competing volunteers both wanting to maintain ?
[13:24:44 CEST] <Chloe> michaelni: what do you think of negating the testing policy so that it's: you must not commit unless it passes fate, works for you, and all reviewers. (I think that's more clear than what it was before)
[13:52:15 CEST] <nevcairiel> michaelni: the point is that even if someone volunteers to maintain a component, we should hopefully still be able to expect a certain degree of quality, otherwise maybe they shouldn't be a maintainer and go through proper reviews
[13:52:39 CEST] <nevcairiel> quality of the code affects us all, in all areas
[13:53:47 CEST] <michaelni> Chloe, maybe both would make most sense. I think the old text was intended to draw a line were the comitter is no longer responsible for breaking obscure corner cases he couldnt even know about like some obscure platform
[13:54:18 CEST] <michaelni> nevcairiel, yes
[13:54:57 CEST] <iive> still talking about that commit?
[13:55:23 CEST] <iive> did it broke anything? was is of low quality?
[13:55:30 CEST] <michaelni> have to go afk
[13:56:57 CEST] <nevcairiel> its a general point to make, just because someone sent a handful of patches to a certain quality, should we just hand them maintainer status? maybe a bit more time of contributions might be sensible first.
[13:57:06 CEST] <nevcairiel> certain component*
[14:01:22 CEST] <iive> yes and yes
[14:01:28 CEST] <iive> do you have other questions?
[14:02:56 CEST] <iive> stop worring about imaginary things.
[14:19:36 CEST] <ubitux> do we still need the packet split side data hack?
[14:20:31 CEST] <nevcairiel> not sure why we ever really needed it
[14:21:20 CEST] <ubitux> prevent leaks in random applications iirc
[14:26:06 CEST] <wm4> I hate this hack so much
[14:26:30 CEST] <ubitux> btw
[14:26:31 CEST] <wm4> ubitux: not leaks, just stupid applications which might discard side data even if using both lavf and lavc
[14:26:39 CEST] <ubitux> we're going to have to deal with 100+ commits from libav pretty soon
[14:27:06 CEST] <ubitux> we might hit the 500 commits delay
[14:27:28 CEST] <nevcairiel> as long as they go the sane way and make it possible to gradually migrate
[14:27:47 CEST] <nevcairiel> but i think in the end they went with that
[14:28:18 CEST] <ubitux> yeah but we're accumulating too much delay IMO
[14:28:42 CEST] <ubitux> it would be fine if we were on par commits wise
[14:29:37 CEST] <ubitux> but we have a bunch of avconv patches and more hevc that continues to pill up
[14:30:39 CEST] <nevcairiel> the next big project will be the avconv changes that make the early-init problem go away, after that it should be a bunch of "normal" patches for a long while
[14:31:20 CEST] <ubitux> what's blocking right now?
[14:31:27 CEST] <ubitux> we're on qsv stuff
[14:31:29 CEST] <nevcairiel> right now? some qsv stuff
[14:31:41 CEST] <ubitux> is there a wip or sth?
[14:32:11 CEST] <nevcairiel> for qsv i see two routes to take - skip them and hope our qsv "maintainers" do something with them, or revert qsv to the libav variant and just merge everything as-is (currently, i would argue theirs is better anyway)
[14:32:48 CEST] <ubitux> who are our maintainers? random externs that pop up at times?
[14:32:54 CEST] <nevcairiel> pretty much
[14:32:57 CEST] <nevcairiel> these nablet guys
[14:33:05 CEST] <wm4> (lol)
[14:33:30 CEST] <ubitux> are they aware of this? because waiting for them might not be the best approach
[14:33:41 CEST] <nevcairiel> jamrial posted on the ML to let them know
[14:33:49 CEST] <nevcairiel> no clue if thats enough to wake them up
[14:34:14 CEST] <ubitux> i wouldn't mind looking at all of this but i was just back on the subtitles api
[14:34:24 CEST] <ubitux> and honestly, this delaying is frightening me more and more
[14:34:58 CEST] <nevcairiel> we can just skip the qsv stuff and decide later if we want to do something more drastic, like clean up the stuff and get more similar to libav again
[14:35:06 CEST] <nevcairiel> its just new features, nothing critical
[14:35:35 CEST] <nevcairiel> it would need quite a bunch of refactoring to adapt to ours, i think
[14:35:40 CEST] <ubitux> will the QSV scaling filter work?
[14:35:59 CEST] <nevcairiel> probably not, i would think it needs the context things the first two patches implement
[14:36:21 CEST] <ubitux> is there any benefit to our version?
[14:36:42 CEST] <nevcairiel> i think we support like mjpeg decoding which they dont have? or something like that. nothing of consequence
[14:38:22 CEST] <nevcairiel> the primary reason it went desync is that our guys were impatient and didnt want to adapt the avcodec infrastucture to be able to use parsers for qsv
[14:38:26 CEST] <ubitux> so mmh, just to be clear; the story is that we merged a dubious qsv support, then libav nihed it, then we forced our maitainers to clean it up a bit to keep it somehow in par, and now it's blocking the progress of current merges?
[14:38:29 CEST] <nevcairiel> so ours use more of the mfx stuff for parsing
[14:38:38 CEST] <nevcairiel> and libav stuff uses more of avcodec
[14:43:36 CEST] <ubitux> wasn't vaapi the intel thing btw?
[14:43:37 CEST] <nevcairiel> i dont quite remember the very first history, libav may have even had it first, and ours was then changed to add more codec support "quickly"
[14:44:58 CEST] <Chloe> ubitux: yes
[14:45:11 CEST] <ubitux> so why qsv?
[14:45:45 CEST] <ubitux> i don't even have that mfx lib
[14:46:20 CEST] <iive> vaapi is the xorg api. Intel use only vaapi for their cards, afair
[14:46:27 CEST] <nevcairiel> they all want a cross-platform variant with more features, instead of maintaining some open-source stuff
[14:46:37 CEST] <nevcairiel> vaapi was initially pushed by intel though
[14:47:11 CEST] <ubitux> oh well fuck this shit, i have a big enough turd to deal with already
[14:47:12 CEST] <wm4> vaapi is basically an exclusive intel thing
[14:47:29 CEST] <wm4> and ubitux is quite right
[14:48:09 CEST] <nevcairiel> ubitux: anyway my suggestion for now would be to skip the three qsv things and put them on the list for later, they dont entangle with anything else in avcodec, so we can either let the nablet people deal with it later if they want, or if someone else comes along  to take over qsv let them do whatever, but for merging purposes keeping it blocked seems silly
[14:48:25 CEST] <Chloe> wm4: it looks like it was designed to be an open hwaccel platform, but it just didnt take off
[14:48:43 CEST] <wm4> Chloe: just like vdpau
[14:48:59 CEST] <Chloe> rip. why are there two
[14:49:09 CEST] <nevcairiel> because vdpau is nvidia
[14:49:17 CEST] <wm4> two? there's a great number of hwdec APIs on Linux
[14:49:44 CEST] <nevcairiel> its the typical linux problem, without a central driving force, there is several parallel attempts at this and none manage to succeed fully
[14:50:35 CEST] <iive> mesa gallium provides vdpau for radeon cards, so you get amd and nvidia covered with vdpau
[14:51:04 CEST] <nevcairiel> last i heard thats still rather buggy, but maybe it improved now, been a while
[14:51:32 CEST] <wm4> well windows also has at least 4 APIs or so
[14:51:32 CEST] <iive> i've been using it for years... 
[14:52:11 CEST] <nevcairiel> windows has one central API for decoding thats supported by everyone, nevermind the ve ndors own cross-platform APIs, you dont really need those to handle decoding =p
[14:55:11 CEST] <ubitux> nevcairiel: fine with me; if you do, please update the TODO in doc/libav-merge.txt doc
[14:55:42 CEST] <ubitux> i won't work on the merge until i'm done with the final blow on subtitles
[14:55:50 CEST] <ubitux> +api
[15:06:26 CEST] <jamrial> ubitux: i emailed the qsv maintainer to deal with this
[15:06:37 CEST] <jamrial> just skip these two merges, they are not blockers
[15:06:56 CEST] <nevcairiel> probably the third one as well, i mean it wont exactly break, but it will just not be usable
[15:07:08 CEST] <jamrial> guess i'll have to ping him since he probably didn't notice my first email some days ago
[15:09:00 CEST] <jamrial> nevcairiel: with the third you mean the filter? it shouldn't depend on the other two commits
[15:09:43 CEST] <nevcairiel> how would it get the shared hwcontext if the decoder and encoder cant use one?
[15:09:48 CEST] <ubitux> wm4: you're merging the move to the new api in ffmpeg soon, aren't you?
[15:10:12 CEST] <ubitux> it would be somehow helpful for my tests :p
[15:10:35 CEST] <jamrial> ah, fair enough
[15:10:57 CEST] <nevcairiel> its technically not required to skip it, but its untestable and unusable right now
[15:11:07 CEST] <nevcairiel> so I would rather not include it yet
[15:21:55 CEST] <cone-087> ffmpeg 03Anton Khirnov 07master:a0524d9b1e1b: qsvdec: support getting the session from an AVHWFramesContext
[15:21:55 CEST] <cone-087> ffmpeg 03Anton Khirnov 07master:ad9c9440d592: qsvenc: support getting the session from an AVHWFramesContext
[15:21:55 CEST] <cone-087> ffmpeg 03Anton Khirnov 07master:ac7bfd69678f: lavfi: add a QSV scaling filter
[15:21:55 CEST] <cone-087> ffmpeg 03Hendrik Leppkes 07master:130e1f1df23e: Merge commit 'a0524d9b1e1bb0012207584f067096df7792df6c'
[15:21:55 CEST] <cone-087> ffmpeg 03Hendrik Leppkes 07master:04b17ff9e819: Merge commit 'ad9c9440d592e4d53d6bec9961b4b22e25387d70'
[15:21:55 CEST] <cone-087> ffmpeg 03Hendrik Leppkes 07master:62c58c59d54f: Merge commit 'ac7bfd69678f3966e38debdb27f4bde94dc0345c'
[15:21:55 CEST] <cone-087> ffmpeg 03Hendrik Leppkes 07master:3c18188f9f3e: doc/libav-merge: add a note for the skipped QSV functionality
[15:56:49 CEST] <nevcairiel> so apparently there is disagreement which timebase AVFrame.pts uses between ffmpeg and libav, libavs recent changes seem to suggest its the same timebase as pkt_pts/dts, ie. the stream timebase, while ffmpeg assumes its the AVCodecContext.time_base .. of course its not documented either way
[15:57:18 CEST] <nevcairiel> (from a decoder)
[15:57:27 CEST] <wm4> decoding should always use pkt_timebase
[15:57:32 CEST] <wm4> in ffmpeg
[15:57:42 CEST] <wm4> or if that is not set, it's implicitly defined by the API user
[15:58:04 CEST] <nevcairiel> but then you have a bit of an odd inconsistentcy as decoding would use stream timebase for AVFrame, but encoding uses codec timebase again, afaik
[15:59:30 CEST] <wm4> well yes encoding uses AVCodecContext.time_base for some reason
[15:59:58 CEST] <nevcairiel> for encoding it makes sense that encoders need to know about timestamps and timebases
[16:00:02 CEST] <nevcairiel> as there is ratecontrol involved
[16:00:36 CEST] <nevcairiel> having AVFrame.pts be in different timebases based on decoding or encoding just sounds wrong though
[16:00:58 CEST] <wm4> it's how it is
[16:01:05 CEST] <wm4> encoding: time_base, decoding: pkt_timebase
[16:01:19 CEST] <nevcairiel> well but it isnt
[16:01:28 CEST] <wm4> it isn't? when?
[16:01:35 CEST] <nevcairiel> ffmpeg.c assumes that if a decoder uses AVFrame.pts, then its in time_base
[16:01:46 CEST] <nevcairiel> but until now most decoders  didnt actually set AVFrame.pts
[16:01:51 CEST] <nevcairiel> unitl libav wants to makee it so
[16:02:09 CEST] <wm4> that's a very broken assumption
[16:02:18 CEST] <wm4> decoders never set AVFrame.pts AFAIK
[16:02:25 CEST] <wm4> could just be some absurd dead code
[16:02:44 CEST] <wm4> (I know these exist in ffmpeg.c, I restored one once to fix a bug)
[16:03:20 CEST] <nevcairiel> that is of course the question, do they really not, and this condition in ffmpeg.c can just be removed?
[16:03:48 CEST] <wm4> various user code might have copied these incorrect assumption
[16:03:57 CEST] <wm4> *assumptions
[16:04:19 CEST] <wm4> maybe deserves a note in APIchanges
[16:04:25 CEST] <nevcairiel> even has one
[16:04:36 CEST] <nevcairiel> although might be extended to indicate the timebase relationship
[16:04:37 CEST] <wm4> about the incorrect assumption ffmpeg.c makes?
[16:04:44 CEST] <wm4> yeah
[16:04:57 CEST] <nevcairiel> lets see if something breaks if i remove this check
[16:08:46 CEST] <nevcairiel> its only in the audio path, too
[16:09:03 CEST] <nevcairiel> not sure why audio decoders should even make up timestamps
[16:13:25 CEST] <ubitux> wm4: do you have a remote branch with the use of the new decoding(/encoding?) api in ffmpeg*c?
[16:14:01 CEST] <wm4> not really
[16:14:52 CEST] <ubitux> actually no tool use that new api yet
[16:16:02 CEST] <wm4> I can try to merge it now
[16:16:40 CEST] <nevcairiel> patch for the pts thing on the ml
[16:16:51 CEST] <nevcairiel> doesnt break pre-merge and fixes post-merge
[16:17:05 CEST] <ubitux> since i plan to have the new subtitles decoding api work with that new api only, it would help me to have at least one thing in the codebase that uses it :p
[16:17:18 CEST] <nevcairiel> avformat find_stream_info does!
[16:17:19 CEST] <nevcairiel> :D
[16:17:21 CEST] <JEEB> lol
[16:17:29 CEST] <ubitux> heh
[16:18:05 CEST] <wm4> (mpv also does, that probably makes them all)
[16:18:32 CEST] <jamrial> mpd also uses it
[16:18:53 CEST] <nevcairiel> i was too lazy to migrate yet
[16:18:56 CEST] <jamrial> they seem to dislike deprecation warnings so they port things as soon as they show up, hehe
[16:18:57 CEST] <wm4> jamrial: woah
[16:19:23 CEST] <wm4> I think I also have a branch somewhere to convert ffprobe.c
[16:19:42 CEST] <wm4> having done a few of such conversions, I have to say supporting both old and new APIs sucks ass
[16:19:55 CEST] <ubitux> avcodec_send_packet() and avcodec_receive_frame() are not thread safe, aren't they?
[16:20:01 CEST] <ubitux> mutually*
[16:20:45 CEST] <wm4> no
[16:20:49 CEST] <wm4> of course not
[16:24:39 CEST] <mateo`_> is it possible for a decoder to implement both APIs ?
[16:24:49 CEST] <wm4> I guess so
[16:27:13 CEST] <jamrial> cuvid did
[16:27:34 CEST] <jamrial> does, rather
[17:24:30 CEST] <cone-087> ffmpeg 03wm4 07master:b2fea2fdee46: ffmpeg: move subframe warning to libavcodec
[17:24:31 CEST] <cone-087> ffmpeg 03wm4 07master:8f6f2322285f: ffmpeg: use new decode API
[17:24:32 CEST] <cone-087> ffmpeg 03wm4 07master:4f8262e37309: ffmpeg: use new encode API
[17:25:49 CEST] <wm4> ubitux: done
[17:25:50 CEST] <JEEB> yayifications
[17:32:47 CEST] <mateo`_> \o/
[17:37:45 CEST] <cone-087> ffmpeg 03Marton Balint 07master:d946424f1933: lavfi/metadata: fix setting metadata values
[17:37:46 CEST] <cone-087> ffmpeg 03Marton Balint 07master:7ef3e5b593fb: lavfi/metadata: allow deleting all metadata
[17:40:42 CEST] <nevcairiel> who the f' would think its a good idea to use floating point in  malloc
[17:42:00 CEST] <kierank> http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc.c
[17:42:10 CEST] <wm4> yeah, musl does it for log2 (lol)
[17:42:12 CEST] <kierank> not sure exactly why
[17:42:18 CEST] <kierank> oh
[17:42:56 CEST] <wm4> it converts an integer to a float, and then extracts the mantissa using questionable code
[17:43:17 CEST] <wm4> oh just saw the ML post
[17:51:49 CEST] <nevcairiel> personally I think its not unreasonable to expect basic libc functions that do nothing externally with floats (or even math) to not internally use floats for such things
[17:52:04 CEST] <nevcairiel> wonder if there is some word from the C standard or posix about such things
[17:52:24 CEST] <wm4> actually I think it's reasonable that a libc user doesn't trash the execution environment, even if it's just the FPU
[17:52:35 CEST] <wm4> good question
[17:53:01 CEST] <BtbN> Isn'T the C standard is usually written in a way that it does not need to care about implementation details like assembly specifics?
[17:53:13 CEST] <nevcairiel> of course its probably not all that common to have mmx with allocs mixed, most of the time it'll just be small self-contained stuff
[17:53:30 CEST] <nevcairiel> BtbN: could still have some generic language about such th ings
[17:55:02 CEST] <ubitux> wm4: thx!
[17:58:52 CEST] <wm4> I don't get why ffmpeg.c gets 0 sized packets from iv32/OPENINGH.avi, but everything else (including ffprobe) does not
[18:00:42 CEST] <BtbN> voodoo magic.
[18:01:45 CEST] <wm4> so, should a decoder be allowed to return errors during draining (on EOF)?
[18:01:55 CEST] <wm4> e.g. return a few errors, then a frame, then some more errors
[18:02:04 CEST] <nevcairiel> shouldnt it just skip the errors then
[18:02:09 CEST] <nevcairiel> and return whatever frames it has
[18:02:11 CEST] <nevcairiel> or can
[18:03:24 CEST] <wm4> there should probably be some way to report errors, but I guess libavcodec has no nice concept for that
[18:03:29 CEST] <wm4> other than spamming log messages
[19:02:51 CEST] <BtbN> turns out CUDA is faster if you go for crazy memory alignments.
[19:03:06 CEST] <BtbN> 512 seems to be where it's at
[19:06:36 CEST] <BtbN> nevcairiel, using / instead of \ for the paths fixes the issue btw.
[19:06:45 CEST] <nevcairiel> gpus sometimes even like power of 2 alignment
[19:07:08 CEST] <BtbN> per line?
[19:07:22 CEST] <BtbN> seems a bit excessive
[19:07:36 CEST] <nevcairiel> yeah
[19:07:42 CEST] <nevcairiel> cant really align memory pointers that much =p
[19:08:02 CEST] <nevcairiel> its not that bad , 2048 for 1920, or 4096 for 3860
[19:08:16 CEST] <BtbN> does ffmpeg have a convenient function to do that?
[19:08:58 CEST] <BtbN> 512 might just happen to be what pushes my 1080p test video there
[19:10:48 CEST] <cone-087> ffmpeg 03James Almer 07master:449f263f9fbd: avcodec: add missing xmm/neon clobber test wrappers for the new encode API
[19:13:59 CEST] <BtbN> doesn't seem like there is
[19:45:30 CEST] <philipl> BtbN: Have you considered using cuda arrays?
[19:45:41 CEST] <philipl> That does implicit alignment. nvenc can consume them
[19:45:53 CEST] <BtbN> that would be a major rewrite of... almost everything
[19:46:10 CEST] <philipl> I did a quick experiment here last night. I got cuvid working fine
[19:46:18 CEST] <philipl> It's not major.
[19:46:45 CEST] <philipl> It's interesting for me because a mapped GL texture is an array - so I could theoretically provide a custom pool of textures and skip a copy
[19:46:54 CEST] <BtbN> The hwcontext stuff needs to be changed, as it does all the allocation now. And you can't just do pointer arith with CUDA Arrays
[19:47:07 CEST] <philipl> You can't, but why do you need to?
[19:47:19 CEST] <philipl> You make the allocated frame be a struct of arrays, one for each plane.
[19:47:26 CEST] <BtbN> Because the current hwcontext implementation assumes it to work like a normal pointer
[19:47:40 CEST] <philipl> If it's a pointer to a struct...
[19:47:46 CEST] <philipl> I did this. It works.
[19:47:54 CEST] <philipl> Can put the diff up if you want
[19:48:08 CEST] <BtbN> sure
[19:48:23 CEST] <BtbN> but just properly aligning the memory is way easier to do
[19:48:53 CEST] <philipl> https://github.com/philipl/FFmpeg/commit/670864a8f9f395117289b8b12583f63ee6e9a046
[19:49:31 CEST] <philipl> It's not finished by any stretch. I just assumed always nv12, but it was enough to prove it works for cuvid. Didn't look at nvenc, but I verified you can say an input resource is an array
[19:51:07 CEST] <BtbN> what's with the linesize for that?
[19:52:22 CEST] <philipl> What do you mean?
[19:52:26 CEST] <BtbN> it should also be aligned
[19:52:41 CEST] <philipl> linesize doesn't mean anything - the array alignment is internal and not actually knowable.
[19:53:13 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/8f9fb837e8dba4283e048a7dc463e584542a0060
[19:53:44 CEST] <BtbN> I just tested it, and power of two aligning each single line made a transcode go faster
[19:53:59 CEST] <philipl> The memcpy, when given an array, doesn't need any other information.
[19:54:18 CEST] <philipl> I have no idea if an array is faster than aggressive alignment, but I'd have thought that it would be comparable.
[19:54:44 CEST] <philipl> A big point of the array is to let cuda handle alignment - so I'd hope they do it right.
[19:55:50 CEST] <philipl> Change looks fine. If it works, go for it.
[19:56:07 CEST] <BtbN> so the linesize of the frame becomes meaningless, hm
[19:56:12 CEST] <philipl> Yeah.
[19:56:26 CEST] <BtbN> This change can't be just gone for
[19:56:29 CEST] <BtbN> it breaks public API
[19:56:37 CEST] <philipl> YEs, that's the main problem.
[19:56:49 CEST] <philipl> Could define a new PIX_FMT and hwcontext to get around that.
[19:57:08 CEST] <philipl> Unfortunately one hwcontext can't do two formats.
[19:58:24 CEST] <BtbN> I'd much rather just fix the alignment.
[19:58:49 CEST] <philipl> Of course.
[19:58:58 CEST] <philipl> I only care because of the potential to save a copy in mpv.
[19:59:13 CEST] <philipl> Of course, my prototype exploded generating textures in my buffer alloc.
[19:59:23 CEST] <philipl> probably calling GL on the wrong thread...
[19:59:53 CEST] <philipl> Could probably avoid that by implementing a fixed pool.
[20:00:56 CEST] <philipl> What sort of speed up did you see?
[20:21:13 CEST] <BtbN> 1080p, -preset slow -global_quality 22, went from somewhat stable ~242 FPS to heavily fluctuating between 380-450 FPS.
[20:22:00 CEST] <BtbN> if it's left running for a while it stabilizes, almost climbing up to 500
[20:27:54 CEST] <philipl> impressive
[20:59:55 CEST] <Chloe> atomnuker: will you still push the libfaac patch today, or shall I?
[21:00:33 CEST] <atomnuker> I literaly just applied it, just need to push it
[21:00:40 CEST] <Chloe> ok :)
[21:01:15 CEST] <cone-087> ffmpeg 03Josh de Kock 07master:dc0f711459e0: lavc: remove libfaac wrapper
[21:02:11 CEST] <atomnuker> now I just need to crawl through trac and figure out what needs a fate test
[21:02:25 CEST] Action: wm4 sounds canned applause
[21:03:10 CEST] <atomnuker> haasn: arithmetic coding for jpeg is some messed up shit
[21:03:25 CEST] <atomnuker> I have 2 books and 3 loose pdf "specs" which all say a different thing
[21:04:11 CEST] <atomnuker> seems the truth is somewhere between those, the current decoder and mozjpeg
[21:06:00 CEST] <wm4> isn't that what they mean by not bitexact?
[21:06:46 CEST] <atomnuker> no, it's bitexact, it's a coding process, doesn't affect quantization
[21:07:06 CEST] <wm4> also, 2 prores encoders, 1 prores decoder, and (final boss) 1 resample lib left to delete
[21:08:29 CEST] <atomnuker> rock paper scissors tournament to determine which prores encoder stays? winner decides
[21:11:10 CEST] <mateo`_> wm4: which resample lib would you delete ? swr* or avr* ?
[21:11:45 CEST] <Gramner> randomly flip bits in the object files and see which one can go one longest without segfaulting
[21:17:35 CEST] <wm4> mateo`_: let rock paper scissors decide
[21:19:31 CEST] <haasn> +1 for Gramner's suggestion
[21:19:52 CEST] <haasn> atomnuker: if in doubt, libjpeg?
[21:20:27 CEST] <atomnuker> libjpeg supports it?
[21:21:22 CEST] <haasn> well libjpeg-turbo does
[21:21:28 CEST] <haasn> not sure about IJG libjpeg but I would have assumed so
[21:22:05 CEST] <atomnuker> huh, so the distributions never enable the flag I guess
[21:22:25 CEST] <haasn> yes IJG libjpeg does too
[21:22:27 CEST] <haasn> atomnuker: yeah
[21:22:34 CEST] <haasn> every major browser would support it too
[21:22:37 CEST] <haasn> they just disable it at compile time
[21:22:50 CEST] <haasn> likely this has been supported for years
[21:22:55 CEST] <atomnuker> my chromium decodes them fine though
[21:22:57 CEST] <Chloe> what's the difference between prores-ks and prores-aw?
[21:23:13 CEST] <haasn> In version 7, support for arithmetic coding was introduced, which earlier has been rejected because of the patent situation
[21:23:41 CEST] <haasn> 2009
[21:23:45 CEST] <haasn> so it's been supported for 6 years
[21:38:04 CEST] <wm4> can libavcodec be used for jpg encoding in practice yet?
[21:38:49 CEST] <durandal_1707> off course you can use it
[21:39:35 CEST] <BtbN> hm, kind of want to push the cygwin configure fix. Nobody seems to care
[21:40:24 CEST] <iive> BtbN: ping the thread first...
[21:40:56 CEST] <BtbN> I think I might be the only one actually using cygwin
[21:41:29 CEST] <durandal_1707> why? Use mysys
[21:41:53 CEST] <BtbN> msys isn't nearly as nicely integrated as cygwin is
[21:42:09 CEST] <durandal_1707> huh?
[21:42:16 CEST] <BtbN> And I don't think msys has stuff like an X server and Windows Shell integration?
[21:42:23 CEST] <iive> BtbN: do cygwin binaries still require a cygwin library?
[21:42:37 CEST] <BtbN> iive, of course. That's kind of the whole point.
[21:42:48 CEST] <wm4> durandal_1707: does it have useful rate control? good quality? usable quality vs. size control?
[21:42:55 CEST] <BtbN> You can "cross compile" from cygwin, using mingw64-gcc, and get a normal binary.
[21:43:13 CEST] <BtbN> Or just msvc
[21:43:56 CEST] <durandal_1707> wm4: use -q 0
[21:43:58 CEST] <BtbN> But the nice thing about a cygwin-aware ffmpeg is that I can give it cygwin paths, and the tty emulation from cygwin makes the cli way nicer, with colors and keyboard interaction and stuff
[21:47:57 CEST] <Chloe> BtbN: are you sure POSIX_SOURCE only needs to be defined for cygwin?
[21:48:19 CEST] <Chloe> how does sigaction work on mingw?
[21:48:33 CEST] <BtbN> Chloe, it's defined for most other systems. But the libc autodetection fails for cygwin
[21:49:11 CEST] <Chloe> So has the cygwin build failed up until now?
[21:49:28 CEST] <BtbN> No, it definitely worked in the past.
[21:49:40 CEST] <BtbN> I guess since ffserver started using sigaction it's broken?
[21:50:09 CEST] <BtbN> hm
[21:50:11 CEST] <BtbN> "2002-06-10 02:44:36 +0000"
[21:50:14 CEST] <BtbN> nope, must be something else
[21:50:24 CEST] <Gramner> iirc _POSIX_C_SOURCE is required for mingw to use the C99/POSIX printf family implementations instead of the ancient microsoft ones
[21:50:55 CEST] <BtbN> _XOPEN_SOURCE is what sigaction is hidden behind on cygwin
[21:51:01 CEST] <Chloe> BtbN: It just seems odd that it suddenly requires _POSIX_C_SOURCE (hence me just inquiring a little)
[21:51:22 CEST] <BtbN> I think some change just made ffserver on cygwin start using sigaction
[21:51:31 CEST] <BtbN> Or some cygwin update put it behind that macro, also possible.
[21:51:49 CEST] <Gramner> sometimes using one feature test macro implicitly defines other ones as well
[21:52:40 CEST] <BtbN> It most likely was a cygwin update that broke it
[21:53:25 CEST] <jamrial> BtbN: don't use mintty from msys2 if you want colors and keyboard interaction. try defterm or conemu
[21:53:41 CEST] <jamrial> alternatively, winpty from within mintty
[21:53:48 CEST] <BtbN> I'm using MinTTY from Cygwin
[21:54:16 CEST] <BtbN> colors work fine if ffmpeg is built as cygwin binary
[22:03:34 CEST] <RiCON> winpty's also needed for keyboard interaction in ffmpeg/mpv
[22:05:20 CEST] <BtbN> cygwin has tty emulation built in, that's why it just works there
[22:06:55 CEST] <BtbN> I was kinda hoping the Ubuntu-On-Win10 thing would be interesting. But without the ability to launch windows applications from it, it's not too interesting for me.
[22:24:09 CEST] <flux> I would assume someone has written a launcher to do that.. seems like such a basic need.
[22:30:25 CEST] <Gramner> yeah, I'm not seing much point of the windows 10 bash implementation in it's current state. might as well run a VM if you can't interact with native windows applications anyway
[23:00:34 CEST] <BtbN> That's what's so nice about cygwin.
[23:00:43 CEST] <BtbN> For what it's worth, it looks like a linux API wise
[23:00:51 CEST] <BtbN> but nothing stopy you from dlopen'ing a dll
[23:54:54 CEST] <BtbN> Doesn't ffmpeg use yasm/nasm on pretty much all platforms?
[23:55:41 CEST] <BtbN> Because I just discovered that on Gentoo it's tied to x86/amd64 and mmx support for some reason: https://github.com/gentoo/gentoo/blob/master/media-video/ffmpeg/ffmpeg-9999.ebuild#L254
[23:56:03 CEST] <Chloe> BtbN: i thought it was x86(_64) only
[23:56:05 CEST] <jamrial> nasm/yasm is x86 only
[23:56:15 CEST] <BtbN> what's used on arm and the like?
[23:56:36 CEST] <jamrial> gas probably
[23:57:06 CEST] <BtbN> hm, so the mmc dependency is probably a hack for not having to specify it twice :D
[23:57:08 CEST] <BtbN> *mmx
[23:58:21 CEST] <jamrial> no, it's probably a remnant from old ebuilds
[23:59:06 CEST] <jamrial> afaik, --{dis,en}able-mmx is older than --{dis,en}able-asm and --{dis,en}able-yasm
[23:59:41 CEST] <BtbN> I can't immediately think of a good check for amd64 || x86
[23:59:49 CEST] <BtbN> so the mmx check is quite a nice workaround
[00:00:00 CEST] --- Sun Oct  2 2016