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

Thu Sep 8 03:05:02 EEST 2016

[00:05:16 CEST] <RiCON> you could roll back to 6 and still let whoever has 7 use it
[00:55:40 CEST] <cone-580> ffmpeg 03Rodger Combs 07master:6ede4e93ca04: lavf/matroskaenc: move skipped metadata keys to separate function
[00:55:40 CEST] <cone-580> ffmpeg 03Rodger Combs 07master:3829a02738c1: lavf/matroskaenc: skip writing "duration" tags
[00:55:40 CEST] <cone-580> ffmpeg 03Rodger Combs 07master:843e72ea5542: lavf/matroskaenc: use mkv_check_tag_name consistently
[02:21:17 CEST] <cone-580> ffmpeg 03Michael Niedermayer 07master:a97e35e7c20a: avcodec: Fix successfull typo
[02:21:18 CEST] <cone-580> ffmpeg 03Michael Niedermayer 07master:ba7be8c083df: swscale: Fix "warning: ISO C90 forbids mixed declarations and code"
[03:42:21 CEST] <rcombs> successfully fixed successfull typo
[03:42:59 CEST] <rcombs> remind me again while we're C90? Is it just to enforce a style preference?
[04:35:03 CEST] <jamrial_> rcombs: we're c99, except for that variable declaration stuff it seems
[09:57:09 CEST] <ubitux> so what does "canonical order" means?
[09:57:39 CEST] <ubitux> seems Diego is now moving libavcodec includes *after* libavutil headers
[09:58:37 CEST] <durandal_1707> low hanging fruits
[10:08:41 CEST] <nevcairiel> apparently system -> other av libraries -> local headers
[10:09:06 CEST] <nevcairiel> with the other libraries in dependency order, so avutil top
[10:27:41 CEST] <ubitux> so, are we adding time_base and ticks_per_frame to codecpar or what/
[10:27:42 CEST] <ubitux> ?
[10:27:51 CEST] <nevcairiel> i thought we didnt need it
[10:27:59 CEST] <nevcairiel> because you could just delete the code
[10:28:05 CEST] <ubitux> i can't
[10:28:16 CEST] <ubitux> if i do it breaks some newly added tests
[10:28:24 CEST] <nevcairiel> personally i still dont like these fields, they are hacks for some crazy avi shit
[10:28:32 CEST] <ubitux> that's not only avi
[10:28:47 CEST] <nevcairiel> timings are container info, not codec
[10:29:10 CEST] <ubitux> i know, but what's the solution here?
[10:39:08 CEST] <BtbN> RiCON, there's code in nvenc that hard-depends on the version 7 header, like 10bit encoding
[10:39:38 CEST] <BtbN> And I don't think it's a problem, by the time current ffmpeg master gets released, and that release makes it into some distribution, it shouldn't be an issue anymore.
[10:52:28 CEST] <wm4> ubitux: move them to AVStream?
[10:53:00 CEST] <ubitux> ticks_per_frame are obtained from decoders
[10:53:49 CEST] <wm4> decoders don't set codecparams anyway
[10:53:59 CEST] <ubitux> so should we copy them from AVCodecContext to AVStream? in that case, wouldn't it be better so simply use AVStream.codecpar?
[10:54:04 CEST] <ubitux> ok
[10:54:24 CEST] <ubitux> but, you would still have a duplicated field, right?
[10:56:39 CEST] <ubitux> currently, the copy AVCodecContext <-> AVStream doesn't really exist afaict, but there is AVCodecContext <-> AVStream.codecpar
[10:58:08 CEST] <ubitux> afaict you find ticks_per_frame in h264, mpeg*, and vc1
[10:59:20 CEST] <ubitux> should we update the decoders to actually not set it?
[11:00:00 CEST] <BtbN> wouldn't that make the problem worse?
[11:01:16 CEST] <ubitux> i don't know, no one seems to say anything else than "there shouldn't be any timing related info at lavc level", but for some reason they are needed
[11:01:31 CEST] <ubitux> i don't know why, can't find an explanation, nor a solution
[11:01:56 CEST] <BtbN> Seems to be a specialty of some codecs, which do carry timing information.
[11:02:27 CEST] <ubitux> yes, we even have a AVCodecContext.framerate
[11:02:58 CEST] <BtbN> yes, a lot of codecs have framerate information. Which gets updated by the decoders when the first frame/spspps gets decoded.
[11:03:29 CEST] <ubitux> so why are we making such a scene about adding ticks_per_frame and time_base?
[11:04:02 CEST] <BtbN> No idea, it seems to be virtal information exposed at the codec level. So adding the fields makes sense to me.
[11:04:17 CEST] <BtbN> I think the primarily complaint is that putting the hacks in ffmpeg.c is ugly.
[11:04:28 CEST] <BtbN> Which I agree with, but I don't know a better place for it either.
[11:11:05 CEST] <wm4> ubitux: and how does the ticks_per_frame value matter for avi?
[11:11:44 CEST] <nevcairiel> ubitux: the scene is because oen cant even come up with a meaning of time_base .. the general concept of a time_base is to interpret timestamps properly, but there is no timestamps here, only a time_base ... so what does it mean?
[11:12:06 CEST] <nevcairiel> i dont want to copy a field with the same name if we cant even figure out what its for
[11:12:53 CEST] <nevcairiel> if its the framerate, then it should fill that
[11:13:01 CEST] <nevcairiel> (and be called that)
[11:16:13 CEST] <BtbN> I somehow feel like this time_base + ticks_per_frame is the common ground of the various codecs/containers, which store framerate/timestamps/... in various otherwise incompatible ways.
[11:17:47 CEST] <cone-347> ffmpeg 03Michael Niedermayer 07master:207d78176f86: avformat: Export ticks_per_frame in st->codec
[11:20:21 CEST] <wm4> lol checking a fourcc in utils.c
[11:20:40 CEST] <michaelni> nevcairiel, there are timestamps and or durations in some codecs. I guess thats because their creators want elementary streams to be playable with timing info
[11:20:42 CEST] <wm4> that's the kind of shit code we all love
[11:23:22 CEST] Action: michaelni too wishes that fourcc check and in fact the whole surrouding code not to be needed
[11:26:58 CEST] <wm4> just like mafia people do not like to hurt anyone etc.
[11:35:06 CEST] <michaelni> wm4, the fourcc check was added in the codecpar merge http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6f69f7a8bf6a0d013985578df2ef42ee6b1c7994
[11:47:41 CEST] <ubitux> this whole block will go away btw, (still accessing st->codec)
[12:16:23 CEST] <ubitux> wm4: it seems to matter for lavf (utils) to determine various things related to durations
[13:17:04 CEST] <durandal_1707> Why we have decoder for every single hwdec+codec combo?
[13:17:43 CEST] <BtbN> We do?
[14:45:35 CEST] <BtbN> ARGB10, "10 bit Packed A2R10G10B10. Each pixel of size 2 bytes. Most Significant 10 bits contain pixel data.". What the hell kind of format is that.
[14:46:14 CEST] <nevcairiel> 10-bit packed into 32-bit isnt that uncommon
[14:46:26 CEST] <nevcairiel> 2 bits either unused or used for alpha
[14:47:03 CEST] <BtbN> yes, but how does the "Most significant 10 bits" thing work witht hat?
[14:47:29 CEST] <nevcairiel> it doesnt
[14:48:20 CEST] <BtbN> there doesn't seem to be any 10bit RGB format in ffmpeg though
[14:48:24 CEST] <BtbN> so I'll just ignore those for now
[14:48:38 CEST] <nevcairiel> passing rgb to a yuv encoder is silly anyway
[14:52:07 CEST] <BtbN> another strange thing is, nvenc seems to support some kind of alpha channel
[14:52:27 CEST] <BtbN> or it just supports AYUV for compatiblity with packed YUV, and throws away the alpha channel
[14:59:50 CEST] <BtbN> On another note, why isn't this a switch: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L1279
[14:59:56 CEST] <jkqxz> Does NVENC actually encode RGB there or not?
[15:00:39 CEST] <nevcairiel> well rgb is just yuv 444 with some vui flag, so it actually might, but who knows
[15:01:00 CEST] <BtbN> jkqxz, I suspect it will convert it to YUV internally
[15:01:10 CEST] <BtbN> But I'll test right now what it actually does
[15:02:54 CEST] <A3G1S> Hey guys, I am facing some issue while compiling FFmpeg for x86 Android 
[15:03:41 CEST] <A3G1S> This error -> ld: warning: skipping incompatible libavutil/libavutil.a while searching for avutil
[15:04:24 CEST] <A3G1S> compilation works fine till tag - n3.0.3 
[15:04:35 CEST] <A3G1S> but not working for tag n3.1 
[15:04:56 CEST] <A3G1S> Any suggestion on how can I debug or fix this ?
[15:09:28 CEST] <jkqxz> If it actually does use RGB then that's nice.  If it doesn't but the convert happens in hardware then I guess it might have some value for performance.  If neither of those then it seems like an antifeature, because it can only cause confusion.
[15:09:50 CEST] <jkqxz> A3G1S:  Build in a clean directory.  (Also, ask in #ffmpeg instead.)
[15:17:18 CEST] <A3G1S> @jkqxz thanks for the suggestion, apologies for posting it in the wrong channel, going to give it a try 
[15:19:22 CEST] <BtbN> jkqxz, it indeed outputs a normal yuv h264 stream
[15:19:44 CEST] <BtbN> But it's a bit faster than software conversion
[15:19:47 CEST] <BtbN> 15FPS for me
[15:35:58 CEST] <cone-347> ffmpeg 03Matthieu Bouron 07master:f574012d5fe9: lavc/mediacodecdec_h264: fix SODB escaping
[15:46:02 CEST] <cone-347> ffmpeg 03Paul B Mahol 07master:424f0f9e3389: avfilter: add avgblur filter
[15:53:15 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/ac2bdbba6ad23b630f9f0945135a212c084653c0 am I missing something, or is there some reason not to use a switch on AV_PIX_FMT?
[16:00:38 CEST] <wm4> I don't understand why this duplicates the frame layouting code
[16:02:17 CEST] <BtbN> hm?
[16:03:15 CEST] <BtbN> how else would I copy to the nvenc native buffer?
[16:07:54 CEST] <wm4> isn't there an av_image function for that or whatever? unless nvenc has its own "special" custom layout
[16:14:37 CEST] <cone-347> ffmpeg 03Paul B Mahol 07master:93ae68d62a88: avfilter/vf_palettegen: add mode for generating palette for each input frame
[16:14:38 CEST] <cone-347> ffmpeg 03Paul B Mahol 07master:b7e78c75cc25: avfilter/vf_paletteuse: add option to use new palette for each output frame
[16:14:39 CEST] <cone-347> ffmpeg 03Paul B Mahol 07master:7a258ef97e54: avcodec/gif: don't honor transparency if palette changed
[16:14:48 CEST] <nevcairiel> should be functions for that if you're just mapping one memory buffer into an avframe
[16:26:02 CEST] <durandal_1707> "What can I use to replace FFmpeg on my Linux server?"
[16:30:09 CEST] <DHE> you can't. the power of ffmpeg compels you to continue using it
[17:02:37 CEST] <BtbN> nevcairiel, but I'd still have to calculate the offsets for each data pointer, which are format dependend, so I'd end up with almost the same construct
[17:05:57 CEST] <nevcairiel> but thats what those functions do?
[17:06:42 CEST] <BtbN> no, they all just expect that to be reabily available
[17:06:59 CEST] <nevcairiel> there is another function to do that
[17:07:15 CEST] <BtbN> av_image_copy expects an int[4] with the pointers, and if I wrap it into an AVFrame, it wants the same parameters set
[17:07:33 CEST] <nevcairiel> av_image_fill_pointers
[17:07:48 CEST] <nevcairiel> fills an ptr[4] from a specified single ptr
[17:08:16 CEST] <BtbN> it wants the 4 linesizes as input as well
[17:08:30 CEST] <nevcairiel> it tells you how to get those
[17:08:42 CEST] <nevcairiel> via av_image_fill_linesizes
[17:08:56 CEST] <BtbN> hm, av_image_fill_arrays looks like it though
[17:09:11 CEST] <nevcairiel> i guess thats a wrapper around those functions there
[17:09:24 CEST] <nevcairiel> ahy eah it is
[17:09:45 CEST] <BtbN> I hope that stuff is fast enough to be called every frame
[17:14:53 CEST] <BtbN> nevcairiel, hm, it doesn't seem to have a way for me to specify an input linesize
[17:15:05 CEST] <BtbN> it wants to calculate one, based on width and an alignment
[17:17:28 CEST] <BtbN> well, I have the linesizes ready anyway. Still ugly
[17:37:20 CEST] <nevcairiel> why is mediacodec always so ugly
[17:40:26 CEST] <mateo`_> nevcairiel: requiring vps+pps+sps for hevc or the code itself ?
[17:41:37 CEST] <nevcairiel> yeah that stuff
[17:42:31 CEST] <BtbN> https://github.com/BtbN/FFmpeg/blob/master/libavcodec/nvenc.c#L1289 that looks better
[17:43:40 CEST] <nevcairiel> so all formats you support have the same linesize on all planes then?
[17:43:58 CEST] <nevcairiel> i guess its all NV12/P010 like formats that are like that
[17:44:00 CEST] <BtbN> nvenc only has exactly one pitch in its surface parameters
[17:44:21 CEST] <BtbN> so there is no other assumption to be made than it's valid for all planes
[17:44:23 CEST] <nevcairiel> well i would still worry if a format isnt defined like that
[17:44:44 CEST] <BtbN> hm?
[17:45:10 CEST] <nevcairiel> 99% of the formats you use are always the same width of chroma and luma
[17:45:14 CEST] <nevcairiel> so its clearly the same value there
[17:45:36 CEST] <nevcairiel> except NV_ENC_BUFFER_FORMAT_YV12_PL, which I would worry about myself and manually confirm
[17:48:23 CEST] <BtbN> what would I do about it? There is only one pitch i get from nvenc.
[17:48:47 CEST] <BtbN> The old code uses the same assumption, and worked fine
[17:48:53 CEST] <nevcairiel> i dont know, test if it works like this and other wise half it
[17:49:15 CEST] <nevcairiel> its quite a lot of wasted space this way =p
[17:49:39 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L1285
[17:49:47 CEST] <BtbN> I can't influence that pitch
[17:49:58 CEST] <BtbN> I allocate a GPU frame from nvenc, and it gives me those values
[17:50:41 CEST] <BtbN> Just noticed another problem, which for some reason never caused issues
[17:50:42 CEST] <nevcairiel> you did half the pitch in there
[17:50:50 CEST] <nevcairiel> pitch >> 1
[17:51:09 CEST] <nevcairiel> for the chroma planes
[17:51:33 CEST] <BtbN> indeed
[17:51:37 CEST] <BtbN> why does that work
[17:51:46 CEST] <BtbN> that's not documented to be like that anywhere
[17:53:40 CEST] <BtbN> it might actually be wrong, and explain why yuv420p input was whacky
[17:54:11 CEST] <nevcairiel> anyway I have to leave, but it did seem like something to think about, and apparently it was!
[17:55:26 CEST] <cone-347> ffmpeg 03Burt P 07master:5e553cab68ea: af_hdcd: some types renamed to remove _t
[17:55:27 CEST] <cone-347> ffmpeg 03Burt P 07master:91be2ad756d6: af_hdcd: fix possible integer overflow
[17:55:28 CEST] <cone-347> ffmpeg 03Burt P 07master:e700e21b6ff5: af_hdcd: move decoding setup from init to config_input
[17:55:29 CEST] <cone-347> ffmpeg 03Burt P 07master:eb0086588f18: af_hdcd: tweak hdcd_analyze_prepare() a bit
[17:59:52 CEST] <BtbN> nevcairiel, seems like it is needed
[17:59:59 CEST] <cone-347> ffmpeg 03Burt P 07master:38445d58f1a1: af_hdcd: hdcd_analyze_gen() using int instead of float
[18:00:02 CEST] <BtbN> it straight up crashes without it, as the input buffer is not large enough.
[18:22:04 CEST] <BtbN> nevcairiel, ah, completely forgot about that as well, YV12 has, compared to YUV420P, the U/V planes swapped...
[18:40:24 CEST] <cone-347> ffmpeg 03Carl Eugen Hoyos 07master:7a8e5ff1fd06: lavc/avcodec: Improve av_parser_parse() documentation, mention padding.
[18:43:40 CEST] <cone-347> ffmpeg 03Steven Liu 07master:30a09eae9818: tests/fate:Add FATE for hls_flags append option
[18:50:00 CEST] <cone-347> ffmpeg 03Timo Rothenpieler 07master:96cba1c5524e: avcodec/nvenc: use av_image_copy for copying frame data
[18:50:01 CEST] <cone-347> ffmpeg 03Timo Rothenpieler 07master:fa3ecad071aa: avcodec/nvenc: correctly set inputPitch
[18:50:02 CEST] <cone-347> ffmpeg 03Sven C. Dack 07master:4aeb7a88ec69: avcodec/nvenc: support RGB input
[18:51:44 CEST] <cone-347> ffmpeg 03Carl Eugen Hoyos 07master:3e886e730750: ffmpeg_opt: Suggest to use "file:..." if a protocol was not found.
[18:56:27 CEST] <A3G1S> @jkqxz clean directory build worked perfectly, but looks like "make clean" isn't actually cleaning everything, so had a put a hack to make it work for most of android architectures. Thanks for the help man :-)
[19:22:20 CEST] <JEEB> A3G1S: you should be doing out of tree building anywqys
[19:22:34 CEST] <JEEB> also there's make distclean
[19:25:50 CEST] <A3G1S> make clean, make distclean both didn't clear all 
[19:26:00 CEST] <A3G1S> thats what it looked like 
[19:26:11 CEST] <JEEB> cool. but still, out of tree builds
[19:26:36 CEST] <A3G1S> yeah thats true 
[19:26:38 CEST] <JEEB> as in next to your ffmpeg src dir you have ARCH-build etc
[19:27:01 CEST] <JEEB> and for each new build you just nuke that
[19:27:36 CEST] <JEEB> and maybe do git clean -dfx in the src dir if you're still feeling there's something
[19:27:55 CEST] <A3G1S> this is what I am doing now, my project has submodules also I have FFmpeg as a submodule 
[19:28:24 CEST] <A3G1S> git clean -dfx doesn't fix it
[19:28:30 CEST] <A3G1S> probably because of gitignore 
[19:28:38 CEST] <JEEB> could be
[19:28:46 CEST] <A3G1S> so basically I am removing ffmpeg dir and re initialising submodules
[19:28:57 CEST] <A3G1S> before starting build for any architecture
[19:28:58 CEST] <JEEB> but yeah, out of tree tends to fix things
[19:29:08 CEST] <JEEB> if it doesn't then there's issues
[19:29:11 CEST] <A3G1S> I think its time to update android library 
[19:30:02 CEST] <JEEB> because with out of tree the build-time outputs should be generated to your build dir, not src dir (of FFmpeg f.ex.)
[19:30:14 CEST] <A3G1S> basically if we are using clean FFmpeg code to build any arch its working absoultely fine now 
[19:30:53 CEST] <A3G1S> okay I understand now
[19:31:10 CEST] <A3G1S> you are saying I should build the code in its own directory 
[19:31:28 CEST] <A3G1S> thats a great suggestion, I am going to refactor the code and follow your suggestion 
[19:31:41 CEST] <JEEB> yup. you can call the configure script from another dir
[19:31:55 CEST] <JEEB> and then the makefiles etc will be made
[19:32:01 CEST] <A3G1S> sorry I am not a C coder so didn't actually know what out of tree means
[19:32:09 CEST] <JEEB> so it works out of tree as well
[19:33:53 CEST] <A3G1S> Out of tree builds are impossible with config.h in source dir.
[19:34:33 CEST] <A3G1S> looks like I need to do some work to make it happen
[19:34:57 CEST] <JEEB> just clean and re-configure in out of tree :p
[19:35:41 CEST] <A3G1S> Thanks :-) Trying
[20:32:43 CEST] <A3G1S> @JEEB that worked for one architecture, good thing is compilation is in process for other architectures too, will update you as soon as it worked 
[20:33:09 CEST] <JEEB> basically I recommend using separate prefixed directories for each arch
[20:34:01 CEST] <A3G1S> I am doing the same 
[20:34:10 CEST] <A3G1S> already have separate directories for each arch
[20:34:21 CEST] <A3G1S> already modified the scripts for that 
[20:34:29 CEST] <JEEB> coal
[21:07:58 CEST] <cone-347> ffmpeg 03Matthieu Bouron 07master:256e99f6f055: lavc/mediacodecdec_h264: move bsf variable declaration at the top of the function
[21:07:59 CEST] <cone-347> ffmpeg 03Matthieu Bouron 07master:4b290078e4c6: lavc/mediacodecdec_h264: use h264_parse.h instead of h264dec.h
[21:10:53 CEST] <durandal_17> what this do: split=2[a][c],[a]gblur=35:1:1,lut=0.75*255/(1 + exp(-(2 + (0.75 * 20)) * (val/255 - 0.5)))[d],[c][d]blend=c0_mode=screen:normal:normal ?
[22:38:31 CEST] <cone-347> ffmpeg 03Paul B Mahol 07master:4fb6f9de0cfc: avfilter/vf_waveform: make possible to change background opacity
[22:53:51 CEST] <philipl> BtbN: you chose 'weave' for the cuvid deinterlacer so that a post-processing filter could deinterlace if desired?
[00:00:00 CEST] --- Thu Sep  8 2016