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

[burek]

[00:36:40 CET] <ethe> ubitux: I think this should work now. I can't test it on anything else other than OSX though https://gist.github.com/anonymous/ce6da631796cbaff69a7
[01:47:53 CET] <cone-478> ffmpeg 03Michael Niedermayer 07master:5590ab45e0b1: ffmpeg: Check best_effort_timestamp after rescale
[10:28:06 CET] <JEEB> hmm
[10:28:15 CET] <JEEB> did we have a feature for pushing a single mux into multiple outputs?
[10:28:44 CET] <durandal_170> tee muxer?
[10:30:24 CET] <JEEB> oh wow
[10:30:26 CET] <JEEB> cheers
[10:31:20 CET] <JEEB> I had somehow completely missed that one
[11:00:52 CET] <ubitux> i'm looking at the png dsp; it seems src and dst buffers are padded, so why is add_bytes doing overwrite checks?
[11:32:46 CET] <durandal_170> nobody tried loop filters?
[11:34:01 CET] <durandal_170> michaelni: have you sent gsoc request?
[11:37:36 CET] Action: wm4 stares at 30 mails saying "probably ok" on libav-devel
[11:37:39 CET] <wm4> quite literally
[11:38:39 CET] <durandal_1707> carl was right :P
[11:41:13 CET] <durandal_1707> the codecpar patches are benign
[11:45:15 CET] <iive> the 269 patches?
[11:45:50 CET] <durandal_170> so many demuxers
[11:47:27 CET] <michaelni> durandal_1707, yes i sent the gsoc req, carl and reynaldo then did fill out the new fields in the forms/questions
[12:09:28 CET] <ubitux> damn, i must say the neon set on aarch64 is quite nice.
[12:10:09 CET] <durandal_170> really? How fast it can get?
[12:12:50 CET] <cone-349> ffmpeg 03Paul B Mahol 07master:08acab85d342: avfilter: add loop filters
[12:15:29 CET] <durandal_1707> 27 to go
[12:17:03 CET] <durandal_1707> *filters to reach 300th one
[12:22:51 CET] <ubitux> durandal_1707: no idea, i can't bench :D
[12:22:57 CET] <ubitux> but the instruction set is really nice
[12:23:16 CET] <ubitux> i get asm smaller that C equivalent
[12:27:09 CET] <durandal_170> really wants motion estimation filter
[13:36:23 CET] <cone-349> ffmpeg 03Thomas Mundt 07master:da94d619f641: avfilter: add BobWeaver deinterlacing filter
[14:42:36 CET] <cone-349> ffmpeg 03Michael Niedermayer 07master:090b673aba21: avformat: add ff_reshuffle_raw_rgb()
[14:42:37 CET] <cone-349> ffmpeg 03Michael Niedermayer 07master:07c7e71d20f7: avformat/avienc: Split avi_write_packet_internal() out
[14:46:49 CET] <ethe> ubitux did you see my updated patch?
[14:47:32 CET] <ubitux> +    ( check_func sem_timedwait || check_header dispatch/dispatch.h ) &&
[14:47:41 CET] <ubitux> since you have them in lists
[14:47:56 CET] <ubitux> you can probably instead do enabled sem_timedwait || enabled dispatch_dispatch_h
[14:52:52 CET] <wm4> lol everyone is reporting breakages over that libav configure change (apparently)
[14:54:45 CET] <ubitux> yeah well, it's really broken
[14:55:19 CET] <ubitux> they still haven't send a revert patch?
[14:55:32 CET] <J_Darnley> Has the spaghetti finally become too knotted to pick apart?
[14:55:32 CET] <ubitux> we should probably revert ourselves
[14:55:53 CET] <wm4> J_Darnley: no, someone added something to the spaghetti without knowing what he was doing
[14:56:08 CET] <wm4> the latter is _very_ easy with this insane 7kloc sh script we have
[14:56:23 CET] <J_Darnley> Could be worse.  Could be autotools
[15:00:53 CET] <atomnuker> m4 is a tool of satan
[15:02:40 CET] <RiCON> wonder why no one made a PR in GitHub to Cmake-fy FFmpeg yet
[15:02:54 CET] <wm4> maybe it was too hard
[15:03:29 CET] <durandal_170> atomnuker: look at ffmpeg -codecs output
[15:05:19 CET] <fritsch> kodi is going cmake
[15:05:23 CET] <fritsch> on all platforms currently
[15:05:35 CET] <wm4> I'm so sorry
[15:05:49 CET] <fritsch> yeah - most people that don't understand cmake - tells that :-)
[15:06:05 CET] <nevcairiel> cmake isnt any better than other build systems
[15:06:13 CET] <wm4> cmake is just ridiculously bad in all aspects
[15:06:24 CET] <wm4> I had my own share of fun with it
[15:06:32 CET] <wm4> (I'd prefer ffmpeg's build system any time)
[15:06:46 CET] <J_Darnley> Uh oh.  I'm starting to feel like I should never have said anything.
[15:06:48 CET] <nevcairiel> I like simple projects that have nothing but a makefile
[15:07:38 CET] <durandal_170> we should not have configure, user should manually build
[15:08:12 CET] <atomnuker> durandal_170: what's wrong with ffmpeg -codecs?
[15:08:51 CET] <durandal_170> count how many times it writes DEVILS
[15:09:20 CET] Action: J_Darnley guesses six hundred and sixty-six
[15:10:07 CET] <wm4> only 3 times here
[15:10:24 CET] <ubitux> BBB: aarch64 is really simple, you'll probably like it
[15:10:31 CET] <ubitux> i miss the macro fun though
[15:10:40 CET] <ubitux> the gas pp is too limited :(
[15:10:45 CET] <BBB> hm...
[15:10:49 CET] <BBB> maybe we need a new meta language
[15:10:58 CET] <nevcairiel> "C"?
[15:10:58 CET] <nevcairiel> :D
[15:11:01 CET] <durandal_170> lavfi
[15:11:24 CET] <ubitux> BBB: but honestly, the assembler is really straightforward, and a pleasure to deal with wrt bytes
[15:11:28 CET] <ubitux> contrary to x86
[15:11:29 CET] <wm4> how about a sh script that generates asm (this would be so deliciously evil)
[15:11:38 CET] <nevcairiel> whats wrong with javascript
[15:11:48 CET] <fritsch> php +1
[15:11:59 CET] <ubitux> BBB: also, no need for all the instruct set ifdefery 
[15:12:04 CET] <ubitux> so code is way cleaner
[15:12:06 CET] <JEEB> nevcairiel: sounds like boost's build system
[15:12:09 CET] <JEEB> or was it c++?
[15:12:14 CET] <JEEB> it builds the build system first
[15:12:18 CET] <ubitux> the only thing i miss is some good doc
[15:12:19 CET] <JEEB> then builds boost
[15:12:21 CET] <ubitux> damn that doc is shit..
[15:12:27 CET] <nevcairiel> yeah boost has its own binary build thing
[15:12:28 CET] <BBB> real men write assembler
[15:12:30 CET] <BBB> that outputs assembler
[15:12:35 CET] <BBB> so ...
[15:12:36 CET] <nevcairiel> i never looked into how it works
[15:12:36 CET] <BBB> anyway
[15:12:37 CET] <BBB> :D
[15:12:42 CET] <ubitux> :)
[15:12:42 CET] <nevcairiel> but it just worked when i needed to build boost
[15:12:44 CET] <BBB> ubitux: ok that sounds pretty cool
[15:13:36 CET] <ubitux> BBB: png add bytes (no boundary checks): http://pastie.org/pastes/10727437/text
[15:14:14 CET] <BBB> how about vp9 loopfilter? :-p
[15:14:23 CET] <atomnuker> DEVILS jpeg2000 DEVILS jpegls DEVILS webp
[15:14:27 CET] <atomnuker> I KNEW IT
[15:14:29 CET] <ubitux> BBB: probably prettier ;)
[15:14:35 CET] <BBB> also, from what I recall, libvpx has all arm64 code in intrinsics
[15:14:43 CET] <BBB> and so does libav
[15:14:45 CET] <atomnuker> proof that jpeg2000 and webp are spawns of satan himself!
[15:14:49 CET] <BBB> so & thats not necessary?
[15:15:06 CET] <wbs> BBB: no, libav has got separate arm and aarch64 asm
[15:15:17 CET] <wbs> BBB: there's only one small snippet that somebody from linaro contributed that is in intrinsics
[15:15:23 CET] <BBB> oh, ok, interesting
[15:15:29 CET] <BBB> so why does libvpx have intrinsics then
[15:15:29 CET] <ubitux> BBB: 32 simd reg, no need for intrinsic
[15:15:31 CET] <BBB> blegh
[15:15:31 CET] <ubitux> :D
[15:15:37 CET] <BBB> 32 reg& omg
[15:15:44 CET] <BBB> you can almost write a stack-free idct32x32
[15:16:01 CET] <nevcairiel> avx512 extends all xmm/ymm to 32 as well :D
[15:18:15 CET] <jamrial> but that's simd registers. aarch64 also has 32 gprs
[15:18:26 CET] <durandal_1707> ubitux: how is division handled?
[15:19:40 CET] <ubitux> only float in simd afaict
[15:41:36 CET] <ubitux> cmge v0.16B,v1.16B,v2.16B  OK
[15:41:52 CET] <ubitux> cmle v0.16B,v1.16B,v2.16B  NOT OK
[15:41:56 CET] <ubitux> Error: operand 1 should be a SIMD scalar register -- `cmle v0.16B,v1.16B,v2.16B'
[15:42:04 CET] <ubitux> the doc even says cmle is an alias for cmge :(
[15:44:47 CET] <ubitux> similarly cmgt works, cmlt doesn't
[15:46:28 CET] <ubitux> sadness.
[15:56:51 CET] <ubitux> http://infocenter.arm.com/help/topic/com.arm.doc.dui0802a/UZP1_advsimd_vector.html useful doc is useful
[15:57:02 CET] <ubitux> "uzp" = "unzip" thx
[16:18:47 CET] <ethe> ubitux: this should do it https://gist.github.com/anonymous/4c96f7d6d1777793bdd4
[16:20:42 CET] <ubitux> ok but now the jack indev is enabled gets enabled even when sem_timedwait and dispatch_dispatch_h are unavailable
[16:21:33 CET] <BBB> michaelni: Id just revert immediately
[16:24:05 CET] <durandal_1707> reverting merges, what if one try to merge other changes?
[16:29:34 CET] <cone-349> ffmpeg 03Moritz Barsnick 07master:6eaad752c1c6: lavf/options_table: mark use_wallclock_as_timestamps as boolean
[16:29:35 CET] <cone-349> ffmpeg 03Michael Niedermayer 07master:8fdee3ee8fb5: Revert 4 commits to configure which broke dependency handling
[16:29:57 CET] <michaelni> durandal_1707, same as if the merges had been "skiped"
[16:39:29 CET] <ethe> ubitux right. yeah idek then
[16:40:52 CET] <ubitux> ethe: || disable jack at the end maybe
[16:41:01 CET] <ubitux> or a smarter dep
[16:42:29 CET] <ethe> I have no idea, I've never done anything with FFmpeg before, and the configure script isn't exactly that straight-forward
[16:43:02 CET] <ethe> ohwait, I think I see what you mean
[16:51:08 CET] <wm4> ethe: oh that looks nice, I didn't know there was such a simple mapping from the dispatch stuff to posix semaphores
[16:53:09 CET] <ubitux> not sure anyone if anyone will know that, but any idea how to get v0=ABCDEFGHIJKLMNOP from v1=AABBCCDDEEFFGGHH and v2=IIJJKKLLMMNNOOPP in neon? 
[16:53:10 CET] <ethe> It works pretty nicely, I'm not sure if ffmpeg uses posix semaphores in other places, but GCD is probably the way to go for operating systems that have it (I'm pretty sure it's OSX & FreeBSD but I'm still trying to confirm that FreeBSD uses it)
[16:53:36 CET] <ubitux> (AA, BB, CC, ... are 0x0000 or 0xffff)
[16:53:53 CET] <wm4> surely fbsd actually supports posix
[16:54:09 CET] <ubitux> it seems i can somehow do that in 3 instr. but that sucks
[16:58:13 CET] <ethe> wm4: It does, but GCD is supposedly faster, but if posix works, there's no real reason to change them. 
[17:06:52 CET] <nevcairiel> whoever invented nested SEI messages in h264 deserves a special kind of hell
[17:11:50 CET] <kierank> nevcairiel: which message is nested?
[17:12:01 CET] <kierank> or you mean the one where they write a single NAL with multiple SEIs?
[17:12:17 CET] <nevcairiel> no, they have SEI messags that can contain a new SEI inside of it
[17:12:30 CET] <kierank> hevc?
[17:12:34 CET] <nevcairiel> h264
[17:13:08 CET] <kierank> which sei si that
[17:13:31 CET] <nevcairiel> apparently only used in annex g and annex h, ie. scalable and multiview
[17:13:58 CET] <nevcairiel> why they didnt just code multiple SEIs is beyond me
[18:50:44 CET] <ethe> why does using "-hide_banner" make it an invalid ticket?
[18:51:30 CET] <nevcairiel> because it hides the version and compile options
[20:01:08 CET] <wm4> "merge of ffmpeg and ffplay"
[20:01:30 CET] <wm4> "SVG decoder"
[20:03:07 CET] <JEEB> sounds real good yo
[20:03:34 CET] <jamrial> he did say the former was probably naive
[20:23:52 CET] <kurosu_> and even if not, there's no harm in asking, he's candidating for gsoc
[21:01:10 CET] <wm4> so uh
[21:01:14 CET] <wm4> what can we give them to do
[21:01:20 CET] <wm4> surely there are good ideas around
[21:01:52 CET] <durandal11707> libavdevice API
[21:02:58 CET] <BtbN> merges
[21:03:15 CET] <durandal11707> let they do merges :)
[21:08:05 CET] <kurosu_> is there anything in what he listed that is not yet exported, but would be useful to export eg as metadata? From what I understand, it seems a core topic in his proposals
[21:14:13 CET] <durandal11707> kurosu_: only stuff then get printed at end of processing
[21:18:59 CET] <durandal11707> imho rdft/fft should be moved to lavu
[21:20:05 CET] <durandal11707> why vp9 encoder doesn't set supported pix fmts?
[21:28:20 CET] <JEEB> hmm
[21:28:21 CET] <JEEB> https://github.com/FFmpeg/FFmpeg/blame/master/libavfilter/vf_zscale.c#L545
[21:28:24 CET] <JEEB> so this has always been here
[21:28:56 CET] <JEEB> yet I distinctly remember that I didn't get the BT.709 flag set when encoding with libx264
[21:29:06 CET] Action: JEEB scratches head
[21:32:13 CET] <durandal11707> JEEB: default is whatever input have
[21:32:30 CET] <JEEB> yes, I can see the code
[21:32:56 CET] <JEEB> I just distinctly remember not getting it through but this forces me to think about retrying just to make sure I wasn't dreaming
[21:33:33 CET] <cone-349> ffmpeg 03Michael Niedermayer 07master:9dd4dcde9cde: avformat/avienc: Use avi_write_packet_internal() to store raw rgb in a more spec compliant way
[21:44:42 CET] <ethe> I really don't how the configure part could be wrong now, so if it is, I'd be grateful if someone explained why it's wrong https://gist.github.com/507fc57c9f934c1b64a3 (Patch for issue #43)
[21:45:01 CET] <durandal11707> michaelni: why colorspace,range,transfer,primaries are not stored if ffv1?
[21:46:00 CET] <JEEB> nobody thought of it I guess?
[21:46:45 CET] <JEEB> ethe: that seems to have a lot of... unrelated changes in it?
[21:46:56 CET] <ethe> ohwait
[21:47:03 CET] <ethe> yeah something broke
[21:47:29 CET] <ethe> https://gist.github.com/28e1408a13444f1dbaf4 <-- there we go
[21:47:41 CET] <ethe> apparently I didn't change the commit I was diffing from
[21:50:16 CET] <michaelni> durandal11707, the idea was that its stored in the codec layer. But it surely could be added to cover the cases like rawvideo ...
[21:51:30 CET] Action: michaelni mixed nut up with ffv1, lets see where i put my brain
[21:52:07 CET] <durandal11707> michaelni: adding it to nut wouldn't hurt but it's tricky
[21:55:19 CET] <cehoyos> ethe: Did you test jack with the resulting binary?
[21:57:00 CET] <michaelni> it could be added to ffv1, or not or both. Storing ffv1 in mpeg-ps would need it in ffv1, storing rawvideo in nut would need it in nut
[22:02:10 CET] <durandal11707> ffmpeg -h full output have 8k lines
[22:02:46 CET] <JEEB> I think nowadays since I always have a browser open I just write ffmpeg-all into my url bar
[22:02:52 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html
[22:06:12 CET] <ethe> cehoyos: yes, it works.
[22:13:17 CET] <cehoyos> ethe: Could you post console output to the ticket? I wonder why it didn't work for me...
[22:23:44 CET] <cehoyos>  ethe: Thank you! Please send your patch made with "git format-patch" to the development mailing list
[22:24:16 CET] <wm4_> cehoyos: you never send git format-patches to the ML
[22:24:45 CET] <JEEB> well, their content, no?
[22:24:52 CET] <JEEB> like what git send-email does
[22:25:19 CET] <JEEB> I'm taking the freedom of thinking that he meant that instead of attaching things as attachments
[22:25:28 CET] <JEEB> although lately that seems to be accepted as well
[22:34:38 CET] <JEEB> cehoyos: seems like this poor soul doesn't have a mail provider that lets him send out plain text e-mails
[22:34:44 CET] <nevcairiel> as long as its actually a git format-patch thing its generally OK
[22:35:00 CET] <JEEB> and I don't have send-email set up in this thing so welp
[22:35:03 CET] <nevcairiel> but just pasting diffs without author info etc are annoying
[22:35:11 CET] <JEEB> yeah
[22:36:07 CET] <TD-Linux> durandal11707, JEEB, ffv1 v4 on the CELLAR mailing list is adding them
[22:36:23 CET] <JEEB> nice
[22:47:01 CET] <durandal_1707> TD-Linux: link?
[22:48:43 CET] <TD-Linux> durandal_1707, https://mailarchive.ietf.org/arch/search/?email_list=cellar
[22:49:01 CET] <TD-Linux> apologies for the horrific archive viewer
[22:53:48 CET] <nevcairiel> and i thought pipermail is terrible
[22:53:53 CET] <nevcairiel> this one doesnt even have threads
[00:00:00 CET] --- Fri Feb 19 2016