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

Sun Feb 12 03:05:02 EET 2017

[00:01:20 CET] <iive> BtbN: is the data you pass to the driver different than the one before the patch?
[00:01:33 CET] <BtbN> So far I have found no differences.
[00:01:44 CET] <BtbN> but obviously something has to be different
[00:02:06 CET] <iive> well, it could be driver bug...
[00:02:17 CET] <nevcairiel> still something has to trigger it =p
[00:02:23 CET] <iive> is the memory error about video memory or system memory?
[00:02:30 CET] <BtbN> It's error code 10
[00:02:36 CET] <BtbN> That's all the information one gets
[00:02:49 CET] <BtbN> translates to "Out of memory"
[00:03:05 CET] <BtbN> Even though the system isn't even nearly out of memory on either vram or ram
[00:03:09 CET] <iive> try running it under valgrind
[00:03:14 CET] <BtbN> haha
[00:03:22 CET] <BtbN> valgrind really dislikes graphics drivers
[00:03:58 CET] <JEEB> reminds me of valgrind and python - they even had to give out suppression files to weed out in-python issues :3
[00:04:33 CET] <iive> you might try some other memory debugger
[00:04:33 CET] <BtbN> valgrind just has no concept of mapped device memory
[00:04:36 CET] <BtbN> and gets terribly confused
[00:04:44 CET] <iive> something that would warn you if system memory allocation fails.
[00:05:00 CET] <iive> glibc also have some debuging
[00:06:22 CET] <wm4> it's probably like ffmpeg APIs and never really gives meaningful error codes
[00:06:54 CET] <BtbN> I just suspect somewhere, some value is uninitialized or zero, and that causes an internal malloc to fail
[00:07:00 CET] <BtbN> Just have to find it
[00:08:20 CET] <iive> once again, memory debuggers have functionality to fill newly allocared memory 
[00:11:51 CET] <BtbN> not if it's on the device
[00:12:11 CET] <BtbN> Trying to run a memory debugger on the nvidia driver will probably crash the whole thing
[00:36:12 CET] <pfanous> is avpriv_exif_decode_ifd(...) ever meant to handle H.264 streams?
[00:50:23 CET] <pfanous> is avpriv_exif_decode_ifd(...) ever meant to handle H.264 streams? If not, why is it being called from avcodec_decode_video2() in ffmpeg 3.2?
[00:58:39 CET] <ubitux> what makes you think avcodec_decode_video2 is h264 specific?
[00:59:24 CET] <ubitux> and you should look at git/master anyway
[01:00:55 CET] <pfanous> i know it's a general function. But when I'm in the context of H.264 decoding, I'm surprised to find it calling a function that deals with metadata parsing associated with frames such as JPEG
[01:01:51 CET] <ubitux> this function is not called from avcodec_decode_video2() in git/master
[01:02:04 CET] <ubitux> or at least not directly
[01:02:35 CET] <ubitux> some decoders call it: mjpeg and webp, and one demuxer does as well: avi
[01:04:18 CET] <pfanous> Yeah. those make sense. I'm running WinDbg and noticed that avcodec_decode_video2 is making calls to avpriv_exif_decode_ifd. I'm really confused about this, since it's H.264
[01:05:19 CET] <ubitux> maybe you have another stream in the container such as a jpeg thumbnail or whatever
[01:05:28 CET] <cone-265> ffmpeg 03James Almer 07master:7b3f0b3de4e0: avformat/apetag: bump micro version
[01:05:32 CET] <J_Darnley> Does this h264 video happen to be in an mp4 container with an embeded jpeg image?
[01:05:47 CET] <J_Darnley> /snap
[01:05:59 CET] <pfanous> no not from an mp4 container... no demuxing. Just a single H.264 stream
[01:07:29 CET] <ubitux> share the result of a ffprobe
[01:08:51 CET] <rcombs> pfanous: could be it's getting the function name wrong
[01:09:32 CET] <rcombs> pfanous: the call stack entry you're seeing might actually be in some private function (no exported name), and the debugger's giving you the name of the nearest symbol
[01:10:29 CET] <ubitux> add av_assert0(0) in the function
[01:13:32 CET] <Chloe> so close for this to work, but there's a phat black box behind it for some reason (doesn't do this when going to dvdsub instead of dvbsub) https://usercontent.irccloud-cdn.com/file/EGC6B4S9/Screen%20Shot%202017-02-11%20at%2000.12.03.png
[01:13:36 CET] <pfanous> possible... i noticed it's not starting at the very beginning of the call
[01:14:23 CET] <rcombs> yeah, that's probably it then
[01:17:50 CET] <tmm1> rcombs: finally had a chance to try your videotoolbox decoders patch
[01:17:57 CET] <rcombs> oh fun
[01:18:11 CET] <tmm1> works surprisingly well given the pts shenanigans
[01:18:28 CET] <rcombs> yeah, I was also surprised
[01:18:51 CET] <rcombs> falls apart on the MPEG1 fate samples, iirc
[01:20:02 CET] <tmm1> was that the only thing?
[01:20:15 CET] <tmm1> seems like this would be worth committing, since it does totally work
[01:21:40 CET] <rcombs> well, it won't work on e.g. H.264 or MPEG-2 streams with B-frames and no timestamps
[01:21:54 CET] <rcombs> unless the OS does decide to do reordering for us, which is not guaranteed
[01:22:08 CET] <rcombs> (no timestamps, or inaccurate ones)
[01:23:40 CET] <JEEB> Chloe: something related to transparency/alpha most likely
[01:25:47 CET] <pfanous> any chance I could build FFmpeg into .dlls along with .pdb files? (i.e. an MSVC specific build)
[01:26:13 CET] <JEEB> pfanous: just look at how the MSVC FATE station builds it and follow step :)
[01:26:22 CET] Action: JEEB has tried it lately as well, worked JustFine
[01:27:47 CET] <atomnuker> michaelni: ok, resent the opus encoder, now fully working and with nice new stuff
[01:27:53 CET] <JEEB> nice
[01:27:59 CET] <atomnuker> just needs a review from someone
[01:28:38 CET] <atomnuker> and of course the ML received the last email first and there's no nice thread
[01:29:02 CET] <pfanous> jeeb: MSVC FATE station? Sorry, not familiar. Any link available?
[01:29:51 CET] <JEEB> pfanous: http://fatebeta.ffmpeg.org/history/x86_32-msvc14-dll-windows-native
[01:29:58 CET] <JEEB> shows the full configure line, too :P
[01:30:11 CET] <JEEB> arch and toolchain are the two primary things
[01:31:00 CET] <atomnuker> bofh_: you alive?
[01:32:05 CET] <pfanous> jeeb: Thanks! I've been getting my stuff pre-built from Zeranoe. This may be a lot more helpful.
[01:32:32 CET] <JEEB> pfanous: just note that when running configure you will have to have "cl" and "link" from MSVC in your PATH
[01:35:48 CET] <pfanous> Ok. I've got a MS developer shell setup with that PATH already. Might be able to just use that.
[01:36:25 CET] <JEEB> just make sure any other "link.exe" isn't in your PATH
[01:36:32 CET] <JEEB> (if you're using msys)
[01:36:52 CET] <pfanous> Good point. I'll check for that.
[01:46:39 CET] <Chloe> is there somewhere I can make ffmpeg.c automaticaly set flags for encoders/decoders if a certain conversion is being done
[02:25:31 CET] <atomnuker> jamrial: I don't see imdct15 anywhere
[02:25:46 CET] <atomnuker> but yeah, ff_mdct15_init_aarch64 is a leftover
[02:26:09 CET] <jamrial> libavcodec/imdct15.[ch]
[02:26:25 CET] <jamrial> you're renaming it to mdct15, but forgot to remove the old files
[02:27:31 CET] <atomnuker> oh, I see, yeah
[02:31:05 CET] <atomnuker> sent a new email with both changes in a new patch
[03:00:55 CET] <cone-265> ffmpeg 03Mulvya 07master:40b6e2877865: doc: Add muxers/demuxers list option
[03:52:44 CET] <cone-265> ffmpeg 03James Almer 07master:96ee6da40106: fate: add WavPack muxer test
[04:12:16 CET] <tmm1> rcombs: tried your patch on ios and it works with an mp4 file but with an mpegts container i get VT errors on decode (-12911, kVTVideoDecoderMalfunctionErr). strange because the same file works on macos no problem
[04:12:37 CET] <rcombs> tmm1: same stream in both files, just remuxed?
[04:13:33 CET] <tmm1> no they're different samples
[04:13:37 CET] <tmm1> let me remux and try
[04:19:23 CET] <tmm1> rcombs: yea same sample file remuxed to mp4 and it plays on ios
[04:19:28 CET] <tmm1> both versions play on macos
[04:19:42 CET] <rcombs> tmm1: what if you remux your mp4 sample to MPEGTS?
[04:22:34 CET] <tmm1> remuxed original mp4 to mpegts, plays on ios
[04:22:59 CET] <tmm1> tried converting the original mpegts -> mp4 -> back to mpegts, still doesn't play
[04:23:58 CET] <tmm1> so i guess its something about this specific video feed, but only in annex b and only on ios?
[04:33:42 CET] <tmm1> rcombs: any hunches?
[04:33:59 CET] <rcombs> what does ffprobe say about it
[05:33:17 CET] <cone-265> ffmpeg 03Steven Liu 07master:d96ebc5ef880: avformat/hlsenc: deprecate hls_wrap option
[07:45:12 CET] <user128> I have opened https://trac.ffmpeg.org/ticket/6140 to get AMR-WB+ decoding support in ffmpeg. I have worked with libavformat before but don't know anything about libavcodec sources. hopefully, the devs can look at this ticket soon.
[12:15:55 CET] <cone-021> ffmpeg 03Paul B Mahol 07master:280a40dd2739: avcodec: add ATRAC Advanced Lossless decoders
[12:49:28 CET] <cone-021> ffmpeg 03Matt Wolenetz 07release/3.0:b5c13002d18e: lavf/mov.c: Avoid OOB in mov_read_udta_string()
[12:49:29 CET] <cone-021> ffmpeg 03Matt Wolenetz 07release/3.0:c63e58756699: lavf/mov.c: Avoid heap allocation wraps in mov_read_{senc,saiz}()
[13:09:36 CET] <BtbN> Did carl just ask for a command line to reproduce compiler warnings...?
[13:10:39 CET] <nevcairiel> its carl, he probably wants a ffmpeg log and a sample file as well
[13:11:30 CET] <BtbN> All it needs is the configure line, which is there in the original report.
[15:27:58 CET] <BtbN> Seems like mailing lists are too complicated nowadays.
[15:47:59 CET] <cone-021> ffmpeg 03Paul B Mahol 07n3.0.7:HEAD: avcodec: add ATRAC Advanced Lossless decoders
[15:55:44 CET] <cone-021> ffmpeg 03Carl Eugen Hoyos 07master:7ff445874be1: lavf/omadec: Remove an unsed variable.
[16:10:31 CET] <durandal_1707> i have 24 bit flic files
[16:20:24 CET] <cone-021> ffmpeg 03Carl Eugen Hoyos 07master:ed491db3e506: lavf/rtpdec_mpeg4: Constify a function parameter.
[16:36:14 CET] <cone-021> ffmpeg 03Carl Eugen Hoyos 07master:b47582f43a82: lavc/atrac3: Constify a pointer declaration.
[18:50:08 CET] <wm4> BtbN, philipl: elenril on #libav-devel is in the process of writing a cuvid decoder using the low level API it provides
[18:50:40 CET] <nevcairiel> its basically the same api
[18:50:56 CET] <nevcairiel> just filling some structs manually instead of calling the  cuvid function to do it for you
[18:51:31 CET] <wm4> and in your opinion the ffmpeg way is better?
[18:52:50 CET] <nevcairiel> i th ink the obstacles the hwaccel way has make it really inconvenient
[19:01:55 CET] <cone-021> ffmpeg 03Carl Eugen Hoyos 07master:350ce0b9d3d5: lavfi/minterpolate: Remove an unused variable.
[19:01:56 CET] <cone-021> ffmpeg 03Carl Eugen Hoyos 07master:5b2c0eebeea9: lavf/omadec: Fix packet duration for Atrac 3 lossless.
[19:09:35 CET] <BtbN> wm4, there are also formats their parser supports that ffmpeg simply doesn't have.
[19:09:45 CET] <BtbN> However relevant they are.
[19:10:00 CET] <wm4> which formats?
[19:10:51 CET] <BtbN> by now it's probably only mpeg1 left
[19:11:08 CET] <BtbN> and maybe mjpeg
[19:11:21 CET] <nevcairiel> mpeg1 is handled by the mpeg2 decoder in  avcodec anyway, so if one really wanted
[19:11:24 CET] <nevcairiel> not like it matters
[19:18:57 CET] <jkqxz> The MJPEG hwaccel should be written anyway; I have vague intensions to do it at some point.  (It has value when people make new webcams sending you over 1/2 Gbps of 4K MJPEG.)
[19:19:37 CET] <wm4> lol
[20:20:32 CET] <cone-021> ffmpeg 03Paul B Mahol 07master:54b5cc035a04: avcodec/flicvideo: fix some indentation issues
[20:20:33 CET] <cone-021> ffmpeg 03Paul B Mahol 07master:5781c983d880: avcodec/flicvideo: add support for 24bit flic files
[20:20:34 CET] <cone-021> ffmpeg 03Paul B Mahol 07master:25d9cb462132: avformat/flic: fix handling of EOF case
[20:30:17 CET] <durandal_1707> i gonna push  improved fmvc decoder if nobody have comments
[21:49:42 CET] <durandal_1707> who made Compn go away?
[21:51:52 CET] <Chloe> durandal_1707: pointing fingers wont help anything
[21:58:24 CET] <wm4> yeah, I wanted to thank him for something else, but he doesn't appear to be on freenode
[22:16:54 CET] <rcombs> hmm
[22:17:04 CET] <rcombs> afaik nobody in here particularly hates me
[22:17:10 CET] <rcombs> am I doing something wrong
[22:18:03 CET] <durandal_1707> if i use bytestream2_copy_buffer why does it gives artifacts?
[22:19:11 CET] <rcombs> artifacts?
[22:20:13 CET] <wm4> rcombs: btw. any chance you could revive your VT decoder?
[22:20:36 CET] <wm4> we could do fancy stuff like using async mode
[22:21:01 CET] <rcombs> wm4: sure, I guess
[22:21:17 CET] <rcombs> still needs reordering so one of us would have to figure out how that works
[22:21:22 CET] <durandal_1707> rcombs: yes. in fmvc decoder
[22:21:31 CET] <rcombs> love 2 parse bitstreams twice
[22:21:48 CET] <rcombs> wonder exactly how deep you have to look to do proper reordering
[22:22:05 CET] <rcombs> I give VP9 a hard time but their solution to this is better
[22:22:08 CET] <wm4> we could just use pts and leave it to someone else to do it right lol
[22:22:31 CET] <wm4> also, I think chromium's VT code does it "right"
[22:22:38 CET] <rcombs> nope
[22:22:47 CET] <wm4> they don't?
[22:22:53 CET] <rcombs> lemme go find it again to double-check
[22:22:59 CET] <rcombs> but I'm pretty sure I looked and they didn't
[22:23:44 CET] <atomnuker> durandal_1707: endianess?
[22:26:54 CET] <durandal_1707> atomnuker: nope. it reads byte after byte
[22:27:15 CET] <rcombs> wm4: oh wow they actually do
[22:27:29 CET] <rcombs> must've been thinking of some other code
[22:27:36 CET] <wm4> neat
[22:34:05 CET] <KGB> [13FFV1] 15michaelni closed pull request #49: add Matroska mapping (06master...06ffv1-in-mkv) 02https://git.io/vDwkr
[22:36:44 CET] <michaelni> atana, any news about the code? did you had time to move the code to a 2nd loop ?
[22:42:03 CET] <JEEB> wbs: not sure how interested you are but since I saw you active #elsewhere can you tell how bad something like this looks? (although you probably don't care too much about ISML manifests any more) https://patchwork.ffmpeg.org/patch/2495/
[22:43:00 CET] <wbs> JEEB: doesn't look harmful to me, so no objection
[22:43:05 CET] <JEEB> k
[22:43:30 CET] <JEEB> just noticed with multiple languages because the server by default calls all tracks "audio" or "video" or whatever the string was for text subs
[22:43:34 CET] <JEEB> and g'night :)
[23:45:00 CET] <atana> michaelni, I will push the commit now
[23:46:39 CET] <michaelni> atana, ok, and please be a bit more active, outreachy is a full time job
[23:48:21 CET] <atana> updated.
[23:53:29 CET] <michaelni> atana, ok, theres a bug
[23:54:03 CET] <michaelni> index is the index in the bin array (0..16) not the frequncy, 
[23:54:21 CET] <michaelni> the index < 64 and end = index + 64; and similar is wrong
[23:54:35 CET] <michaelni> it should use the frequency of that bin not the index
[23:54:50 CET] <michaelni> frequencies[index]
[23:54:57 CET] <atana> Yes. I will fix it
[23:55:50 CET] <michaelni> atana, ok, tell me when you updated it so i can recheck and we can continue
[00:00:00 CET] --- Sun Feb 12 2017