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

[burek]

[00:03:09 CET] <SortaCore> h264_qsv doesn't like ending empty packets, "h264_qsv : A decode call did not consume any data: expect more data at input (-10)" and "avcodec_send_frame failed with error -11: Resource temporarily unavailable"
[00:10:55 CET] <SortaCore> but it is marked with cap delay, so it needs a null packet to flush
[00:14:17 CET] <SortaCore> seems to die since a couple weeks ago and 31de45d
[00:15:36 CET] <cone-097> ffmpeg 03Carl Eugen Hoyos 07master:ed4a0c7923e8: ffmpeg_opt: Constify hwaccel pointer.
[00:19:23 CET] <cone-097> ffmpeg 03James Zern 07master:86cead525633: libvpxenc,vp9: add corpus-complexity option
[00:39:42 CET] <whysohard> Hi guys. For years I couldn't understand. Ffmpeg is very powerful. But it cannot handle with a very simple trim case: Trim end of file.. There are several commands -ss -sseof -t... But it's not sufficient. There is a question about that: https://stackoverflow.com/questions/31862634/i-need-to-cut-mp4-videos-a-part-at-the-beginning-and-a-part-at-the-end-in-a-bat The solution is sooo complex. Why we dont have an easy single comma
[00:42:49 CET] <SortaCore> because formats are written to be read from beginning to end?
[00:43:59 CET] <whysohard> Couldn't ffmpeg read total length?
[00:44:23 CET] <whysohard> It's very vital and common request... You know, almost all video have unnecessary scenes of the end. I think an average user should done easy with ffmpeg... Is this improvement so hard?
[00:45:10 CET] <SortaCore> does the codec format have total length in it?
[00:45:25 CET] <SortaCore> does it indicate the byte offsets of the last frames and have an index for them?
[00:45:40 CET] <SortaCore> at what point from end of file and last frame minus n frames should the data be stored for?
[00:46:04 CET] <SortaCore> how large are frames? fixed? compressed? keyframes, partial?
[00:46:09 CET] <whysohard> Wow. I started to understand now
[00:46:32 CET] <SortaCore> the formats of most are to be read from start of file to end of file
[00:46:58 CET] <SortaCore> the best you can do is look for a frame start marker at a best guess from end of file - if the format has one for frames
[00:47:07 CET] <SortaCore> then you have to hope it's a frame you can terminate on
[00:47:26 CET] <SortaCore> otherwise you may have to rearrange due to gop size
[00:47:42 CET] <whysohard> Thank you SortaCore. You're great pathfinder
[00:47:55 CET] <SortaCore> plus there's the complication that even if the file stores duration in the header, as in time, that will need recalculating
[00:48:05 CET] <SortaCore> and sometimes frames are decoded and stay on screen longer than previous frames
[00:48:14 CET] <SortaCore> so... basically it's super annoyingly complex
[00:48:30 CET] <SortaCore> you might be able to find a format that's well-equipped for trimming from end, though
[00:48:50 CET] <SortaCore> and increasing number of keyframes makes seeking to a particular time easier, so logically seeking from end would be easier too
[00:49:09 CET] <whysohard> Therefore we need to have ffprobe.. 
[00:49:17 CET] <SortaCore> yea
[00:49:29 CET] <SortaCore> actually, there's a thing called steganography that exploits footer/header formats
[00:49:35 CET] <whysohard> For years I never understand. Now it's so clear.
[00:49:41 CET] <SortaCore> you can append a zip file to a bmp file
[00:49:53 CET] <SortaCore> a zip file stores its details in the end, a bmp in the start
[00:50:05 CET] <SortaCore> so you can read both by just renaming the extension
[00:52:19 CET] <whysohard> Yes I tried now. Thank you very much SortaCore 
[00:52:27 CET] <SortaCore> most video file formats are compressed, so frame byte size varies - some have varying levels of compression, so varies again - most have partial frames only showing what's changed since the last full frame...
[00:52:42 CET] <SortaCore> np, it's just you've asked this a lot
[00:52:53 CET] <SortaCore> it's more complicated that I'm making out - I'm not even a ffmpeg developer
[00:52:54 CET] <iive> SortaCore: cutting at the end is easier that cutting from the start
[00:53:17 CET] <SortaCore> now you've just confused him again
[00:53:21 CET] <iive> especially if yo do stream copy (not reencoding)
[00:53:24 CET] <whysohard> Haha
[00:53:47 CET] <iive> yeh
[00:53:58 CET] <jdarnley> > Is this improvement so hard?
[00:54:08 CET] <SortaCore> y'all should improve it
[00:54:10 CET] <jdarnley> Why don't you try it?
[00:54:15 CET] <SortaCore> negative start time let's go
[00:54:58 CET] <whysohard> Wait a minute. How works sseof command? IF It can easily crop from the end, why we don't "cut out".... (Sorry for my english, I hope you understand)
[00:59:13 CET] <SortaCore> why does h264_qsv fuss when you pass null packet to flush the stream?
[01:00:18 CET] <JEEB> someone overlooked that thing most likely
[01:00:59 CET] <SortaCore> I'm 70% sure it was a bug added in last couple of weeks' commits
[01:01:15 CET] <JEEB> alright, oppan bisect time then
[01:01:35 CET] <JEEB> I've got my own weird fixations that I need to take care of unfortunately
[01:01:43 CET] <JEEB> or you find the maintainer and poke that person
[01:01:56 CET] <JEEB> although if you want to be helpful a bisect is always nice
[01:01:56 CET] <SortaCore> how do you check the commits for qsv changes?
[01:02:19 CET] <SortaCore> I don't have a link for that, and because I messed with patching I don't know the commit hash for the working one
[01:03:17 CET] <JEEB> I usually use gitk as that's the least insane graphical UI for git that doesn't try to do Various Things (`gitk -- libavcodec/stuff*.c`)
[01:03:27 CET] <JEEB> git log can do it on command line in a similar manner
[01:03:48 CET] <JEEB> and github/git.videolan.org has history for specific files
[01:04:00 CET] <JEEB> if something spans multiple files it gets less simple though
[01:04:38 CET] <JEEB> that will leave out any other generic changes that happen to hit an issue with the qsv thing
[01:05:04 CET] <whysohard> Sorry to interrupt, what happen now? Should I write a request to bugtrack? Is this development (a new command to delete X seconds from the end) possible or impossible?
[01:06:05 CET] <JEEB> whysohard: if it's a generic "X seconds before end" ffmpeg.c and raw lavf can't do it
[01:06:14 CET] <JEEB> if you have a specific timestamp that is possible
[01:07:02 CET] <JEEB> for specifics like that I recommend something like ffms2 that indexes files before hand (it uses lavf underneath). of course requires decoding and encoding, so copying is not possible
[01:07:37 CET] <JEEB> ffmpeg.c and lavf work purely A->B and you can only know a duration if the file format you're dealing with has such data in it
[01:07:59 CET] <JEEB> so with something like mpeg-ts you are bound to get derps
[01:08:06 CET] <JEEB> because ffmpeg.c will try to guess
[01:08:14 CET] <JEEB> or closer to home, stuff like raw mp3 files
[01:08:54 CET] <JEEB> you can request a feature of following the guessed duration blindly, but I bet people will then file bug reports when the value is guessed
[01:09:24 CET] <whysohard> Haha you're right.
[01:09:44 CET] <JEEB> not that it's impossible to index stuff like ffms2 does and do stream copy
[01:09:54 CET] <JEEB> it's just that ffmpeg.c is not an indexing tool
[01:10:33 CET] <whysohard> Thanks a lot JEEB. I really learn the real reasons. 
[01:11:07 CET] <JEEB> you could make a tool on top of lavf/lavc for such cutting, of course
[01:11:19 CET] <JEEB> it would index first, then let you do stuff
[01:11:43 CET] <JEEB> that way it wouldn't make ffmpeg.c even a bigger badonkadonk than it currently is :)
[01:11:57 CET] <JEEB> and people would get their expected results since the files would be indexed
[01:12:09 CET] <JEEB> someone just needs to care.jpg
[01:12:23 CET] <whysohard> Hahah
[01:12:41 CET] <SortaCore> I think jamrial is the culprit?
[01:13:05 CET] <SortaCore> he changed error returns in qsv
[01:13:16 CET] <JEEB> vOv
[01:13:46 CET] <JEEB> of course the actual error might be in some vaguely related place which was hidden before, not that I've looked at the context
[01:14:06 CET] <JEEB> and it doesn't mean that it shouldn't be fixed. just that the fix isn't always "revert it" :)
[01:14:13 CET] <SortaCore> I'll dig some more
[01:14:29 CET] <SortaCore> I suspect the changes are fine there's just exception for flushing
[01:14:39 CET] <SortaCore> expecting more data is fine when not flushing, after all
[01:15:11 CET] <whysohard> JEEB: Thank you for your valuable comments. I wish everyone could read it. I totally understand what it is. Thank you so much.
[01:15:28 CET] <JEEB> whysohard: so you were asking for "-20 seconds from the end" kind of thing?
[01:15:32 CET] <JEEB> which is the hard thing
[01:15:50 CET] <whysohard> Yep..
[01:15:53 CET] <JEEB> yup
[01:16:17 CET] <tmm1> SortaCore: did you figure out how to fix those random device failed errors?
[01:16:17 CET] <JEEB> the simple thing is "continue until X seconds/minutes/hours" because you can just keep on rolling until you hit the timestamp
[01:16:30 CET] <SortaCore> Not yet, it seems to be a matter of timing
[01:16:45 CET] <SortaCore> my app can sometimes run too slowly and get it upset
[01:17:06 CET] <SortaCore> having said that, I've not experienced it since the last master update, either
[01:17:23 CET] <SortaCore> err, *last git pull
[01:18:50 CET] <whysohard> Ignorance is bliss... For years I think it's very very easy, just a developer writes 3-5 lines and the problem is solved
[01:19:48 CET] <JEEB> whysohard: if you don't care about the details (making it properly work) it would be something like that :P and it would work with at least a couple of file formats
[01:20:05 CET] <SortaCore> whysohard that does imply either no one needs it, or not enough people need it for ffmpeg guys to develop it
[01:21:50 CET] <whysohard> Yes I see. You have serious responsibilities. There must always be situations that need to work.. Thank you guys again. Time to go for me. I hope anyone can search and find tese information from logged chat text
[01:22:21 CET] <SortaCore> you could post on codeproject site
[01:22:33 CET] <SortaCore> *stackoverflow
[01:28:25 CET] <SortaCore> err JEEB when did you help me with patches?
[01:28:43 CET] <SortaCore> I can use that for filtering the commits
[01:34:10 CET] <SortaCore> could AV_CODEC_CAP_AVOID_PROBING have a change on the flush?
[01:40:41 CET] <SortaCore> I'm gonna jump in the call stack and see what line makes the error
[02:14:24 CET] <SortaCore> err... wot
[02:16:18 CET] <SortaCore> rtsp demuxer is avcodec_receive_frame() a YUV420P frame straight into a NV12 AVFrame
[02:18:20 CET] <SortaCore> are you meant to be able to do that?
[02:55:00 CET] <atomnuker> oh wow, the ML broke the jan 2016 record and now it has the most emails since oct 2015 (which had 2700)
[02:55:45 CET] <SortaCore> admit it I carried you all
[02:55:54 CET] <SortaCore> (no but seriously what's up with NV12)
[03:14:18 CET] <raytiley_> i'm messing around with ffmpeg to generate HLS from a deckling card using dshow. I think i'm seeing the bitrit of the files grow if the decklink card doesn't get video for a while and x264 is encoding black frames... the output is still working ok.. the files are just oo big
[03:14:25 CET] <raytiley_> does that make sense?
[03:17:16 CET] <raytiley_>   `-c:v libx264 -x264opts keyint=60:no-scenecut -s 416x234 -r 29.97 -b:v 200k -preset ultrafast -profile:v main -level 3.0 -pix_fmt yuv420p -y -c:a aac -ar 48000 -hls_list_size 5 out.ts` is the output part of the command i'm using
[03:20:19 CET] <raytiley_> oops wrong channel, sorry
[03:34:54 CET] <SortaCore> I shall afk and hope someone answers by tomorrow
[04:47:57 CET] <cone-178> ffmpeg 03Dale Curtis 07master:a3a0b5bd0aaa: avformat/oggparseopus: Free opus extradata before reallocating.
[04:52:53 CET] <cone-178> ffmpeg 03Dale Curtis 07master:c5fd57f483d2: Don't manipulate duration when it's AV_NOPTS_VALUE.
[05:42:44 CET] <atomnuker> michaelni: what does need to be atomic when registering filters
[05:43:30 CET] <atomnuker> as far as I see, **f points to a place in an array and writing to that array needs to be atomic, right (e.g. *f = filter_next)
[07:00:34 CET] <stevenliu> Hello guys?
[07:00:44 CET] <stevenliu> https://patchwork.ffmpeg.org/patch/6244/  can this patch be pushed?
[07:33:33 CET] <cone-178> ffmpeg 03Jeyapal, Karthick 07master:62f63b24bfec: libavformat/avio: Utility function to return URLContext
[07:33:34 CET] <cone-178> ffmpeg 03Jeyapal, Karthick 07master:4ddf7476c009: libavformat/http: Handled multiple_requests option during write
[07:33:35 CET] <cone-178> ffmpeg 03Jeyapal, Karthick 07master:815e34b5b4ed: libavformat/hlsenc: Persistent HTTP connections supported as an option
[07:39:26 CET] <atomnuker> stevenliu: no, the function needs to start with ff_io rather than ffio_ or whatever
[07:46:50 CET] <stevenliu> ......
[07:47:34 CET] <atomnuker> well its for consistency reasons, all around the code all functions start with ff_<stuff> rather than ff<stuff>
[07:48:46 CET] <atomnuker> oh wait, nervermind, ffio stuff is excluded
[07:49:22 CET] <stevenliu> libavformat/aviobuf.c there have samples api name: ffio_ensure_seekback
[07:50:04 CET] <stevenliu> so the name maybe reference the ffio_ensure_seekback , so he make the name "ffio_geturlcontext"
[07:50:20 CET] <stevenliu> ok
[07:50:40 CET] <stevenliu> Thanks :D
[09:50:57 CET] <atomnuker> is there some ptwo fft which needs avx2?
[10:53:48 CET] <cone-040> ffmpeg 03Pan Bian 07master:eb69e7bed80a: avcodec/nvenc: set correct error code
[12:45:27 CET] <cone-040> ffmpeg 03Karthick J 07master:da49cdf6401e: avformat/hlsenc: Modularized playlist creation to allow reuse
[14:34:49 CET] <SortaCore> best codec?
[14:36:40 CET] <thardin> cinepak
[14:43:39 CET] <SortaCore> motion carries
[14:43:45 CET] <SortaCore> all other codecs are now outlawed
[14:44:45 CET] <thardin> hooray!
[14:45:30 CET] <SortaCore> on a vote of 1 to 0 with  abstaining
[15:13:31 CET] <ubitux> anyone has a 1:1 pixel filter in mind in the codebase that's not component based (that is, that can not be solved with a lut3d)?
[15:13:36 CET] <ubitux> other than... lut3d
[15:13:59 CET] <ubitux> i'd say filters like colormatrix but i'm looking for something more "shiny"/visible
[15:14:18 CET] <ubitux> s/can not be solved with a lut3d/can not be solved with a lut *2D*/
[15:14:23 CET] <ubitux> (but can with a lut3d)
[15:14:49 CET] <ubitux> mmh, maybe selectivecolor could do the trick
[15:24:39 CET] <atomnuker> ubitux: yeah, many, but they can all be solved by convolve
[15:28:02 CET] <durandal_1707> glitch filters
[15:55:50 CET] <Compn> ehe
[15:56:07 CET] <Compn> i think my reply to jim delahunt will fix some things...
[16:33:21 CET] <BBB> wm4: about that patch, I think jamrial sent that a while ago also, if we remove the parser (or splitting in the parser) Im fine with it
[16:33:35 CET] <BBB> wm4: if we keep the splitting in the parser, I feel were doing redundant operations which is silly
[16:33:40 CET] <jamrial> i didn't send it
[16:33:43 CET] <BBB> hm
[16:33:44 CET] <BBB> someone did
[16:33:58 CET] <wm4> BBB: I can certainly disable the parser in the mkv demuxer
[16:34:11 CET] <wm4> I'm using vp9 without parser in my own mkv demuxer too (now)
[16:34:11 CET] <BBB> I meant disable the splitting in the parser
[16:34:21 CET] <wm4> hm
[16:34:25 CET] <BBB> the parser could still be useful for identifying keyframes etc.
[16:34:36 CET] <BBB> I dont know if that makes sense
[16:34:43 CET] <BBB> remove the parser altogether is fine also IMO
[16:34:52 CET] <BBB> but it might be useful for some fringe scenarios (?)
[16:34:58 CET] <wm4> I think while we still have both BSFs and parsers, we can't create anything logically clean anyway
[16:35:15 CET] <wm4> I think in the end we'll probably remove all parsers for BSFs?
[16:35:28 CET] <wm4> in 20 years or so
[16:35:31 CET] <BBB> :-p
[16:36:17 CET] <jamrial> just remove/disable the splitting part from the parser
[16:36:27 CET] <jamrial> but yeah, i think the idea was for that kind of manipuation to be done in bsfs and leave the parsers for simpler stuff, so the parser api can be replaced by an avpacket based one
[16:36:36 CET] <jamrial> eventually(tm)
[16:36:51 CET] <BBB> I wonder if you can just remove the whole parser
[16:36:55 CET] <BBB> I dont think it does anything else
[16:36:58 CET] <BBB> maybe keyframe identification
[16:37:15 CET] <jamrial> it does that, yeah
[16:37:24 CET] <BBB> I think all you need to keep is the top half of parse-frame
[16:37:27 CET] <BBB> parse_frame()
[16:37:31 CET] <wm4> raw video?
[16:37:47 CET] <BBB> the bottom half (pts mangling) can be removed, including reading the invisible bit
[16:37:56 CET] <BBB> and parse itself can just call parse_frame() and return
[16:38:08 CET] <BBB> then patch is fine with me (assuming this doesnt break anything)
[16:38:22 CET] <wm4> according to mkvdec we parse all video streams, even h264, except hevc (???)
[16:38:49 CET] <wm4> BBB: you mean patch is fine as is?
[16:39:05 CET] <BBB> delete most of vp9_parser.c
[16:39:07 CET] <BBB> then its fine
[16:39:58 CET] <nevcairiel> mkvdec used to exclude h264 as well some time ago, but someone probably found some broken mkv that got fixed by it, not that the parser really does anything on frames that are in mp4-style syntax
[16:40:00 CET] <BBB> if you dont delete vp9_parser.c splitting, a problem is that I will never call that splitting code in the BSF, because the parser splits for my uses, so my code coverage becomes different from yours, which complicates bug fixing/finding
[16:40:10 CET] <BBB> thats why Im asking to delete the splitting from vp9_parser.c
[16:40:16 CET] <BBB> it makes my life easier when you find bugs
[16:40:43 CET] <wm4> why is ffmpeg's policy "eat shit"
[16:41:01 CET] <BBB> huh?
[16:41:02 CET] <wm4> (except for subtitle encodings, because of nicolas george)
[16:41:28 CET] <wm4> regarding attempting to read every broken file (but also in broader aspects)
[16:42:05 CET] <wm4> BBB: so, remind me how the parser works... does it make extra effort to separate out superframes?
[16:42:11 CET] <BBB> ys
[16:42:12 CET] <BBB> yes
[16:42:26 CET] <BBB> http://ffmpeg.org/doxygen/trunk/vp9__parser_8c_source.html
[16:42:40 CET] <BBB> delete line 64-72
[16:43:06 CET] <BBB> delete line 116-161
[16:43:26 CET] <BBB> and I think you can delete VP9ParserContext entirely, and all behaviour stemming from that
[16:43:42 CET] <BBB> like line 92-114
[16:44:07 CET] <nevcairiel> the entire parse function should basically be emptied and replaced by parse_frame
[16:44:15 CET] <BBB> so youre left with half of parse_frame(), line 85-90, line 162-165
[16:44:20 CET] <BBB> yes, basically
[16:44:30 CET] <BBB> it becomes an extremely stupid simple little parser that detects keyframes
[16:44:36 CET] <nevcairiel> although i dont know if parse_frame needs to be updated to handle super frames
[16:44:41 CET] <BBB> so you can remux ivf (which has no keyframe markers) into avi (which does)
[16:44:47 CET] <nevcairiel> since those apparently have a prefix marker
[16:44:51 CET] <BBB> no, keyframes are never in superframes
[16:44:55 CET] <nevcairiel> oh wait its a postfix marker
[16:44:57 CET] <BBB> and the marker is at the end
[16:44:59 CET] <BBB> so its fine
[16:45:12 CET] <nevcairiel> sounds good then
[16:45:21 CET] <BBB> :)
[16:46:22 CET] <wm4> it's not clear to me where it reads the frame size
[16:47:39 CET] <nevcairiel> all sources of vp9 come from properly packeted formats, so packet size = frame size
[16:48:11 CET] <wm4> so it's not possible to parse a concatenated byte stream, and the parser can't eat that?
[16:48:20 CET] <nevcairiel> no
[16:48:25 CET] <wm4> great
[16:48:35 CET] <nevcairiel> thats why ivf exists, a  super lightweight container that has packet sizes for you
[16:48:50 CET] <wm4> yeah I think I remember about this
[16:48:57 CET] <wm4> that makes it indeed very trivial
[16:49:59 CET] <kierank> wm4: welcome back
[16:50:41 CET] <BBB> have you guys confirmed that frame-mt works correctly with the bsf? I have no doubt that it does but just to make sure
[16:52:11 CET] <wm4> I mean it looks non-corrupted
[16:55:37 CET] <wm4> kierank: sort of
[16:57:33 CET] <wm4> BtbN: would you be against moving cuda headers to an external repo?
[16:57:56 CET] <wm4> is fate-source failing in git master
[16:58:24 CET] <BtbN> wm4, not a fan of it at least.
[16:58:37 CET] <durandal_1707> where is it failing ?
[16:58:59 CET] <BtbN> And so far it only seems to be one person on the ML who is actually strongly against the headers?
[16:59:00 CET] <nevcairiel> yean fate-source seems broken since that recent hls commit
[16:59:01 CET] <jamrial> libavformat/hlsplaylist.h
[16:59:05 CET] <wm4> why do we even have this useless test
[16:59:09 CET] <wm4> oh right, because of michaelni 
[16:59:27 CET] <jamrial> to find missing header wrappers, for example
[16:59:28 CET] <nevcairiel> it wouldnt be so useless if people were to actually run it before pushing to find their mistakes =p
[16:59:44 CET] <wm4> pretty hilarious... 1 hour of having returned and I already hit multiple things that made me leave before
[17:00:18 CET] <jamrial> a grep test on headers is the last thing that should make people angry, imo :p
[17:00:38 CET] <wm4> I don't even know why the test fails
[17:00:50 CET] <wm4> that would mean digging into fate's shitty sources and probably inspecting some horrible regexp
[17:00:58 CET] <durandal_1707> every header should have copyright and license
[17:00:59 CET] <nevcairiel> because that header there has wrong include guards
[17:01:03 CET] <nevcairiel> or license
[17:01:05 CET] <nevcairiel> one of those
[17:01:21 CET] <wm4> the license looks correct
[17:01:36 CET] <wm4> except it has the name of a TRAITOR (as cehoyos would put it) in it
[17:01:45 CET] <nevcairiel> the include guard is wrong
[17:01:47 CET] <jamrial> it's the wrapper
[17:01:49 CET] <nevcairiel> has an extra _ at the end
[17:01:50 CET] <wm4> correction, a LIAR AND TRAITOR
[17:01:51 CET] <jamrial> yeah
[17:01:57 CET] <wm4> (add mouth foam)
[17:02:30 CET] <kierank> wm4: it's actually liars and thieves
[17:02:33 CET] <kierank> get it right
[17:03:01 CET] <wm4> oh right
[17:03:10 CET] <wm4> my error
[17:03:22 CET] <cone-254> ffmpeg 03James Almer 07master:85b84e124330: avformat/hlsplaylist: fix header include guard
[17:04:03 CET] <jamrial> meh, it's also missing a lot of inlcude headers, like avio.h
[17:04:10 CET] <jamrial> checkheaders will fail as is
[17:04:18 CET] <nevcairiel> luckily fate doesnt run that =p
[17:04:40 CET] <jamrial> ubitux has one client running it :p
[17:04:47 CET] <jamrial> but yeah, it's not part of make fate
[17:04:57 CET] <jamrial> but it is part of make check
[17:05:28 CET] <jamrial> i think a libav commit tried to add it to make fate but i sort of skipped it
[17:06:22 CET] <wm4> poor AMD person
[17:06:40 CET] <wm4> BBB: nice, fate passes with the parser change
[17:06:52 CET] <BBB> tests are awesome! \o/
[17:07:23 CET] <jkqxz> checkheaders is not part of make check in ffmpeg.  (I've been caught out by thinking it was.)
[17:07:28 CET] <jkqxz> It probably should be.
[17:07:53 CET] <jkqxz> (And everyone should run "make check" before pushing, y'know.)
[17:07:54 CET] <jamrial> jkqxz: as i said, i think i didn't merge that. but i can look into it if you want
[17:08:56 CET] <wm4> BBB, jamrial: parser change sent
[17:09:21 CET] <BBB> I thought you said it failed fate?
[17:09:25 CET] <BBB> or was it a typo?
[17:09:30 CET] <BBB> oh wait
[17:09:30 CET] <BBB> duh
[17:09:32 CET] <BBB> I cant read
[17:09:35 CET] <wm4> no it failed for this hls thing
[17:09:35 CET] <nevcairiel> lol
[17:09:42 CET] <cone-254> ffmpeg 03James Almer 07master:91127355f586: avformat/hlsplaylist: add missing header includes
[17:09:50 CET] <jkqxz> wm4:  The AMD support is already autodetected.  (If you have the headers.)
[17:10:11 CET] <BBB> Id better become a manager quickly or else my career is going downhill from here
[17:10:51 CET] <nevcairiel> any feature without a fixed runtime linkage dependency can realistically just auto-enable if headers are available, with linking it should preferably not, imho
[17:11:11 CET] <BBB> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/thread.html ???
[17:11:13 CET] <BBB> how did that happen
[17:11:32 CET] <nevcairiel> intel lives in the future
[17:11:33 CET] <iive> intel have time machine
[17:11:33 CET] <wm4> it wasn't me
[17:11:42 CET] <jamrial> he blew his cover and now we know he's from the future
[17:11:45 CET] <wm4> maybe it thinks it was february
[17:11:47 CET] <nevcairiel> it just takes the emails date, not receiving date
[17:12:00 CET] <BBB> I wish I was as smart as intel
[17:12:01 CET] <nevcairiel> and email date is specified by the sneder
[17:12:21 CET] <wm4> I should randomize my email dates
[17:12:50 CET] <nevcairiel> just dont have it way in the past, or your mail may get sorted on page 128 of my inbox
[17:13:21 CET] <BtbN> Is anyone against me creating a repository on the github FFmpeg organization for the nvidia-video-sdk headers? And what would be a good name for it? I'm thinking of just nvidia-sdk, but that might be a copyright issue?
[17:13:38 CET] <wm4> BtbN: I think that'd be great...
[17:13:39 CET] <jamrial> ffnvidia
[17:13:44 CET] <BtbN> nah
[17:13:53 CET] <wm4> not sure if it should be nvidia specific or just a collection repo where we dump crap
[17:14:10 CET] <wm4> (for avisynth too)
[17:14:12 CET] <jkqxz> nevcairiel:  Lots of features with linking are auto-enabled.  I agree they probably shouldn't (because it has surprise dependency on the build machine), but there is a lot of inertia and me-too for it.
[17:14:23 CET] <nevcairiel> ffmpeg-contrib-headers
[17:14:24 CET] <nevcairiel> no idea
[17:14:45 CET] <nevcairiel> jkqxz: luckily ubitux made us an option to disable all autodetected crap now
[17:15:07 CET] <wm4> is ffcuda still auto enabled on osx?
[17:15:08 CET] <nevcairiel> oss projects configure and build systems are never designed for portable binaries
[17:15:14 CET] <BtbN> I'd kind of like to keep them seperate, and give the nvidia headers a proper Makefile and pkg-config
[17:15:21 CET] <jamrial> autodetect right now is only for "system" libraries and hardware stuff
[17:15:21 CET] <wm4> BtbN: fine
[17:15:28 CET] <BtbN> As they can indeed by usefull for non-ff projects
[17:15:30 CET] <nevcairiel> why a makefile, its not like it needs to build anything
[17:15:35 CET] <ubitux> wm4: it shouldn't with --disable-autodetect
[17:15:36 CET] <BtbN> Just for make install
[17:16:43 CET] <jamrial> wm4: make sure to remove the stray hls change before pushing the vp9 parser change :p
[17:16:55 CET] <jamrial> i'll leave the real review to BBB
[17:16:57 CET] <nevcairiel> jamrial: on osx it pulls in a whole lot of shit with relatively high os version requirements tho
[17:17:31 CET] <BBB> wm4: lgtm
[17:17:32 CET] <BBB> tnx
[17:17:37 CET] <wm4> jamrial: oh damn, I intended to remove it by rebasing but forgot that
[17:18:19 CET] <jamrial> nevcairiel: the videotoolbox and avfoundation stuff?
[17:18:35 CET] <wm4> jamrial: also ok?
[17:18:44 CET] <wm4> for the vp9 patches
[17:18:54 CET] <nevcairiel> jamrial: all sorts of frameworks get pulled in from all of those, mostly avfoundation i guess
[17:19:05 CET] <jamrial> wm4: yeah
[17:19:49 CET] <BtbN> Anyone against FFNV-Video-SDK? That avoids having nvidia in there, which could cause issues with name trademarks.
[17:20:13 CET] <cone-254> ffmpeg 03wm4 07master:a5679933c1b8: vp9: use superframe split BSF
[17:20:14 CET] <cone-254> ffmpeg 03wm4 07master:0c162854c1fa: vp9_parser: don't split superframes into separate packets
[17:20:28 CET] <jamrial> with this there's no way to mux split vp9 packets on matroska/mp4 by accident anymore, so maybe the autobsf on muxer level can remain optional
[17:20:29 CET] <atomnuker> BtbN: ffmpeg-contrib-headers + a configure/make file to specify which headers to install then?
[17:20:45 CET] <iive> BtbN: if it is only headers, then it would be good to have "headers" in the name. 
[17:20:56 CET] <BtbN> iive, well, the video codec SDK is only headers.
[17:21:21 CET] <nevcairiel> the official sdk download is a whole bunch of docs and example apps
[17:21:25 CET] <iive> BtbN: sdk could include libraries, documentation and examples
[17:21:34 CET] <jamrial> also, as atomnuker and nevcairiel said, is it going to be for nvidia headers only, or for all? (amd, nvidia, avisynth)
[17:21:48 CET] <atomnuker> I'd like one for all
[17:21:52 CET] <BtbN> atomnuker, I'd really prefer to keep them seperate, as distributions will need to package them, and a meta-thing with a bunch of unrelated stuff might cause issues
[17:22:09 CET] <durandal_1707> we could include ladspa and libmysofa header
[17:22:17 CET] <jkqxz> Basically everyone else already has a proper repository for their headers.
[17:22:25 CET] <nevcairiel> personally i would prefer one for all, we dont want to create 100 repos for all sorts of crap
[17:22:44 CET] <atomnuker> because who's going to package the avisynth headers
[17:22:48 CET] <BtbN> Specially with nvidia, there could be a reason to build with an older version of that header, since it keeps compatiblity with old drivers
[17:22:53 CET] <jkqxz> So I think this is just nvidia, though it could be the avisynth ones as well.
[17:23:04 CET] <jamrial> durandal_1707: no, such libraries are not dinamically loaded, nor part of a normal system
[17:23:06 CET] <nevcairiel> its not like  ffmpeg works with older headers
[17:23:10 CET] <BtbN> So if you have all of them in one repo, you cannot just downgrade the nvidia headers without jumping through some hoops
[17:23:28 CET] <BtbN> Well, with the next bump and the headers being external, I'd certainly try to keep compatiblity.
[17:23:41 CET] <iive> BtbN: what is the full name of the sdk and full name of the "technology" used?
[17:23:52 CET] <BtbN> Video-Codec-SDK
[17:23:58 CET] <jkqxz> nevcairiel:  That's only because the headers were packaged so you had to use a particular version.  (One of the problems with packaging the headers.)
[17:24:19 CET] <nevcairiel> iive: https://developer.nvidia.com/nvidia-video-codec-sdk
[17:24:21 CET] <iive> BtbN: but it is about gpu video, right?
[17:24:33 CET] <BtbN> It's about the video codec stuff on nvidia cards.
[17:24:34 CET] <philipl> Although I really want to keep the headers in tree, if we have to move them out, can we at least set up a submodule to pull them in?
[17:25:01 CET] <iive> BtbN: how about "NVCodec-headers" ?
[17:25:44 CET] <BtbN> The headers are the full SDK. There's not more to it. Only docs and examples are missing pretty much
[17:26:37 CET] <philipl> BtbN: If you pull them in as a submodule, you specify which hash in the external repo to use, so we could keep the tight coupling and avoid compatibility games.
[17:26:59 CET] <BtbN> I'm pretty sure making them a submodule won't find any acceptance.
[17:27:17 CET] <wm4> submodules suck too much
[17:27:18 CET] <philipl> submodules can be left uninitialised so it doesn't force inclusion.
[17:27:27 CET] <philipl> This might be the one place where a submodule is actually useful
[17:27:32 CET] <atomnuker> BtbN: --enable-cuda-header-vN which makes the makefile apply a patch?
[17:27:34 CET] <nevcairiel> submodules dont solve anything, then everyone still wants the same treatment because unfair
[17:28:11 CET] <nevcairiel> and you still need a commit in ffmpeg when they get updated, so might as well keep them itnernal
[17:28:31 CET] <philipl> I did say I was in favour of keeping them internal :-)
[17:28:47 CET] <BtbN> atomnuker, what?
[17:31:07 CET] <BtbN> I don't see what the advantage of an external repository for contrib headers is, over having them in-tree.
[17:32:13 CET] <wm4> do you want all the AMD headers in tree? and probably more such cases to come?
[17:34:04 CET] <BtbN> I'd like to have them in proper repositories for themselves. Ideally in one made and maintained by AMD.
[17:34:27 CET] <atomnuker> how about they distribute the damn headers with their binaries?
[17:34:53 CET] <BtbN> The drivers? Unlikely to happen. Nobody would package them.
[17:35:42 CET] <atomnuker> I mean e.g. the nvidia binary driver to also install a cuvid header
[17:35:57 CET] <atomnuker> distros package the binary drivers
[17:36:36 CET] <atomnuker> thinking about it the kernel people have a very similar problem
[17:37:00 CET] <atomnuker> to run the proprietary blobs nvidia ship a wrapper which is a kernel module
[17:37:08 CET] <atomnuker> which users need to compile themselves
[17:37:40 CET] <atomnuker> which breaks pretty much on every new kernel release because more and more symbols get flagged as gpl
[17:37:53 CET] <BtbN> In most cases, the one building ffmpeg is not the one running it and having an nvidia card.
[17:38:10 CET] <atomnuker> oh, right
[17:38:23 CET] <BtbN> So if you'd have to download a whole 500MB driver just to get those headers, that'd be definitely not nice
[17:41:12 CET] <wm4> yeah but you just need to extract them and out them into a git or so
[17:41:17 CET] <wm4> no custom changes
[17:41:30 CET] <iive> that's what he is going to do
[17:41:39 CET] <iive> we are just looking for a nice name of the repo
[17:42:13 CET] <iive> BtbN: so, would you be happy with "nvcodec-sdk-headers" ?
[17:42:47 CET] <BtbN> No, because only calling it headers is missleading. It is the whole SDK, everything you need to develope with their APIs
[17:43:00 CET] <nevcairiel> its not misleading, it only contains headers
[17:43:15 CET] <nevcairiel> an SDK is more then headers, its docs and examples
[17:43:26 CET] <iive> BtbN: so you are oging to put documentation there?
[17:43:37 CET] <nevcairiel> calling it just "sdk" i would expect all the extra stuff besides headers to also be included
[17:44:08 CET] <philipl> Are we including the dynlink cuda stuff in this discussion? that's not nvidia code - BtbN wrote it
[17:44:09 CET] <BtbN> I cannot create repositories anyway, so do whatever
[17:44:55 CET] <iive> BtbN: i thought you are making github one
[17:45:08 CET] <BtbN> like I said, I can't create repositories.
[17:46:01 CET] <nevcairiel> at least you're part of the organization, so you're closer then anyone =p
[17:46:39 CET] <iive> sorry, I thought everybody could create a repo in github. What am I missing?
[17:47:02 CET] <nevcairiel> its supposed to be part of the ffmpeg org
[17:47:04 CET] <BtbN> No idea who has enough access to create a new repository, I guess michaelni?
[17:47:19 CET] <jamrial> iive: he means a new repo in github.com/FFmpeg
[17:47:35 CET] <iive> oh
[17:48:04 CET] <jamrial> IMO it should be added to source.ffmpeg.org first, and mirrored in github
[17:48:18 CET] <wm4> yeah
[17:48:51 CET] <BtbN> Isn't videolan slowly moving away from that anyway?
[17:48:55 CET] <BtbN> To their own gitlab
[17:49:09 CET] <j-b> nope, we have both
[17:49:31 CET] <j-b> gitlab is just a good replacement for wiki+bugtracker+git+usermanagement for all projects
[17:49:40 CET] <j-b> like libdvdcss or libdvdread or the mobile version
[17:49:50 CET] <j-b> github is just a mirror, because it is not open source
[17:53:19 CET] <BtbN> I don't know. I'd be fine with maintaining that on github.
[18:16:33 CET] <jamrial> jkqxz: where are the amd headers currently hosted, btw?
[18:16:56 CET] <BtbN> On their github
[18:17:15 CET] <BtbN> But the repo is kinda messed up, and included half of ffmpeg or something
[18:21:43 CET] <jamrial> amfenc.c includes config.h too late :/
[18:28:28 CET] <cone-254> ffmpeg 03James Almer 07master:a198c1386a4f: avcodec/amfenc: move config.h include where it's needed
[18:28:38 CET] <wm4> oh it got merged already?
[18:28:51 CET] <jamrial> without the headers in tree, yeah
[18:40:10 CET] <jkqxz> jamrial:  <https://github.com/GPUOpen-LibrariesAndSDKs/AMF>; "cp -a amf/public/include /usr/local/include/AMF".
[18:42:40 CET] <jamrial> jkqxz: https://pastebin.com/PpEZH2dh i thought this was using loadlibrary
[18:44:01 CET] <jkqxz> The AMD headers are not very C-compatible.  You need to build with optimisations so that everything marked inline is actually inlined.
[18:45:10 CET] <jkqxz> (There are non-static inline functions with no out-of-line implementation.  They should all be static.)
[18:46:34 CET] <jamrial> then shouldn't the headers be fixed?
[18:47:02 CET] <jkqxz> Yes.
[18:47:36 CET] <jkqxz> The submitter fixed some bits, but there are more.
[18:57:18 CET] <wm4> if the author is willing to fix them and acts on requests, everything is ok
[18:57:42 CET] <jamrial> 100% cpu usage, 20% gpu encode unit usage...
[18:58:36 CET] <jamrial> 25fps for a 1080p h264 stream
[18:59:11 CET] <atomnuker> if only vaapi was available under windows, eh?
[18:59:20 CET] <jamrial> lets try a different input sample. maybe h264 lossless as input is not a good idea
[19:01:28 CET] <nevcairiel> could test with d3d11 input for all the fancyness
[19:01:34 CET] <jkqxz> If you have Windows 10 you should be able to do "-hwaccel d3d11va -hwaccel_output_format d3d11 -i whatever -c:v h264_amf".
[19:01:40 CET] <jkqxz> Yeah, that :P
[19:02:33 CET] <jamrial> 60% cpu, 100% gpu encode unit using a blu ray h264 stream as input. 80 fps
[19:02:48 CET] <jamrial> and ok, lets try d3d11 :p
[19:04:11 CET] <jamrial> still ~80fps, but now ~0% cpu usage and full gpu encode and decode unit usage
[19:04:57 CET] <jamrial> this using a first gen GCN card
[19:05:35 CET] <iive> amd
[19:07:07 CET] <jkqxz> I didn't get particularly impressive numbers either (1080p60 or so).  That was a low-end GCN 2 card.
[19:07:32 CET] <nevcairiel> amds video engine isnt particularly good in comparison to nvidia and intel
[19:07:40 CET] <jamrial> HD 7950 here, so hevc or anything like that either
[19:07:42 CET] <nevcairiel> but still nice to be able to use it, i guess
[19:11:09 CET] <jamrial> win10 falls creators build showing gpu usage in task manager is really nice
[19:11:44 CET] <nevcairiel> the interesting part about that is that no third party tool could previously show video engine usage on amd, but there it is
[19:12:34 CET] <BtbN> it shows video engine usage? More than just "Yes, this uses it!"?
[19:12:46 CET] <jamrial> yeah
[19:14:02 CET] <jamrial> now if only configure could stop taking 13 minutes on it, i'd consider it the best win10 build so far
[19:14:18 CET] <nevcairiel> https://i.imgur.com/3d72ALB.png all sorts of info!
[19:15:34 CET] <jamrial> playing something? :p
[19:15:44 CET] <nevcairiel> yeah =p
[19:19:39 CET] <SortaCore> you guys messing with d3d11
[19:20:05 CET] <SortaCore> I'm doin' H264 decode/encode with HWA so lemme know if you want tests
[19:20:12 CET] <SortaCore> windoze 10
[19:35:00 CET] <SortaCore> I'm confused, is d3d11va related to vaapi?
[19:35:11 CET] <nevcairiel> no
[19:35:40 CET] <nevcairiel> btw jamrial, 6m40s for configure here
[19:35:44 CET] <JEEB> \o/
[19:36:53 CET] <jamrial> curious
[19:37:21 CET] <jamrial> it can't be cpu dependent since during the last several minutes cpu usage stays in the single digits for me and it just spawns sh time and time again
[19:39:52 CET] <atomnuker> what was the variable to regenerate fate checksums
[19:40:47 CET] <ubitux> atomnuker: GEN
[19:49:08 CET] <SortaCore> hwaccel what's the diff between d3d11va and d3d11va2 hwaccel?
[19:52:47 CET] <wm4> d3d11va is old API
[19:52:57 CET] <wm4> d3d11va2 is badly named new API, which you should use
[22:25:50 CET] <cone-451> ffmpeg 03Pan Bian 07master:61bbc537ab23: avcodec/samidec: check av_strdup() return value
[22:25:50 CET] <cone-451> ffmpeg 03Clément BSsch 07master:8d51d10eb895: lavc/samidec: properly raise errors from sami_paragraph_to_ass()
[22:31:55 CET] <SortaCore> sorry, I asked this before but forgot
[22:32:02 CET] <SortaCore> h264_nvenc or nvenc_h264?
[22:32:41 CET] <jkqxz> Look at all the other encoders and follow the common pattern.
[22:33:12 CET] <SortaCore> first one?
[22:33:25 CET] <SortaCore> I don't wanna run configure for listing, not sure if it'll erase stuff
[22:34:41 CET] <jkqxz> ./ffmpeg_g -encoders | grep h264
[22:35:33 CET] <BtbN> Just use the one that does not throw a big deprecation warning
[22:36:12 CET] <jkqxz> That too.
[22:39:23 CET] <SortaCore> why list the deprecated by default?
[22:39:38 CET] <BtbN> what?
[22:41:11 CET] <SortaCore> the grep one shows those two + "nvenc" with the same description
[22:42:18 CET] <BtbN> Well, they are deprecated, not removed
[23:37:10 CET] <jdlh> Hi, anyone want to talk about ffmpeg.org/developer.html ?
[23:41:27 CET] <jkqxz> jdlh:  It doesn't sound like a very fun subject, tbh.
[23:42:24 CET] <wm4> we need a project leader (I nominate jamrial)
[23:42:58 CET] <wm4> also why does ffserver.c still exist?
[23:45:39 CET] <jkqxz> Apathy?  Bloody-mindedness?  Some combination thereof?
[23:48:42 CET] <atomnuker> wm4: because the abi unstable period isn't over
[23:48:53 CET] <atomnuker> and it isn't over because the atomic patches need to be pushed
[23:49:02 CET] <atomnuker> so the avpriv_atomic stuff can be removed
[23:50:10 CET] <atomnuker> and the reason why they're not pushed is because it takes _time_ and _patience_ to make those patches, review them and redo them
[23:50:29 CET] <nevcairiel> both things you dont have? :)
[23:50:56 CET] <atomnuker> in limited supplies, I HATE BAD WEATHER AND MY THROAT'S BEEN SICK FOR A FEW DAYS NOW
[23:51:08 CET] <atomnuker> see, one just ran out momentarily
[23:51:32 CET] <jdarnley> If you select me to be your dictator I will remove it immediately.
[23:52:02 CET] <atomnuker> my throat or the bad weather?
[23:52:39 CET] <jdarnley> All 3 - ffserver, your throat, batweather - if that's what you want.
[23:53:02 CET] <ubitux> ffserver down your throat
[23:53:19 CET] <atomnuker> I'd honestly want my left ear fixed, its still clicking when I swallow from when I was sick half a year ago
[23:53:53 CET] <atomnuker> and that was during the summer, so the weather wasn't a problem
[23:54:05 CET] <iive> have you seen a doctor for it? i've heard UK has free healthcare.
[23:54:40 CET] <jdlh> So, there is no description of the ffmpeg-devel list in ffmpeg.org/developer.html . Is that OK?
[23:54:52 CET] <wm4> jdlh: probably not
[23:55:10 CET] <wm4> I've tried to figure out our development policy maybe a year or two ago
[23:55:14 CET] <wm4> I still don't know it
[23:55:25 CET] <atomnuker> iive: haven't had the time, and I lost touch with the gp I registered 5 years ago (pretty sure the practise shut down in the meantime too)
[23:56:05 CET] <nevcairiel> i havent been to a gp for probably over a decade, and i moved in between too
[23:56:15 CET] <wm4> what's a gp
[23:56:38 CET] <iive> general practitioner
[23:56:51 CET] <nevcairiel> ie. the doctor for your every day problems
[23:56:51 CET] <iive> a "personal" doctor.
[23:56:52 CET] <durandal_1707> michaelni: how midstream filtering with scale works? it look broken with other filters combinations atm
[23:57:21 CET] <jdlh> I get the sense that people regard the patch I proposed in http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220998.html as a change to ffmpeg-devel policy. In fact, Im trying to get people to articulate the *existing* policy, so I can make a patch to add it to the developer.html page.
[23:57:30 CET] <jdlh> I dont know how to get that across.
[23:58:09 CET] <durandal_1707> michaelni: the calling of config props in filter frame
[23:58:54 CET] <wm4> jdlh: good luck with that
[23:59:05 CET] <wm4> my opinion is that ffmpeg issues can't be fixed
[23:59:06 CET] <wm4> it's fucked
[23:59:44 CET] <durandal_1707> jdlh: ask carl eugen, he claims to know it 
[00:00:00 CET] --- Thu Nov 30 2017