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

[burek]

[00:07:52 CEST] <jkqxz> wm4:  Are you happy with the V4L2 size fixup thing now?  I'd commit it along with that other V4L2 stuff.
[00:08:32 CEST] <wm4> jkqxz: yes, because it has been said good drivers ignore it
[00:09:43 CEST] <jkqxz> There are good drivers for V4L2?
[00:10:43 CEST] <wm4> dunno lol
[00:11:10 CEST] <JEEB> lol
[00:14:12 CEST] <cone-895> ffmpeg 03James Almer 07master:ede233a27889: configure: fix detecting libdl when dlsym requires extra linker flags
[00:27:40 CEST] <rcombs> "good" is relative
[01:08:04 CEST] <cone-895> ffmpeg 03Mark Thompson 07master:a0d076f3ef95: lavc/v4l2: Remove use of lfind()
[01:08:05 CEST] <cone-895> ffmpeg 03Mark Thompson 07master:8da5af258423: lavc/v4l2: Mark static const tables as such
[01:08:06 CEST] <cone-895> ffmpeg 03Jorge Ramirez-Ortiz 07master:44188993a186: avcodec/v4l2: set sizeimage param for non-raw buffers [fixes #6716]
[01:11:52 CEST] <JEEB> hmm, is there a clang style config that would match what FFmpeg requires?
[01:24:54 CEST] <cone-895> ffmpeg 03Michael Niedermayer 07master:df62b70de8aa: avcodec/x86/lossless_videoencdsp: Fix handling of small widths
[01:24:55 CEST] <cone-895> ffmpeg 03Michael Niedermayer 07master:26ea142658a8: avcodec/x86/lossless_videoencdsp: Fix warning: signed dword value exceeds bounds
[04:52:17 CEST] <cone-556> ffmpeg 03James Almer 07master:18279738f9a2: x86/blockdsp: use three operand form for an instruction
[07:37:44 CEST] <TimothyGu> michaelni: congrats on winning the Google Open Source Peer Bonus!
[09:56:55 CEST] <cone-730> ffmpeg 03Tobias Rapp 07master:c941e99b7f7b: avformat/wavenc: replace literal numbers with enum constants
[09:59:05 CEST] <cone-730> ffmpeg 03Mark Thompson 07master:e01a270762c1: lavc/v4l2: Fix printf format for int64_t
[10:32:00 CEST] <wm4> holy hell, h264 exports stereo3d metadata as AVDictionary instead of using the side data
[10:36:20 CEST] <cone-730> ffmpeg 03Tobias Rapp 07master:4f5fb7813423: doc/filters: align order of fps filter options to implementation
[10:36:21 CEST] <cone-730> ffmpeg 03Tobias Rapp 07master:0a499d6a5740: avfilter/vf_fps: clean-up filter options
[10:36:26 CEST] <rcombs> wm4: how even
[10:37:42 CEST] <wm4> av_dict_set(&dst->metadata, "stereo_mode", ff_h264_sei_stereo_mode(&h->sei.frame_packing), 0);
[10:38:21 CEST] <wm4> hevc does it correctly
[10:43:46 CEST] <rcombs> oh, on the frame
[10:43:59 CEST] <rcombs> quality
[10:46:29 CEST] <wm4> probably from before there was side data
[16:37:18 CEST] <cone-730> ffmpeg 03James Almer 07master:cafd9d66ed9e: build: add install targets for the examples
[16:41:13 CEST] <qwebirc25491> hello
[16:41:35 CEST] <qwebirc25491> I am trying to statically compile an ffmpeg binary for testing on macOS
[16:41:45 CEST] <qwebirc25491> But I cannot find any decent guide that can let me do this
[16:42:11 CEST] <nevcairiel> You probably want #ffmpeg, this channel is for development of ffmpeg, not questions on how to use or build it
[16:42:12 CEST] <qwebirc25491> I tried doing it with dependencies installed from homebrew, but when I try it on a different computer it gives me a dylib: image not found error
[16:42:16 CEST] <qwebirc25491> ok
[16:42:18 CEST] <qwebirc25491> thank you
[16:51:06 CEST] <jamrial> ubitux: can you test the latest merge whenever you have time? it's a "fine-grained link-time dependency" overhaul in the build system
[16:51:17 CEST] <jamrial> basically, instead of every module adding global "extralibs", it's done individually per ffmpeg library as needed
[16:52:10 CEST] <jamrial> had to adapt parts since we have a lot of external libraries libav doesn't, but some things like the avfoundation stuff is completely untested
[16:53:43 CEST] <jamrial> i pretty much guessed what to change with those :p
[16:55:16 CEST] <nevcairiel> iirc that change also had a bunch of bugs, should probably read a bit into the future of their commits
[16:57:37 CEST] <jamrial> where those found quickly or after a while? can't find any other commit related to this
[17:00:01 CEST] <jamrial> maybe d9da7151ee?
[17:06:26 CEST] <tmm1> jkqxz: did you get a chance to try that qsv repro on your win7 setup?
[17:12:05 CEST] <cone-730> ffmpeg 03Lukas Stabe 07master:1fd80106be3d: avformat: fix id3 chapters
[17:26:17 CEST] <kiroma> Is there a config option to enable all codecs?
[17:32:53 CEST] <nevcairiel> All codecs are enabled by default
[17:37:00 CEST] <kiroma> Oh so I can just omit all those --enable flags?
[17:38:14 CEST] <jamrial> that depends. if they are external libraries and you want them, no
[17:38:17 CEST] <jamrial> read the output of configure --help
[17:38:25 CEST] <jamrial> also, this is a subject for #ffmpeg, not this channel
[17:38:54 CEST] <kiroma> Okay, sorry.
[18:02:25 CEST] <jamrial> nevcairiel: thanks, squashed that one into the merge
[18:08:21 CEST] <nevcairiel> jamrial: 5e27ef800 probably as well
[18:18:06 CEST] <jamrial> nevcairiel: done
[18:19:46 CEST] <jamrial> nevcairiel: if you want to help testing the merge, i'd be grateful :p
[19:15:27 CEST] <graphitemaster> does ffmpeg have a function for defining custom allocation functions?
[19:20:54 CEST] <atomnuker> custom allocation functions for avframes? yep
[19:21:11 CEST] <nevcairiel> he probably means a generic allocator
[19:21:14 CEST] <graphitemaster> custom allocation functions for the entire library, yes
[19:21:25 CEST] <jkqxz> ELF interposition.
[19:21:40 CEST] <jkqxz> (Just like every other library.)
[19:21:50 CEST] <graphitemaster> I noticed the configure script permits a custom allocator like tcmalloc and jemalloc, but I need something that is provided by the application
[19:22:07 CEST] <nevcairiel> its kind-of supported, as long as your allocators start with a defined prefix and are linked at compile time
[19:22:12 CEST] <nevcairiel> not at runtime
[19:23:11 CEST] <graphitemaster> how difficult would it be to provide a runtime allocator registration as part of avutil, since it seems all the relevant stuff just uses av_(malloc,realloc) anyways?
[19:23:40 CEST] <nevcairiel> it would require global state, and we really dont like global state
[19:23:43 CEST] <graphitemaster> kind of sucks there is no context param for it though, so it would be global state which sucks
[19:24:51 CEST] <graphitemaster> looks like the only way is to build ffmpeg against a wrapper malloc implementation which lets me register my own hooks then
[19:25:22 CEST] <graphitemaster> does ffmpeg make allocations in global constructors anywhere?
[19:25:38 CEST] <nevcairiel> we dont use global constructors (yet)
[19:25:55 CEST] <graphitemaster> okay so then I don't have to worry about heap allocations before main is entered in my application
[19:26:00 CEST] <graphitemaster> thanks.
[19:26:20 CEST] <nevcairiel> there is no guarantee that it wont start doing that at some point tho
[19:27:18 CEST] <graphitemaster> *sigh*
[19:29:43 CEST] <graphitemaster> the rationale for this is to build a video player who's backing memory is represnted by an allocator which mlocks the pages so no sensitive information (like video frames) are included in the coredump for crash reports sent to us.
[19:31:28 CEST] <nevcairiel> video frames get a custom allocator anyway
[19:31:38 CEST] <nevcairiel> you can provide one by using get_buffer2
[19:32:53 CEST] <graphitemaster> well it was more generally about having full coverage of the library as a whole, e.g network subsystem too
[19:34:36 CEST] <nevcairiel> you cant really tell where an allocation is from though and if all memory is locked out, core dumps would seem quite a bit less useful
[19:36:25 CEST] <graphitemaster> if anything it is more useful because the coredump is filtered against the application instead of libraries linked
[21:23:11 CEST] <wm4> will I have to call a vote on this opaque_ref patch bullshit
[21:24:19 CEST] <BtbN> internal_opaque_ref
[21:25:08 CEST] <wm4> no
[21:27:14 CEST] <wm4> opaque_ref _is_ already "internal"
[21:27:58 CEST] <wm4> passing an AVFrame with opaque_ref set to some other piece of code makes no sense at all, unless it's for merely passing it through
[21:28:07 CEST] <wm4> (like in libavfilter, for which this was created)
[21:30:11 CEST] <jamrial> wm4: instead of a vote, call for more opinions. there are other developers that could contribute here
[21:30:34 CEST] <jamrial> they probably ignored/skipped the thread for being called "cuvid hwaccel"
[21:31:41 CEST] <jamrial> so far, you think it's ok and safe, michael that it's bad and risky. so what we need is to know what do other devs think
[21:39:35 CEST] <jkqxz> I don't understand the discussion at all.  The output AVFrame is bound by the API contract /not/ to be the same as the one in get_buffer2 (since the former is allocated by the user and the latter by lavc), so why would it matter what route any metadata on it takes?
[21:40:19 CEST] <wm4> the patch tries to preserve opaque_ref from get_buffer2
[21:40:29 CEST] <wm4> I don't know why, I find this unnecessary
[21:42:23 CEST] <jkqxz> Yeah, I can see making sure some metadata matches, fine.  But the AVFrame structure itself doesn't matter - the user can't keep any pointers to it because it would be fine for a decoder to move the reference to another AVFrame and free it as soon as get_buffer2 returns.
[22:06:49 CEST] <saml_> how can I apply patch like  https://github.com/FFmpeg/FFmpeg/commit/bb1014279d865597c281c651c9d78dfb56ca2742.patch  ?
[22:07:11 CEST] <saml_> patch -p0 < mypatch    asks me File to patch:      
[22:07:17 CEST] <jkqxz> -p1
[22:08:20 CEST] <saml_> ah thanks. should've read man page more carefully
[22:08:34 CEST] <JEEB> git itself can apply patches as well
[22:08:39 CEST] <JEEB> git am with commit messages
[22:08:44 CEST] <JEEB> and git apply for just diffs
[22:12:32 CEST] <BtbN> git applying patches is not the most pleasant experience sadly
[22:12:49 CEST] <BtbN> It fails at the slightest issue, where patch just shows an offset and applies away
[22:14:17 CEST] <jkqxz> "git am -3"?  But yeah, it still gives up annoyingly often.
[22:16:04 CEST] <saml_> nice thanks
[22:19:54 CEST] <alallein> is there any interest in a patch making -vcodec copy -acodec copy -avoid_negative_ts make_zero behavior the default when you do  -vcodec copy -acodec copy?
[22:24:40 CEST] <Compn> -c copy :P
[22:24:47 CEST] <Compn> but uh... changing a default , alallein ?
[22:25:05 CEST] <llogan> TimothyGu: i added doc/mailing-list-faq.texi on tuesday. i was assuming generate-doc.sh is executed regularly and would deal with adding it to the online docs, but it has not shown up (yet). got any suggestions?
[22:25:09 CEST] <Compn> alallein : i mean, patch welcome , maybe someone would use it. it would start a discussion on the current default of course
[22:25:46 CEST] <alallein> Compn: well, this just bit me badly, since I only noticed the odd behavior after running on a large number of files :)
[22:26:05 CEST] <Compn> aww
[22:26:23 CEST] <Compn> well did you run it on a large number of files with your option on and notice any problems?
[22:26:26 CEST] <Compn> could go both ways
[22:26:38 CEST] <alallein> investigating further now
[22:26:51 CEST] <alallein> maybe re-encoding is really the way to go?
[22:28:46 CEST] <Compn>  what is your use case
[22:28:54 CEST] <Compn> running a porn-hub type site ?
[22:29:02 CEST] <Compn> ehe
[22:29:05 CEST] <alallein> haha
[22:29:24 CEST] <alallein> no, just chopping up a bunch of larger files into scenes for further analysis
[22:29:45 CEST] <Compn> some kind of research ? 
[22:29:50 CEST] <Compn> fine i wont ask if you dont want to say lol
[22:30:02 CEST] <alallein> yep, CV research
[22:30:05 CEST] <Compn> what container format ?
[22:30:09 CEST] <alallein> mp4
[22:30:20 CEST] <Compn> for automated vehicle system? :P
[22:30:21 CEST] <Compn> ehe
[22:30:25 CEST] <alallein> no ;)
[22:30:50 CEST] <Compn> you might want to use the mp4box for splitting mp4
[22:31:19 CEST] <alallein> hm
[22:31:22 CEST] <alallein> never heard of that one
[22:34:04 CEST] <Compn> it may or may not work better for your purposes
[22:34:08 CEST] <Compn> i make no promises...
[22:34:47 CEST] <alallein> actually
[22:34:59 CEST] <alallein> there appears to be an actual bug being surfaced here
[22:35:10 CEST] <alallein> a bunch of these files only have audio streams, no video stream at all
[22:35:13 CEST] <alallein> according to ffprobe
[22:35:13 CEST] <Compn> what ver ffmpeg are you using ?
[22:35:31 CEST] <alallein> something very recent, sec
[22:37:01 CEST] <llogan> you should move this discussion to #ffmpeg, then use pastebin to show your actual command and the complete console output
[22:37:34 CEST] <Compn> (and upload a sample and report a bug on http://trac.ffmpeg.org )
[22:39:26 CEST] <alallein> will do, perhaps tomorrow
[22:39:31 CEST] <alallein> using 3.2.4
[22:39:46 CEST] <alallein> so a few point releases behind
[00:00:00 CEST] --- Fri Oct  6 2017