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

[burek]

[00:02:03 CET] <tmm1> might just be the localhost hostname on the machine
[02:49:07 CET] <cone-650> ffmpeg 03Michael Niedermayer 07master:02ecda4aba69: avformat/oggparsetheora: Do not adjust AV_NOPTS_VALUE
[02:49:07 CET] <cone-650> ffmpeg 03Michael Niedermayer 07master:06e092e7819b: avformat/avidec: Fix integer overflow in cum_len check
[02:49:07 CET] <cone-650> ffmpeg 03Michael Niedermayer 07master:010b7b30b721: avformat/oggparseogm: Fix undefined shift in ogm_packet()
[02:49:07 CET] <cone-650> ffmpeg 03Michael Niedermayer 07master:3e7c847aaf5a: avformat/oggparseogm: Check lb against psize
[02:49:07 CET] <cone-650> ffmpeg 03Michael Niedermayer 07master:f655ddfb47e8: avformat/oggparsedaala: Do not adjust AV_NOPTS_VALUE
[02:49:07 CET] <cone-650> ffmpeg 03Michael Niedermayer 07master:a6cba062051f: avformat/img2dec: fix infinite loop
[05:16:19 CET] <cone-650> ffmpeg 03James Almer 07master:950170bd3bb4: avutil: add missing version bump for AV_CRC_8_EBU
[06:47:49 CET] <atx_> Ey hello everyone, I have a question. I'm trying ffmpeg with some test but the program crash. Seems like the memory is too restrictive, if you try ulimit -Sv $[49 << 10]; ./ffmepg -i test.mp4 test.avi we got a segfault. It can be fix with gcc -m32 or gcc -m64. Could you please tell me where should I add this -m on the configure file please?
[06:54:12 CET] <Compn> why are you limiting the mem so hard
[06:54:17 CET] <Compn> and also what ffmpeg version?
[06:54:19 CET] Action: Compn sleeps
[06:55:26 CET] <atx_> I guess N-90283-ga6cba06205
[06:55:37 CET] <atx_> I clone the repo a few hours ago
[06:56:20 CET] <atx_> jajaj sorry about the mem, the fuzzer does that by default 
[06:57:16 CET] <Compn> im not sure where to stick the compiler flags
[06:57:24 CET] <Compn> ./configure --help | grep -i extra 
[06:57:25 CET] <Compn> maybe 
[06:57:30 CET] <Compn> will give you some hints
[06:57:41 CET] <Compn> --extra-cflags=-m32  or something
[06:59:09 CET] <atx_> I should search for that first, I just try grep mem or something 
[06:59:16 CET] <atx_> Thanks ;)
[13:01:15 CET] <gagandeep> kierank: i am finding interlaced frames are filtered using temporal transform
[13:01:26 CET] <kierank> maybe
[13:01:32 CET] <kierank> could be the case
[13:01:47 CET] <kierank> but I thought it was a case of applying spatial transform on each field
[13:02:00 CET] <kierank> you can have combinations of all, interlaced, temporal or both iiuc
[13:02:18 CET] <gagandeep> basically in temporal.c and filter.c interlace word is present but in spatial.c it is not present
[13:02:37 CET] <gagandeep> yeah i have also read in wavelet.c that we could have combinations
[13:03:24 CET] <gagandeep> all these files in cineform-sdk
[13:04:51 CET] <gagandeep> what is frame pitch btw?
[13:05:15 CET] <gagandeep> the formula for filter interlaced is not looking that tough though
[13:05:55 CET] <durandal_1707> do it!
[13:07:46 CET] <gagandeep> alright
[13:09:33 CET] <gagandeep> but first can you guys tell me what actually temporal transform is about? i now know spatial one
[13:09:50 CET] <gagandeep> it will probably help me in going through the code
[13:11:01 CET] <gagandeep> kierank
[13:11:11 CET] <kierank> gagandeep: it is stride
[13:11:26 CET] <kierank> gagandeep: temporal transform uses data from both frames
[13:14:09 CET] <gagandeep> there are also some macros '_PROCESSOR_DISPATCH' do i need to be cautious of these because same function have two definitions
[13:15:52 CET] <gagandeep> kierank
[13:16:16 CET] <kierank> looks like a threaded vs non threaded
[13:16:19 CET] <kierank> choose the non threaded
[13:20:27 CET] <gagandeep> is it _PROCESSOR_GENERIC
[13:21:33 CET] <nevcairiel> the generic variant is usually the easiest to understand
[13:24:25 CET] <kierank> they claim to have generic functions but i've not seen them
[13:25:50 CET] <gagandeep> ok, filterInterlaced function, one is under #IF _PROCESSOR_GENERIC, one under # _PROCESSOR_PENTIUM_4 
[13:26:13 CET] <kierank> does that file have the right tags to reach filterInterlaced?
[13:26:27 CET] <kierank> add a printf in the cfhd code or find manually
[13:26:50 CET] <kierank> filterInterlaced
[13:26:53 CET] <kierank> comment is wrong i think
[13:26:58 CET] <kierank> doesn't look like a temporal transform
[13:27:02 CET] <kierank> it only uses one frame
[13:27:04 CET] <kierank> i think it means spatial
[13:27:51 CET] <durandal_1707> always beware of misleading comments
[13:28:08 CET] <kierank> hmm they call it that elsewhere t oo
[13:28:13 CET] <gagandeep> it isn't comment its preprocessor #if
[13:28:21 CET] <gagandeep> with #endif
[13:28:33 CET] <kierank> ah no i see why
[13:28:40 CET] <nevcairiel> one "frame" could still be temporal since its two fields
[13:28:42 CET] <kierank> in interlaced mode the fields are two different pieces in time
[13:28:45 CET] <kierank> yeah exactly
[13:28:59 CET] <gagandeep> yeah that is how they are implementing
[13:29:09 CET] <gagandeep> they are using two different fields
[13:29:09 CET] <kierank> so it's exactly how i imagined, just run the transform on individual fields instead of frames as we do now
[13:29:12 CET] <kierank> and the picture will look right
[13:30:53 CET] <gagandeep> k, let me go through the invertfunctions also, cause there are many varients for the final pixel format
[13:31:34 CET] <kierank> yes they have it unrolled for all combinations
[13:32:01 CET] <kierank> crazy but they did what they had to do for realtime hd in 2002
[13:32:19 CET] <gagandeep> yeah and i am seeing that processor thing was for some hand done optimization for pentium 4
[13:32:34 CET] <gagandeep> SSE2, rings a bell?
[13:34:34 CET] <gagandeep> for generic processor optimization is using MMX instructions
[13:34:47 CET] <gagandeep> i don't really know this processor specific things
[13:34:59 CET] <gagandeep> will ask if don't know how to proceed
[13:35:05 CET] <gagandeep> over and out
[13:35:06 CET] <kierank> yes they use intrinsics
[13:35:13 CET] <kierank> instead of c
[13:35:18 CET] <gagandeep> ohh
[13:35:24 CET] <kierank> hand written for each processor
[13:35:40 CET] <kierank> ffmpeg does the same but (nowadays) much more cleanly
[13:35:44 CET] <durandal_1707> and without pure C path, *sigh*
[13:35:46 CET] <kierank> back then ours was ugly or worse than theirs
[13:36:49 CET] <gagandeep> ok, let me go through the code and follow the function used in them and see if i can figure it out myself
[14:01:04 CET] <cone-686> ffmpeg 03James Almer 07release/3.4:c289f4b6c939: avcodec/extract_extradata: zero initalize the padding bytes in all allocated buffers
[15:36:26 CET] <durandal_1707> kierank: what's status of mpeg-4 simple studio profile patches?
[15:36:39 CET] <kierank> got bored of michaelni nitpicking
[15:40:55 CET] <cone-686> ffmpeg 03Rostislav Pehlivanov 07master:ea6973a5733c: vc2enc: replace quantization LUT with a smaller division LUT
[15:59:42 CET] <kierank> durandal_1707: do you want to finish it?
[15:59:59 CET] <kierank> michaelni nitpicking about ricing made it boring
[16:01:09 CET] <kierank> also complaining about issues that were present in existing code which he maintains
[16:02:31 CET] <durandal_1707> kierank: maybe, but not right now
[16:05:01 CET] <wm4> kierank: michaelnio never bothers to find the cause of issues in other's patches or even checking whether it's caused by the patch, so he can't know
[16:05:13 CET] <michaelni> kierank, if you disagree with something in a review, please talk with me about it instead of finger pointing 
[16:05:39 CET] <kierank> I have, you just repeat the same nonsense again
[16:05:43 CET] <michaelni> wm4, that is slander
[16:06:08 CET] <kierank> you always complain about the startcode search not being riced enough, even though you fail to understand it's different to the normal one in mpeg4video
[16:06:11 CET] <kierank> etc etc
[16:06:19 CET] <kierank> you complain about error propagation that you don't do yourself
[16:06:23 CET] <kierank> etc etc
[16:06:58 CET] <michaelni> kierank, if some function fails to propagte errors that doesnt mean its ok to knowingly add more code that fails to propagate errors
[16:07:24 CET] <wm4> michaelni: no, just observation
[16:08:08 CET] <wm4> like saying "this command line fails" without trying to check why, or saying what's expected/actual behavior, or even providing sample file
[16:08:16 CET] <wm4> very irritating
[16:08:45 CET] <kierank> michaelni: and the startcode complaint
[16:08:46 CET] <kierank> which is bogus?
[16:09:04 CET] <durandal_1707> isn't startcode complaint not present in latest review?
[16:09:07 CET] <kierank> it is
[16:09:10 CET] <kierank> https://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225185.html
[16:10:52 CET] <michaelni> in that i said " Please use avpriv_find_start_code() or document why that should not be used.", so if as you say now its not the same then that would have asked to document it, not sure why you are upset 
[16:11:23 CET] <michaelni> its just asking for a simple explanation/comment why it doesnt use the existing function
[16:11:29 CET] <kierank> I told you that in a previous review
[16:11:37 CET] <kierank> but you ignored it because it's all about the ricing
[16:13:36 CET] <michaelni> it should be written in the code as a comment, so anyone reading it understands
[16:14:08 CET] <michaelni> but i can add the comment if you prefer ?
[17:57:58 CET] <cone-686> ffmpeg 03Jérôme Martinez 07master:b6fc09cdb4c4: avcodec/ffv1: support of more pix_fmt
[17:57:59 CET] <cone-686> ffmpeg 03Sasi Inguva 07master:43205df645bc: lavf/mov.c: Use the correct offset to shift timestamp when seeking.
[23:33:54 CET] <cone-686> ffmpeg 03James Almer 07master:2536bd863246: avcodec/extract_extradata: don't allocate more space than needed when removing NALUs in h264/hevc
[00:00:00 CET] --- Sun Mar 11 2018