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

[burek]

[01:14:59 CET] <kierank> michaelni: thanks
[01:28:31 CET] <cone-448> ffmpeg 03Timothy Gu 07master:ee20354b29eb: pixblockdsp: Use AV_COPY128U for get_pixels_16_c
[08:18:59 CET] <rcombs> why don't parsers set (coded_)(height|width), pix_fmt, and similar on AVCodecContext? 
[08:26:51 CET] <cousin_luigi> Whom could I ask about an ARM concern?
[08:30:04 CET] <Timothy_Gu> cousin_luigi: I took a look at your ARM patch
[08:30:25 CET] <Timothy_Gu> so you are enabling the use of p15 conditional coprocessor on armv6zf
[08:30:43 CET] <Timothy_Gu> but accoring to official arm docs the specific opcode is not supported
[08:32:01 CET] <Timothy_Gu> See http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0301h/Cacicebd.html 
[08:32:31 CET] <Timothy_Gu> or actually http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0301h/Cacicebd.html
[08:32:41 CET] <Timothy_Gu> err http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/Babfbibb.html
[08:33:11 CET] <Timothy_Gu> in ffmpeg we are using c9 c13
[08:34:18 CET] <Timothy_Gu> in that documentation it says that only c9 c{0,1,2,8} are supported on ARM1176JZF-S
[08:34:32 CET] <Timothy_Gu> so i dont think your patch is correct
[08:40:27 CET] <cousin_luigi> Timothy_Gu: I see. Thanks for clarifying this.
[08:40:49 CET] <Timothy_Gu> note that im not an "ARM guy." just did some research on this
[09:52:49 CET] <nevcairiel> i should totally setup a linux vm on a faster system, running valgrind in this slow vm is painful :(
[12:05:42 CET] <kierank> nevcairiel: you can use avdev if you want
[12:46:21 CET] <nevcairiel> i have plenty fast systems, just that most of them run windows :D just need to setup a new VM on one of them
[12:54:21 CET] <wm4> durandal_170: in case you're interested in game formats: the descent 2 movies have heavy artifacts
[12:55:10 CET] <durandal_170> wm4: what format/codec?
[12:55:32 CET] <wm4> interplayvideo
[12:55:57 CET] <wm4> outputs errors like "interplayvideo: motion offset < 0 (-580)"
[12:57:51 CET] <wm4> sample: https://0x0.st/ivH.bin
[12:58:25 CET] <wm4> even a working video regressed, wth
[12:58:54 CET] <wm4> (works with debian's ffmpeg, doesn't work with git)
[13:01:52 CET] <durandal_170> what version of lavc is in debian ffmpeg?
[13:02:06 CET] <wm4> 56.60.100
[13:02:29 CET] <wm4> 2.8.1-1
[13:02:47 CET] <J_Darnley> Wow, really?
[13:05:09 CET] <wm4> debian unstable
[13:05:18 CET] <wm4> durandal_170: this is a sample that used to work https://0x0.st/ivX.bin
[13:06:28 CET] <wm4> or actually, maybe it's a mpv bug
[13:06:51 CET] <wm4> the other sample still fails with in ffplay and mpv though
[13:36:17 CET] <Daemon404> bisect time?
[14:41:42 CET] <durandal_170> wm4: the first sample never worked?
[14:44:24 CET] <wm4> dunno
[15:20:28 CET] <wm4> what's the status of HDS support? I see there's some old work spread around...
[16:51:17 CET] <nevcairiel> so many streaming protocols
[16:52:16 CET] <Daemon404> i can make more if you wish
[16:52:41 CET] <nevcairiel> sure, why not
[16:53:13 CET] <Compn> make mplayer's netstream.c into a standard
[17:10:01 CET] <durandal_170> wm4: fixed
[17:14:36 CET] <wm4> works
[17:34:32 CET] <kierank> fuzzing h264 sliced threads looks good now
[17:34:48 CET] <kierank> but still a reasonable amount left
[17:59:19 CET] <Timothy_Gu> what's with zimg? is it better than libswscale?
[17:59:51 CET] <wm4> yes
[17:59:56 CET] <Timothy_Gu> in what way?
[18:00:01 CET] <JEEB> does things correctly
[18:00:14 CET] <Timothy_Gu> ?
[18:01:45 CET] <JEEB> although the issue right now is that it doesn't seem to propagate its output colorspace into the next part
[18:01:54 CET] <JEEB> should send a patch for that :V
[18:02:06 CET] <JEEB> s/colorspace/colorimetry/
[18:02:25 CET] <Timothy_Gu> ok
[18:02:31 CET] <Timothy_Gu> also https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/blockdsp.c#L35 <-- why 6
[18:03:28 CET] <wm4> uh we have custom asm for memset?
[18:04:02 CET] <Timothy_Gu> not for x86
[18:04:15 CET] <Timothy_Gu> actually i take that back
[18:04:20 CET] <Timothy_Gu> yes apparently
[18:04:27 CET] <wm4> lol
[18:12:27 CET] <Daemon404> wur
[18:12:29 CET] <Daemon404> wut
[18:15:55 CET] <wm4> man av_strtod is so misleading
[18:17:44 CET] <cbsrobot> btw zimg compiles now on osx too
[18:19:13 CET] <JEEB> nice
[19:10:09 CET] <durandal_170> can I get some reviews?
[19:14:51 CET] <atomnuker> durandal_170: bump lavc major and lavf minor?
[19:15:10 CET] <atomnuker> also you're missing a letter on your nick
[19:15:33 CET] <jamrial> not major
[19:16:09 CET] <atomnuker> minor and micro, sorry
[19:34:11 CET] <atomnuker> huh, totally forgot about the IETF ffv1+flac+mkv thing
[19:34:55 CET] Action: Daemon404 still wonders why flac was chosed over a saner format like wavpack
[19:36:48 CET] <atomnuker> because it can be lossy?
[19:37:35 CET] <wm4> why use flac at all? it saves only 50% of already smallish data (compared to video)
[19:37:36 CET] <atomnuker> besides, that and float samples is the only things flac is missing compared
[19:38:26 CET] <atomnuker> wm4: yes, let's standartize wav + WAVEFORMATEXTENSIBLE
[19:39:47 CET] <wm4> mkv has pcm support
[19:40:06 CET] <wm4> granted, maybe that's not sane either (no channel layouts)
[19:40:25 CET] <wm4> you could of course use vfw muxing
[19:40:54 CET] <nevcairiel> how is wavpack saner than flac
[19:40:58 CET] <jamrial> flac is probably the fastest lossless codec, while also being decent at compression
[19:41:13 CET] <Daemon404> it's no faster/slower than wavpack at a comparable speed
[19:41:17 CET] <Daemon404> er comp level
[19:41:23 CET] <Daemon404> with the downside of an insane format
[19:41:31 CET] <Daemon404> byte alignment is for chumps, etc
[19:41:37 CET] <nevcairiel> wavpack has this totally insane hybrid format
[19:41:41 CET] <nevcairiel> so go back to finding a new one =P
[19:41:43 CET] <Daemon404> thats entirely optional
[19:41:51 CET] <Daemon404> the file format itself is fine without that
[19:42:09 CET] <Daemon404> stereo/mono channel paids, with a chennel layout
[19:42:12 CET] <Daemon404> pairs*
[19:42:15 CET] <Daemon404> byte alignment (!)
[19:42:59 CET] <atomnuker> it's hybrid so it was not even considered probably
[19:43:31 CET] <nevcairiel> wavpack is an unknown niche format compared to flac, really
[19:43:45 CET] <Daemon404> thats certainly true
[19:43:51 CET] <Daemon404> atomnuker, hybride is entirely optional
[19:44:00 CET] <Daemon404> next to nobody uses it
[19:44:11 CET] <atomnuker> regardless, you don't want people thinking your completely lossless standard can be half lossless
[19:44:13 CET] <jamrial> every lossless format except for flac are unknown niche formats. even alac is :p
[19:44:28 CET] <Daemon404> atomnuker, that's a pretty stupid reason
[19:44:28 CET] <atomnuker> (or a quater lossless)
[19:44:37 CET] <Daemon404> "people might assume stuff without reading what we actually use"
[19:44:49 CET] <atomnuker> yep, they sure love to
[19:44:53 CET] <Daemon404> jamrial, an ffv1 isnt? :P
[19:44:57 CET] <Daemon404> and*
[19:45:16 CET] <Daemon404> compared to e.g. huffyuv and lagarith
[19:45:20 CET] <jamrial> haha, point
[19:47:08 CET] <nevcairiel> iirc they wanted open and free formats, so maybe those wouldnt work?
[19:47:32 CET] <Daemon404> they would
[19:47:41 CET] <Daemon404> but they dont compress as well
[19:56:36 CET] <kierank> wm4: afaik ietf just wanted a complementary lossless codec to opus
[19:56:50 CET] <Timothy_Gu> anyone with trac admin: could you please revert to https://trac.ffmpeg.org/wiki/FFmeeting/2014-01?action=edit&version=4 ? Copy pasted the log into the wrong page
[19:56:50 CET] <kierank> And to complement ffv1
[19:57:38 CET] <Timothy_Gu> I can't do it because apparently the content of the meeting is spammy
[20:22:45 CET] <durandal_170> this xma1/xma2 thing is pure nonsense, nightmare to work with
[20:23:11 CET] <michaelni> Timothy_Gu, deleted version 5
[20:40:36 CET] <Timothy_Gu> michaelni: ok thx
[21:23:11 CET] <ubitux> M:N API draft on its way; i have a working prototype, need to figure out a bunch of "details" and i can submit a RFC by the end of this coming week
[21:23:29 CET] <JEEB> nice
[21:24:13 CET] Action: Daemon404 wonders id this will end up being a big merge problem with the supposedly coming libav M:N
[21:25:05 CET] <nevcairiel> ubitux isnt silly enough to try to push it without involving the other side at all, or so I hope
[21:25:31 CET] <ubitux> yeah i'll probably put libav in cc
[21:25:42 CET] <ubitux> could be easily rebasable on libav i suppose, at least for the first part
[21:26:17 CET] <ubitux> nlmeans in progress too, but more slowly :x
[21:26:28 CET] <ubitux> pro vs free time dilemma
[21:26:30 CET] <ubitux> :(
[21:26:36 CET] <Daemon404> well
[21:26:47 CET] <Daemon404> luca has it WIP... in theory
[21:26:50 CET] <Daemon404> i dunno
[21:26:53 CET] Action: Daemon404 just grabs popcorn
[21:27:20 CET] <ubitux> his rfc didn't answer the important questions
[21:27:28 CET] <ubitux> as in error management and where is it blocking or not
[21:27:37 CET] <nevcairiel> his rfc was some blog blob with 3 concepts muddled together, nothing really clear
[21:27:55 CET] <ubitux> yeah, i actually started implementing his draft
[21:27:58 CET] <ubitux> wasn't very viable
[21:28:16 CET] <nevcairiel> ooh opus in ts muxing patches
[21:28:20 CET] <nevcairiel> i was waiting for that, kinda
[21:28:31 CET] <Daemon404> that doesnt stop :drama:, nevcairiel
[21:29:01 CET] <Daemon404> im on ubitux's side here :P
[21:29:08 CET] Action: Daemon404 just will be on the sidelines
[21:32:53 CET] <ubitux> wm4: " - implement a thread-safe queue for packets/frames"  we actually have lavu/threadmessage in ffmpeg (generic thread safe queue), and this is extremelly useful because it's handling error
[21:33:02 CET] <ubitux> i make heavy use of them
[21:34:08 CET] <ubitux> that might be problematic if i want to submit to libav, but well
[21:43:43 CET] <nevcairiel> threasmessage.h has a weird documentation problem, av_thread_message_queue_set_err_send talks about returning the error from av_thread_message_queue_recv and vice-versa, which seems backwards to begin with, and the code does it the other way around :)
[21:45:55 CET] <wm4> ubitux: awesome
[21:46:01 CET] <wm4> not sure if I trust this threadmessage stuff
[21:46:11 CET] <ubitux> nevcairiel: growing and reducing the fifo can be blocking (if full or empty), setting the error unblock one or another
[21:46:29 CET] <nevcairiel> the comment still doesnt make sense
[21:46:42 CET] <ubitux> wm4: yes, i'm unsure about one thing: the fact that it's using a single condition for growing and reducing
[21:46:54 CET] <nevcairiel> the error set by av_thread_message_queue_set_err_send will be returned from av_thread_message_queue_send, as the function names may suggest
[21:47:01 CET] <nevcairiel> yet the comment says otherwise :D
[21:47:08 CET] <ubitux> i think i need to write a PoC to test if it can not stall (iiuc there is a corner care where it does)
[21:47:30 CET] <ubitux> nevcairiel: i actually didn't read the doxy
[21:47:35 CET] <ubitux> the code is short enough
[21:47:58 CET] <ubitux> it's btw in use in ffmpeg (for multiple demuxing source, scheme i'm reproducing)
[21:47:58 CET] <wm4> for one this threadmessage thing doesn't have everything that'd be needed, like a way that doesn't force you to either block potentially forever, or use polling
[21:48:34 CET] <wm4> and this weird concept of sending an error code?
[21:48:35 CET] <ubitux> it's just a thread safe queue building block, that goes above, which is what i use
[21:48:51 CET] <ubitux> anyway, enough teasing
[21:53:19 CET] <atomnuker> when did we end up accepting that bulgarian hosting offer, I though most people were against that
[21:54:43 CET] <iive> nobody have said anything against it, at the time
[21:56:49 CET] <iive> and I haven't heard any objections for quite a while. It took months until all papers were signed.
[21:58:01 CET] <iive> if somebody have objected during that time, the offer could have easily been canceled.
[22:21:42 CET] <iive> atomnuker: btw, where are you from?
[22:24:06 CET] <kierank> I need a name for my blog post about fuzzing
[22:24:27 CET] <kierank> FFuzzing
[22:25:20 CET] <Daemon404> Fu**ing ffmpeg?
[22:27:41 CET] <thardin> ^
[22:28:35 CET] <Gramner> 10/10 would fu** again
[22:53:36 CET] <kierank> "Fuzzing FFmpeg for fun and profit"
[22:56:21 CET] <ubitux> for fun and frofit
[22:56:29 CET] <ubitux> never stop the f
[22:58:22 CET] <kierank> http://obe.tv/about-us/obe-blog/item/26-fuzzing-ffmpeg-for-fun-and-profit
[23:07:16 CET] <durandal_1707> I also found few ffv1 bugs with afl
[23:09:01 CET] <kierank> ah, was just talking about my fuzzing but can mention you if you want
[23:09:11 CET] <kierank> I haven't fuzzed ffv1 with afl yet
[23:09:39 CET] <kierank> and vp8/9 is next on my list
[23:19:29 CET] <BBB> \o/
[23:21:36 CET] <kierank> ffv1 will be hard though because the file sizes are so big
[23:22:31 CET] <Gramner> you can go really low res I guess
[23:22:38 CET] <kierank> yeah
[23:25:15 CET] <BBB> kierank: so how does the profit work?
[23:25:19 CET] <BBB> kierank: one beer per bug?
[23:25:25 CET] <BBB> (darn it I owe you one already)
[23:25:56 CET] <kierank> people pay monies for our boxes and now they don't crash in slice threads mode
[23:26:13 CET] <cbsrobot> kierank: can you share the script ?
[23:26:31 CET] <kierank> basically https://github.com/rillian/afl-ffmpeg-opus
[23:26:43 CET] <cbsrobot> thx
[23:26:52 CET] <kierank> but I changed it to support multithreading
[23:26:53 CET] <kierank> one sec
[23:27:07 CET] <kierank> http://paste.ubuntu.com/13076450/
[23:27:15 CET] <kierank> very crude, I am sure there are better ways
[23:27:53 CET] <kierank> the trick seems to be to use dd to make samples which are a few hundred kB
[23:33:30 CET] <BBB> do you still need samples with full code coverage?
[23:33:34 CET] <BBB> or does afl take care of that?
[23:33:41 CET] <BBB> or do you need both for best results?
[23:35:52 CET] <kierank> not sure, I deliberately encoded progressive stuff as interlaced in order to have more interlaced codepaths used
[23:36:14 CET] <kierank> I need to get some non-x264 ones I guess as well
[23:40:17 CET] <Timothy_Gu> what's the difference between v210 and v210x?
[23:40:49 CET] <kierank> some weird endian change
[23:42:14 CET] <Timothy_Gu> hm
[00:00:00 CET] --- Mon Nov  2 2015