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

Wed Nov 18 02:05:03 CET 2015

[00:04:40 CET] <nevcairiel> this stream actually has 127 subframes in between
[00:04:53 CET] <nevcairiel> no wonder :)
[00:08:23 CET] <nevcairiel> rc0mbs: this seems to work http://pastebin.com/Ft5L7Hth
[00:20:08 CET] <rcombs> nevcairiel: LGTM
[00:29:59 CET] <nevcairiel> i put it on the ml
[00:35:46 CET] <rcombs> cool
[00:54:42 CET] <cone-671> ffmpeg 03James Almer 07master:9e3b39ed691d: avformat/movenc-test: fix copyright header
[00:55:48 CET] <nevcairiel> should've removed it from the exception list while you're at it =p
[01:02:39 CET] <jamrial_> i thought the exception list was for files with weird license headers
[01:04:11 CET] <kierank> nevcairiel: how did you get the mlp spec
[01:04:29 CET] <nevcairiel> i didnt, that part is in the bd spec
[01:04:41 CET] <kierank> ah
[01:05:24 CET] <jamrial_> oh, removed. misread what you said
[01:05:52 CET] <jamrial_> why did Daemon404 add it there instead of fixing the header in the merge to begin with, lol
[01:07:31 CET] <Daemon404> jamrial_, dumbness
[01:08:26 CET] <Daemon404> i also didnt think we'd have a fate test that failed based on what project is in the header of a c file
[01:08:37 CET] <Daemon404> that is so beyond ridiculous it didnt even occur to me
[01:08:45 CET] <Daemon404> my bad, though.
[01:09:04 CET] <jamrial_> we almost almost get one that would fail with common typos :p
[01:10:15 CET] <jamrial_> but didn't make it in
[01:10:28 CET] <Daemon404> it could be even more insane
[01:10:38 CET] <Daemon404> openembedded used to use hashes of licenses and headers.
[01:10:41 CET] <Daemon404> to ID them
[01:11:04 CET] <Daemon404> (iirc)
[01:12:46 CET] <cone-671> ffmpeg 03James Almer 07master:88e381c807b9: fate: update fate-source reference file
[01:37:03 CET] <cone-671> ffmpeg 03Michael Niedermayer 07master:bf6d41d8a233: avcodec/internal: Fix skiped typo
[02:17:03 CET] <Timothy_1u> We need a clang for windows fate station
[02:17:30 CET] <J_Darnley> Does it work now?
[02:19:39 CET] <Timothy_1u> According to that Chromium guy, no
[02:19:50 CET] <Timothy_1u> not for FFmpeg at least
[02:20:03 CET] <Timothy_1u> although it should
[02:21:15 CET] <wm4> wait does that mean chromium is going to use clang on windows?
[02:26:31 CET] <J_Darnley> How old is 3.5.2, I wonder.
[02:28:22 CET] <J_Darnley> hmm a little old
[02:29:34 CET] <J_Darnley> ha only 7 months
[02:31:51 CET] <J_Darnley> Oh is that the message that triggered this?  tzcnt
[02:54:33 CET] <jamrial_> clang defines __INTEL_COMPILER and/or _MSC_VER then?
[06:26:22 CET] <Timothy_1u> wm4: probably eventually https://chromium.googlesource.com/chromium/src/+/master/docs/clang.md#Windows
[06:27:07 CET] <Timothy_1u> so I guess it apparently defines _MSC_VER
[09:35:24 CET] <nevcairiel> Microsoft has been working with the clang guys to get clang for windows going, once MS makes their first official release I was going to see about getting ffmpeg setup for that properly
[09:37:16 CET] <nevcairiel> (nad setting up a fate box)
[09:37:48 CET] <wm4> I wonder how broken C support will be
[09:37:56 CET] <wm4> surely worse than mingw
[09:38:07 CET] <nevcairiel> how so
[09:38:23 CET] <nevcairiel> i havent really used clang much before, is it bad at C? :p
[09:39:02 CET] <wm4> no, but I assume it uses the MS headers and runtime
[09:39:17 CET] <wm4> to be ABI compatible to it
[09:39:25 CET] <nevcairiel> vs2015 is pretty good at C these days, anyway
[09:39:48 CET] <wm4> but are they not missing typical fixes like large file support?
[09:39:59 CET] <nevcairiel> that sounds like a posix thing
[09:40:02 CET] <nevcairiel> not C
[09:40:25 CET] <wm4> yeah, MS has a very broken posix subset there; mingw fixes these things anyway
[09:41:16 CET] <nevcairiel> in any case, ffmpeg builds with vs2015 with minimal compat hacks, so i dont expect clang to be any different
[09:41:27 CET] <nevcairiel> and not using lacking mingw headers is a good thing :)
[09:44:01 CET] <TimNich> compzring clang on OSX and Windoze will be interesting
[09:44:17 CET] <nevcairiel> on top of that you can hopefully get inline asm with clang, which should fix a big part of the performance disparity of msvc builds
[09:44:56 CET] <TimNich> hmm. I use yasm with clang on OSx
[09:45:36 CET] <wm4> there are no ffmpeg perf problems on osx, right
[09:45:50 CET] <TimNich> not that I have found
[09:45:59 CET] <wm4> so clang not only handles the inline asm, but it handles it just fine
[09:47:56 CET] <TimNich> afaik, but Im no expert. I just ensure that I configure --as=yasm
[09:48:17 CET] <nevcairiel> that sounds odd
[09:48:29 CET] <TimNich> in what w`y
[09:48:36 CET] <nevcairiel> using yasm as as
[09:49:22 CET] <TimNich> It was reccomended by hexeract so I tired it.
[09:51:39 CET] <TimNich> once upon a time gcc on osx was gcc, now it links to llvm&
[09:52:59 CET] <TimNich> so maybe  unnecessary now.
[13:18:04 CET] <wm4> do we have a coding style?
[13:19:27 CET] <wm4> I see https://ffmpeg.org/developer.html#Contributing but there's nothing whether something like "if(foo){" is ok or if it should be "if (foo) {"
[13:25:14 CET] <Compn> wm4 : patcheck :P
[13:25:24 CET] <Compn> wm4 : did that student from westminster email you ?
[13:25:29 CET] <wm4> no
[13:26:03 CET] <Compn> a lot of students mail webmaster/projects and ask questions for their homework
[13:28:29 CET] <wm4> do we allow C99 bool?
[13:31:08 CET] <kierank> has anyone got ieee access?
[13:31:46 CET] <kierank> please try http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=7289943&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel7%2F7289941%2F7289942%2F07289943.pdf%3Farnumber%3D7289943
[13:36:03 CET] <atomnuker> wm4: pretty sure we do not
[13:40:41 CET] <Compn> google spidered it but no cache, http://ieeexplore.ieee.org/iel7/7289941/7289942/07289943.pdf?arnumber=7289943
[14:06:42 CET] <ubitux> do we have swscale convert tests?
[14:06:58 CET] <ubitux> (pixel fmt convert)
[14:07:09 CET] <ubitux> aside from the random lavfi side effects convert etc
[14:36:30 CET] <ubitux> why do we have weird Y coeff in yuv2rgb convert?
[14:36:40 CET] <ubitux> why isn't it a pow of 2?
[14:43:53 CET] <J_Darnley> As long as the coeffs are correct it doesn't much matter, right?
[14:44:11 CET] <ubitux> it does, because in asm you can do a shift instead of a mul
[14:44:42 CET] <J_Darnley> True but then you are saving 1 because the others can't be powers of 2 also
[14:44:50 CET] <ubitux> ah fuck it's because it's not set to full range
[14:45:30 CET] <ubitux> J_Darnley: i don't understand
[14:46:46 CET] <ubitux> color,format=nv12,format=rgb32  fullrange=0
[14:46:47 CET] <J_Darnley> There are 9 coeffs to use making 1 a power still leaves the other 8 as non-power
[14:46:48 CET] <ubitux> :(
[14:47:03 CET] <ubitux> 4+1 coeffs
[14:47:09 CET] <ubitux> (yuv2rgb)
[14:47:38 CET] <J_Darnley> Ah.  wrong way round
[14:47:38 CET] <ubitux> yes the others are mul, but it's for chroma only anyway
[14:49:31 CET] <ubitux> damn and there is a need for offsetting
[14:50:56 CET] <wm4> sigh, h264 crashes randomly if videotoolbox returns an error from end_frame
[14:51:10 CET] <wm4> well doesn't crash, but returns the dummy buffer
[14:51:40 CET] <wm4> and if you unset the dummy buffer in end_frame, some assertion triggers when uniniting the codec context
[14:52:17 CET] <Compn> more asserts!
[14:53:00 CET] <J_Darnley> Isn't hardware acceleration grand?
[14:53:21 CET] <wm4> it has nothing to do witg hardware acceleration
[14:53:25 CET] <wm4> just shitty h264.c logic
[14:53:33 CET] <J_Darnley> Oh I thought that's what video toolbox was
[14:54:16 CET] Action: J_Darnley is making an arse of himself today
[14:55:15 CET] <wm4> and of course the broken logic has to do with error recovery
[15:12:38 CET] <SianaGearz> helloes. as a potential user of ffmpeg, how do i go about integrating an auxiliary data stream? i want a few additional bytes of per-frame information in for streaming.
[15:13:09 CET] <SianaGearz> i haven't actually actively strated on things, just poking around what to use. :P
[15:23:13 CET] <SianaGearz> oh sorry, i should have seen the topic. but the other channel is not very helpful. oh well.
[15:36:18 CET] <kierank> Compn: https://github.com/subho007/python-downloader
[15:42:14 CET] <jonga> when streaming to rtmp the process is very fast and ending before i can play it [ stream ] with ffplay what is up ?
[15:42:51 CET] <kierank> -re
[15:48:14 CET] <jonga> i stream an mp4 or a flv to an rtmp server , the transfer is made with big steps [size] exmpl:a jump from 2mo to 11mo in one step even if the file is bigsize and finish the stream in a little delay
[15:50:36 CET] <BtbN> you can't stream mp4.
[15:51:10 CET] <BtbN> And -re is the option you are looking for.
[15:58:31 CET] <jonga> i understand before -i ?
[15:59:26 CET] <jonga> or before -f ?
[16:01:30 CET] <cone-584> ffmpeg 03Martin Storsjö 07master:09e431b9e367: movenc: Assume streams starting at pts=0 for discontinuous fragments with editlists
[16:01:32 CET] <cone-584> ffmpeg 03Martin Storsjö 07master:3eeb7edfc2a1: movenc: Add a unit test for frag_discont with edit lists
[16:01:33 CET] <cone-584> ffmpeg 03Derek Buitenhuis 07master:6c9fb32ae476: Merge commit '09e431b9e3674804172e7b0a0f865b65ec09739a'
[16:01:35 CET] <cone-584> ffmpeg 03Derek Buitenhuis 07master:f6e5b17abb44: Merge commit '3eeb7edfc2a1157b7b0e0ce21ac2cd44d55d405b'
[16:10:28 CET] <jonga> hi BtbN im streamin an mp4 file rightnow : ffmpeg -re -i veneration.mp4 -f flv rtmp://localhost/live/live.sdp
[16:10:44 CET] <BtbN> no, you are streaming via rtmp, so essentials flv.
[16:10:45 CET] <BtbN> *y
[16:10:59 CET] <Daemon404> hmm...
[16:11:00 CET] <Daemon404> -                baseMediaDecodeTime = 45056
[16:11:00 CET] <Daemon404> +                baseMediaDecodeTime = 43008
[16:11:05 CET] <jonga> oh i understand
[16:11:09 CET] <Daemon404> i wonder if this is due to the invalid aac
[16:11:54 CET] <jonga> you mean not -f mp4 rtmp://....
[16:13:54 CET] <jonga> ?
[16:20:48 CET] <jonga> i thank you btbn
[16:23:41 CET] <Daemon404> philipl_, ping
[16:23:42 CET] <Daemon404> you here?
[16:42:01 CET] <Daemon404> nevcairiel, seems that the malformed aac thing is not a warning
[16:42:03 CET] <Daemon404> it's an 'error'
[16:42:07 CET] <nevcairiel> i know
[16:42:15 CET] <Daemon404> yeah well it utterly breaks the unit test
[16:42:17 CET] <Daemon404> since it drops the packets
[16:42:17 CET] <nevcairiel> which is why i said its going to be fun
[16:44:12 CET] <Daemon404> looking at b448c0a68d0cc7dfef736267dfdaed0e213c020b
[16:44:18 CET] <Daemon404> the commit message and what it does seem to be the exact opposite
[16:44:52 CET] <Daemon404> afaict?
[16:45:15 CET] <nevcairiel> it was changed to only error on the first packet
[16:45:22 CET] <Daemon404> ... but why
[16:45:22 CET] <nevcairiel> or something
[16:45:25 CET] <Daemon404> that seems nonsensical
[16:45:42 CET] <nevcairiel> so the message for ffmpeg cli users can be output, doh
[16:45:49 CET] <Daemon404> ...
[16:45:55 CET] <Daemon404> why would you return -1 then
[16:45:58 CET] <Daemon404> you can still print it
[16:46:16 CET] <nevcairiel> also because adts in mp4 is probably invalid
[16:46:44 CET] <nevcairiel> why does your data start with 0xfff0 anyway
[16:46:51 CET] <nevcairiel> that seems like an odd coincedence
[16:46:55 CET] <Daemon404> ask wbs :D
[16:47:15 CET] <nevcairiel> i thought it writes the timestamp into the data
[16:47:18 CET] <nevcairiel> is the timestamp negative?
[16:47:37 CET] <Daemon404> of course it is
[16:47:48 CET] <Daemon404> or, it should be, for this test
[16:47:54 CET] <Daemon404> thats kind of the point
[16:47:54 CET] <nevcairiel> guess that explains it
[16:48:05 CET] <nevcairiel> negative gives you many f's
[16:48:05 CET] <nevcairiel> :D
[16:48:08 CET] <Daemon404> ah... yes
[16:48:09 CET] <Daemon404> it's -10
[16:48:18 CET] <Daemon404> iirc
[16:48:23 CET] <Daemon404> still
[16:48:33 CET] <Daemon404> [15:46] <@nevcairiel> also because adts in mp4 is probably invalid
[16:48:41 CET] <Daemon404> i dont get why this means write only packet 2+
[16:48:44 CET] <Daemon404> surely the rest are *also* wrong
[16:48:49 CET] <nevcairiel> actually it doesnt
[16:49:12 CET] <nevcairiel> if all frames are adts, it will always error
[16:49:17 CET] <Daemon404> oh i see, it 
[16:49:21 CET] <nevcairiel> but if the first would be valid, then it would let further packets through
[16:49:23 CET] <Daemon404> "skips" the "right" packets
[16:49:26 CET] <Daemon404> to make it "right"
[16:49:34 CET] <Daemon404> by checking for 0xFFF0
[16:49:54 CET] <Daemon404> this seems like it would be incredibly error prone
[16:49:58 CET] <nevcairiel> should push rcombs
[16:50:01 CET] <Daemon404> depending on how packets are layed out
[16:50:02 CET] <Daemon404> no?
[16:50:02 CET] <nevcairiel> ' patch already
[16:50:07 CET] <nevcairiel> and make it auto-use the bsf
[16:50:09 CET] <nevcairiel> get rid of hackery
[16:50:26 CET] <nevcairiel> why would it be error prone
[16:50:26 CET] <Daemon404> was there anything blocking rcombs
[16:50:31 CET] <nevcairiel> valid aac never starts with 0xfff
[16:50:48 CET] <Daemon404> yes but this is only skipping those packets
[16:50:49 CET] <rcombs> Daemon404: there was one issue about error handling in the BSFs and I forget if I fixed it
[16:50:53 CET] <rcombs> I think I did but lemme make sure
[16:50:58 CET] <Daemon404> nevcairiel, what abotu grouped packets
[16:51:00 CET] <Daemon404> or do we never have those
[16:51:25 CET] <nevcairiel> thats what we have parsers for to split things
[16:51:34 CET] <Daemon404> eh right
[16:51:41 CET] <Daemon404> i always forget the difference between parsers and bsfs
[16:51:53 CET] <nevcairiel> parsers just slice, bsf convert
[16:52:20 CET] <Daemon404> most of that 'conversion' is dropping packets
[16:52:25 CET] <Daemon404> but i see your point
[16:52:32 CET] <Daemon404> (or parts of packets)
[16:52:47 CET] <nevcairiel> in this case yes
[16:53:02 CET] <nevcairiel> the annexb converter in contrast to that adds data to the stream
[16:53:07 CET] <Daemon404> anyway, i guess i cant merge the next patch / test (which is the one i need) until we solve this
[16:53:23 CET] <Daemon404> since the unit test is an noop for one track atm
[16:53:33 CET] <nevcairiel> change the data format it writes so it starts with an extra zero byte or something
[16:53:46 CET] <Daemon404> lull... i guess
[16:53:51 CET] <nevcairiel> need to update hashes, but they dont match libav's anyway
[16:53:58 CET] <Daemon404> only some hashes would need to be updated
[16:54:06 CET] <Daemon404> only some of the unit tests rely on this
[16:54:39 CET] <nevcairiel> (to avoid shenanigans entirely, i would probably double the size and write 32-bit zero followed by 32-bit pts)
[16:54:54 CET] <Daemon404> thats my plan
[16:55:09 CET] <Daemon404> ill send a patch
[16:55:16 CET] <Daemon404> i see why you pawned off merging this to me
[16:55:31 CET] <nevcairiel> haha
[16:55:51 CET] <Daemon404> the differences in the mov code are pretty big
[16:56:16 CET] <rcombs> yeah, I did fix that
[16:56:16 CET] <nevcairiel> i wanted to start looking at it, but since you offered
[16:57:38 CET] <nevcairiel> i forgot what my comments were for the bsf stuff
[16:57:46 CET] <nevcairiel> github doesnt preserve them when you re-push the branch :(
[16:58:18 CET] <Daemon404> hat drives me nuts
[16:58:23 CET] <Daemon404> i lose comments for future reference
[17:00:08 CET] <nevcairiel> rcombs: does that pass fate as is, or does it need ref updates somewhere?
[17:03:18 CET] Action: rcombs updates branch
[17:03:20 CET] <rcombs> let's find out
[17:03:28 CET] <Daemon404> patch sent
[18:22:42 CET] <Compn>  kierank : thanks much
[18:25:00 CET] <Compn> thats a generic name, not easy to find haha
[18:48:48 CET] <philipl_> Daemon404: what's up?
[18:48:55 CET] <Daemon404> philipl_, nvm i figured it out =p
[18:49:14 CET] <Daemon404> i was gonna ask about some mov subtitle thing, but its obvious now
[18:49:16 CET] <philipl_> jolly good
[18:49:41 CET] <philipl> Although I'd generally say there's nothing obvious about those subtitles :-)
[18:50:25 CET] <Daemon404> ;p
[19:18:14 CET] <durandal_1707> michaelni_: are multirate rm supported?
[19:21:43 CET] <cone-584> ffmpeg 03Michael Niedermayer 07master:a5034b324cad: avformat/matroskadec: Check subtitle stream before dereferencing
[19:23:27 CET] <michaelni_> i dont remember exactly but i think they partly are
[19:27:52 CET] <Compn> durandal_1707 :  some work ,some do not
[19:28:01 CET] <Compn> durandal_1707 : rm demux really kind of sucks
[19:28:13 CET] <nevcairiel> s/demux//
[19:28:29 CET] <Compn>  durandal_1707: https://trac.ffmpeg.org/ticket/2077
[19:29:11 CET] <Compn> durandal_1707 : https://trac.ffmpeg.org/ticket/1891  
[19:29:22 CET] <Compn> https://trac.ffmpeg.org/ticket/3084
[20:11:13 CET] <wm4> nice, clang/chromium guy fixed it in clang, instead of making us add a workaround
[20:12:38 CET] <nevcairiel> thats always nice
[20:19:03 CET] <llogan> inconceivable!
[20:21:03 CET] <llogan> they have a weird review thing: http://reviews.llvm.org/D14748
[21:23:34 CET] <durandal_1707> bing can find ivr that google can't
[21:45:01 CET] <J_Darnley> People must be very dedicated to build compilers from source.
[21:45:17 CET] <kierank> I built GCC once from source
[21:45:21 CET] <kierank> I don't recall why
[21:45:32 CET] <nevcairiel> i build gcc every release from source
[21:45:40 CET] <nevcairiel> where else would i get decent windows binaries
[21:45:40 CET] <nevcairiel> :)
[21:45:46 CET] <J_Darnley> :)
[21:48:33 CET] <atomnuker> I used to build my gcc from source
[21:48:56 CET] <atomnuker> but then I realized debian did that already and an isolated gcc-snapshot package
[21:49:14 CET] <nevcairiel> i have a script setup and everything, so every new gcc release i just check if any deps need updating, run it, package it up, and done
[22:11:21 CET] <rcombs> I've built both gcc and clang a few times
[22:11:26 CET] <rcombs> it's not that bad in most cases
[22:16:04 CET] <Daemon404> assuming you understand what a canadian cross is and why you need it
[22:16:08 CET] <Daemon404> (clang doesnt need it
[22:29:23 CET] <J_Darnley> For crying out loud.  Useless autotools shit.
[22:31:07 CET] <cone-584> ffmpeg 03Ganesh Ajjanagadde 07master:3fb32ae2cf03: avformat/rtpdec_mpa_robust: change assignment to inequality test in conditional
[22:36:39 CET] <cone-584> ffmpeg 03Ganesh Ajjanagadde 07master:e9aea6d7cf17: avcodec/faandct: use typedef instead of #define
[22:39:45 CET] <J_Darnley> WTF!  Where did my bash history go to?
[22:40:29 CET] <atomnuker> it got corrupted?
[22:40:35 CET] <J_Darnley> No idea
[22:40:49 CET] <J_Darnley> It got cut from >20K lines to <1000
[22:44:01 CET] <wm4> what a loss
[22:44:12 CET] <atomnuker> no
[22:44:21 CET] <atomnuker> 1000 lines is a tragedy
[22:44:26 CET] <atomnuker> 19000 is a statistic
[22:51:07 CET] <J_Darnley> Oh thank god I never clean anything up.  I found a slightly old backup I had
[22:52:52 CET] <atomnuker> btw, here's the FFmpeg daala decoder I wrote in case any of you get bored of 10+ year old game codecs
[22:52:55 CET] <atomnuker> https://github.com/atomnuker/FFmpeg
[22:53:29 CET] <atomnuker> only lossless I-frames right now
[22:53:40 CET] <BBB> daala?
[22:53:44 CET] <BBB> but daala is not finished yet
[22:53:44 CET] <atomnuker> yep
[22:56:00 CET] <BBB> so ...
[22:56:03 CET] <BBB> I have to ask
[22:56:15 CET] <BBB> thor, daala, vp10, and I believe there was one more right?
[22:56:31 CET] <BBB> this seems utterly wasteful
[22:56:43 CET] <JEEB> well at least thor and daala seem to be on a similar playfield
[22:56:44 CET] <BtbN> The open ones want to join forces though
[22:56:57 CET] <JEEB> vp10 is as göggels as göggels ever was
[22:58:14 CET] <atomnuker> göggels?
[22:58:31 CET] <nevcairiel> isnt thor just "hevc lite"?
[22:58:42 CET] <atomnuker> pretty much
[22:59:24 CET] <nevcairiel> dalaa is the only codec of the bunch actually exploring entirely new concepts, instead of just iterating on the old things like hevc, vp10, etc
[22:59:30 CET] <JEEB> true
[22:59:43 CET] <JEEB> atomnuker: the G
[23:00:23 CET] <nevcairiel> speaking of things not quite done yet, where is claudio with our missing aac fixes? :)
[23:00:31 CET] <atomnuker> was at pycon
[23:00:36 CET] <atomnuker> now back
[23:00:56 CET] <nevcairiel> it sounded like we are so close to the goal :D
[23:02:16 CET] <durandal_1707> atomnuker: have filter that draws fixed font text?
[23:05:23 CET] <atomnuker> huh?
[23:08:27 CET] <durandal_1707> you don't use filter to draw text of that screenshot?
[23:09:46 CET] <atomnuker> no, just ff_draw_pc_font() for now because it was dead simple to use
[00:00:00 CET] --- Wed Nov 18 2015