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

[burek]

[00:13:50 CET] <cone-324> ffmpeg 03Ståle Kristoffersen 07master:d8b9bef1a06e: avformat: Auto-detect mjpeg 2000 in mpeg-ts
[00:33:15 CET] <kierank> michaelni: so, any suggestions where I do slice header decoding in mpeg4videodec?
[00:49:06 CET] <michaelni> kierank, i have just briefly looked at the new stuff but the studio slice stuff seems at a similar level as the video packet (header) stuff
[00:49:21 CET] <michaelni> as in an alternative
[00:49:42 CET] <kierank> well there's a vop and a slice header
[00:49:45 CET] <kierank> instead of just a vop
[00:50:10 CET] <michaelni> with video packets theres a vop and video packet headers IIRC
[01:22:52 CET] <kierank> will look tomorrow ig uess
[08:15:53 CET] <cone-954> ffmpeg 03Rostislav Pehlivanov 07master:38a13155827b: opus: remove redundant ff_celt_window2 declaration
[08:45:47 CET] <bp0> Can anyone here add some samples to fate for me? (re: http://ffmpeg.org/pipermail/ffmpeg-devel/2016-December/204597.html)
[09:28:31 CET] <nevcairiel> note that we can't delete samples since old versions of fate should remain functional, so knowing that would that change your choices of adding new samples, as the net size change would only ever increase
[10:08:00 CET] <cone-954> ffmpeg 03Paul B Mahol 07master:14090b705029: avcodec/get_bits: add av_assert2 to get_bits_long()
[10:49:37 CET] <cone-954> ffmpeg 03Nicolas George 07master:62b11db0a08c: lavfi: add FFFrameQueue API.
[10:49:38 CET] <cone-954> ffmpeg 03Nicolas George 07master:02aa0701ae0d: lavfi: make filter_frame non-recursive.
[11:05:24 CET] <fritsch> wm4: you got a minute? Having a question concerning the new send / receive API and using own memory in AVPacket?
[11:06:08 CET] <fritsch> with old API I allocated my outputbuffer, e.g. set the data and the size field via: https://ffmpeg.org/doxygen/2.7/group__lavc__encoding.html
[11:06:39 CET] <fritsch> with new API this is ignored and I have to memcpy the resulting data which points to somewhere else, via: https://ffmpeg.org/doxygen/trunk/group__lavc__decoding.html#ga5b8eff59cf259747cf0b31563e38ded6
[11:06:51 CET] <fritsch> is there a possibility to use my own memory also with that new API?
[11:35:47 CET] <nevcairiel> Don't think packets having your own memory was officially supported ever
[11:36:51 CET] <nevcairiel> Because you had no good way to guess the output size
[11:37:52 CET] <nevcairiel> In any case that's definitely dead with the new api
[11:46:00 CET] <fritsch> oki, we just did what the 2.7 documentation said
[11:46:13 CET] <fritsch> oki, so when I need to copy the data afterwards in my own buffers I need a memcpy?
[11:50:46 CET] <fritsch> I took the chance to ping you on github as we currently do the 3.2 API transition
[11:50:52 CET] <fritsch> thx for your reply
[11:51:13 CET] <atomnuker> wait, what? I thought ff_alloc_packet2 can return any memory
[11:51:48 CET] <fritsch> the problem is with giving it into the receive_packet api
[11:54:00 CET] <fritsch> we used it to encode textures rgba to jpeg to save thumbnails in code
[11:54:20 CET] <fritsch> means, allocate buffer, give it to a avpacket, use the old encode_video2 api
[11:54:39 CET] <fritsch> and use the resulting jpeg data to save it to disk
[11:55:17 CET] <atomnuker> huh, I guess the custom allocator DR1 stuff only applies to decoders
[11:55:28 CET] <fritsch> i think we talk to something different :-)
[11:55:42 CET] <fritsch> new: https://github.com/FernetMenta/kodi-agile/pull/48/commits/e45beb95df1a548e130af07ab9a279a02a31f11d
[11:57:42 CET] <fritsch> old with corruption: https://github.com/fernetmenta/kodi-agile/blob/master/xbmc/guilib/FFmpegImage.cpp#L724
[11:57:44 CET] <atomnuker> memcpy on compressed data isn't really that big of a problem (also the input memory might have to be aligned to some value for some codecs because SIMD)
[11:58:21 CET] <fritsch> old before transition: https://github.com/fritsch/kodi-agile/blob/master/xbmc/guilib/FFmpegImage.cpp#L673
[11:58:27 CET] <fritsch> honoring my .data and my .size
[11:58:35 CET] <fritsch> I think this needs some documentation update
[11:58:56 CET] <fritsch> atomnuker: it's a memcpy for every packet that you could have easily allocated from a memory pool before
[11:59:37 CET] <fritsch> all we did was a "smooth" transition from avcodec_encode_video2 to the new send / receive api
[12:00:23 CET] <fritsch> for our use case: getting exactly one frame in and giving one pkt out, this double the memory usage
[12:08:13 CET] <wm4> if you really want the old behavior we could add get_buffer style API
[12:08:24 CET] <fritsch> no no - it's not about the API
[12:08:27 CET] <wm4> but probably not worth it
[12:08:41 CET] <fritsch> just wanted to ask: is there any way I can give my own allocated memory to that?
[12:08:52 CET] <wm4> not at all
[12:08:59 CET] <fritsch> oki
[12:09:20 CET] <fritsch> for my use case (1 frame in only, or 1 pkt in only) I did a 1:1 transition via: https://blogs.gentoo.org/lu_zero/2016/03/29/new-avcodec-api/
[12:09:29 CET] <wm4> so just likewith decoding this could be solved with an alloc casllback
[12:11:23 CET] <fritsch> it's fine - just wanted to make sure I don't do something wrong cause of a misunderstanding
[12:12:00 CET] <fritsch> I also only need to unref this paket, right? no need to free anything?
[12:13:38 CET] <wm4> yeah
[12:14:12 CET] <fritsch> Then I need to also relook into the decode case as there I should also get a new self allocated frame
[12:15:14 CET] <wm4> if you used get_buffer2 nothing changes
[12:15:40 CET] <fritsch> I allocate a frame and give it into that method: https://github.com/fritsch/kodi-agile/blob/e45beb95df1a548e130af07ab9a279a02a31f11d/xbmc/guilib/FFmpegImage.cpp#L413 - now I wonder if the avcodec_receive_frame allocates a second frame
[12:15:53 CET] <fritsch> so that I need to unref the one I get after this method and free my original frame?
[12:16:07 CET] <wm4> (maybe you should make sure to send refcounted packets to avoid copies, if you don't yet)
[12:17:56 CET] <fritsch> in the encode case it's a ptr to a stack AVPacket
[12:18:23 CET] <fritsch> in Decode case, too, while the avpkt was filled with av_read_frame
[12:18:41 CET] <wm4> not sure why you call av_frame_clone
[12:19:21 CET] <fritsch> you mean I could drop the free? and just continue using it?
[12:19:30 CET] <fritsch> and then freeing it when "clone" is freed?
[12:23:47 CET] <fritsch> yeah makes sense
[12:23:52 CET] <fritsch> I added a commit
[12:24:29 CET] <wm4> yes receive guarantees that a refcounted frame is returned
[12:24:46 CET] <fritsch> but one question left
[12:24:52 CET] <fritsch> you see that I do av_frame_alloc
[12:25:23 CET] <fritsch> before, that one I need to free somewhere, while I thought I should only unref the frame I get from receive?
[12:26:24 CET] <nevcairiel> If you use alloc, you need free somewhere. Unref gets rid of the data inside a frame, but not the frame structure itself
[12:26:57 CET] <wm4> yeah, unref just resets an AVFrame to blank
[12:27:18 CET] <fritsch> when I get an AVPacket from this new method, who calls free?
[12:27:38 CET] <fritsch> is it when context is destroyed of the encoder?
[12:28:27 CET] <wm4> for the decode/encode API, the data you give it you still own
[12:28:36 CET] <wm4> and the data it returns changes ownership to you
[12:30:45 CET] <fritsch> oki - when I got that right, this: https://github.com/FernetMenta/kodi-agile/pull/48/commits/5160562682a5feeabf6dac451a4a4d6a4ad07b62 this is what you had in mind with the clone?
[12:31:13 CET] <fritsch> just returning the refcounted frame, but later on unref and free it?
[12:32:59 CET] <wm4> yes
[12:33:05 CET] <wm4> but _free also does _unref
[12:33:09 CET] <wm4> so the extra call is not needed
[12:33:19 CET] <fritsch> oki, thx very much.
[12:33:35 CET] <fritsch> yeah - still kind of confusing
[14:45:25 CET] <sylvain> hi
[14:46:17 CET] <Guest28871> we have a strange problem building ffmpeg for chromium (x86) can find report here https://github.com/iteufel/nwjs-ffmpeg-prebuilt/issues/28
[14:46:45 CET] <Guest28871> an idear ? problem with h264_cabac and hevc_cabac
[14:46:57 CET] <Guest28871> works if i add --disable-asm in configure
[14:47:11 CET] <Guest28871> (but seems a bad idear)
[14:47:52 CET] <JEEB> that looks like a bug in clang 4 rather than FFmpeg, no?
[14:48:06 CET] <JEEB> I mean, clang crashed
[14:48:35 CET] <JEEB> also llvm+clang 4.0 isn't even stable yet
[14:48:49 CET] <JEEB> see: http://llvm.org/
[14:49:01 CET] <JEEB> so yes, go provide a bug report to the llvm+clang people
[14:49:06 CET] <JEEB> it shouldn't crash
[14:51:03 CET] <smolleyes> seems yes ok i ll do that thanks
[15:03:29 CET] <BtbN> https://bpaste.net/show/04d891fa4fce gcc warnings have become quite verbose
[15:04:37 CET] <JEEB> yeah, they've been trying to improve after clang started improving things
[15:05:21 CET] <BtbN> This seems quite a bit too much though
[15:05:28 CET] <BtbN> I have no idea what it's trying to show me there
[15:06:11 CET] <BtbN> ah, there is one char marked in those 180 lines
[15:10:52 CET] <BtbN> Timothy_Gu, https://btbn.de/public/build-log.txt that's the build log from a docker container. (It's huge, over 30MB)
[15:11:41 CET] <BtbN> The only error I can spot is a bunch of "/usr/lib/gcc/x86_64-linux-gnu/6/include/xmmintrin.h:52:1: error: conflicting types for '_mm_prefetch'"
[15:11:42 CET] <jkqxz> The warning is also wrong, though I admit the compiler would have a hard time working that out.  There is only ever one layer there, so nothing inside the loop gets run.  (That code fragment is present to make it match the standard exactly.)
[18:35:39 CET] <Timothy_Gu> BtbN: thanks
[18:35:54 CET] <BtbN> I have no idea how to fix it though
[18:35:57 CET] <BtbN> That error is weird
[18:36:10 CET] <BtbN> Almost seems like the gcc and stuff is too new for their tools?
[18:42:22 CET] <Timothy_Gu> ... yeah
[18:44:11 CET] <Timothy_Gu> but why didn't this pop up before?
[18:45:07 CET] <nevcairiel> we recently added stdatomic support which sets the compiler into c11 mode if appropriate
[18:45:22 CET] <nevcairiel> which might break it
[18:45:40 CET] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=6a4e24280dd7f15c41628ebfb01ee25661d8b258
[18:54:08 CET] <BtbN> hm, so we should somehow force it to c99 for the cov build
[19:01:30 CET] <BtbN> Timothy_Gu, what about adding "sed -i 's/-std=c11/-std=c99/g' configure"?
[19:01:44 CET] <Timothy_Gu> Will that work with stdatomic then?
[19:01:53 CET] <BtbN> It will just disable it I think
[19:02:09 CET] <BtbN> But as it can't be tested anyway, that's no loss
[19:02:21 CET] <BtbN> And gets rid of like 30 errors
[19:02:43 CET] <Timothy_Gu> yeah, but I know coverity does certain smart things with pthread functions
[19:03:04 CET] <BtbN> It will basically revert it to before that patch
[19:12:54 CET] <Timothy_Gu> hmm I can use stdatomic without -std=c11
[19:14:04 CET] <Timothy_Gu> echo -e '#include <stdatomic.h>\nint main(void) { int *ptr, *oldval; int newval; __atomic_compare_exchange_n(ptr, oldval, newval, 0, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST); }' | gcc -x c -
[19:14:58 CET] <Timothy_Gu> my Internet here is kinda shitty so I can't test on FFmpeg
[19:17:31 CET] <Timothy_Gu> indeed in gcc 5 the default for C has been changed from gnu89 to gnu11 so I don't know if that is the problem
[19:17:39 CET] <durandal_1707> why I can't get gcno files to generate?
[19:18:28 CET] <Timothy_Gu> https://gcc.gnu.org/gcc-5/changes.html
[20:08:19 CET] <kierank> why is h263dec doing the job of a parser
[20:08:39 CET] <kierank> why is AV_CODEC_FLAG_TRUNCATED a thing
[20:17:25 CET] <atomnuker> why does a segfault sometimes just print it's a segfault and other times it prints "memory corruption" + backtrace + memory map and spams the terminal?
[20:18:01 CET] <kierank> nondeterminisms
[20:23:49 CET] <jkqxz> That's glibc saying "you messed up the malloc arena", not a segfault.  (Though it probably would be very quickly if glibc didn't catch it first.)
[20:26:16 CET] <atomnuker> how do you mess up the malloc arena, it's still your own address space, you can do whatever you want there
[20:28:23 CET] <nevcairiel> writing beyond your allocation can still damage things
[20:28:54 CET] <jkqxz> Well, yes.  And glibc isn't going to be very pleased if you go and overwrite glibc's bookkeeping information about where all of the allocated/free blocks are.
[20:29:21 CET] <kierank> michaelni: so I guesss a video packet header is analagous to a slice header
[20:42:15 CET] <atomnuker> nevcairiel: well, yeah, but that's then a segfault
[20:44:21 CET] <kierank> not if you rewrite glibc's reserved space
[20:44:55 CET] <atomnuker> I guess it needs somewhere to store that data
[21:00:25 CET] <Compn> kierank : because h263 decoder was made before we split parsers out of decoders ? maybe ? no ?
[21:53:28 CET] <wm4> kierank: last it came up the arguments were API compatibility and SPEED
[21:53:32 CET] <wm4> you know, the usual bullshit
[21:54:47 CET] <kierank> pfft
[21:55:57 CET] <wm4> you could try to send a patch to deprecate it and remove its functionality
[21:56:24 CET] <wm4> (we had changes which keep API artifacts for compatibility but remove the implementation before)
[22:48:57 CET] <durandal_1707> kierank: i cleaned up all functions for pixlet, only remain to fix bugs with ed-pixlet.mov file
[22:49:53 CET] <durandal_1707> give a look and say what's obvious source of bug which I can't find
[22:53:59 CET] <kierank> Nice
[22:54:11 CET] <kierank> Ok i will look with your repo
[23:00:08 CET] <durandal_1707> ed-pixlet.mov is big file in xiph media of elephants dream
[23:14:48 CET] <kierank> hmmm quite big
[23:14:52 CET] <kierank> durandal_1707: link to repo?
[23:16:31 CET] <durandal_1707> kierank: https://github.com/richardpl/FFmpeg/tree/pixlet
[23:20:30 CET] <kierank> downloading file
[23:26:06 CET] <kierank> durandal_1707: yuv420? really?
[23:26:17 CET] <durandal_1707> yes
[23:26:31 CET] <kierank> I would port it to yuv420p10
[23:26:41 CET] <kierank> makes it easier to see overflows
[23:27:14 CET] <durandal_1707> overflows are in parsing
[23:27:28 CET] <durandal_1707> output is fine
[23:28:36 CET] <durandal_1707> some bits are over reading
[23:39:00 CET] <kierank> [pixlet @ 0xf366e0] wrong magic number: 0x0000 for plane 0, level 10
[23:39:49 CET] <kierank> looks fine to me
[23:41:57 CET] <kierank> durandal_1707: does it actually do floating point filter?
[23:42:48 CET] <durandal_1707> afaik yes
[23:43:50 CET] <durandal_1707> those errors shouldn't happen
[23:45:07 CET] <kierank> looks like padding
[23:47:09 CET] <kierank>             uint32_t magic2 = bytestream2_get_be32(&ctx->gbc);
[23:47:10 CET] <kierank>             uint32_t magic3 = bytestream2_get_be32(&ctx->gbc);
[23:47:10 CET] <kierank>             uint32_t magic4 = bytestream2_get_be32(&ctx->gbc);
[23:47:10 CET] <kierank>             uint32_t magic5 = bytestream2_get_be32(&ctx->gbc);
[23:47:10 CET] <kierank>             uint32_t magic6 = bytestream2_get_be32(&ctx->gbc);
[23:47:10 CET] <kierank>             printf("\n %x %x %x %x %x %x \n", magic2, magic3, magic4, magic5, magic6);
[23:47:11 CET] <kierank> all zero
[23:47:46 CET] <durandal_1707> bitreader prior that consumes all bits
[23:48:05 CET] <kierank> oh
[23:48:31 CET] <durandal_1707> either bug is in low or high somewhere
[23:51:45 CET] <kierank> exactly one byte overread
[23:52:01 CET] <kierank> so basically escape is weird
[23:55:33 CET] <jamrial> durandal_1707: in filter(), either make value a double, or make the constants float. otherwise those loops may end up being slow
[23:55:47 CET] <kierank> it's slow as hell already :)
[23:55:54 CET] <jamrial> slower then :p
[23:56:08 CET] <kierank> durandal_1707: does the binary decoder not have an escape condition?
[23:56:15 CET] <jamrial> but yeah, pointless double to float then float to int if he leaves it as is
[23:56:17 CET] <kierank> durandal_1707: can you let me know where the binary decoder does it's highpass
[23:56:58 CET] <durandal_1707> kierank: search for deadbeef in hex
[23:57:57 CET] <durandal_1707> there are 3 functions but 2 are dead code
[23:58:02 CET] <kierank> my guess is your termination condition is wrong
[00:00:00 CET] --- Mon Dec 19 2016