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

[burek]

[00:33:23 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:34f49bfacd75: avfilter/avf_showcqt: Replace all fmin* and fmax* by FFMIN/FFMAX
[03:34:02 CET] <cone-802> ffmpeg 03Michael Niedermayer 07master:a75bebfe9aa8: avcodec/libopenh264enc: set .i64 for AV_OPT_TYPE_INT
[03:34:02 CET] <cone-802> ffmpeg 03Michael Niedermayer 07master:9319e0838008: avcodec/libopenh264enc: Fix project name
[03:34:02 CET] <cone-802> ffmpeg 03Michael Niedermayer 07master:81d3986d2d09: avcodec/libopenh264enc: AV_OPT_TYPE_STRING should use .str default
[03:34:02 CET] <cone-802> ffmpeg 03Michael Niedermayer 07master:865f6f410fdb: avdevice/caca: change AV_OPT_TYPE_STRING to set .str default
[04:20:09 CET] <cone-802> ffmpeg 03Ganesh Ajjanagadde 07master:8d9f86bd3791: avutil/rational: use frexp rather than ad-hoc log to get floating point exponent
[12:35:41 CET] <BBB> michaelni: how are the two motion searches different? one has a cost table associated with it, the other doesnt (so you set the cost table to zero), but the algorithm is not different
[12:53:17 CET] <wm4> michaelni: didn't you have a patch to add motion search to lavu?
[12:53:21 CET] <wm4> as API
[12:53:27 CET] <wm4> or maybe it was lavc
[13:00:35 CET] <michaelni> BBB, its harder than seting cost to a constant, if you want to find good robust real motion. for example a flat black area moving would have very very bad motion vectors if just the best match is taken for each such black + noise block
[13:01:24 CET] <wm4> also, god damn I hate ffprobe's command line interface so much, I might write my own probe tool
[13:01:42 CET] <BBB> black area has no motion, thats the whole point
[13:01:46 CET] <wm4> so you can select streams with -select_streams, but this disavles -show_frames???
[13:01:52 CET] <BBB> the object around it may have motion
[13:02:02 CET] <iive> wm4:  mpv -identify ;)
[13:02:17 CET] <wm4> iive: no, I want to dump frames
[13:03:13 CET] <michaelni> no i didnt speed, cant you see my car is black, only the others where moving
[13:14:22 CET] <cone-054> ffmpeg 03Matt Oliver 07master:e82883aa88bf: gdigrab: grab right desktop size if DPI in use, based on patch from Alexander Brotzge
[13:14:23 CET] <cone-054> ffmpeg 03Matt Oliver 07master:6c6ac9cb17c4: avutil/x86/intmath: Use tzcnt in place of bsf.
[14:20:18 CET] <cousin_luigi> Greetings.
[15:01:16 CET] <ubitux> wm4: no
[15:01:41 CET] <ubitux> you probably didn't match any existing streams with your pattern
[15:05:18 CET] <wm4> guess that's possible
[15:10:25 CET] <wm4> also, the documented -codec option does not exist
[15:12:25 CET] <cousin_luigi> Whom should I ask about an ARM concern?
[15:13:52 CET] <rcombs> nevcairiel: where do you think I should "catch" a bitstream filtering error?
[15:15:23 CET] <nevcairiel> its kind of unfortunate that errors from av_interleaved_write_frame are considered fatal, so we can't really notify upstream about it at all, so I see two options - drop the packet, or just write it as is
[15:15:28 CET] <nevcairiel> while logging an error, i guess
[15:16:08 CET] <cousin_luigi> http://pastie.org/private/fssxhnohzeodnonjr7ba <- what tests would you recommend to run to test if AV_READ_TIME works properly also on this arm target?
[15:17:44 CET] <rcombs> nevcairiel: the ffmpeg.c behavior differs here in 2 ways
[15:18:16 CET] <rcombs> or, well, lemme rephrase
[15:18:25 CET] <nevcairiel> what did the old code do when filtering failed?
[15:18:32 CET] <rcombs> by default, on a BSF error, it passes through the source packet _to the next BSF_ (if present)
[15:19:11 CET] <rcombs> not sure if that behavior is desirable
[15:19:25 CET] <nevcairiel> does it?
[15:19:35 CET] <rcombs> should a BSF error result in writing the packet that failed as-is, or should it continue to the next BSF in the chain as it does now?
[15:19:53 CET] <rcombs> see the code removed here: https://github.com/FFmpeg/FFmpeg/commit/62903e99cfea55d6ee537f61fc8b21798daa5015
[15:19:53 CET] <nevcairiel> how likely is it to ever have multiple bsf'es for one stream
[15:19:58 CET] <nevcairiel> not fucking likely =p
[15:20:02 CET] <rcombs> line 709
[15:20:06 CET] <rcombs> nevcairiel: I've done it
[15:20:12 CET] <nevcairiel> like which?
[15:21:00 CET] <rcombs> I've got a BSF in my copy that drops some extraneous Annex B NALs, like the SEI or whatever it is that x264 sticks its encoder info in
[15:21:09 CET] <rcombs> because they anger some players
[15:21:17 CET] <nevcairiel> you have weird players
[15:21:21 CET] <nevcairiel> like, not spec compliant players
[15:21:28 CET] <rcombs> though I really don't care that much about that case
[15:21:40 CET] <rcombs> I think that was for some really old thing
[15:21:56 CET] <nevcairiel> its hard to answer because you dont know if a bsf is mandatory
[15:22:15 CET] <nevcairiel> the aac_adtstoasc bsf is mandatory as otherwise the packets are in the wrong format
[15:22:21 CET] <nevcairiel> while your sei dropping thing is just a bonus
[15:23:22 CET] <rcombs> I also rely on the behavior that ffmpeg will keep chugging along if mp4toannexb fails (i.e. source was already Annex B)
[15:23:43 CET] <nevcairiel> in that particular case the bsf would ideally detect that and not raise an error
[15:23:48 CET] <rcombs> yeah, agreed
[15:23:50 CET] <nevcairiel> like the aac bsf does that and just returns 0
[15:24:34 CET] <rcombs> there's code in this my copy (which I didn't write, mind you; nor the SEI-dropping bsf) that keeps an int `ran_into_error` or something like that in the bsfctx private data
[15:24:54 CET] <rcombs> sets it to 1 after the first error, and then doesn't log subsequent ones
[15:25:13 CET] <rcombs> I guess someone who worked on this before me got tired of unexpected already-annexb data filling up their logs
[15:25:24 CET] <rcombs> and didn't want to bother to detect the case properly and passthrough packets
[15:25:45 CET] <nevcairiel> i am just lucky that i never bothered with re-muxing
[15:25:49 CET] <nevcairiel> we always force re-encoding
[15:26:15 CET] <rcombs> this runs on PPC NAS devices
[15:26:26 CET] <rcombs> as much as I often wish it didn't
[15:26:45 CET] <cone-054> ffmpeg 03Ganesh Ajjanagadde 07master:7910a2c26939: avfilter/vf_deshake: replace qsort with AV_QSORT
[15:28:00 CET] <rcombs> I still occasionally get reports of the media analyzer process (acts a little bit like ffprobe) crashing when reading an MP3 file with an attached image on PPC
[15:28:16 CET] <rcombs> on some specific shitty NAS
[15:28:28 CET] <rcombs> cba to set up a debug environment and figure out the real problem, and it has like 5 users
[15:28:39 CET] <rcombs> (I exaggerate slightly)
[15:31:29 CET] <rcombs> but eh, I'll just keep ffmpeg.c's behavior for now
[15:32:23 CET] <rcombs> nevcairiel: are you OK with ignoring the "ADTS with first packet corrupted" case until someone comes up with a real sample it breaks on
[15:33:01 CET] <rcombs> 'cause that seems like an awkward edge case, and any fix for it is going to come up with some additional unpleasant edge cases
[15:40:58 CET] <nevcairiel> i suppose its fine
[15:41:26 CET] <nevcairiel> it might however get even more evil
[15:41:30 CET] <nevcairiel> if the first adts frame is broken
[15:41:37 CET] <nevcairiel> check_bitstream might not figure that out
[15:41:43 CET] <nevcairiel> and adts filter is never engaged :D
[15:43:25 CET] <cone-054> ffmpeg 03Ganesh Ajjanagadde 07master:8a5b60a6b1d8: avutil/opencl_internal: add av_warn_unused_result
[15:44:59 CET] <kierank> woah a lot of h264 sliced thread crashes
[15:46:35 CET] <Compn> i would guess it is a rarely used feature
[15:47:11 CET] <kierank> I will wait for michaelni to fix the first one before reporting more
[15:47:57 CET] <kierank> at least 5 different crash positions but might all be the same bug
[16:09:14 CET] <cone-054> ffmpeg 03Agatha Hu 07master:20abda6b626c: avcodec/nvenc: fix potential profile error when encoding yuv444p
[16:11:43 CET] <cone-054> ffmpeg 03Matt Oliver 07master:bff009697d02: avutil/x86/intmath: Add missing header.
[17:33:50 CET] <cone-054> ffmpeg 03Clément BSsch 07master:953d358462f2: avcodec/libopenh264enc: use AV_OPT_TYPE_BOOL for allow_skip_frames option
[18:59:04 CET] <jamrial> nevcairiel: merge 54de179c broke fate-vp8-alpha with valgrind. some sidedata is not being freed
[18:59:53 CET] <jamrial> libav doesn't have that test, so i'm going to run it manually and see if it also affects them
[19:05:56 CET] <nevcairiel> only that one? that appears odd
[19:06:03 CET] <nevcairiel> i figured either all with sidedata or none
[19:06:56 CET] <nevcairiel> av_read_frame might need a packet unref after adding it to the pkt buffer
[19:10:53 CET] <nevcairiel> although I would've thought the main data may then also leak
[19:11:36 CET] <jamrial> http://fate.ffmpeg.org/report.cgi?time=20151031142418&slot=x86_64-archlinux-gcc-valgrindundef
[19:11:40 CET] <jamrial> yeah, only that one
[19:22:42 CET] <jamrial> looks like it doesn't affect libav
[19:23:09 CET] <nevcairiel> if its only that one particular test for some reason, it may be something weird
[19:26:21 CET] <jamrial> maybe av_dup_packet does something with sidedata that av_packet_ref alone doesn't
[19:27:07 CET] <nevcairiel> it does nothing with it really, it just moves it from the one to the other packet
[19:27:08 CET] <nevcairiel> ref does more
[19:31:05 CET] <wm4> vp8 alpha smells like hacks at work?
[19:31:13 CET] <wm4> something fishy only vp8 does?
[19:33:36 CET] <jamrial> how many fate tests deal with sidedata in matroska? maybe this is the only one and that's why it fails alone
[19:35:20 CET] <wm4> hm it does use blockadditional
[19:36:32 CET] <wm4> and something very strange with an internal packet queue
[19:37:42 CET] <wm4> and the prev_pkt field is only ever written to?
[19:46:02 CET] <jamrial> can reproduce this with an opus mka file that has discard_padding sidedata
[20:20:26 CET] <nevcairiel> that couldnt be the only demux test which ever produces side data, could it
[20:22:00 CET] <nevcairiel> but interestingly, why does av_packet_new_side_data not create refcounted side data?
[20:23:37 CET] <nevcairiel> mm nothing uses refcounted sidedata
[20:24:36 CET] <nevcairiel> anyway the difference seems to be that dup_packet didnt copy the side data while packet_ref does
[20:24:48 CET] <nevcairiel> i still wodner why the main packet data is not leaking in the same thought however
[20:26:33 CET] <nevcairiel> i'll debug it tomorrow if noone e lse does, i dont have time tonight
[22:11:47 CET] <durandal_1707> cinepakenc gives bunch of warnings when compiling
[22:17:50 CET] <thardin> uhh
[22:18:03 CET] <thardin> cinepakenc got committed?
[22:18:26 CET] <jamrial> long ago
[22:20:02 CET] <Daemon404> for all its wide range of real world use cases.
[22:31:43 CET] <Compn> time travelers , mostly
[22:32:08 CET] <durandal_1707> why Chinese anime folks are following me?
[22:32:36 CET] <durandal_1707> Or Japanese dunno
[22:32:59 CET] <Compn> maybe your work on some video filter ?
[22:34:05 CET] <durandal_1707> bah, only audio
[22:37:41 CET] <cousin_luigi> durandal_1707: Perhaps they are into swords?
[22:39:22 CET] <durandal_1707> nah, nick is about AI frome game
[22:59:20 CET] <cone-448> ffmpeg 03Michael Niedermayer 07master:4d76e89c1818: avformat/http: Initialize .str based default for AV_OPT_TYPE_STRING types
[22:59:20 CET] <cone-448> ffmpeg 03Michael Niedermayer 07master:58346f6a294b: avformat/icecast: Initialize .str based default for AV_OPT_TYPE_STRING types
[22:59:20 CET] <cone-448> ffmpeg 03Michael Niedermayer 07master:507b01f89969: avcodec/h264_slice: Disable slice threads if there are multiple access units in a packet
[00:00:00 CET] --- Sun Nov  1 2015