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

[burek]

[00:30:01 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vS7Gw
[00:30:01 CEST] <KGB> 13FFV1/06master 1490aea8b 15Ashley Blewer: updates instances of colorspace to "color space" for consistency...
[00:30:26 CEST] <Guest23257> [13FFV1] 15michaelni closed pull request #55: updates instances of colorspace to "color space" for consistency (06master...06ab/colorspace) 02https://git.io/vS1AP
[02:56:28 CEST] <michaelni> atomnuker, if you want you can push the 3.3 news patch or if i should push it, please say so
[02:58:09 CEST] <atomnuker> I didn't know I can push (nor that it would change the website)
[02:58:16 CEST] <atomnuker> also no idea what the push url would be
[03:47:25 CEST] <J_Darnley> Blimey.  I've been wasting all evening/night and will have to clean up my not-work patches tomorrow.
[05:54:28 CEST] <jamrial> durandal_1707: your dnxhd patches broke every related vsynth test
[06:11:07 CEST] <cone-190> ffmpeg 03Steven Liu 07n3.4-dev:HEAD: avformat/hlsenc: add hls encrypt options
[07:50:00 CEST] <cone-190> ffmpeg 03Carl Eugen Hoyos 07master:b9e4bbc68651: lavc/opus_pvq: Add missing copyright notices from libopus.
[09:25:04 CEST] <cone-190> ffmpeg 03Paul B Mahol 07master:f6b5a5c7d05a: avcodec/dnxhdenc: fix recent regression
[12:39:02 CEST] <cone-324> ffmpeg 03Marton Balint 07master:915bb7881555: ffplay: convert to new decode API
[12:39:02 CEST] <cone-324> ffmpeg 03Marton Balint 07master:e8547647292e: ffplay: fix indentation
[12:39:02 CEST] <cone-324> ffmpeg 03Aaron Levinson 07master:9e86a61870c1: avdevice/decklink: remove pthread dependency
[13:54:16 CEST] <durandal_1707> here you go: another zlib screen capture decoder
[14:10:42 CEST] <JEEB> durandal_1707: they sure like that don't they
[14:11:16 CEST] <durandal_1707> JEEB: who? devs?
[14:11:51 CEST] <JEEB> screen capture format devs
[14:12:36 CEST] <durandal_1707> they dont know anything different, usua:ly
[15:38:05 CEST] <J_Darnley> Dammit!  Why does Linux on my laptop have 2 different clipboards?
[15:39:35 CEST] <atomnuker> X
[15:40:09 CEST] <atomnuker> and there aren't 2 clipboards, there are 3
[15:40:21 CEST] <atomnuker> primary, secondary and clipboard
[15:41:21 CEST] <J_Darnley> Ah,  It seems like I can use Ctl-Shift-V to paste in my terminal
[15:44:12 CEST] <durandal_1707> really?
[15:44:27 CEST] <durandal_1707> 3 clipboards?
[15:46:14 CEST] <wm4> I find 2 clipboards pretty convenient
[15:46:30 CEST] <Compn> having multiple clipboards could be useful, as long as you instruct the user how to use them easily
[15:46:50 CEST] <Compn> e.g. want to copy paste between 2 sets of 4 different things
[15:46:57 CEST] <Compn> at the SAME TIME
[15:47:07 CEST] Action: Compn multitasks his brain
[16:58:48 CEST] <atomnuker> J_Darnley: is that demuxer really for a 32 year old game?
[17:01:03 CEST] <J_Darnley> 32?  No 10 with a new Worldwide release last year
[17:01:11 CEST] <J_Darnley> *no, 10, with...
[17:02:06 CEST] <J_Darnley> Oh, I guess I forgot to put "Xanadu Next" anywhere in there
[17:02:09 CEST] <J_Darnley> My bad
[17:29:44 CEST] <BBB> J_Darnley: I have no specific objection to the patch, Ive said that before, but I hope you can see my general point that if were gonna do it differently then that probably has effects beyond just h264_idct that we have to consider
[17:29:57 CEST] <BBB> J_Darnley: but I agree that right now disassembly is painful to go through :(
[17:32:43 CEST] <RiCON> minor issue: libzvbi.h includes pthread.h so it breaks when compiling decklink with --enable-w32threads: https://i.fsbn.eu/eGOE.txt
[17:36:33 CEST] <J_Darnley> BBB I understand
[17:37:14 CEST] <BBB> maybe asking to fix objdump etc. is taking it too far, but Im confused that in the past (I believe w/ gdb) this wasnt an issue
[17:37:22 CEST] <BBB> its only with objdump and lldb that this has become an issue for me
[17:37:23 CEST] <BBB> (IIRC)
[17:37:58 CEST] <J_Darnley> perf is another tool that shows dot labels
[17:38:42 CEST] <BBB> Im ok with showing it, I just dont want it to cut off blocks and stop displaying by default from the next label onwards ;)
[17:38:47 CEST] <BBB> (which is what lldb does, sadly)
[17:38:57 CEST] <J_Darnley> Ah.  That is much worse
[17:39:04 CEST] <BBB> so disass at the start of a function thats basically one giant loop will show me one instruction
[17:39:13 CEST] <BBB> mov r3d, $10
[17:39:17 CEST] <BBB> which means the loop iterates 16 times
[17:39:23 CEST] <BBB> but otherwise it wont show me the loop
[17:39:26 CEST] <BBB> which is infuriating
[17:39:39 CEST] <BBB> so I have to stepi and then re-disass
[17:39:43 CEST] <BBB> and only then does it show me the loop
[17:39:45 CEST] <BBB> drives me nuts
[17:39:50 CEST] <nevcairiel> RiCON: decklink includes zvbi?
[17:40:26 CEST] <nevcairiel> anyway if that cant be turned off, then libzvbi support probably needs to be turned off if pthreads isnt  used
[17:40:46 CEST] <BBB> brb
[17:46:40 CEST] <RiCON> nevcairiel: no, but for some reason libzvbi.h is being included when compiling the c++ decklink_dec files
[17:47:15 CEST] <nevcairiel> well there must be some reason :)
[17:47:48 CEST] <nevcairiel> it can apparently use zvbi to read teletext data
[17:48:15 CEST] <RiCON> so it's still not completely undependant on pthreads
[17:48:39 CEST] <nevcairiel> cant control external libraries
[17:49:04 CEST] <wm4> so zvbi on windows relies on winpthreads or what? in their public headers?
[17:49:27 CEST] <nevcairiel> it just relies on pthreads, it probably doesnt care where it comes from
[17:49:49 CEST] <nevcairiel> even worse though, the only reason it includes it is because it has a mutex in a private part of a struct
[17:49:51 CEST] <RiCON> https://i.fsbn.eu/wFN2.txt libzvbi.h L1064
[17:51:26 CEST] <RiCON> my workaround was disabling w32threads when decklink was enabled, so now it'll be when both zvbi and decklink are enabled
[17:51:31 CEST] <wm4> lol "private"
[17:51:53 CEST] <wm4> should ask upstream to move that into a malloced internal struct
[17:52:07 CEST] <RiCON> upstream seems dead
[17:52:18 CEST] <RiCON> wasn't durandal_1707 working on native zvbi?
[17:52:34 CEST] <nevcairiel> seems like a waste of time to me
[17:54:15 CEST] <durandal_1707> zvbi does more than eia608
[17:54:17 CEST] <J_Darnley> jamrial: FYI you replied directly to me instead of to the list
[17:54:41 CEST] <jamrial> J_Darnley: yeah, latest thunderbird changed the behavior of the reply button
[17:54:51 CEST] <jamrial> now i need to click on reply list instead
[17:54:58 CEST] <J_Darnley> Oh that was useful
[17:55:04 CEST] <nevcairiel> stupid mail client
[17:55:10 CEST] <nevcairiel> who wants to respond to people directly on a ML
[18:06:38 CEST] Action: J_Darnley disables updates in Thunderbird before he suffers that same fate
[18:09:04 CEST] <J_Darnley> Blimey.  Half the time in this function is spent on a pshufd and a paddq
[18:26:25 CEST] <Compn> you know
[18:26:30 CEST] <Compn> you can edit the thunderbird buttons
[18:26:40 CEST] <Compn> or i guess add a button to "reply list"
[18:26:44 CEST] <Compn> probably
[18:27:03 CEST] <wm4> or thunderbird could stop making stupid changes
[18:30:27 CEST] <durandal_1707> Compn: could you pay me some bitcoins, i added mscc decoder you linked to trac report that carl closed
[18:30:55 CEST] <Compn> i do have some mplayer bitcoins
[18:31:17 CEST] <Compn> i havent ran the bitcoin client in forever
[18:31:36 CEST] <durandal_1707> really? donated?
[18:31:44 CEST] <Compn> i mean fractions of bitcoins, like .02 btc
[18:32:03 CEST] <Compn> yes someone donated to me, because i had the only bitcoin address on mplayer donation page :)
[18:32:08 CEST] <durandal_1707> still works
[18:33:17 CEST] <Compn> so i'll have to search for my wallet.dat and see if i can figure it out
[18:35:20 CEST] <Compn> did you download the other .exe files? did you find nscc ?
[18:35:21 CEST] <durandal_1707> Compn: i was joking, but dont waste bitcoins to nothing
[18:36:02 CEST] <Compn> lol
[18:36:21 CEST] <durandal_1707> Compn: nope, but nscc is very similar to mscc, just need to find files
[18:36:35 CEST] <Compn> where is that trac ticket, cant find it :\
[18:37:06 CEST] <cone-161> ffmpeg 03Diego Biurrun 07master:932cc6496ef6: vdpau: Do not #include vdpau_x11.h from the main vdpau header
[18:37:07 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:d40e181bec22: Merge commit '932cc6496ef6ab0e589ea51d3adefe5b7d7f1e2a'
[18:38:19 CEST] <durandal_1707> Compn: #3041
[18:39:01 CEST] <Compn> oh yes
[18:39:05 CEST] <Compn> that was a good bug for beginner developers
[18:39:20 CEST] <Compn> not good in that i was too lazy to make samples, but good for new developers to make samples :)
[18:39:56 CEST] <Compn> durandal_1707 : how many more unknown codecs are left, would you say ? if you could guess a number ?
[18:39:58 CEST] <Compn> 500?
[18:40:02 CEST] <cone-161> ffmpeg 03Diego Biurrun 07master:af451ac0de67: configure: Drop redundant and partly bogus vaapi/vdpau header checks
[18:40:03 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:3390a2be9deb: Merge commit 'af451ac0de6776e97d6a3ff95eac257b7964002e'
[18:40:46 CEST] <durandal_1707> Compn: i count only ones in codecs.conf not much
[18:41:15 CEST] <Compn> durandal_1707 : did you see my collection? https://wiki.multimedia.cx/index.php/Category_talk:Video_FourCCs
[18:41:36 CEST] <Compn> prepare to be surprised how many there are.
[18:41:36 CEST] <durandal_1707> ahh that is very big
[18:42:32 CEST] <Compn> VIDC.DP02=DynaPel MPEG-4
[18:42:36 CEST] <Compn> seems like an easy one.
[18:42:41 CEST] <Compn> if we can find that codec :D
[18:43:24 CEST] <Compn> oops added that long ago
[18:43:25 CEST] <Compn> nevermind
[18:43:32 CEST] Action: Compn needs food
[18:46:39 CEST] <ubitux> seems the next commit breaks alsa detection
[18:48:41 CEST] <ubitux> and it's broken in libav master, great
[18:50:02 CEST] <ubitux> ah my bad it's been fixed somewhere
[18:52:19 CEST] <ubitux> ok, the next commit is supposed to fix it
[18:52:24 CEST] <ubitux> not sure how
[19:31:34 CEST] <atomnuker> have there been any attempts to add an librsvg demuxer?
[19:32:43 CEST] <nevcairiel> isnt that more a decoder
[19:33:17 CEST] <atomnuker> well, a demuxer which demuxes and decodes svg to raw rgba
[19:33:53 CEST] <atomnuker> like libgme
[19:33:56 CEST] <nevcairiel> does it need special demuxing? why not just use image2?
[19:34:30 CEST] <atomnuker> no, not really
[19:43:18 CEST] <durandal_1707> svg can be decoded at various resolutions
[19:44:56 CEST] <atomnuker> yes, however svg files usually specify a size at which they were made anyway
[19:45:34 CEST] <atomnuker> the problem with doing it in lavf is that for probing I can do nothing else but compare "<svg" and "</svg>" as the start/end of packet
[19:45:45 CEST] <atomnuker> svgs are XML
[19:47:23 CEST] <atomnuker> ugh, I would have to do so anyway because librsvg hasn't got any function to probe
[19:53:06 CEST] <wm4> just waiting on the inevitable hrml demuxer
[19:54:51 CEST] <nevcairiel> atomnuker: worst case you can just make it match by extension
[19:55:10 CEST] <nevcairiel> for image files thats probably an OK situation
[19:57:51 CEST] <atomnuker> that's exactly what I'll do
[19:58:03 CEST] <atomnuker> svgz is just a gzipped svg so I can't even compare
[19:58:26 CEST] <atomnuker> I'll just rely on mime type and extensions and avoid dealing with any xml
[19:59:31 CEST] <atomnuker> xml? all I see are a bunch of bytes
[20:05:28 CEST] Action: kierank wonders what atomnuker is trying to do
[20:07:28 CEST] <durandal_1707> wm4: the committ you done causes #6323
[20:08:09 CEST] <wm4> let cehoyos be angry about it?
[20:11:31 CEST] <atomnuker> kierank: I've always wanted to view and render svgs without opening inkscape or firefox
[20:15:27 CEST] <atomnuker> I'd still rather do everything in the demuxer and avoid adding a codec id
[20:15:47 CEST] <wm4> but that's impure
[20:15:54 CEST] <nevcairiel> but then i cant render svgs added as attachments in mkvs!
[20:15:55 CEST] <nevcairiel> :)
[20:16:57 CEST] <nevcairiel> and using image2 for demuxing also has the advantage that you get globbing and series support and whatnot
[20:18:17 CEST] <wm4> are there svg animations yet?
[20:18:33 CEST] <wm4> or are these still restricted to DOM manipulation via external scripts
[20:20:15 CEST] <atomnuker> nevcairiel: globbing?
[20:20:39 CEST] <wm4> using a sequence of images as video
[20:21:15 CEST] <nevcairiel> https://linux.die.net/man/3/glob
[20:21:32 CEST] <nevcairiel> it uses that function specifically to parse more complex pattern then simple sequences
[20:23:32 CEST] <atomnuker> oh, I see, you mean just add support for svg in the image2 demuxer
[20:25:14 CEST] <atomnuker> image2 doesn't set any mime_type in AVInputFormat
[20:26:01 CEST] <TD-Linux> wm4, there has always been svg animations, via smil. it's been somewhat controversial though
[20:26:30 CEST] <TD-Linux> https://upload.wikimedia.org/wikipedia/commons/b/ba/Toy_train_SMIL.svg
[20:27:31 CEST] <wm4> smil..
[20:27:45 CEST] <nevcairiel> atomnuker: nothing stopping you from defining one, but i dont think mime_type is used particulary often in avformat itself
[20:27:52 CEST] <wm4> how beautiful
[20:28:45 CEST] <atomnuker> nevcairiel: I still need a standalone demuxer in addition to image2, right?
[20:28:57 CEST] <nevcairiel> no, why?
[20:29:12 CEST] <nevcairiel> there is no jpeg demuxer or something like that
[20:29:42 CEST] <wm4> I think there is?
[20:29:45 CEST] <wm4> just that it's a stub
[20:30:01 CEST] <atomnuker> every single image2 supported format has a separate demuxer
[20:30:37 CEST] <nevcairiel> those that are defined at the bottom of  img2dec.c?
[20:31:09 CEST] <wm4> yes
[20:31:10 CEST] <nevcairiel> that basically is img2, just designed to avformat can select them automatically
[20:31:19 CEST] <wm4> yep
[20:31:28 CEST] <nevcairiel> feels a bit ugly, but thats how demuxer probing works
[20:31:51 CEST] <wm4> well in theory a single demuxer could conflate them
[20:32:04 CEST] <wm4> but it's probably better this way (?)
[20:43:20 CEST] <jamrial> nobody wants to review my aac_adtstoasc patchset?
[20:50:53 CEST] <durandal_1707> wm4: fix regressions
[20:52:04 CEST] <J_Darnley> jamrial: clearly I don't know what the code is supposed to do because discarding frames smaller than their header sounds right
[20:52:47 CEST] <jamrial> not that one, the 6 patch set that starts with a movenc patch
[20:53:40 CEST] <jamrial> and that patch is to fix the passthrough case of the filter. adts header size is not relevant there
[20:53:53 CEST] <nevcairiel> J_Darnley: the packet may not have a header though, it just moves the check, not removes it
[20:54:29 CEST] <nevcairiel> i do wonder how an aac frame can be that small though
[20:55:12 CEST] <wm4> durandal_1707: I've fixed every regression I encountered
[20:57:57 CEST] <jamrial> nevcairiel: silence it seems
[20:58:18 CEST] <jamrial> the file i tested had 6 byte long frames
[21:12:00 CEST] <durandal_1707> Compn: could you create sample with dshow capture codec?
[21:25:04 CEST] <durandal_1707> Compn: you sure it actually is new codec?
[21:26:58 CEST] <J_Darnley> How the hell has some of ffmpeg's log ended up in these output files?  There goes a few days worth of work.
[21:29:53 CEST] <durandal_1707> J_Darnley: into video files?
[21:32:02 CEST] <J_Darnley> nah flac
[21:33:16 CEST] <J_Darnley> Bits of the headers have been overwritten with "stream ... pcm_s16le (native) -> flac (native)" 
[21:36:13 CEST] <durandal_1707> used pipe?
[21:37:00 CEST] <J_Darnley> No, writing to files.
[21:38:29 CEST] <durandal_1707> that impossible
[21:39:02 CEST] <J_Darnley> Meh.  I blame the wrapper script I was using around ffmpeg
[21:39:30 CEST] <J_Darnley> And Windows for not having first-class scripting.
[21:39:44 CEST] <J_Darnley> and that command lines are just a string
[21:39:47 CEST] <JEEB> powershell should be more ok than batch
[21:41:35 CEST] <J_Darnley> Ugh.  Something else I don't speak.
[21:45:37 CEST] <J_Darnley> Now I get to put 2 more things on my TODO list: find out which files are screwed; rip them again
[22:15:14 CEST] <atomnuker> is there any way to know from within a decoder whether its just being ran to get parameters?
[22:15:31 CEST] <atomnuker> to avoid doing a complete decode unnecessarily
[22:16:07 CEST] <durandal_1707> i doubt so
[22:32:26 CEST] <wm4> atomnuker: that should be done by a parser IMO, so it doesn't try to decode anything in the first place
[22:32:48 CEST] <wm4> although there are shitty hacks to do so for png and jpg
[22:40:50 CEST] <J_Darnley> Lazy POS avfilter.  Do a volume change without resampling!
[22:42:18 CEST] <durandal_1707> J_Darnley: it should without, what you doing?
[22:42:43 CEST] <J_Darnley> -af volume=0.5
[22:43:26 CEST] <durandal_1707> and its resampling?
[22:43:32 CEST] <J_Darnley> yes
[22:44:02 CEST] <J_Darnley> Yeah, resampling ym nice 16-bit integers to floats
[22:45:06 CEST] <iive> atomnuker: afair there is skip frame decoding parameter, that maybe should be useful for that case.
[22:45:17 CEST] <durandal_1707> J_Darnley: use option to force integer
[22:46:00 CEST] <J_Darnley> I NEED A FUCKING OPTION FOR THAT
[22:47:02 CEST] <durandal_1707> J_Darnley: yes, by default it uses float instructions
[22:48:31 CEST] <atomnuker> definitely lost: 15,744 bytes in 41 blocks
[22:48:44 CEST] <atomnuker> thank you glib I hope my ram was tasty
[22:59:55 CEST] <wm4> atomnuker: trying svg libs?
[23:02:10 CEST] <atomnuker> it works, cairo is suprisingly competent and even supports direct rendering
[23:02:21 CEST] <atomnuker> problem is it leaks like a garden hose
[23:02:59 CEST] <durandal_1707> nih it
[23:18:18 CEST] <Compn> durandal_1707 : ignore that dp02 , i added to mplayer long ago
[23:19:23 CEST] <durandal_1707> Compn: dp02?
[23:19:38 CEST] <Compn> durandal_1707 : what codec were you talking about ?
[23:20:50 CEST] <durandal_1707> direct show filter capture from medialooks
[23:21:17 CEST] <durandal_1707> what fourcc is it using?
[23:22:36 CEST] <Compn> i will check
[23:25:59 CEST] <Compn> so many colorspaces in this dll
[23:29:23 CEST] <Compn> durandal_1707 : oh,   i think i have this wrong. this is just a dshow filter to do screen capture
[23:29:30 CEST] <Compn> its not a codec, just a video capture source
[23:33:38 CEST] <durandal_1707> as i thought
[23:34:41 CEST] <Compn> any other codec you want me to find / check ?
[23:59:27 CEST] <J_Darnley> Can I squash a dozen, 3 year old commits together and title the patch "avcodec/flac: lpc encoder improvements"?
[00:00:00 CEST] --- Sun Apr 16 2017